Microsoft ExchangeServer2010 包括一個新的用于郵箱恢復的統一框架，該框架包括一些新功能，如數據庫可用性組 (DAG) 和郵箱數據庫副本。盡管可以快速簡單地部署這些新功能，但是必須先進行認真規劃，以確保使用這些功能的任何高可用性和站點恢復解決方案可以達到預期目的和滿足業務要求。

在規劃階段中，系統結構設計師、管理員和其他主要利益相關方應確定部署的要求；尤其是高可用性和站點恢復的要求。部署這些功能必須滿足一些常規要求，還必須滿足硬件、軟件和網絡連接要求。有關 DAG 存儲要求的指南，請參閱Mailbox Server Storage Design。

[[18006]] 常規要求

在部署 DAG 和創建郵箱數據庫副本之前，請確保符合以下系統范圍建議：

• 域名系統 (DNS) 必須在運行。理論上，DNS 服務器應該接受動態更新。如果 DNS 服務器不接受動態更新，則必須為每個 Exchange 服務器創建 DNS 主機 (A) 記錄。否則，Exchange 不能正常運行。
• DAG 中的每個郵箱服務器必須是相同域中的成員服務器。
• 不支持將同時作為目錄服務器的 Exchange2010 郵箱服務器添加到 DAG。
• 分配給 DAG 的名稱必須是不超過 15 個字符的有效、可用和唯一的計算機名稱。

[[18006]] 硬件要求

通常，沒有特定于 DAG 或郵箱數據庫副本的特殊硬件要求。使用的服務器必須符合 Exchange 2010 先決條件和 Exchange 2010 系統要求主題中規定的所有要求。有關硬件規劃信息，請參閱下列主題：

• 了解處理器配置和 Exchange 性能
• 了解內存配置和 Exchange 性能
• Mailbox Server Storage Design
• 了解服務器角色比率和 Exchange 性能

[[18006]] 軟件要求

Exchange2010 Standard Edition 和 Exchange2010 Enterprise Edition 中都提供 DAG。此外，DAG 可以包含運行 Exchange2010 Standard Edition 和 Exchange2010 Enterprise Edition 的混合服務器。

DAG 的每個成員還必須運行相同的操作系統。WindowsServer2008 和 WindowsServer2008 R2 操作系統都支持 Exchange2010。DAG 的所有成員都必須運行 WindowsServer2008 或 WindowsServer2008 R2。它們不能包含 WindowsServer2008 和 WindowsServer2008 R2 的組合。

除符合安裝 Exchange2010 的先決條件外，還必須符合操作系統要求。DAG 使用 Windows 故障轉移群集技術，因此，它們需要 Windows Enterprise 版本。

[[18006]] 網絡要求

每個 DAG 和每個 DAG 成員都必須符合特定的網絡要求。DAG 網絡與在 Exchange 的以前版本中使用的公用、混合和專用網絡類似。但是，與以前版本不同，在每個 DAG 成員中使用單一網絡是一種受支持的配置。此外，該術語已有所更改。每個 DAG 都不再使用公用、專用或混合網絡，而是一個“MAPI 網絡”（其他服務器，例如其他 Exchange2010 服務器、目錄服務器等使用該網絡與 DAG 成員通信）和零個或多個“復制網絡”（這些網絡專用于日志傳送和種子設定）。

盡管支持一個網絡，但我們建議每個 DAG 至少應有兩個網絡：一個 MAPI 網絡和一個復制網絡。這可以提供網絡和網絡路徑的冗余，使系統能夠區分服務器故障和網絡故障。使用單個網絡適配器會阻礙系統區分這兩種類型的故障。

注意：
此內容區中的產品文檔在編寫時假定每個 DAG 成員至少包含兩個網絡適配器，每個 DAG 配置一個 MAPI 網絡和至少一個復制網絡，并且系統能夠區分網絡故障和服務器故障。

