Exchange2003/2010共存模式環境遷移

 

1、我司的exchange2010架構設計基於中心的模式進行。並且基於exchange2010sp3進行。

基於dag三臺架構設計進行，截止到5月14日，北京局基於2臺dag進行，大連局基於exchange2007部署，我局眼下是惟一基於dag三臺進行的exchange2010sp3改造。

 

2、exchange虛擬化環境基於veeam複製技術構建，基於veeam的複製技術實現了三點功能特性：

       一、veeam複製的虛擬機狀態快照基於的是增量備份，有效下降了磁盤佔用量。並基於veeam的反覆數據刪除技術可以實現虛擬機的有效的數據佔用量。

       二、veeam基於連續數據複製的方式實現了虛擬機跨主機esxi server的災難切換。

       三、veeam可以識別虛擬機中的exchange數據，並可以單獨對郵箱和用戶內容進行備份和歸檔。實現了應用級的業務連續性。

 

 

咱們建議基於dagserver奇數臺進行架構設計，不建議基於dagserver偶數臺進行架構設計。緣由是dag集羣的腦裂故障會致使高可用性的下降。

DAG是創建在故障轉移羣集基礎上的，而CAS Array是創建在負載平衡基礎上的，所以DAG和CAS Array沒法在一臺server上並存！也就是說，假設你選擇使用兩臺server安裝Exchange2010，每臺server上都安裝了CAS，HUB及Mailbox角色，那麼你沒法既實現DAG，又實現CAS Array。通常咱們建議在這種拓撲上配置DAG，使用DNS輪詢實現CAS角色的負載平衡功能。第二，DAG因爲需要在每臺Mailboxserver上都建立一套全然一樣的郵箱數據庫，所以計算郵箱存儲空間時需要考慮這一特性。好比公司有5000名郵箱用戶，每人郵箱空間1G。那存儲需要的空間就不是5T左右，而是至少10T。第三，DAG需要從Active Directory中讀取郵箱數據庫的配置，而域控制器之間存在複製同步的問題。所以。假設郵箱數據庫複製時暫時出現找不到數據庫的情況，在5分鐘後重試又能正常進行復制，這些屬於正常現象。不用操心。

配置DAG時Mailboxserver最好有兩塊網卡，一塊網卡用於生產環境，還有一塊網卡用於DAG之間的複製。

例如如下圖所看到的。MAPI網卡就是用於生產環境的，還有一塊網卡是用於DAG複製的。MAPI網卡的IP是10.1.1網段。DAG複製網卡的網段是10.1.2網段。通常建議把DAG複製網卡的優先級調高，但事實上並不影響工做。無論哪塊網卡的優先級高，都是可以的。

 

假設DAG組中的Mailboxserver爲奇數。好比3臺或5臺，就不需要見證server；假設Mailboxserver爲偶數，則需要配置一臺見證server。用於仲裁。

通常咱們使用HUBserver做爲見證。假設HUB和Mailbox安裝在同一臺server上。事實上也可以使用DC做爲見證server。

CASHUB1是見證server，使用c:\dag01文件夾做爲見證文件夾。

 

見證server」是 DAG 外部的server，當 DAG 的成員數爲偶數時。使用該server可實現和維護仲裁。

DAG 的成員數爲奇數時，則不使用見證server。成員爲偶數的全部 DAG 都將使用見證server。

見證server可以是執行 Windows Server 的不論什麼計算機。

不要求見證server的 Windows Server 操做系統版本號與 DAG 成員使用的操做系統匹配。

仲裁在 DAG 下的羣集級別維護。當 DAG 的大多數成員處於聯機狀態。並且可以與 DAG 的其它聯機成員通訊時，DAG 才進行仲裁。此仲裁概念是 Windows 故障轉移羣集中仲裁概念的一個方面。在故障轉移羣集中與仲裁相關的必需方面是「仲裁資源」。

仲裁資源是故障轉移羣集內部的資源，它可爲致使羣集狀態和成員身份決策提供一種仲裁方法。仲裁資源還爲存儲配置信息提供了永久存儲區。仲裁資源的配套組件是「仲裁日誌」，它是羣集的配置數據庫。

