規(guī)劃高可用性和站點恢復
Microsoft ExchangeServer2010 包括一個新的用于郵箱恢復的統(tǒng)一框架,該框架包括一些新功能,如數(shù)據(jù)庫可用性組 (DAG) 和郵箱數(shù)據(jù)庫副本。盡管可以快速簡單地部署這些新功能,但是必須先進行認真規(guī)劃,以確保使用這些功能的任何高可用性和站點恢復解決方案可以達到預期目的和滿足業(yè)務要求。
在規(guī)劃階段中,系統(tǒng)結構設計師、管理員和其他主要利益相關方應確定部署的要求;尤其是高可用性和站點恢復的要求。部署這些功能必須滿足一些常規(guī)要求,還必須滿足硬件、軟件和網(wǎng)絡連接要求。有關 DAG 存儲要求的指南,請參閱Mailbox Server Storage Design。
常規(guī)要求
在部署 DAG 和創(chuàng)建郵箱數(shù)據(jù)庫副本之前,請確保符合以下系統(tǒng)范圍建議:
- 域名系統(tǒng) (DNS) 必須在運行。理論上,DNS 服務器應該接受動態(tài)更新。如果 DNS 服務器不接受動態(tài)更新,則必須為每個 Exchange 服務器創(chuàng)建 DNS 主機 (A) 記錄。否則,Exchange 不能正常運行。
- DAG 中的每個郵箱服務器必須是相同域中的成員服務器。
- 不支持將同時作為目錄服務器的 Exchange2010 郵箱服務器添加到 DAG。
- 分配給 DAG 的名稱必須是不超過 15 個字符的有效、可用和唯一的計算機名稱。
硬件要求
通常,沒有特定于 DAG 或郵箱數(shù)據(jù)庫副本的特殊硬件要求。使用的服務器必須符合 Exchange 2010 先決條件和 Exchange 2010 系統(tǒng)要求主題中規(guī)定的所有要求。有關硬件規(guī)劃信息,請參閱下列主題:
軟件要求
Exchange2010 Standard Edition 和 Exchange2010 Enterprise Edition 中都提供 DAG。此外,DAG 可以包含運行 Exchange2010 Standard Edition 和 Exchange2010 Enterprise Edition 的混合服務器。
DAG 的每個成員還必須運行相同的操作系統(tǒng)。WindowsServer2008 和 WindowsServer2008 R2 操作系統(tǒng)都支持 Exchange2010。DAG 的所有成員都必須運行 WindowsServer2008 或 WindowsServer2008 R2。它們不能包含 WindowsServer2008 和 WindowsServer2008 R2 的組合。
除符合安裝 Exchange2010 的先決條件外,還必須符合操作系統(tǒng)要求。DAG 使用 Windows 故障轉移群集技術,因此,它們需要 Windows Enterprise 版本。
網(wǎng)絡要求
每個 DAG 和每個 DAG 成員都必須符合特定的網(wǎng)絡要求。DAG 網(wǎng)絡與在 Exchange 的以前版本中使用的公用、混合和專用網(wǎng)絡類似。但是,與以前版本不同,在每個 DAG 成員中使用單一網(wǎng)絡是一種受支持的配置。此外,該術語已有所更改。每個 DAG 都不再使用公用、專用或混合網(wǎng)絡,而是一個“MAPI 網(wǎng)絡”(其他服務器,例如其他 Exchange2010 服務器、目錄服務器等使用該網(wǎng)絡與 DAG 成員通信)和零個或多個“復制網(wǎng)絡”(這些網(wǎng)絡專用于日志傳送和種子設定)。
盡管支持一個網(wǎng)絡,但我們建議每個 DAG 至少應有兩個網(wǎng)絡:一個 MAPI 網(wǎng)絡和一個復制網(wǎng)絡。這可以提供網(wǎng)絡和網(wǎng)絡路徑的冗余,使系統(tǒng)能夠區(qū)分服務器故障和網(wǎng)絡故障。使用單個網(wǎng)絡適配器會阻礙系統(tǒng)區(qū)分這兩種類型的故障。
![]() |
---|
此內容區(qū)中的產(chǎn)品文檔在編寫時假定每個 DAG 成員至少包含兩個網(wǎng)絡適配器,每個 DAG 配置一個 MAPI 網(wǎng)絡和至少一個復制網(wǎng)絡,并且系統(tǒng)能夠區(qū)分網(wǎng)絡故障和服務器故障。 |
為 DAG 設計網(wǎng)絡基礎結構時,請考慮下列事項:
- DAG 的每個成員必須具有至少一個能夠與所有其他 DAG 成員通信的網(wǎng)絡適配器。如果使用的是單一網(wǎng)絡路徑,我們建議使用千兆比特的以太網(wǎng)。在每個 DAG 成員中使用單一網(wǎng)絡適配器時,需要為復制啟用 DAG 網(wǎng)絡,并且應將其配置為 MAPI 網(wǎng)絡。因為沒有其他網(wǎng)絡,所以系統(tǒng)還使用 MAPI 網(wǎng)絡作為復制網(wǎng)絡。此外,在每個 DAG 成員中使用單一網(wǎng)絡適配器時,我們建議在設計總體解決方案時考慮單一網(wǎng)絡適配器和路徑。
- 在每個 DAG 成員中使用兩個網(wǎng)絡適配器可提供一個 MAPI 網(wǎng)絡和一個復制網(wǎng)絡,以及以下恢復行為:
- 如果故障影響 MAPI 網(wǎng)絡,將發(fā)生服務器故障轉移(假定可以激活健康的郵箱數(shù)據(jù)庫副本)。
- 在故障影響復制網(wǎng)絡時,如果 MAPI 網(wǎng)絡未受故障的影響,則日志傳送和種子設定操作將恢復為使用 MAPI 網(wǎng)絡。還原發(fā)生故障的復制網(wǎng)絡時,日志傳送和種子設定操作將恢復到復制網(wǎng)絡。
- 每個 DAG 成員都必須具有相同數(shù)量的網(wǎng)絡。例如,如果計劃在一個 DAG 成員中使用單一網(wǎng)絡適配器,則 DAG 的所有成員也必須使用單一網(wǎng)絡適配器。
- 每個 DAG 不得有多個 MAPI 網(wǎng)絡。MAPI 網(wǎng)絡必須提供與其他 Exchange 服務器和其他服務(如 ActiveDirectory 和 DNS)的連接。
- 可以根據(jù)需要添加其他復制網(wǎng)絡。通過使用網(wǎng)絡適配器成組或類似的技術還可以防止個別網(wǎng)絡適配器發(fā)生單點故障。但是,即使使用成組,也不能阻止網(wǎng)絡本身發(fā)生單點故障。
- 每個 DAG 成員服務器中的每個網(wǎng)絡必須在自己的網(wǎng)絡子網(wǎng)上。DAG 中的每個服務器可以在不同的子網(wǎng)上,但 MAPI 和復制網(wǎng)絡必須可以路由并提供連接,以便于:
- 每個 DAG 成員服務器中的每個網(wǎng)絡位于自己的網(wǎng)絡子網(wǎng)上,并且該子網(wǎng)與服務器中每個其他網(wǎng)絡使用的子網(wǎng)分離。
- 每個 DAG 成員服務器的 MAPI 網(wǎng)絡可以與每個其他 DAG 成員的 MAPI 網(wǎng)絡通信。
- 每個 DAG 成員服務器的復制網(wǎng)絡可以與每個其他 DAG 成員的復制網(wǎng)絡通信。
- 沒有直接路由將檢測信號通信從一個 DAG 成員服務器上的復制網(wǎng)絡傳遞到另一個 DAG 成員服務器上的 MAPI 網(wǎng)絡(反之亦然),在 DAG 中的多個復制網(wǎng)絡之間也沒有直接路由。
- 無論 DAG 的每個成員相對于其他 DAG 成員的地理位置如何,每個成員相互之間的往返網(wǎng)絡延遲均不得大于 250 毫秒 (ms)。
- 對于多數(shù)據(jù)中心配置,往返延遲要求可能不是最嚴格的網(wǎng)絡帶寬和延遲要求。必須評估網(wǎng)絡總負載(其中包括客戶端訪問、ActiveDirectory、傳輸、連續(xù)復制和其他應用程序通信)以確定您的環(huán)境所需的網(wǎng)絡要求。
- DAG 網(wǎng)絡支持 Internet 協(xié)議版本 4 (IPv4) 和 IPv6。僅當同時使用 IPv4 時才支持 IPv6;不支持純 IPv6 環(huán)境。僅當在計算機上同時啟用 IPv6 和 IPv4,并且網(wǎng)絡支持這兩種 IP 地址版本時,才支持使用 IPv6 地址和 IP 地址范圍。如果在此配置中部署 Exchange2010,則所有服務器角色均可在使用 IPv6 地址的設備、服務器和客戶端中發(fā)送和接收數(shù)據(jù)。
- 自動專用 IP 尋址 (APIPA) 是 Microsoft Windows 的一種功能,當網(wǎng)絡上沒有任何動態(tài)主機配置協(xié)議 (DHCP) 服務器可用時,它將自動分配 IP 地址。APIPA 地址(包括從 APIPA 地址范圍手動分配的地址)不支持由 DAG 或 Exchange2010 使用。
DAG 名稱和 IP 地址要求
在創(chuàng)建過程中,會為每個 DAG 指定一個唯一名稱,并分配一個或多個靜態(tài) IP 地址,或配置為使用 DHCP。不論使用靜態(tài)地址還是動態(tài)分配的地址,分配給 DAG 的任何 IP 地址必須在 MAPI 網(wǎng)絡上。
每個 DAG 在 MAPI 網(wǎng)絡上至少需要一個 IP 地址。當 MAPI 網(wǎng)絡跨多個子網(wǎng)擴展時,DAG 需要其他 IP 地址。下圖說明了 DAG,其中 DAG 中的所有節(jié)點在相同子網(wǎng)上都具有 MAPI 網(wǎng)絡。
在同一子網(wǎng)上具有 MAPI 網(wǎng)絡的數(shù)據(jù)庫可用性組
在此示例中,每個 DAG 成員中的 MAPI 網(wǎng)絡都位于 172.19.18 .x 子網(wǎng)上。因此,DAG 在該子網(wǎng)上需要具備單一 IP 地址。
下一個圖說明了具有一個 MAPI 網(wǎng)絡的 DAG,該網(wǎng)絡跨兩個子網(wǎng):172.19.18.x 和 172.19.19.x。
在多個子網(wǎng)上具有 MAPI 網(wǎng)絡的數(shù)據(jù)庫可用性組
在此示例中,每個 DAG 成員中的 MAPI 網(wǎng)絡都位于單獨的子網(wǎng)上。因此,DAG 需要兩個 IP 地址,MAPI 網(wǎng)絡上每個子網(wǎng)有一個地址。
DAG 的 MAPI 網(wǎng)絡每次跨其他子網(wǎng)擴展時,必須為 DAG 配置該子網(wǎng)的其他 IP 地址。為 DAG 配置的每個 IP 地址被分配到 DAG 的基礎故障轉移群集,并由該群集使用。DAG 的名稱也用作基礎故障轉移群集的名稱。
在任何特定時間,DAG 的群集將僅使用分配的 IP 地址之一。當群集 IP 地址和網(wǎng)絡名稱資源進入聯(lián)機狀態(tài)時,Windows 故障轉移群集會在 DNS 中注冊此 IP 地址。除了使用 IP 地址和網(wǎng)絡名稱外,在 ActiveDirectory 中還將創(chuàng)建群集網(wǎng)絡對象 (CNO)。系統(tǒng)還將在內部使用群集的名稱、IP 地址和 CNO 來保護 DAG 進行內部通信。管理員和最終用戶不需要對接或連接 DAG 名稱或 IP 地址。
![]() |
---|
盡管群集的 IP 地址和網(wǎng)絡名稱由系統(tǒng)內部使用,但在提供這些資源的 Exchange2010 中沒有硬性依賴關系。即使基礎群集的 IP 地址和網(wǎng)絡名稱資源處于脫機狀態(tài),通過使用 DAG 成員的服務器名稱,在 DAG 中仍會發(fā)生內部通信。但是,我們建議定期監(jiān)視這些資源的可用性,以確保它們的脫機時間不超過 30 天。如果基礎群集的脫機時間超過 30 天,則 ActiveDirectory 中的垃圾收集機制可能使群集 CNO 帳戶無效。 |
DAG 的網(wǎng)絡適配器配置
必須根據(jù)預期的用途正確配置每個網(wǎng)絡適配器。用于 MAPI 網(wǎng)絡的網(wǎng)絡適配器的配置與用于復制網(wǎng)絡的網(wǎng)絡適配器的不同。除正確配置每個網(wǎng)絡適配器外,還必須在 Windows 中配置網(wǎng)絡連接順序,以便 MAPI 網(wǎng)絡位于連接順序的頂部。有關如何修改網(wǎng)絡連接順序的詳細步驟,請參閱修改協(xié)議綁定順序
MAPI 網(wǎng)絡適配器配
應按照下表中的描述配置供 MAPI 網(wǎng)絡使用的網(wǎng)絡適配器。
聯(lián)網(wǎng)功能 | 設置 |
---|---|
Microsoft 網(wǎng)絡的客戶端 |
已啟用 |
QoS 數(shù)據(jù)包計劃程序 |
可選啟用 |
Microsoft 網(wǎng)絡的文件和打印機共享 |
啟用 |
Internet 協(xié)議版本 6 (TCP/IP v6) |
可選啟用 |
Internet 協(xié)議版本 4 (TCP/IP v4) |
已啟用 |
鏈路層拓撲發(fā)現(xiàn)映射器 I/O 驅動程序 |
已啟用 |
鏈路層拓撲發(fā)現(xiàn)響應程序 |
已啟用 |
MAPI 網(wǎng)絡適配器的 TCP/IP v4 屬性配置如下:
- 可以手動分配 IP 地址,或將其配置為使用 DHCP。如果使用 DHCP,我們建議對服務器的 IP 地址使用持久保留。
- MAPI 網(wǎng)絡通常使用默認網(wǎng)關,盡管不需要網(wǎng)關。
- 必須配置至少一個 DNS 服務器地址。為實現(xiàn)冗余,建議使用多個 DNS 服務器。
- 應選中“在 DNS 中注冊此連接地址”復選框。
復制網(wǎng)絡適配器配置
應按照下表中的描述配置供復制網(wǎng)絡使用的網(wǎng)絡適配器。
聯(lián)網(wǎng)功能 | 設置 |
---|---|
Microsoft 網(wǎng)絡的客戶端 |
已禁用 |
QoS 數(shù)據(jù)包計劃程序 |
可選啟用 |
Microsoft 網(wǎng)絡的文件和打印機共享 |
已禁用 |
Internet 協(xié)議版本 6 (TCP/IP v6) |
可選啟用 |
Internet 協(xié)議版本 4 (TCP/IP v4) |
已啟用 |
鏈路層拓撲發(fā)現(xiàn)映射器 I/O 驅動程序 |
已啟用 |
鏈路層拓撲發(fā)現(xiàn)響應程序 |
已啟用 |
復制網(wǎng)絡適配器的 TCP/IP v4 屬性配置如下:
- 可以手動分配 IP 地址,或將其配置為使用 DHCP。如果使用 DHCP,我們建議對服務器的 IP 地址使用持久保留。
- 復制網(wǎng)絡通常沒有默認網(wǎng)關,如果 MAPI 網(wǎng)絡有默認網(wǎng)關,則其他網(wǎng)絡不應有默認網(wǎng)關。可以使用持久的靜態(tài)路由配置復制網(wǎng)絡上的網(wǎng)絡通信路由,將網(wǎng)絡通信路由到使用網(wǎng)關地址的其他 DAG 成員上的相應網(wǎng)絡,該網(wǎng)關地址具有在復制網(wǎng)絡之間路由的能力。與此路由不匹配的所有其他通信都將由在 MAPI 網(wǎng)絡的適配器上配置的默認網(wǎng)關處理。
- 不應配置 DNS 服務器地址。
- 不應選中“在 DNS 中注冊此連接地址”復選框。
見證服務器要求
“見證服務器”是 DAG 外部的服務器,當 DAG 的成員數(shù)為偶數(shù)時,使用該服務器可實現(xiàn)和維護仲裁。DAG 的成員數(shù)為奇數(shù)時,則不使用見證服務器。成員為偶數(shù)的所有 DAG 都將使用見證服務器。見證服務器可以是運行 WindowsServer 的任何計算機。不要求見證服務器的 WindowsServer 操作系統(tǒng)版本與 DAG 成員使用的操作系統(tǒng)匹配。
仲裁在 DAG 下的群集級別維護。當 DAG 的大多數(shù)成員處于聯(lián)機狀態(tài),并且可以與 DAG 的其他聯(lián)機成員通信時,DAG 才進行仲裁。此仲裁概念是 Windows 故障轉移群集中仲裁概念的一個方面。在故障轉移群集中與仲裁相關的必需方面是“仲裁資源”。仲裁資源是故障轉移群集內部的資源,它可為導致群集狀態(tài)和成員身份決策提供一種仲裁方法。仲裁資源還為存儲配置信息提供了***存儲區(qū)。仲裁資源的配套組件是“仲裁日志”,它是群集的配置數(shù)據(jù)庫。仲裁日志包含以下信息:哪些服務器是群集的成員,群集中安裝了哪些資源,以及這些資源的狀態(tài)(例如,聯(lián)機或脫機)。
每個 DAG 成員對如何配置 DAG 的基礎群集應具有一致的視圖,這一點至關重要。仲裁充當了與群集相關的所有配置信息的權威性存儲庫。仲裁還用作關系斷開裁判,以避免“網(wǎng)絡分區(qū)”癥狀。網(wǎng)絡分區(qū)癥狀是在 DAG 成員無法相互通信(但能夠正常運行)時發(fā)生的一種情況。始終要求大多數(shù) DAG 成員(在 DAG 成員為偶數(shù)時使用 DAG 見證服務器)可用并處于交互狀態(tài),使 DAG 能夠正常工作,這樣即可防止網(wǎng)絡分區(qū)癥狀。
規(guī)劃站點恢復
越來越多的業(yè)務人員認識到,每天訪問可靠而又可用的郵件系統(tǒng)是其成功的基礎。對于許多組織而言,郵件系統(tǒng)是業(yè)務連續(xù)性計劃的一部分,并且在設計郵件服務部署時應考慮站點恢復。基本上,許多站點恢復解決方案都涉及在第二個數(shù)據(jù)中心中部署硬件。
最終,DAG 的總體設計(其中包括 DAG 的成員數(shù)和郵箱數(shù)據(jù)庫副本數(shù))將取決于每個組織的包括各種故障情形的恢復服務級別協(xié)議 (SLA)。在規(guī)劃階段中,解決方案的結構設計師和管理員將確定部署要求,尤其是站點恢復要求。他們確定要使用的位置和所需的恢復 SLA 目標。SLA 將確定兩個特定的元素,這兩個元素應是設計高可用性和站點恢復解決方案的基礎:恢復時間目標 (RTO) 和恢復點目標 (RPO)。這兩個值都以分鐘為單位度量。RTO 是還原服務所需的時間。RPO 指在完成恢復操作之后數(shù)據(jù)的新舊程度。還可以將 SLA 定義為在解決主數(shù)據(jù)中心的問題之后,將還原為完整服務。
解決方案的結構設計師和管理員還將確定哪一組用戶需要站點恢復保護,并確定多站點解決方案是活動/被動配置還是活動/活動配置。在活動/被動配置中,備用數(shù)據(jù)中心中通常不駐留任何用戶。在活動/活動配置中,用戶同時駐留在兩個位置,在該解決方案中,數(shù)據(jù)庫總數(shù)中有一定的百分比在第二個數(shù)據(jù)中心的***活動位置。當一個數(shù)據(jù)中心的用戶的服務出現(xiàn)故障時,將在另一數(shù)據(jù)中心中激活這些用戶。
構造適當?shù)?SLA 通常需要考慮以下基本問題:
- 主數(shù)據(jù)中心出現(xiàn)故障后,需要什么級別的服務?
- 用戶是需要數(shù)據(jù)服務還是僅需要郵件服務?
- 急需數(shù)據(jù)的程度怎樣?
- 必須支持多少用戶?
- 用戶如何訪問自已的數(shù)據(jù)?
- 備用數(shù)據(jù)中心激活服務級別協(xié)議 (SLA) 是什么?
- 服務如何移回主數(shù)據(jù)中心?
- 資源是否專用于站點恢復解決方案?
通過回答這些問題,您實際上已經(jīng)開始為郵件解決方案構建站點恢復設計的大致框架。從站點故障進行恢復的核心要求是:創(chuàng)建解決方案,將必要的郵件數(shù)據(jù)放入承載備用郵件服務的備用數(shù)據(jù)中心。
命名空間規(guī)劃
部署站點恢復配置時,Exchange2010 將更改計劃命名空間設計的方式。正確的命名空間計劃是數(shù)據(jù)中心成功切換的關鍵。從命名空間角度看,在站點恢復配置中使用的每個數(shù)據(jù)中心都被視為活動數(shù)據(jù)中心。因此,每個數(shù)據(jù)中心對于該站點中的各種 Exchange2010 服務都需要自己的唯一命名空間,其中包括 OutlookWebApp、Outlook Anywhere、ExchangeActiveSync、Exchange Web 服務、RPC 客戶端訪問、郵局協(xié)議版本 3 (POP3)、Internet 郵件訪問協(xié)議版本 4 (IMAP4) 和簡單郵件傳輸協(xié)議 (SMTP) 的命名空間。此外,其中一個數(shù)據(jù)中心還承載 Autodiscover 的命名空間。此設計還使您能夠執(zhí)行從主數(shù)據(jù)中心到第二個數(shù)據(jù)中心的單一數(shù)據(jù)庫切換,以便作為數(shù)據(jù)中心切換的驗證和實踐的一部分來驗證第二個數(shù)據(jù)中心的配置。
作為***實踐,我們建議使用“拆分 DNS”作為客戶端使用的 Exchange 主機名。拆分 DNS 是指一種 DNS 服務器配置,其中內部 DNS 服務器返回主機名的內部 IP 地址,外部(面向 Internet)DNS 服務器返回同一主機名的公用 IP 地址。因為通過拆分 DNS 可以在內部和外部使用相同的主機名,所以此策略可使所需的主機名數(shù)目達到最少。
下圖說明了站點恢復配置的命名空間規(guī)劃。
站點恢復 DAG 部署的命名空間
如上所示,每個數(shù)據(jù)中心都使用單獨的唯一命名空間,并且每個命名空間在這些命名空間的拆分 DNS 配置中都包含 DNS 服務器。雷蒙德數(shù)據(jù)中心(視為主數(shù)據(jù)中心)配置了一個命名空間 protocol.contoso.com。波特蘭數(shù)據(jù)中心配置了一個命名空間 protocol.standby.contoso.com。命名空間可以包括備用標志,如示例圖中所示,它們可以基于地區(qū)命名(例如 protocol.portland.contoso.com),也可以基于適合組織需要的其他命名約定來命名。不論使用哪種命名約定,關鍵一點是每個數(shù)據(jù)中心都需要有自己的唯一命名空間。
證書規(guī)劃
在單一數(shù)據(jù)中心部署 DAG 時,證書不存在唯一或特殊的設計注意事項。但是,在站點恢復配置中跨多個數(shù)據(jù)中心擴展 DAG 時,對于證書有一些具體注意事項。通常,證書設計依賴于正在使用的客戶端,以及使用證書的其他應用程序的證書要求。但是,對于要使用的證書類型和證書數(shù),應當遵循一些特定的建議和***實踐。
作為***實踐,應當將用于客戶端訪問服務器、反向代理服務器和傳輸服務器(邊距和集線器)的證書數(shù)減少到***限度。我們建議在每個數(shù)據(jù)中心中為所有這些服務端點使用單一證書。此方法將可使所需的證書數(shù)達到最少,從而減少解決方案的成本和復雜性。
對于 Outlook Anywhere 客戶端,我們建議對每個數(shù)據(jù)中心使用單一主題備用名稱 (SAN) 證書,并在該證書中包括多個主機名稱。為確保在數(shù)據(jù)庫、服務器或數(shù)據(jù)中心切換之后 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 環(huán)境中使用其他單獨證書。
有關使用 SAN 證書進行 Exchange2010客戶端訪問的詳細信息,請參見配置 SSL 證書使用多個客戶端訪問服務器主機名稱。
網(wǎng)絡規(guī)劃
除了必須滿足每個 DAG 和屬于 DAG 成員的每個服務器的特定網(wǎng)絡要求外,還有一些特定于站點恢復配置的要求和建議。與所有 DAG 一樣,無論 DAG 成員部署在單個站點還是多個站點,DAG 成員之間的往返返回網(wǎng)絡延遲均不得大于 250 毫秒 (ms)。此外,對于跨多個站點擴展的 DAG 還有一些特定的配置設置建議:
- MAPI 網(wǎng)絡應獨立于復制網(wǎng)絡 Windows 網(wǎng)絡策略、Windows 防火墻策略或路由器訪問控制列表 (ACL) 應當用于阻止 MAPI 網(wǎng)絡與復制網(wǎng)絡之間的通信。此配置是防止網(wǎng)絡檢測信號交叉對話所必需的。
- 面向客戶端的 DNS 記錄應有 5 分鐘的生存時間 (TTL) 客戶端體驗的停機時間長短不僅依賴于切換的速度,還依賴于 DNS 復制的速度,以及客戶端查詢 DNS 更新信息的速度。應將所有 Exchange 客戶端服務(包括內部和外部 DNS 服務器中的 OutlookWebApp、ExchangeActiveSync、Exchange Web 服務、Outlook Anywhere、SMTP、POP3、IMAP4 和 RPC 客戶端訪問)的 DNS 記錄的生存時間設置為 5 分鐘。
- 使用靜態(tài)路由配置跨復制網(wǎng)絡的連接 若要在每個復制網(wǎng)絡適配器之間提供網(wǎng)絡連接,請使用持久靜態(tài)路由。使用靜態(tài) IP 地址時,這是對每個 DAG 成員執(zhí)行的一次性快速配置。如果在使用 DHCP 為復制網(wǎng)絡獲取 IP 地址,則還可以使用它為復制分配靜態(tài)路由,從而簡化配置過程。
常規(guī)網(wǎng)站恢復規(guī)劃
除上面列出的針對高可用性的要求外,在站點恢復配置中部署 Exchange2010(例如,跨多個數(shù)據(jù)中心擴展 DAG)還有一些其他建議。在計劃階段中,哪些問題會直接影響站點恢復解決方案的成功。例如,糟糕的命名空間設計可以導致證書出現(xiàn)問題,不正確的證書配置可能阻止用戶訪問服務。
為了盡可能縮短激活第二個數(shù)據(jù)中心所需的時間,并允許第二個數(shù)據(jù)中心承載故障數(shù)據(jù)中心的服務端點,必須完成適當?shù)囊?guī)劃。例如:
- 必須充分理解和記錄站點恢復解決方案的服務級別協(xié)議 (SLA) 目標。
- 第二個數(shù)據(jù)中心中的服務器必須具有足夠的容量,以便承載兩個數(shù)據(jù)中心的組合用戶群。
- 第二個數(shù)據(jù)中心必須啟用在主數(shù)據(jù)中心中提供的所有服務(除非這些服務未作為站點恢復 SLA 的一部分包括在內)。這包括 ActiveDirectory、網(wǎng)絡基礎結構(DNS 和 TCP/IP 等)、電話服務(如果使用的是統(tǒng)一消息)和站點基礎結構(電源、散熱等)。
- 為使某些服務能夠服務于發(fā)生故障的數(shù)據(jù)中心中的用戶,必須為這些服務必須配置了正確的服務器證書。有些服務不允許實例化(例如,POP3 和 IMAP4),只允許使用單一證書。在這些情況下,證書要么必須是一個包括多個名稱的主題備用名稱 (SAN) 證書,要么必須是非常相似的多個名稱,以便能夠使用通配符證書(假定組織的安全策略允許使用通配符證書)。
- 在第二個數(shù)據(jù)中心中必須定義必要的服務。例如,如果***個數(shù)據(jù)中心在不同的傳輸服務器上有三個不同的 SMTP URL,那么必須在第二個數(shù)據(jù)中心中定義合適的配置,使至少一個(如果不是全部三個)傳輸服務器承載工作負荷。
- 要支持數(shù)據(jù)中心切換,必須已配置了必要的網(wǎng)絡。這可能意味著,確保配置了負載平衡,配置了全局 DNS,并且啟用了配置適當路由的 Internet 連接。
- 必須了解支持數(shù)據(jù)中心切換所需的 DNS 更改策略。必須定義和記錄特定的 DNS 更改(包括其生存時間 (TTL) 設置),才能支持有效的 SLA。
- 還必須建立測試解決方案的策略,并將其包括在 SLA 中。定期驗證部署是保證部署的質量和實用性不隨時間的推移而降級的唯一方式。在驗證部署之后,我們建議明確記錄直接影響解決方案成功的配置部分。此外,還建議圍繞這些部署部分加強更改管理過程。
對數(shù)據(jù)中心切換的規(guī)劃
正確規(guī)劃和準備不僅涉及第二個數(shù)據(jù)中心資源的部署(如活動客戶端訪問和集線器傳輸服務器),而且涉及作為數(shù)據(jù)中心切換操作的一部分預配置這些資源,從而使所需的更改達到***限度。
![]() |
---|
第二個數(shù)據(jù)中心需要客戶端訪問和集線器傳輸服務,即使阻止第二個數(shù)據(jù)中心中的郵箱數(shù)據(jù)庫自動激活也如此。這些服務是執(zhí)行數(shù)據(jù)庫切換以及在第二個數(shù)據(jù)中心測試和驗證服務和數(shù)據(jù)所必需的。 |
為更好地了解數(shù)據(jù)中心切換過程的工作方式,了解 Exchange2010 數(shù)據(jù)中心切換的基本操作非常有用。
如下圖所示,站點恢復部署包括一個在兩個數(shù)據(jù)中心中都有成員的 DAG。
成員位于兩個數(shù)據(jù)中心中的數(shù)據(jù)庫可用性組
跨多個數(shù)據(jù)中心擴展 DAG 時,應對其進行相應設計,使大多數(shù) DAG 成員都在主數(shù)據(jù)中心,或者,在每個數(shù)據(jù)中心都具有相同數(shù)量的成員時,使主數(shù)據(jù)中心承載見證服務器。此設計可保證在主數(shù)據(jù)中心提供服務,即使兩個數(shù)據(jù)中心之間的網(wǎng)絡連接發(fā)生故障時也如此。不過,這還意味著主數(shù)據(jù)中心發(fā)生故障時,將失去對第二個數(shù)據(jù)中心中的成員的仲裁。
還可能會發(fā)生部分數(shù)據(jù)中心故障。如果主數(shù)據(jù)中心因失去足夠的功能而阻礙有效的服務和管理,則應執(zhí)行數(shù)據(jù)中心切換來激活第二個數(shù)據(jù)中心。激活過程涉及管理員將部分操作狀態(tài)的幸存服務器配置為停止服務。然后可以在第二個數(shù)據(jù)中心繼續(xù)激活。這樣可以防止同時嘗試和操作兩組服務。
由于仲裁丟失,第二個數(shù)據(jù)中心中的 DAG 成員將無法自動聯(lián)機。因此,在第二個數(shù)據(jù)中心中激活郵箱服務器還需要一個強制 DAG 成員服務器創(chuàng)建仲裁的步驟,這時將從 DAG 內部刪除(僅臨時刪除)故障數(shù)據(jù)中心中的服務器。這可以提供一個穩(wěn)定的部分服務解決方案,能夠體驗某種級別的其他故障,并能繼續(xù)正常工作。
![]() |
---|
能夠體驗其他故障的一個先決條件是 DAG 至少有四個成員,并且這四個成員分布在兩個 ActiveDirectory 站點之間(即每個數(shù)據(jù)中心至少有兩個成員)。 |
這是用于在第二個數(shù)據(jù)中心中重新建立郵箱角色功能的基本過程。激活第二個數(shù)據(jù)中心中的其他角色不涉及對第二個數(shù)據(jù)中心中受影響服務器的顯式操作。相反,第二個數(shù)據(jù)中心中的服務器將成為通常由主數(shù)據(jù)中心承載的那些服務的服務端點。例如,通常在主數(shù)據(jù)中心駐留的用戶可以使用 https://mail.contoso.com/owa 連接到 OutlookWebApp。在數(shù)據(jù)中心發(fā)生故障之后,這些服務端點作為切換操作的一部分移動到第二個數(shù)據(jù)中心中的端點。在切換操作過程中,主數(shù)據(jù)中心的服務端點將重新定向到第二個數(shù)據(jù)中心中的相同服務的備用 IP 地址。在切換過程中,這可以減少必須對 ActiveDirectory 中存儲的配置信息進行更改的次數(shù)。通常,可以通過兩種方法來完成此步驟:
- 使用 DNS 記錄更新;或
- 使用全局 DNS 和負載平衡器 (LB) 重新配置啟用和禁用備用 IP 地址,從而在數(shù)據(jù)中心之間移動服務。
- 必須建立一個測試解決方案的策略。必須將其包括在 SLA 中。定期驗證部署是保證部署不隨時間的推移而降級的唯一方式。
認真完成這些規(guī)劃步驟對成功進行數(shù)據(jù)中心切換有著立竿見影的效果。例如,糟糕的命名空間設計可能會導致證書出現(xiàn)問題,不正確的證書配置則可能會阻止用戶訪問服務。
在驗證部署之后,我們建議明確記錄直接影響成功進行數(shù)據(jù)中心切換的所有配置部分。此外,還應圍繞這些部署部分加強更改管理過程。
有關數(shù)據(jù)中心切換(包括激活輔助數(shù)據(jù)中心和重新激活發(fā)生故障的(主)數(shù)據(jù)中心)的詳細信息,請參閱數(shù)據(jù)中心切換。