為 DAG 設計網絡基礎結構時，請考慮下列事項：

• DAG 的每個成員必須具有至少一個能夠與所有其他 DAG 成員通信的網絡適配器。如果使用的是單一網絡路徑，我們建議使用千兆比特的以太網。在每個 DAG 成員中使用單一網絡適配器時，需要為復制啟用 DAG 網絡，并且應將其配置為 MAPI 網絡。因為沒有其他網絡，所以系統還使用 MAPI 網絡作為復制網絡。此外，在每個 DAG 成員中使用單一網絡適配器時，我們建議在設計總體解決方案時考慮單一網絡適配器和路徑。
• 在每個 DAG 成員中使用兩個網絡適配器可提供一個 MAPI 網絡和一個復制網絡，以及以下恢復行為：
  • 如果故障影響 MAPI 網絡，將發生服務器故障轉移（假定可以激活健康的郵箱數據庫副本）。
  • 在故障影響復制網絡時，如果 MAPI 網絡未受故障的影響，則日志傳送和種子設定操作將恢復為使用 MAPI 網絡。還原發生故障的復制網絡時，日志傳送和種子設定操作將恢復到復制網絡。
• 每個 DAG 成員都必須具有相同數量的網絡。例如，如果計劃在一個 DAG 成員中使用單一網絡適配器，則 DAG 的所有成員也必須使用單一網絡適配器。
• 每個 DAG 不得有多個 MAPI 網絡。MAPI 網絡必須提供與其他 Exchange 服務器和其他服務（如 ActiveDirectory 和 DNS）的連接。
• 可以根據需要添加其他復制網絡。通過使用網絡適配器成組或類似的技術還可以防止個別網絡適配器發生單點故障。但是，即使使用成組，也不能阻止網絡本身發生單點故障。
• 每個 DAG 成員服務器中的每個網絡必須在自己的網絡子網上。DAG 中的每個服務器可以在不同的子網上，但 MAPI 和復制網絡必須可以路由并提供連接，以便于：
  • 每個 DAG 成員服務器中的每個網絡位于自己的網絡子網上，并且該子網與服務器中每個其他網絡使用的子網分離。
  • 每個 DAG 成員服務器的 MAPI 網絡可以與每個其他 DAG 成員的 MAPI 網絡通信。
  • 每個 DAG 成員服務器的復制網絡可以與每個其他 DAG 成員的復制網絡通信。
  • 沒有直接路由將檢測信號通信從一個 DAG 成員服務器上的復制網絡傳遞到另一個 DAG 成員服務器上的 MAPI 網絡（反之亦然），在 DAG 中的多個復制網絡之間也沒有直接路由。
• 無論 DAG 的每個成員相對于其他 DAG 成員的地理位置如何，每個成員相互之間的往返網絡延遲均不得大于 250 毫秒 (ms)。
• 對于多數據中心配置，往返延遲要求可能不是最嚴格的網絡帶寬和延遲要求。必須評估網絡總負載（其中包括客戶端訪問、ActiveDirectory、傳輸、連續復制和其他應用程序通信）以確定您的環境所需的網絡要求。
• DAG 網絡支持 Internet 協議版本 4 (IPv4) 和 IPv6。僅當同時使用 IPv4 時才支持 IPv6；不支持純 IPv6 環境。僅當在計算機上同時啟用 IPv6 和 IPv4，并且網絡支持這兩種 IP 地址版本時，才支持使用 IPv6 地址和 IP 地址范圍。如果在此配置中部署 Exchange2010，則所有服務器角色均可在使用 IPv6 地址的設備、服務器和客戶端中發送和接收數據。
• 自動專用 IP 尋址 (APIPA) 是 Microsoft Windows 的一種功能，當網絡上沒有任何動態主機配置協議 (DHCP) 服務器可用時，它將自動分配 IP 地址。APIPA 地址（包括從 APIPA 地址范圍手動分配的地址）不支持由 DAG 或 Exchange2010 使用。