仲裁日誌包含下面信息：哪些server是羣集的成員。羣集中安裝了哪些資源，以及這些資源的狀態（好比。聯機或脫機）。

每個 DAG 成員對怎樣配置 DAG 的基礎羣集應具備一致的視圖。這一點相當重要。仲裁充當了與羣集相關的全部配置信息的權威性存儲庫。仲裁還用做關係斷開裁判，以免「網絡分區」症狀。

網 絡分區症狀是在 DAG 成員沒法相互通訊（但可以正常執行）時發生的一種狀況。始終要求大多數 DAG 成員（在 DAG 成員爲偶數時使用 DAG 見證server）可用並處於交互狀態。使 DAG 可以正常工做，這樣就能夠防止網絡分區症狀。

 

規劃高可用性和網站恢復

Microsoft Exchange Server 2010 包含一個新的用於郵箱恢復的統一框架。該框架包含一些新功能。如數據庫可用性組 (DAG) 和郵箱數據庫副本。

雖然可以高速簡單地部署這些新功能，但是必須先進行認真規劃，以確保使用這些功能的不論什麼高可用性和網站恢復解決方式可以達到預期目的和 知足業務要求。

在規劃階段中。系統結構設計師、管理員和其它主要利益相關方應肯定部署的要求；尤爲是高可用性和網站恢復的要求。部署這些功能必須知足一些常規要求，還必須知足硬件、軟件和網絡鏈接要求。

常規要求

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

• 域名系統 (DNS) 必須在執行。理論上。DNS server應該接受動態更新。假設 DNS server不接受動態更新。則必須爲每個 Exchange server建立 DNS 主機 (A) 記錄。不然，Exchange 不能正常執行。
• DAG 中的每個郵箱server必須是一樣域中的成員server。
• 不支持將同一時候做爲文件夾server的 Exchange 2010 郵箱server加入到 DAG。

• 分配給 DAG 的名稱必須是不超過 15 個字符的有效、可用和惟一的計算機名稱。

硬件要求

一般，沒有特定於 DAG 或郵箱數據庫副本的特殊硬件要求。使用的server必須符合 Exchange 2010 先決條件和Exchange 2010 系統要求主題中規定的全部要求。

軟件要求

Exchange 2010 Standard Edition 和 Exchange 2010 Enterprise Edition 中都提供 DAG。此外，DAG可以包含執行 Exchange 2010 Standard Edition 和 Exchange 2010 Enterprise Edition 的混合server。

DAG 的每個成員還必須執行一樣的操做系統。Windows Server 2008 和 Windows Server 2008 R2 操做系統都支持 Exchange 2010。DAG 的全部成員都必須執行Windows Server 2008 或Windows Server 2008 R2。它們不能包含 Windows Server 2008 和 Windows Server 2008 R2 的組合。

除符合安裝 Exchange 2010 的先決條件外，還必須符合操做系統要求。

DAG 使用Windows 故障轉移羣集技術，所以，它們需要Windows Enterprise 版本號。

網絡要求

每個 DAG 和每個DAG 成員都必須符合特定的網絡要求。

DAG 網絡與在 Exchange 的曾經版本號中使用的公用、混合和專用網絡類似。

但是，與曾經版本號不一樣，在每個 DAG 成員中使用單一網絡是一種受支持的配置。此外，該術語已有所更改。每個 DAG 都再也不使用公用、專用或混合網絡。而是一個「MAPI 網絡」（其它server，好比其它 Exchange 2010 server、文件夾server等使用該網絡與 DAG 成員通訊）和零個或多個「複製網絡」（這些網絡專用於日誌傳送和種子設定）。

雖然支持一個網絡，但咱們建議每個 DAG 至少應有兩個網絡：一個MAPI 網絡和一個複製網絡。這可以提供網絡和網絡路徑的冗餘，使系統可以區分server故障和網絡故障。使用單個網絡適配器會阻礙系統區分這兩種類型的故障。

注意：

此內容區中的產品文檔在編寫時假定每個 DAG 成員至少包含兩個網絡適配器，每個 DAG 配置一個 MAPI 網絡和至少一個複製網絡。並且系統可以區分網絡故障和server故障。

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

