規劃高可用性及站台恢復
適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3
上次修改主題的時間： 2016-11-28
Microsoft Exchange Server 2010 包含一個新的信箱恢復整合架構，其中的新功能包含資料庫可用性群組 (DAG) 和信箱資料庫副本。儘管部署這些新功能的處理程序很快速而且簡單，但是事先必須小心規劃，以確保使用這些功能的所有高可用性和站台恢復解決方案能夠符合您的期望和企業的需求。
在規劃階段期間，系統建構者、系統管理員和其他關鍵專案關係人應該識別部署的需求；尤其是高可用性和站台恢復的需求。部署這些功能有一些必須符合的一般需求，同時也有必須符合的硬體、軟體及網路需求。如需 DAG 儲存需求的指引，請參閱信箱伺服器儲存設計。
目錄
一般需求
硬體需求
儲存需求
軟體需求
網路需求
見證伺服器需求
規劃站台恢復
規劃資料中心轉換
一般需求
部署 DAG 和建立信箱資料庫副本之前，請確認符合下列整體系統建議：
必須執行網域名稱系統 (DNS)。理想的情況是，DNS 伺服器應接受動態更新。如果 DNS 伺服器不接受動態更新，則必須爲每個 Exchange 伺服器建立 DNS 主機 (A) 記錄。否則，Exchange 無法正常運作。
DAG 中的每個信箱伺服器都必須是相同網域中的成員伺服器。
不支援新增同時也是 DAG 目錄伺服器的 Exchange 2010 信箱伺服器。
您指派給 DAG 的名稱必須是 15 個字元或以下的有效、可用和唯一的電腦名稱。
硬體需求
一般而言，DAG 或信箱資料庫副本沒有專屬的特殊硬體需求。使用的伺服器必須符合 Exchange 2010 必要條件和 Exchange 2010 系統需求主題中所設定的所有需求。如需硬體規劃的資訊，請參閱下列主題：
儲存需求
一般而言，針對 DAG 或信箱資料庫副本，並沒有特殊的儲存需求。DAG 不需要也不使用叢集受管理的共用儲存。只有當 DAG 設定為使用在 Exchange 2010 中採用協力廠商複寫 API 的解決方案時，才支援在 DAG 中使用叢集受管理的共用儲存。如需儲存規劃詳細資訊，請參閱信箱伺服器儲存設計。
軟體需求
DAG 可在 Exchange 2010 Standard Edition 與 Exchange 2010 Enterprise Edition 中使用。此外，一個 DAG 中可以包含執行 Exchange 2010 Standard Edition 和 Exchange 2010 Enterprise Edition 之伺服器的混合。
DAG 的每個成員也都必須執行相同的作業系統。Exchange 2010 和 Windows Server 2008 R2 作業系統皆支援 Windows Server 2008。DAG 的所有成員都必須執行 Windows Server 2008 或 Windows Server 2008 R2。它們不能包含 Windows Server 2008 和 Windows Server 2008 R2 的組合。
除了符合安裝 Exchange 2010 的必要條件之外，還有必須符合的作業系統需求。DAG 使用 Windows 容錯移轉叢集技術，因此需要使用 Enterprise 版本的 Windows。
網路需求
每個 DAG 和 DAG 成員都有必須符合的特定網路需求。DAG 網路與舊版 Exchange 中使用的公用、混合和私人網路類似。不過與舊版不同的是，在每個 DAG 成員中使用單一網路是受支援的組態。此外，有些術語已經變更。與使用公用、私人或混合網路不同，每個 DAG 都有一個單一的*「MAPI 網路」(由其他伺服器 (例如，其他 Exchange 2010 伺服器、目錄伺服器等等) 使用以便與 DAG 成員進行通訊)，以及零或多個「複寫網路」*(專用於記錄傳送和植入的網路)。
儘管支援單一網路，但我們建議每個 DAG 至少有兩個網路：單一 MAPI 網路和單一複寫網路。這可提供網路和網路路徑的備援，並讓系統能夠辨別伺服器失敗和網路失敗。使用單一網路介面卡會讓系統無法辨別這兩種類型的失敗。
.gif "注意事項") 附註： |
|---|
| 此內容區域中的產品文件是以假設每個 DAG 成員至少包含兩個網路介面卡、每個 DAG 設定一個 MAPI 網路和至少一個複寫網路，以及系統能够辨別網路失敗和伺服器失敗來撰寫。 |
設計 DAG 的網路基礎結構時，請考慮下列各項：
DAG 的每個成員都必須至少有一個能够與其他所有 DAG 成員進行通訊的網路介面卡。如果您使用單一網路路徑，則建議您使用 Gigabit Ethernet。在每個 DAG 成員中使用單一網路介面卡時，不需要為 DAG 網路啟用複寫，並應將其設定為 MAPI 網路。因爲沒有其他網路，因此系統也將使用 MAPI 網路作為複寫網路。此外，在每個 DAG 成員中使用單一網路介面卡時，建議您根據單一網路介面卡和路徑來設計整體解決方案。
在每個 DAG 成員中使用兩個網路介面卡可提供一個 MAPI 網路和一個複寫網路，以及下列復原行為：
發生影響 MAPI 網路的失敗時，將會發生伺服器容錯移轉 (假設有狀況良好的信箱資料庫副本可以啟動)。
發生影響複寫網路的失敗時，如果 MAPI 網路不受失敗影響，則記錄傳送和植入作業操作將還原為使用 MAPI 網路，即使將 MAPI 網路的 ReplicationEnabled 內容設定為 False 亦然。當失敗的複寫網路還原至正常狀態，並準備好繼續進行記錄傳送和植入作業時，您必須以手動的方式切換至複寫網路。要將複寫作業從 MAPI 網路變更至還原的複寫網路，您可利用 Suspend-MailboxDatabaseCopy 和 Resume-MailboxDatabaseCopy 指令程式來暫停及繼續連續複寫作業，或是重新啟動 Microsoft Exchange 複寫服務。我們建議您使用暫停和繼續等操作，以免因重新啟動 Microsoft Exchange 複寫服務，而出現短暫中斷的情形。
每個 DAG 成員的網路數量必須相同。例如，如果您計畫在一個 DAG 成員中使用單一網路介面卡，則 DAG 的所有成員也必須使用單一網路介面卡。
每個 DAG 都必須只能有一個 MAPI 網路。MAPI 網路必須提供對其他 Exchange 伺服器和其他服務 (例如 Active Directory 和 DNS) 的連線。
您可以視需要加入其他複寫網路。您也可以使用網路介面卡協力作業或類似的技術，以避免個別網路卡成為單一失敗點。不過，即使使用了協力作業，也無法避免網路本身成為單一失敗點。
每個 DAG 成員伺服器中的每個網路都必須在自己網路的子網路上。DAG 中的每個伺服器都可以在不同的子網路上，但 MAPI 和複寫網路必須可進行路由傳送並提供連線能力，使得：
每個 DAG 成員伺服器中的每個網路位於自己網路的子網路上，而與伺服器中各個網路所使用的子網路不同。
每個 DAG 成員伺服器的 MAPI 網路都能夠與其他每個 DAG 成員的 MAPI 網路進行通訊。
每個 DAG 成員伺服器的複寫網路都能夠與其他每個 DAG 成員的複寫網路進行通訊。
沒有任何直接路由可允許從一部 DAG 成員伺服器之複寫網路到另一部 DAG 成員伺服器之 MAPI 網路 (或相反方向) 的活動訊號流量，或是介於 DAG 中多個複寫網路之間的活動訊號流量。
不論與其他 DAG 成員之間相對的地理位置為何，DAG 的每個成員與其他每個成員之間的往返網路延遲不可大於 500 毫秒。隨著裝載資料庫副本的兩部信箱伺服器之間的往返延遲增加，複寫未更新的可能性也會越高。無論解決方案的延遲為何，客戶都應該驗證所有 DAG 成員之間的網路是否能夠滿足部署的資料保護和可用性目標。延遲值較高的組態可能需要特別調整 DAG、複寫和網路參數，例如增加資料庫數目或減少每個資料庫的信箱數目，以便達到所需的目標。
往返延遲需求並不是多重資料中心組態最嚴格的網路頻寬及延遲需求。您必須評估網路總負載 (包括用戶端存取、Active Directory、傳輸、連續複寫和其他應用程式流量) 來判定環境所需的網路需求。
DAG 網路支援網際網路通訊協定第 4 版 (IPv4) 和 IPv6。僅在同時使用 IPv4 時支援 IPv6；不支援純 IPv6 環境。僅在該電腦上同時啟用 IPv6 和 IPv4，且網路支援兩個 IP 位址版本時，才支援使用 IPv6 位址和 IP 位址範圍。如果在此組態中部署 Exchange 2010，則所有伺服器角色都可以對使用 IPv6 位址的裝置、伺服器及用戶端傳送和接收資料。
自動私人 IP 定址 (APIPA) 是 Microsoft Windows 的功能，可在網路上沒有動態主機設定通訊協定 (DHCP) 伺服器可用時自動指派 IP 位址。DAG 或 Exchange 2010 不支援使用 APIPA 位址 (包含從 APIPA 位址範圍手動指派的位址)。
DAG 名稱和 IP 位址需求
建立期間會為每個 DAG 指定一個唯一名稱，並指派一個或多個靜態 IP 位址，或設定為使用 DHCP。不論您使用的是靜態或動態指派的位址，指派給 DAG 的任何 IP 位址都必須位於 MAPI 網路上。
每個 DAG 至少需要一個 MAPI 網路上的 IP 位址。當 MAPI 網路遍佈多個子網路時，DAG 需要額外的 IP 位址。下圖說明一個 DAG，其中 DAG 中所有節點的 MAPI 網路都位於相同的子網路上。
MAPI 網路位於相同子網路上的資料庫可用性群組
在此範例中，每個 DAG 成員中的 MAPI 網路都位於 172.19.18.x 子網路上。因此，DAG 在該子網路上需要單一 IP 位址。
下一個圖說明具備 MAPI 網路且延伸至兩個子網路的 DAG：172.19.18.x 和 172.19.19.x。
MAPI 網路位於多個子網路上的資料庫可用性群組
在此範例中，每個 DAG 成員中的 MAPI 網路都位於個別的子網路上。因此，DAG 需要兩個 IP 位址，MAPI 網路上的每個子網路各需要一個。
每次 DAG 的 MAPI 網路延伸至額外的子網路時，必須爲 DAG 的該子網路設定其他的 IP 地址。為 DAG 設定的每個 IP 位址都會指派給 DAG 的基礎容錯移轉叢集，並由其使用。DAG 的名稱也會當做基礎容錯移轉叢集的名稱使用。
在任何特定時間中，DAG 的叢集將僅使用其中一個指派的 IP 位址。Windows 容錯移轉叢集會在叢集 IP 位址和網路名稱資源上線時，在 DNS 中登錄此 IP 位址。除了使用 IP 位址和網路名稱以外，也會在 Active Directory 中建立叢集名稱物件 (CNO)。系統會以保護 DAG 和內部通訊的用途，在內部使用叢集的名稱、IP 位址和 CNO。系統管理員和使用者不需要處理或連線到 DAG 名稱或 IP 位址。
| 附註： |
|---|
| 雖然系統會在內部使用叢集的 IP 位址和網路名稱，但在可以使用這些資源的 Exchange 2010 中並沒有強制相依性。即使基礎叢集的 IP 位址和網路名稱資源離線，DAG 中的內部通訊仍可使用 DAG 成員的伺服器名稱繼續進行。不過，建議您定期監視這些資源的可用性，以確保它們不會離線超過 30 天。如果基礎叢集離線超過 30 天，則在 Active Directory 中的廢棄項目收集機制可能會讓叢集 CNO 帳戶失效。 |
DAG 的網路介面卡組態
每個網路介面卡都必須根據其預定的用途適當地進行設定。用於 MAPI 網路之網路介面卡的設定方式與用於複寫網路之網路介面卡的設定方式不同。除了正確設定每個網路介面卡以外，您還必須在 Windows 中設定網路連線順序，讓 MAPI 網路在連線順序的最上方。如需如何修改網路連線順序的詳細步驟，請參閱修改通訊協定連結順序。
MAPI 網路介面卡組態
預定用於 MAPI 網路的網路介面卡應以如下表中所述的方式來設定。
| 網路功能 | 設定 |
|---|---|
Microsoft 網路的用戶端 |
已啟用 |
QoS 封包排程器 |
選擇性地啟用 |
Microsoft Networks 檔案與印表機共享 |
Enable |
網際網路通訊協定第 6 版 (TCP/IP v6) |
選擇性地啟用 |
網際網路通訊協定第 4 版 (TCP/IP v4) |
已啟用 |
連結層拓撲搜索對應程式 I/O 驅動程式 |
已啟用 |
連結層拓撲搜索回應程式 |
已啟用 |
MAPI 網路介面卡的 TCP/IP v4 內容設定如下：
DAG 成員之 MAPI 網路的 IP 位址可以手動指派，或設定為使用 DHCP。如果使用 DHCP，則建議為伺服器的 IP 位址使用持續保留。
MAPI 網路通常會使用預設閘道，但是不一定要使用。
至少必須設定一個 DNS 伺服器位址。建議使用多個 DNS 伺服器以提供備援。
應該核取 [在 DNS 中登錄這個連線的位址] 核取方塊。
複寫網路介面卡組態
預定用於複寫網路的網路介面卡應以如下表中所述的方式來設定。
| 網路功能 | 設定 |
|---|---|
Microsoft 網路的用戶端 |
已停用 |
QoS 封包排程器 |
選擇性地啟用 |
Microsoft Networks 檔案與印表機共享 |
已停用 |
網際網路通訊協定第 6 版 (TCP/IP v6) |
選擇性地啟用 |
網際網路通訊協定第 4 版 (TCP/IP v4) |
已啟用 |
連結層拓撲搜索對應程式 I/O 驅動程式 |
已啟用 |
連結層拓撲搜索回應程式 |
已啟用 |
複寫網路介面卡的 TCP/IP v4 內容設定如下：
DAG 成員之複寫網路的 IP 位址可以手動指派，或設定為使用 DHCP。如果使用 DHCP，則建議為伺服器的 IP 位址使用持續保留。
複寫網路通常沒有預設閘道，如果 MAPI 網路有預設閘道，則其他網路都不應有預設閘道。您可以使用能夠在複寫網路間進行路由傳送的閘道位址，在其他 DAG 成員上對應網路的持續、靜態路由，來設定複寫網路上網路流量的路由。不符合此路由的其他所有流量將由 MAPI 網路的介面卡上設定的預設閘道來處理。
不應該設定 DNS 伺服器位址。
不應該核取 [在 DNS 中登錄這個連線的位址] 核取方塊。
一般需求
見證伺服器需求
*「見證伺服器」*是 DAG 之外的伺服器，在 DAG 成員的數量為偶數時，用於達成及維護仲裁。成員數為奇數的 DAG 不使用見證伺服器。成員數為偶數的所有 DAG 都將使用見證伺服器。見證伺服器可以是執行 Windows Server 的任何電腦。見證伺服器的 Windows Server 作業系統版本不需要符合 DAG 成員所使用的作業系統。
仲裁是在叢集層級維護，位於 DAG 之下。當 DAG 的大部分成員都已連線且可與其他線上 DAG 成員進行通訊時，DAG 就具有仲裁。這個仲裁概念是 Windows 容錯移轉叢集中仲裁概念的一環。與容錯移轉叢集中的仲裁相關而且必要的觀點是*「仲裁資源」。仲裁資源是容錯移轉叢集內的資源，可提供叢集狀態和成員資格決策的仲裁方法。仲裁資源也提供用於儲存組態資訊的持續性儲存體。可搭配仲裁資源使用的是「仲裁記錄」*，這是叢集的組態資料庫。仲裁記錄包含的資訊例如哪些伺服器是叢集的成員、叢集中安裝的資源，以及這些資源的狀態 (例如，線上或離線狀態)。
每個 DAG 成員對於如何設定 DAG 基礎叢集擁有一致的觀點非常重要。仲裁是所有與叢集相關之組態資訊的最終存放庫。仲裁也用於突破僵局，以避免發生「核心分裂」的狀況。核心分裂的狀況是當 DAG 成員間無法相互進行通訊，但各自都正常運作時發生的狀況。您可以透過一律要求大部分的 DAG 成員 (如果 DAG 成員的數量為偶數，則為 DAG 見證伺服器) 可以使用，且可與要操作的 DAG 互動，來避免發生核心分裂的狀況。
規劃站台恢復
每天有越來越多的企業認知到存取可靠和可用的郵件系統是其致勝的基礎。對許多組織而言，郵件系統是營運持續計畫的一部分，且在設計郵件服務部署時納入站台恢復。基本上，許多站台恢復解決方案都會採用在另一個資料中心部署硬體的方式。
最終，DAG 的整體設計 (包含 DAG 成員的數量和信箱資料庫副本的數量) 將取决於每個組織涵蓋各種失敗案例的復原服務等級協定 (SLA)。在規劃階段期間，解決方案的建構者和系統管理員會識別部署的需求，特別是包含站台恢復的需求。他們會識別要使用的位置和所需的復原 SLA 目標。SLA 會識別作為提供高可用性和站台恢復之解決方案設計基礎的兩個特定元素：復原時間目標 (RTO) 以及復原點目標 (RPO)。這兩個值會以分鐘為測量單位。RTO 是還原服務所需的時間。復原作業完成之後，RPO 會指出資料目前的狀況。SLA 也可定義為在主要資料中心的問題解決後還原至完整服務。
解決方案的建構者和系統管理員也會識別哪一組使用者需要站台恢復保護，並決定多站台解決方案是主動/被動或主動/主動組態。在主動/被動組態中，待命資料中心通常不主控使用者。在主動/主動組態中，兩個位置都主控使用者，而解決方案中資料庫總數的特定百分比在另一個資料中心具有慣用的主動位置。當一個資料中心的使用者服務失敗時，會在其他資料中心啟動這些使用者。
建構適當的 SLA 時，通常需要回答下列基本問題：
主要資料中心失敗後所需的服務等級為何？
使用者需要其資料，還是只需要郵件服務？
資料需求的急迫性如何？
必須支援多少使用者？
使用者將如何存取其資料？
待命資料中心啟動的服務等級協定 (SLA) 為何？
服務如何移回主要資料中心？
資源是否為站台恢復解決方案所專用？
您可以藉由回答這些問題，著手為您的郵件解決方案擬定站台恢復設計。從站台失敗進行復原的核心需求是建立適當的解決方案，將必要的資料移至主控備份郵件服務的備份資料中心。
命名空間規劃
部署站台恢復組態時，Exchange 2010 會變更您規劃命名空間設計的方式。正確的命名空間規劃對於讓資料中心轉換成功十分重要。從命名空間的角度來看，站台恢復組態中使用的每個資料中心都會被視為作用中。因此，每個資料中心在該站台的各種 Exchange 2010 服務 (包含 Outlook Web App、Outlook 無所不在、Exchange ActiveSync、Exchange Web 服務、RPC 用戶端存取、郵局通訊協定第 3 版 (POP3)、網際網路郵件存取通訊協定第 4 版 (IMAP4) 和簡易郵件傳輸通訊協定 (SMTP)) 都需要自己的唯一命名空間。此外，其中一個資料中心也會主控自動探索的命名空間。這個設計也可讓您將單一資料庫從主要資料中心轉換至另一個資料中心，以驗證第二個資料中心的組態，作為資料中心轉換驗證和作法的一部分。
建議的最佳作法是，使用 *「分割 DNS」*作為用戶端使用的 Exchange 主機名稱。切割 DNS 是指 DNS 伺服器設定中，內部 DNS 伺服器傳回主機名稱的內部 IP 位址，而外部 (面對網際網路的) DNS 伺服器則傳回相同主機名稱的公用 IP 位址。由於使用切割 DNS 會在內部和外部使用相同的主機名稱，這項策略讓您能將需要的主機名稱數減到最少。
下圖說明站台恢復組態的命名空間規劃。
站台恢復 DAG 部署的命名空間
如上圖所示，在這些命名空間的分割 DNS 組態中，每個資料中心都會使用個別和唯一命名空間，且分別也包含 DNS 伺服器。被視為主要資料中心的 Redmond 資料中心是以 protocol.contoso.com 的命名空間設定。Portland 資料中心則是以 protocol.standby.contoso.com 的命名空間設定。命名空間可以包含待命的指定 (如範例圖表中所示)，它們可以以地區 (例如，protocol.portland.contoso.com) 為基礎，或者以符合組織需求的其他命名慣例為基礎。主要需求為，不論您使用的命名慣例為何，每個資料中心都應該有其自己的唯一命名空間。
FailbackURL 組態
部分 Web 瀏覽器 (包括 Microsoft Internet Explorer) 會在每個瀏覽器工作階段保留 DNS 名稱快取，此快取有別於作業系統所提供的 DNS 快取。在資料中心發生轉換之後回復至主要資料中心的過程中，Web 瀏覽器使用此個別快取可能會導致 Outlook Web App 使用者陷入登入迴圈中，使用者會在不斷重複的迴圈中重新導向至相同的 URL。
在回復過程中，DNS 中 Outlook Web App 命名空間的 IP 位址會從待命資料中心的端點，變更回主要資料中心內的原始端點。在 DNS 記錄的 TTL 過期且甚至在作業系統的 DNS 快取清除之後，即使命名空間裝載於主要資料中心內，另行保留名稱快取的 Web 瀏覽器可能仍會繼續連線至待命資料中心的端點。
通常，關閉 Web 瀏覽器就能清除另外這個名稱快取，並且避免發生登入迴圈。不過，若要為所有 Web 瀏覽器和 Outlook Web App 使用者解決此問題，您可以設定 Outlook Web App 虛擬目錄的 FailbackURL 內容。FailbackUrl 參數會指定 Outlook Web App 在回復至主要站台之後用來連線至 Client Access Server 的主機名稱。這個命名空間需要另一個指向原始 Client Access Server 之 IP 位址的 DNS 項目。FailbackUrl 參數值必須與 Outlook Web App 虛擬目錄的 ExternalUrl 參數值不同。當 Outlook Web App 使用者提供其認證時，Client Access Server 將偵測重新導向 URL 是否與使用者造訪的 URL 相同。如果 URL 相同，Client Access Server 將查看是否已設定 FailbackUrl 參數：
如果已設定 FailbackUrl 參數，則會將使用者重新導向至能夠存取 Outlook Web App 的 URL。
如果未設定 FailbackUrl 參數，使用者將收到錯誤訊息，指出伺服器組態變更暫時阻止存取其信箱。訊息會指示使用者關閉所有瀏覽器視窗 (藉此清除瀏覽器的名稱快取) 並於幾分鐘後再試一次。
憑證規劃
在單一資料中心部署 DAG 時，並沒有針對憑證的唯一或特殊設計考量。不過，如果站台恢復組態中的 DAG 遍佈多個資料中心時，有一些與憑證相關的特定考量。您的憑證設計一般取決於使用中的用戶端，以及其他使用憑證之應用程式的憑證需求。但是，您應該遵守一些關於憑證類型和數目的特定建議和最佳作法。
最佳作法是，將用戶端存取伺服器、反向 Proxy 伺服器以及 Transport Server (Edge 和 Hub) 所使用的憑證數目減到最少。建議您針對每個資料中心的這些所有服務使用單一憑證。這個方法可以將所需的憑證數目減到最少，同時降低解決方案的成本和和複雜性。
針對 Outlook 無所不在用戶端，建議您在每個資料中心使用單一主體別名 (SAN) 憑證，並在憑證中加入多個主機名稱。若要在資料庫、伺服器或資料中心轉換後確保 Outlook 無所不在的連線能力，您必須在每個憑證上使用相同的憑證主體名稱，並在 Microsoft 標準表單 (msstd) 中使用相同的主體名稱來設定 Outlook Provider Configuration 物件 Active Directory。例如，如果您使用憑證主體名稱 mail.contoso.com，則設定屬性的方式如下：
Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"
與 Exchange 整合的某些應用程式可能有需要使用其他憑證的特定憑證需求。Exchange 2010 可以與 Office Communications Server (OCS) 共存。OCS 需要 1024 位元或更大的憑證，這些憑證會使用 OCS 伺服器名稱作為憑證主體名稱。使用 OCS 伺服器名稱作為憑證主體名稱會使 Outlook 無所不在無法正確運作，因此您需要在 OCS 環境使用額外和不同的憑證。
如需有關在 Exchange 2010 用戶端存取使用 SAN 憑證的詳細資訊，請參閱設定 SSL 憑證以使用多個 Client Access Server 主機名稱。
網路規劃
除了每個 DAG 以及屬於 DAG 成員的每個伺服器必須符合的特定網路需求外，針對站台恢復組態還有一些特定的需求和建議。與所有 DAG 一樣，不論是在單一站台或多個站台中部署 DAG 成員，在 DAG 成員和 DAG 之間往返傳回網路延遲時間都不得大於 500 毫秒。此外，針對遍佈多個站台的 DAG 還有建議的特定組態設定：
MAPI 網路應與複寫網路隔離 您應該使用 Windows 網路原則、Windows 防火牆原則或路由存取控制清單 (ACL) 來封鎖 MAPI 網路和複寫網路之間的流量。這種組態對於避免發生網路活動訊號干擾是必要的。
用戶端使用的 DNS 記錄存留時間 (TTL) 必須設定為 5 分鐘 用戶端經歷的停機時間不僅取決於轉換進行的速度，還有 DNS 複寫發生的速度以及用戶端查詢更新 DNS 的速度。所有 Exchange 用戶端服務的 DNS 記錄 (包括 Outlook Web App、Exchange ActiveSync、Exchange Web 服務、Outlook 無所不在、SMTP、POP3、IMAP4 以及內部和外部 DNS 伺服器的 RPC 用戶端存取)，其 TTL 都應設定為 5 分鐘。
使用靜態路由設定複寫網路間的連線 若要在每個複寫網路介面卡之間提供網路連線，請使用持續性靜態路由。如果使用的是靜態 IP 位址，這是在每個 DAG 成員上執行的快速和單次組態。如果使用 DHCP 取得複寫網路的 IP 位址，您還可以使用它來為複寫指派靜態路由，進而簡化組態處理程序。
一般站台恢復規劃
除了以上所列針對高可用性的需求之外，此處有一些用於在站台恢復組態中部署 Exchange 2010 的建議 (例如，將 DAG 延伸至多個資料中心)。您在規劃階段中所做的規劃，會對站台恢復解決方案的成功與否造成直接的影響。例如，命名空間設計不良會造成憑證發生問題，而不正確的憑證組態可能會讓使用者無法存取服務。
若要讓啟動另一個資料中心的時間縮到最短，並讓第二個資料中心主控失敗資料中心的服務端點，必須完成適當的規劃。例如：
您必須充分了解並記錄站台恢復解決方案的服務等級協定 (SLA) 目標。
第二個資料中心的伺服器必須有足夠的容量，才可以主控結合兩個資料中心的所有使用者。
第二個資料中心必須啟用主要資料中心提供的所有服務 (除非該服務並未包含在站台恢復 SLA 中)。這包含 Active Directory、網路基礎結構 (DNS、TCP/IP 等等)、電話語音服務 (如果使用整合通訊) 以及站台基礎結構 (電力、冷卻等等)。
若要讓某些服務能夠為失敗資料中心的使用者提供服務，必須為這些服務設定正確的伺服器憑證。某些服務不允許執行個體 (例如 POP3 和 IMAP4) 而僅允許使用單一憑證。在這些情況下，憑證必須是包含多個名稱的主體別名 (SAN) 憑證，或者多個名稱必須足夠相似，可當做萬用字元憑證使用 (假設組織的安全性原則允許使用萬用字元憑證)。
您必須在第二個資料中心定義所需的服務。例如，如果在第一個資料中心的不同傳輸伺服器上有三個不同的 SMTP URL，則必須在第二個資料中心定義適當的組態，以便至少啟用一個 (如果不啟用全部三個) 傳輸伺服器來主控工作負載。
所需的網路組態必須就緒，才能支援資料中心轉換。這可能表示確定已完成負載平衡組態、已設定全域 DNS、已啟用網際網路連線，以及已設定適當的路由。
您必須了解啟用資料中心轉換所需之 DNS 變更的策略。您必須定義並記錄特定的 DNS 變更 (包括其存留時間 (TTL) 設定) 以有效支援 SLA。
您也必須建立用於測試解決方案的策略，並作為因素納入 SLA 中。定期驗證部署是確保部署的品質和可行性不會隨時間而降低的唯一方式。驗證部署之後，建議您明確記錄組態的哪些部分會直接影響解決方案成功與否。此外，建議您增強這些部署區段週邊的變更管理程序。
一般需求
規劃資料中心轉換
正確的規劃與準備不僅只牽涉到部署第二個資料中心的資源 (例如，即時用戶端存取和 Hub Transport Server)，也包含預先設定這些資源，以便將資料中心轉換作業所需的變更減到最少。
| 附註： |
|---|
| 即使無法自動啟動第二個資料中心的信箱資料庫，第二個資料中心仍需要用戶端存取和集線傳輸服務。系統需要這些服務才可以執行資料庫轉換，以及在第二個資料中心執行服務和資料的測試與驗證。 |
若要進一步了解資料中心轉換程序的運作方式，了解 Exchange 2010 資料中心轉換的基本操作會很有幫助。
如下圖所述，站台恢復部署由在兩個資料中心都具有成員的 DAG 組成。
具有兩個資料中心成員的資料庫可用性群組
當 DAG 遍佈多個資料中心時，應該將其設計為讓大多數 DAG 成員位於主要資料中心，或是當每個資料中心成員數相同時，由主要資料中心主控見證伺服器。這種設計可確保即使兩個資料中心之間的網路連線失敗，服務仍由主要資料中心提供。這也表示主要資料中心失敗時，將會失去第二個資料中心中成員的仲裁。
也可能且會發生部分資料中心失敗。前提是，如果主要資料中心失去的功能足以造成無法有效服務和管理，則會執行資料中心轉換以啟用第二個資料中心。啟動程序會將系統管理員所設定之剩餘伺服器部分作業狀態的服務停止。然後繼續啟動第二個資料中心。這樣做可避免同時嘗試與操作兩組服務。
由於失去仲裁，第二個資料中心的 DAG 成員無法自動連線。因此，啟動第二個資料中心的信箱伺服器還需要一個強制 DAG 成員伺服器建立仲裁的步驟，此時會從 DAG 內部移除失敗資料中心的伺服器 (僅暫時)。這可提供一個穩定的部分服務解決方案，可能會發生某些層級的其他失敗，但仍可繼續運作。
| 附註： |
|---|
| 會發生其他失敗的一個必要條件是 DAG 至少有四個成員，而四個成員分散在兩個 Active Directory 站台之間 (例如，每個資料中心至少有兩個成員)。 |
這是用於在第二個資料中心重新建立信箱角色功能的基本程序。啟動第二個資料中心的其他角色不會牽涉第二個資料中心中受影響伺服器上的明確動作。但是，第二個資料中心的伺服器會成為通常由主要資料中心主控之服務的服務端點。例如，通常由主要資料中心主控的使用者會使用 https://mail.contoso.com/owa 連線到 Outlook Web App。在資料中心失敗之後，這些服務端點會在轉換作業期間，移至第二個資料中心的端點。在轉換作業期間，主要資料中心的服務端點會重新以第二個資料中心中相同服務的替代 IP 位址作為目標。這樣可以讓轉換程序期間 Active Directory 中儲存的組態資訊必須變更的量降到最低。一般而言，有兩種方法可以完成這個步驟：
更新 DNS 記錄；或
重新設定 DNS 和負載平衡器以啟用與停用替代 IP 位址，以便在資料中心之間移動服務。
必須先建立測試解決方案的策略。它必須作為因素納入 SLA 中。定期驗證部署是確保部署不會隨時間而降低的唯一方式。
仔細地完成這些規劃步驟會直接影響資料中心轉換的成功。例如，命名空間設計不良會造成憑證發生問題，而不正確的憑證組態會造成使用者無法存取服務。
驗證部署之後，建議您明確記錄會直接影響資料中心轉換成功與否的所有組態。此外，也應審慎地增強這些部署區段週邊的變更管理程序。
如需有關資料中心轉換的詳細資訊，包括啟動次要資料中心和重新啟動失敗的 (主要) 資料中心，請參閱資料中心轉換。
一般需求
© 2010 Microsoft Corporation. 著作權所有，並保留一切權利。