[[18006]] 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 地址之一。當群集 IP 地址和網絡名稱資源進入聯機狀態時，Windows 故障轉移群集會在 DNS 中注冊此 IP 地址。除了使用 IP 地址和網絡名稱外，在 ActiveDirectory 中還將創建群集網絡對象 (CNO)。系統還將在內部使用群集的名稱、IP 地址和 CNO 來保護 DAG 進行內部通信。管理員和最終用戶不需要對接或連接 DAG 名稱或 IP 地址。

注意：
盡管群集的 IP 地址和網絡名稱由系統內部使用，但在提供這些資源的 Exchange2010 中沒有硬性依賴關系。即使基礎群集的 IP 地址和網絡名稱資源處于脫機狀態，通過使用 DAG 成員的服務器名稱，在 DAG 中仍會發生內部通信。但是，我們建議定期監視這些資源的可用性，以確保它們的脫機時間不超過 30 天。如果基礎群集的脫機時間超過 30 天，則 ActiveDirectory 中的垃圾收集機制可能使群集 CNO 帳戶無效。

[[18006]] DAG 的網絡適配器配置

必須根據預期的用途正確配置每個網絡適配器。用于 MAPI 網絡的網絡適配器的配置與用于復制網絡的網絡適配器的不同。除正確配置每個網絡適配器外，還必須在 Windows 中配置網絡連接順序，以便 MAPI 網絡位于連接順序的頂部。有關如何修改網絡連接順序的詳細步驟，請參閱修改協議綁定順序

[[18006]] MAPI 網絡適配器配

應按照下表中的描述配置供 MAPI 網絡使用的網絡適配器。

MAPI 網絡適配器的 TCP/IP v4 屬性配置如下：

• 可以手動分配 IP 地址，或將其配置為使用 DHCP。如果使用 DHCP，我們建議對服務器的 IP 地址使用持久保留。
• MAPI 網絡通常使用默認網關，盡管不需要網關。
• 必須配置至少一個 DNS 服務器地址。為實現冗余，建議使用多個 DNS 服務器。
• 應選中“在 DNS 中注冊此連接地址”復選框。

[[18006]] 復制網絡適配器配置

應按照下表中的描述配置供復制網絡使用的網絡適配器。

復制網絡適配器的 TCP/IP v4 屬性配置如下：

• 可以手動分配 IP 地址，或將其配置為使用 DHCP。如果使用 DHCP，我們建議對服務器的 IP 地址使用持久保留。
• 復制網絡通常沒有默認網關，如果 MAPI 網絡有默認網關，則其他網絡不應有默認網關。可以使用持久的靜態路由配置復制網絡上的網絡通信路由，將網絡通信路由到使用網關地址的其他 DAG 成員上的相應網絡，該網關地址具有在復制網絡之間路由的能力。與此路由不匹配的所有其他通信都將由在 MAPI 網絡的適配器上配置的默認網關處理。
• 不應配置 DNS 服務器地址。
• 不應選中“在 DNS 中注冊此連接地址”復選框。

[[18006]] 見證服務器要求

“見證服務器”是 DAG 外部的服務器，當 DAG 的成員數為偶數時，使用該服務器可實現和維護仲裁。DAG 的成員數為奇數時，則不使用見證服務器。成員為偶數的所有 DAG 都將使用見證服務器。見證服務器可以是運行 WindowsServer 的任何計算機。不要求見證服務器的 WindowsServer 操作系統版本與 DAG 成員使用的操作系統匹配。