• DAG 的每個成員必須具備至少一個可以與全部其它 DAG 成員通訊的網絡適配器。假設使用的是單一網絡路徑，咱們建議使用千兆比特的以太網。在每個 DAG 成員中使用單一網絡適配器時，需要爲複製啓用 DAG 網絡，並且應將其配置爲 MAPI 網絡。因爲沒有其它網絡，因此係統還使用 MAPI 網絡做爲複製網絡。此外。在每個 DAG 成員中使用單一網絡適配器時，咱們建議在設計總體解決方式時考慮單一網絡適配器和路徑。
• 在每個 DAG 成員中使用兩個網絡適配器可提供一個 MAPI 網絡和一個複製網絡。以及下面恢復行爲：
• 假設故障影響 MAPI 網絡。將發生server故障轉移（假定可以激活健康的郵箱數據庫副本）。
• 在故障影響複製網絡時。假設 MAPI 網絡未受故障的影響，則日誌傳送和種子設定操做將恢復爲使用 MAPI 網絡。還原發生問題的複製網絡時，日誌傳送和種子設定操做將恢復到複製網絡。
• 每個 DAG 成員都必須具備一樣數量的網絡。好比，假設計劃在一個 DAG 成員中使用單一網絡適配器。則 DAG 的全部成員也必須使用單一網絡適配器。
• 每個 DAG 不得有多個 MAPI 網絡。

  MAPI 網絡必須提供與其它 Exchange server和其它服務（如 Active Directory 和 DNS）的鏈接。

• 可以依據需要加入其它複製網絡。經過使用網絡適配器成組或類似的技術還可以防止個別網絡適配器發生單點故障。

  但是，即便使用成組，也不能阻止網絡自己發生單點故障。

• 每個 DAG 成員server中的每個網絡必須在本身的網絡子網上。DAG 中的每個server可以在不一樣的子網上，但 MAPI 和複製網絡必須可以路由並提供鏈接，以便於：
• 每個 DAG 成員server中的每個網絡位於本身的網絡子網上。並且該子網與server中每個其它網絡使用的子網分離。
• 每個 DAG 成員server的 MAPI 網絡可以與每個其它 DAG 成員的 MAPI 網絡通訊。
• 每個 DAG 成員server的複製網絡可以與每個其它 DAG 成員的複製網絡通訊。

• 沒有直接路由將檢測信號通訊從一個 DAG 成員server上的複製網絡傳遞到還有一個 DAG 成員server上的 MAPI 網絡（反之亦然），在 DAG 中的多個複製網絡之間也沒有直接路由。

• 無論 DAG 的每個成員相對於其它 DAG 成員的地理位置怎樣，每個成員相互之間的往返網絡延遲均不得大於 250 毫秒 (ms)。

• 對於多數據中心配置，往返延遲要求可能不是最嚴格的網絡帶寬和延遲要求。必須評估網絡總負載（當中包含client訪問、Active Directory、傳輸、連續複製和其它應用程序通訊）以肯定您的環境所需的網絡要求。
• DAG 網絡支持 Internet 協議版本號 4 (IPv4) 和 IPv6。

  僅當同一時候使用 IPv4 時才支持 IPv6。不支持純 IPv6 環境。

  僅當在計算機上同一時候啓用 IPv6 和 IPv4。並且網絡支持這兩種 IP 地址版本號時，才支持使用 IPv6 地址和 IP 地址範圍。

  假設在此配置中部署 Exchange 2010，則全部server角色都可在使用 IPv6 地址的設備、server和client中發送和接收數據。

• 本身主動專用 IP 尋址 (APIPA) 是 Microsoft Windows 的一種功能，當網絡上沒有不論什麼動態主機配置協議 (DHCP) server可用時，它將本身主動分配 IP 地址。APIPA 地址（包含從 APIPA 地址範圍手動分配的地址）不支持由 DAG 或 Exchange 2010 使用。

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 地址和網絡名稱外，在Active Directory 中還將建立羣集網絡對象(CNO)。系統還將在內部使用羣集的名稱、IP地址和 CNO 來保護DAG 進行內部通訊。管理員和終於用戶不需要對接或鏈接DAG 名稱或 IP 地址。

注意：

