1 部署前的準備

1.1 網絡環境規劃：

如圖：

1.1.1 DAG介紹：

數據庫可用性組 (DAG) 可以容納多達 16 個郵箱服務器，並且可以跨多個物理位置和 Active Directory 站點擴展 DAG，這些都爲 DAG 提供了很多體系結構設計可能性。

可以在下列各種環境中使用 DAG 的設計示例：

1.兩成員 DAG，適用於小型辦公室和分區辦公室部署

2.四成員 DAG，可通過定位同一數據中心中的所有成員來提高單個數據中心的高可用性

3.四成員 DAG，可通過在主數據中心定位兩名成員和在第二個數據中心定位另外兩名成員來提高單個數據中心的高可用性以及該數據中心的站點彈性DAG 所使用的設計和郵箱數據庫副本的分發方式將基於組織的服務級別協議 (SLA) 和這些 SLA 中聲明的郵箱服務和數據的恢復時間目標和恢復點目標。

單個數據中心/Active Directory 站點中的四成員 DAG : 單個數據中心部署中的四成員 DAG 可提供比兩成員或三成員 DAG 彈性更大的故障應對能力。更大的 DAG 本身就能提供更大的彈性，因爲它們能夠承受更多故障且不會造成服務中斷。在不損失仲裁和有損服務的情況下，兩成員或三成員 DAG 僅可承受失去單個投票者的情形，而四成員 DAG（按照定義，它有五個仲裁投票者）則可承受失去兩個投票者的情形。

1.1.2 此配置有幾個方面值得注意：

1.在此設計中，僅將客戶端訪問、郵箱和集線器傳輸這三種服務器角色設在一起。儘管支持與統一消息服務器角色位於同一地點，但出於性能考慮建議不要如此配置。

2.若要實現客戶端訪問和集線器傳輸服務器角色的高可用性，應當在客戶端和這些服務器角色之間使用某種形式的負載平衡。因爲這些服務器角色與是 DAG 成員的郵箱服務器位於同一地點，所以不能使用，Windows 網絡負載平衡 (NLB)（因爲 NLB 和 Windows 故障轉移羣集不能安裝在同一個服務器上），而必須使用非 Windows NLB 解決方案（例如 Internet Security and Acceleration (ISA) Server 2006 負載平衡、硬件負載平衡器或基於第三方軟件的負載平衡器）。

3.與所有成員人數爲偶數的 DAG 一樣，兩成員 DAG 也需要見證服務器來維護仲裁。只要仲裁投票者中有超過半數的人可用並正在通信即可維護仲裁。具有見證服務器的兩成員 DAG 提供三個仲裁投票者（一旦它們可用並正在進行通信，每個 DAG 成員和見證服務器就可以投票）。因此，兩成員 DAG 不會因單個投票者（例如，某個 DAG 成員，或只是見證服務器）的故障或中斷而中斷服務。但是，如果丟失兩個投票者（例如，某個 DAG 成員和見證服務器），則將導致仲裁丟失，進而導致服務中斷。

1.1.3 數據庫副本佈局設計

爲郵箱服務器設計高可用性解決方案時，需要確保各種基礎結構組件的高可用性，其中包括：

基礎結構服務（如 Active Directory 和域名系統 (DNS)）

數據庫可用性組 (DAG) 成員服務器

各個存儲組件（如磁盤、存儲控制器和存儲架）

各個網絡組件（如路由器、交換機和聚合器）

服務器和存儲機架

電源總線

數據中心

每一個組件區域均代表潛在的故障點，有時將其稱爲“故障域”。因此，DAG 的可用性級別最終取決於如何設計解決方案來隔離並最小化某個域發生故障時可能對 DAG 環境產生的負面影響。若要實現故障域之間的獨立性，每個故障域必須具有一個數據庫副本。此外，由於故障會導致多個副本不可用，因此每個故障域僅需要一個副本。

例如，考慮有兩個數據庫副本的情況。每個副本分別存儲在單獨的磁盤組中，但這兩個副本位於相同的存儲陣列中。如果存儲陣列出現故障或因任何原因不可用，則這兩個副本也將不可用。在本示例中，故障域爲存儲陣列。陣列中只應駐留每個郵箱數據庫的一個副本。否則，如果陣列出現故障，數據庫的多個（也可能所有）副本都將不可用。

規劃郵箱體系結構時，需考慮以下其他設計要點：

是否部署多個數據庫副本？

部署多少個數據庫副本？

是否有站點恢復體系結構？

部署哪種類型的郵箱服務器恢復模型？

部署多少個郵箱服務器？

使用什麼備份模型？

使用什麼存儲體系結構？

DAG部署規劃不再做過多介紹，如要了解更詳細信息請參閱微軟官方技術文檔庫

http://technet.microsoft.com/zh-CN/library/dd638104

本環境爲虛擬環境，所有服務器均在Hyper-V羣集中進行。