仲裁在 DAG 下的群集級別維護。當 DAG 的大多數成員處于聯機狀態，并且可以與 DAG 的其他聯機成員通信時，DAG 才進行仲裁。此仲裁概念是 Windows 故障轉移群集中仲裁概念的一個方面。在故障轉移群集中與仲裁相關的必需方面是“仲裁資源”。仲裁資源是故障轉移群集內部的資源，它可為導致群集狀態和成員身份決策提供一種仲裁方法。仲裁資源還為存儲配置信息提供了***存儲區。仲裁資源的配套組件是“仲裁日志”，它是群集的配置數據庫。仲裁日志包含以下信息：哪些服務器是群集的成員，群集中安裝了哪些資源，以及這些資源的狀態（例如，聯機或脫機）。

每個 DAG 成員對如何配置 DAG 的基礎群集應具有一致的視圖，這一點至關重要。仲裁充當了與群集相關的所有配置信息的權威性存儲庫。仲裁還用作關系斷開裁判，以避免“網絡分區”癥狀。網絡分區癥狀是在 DAG 成員無法相互通信（但能夠正常運行）時發生的一種情況。始終要求大多數 DAG 成員（在 DAG 成員為偶數時使用 DAG 見證服務器）可用并處于交互狀態，使 DAG 能夠正常工作，這樣即可防止網絡分區癥狀。

[[18006]] 規劃站點恢復

越來越多的業務人員認識到，每天訪問可靠而又可用的郵件系統是其成功的基礎。對于許多組織而言，郵件系統是業務連續性計劃的一部分，并且在設計郵件服務部署時應考慮站點恢復。基本上，許多站點恢復解決方案都涉及在第二個數據中心中部署硬件。

最終，DAG 的總體設計（其中包括 DAG 的成員數和郵箱數據庫副本數）將取決于每個組織的包括各種故障情形的恢復服務級別協議 (SLA)。在規劃階段中，解決方案的結構設計師和管理員將確定部署要求，尤其是站點恢復要求。他們確定要使用的位置和所需的恢復 SLA 目標。SLA 將確定兩個特定的元素，這兩個元素應是設計高可用性和站點恢復解決方案的基礎：恢復時間目標 (RTO) 和恢復點目標 (RPO)。這兩個值都以分鐘為單位度量。RTO 是還原服務所需的時間。RPO 指在完成恢復操作之后數據的新舊程度。還可以將 SLA 定義為在解決主數據中心的問題之后，將還原為完整服務。

解決方案的結構設計師和管理員還將確定哪一組用戶需要站點恢復保護，并確定多站點解決方案是活動/被動配置還是活動/活動配置。在活動/被動配置中，備用數據中心中通常不駐留任何用戶。在活動/活動配置中，用戶同時駐留在兩個位置，在該解決方案中，數據庫總數中有一定的百分比在第二個數據中心的***活動位置。當一個數據中心的用戶的服務出現故障時，將在另一數據中心中激活這些用戶。

構造適當的 SLA 通常需要考慮以下基本問題：

• 主數據中心出現故障后，需要什么級別的服務？
• 用戶是需要數據服務還是僅需要郵件服務？
• 急需數據的程度怎樣？
• 必須支持多少用戶？
• 用戶如何訪問自已的數據？
• 備用數據中心激活服務級別協議 (SLA) 是什么？
• 服務如何移回主數據中心？
• 資源是否專用于站點恢復解決方案？

通過回答這些問題，您實際上已經開始為郵件解決方案構建站點恢復設計的大致框架。從站點故障進行恢復的核心要求是：創建解決方案，將必要的郵件數據放入承載備用郵件服務的備用數據中心。

[[18006]] 命名空間規劃

部署站點恢復配置時，Exchange2010 將更改計劃命名空間設計的方式。正確的命名空間計劃是數據中心成功切換的關鍵。從命名空間角度看，在站點恢復配置中使用的每個數據中心都被視為活動數據中心。因此，每個數據中心對于該站點中的各種 Exchange2010 服務都需要自己的唯一命名空間，其中包括 OutlookWebApp、Outlook Anywhere、ExchangeActiveSync、Exchange Web 服務、RPC 客戶端訪問、郵局協議版本 3 (POP3)、Internet 郵件訪問協議版本 4 (IMAP4) 和簡單郵件傳輸協議 (SMTP) 的命名空間。此外，其中一個數據中心還承載 Autodiscover 的命名空間。此設計還使您能夠執行從主數據中心到第二個數據中心的單一數據庫切換，以便作為數據中心切換的驗證和實踐的一部分來驗證第二個數據中心的配置。