雖然羣集的 IP 地址和網絡名稱由系統內部使用，但在提供這些資源的 Exchange 2010 中沒有硬性依賴關係。即便基礎羣集的 IP 地址和網絡名稱資源處於脫機狀態。經過使用 DAG 成員的server名稱。在 DAG 中仍會發生內部通訊。但是。咱們建議按期監視這些資源的可用性，以確保它們的脫機時間不超過 30 天。假設基礎羣集的脫機時間超過 30 天。則 Active Directory 中的垃圾收集機制可能使羣集 CNO 賬戶無效。

DAG 的網絡適配器配置

必須依據預期的用途正確配置每個網絡適配器。

用於 MAPI 網絡的網絡適配器的配置與用於複製網絡的網絡適配器的不一樣。除正確配置每個網絡適配器外，還必須在 Windows 中配置網絡鏈接順序，以便 MAPI 網絡位於鏈接順序的頂部。

MAPI 網絡適配器配置

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

聯網功能	設置
Microsoft 網絡的client	已啓用
QoS 數據包計劃程序	可選啓用
Microsoft 網絡的文件和打印機共享	啓用
Internet 協議版本號 6 (TCP/IP v6)	可選啓用
Internet 協議版本號 4 (TCP/IP v4)	已啓用
鏈路層拓撲發現映射器 I/O 驅動程序	已啓用
鏈路層拓撲發現響應程序	已啓用

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

• 可以手動分配 IP 地址。或將其配置爲使用 DHCP。

  假設使用 DHCP，咱們建議對server的 IP 地址使用持久保留。

• MAPI 網絡一般使用默認網關，雖然不需要網關。
• 必須配置至少一個 DNS server地址。爲實現冗餘，建議使用多個 DNS server。

• 應選中「在 DNS 中註冊此鏈接地址」複選框。

複製網絡適配器配置

應依照下表中的描寫敘述配置供複製網絡使用的網絡適配器。

聯網功能	設置
Microsoft 網絡的client	已禁用
QoS 數據包計劃程序	可選啓用
Microsoft 網絡的文件和打印機共享	已禁用
Internet 協議版本號 6 (TCP/IP v6)	可選啓用
Internet 協議版本號 4 (TCP/IP v4)	已啓用
鏈路層拓撲發現映射器 I/O 驅動程序	已啓用
鏈路層拓撲發現響應程序	已啓用

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

• 可以手動分配 IP 地址，或將其配置爲使用 DHCP。假設使用 DHCP。咱們建議對server的 IP 地址使用持久保留。
• 複製網絡一般沒有默認網關。假設 MAPI 網絡有默認網關，則其它網絡不該有默認網關。可以使用持久的靜態路由配置複製網絡上的網絡通訊路由，將網絡通訊路由到使用網關地址的其它 DAG 成員上的對應網絡。該網關地址具備在複製網絡之間路由的能力。與此路由不匹配的全部其它通訊都將由在 MAPI 網絡的適配器上配置的默認網關處理。
• 不該配置 DNS server地址。
• 不該選中「在 DNS 中註冊此鏈接地址」複選框。

見證server要求

「見證server」是 DAG 外部的server。當DAG 的成員數爲偶數時，使用該server可實現和維護仲裁。

DAG的成員數爲奇數時。則不使用見證server。

成員爲偶數的全部 DAG 都將使用見證server。

見證server可以是執行 Windows Server 的不論什麼計算機。

不要求見證server的 Windows Server 操做系統版本號與 DAG 成員使用的操做系統匹配。

仲裁在 DAG 下的羣集級別維護。

當DAG 的大多數成員處於聯機狀態，並且可以與DAG 的其它聯機成員通訊時，DAG 才進行仲裁。此仲裁概念是 Windows 故障轉移羣集中仲裁概念的一個方面。在故障轉移羣集中與仲裁相關的必需方面是「仲裁資源」。仲裁資源是故障轉移羣集內部的資源，它可爲致使羣集狀態和成員身份決策提供一種仲裁方法。仲裁資源還爲存儲配置信息提供了永久存儲區。仲裁資源的配套組件是「仲裁日誌」。它是羣集的配置數據庫。仲裁日誌包含下面信息：哪些server是羣集的成員。羣集中安裝了哪些資源。以及這些資源的狀態（好比。聯機或脫機）。

