1. 首頁 > 云知道 > >

一 域控制器發生故障時確保繼續復制活動目錄

云知道

對管理員來說 ， 他們最重要的工作能力之一就是要能進行突發故障的恢復 ， 無論該故障是故意的還是偶然的 。活動目錄（AD）災難恢復包括確保AD恢復的許多方面 。比起只是留有備份 ， 這要復雜的多 。本篇是關于AD災難恢復系列文章里的第一篇 ， 這些系列文章包括了從如何確保環境保護到災難損失方面的實用例子 。
確保你能對任何故障 ， 無論硬件還是軟件方面進行恢復的最佳方法就是要搶先防備 。設法讓業務停工期的時間最短 ， 最好沒有停工期 。在本文中 ， 我們將討論關于在關鍵域控制器發生故障時如何確保繼續復制AD方面的問題 。
密碼和安全發生改變 ， 安全策略以及關鍵配置設置通過組策略執行 ， FRS復制和AD復制都能使所有域控制器具有相同的組策略 。因此 ， 有理由相信它是企業的最大興趣點 ， 可幫助企業確保成功進行AD復制 ， 并保留未遭破壞的部分 。對公司來說 ， 通常會創建災難恢復站點 ， 在整個組織“軸心”站點出現故障時 ， 該站點可用于支持基礎結構 ， 關鍵應用程序以及數據 。許多組織網絡以重復軸心及輪輻網絡方式進行配置 ， 如圖一所示 。注意在某些配置中 ， 多種軸心形成AD恢復的核心 。多種核心軸心站點包含固有的災難恢復配置 。也就是說 ， 如果一個核心站點出現故障 ， 還有其他站點分擔載荷 。
對單一的軸心配置來說 ， 災難恢復的難題在于在網絡鏈接良好的地方創建AD站點 ， 至少與企業中的每個森林的每個域中的一個域控制器相連接 。這就得包括至少一個通用目錄服務器（GC） ， Exchange服務器和其他依賴于用來支持用戶社區的基礎結構中的打印文件或應用程序服務器 。
假設我們選擇了這樣一個站點 ， 并具備必需的服務器基礎結構 ， 我們需確定的一件事就是在主要軸心站點不可用時AD恢復會如何 。記住 ， 你不必非要等到對該站點的恐怖襲擊會使其不可用 ， 一個簡單的網絡故障或電力損耗都會使其出現問題 。
你需要考慮哪里的網絡是簡單的中心輻射型拓撲結構 。如果主要軸心站點發生故障 ， 設計良好的DR站點可以繼續工作 。為避免軸心站點中所有域控制器發生故障 ， 在考慮如何準備多余AD復制時要創建與主要軸心站點及DR站點之間的站點鏈接 ， 如圖二所示 。這里我們發現將遠程站點與主要軸心站點相鏈接起來的站點消耗為100 ， 而那些將遠程站點與DR站點鏈接起來的要消耗200 。表面看起來很有道理 。只要主要站點中的域控制器還在運行 ， 就不會用到多余的鏈接 。然而 ， 在測試主要站點域控制器實效時 ， 我們發現KCC計算出不同的拓撲結構 ， 而不是本來想要的結構 ， 這樣就在遠程站點之間而不是直接同DR站點建立連接 。它無法進行糾正 。在考慮為何KCC會以這種方式進行計算時會發現 ， AD復制規則中顯示該錯誤是源于設計問題 。
【一 域控制器發生故障時確保繼續復制活動目錄】活動目錄復制有一個內置的冗余特性 ， 被稱為站點鏈接橋（SLB） 。如在任何給定站點中 ， 域控制器出現故障 ， SLB允許KCC建立可傳遞鏈接 ， 在不需人力操作的情況下 ， 允許復制對出現故障的域控制器進行調整 。當出現故障的域控制器是站點中唯一的域控制器（或者 ， 如站點中所有域控制出現問題時） ， SLB就尤為重要了 ?？纯磮D示三中的情況 。有三個站點 ， ATL ， CHI ， 以及NYC 。假設物理網絡將所有三個站點聯結起來 ， 一個站點鏈接聯結ATL和CHI ， 一個站點鏈接聯結CHI和NYC 。ATL與NYC之間沒有站點鏈接聯結 。只要CHI中的域控制器可用 ， 復制就沒有問題 。但如果CHI域控制器發生故障怎么辦？似乎ATL同NYC之間的復制也會無法進行 ， 在沒有SLB的情況下更會出現這種問題 。如果SLB可用 ， KCC就要有所決定 ， 因為ATL能復制到CHI ， CHI復制到NYC ， 然后ATL又能復制到NYC 。從ATL到NYC之間又會創建鏈接 ， 消耗與CHI-NYC ， ATL-CHI鏈接的聯合消耗相等 。

推薦閱讀