作為***實踐，我們建議使用“拆分 DNS”作為客戶端使用的 Exchange 主機名。拆分 DNS 是指一種 DNS 服務器配置，其中內部 DNS 服務器返回主機名的內部 IP 地址，外部（面向 Internet）DNS 服務器返回同一主機名的公用 IP 地址。因為通過拆分 DNS 可以在內部和外部使用相同的主機名，所以此策略可使所需的主機名數目達到最少。

下圖說明了站點恢復配置的命名空間規劃。

站點恢復 DAG 部署的命名空間

如上所示，每個數據中心都使用單獨的唯一命名空間，并且每個命名空間在這些命名空間的拆分 DNS 配置中都包含 DNS 服務器。雷蒙德數據中心（視為主數據中心）配置了一個命名空間 protocol.contoso.com。波特蘭數據中心配置了一個命名空間 protocol.standby.contoso.com。命名空間可以包括備用標志，如示例圖中所示，它們可以基于地區命名（例如 protocol.portland.contoso.com），也可以基于適合組織需要的其他命名約定來命名。不論使用哪種命名約定，關鍵一點是每個數據中心都需要有自己的唯一命名空間。

[[18006]] 證書規劃

在單一數據中心部署 DAG 時，證書不存在唯一或特殊的設計注意事項。但是，在站點恢復配置中跨多個數據中心擴展 DAG 時，對于證書有一些具體注意事項。通常，證書設計依賴于正在使用的客戶端，以及使用證書的其他應用程序的證書要求。但是，對于要使用的證書類型和證書數，應當遵循一些特定的建議和***實踐。

作為***實踐，應當將用于客戶端訪問服務器、反向代理服務器和傳輸服務器（邊距和集線器）的證書數減少到***限度。我們建議在每個數據中心中為所有這些服務端點使用單一證書。此方法將可使所需的證書數達到最少，從而減少解決方案的成本和復雜性。

對于 Outlook Anywhere 客戶端，我們建議對每個數據中心使用單一主題備用名稱 (SAN) 證書，并在該證書中包括多個主機名稱。為確保在數據庫、服務器或數據中心切換之后 Outlook Anywhere 的連接性，必須在每個證書上使用相同的證書主體名稱，并使用 Microsoft 標準格式 (msstd) 為 Outlook 提供程序配置對象 ActiveDirectory 配置相同的主體名稱。例如，如果使用證書主體名稱 mail.contoso.com，則可以按如下方式配置屬性：

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

與 Exchange 集成的某些應用程序具有特定的證書要求，這些應用程序可能需要使用其他證書。Exchange2010 可以與 Office Communications Server (OCS) 共存。OCS 需要 1024 位或更高版本的證書，這些證書使用 OCS 服務器名稱作為證書主體名稱。因為將 OCS 服務器名稱用作證書主體名稱會阻止 Outlook Anywhere 正常工作，所以需要在 OCS 環境中使用其他單獨證書。

有關使用 SAN 證書進行 Exchange2010客戶端訪問的詳細信息，請參見配置 SSL 證書使用多個客戶端訪問服務器主機名稱。

[[18006]] 網絡規劃

除了必須滿足每個 DAG 和屬于 DAG 成員的每個服務器的特定網絡要求外，還有一些特定于站點恢復配置的要求和建議。與所有 DAG 一樣，無論 DAG 成員部署在單個站點還是多個站點，DAG 成員之間的往返返回網絡延遲均不得大于 250 毫秒 (ms)。此外，對于跨多個站點擴展的 DAG 還有一些特定的配置設置建議：