每個 DAG 成員對怎樣配置DAG 的基礎羣集應具備一致的視圖，這一點相當重要。

仲裁充當了與羣集相關的全部配置信息的權威性存儲庫。仲裁還用做關係斷開裁判，以免「網絡分區」症狀。

網絡分區症狀是在 DAG 成員沒法相互通訊（但可以正常執行）時發生的一種狀況。始終要求大多數 DAG 成員（在DAG 成員爲偶數時使用 DAG 見證server）可用並處於交互狀態，使 DAG 可以正常工做，這樣就能夠防止網絡分區症狀。

規劃網站恢復

愈來愈多的業務人員認識到，天天訪問可靠而又可用的郵件系統是其成功的基礎。

對於不少組織而言，郵件系統是業務連續性計劃的一部分，並且在設計郵件服務部署時應考慮網站恢復。

基本上，不少網站恢復解決方式都涉及在第二個數據中心中部署硬件。

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

解決方式的結構設計師和管理員還將肯定哪一組用戶需要網站恢復保護，並肯定多網站解決方式是活動/被動配置仍是活動/活動配置。在活動/被動配置 中。備用數據中心中一般不駐留不論什麼用戶。在活動/活動配置中，用戶同一時候駐留在兩個位置。在該解決方式中，數據庫總數中有必定的百分比在第二個數據中心的首 選活動位置。當一個數據中心的用戶的服務出現故障時。將在還有一數據中心中激活這些用戶。

構造適當的 SLA 一般需要考慮下面基本問題：

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

經過回答這些問題。您實際上已經開始爲郵件解決方式構建網站恢復設計的大體框架。

從網站故障進行恢復的核心要求是：建立解決方式。將必要的郵件數據放入承載備用郵件服務的備用數據中心。

命名空間規劃

部署網站恢復配置時，Exchange 2010 將更改計劃命名空間設計的方式。

正確的命名空間計劃是數據中心成功切換的關鍵。從命名空間角度看。在網站恢復配置中使用的每個數據中心都被視爲活動數據中 心。所以，每個數據中心對於該網站中的各類 Exchange 2010 服務都需要本身的惟一命名空間，當中包含 Outlook Web App、Outlook Anywhere、Exchange ActiveSync、Exchange Web 服務、RPC client訪問、郵局協議版本號 3 (POP3)、Internet 郵件訪問協議版本號 4 (IMAP4) 和簡單郵件傳輸協議 (SMTP) 的命名空間。

此外，當中一個數據中心還承載 Autodiscover 的命名空間。

此設計還使您可以執行從主數據中心到第二個數據中心的單一數據庫切換，以便做爲數據中心切換的驗證和實踐的一部分來驗證第二個數據中心的配 置。

做爲最佳實踐，咱們建議使用「拆分DNS」做爲client使用的 Exchange 主機名。

拆分 DNS 是指一種DNS server配置，當中內部 DNS server返回主機名的內部 IP 地址，外部（面向Internet）DNS server返回同一主機名的公用 IP 地址。因爲經過拆分DNS 可以在內部和外部使用一樣的主機名，因此此策略可以使所需的主機名數目達到最少。

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

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

如上所看到的，每個數據中心都使用單獨的惟一命名空間，並且每個命名空間在這些命名空間的拆分 DNS 配置中都包含DNS server。雷蒙德數據中心（視爲主數據中心）配置了一個命名空間protocol.contoso.com。

波特蘭數據中心配置了一個命名空間 protocol.standby.contoso.com。命名空間可以包含備用標誌，如演示樣例圖中所看到的，它們可以基於地區命名（好比 protocol.portland.contoso.com），也可以基於適合組織需要的其它命名約定來命名。

不論使用哪一種命名約定，關鍵一點是每個數據中心都需要有本身的惟一命名空間。

證書規劃

在單一數據中心部署 DAG 時，證書不存在惟一或特殊的設計注意事項。

但是，在網站恢復配置中跨多個數據中心擴展 DAG 時，對於證書有一些詳細注意事項。一般，證書設計依賴於正在使用的client，以及使用證書的其它應用程序的證書要求。

但是，對於要使用的證書類型和證書數。 應當遵循一些特定的建議和最佳實踐。

做爲最佳實踐，應當將用於client訪問server、反向代理server和傳輸server（邊距和集線器）的證書數下降到最低限度。咱們建議在每個數據中心中爲全部這些服務端點使用單一證書。

此方法將可以使所需的證書數達到最少。從而下降解決方式的成本和複雜性。

對於 Outlook Anywhere client，咱們建議對每個數據中心使用單一主題備用名稱 (SAN) 證書，並在該證書中包含多個主機名稱。

爲確保在數據庫、server或數據中心切換以後 Outlook Anywhere 的鏈接性，必須在每個證書上使用一樣的證書主體名稱。並使用 Microsoft 標準格式 (msstd) 爲Outlook 提供程序配置對象Active Directory 配置一樣的主體名稱。好比。假設使用證書主體名稱 mail.contoso.com，則可以按例如如下方式配置屬性：

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

與 Exchange 集成的某些應用程序具備特定的證書要求。這些應用程序可能需要使用其它證書。Exchange 2010 可以與 Office Communications Server (OCS) 共存。OCS 需要1024 位或更高版本號的證書。這些證書使用OCS server名稱做爲證書主體名稱。因爲將OCS server名稱用做證書主體名稱會阻止Outlook Anywhere 正常工做。因此需要在OCS 環境中使用其它單獨證書。

網絡規劃

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

• MAPI 網絡應獨立於複製網絡 Windows 網絡策略、Windows 防火牆策略或路由器訪問控制列表 (ACL) 應當用於阻止 MAPI 網絡與複製網絡之間的通訊。此配置是防止網絡檢測信號交叉對話所必需的。
• 面向client的 DNS 記錄應有 5 分鐘的生存時間 (TTL) client體驗的停機時間長短不只依賴於切換的速度。還依賴於 DNS 複製的速度。以及client查詢 DNS 更新信息的速度。應將全部 Exchange client服務（包含內部和外部 DNS server中的 Outlook Web App、Exchange ActiveSync、Exchange Web 服務、Outlook Anywhere、SMTP、POP三、IMAP4 和 RPC client訪問）的 DNS 記錄的生存時間設置爲 5 分鐘。
• 使用靜態路由配置跨複製網絡的鏈接 若要在每個複製網絡適配器之間提供網絡鏈接。請使用持久靜態路由。使用靜態 IP 地址時，這是對每個 DAG 成員執行的一次性高速配置。

  假設在使用 DHCP 爲複製網絡獲取 IP 地址，則還可以使用它爲複製分配靜態路由。從而簡化配置過程。

常規網站恢復規劃

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

爲了儘量縮短激活第二個數據中心所需的時間，並贊成第二個數據中心承載故障數據中心的服務端點。必須完畢適當的規劃。

好比：

• 必須充分理解和記錄網站恢復解決方式的服務級別協議 (SLA) 目標。
• 第二個數據中心中的server必須具備足夠的容量，以便承載兩個數據中心的組合用戶羣。

• 第二個數據中心必須啓用在主數據中心中提供的全部服務（除非這些服務未做爲網站恢復 SLA 的一部分包含在內）。這包含 Active Directory、網絡基礎結構（DNS 和 TCP/IP 等）、電話服務（假設使用的是統一消息）和網站基礎結構（電源、散熱等）。

• 爲使某些服務可以服務於發生問題的數據中心中的用戶。必須爲這些服務必須配置了正確的server證書。有些服務不一樣意實例化（好比，POP3 和 IMAP4），僅僅贊成使用單一證書。

  在這些狀況下，證書要麼必須是一個包含多個名稱的主題備用名稱 (SAN) 證書，要麼必須是很類似的多個名稱，以便可以使用通配符證書（假定組織的安全策略贊成使用通配符證書）。

• 在第二個數據中心中必須定義必要的服務。

  好比。假設第一個數據中心在不一樣的傳輸server上有三個不一樣的 SMTP URL，那麼必須在第二個數據中心中定義合適的配置。使至少一個（假設不是全部三個）傳輸server承載工做負荷。