• MAPI 網絡應獨立于復制網絡 Windows 網絡策略、Windows 防火墻策略或路由器訪問控制列表 (ACL) 應當用于阻止 MAPI 網絡與復制網絡之間的通信。此配置是防止網絡檢測信號交叉對話所必需的。
• 面向客戶端的 DNS 記錄應有 5 分鐘的生存時間 (TTL) 客戶端體驗的停機時間長短不僅依賴于切換的速度，還依賴于 DNS 復制的速度，以及客戶端查詢 DNS 更新信息的速度。應將所有 Exchange 客戶端服務（包括內部和外部 DNS 服務器中的 OutlookWebApp、ExchangeActiveSync、Exchange Web 服務、Outlook Anywhere、SMTP、POP3、IMAP4 和 RPC 客戶端訪問）的 DNS 記錄的生存時間設置為 5 分鐘。
• 使用靜態路由配置跨復制網絡的連接 若要在每個復制網絡適配器之間提供網絡連接，請使用持久靜態路由。使用靜態 IP 地址時，這是對每個 DAG 成員執行的一次性快速配置。如果在使用 DHCP 為復制網絡獲取 IP 地址，則還可以使用它為復制分配靜態路由，從而簡化配置過程。

[[18006]] 常規網站恢復規劃

除上面列出的針對高可用性的要求外，在站點恢復配置中部署 Exchange2010（例如，跨多個數據中心擴展 DAG）還有一些其他建議。在計劃階段中，哪些問題會直接影響站點恢復解決方案的成功。例如，糟糕的命名空間設計可以導致證書出現問題，不正確的證書配置可能阻止用戶訪問服務。

為了盡可能縮短激活第二個數據中心所需的時間，并允許第二個數據中心承載故障數據中心的服務端點，必須完成適當的規劃。例如：

• 必須充分理解和記錄站點恢復解決方案的服務級別協議 (SLA) 目標。
• 第二個數據中心中的服務器必須具有足夠的容量，以便承載兩個數據中心的組合用戶群。
• 第二個數據中心必須啟用在主數據中心中提供的所有服務（除非這些服務未作為站點恢復 SLA 的一部分包括在內）。這包括 ActiveDirectory、網絡基礎結構（DNS 和 TCP/IP 等）、電話服務（如果使用的是統一消息）和站點基礎結構（電源、散熱等）。
• 為使某些服務能夠服務于發生故障的數據中心中的用戶，必須為這些服務必須配置了正確的服務器證書。有些服務不允許實例化（例如，POP3 和 IMAP4），只允許使用單一證書。在這些情況下，證書要么必須是一個包括多個名稱的主題備用名稱 (SAN) 證書，要么必須是非常相似的多個名稱，以便能夠使用通配符證書（假定組織的安全策略允許使用通配符證書）。
• 在第二個數據中心中必須定義必要的服務。例如，如果***個數據中心在不同的傳輸服務器上有三個不同的 SMTP URL，那么必須在第二個數據中心中定義合適的配置，使至少一個（如果不是全部三個）傳輸服務器承載工作負荷。
• 要支持數據中心切換，必須已配置了必要的網絡。這可能意味著，確保配置了負載平衡，配置了全局 DNS，并且啟用了配置適當路由的 Internet 連接。
• 必須了解支持數據中心切換所需的 DNS 更改策略。必須定義和記錄特定的 DNS 更改（包括其生存時間 (TTL) 設置），才能支持有效的 SLA。
• 還必須建立測試解決方案的策略，并將其包括在 SLA 中。定期驗證部署是保證部署的質量和實用性不隨時間的推移而降級的唯一方式。在驗證部署之后，我們建議明確記錄直接影響解決方案成功的配置部分。此外，還建議圍繞這些部署部分加強更改管理過程。