• 要支持數據中心切換。必須已配置了必要的網絡。這可能意味着。確保配置了負載平衡，配置了全局 DNS。並且啓用了配置適當路由的 Internet 鏈接。
• 必須瞭解支持數據中心切換所需的 DNS 更改策略。必須定義和記錄特定的 DNS 更改（包含其生存時間 (TTL) 設置），才幹支持有效的 SLA。
• 還必須創建測試解決方式的策略，並將其包含在 SLA 中。按期驗證部署是保證部署的質量和實用性不隨時間的推移而降級的惟一方式。

  在驗證部署以後，咱們建議明白記錄直接影響解決方式成功的配置部分。

  此外，還建議環繞這些部署部分增強更改管理過程。

對數據中心切換的規劃

正確規劃和準備不只涉及第二個數據中心資源的部署（如活動client訪問和集線器傳輸server），並且涉及做爲數據中心切換操做的一部分預配置這些資源，從而使所需的更改達到最低限度。

注意：

第二個數據中心需要client訪問和集線器傳輸服務。即便阻止第二個數據中心中的郵箱數據庫本身主動激活也如此。 這些服務是執行數據庫切換以及在第二個數據中心測試和驗證服務和數據所必需的。

爲更好地瞭解數據中心切換過程的工做方式，瞭解 Exchange 2010 數據中心切換的基本操做很實用。

例如如下圖所看到的，網站恢復部署包含一個在兩個數據中心中都有成員的 DAG。

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

跨多個數據中心擴展 DAG 時，應對其進行對應設計。使大多數 DAG 成員都在主數據中心。或者，在每個數據中心都具備一樣數量的成員時，使主數據中心承載見證server。此設計可保證在主數據中心提供服務，即便兩個數據中心之 間的網絡鏈接發生問題時也如此。只是，這還意味着主數據中心發生問題時。將失去對第二個數據中心中的成員的仲裁。

還可能會發生部分數據中心故障。

假設主數據中心因失去足夠的功能而阻礙有效的服務和管理，則應執行數據中心切換來激活第二個數據中心。激活過程涉及管理員將部分操做狀態的倖存server配置爲中止服務。而後可以在第二個數據中心繼續激活。這樣可以防止同一時候嘗試和操做兩組服務。

因爲仲裁丟失。第二個數據中心中的 DAG 成員將沒法本身主動聯機。所以。在第二個數據中心中激活郵箱server還需要一個強制 DAG 成員server建立仲裁的步驟，這時將從 DAG 內部刪除（僅暫時刪除）故障數據中心中的server。這可以提供一個穩定的部分服務解決方式，可以體驗某種級別的其它故障。並能繼續正常工做。

注意：

可以體驗其它故障的一個先決條件是 DAG 至少有四個成員，並且這四個成員分佈在兩個 Active Directory 網站之間（即每個數據中心至少有兩個成員）。

這是用於在第二個數據中心中又一次創建郵箱角色功能的基本過程。

激活第二個數據中心中的其它角色不涉及對第二個數據中心中受影響server的顯式操做。相 反，第二個數據中心中的server將成爲一般由主數據中心承載的那些服務的服務端點。

好比，一般在主數據中心駐留的用戶可以使用 https://mail.contoso.com/owa 鏈接到 Outlook Web App。在數據中心發生問題以後，這些服務端點做爲切換操做的一部分移動到第二個數據中心中的端點。在切換操做過程當中。主數據中 心的服務端點將又一次定向到第二個數據中心中的一樣服務的備用 IP 地址。在切換過程當中。這可以下降必須對 Active Directory 中存儲的配置信息進行更改的次數。一般，可以經過兩種方法來完畢此步驟：

• 使用 DNS 記錄更新。或
• 使用全局 DNS 和負載平衡器 (LB) 又一次配置啓用和禁用備用 IP 地址，從而在數據中心之間移動服務。

• 必須創建一個測試解決方式的策略。必須將其包含在 SLA 中。按期驗證部署是保證部署不隨時間的推移而降級的惟一方式。

認真完畢這些規劃步驟對成功進行數據中心切換有着立竿見影的效果。

好比，糟糕的命名空間設計可能會致使證書出現故障，不對的證書配置則可能會阻止用戶訪問服務。

在驗證部署以後。咱們建議明白記錄直接影響成功進行數據中心切換的全部配置部分。此外。還應環繞這些部署部分增強更改管理過程。