[[18006]] 對數據中心切換的規劃

正確規劃和準備不僅涉及第二個數據中心資源的部署（如活動客戶端訪問和集線器傳輸服務器），而且涉及作為數據中心切換操作的一部分預配置這些資源，從而使所需的更改達到***限度。

注意：
第二個數據中心需要客戶端訪問和集線器傳輸服務，即使阻止第二個數據中心中的郵箱數據庫自動激活也如此。這些服務是執行數據庫切換以及在第二個數據中心測試和驗證服務和數據所必需的。

為更好地了解數據中心切換過程的工作方式，了解 Exchange2010 數據中心切換的基本操作非常有用。

如下圖所示，站點恢復部署包括一個在兩個數據中心中都有成員的 DAG。

成員位于兩個數據中心中的數據庫可用性組

跨多個數據中心擴展 DAG 時，應對其進行相應設計，使大多數 DAG 成員都在主數據中心，或者，在每個數據中心都具有相同數量的成員時，使主數據中心承載見證服務器。此設計可保證在主數據中心提供服務，即使兩個數據中心之間的網絡連接發生故障時也如此。不過，這還意味著主數據中心發生故障時，將失去對第二個數據中心中的成員的仲裁。

還可能會發生部分數據中心故障。如果主數據中心因失去足夠的功能而阻礙有效的服務和管理，則應執行數據中心切換來激活第二個數據中心。激活過程涉及管理員將部分操作狀態的幸存服務器配置為停止服務。然后可以在第二個數據中心繼續激活。這樣可以防止同時嘗試和操作兩組服務。

由于仲裁丟失，第二個數據中心中的 DAG 成員將無法自動聯機。因此，在第二個數據中心中激活郵箱服務器還需要一個強制 DAG 成員服務器創建仲裁的步驟，這時將從 DAG 內部刪除（僅臨時刪除）故障數據中心中的服務器。這可以提供一個穩定的部分服務解決方案，能夠體驗某種級別的其他故障，并能繼續正常工作。

注意：
能夠體驗其他故障的一個先決條件是 DAG 至少有四個成員，并且這四個成員分布在兩個 ActiveDirectory 站點之間（即每個數據中心至少有兩個成員）。

這是用于在第二個數據中心中重新建立郵箱角色功能的基本過程。激活第二個數據中心中的其他角色不涉及對第二個數據中心中受影響服務器的顯式操作。相反，第二個數據中心中的服務器將成為通常由主數據中心承載的那些服務的服務端點。例如，通常在主數據中心駐留的用戶可以使用 https://mail.contoso.com/owa 連接到 OutlookWebApp。在數據中心發生故障之后，這些服務端點作為切換操作的一部分移動到第二個數據中心中的端點。在切換操作過程中，主數據中心的服務端點將重新定向到第二個數據中心中的相同服務的備用 IP 地址。在切換過程中，這可以減少必須對 ActiveDirectory 中存儲的配置信息進行更改的次數。通常，可以通過兩種方法來完成此步驟：

• 使用 DNS 記錄更新；或
• 使用全局 DNS 和負載平衡器 (LB) 重新配置啟用和禁用備用 IP 地址，從而在數據中心之間移動服務。
• 必須建立一個測試解決方案的策略。必須將其包括在 SLA 中。定期驗證部署是保證部署不隨時間的推移而降級的唯一方式。

認真完成這些規劃步驟對成功進行數據中心切換有著立竿見影的效果。例如，糟糕的命名空間設計可能會導致證書出現問題，不正確的證書配置則可能會阻止用戶訪問服務。

在驗證部署之后，我們建議明確記錄直接影響成功進行數據中心切換的所有配置部分。此外，還應圍繞這些部署部分加強更改管理過程。

有關數據中心切換（包括激活輔助數據中心和重新激活發生故障的（主）數據中心）的詳細信息，請參閱數據中心切換。

原文地址

查看更多相關文章