規劃高可用性及站台恢復

適用於：Exchange Server 2013

在規劃階段期間，系統建構者、系統管理員和其他關鍵專案關係人應該識別部署的企業需求以及架構需求；尤其是關於高可用性和站台恢復的需求。

部署這些功能時必須符合一般需求，以及也必須符合的硬體、軟體和網路需求。

一般需求

部署資料庫可用性群組 (DAG) 和建立信箱資料庫副本之前，請確認符合下列整體系統建議：

• 必須執行網域名稱系統 (DNS)。 理想的情況是，DNS 伺服器應接受動態更新。 如果 DNS 伺服器不接受動態更新，則必須爲每個 Exchange 伺服器建立 DNS 主機 (A) 記錄。 否則，Exchange 無法正常運作。
• DAG 中的每個信箱伺服器都必須是相同網域中的成員伺服器。
• 不支援將同時也是目錄伺服器的 Exchange 2013 信箱伺服器新增到 DAG。
• 您指派給 DAG 的名稱必須是 15 個字元或以下的有效、可用和唯一的電腦名稱。

硬體需求

一般而言，DAG 或信箱資料庫副本沒有專屬的特殊硬體需求。 使用的伺服器必須符合 Exchange 2013 必要條件 和 Exchange 2013 系統需求主題中所述的所有需求。

儲存需求

一般而言，DAG 或信箱資料庫副本沒有專屬的特殊儲存需求。 DAG 不需要也不使用叢集受管理的共用儲存。 只有當 DAG 設定為使用使用 Exchange 2013 內建之協力廠商複寫 API 的解決方案時，才支援叢集管理的共用儲存體在 DAG 中使用。

軟體需求

DAG 可在 Exchange 2013 Standard 與 Exchange 2013 Enterprise 中使用。 此外，一個 DAG 中可以包含執行 Exchange 2013 Standard 和 Exchange 2013 Enterprise 之伺服器的混合。

DAG 的每個成員也都必須執行相同的作業系統。 Windows Server 2008 R2、Windows Server 2012 和 Windows Server 2012 R2 作業系統都支援 Exchange 2013。 特定 DAG 的所有成員皆須執行相同作業系統。 只有執行 Exchange 2013 Service Pack 1 或更新版本的 DAG 成員才支援 Windows Server 2012 R2。

除了符合安裝 Exchange 2013 的必要條件之外，還有必須符合的作業系統需求。 DAG 使用 Windows 容錯移轉叢集技術，因此需要 Windows Server 2008 R2 的 Enterprise 或 Datacenter 版本，或者 Windows Server 2012 或 Windows Server 2012 R2 作業系統的 Standard 或 Datacenter 版本。

網路要求

每個 DAG 和 DAG 成員都有必須符合的特定網路需求。 每個 DAG 都必須有單一 MAPI 網路，DAG 成員會使用此網路與其他伺服器通訊 (例如，其他 Exchange 2013 伺服器或目錄伺服器) ，以及零或多個 複寫網路，這些網路是記錄傳送和植入專用的網路。

在舊版 Exchange 中，我們為 DAG 至少建議兩個網路 (一個 MAPI 網路和一個複寫網路)。 在 Exchange 2013 中則可支援多個網路，但我們的建議取決於您的實體網路拓撲。 如果您在 DAG 成員之間有多個實體網路彼此實際分開，則使用個別的 MAPI 和複寫網路可提供更多備援。 如果多個網路實際上並不完全分開，但仍匯聚至單一實體網路 (例如，單一 WAN 連結)，則建議使用單一網路 (最好是 10 GB 乙太網路) 來同時處理 MAPI 和複寫流量。 這種方法可為網路和網路路徑提供簡易性。

設計 DAG 的網路基礎結構時，請考慮下列因素：

• DAG 的每個成員都必須至少有一個能够與其他所有 DAG 成員進行通訊的網路介面卡。 如果您使用單一網路路徑，則建議您至少使用 1 GB 乙太網路，最好是 10 GB 乙太網路。 此外，在每個 DAG 成員中使用單一網路介面卡時，建議您根據單一網路介面卡和路徑來設計整體解決方案。

• 在每個 DAG 成員中使用兩個網路介面卡可提供一個 MAPI 網路和一個複寫網路，具有複寫網路的備援以及下列復原行為：

  • 如果失敗影響 MAPI 網路，則會發生伺服器容錯移轉 (假設有狀況良好的信箱資料庫複本可) 啟動。

  • 如果失敗影響複寫網路，如果 MAPI 網路不受失敗影響，即使 MAPI 網路的 ReplicationEnabled 屬性設定為 False，記錄傳送和植入作業也會還原為使用 MAPI 網路。 當失敗的複寫網路還原至正常狀態，並準備好繼續進行記錄傳送和植入作業時，您必須以手動的方式切換至複寫網路。 要將複寫作業從 MAPI 網路變更至還原的複寫網路，您可利用 Suspend-MailboxDatabaseCopy 和 Resume-MailboxDatabaseCopy Cmdlet 來暫停及繼續連續複寫作業，或是重新啟動 Microsoft Exchange 複寫服務。 我們建議您使用暫停和繼續等操作，以免因重新啟動 Microsoft Exchange 複寫服務，而出現短暫中斷的情形。

• 每個 DAG 成員的網路數量必須相同。 例如，如果您計畫在一個 DAG 成員中使用單一網路介面卡，則 DAG 的所有成員也必須使用單一網路介面卡。

• 每個 DAG 都必須只能有一個 MAPI 網路。 MAPI 網路必須提供對其他 Exchange 伺服器和其他服務 (例如 Active Directory 和 DNS) 的連線。

• 您可以視需要新增更多複寫網路。 您也可以使用網路介面卡協力作業或類似的技術，以避免個別網路卡成為單一失敗點。 不過，即使使用小組，這項技術也不會防止網路本身成為單一失敗點。 再者協力作業會無謂增加對 DAG 的複雜性。

• 每個 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 2013，則所有伺服器角色都可以對使用 IPv6 位址的裝置、伺服器及用戶端傳送和接收資料。

• 自動私人 IP 定址 (APIPA) 是 Windows 的功能，可在網路上沒有動態主機設定通訊協定 (DHCP) 伺服器可用時自動指派 IP 位址。 DAG 或 Exchange 2013 不支援使用 APIPA 位址 (包含從 APIPA 位址範圍手動指派的位址)。

DAG 名稱和 IP 位址需求

建立期間會為每個 DAG 指定一個唯一名稱，並指派一或多個靜態 IP 位址，或設定為使用 DHCP。 不論您使用的是靜態或動態指派的位址，指派給 DAG 的任何 IP 位址都必須位於 MAPI 網路上。

每個在 Windows Server 2008 R2 或 Windows Server 2012 上執行的 DAG 至少需要 MAPI 網路上的一個 IP 位址。 當 MAPI 網路擴充到多個子網時，DAG 需要更多 IP 位址。 在 Windows Server 2012 R2 上執行的 DAG 若沒有叢集管理存取點，則不需要 IP 位址。

下圖說明一個 DAG，其中 DAG 中所有節點的 MAPI 網路都位於相同的子網路上。

在此範例中，每個 DAG 成員中的 MAPI 網路位於 172.19.18.*x_ 子網上。 因此，DAG 在該子網路上需要單一 IP 位址。

下圖說明具有 MAPI 網路的 DAG，該網路可跨兩個子網延伸：172.19.18.*x_ 和 172.19.19.*x_。

在此範例中，每個 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 位址。

DAG 的網路介面卡組態

每個網路介面卡都必須根據其預定的用途適當地進行設定。 用於 MAPI 網路之網路介面卡的設定方式與用於複寫網路之網路介面卡的設定方式不同。 除了正確設定每個網路介面卡以外，您還必須在 Windows 中設定網路連線順序，讓 MAPI 網路在連線順序的最上方。 如需如何修改網路連線順序的詳細步驟，請參閱修改通訊協定繫結與網路提供者順序。

MAPI 網路介面卡組態

預定用於 MAPI 網路的網路介面卡應以如下表中所述的方式來設定。

MAPI 網路介面卡的 TCP/IP v4 內容設定如下：

• DAG 成員之 MAPI 網路的 IP 位址可以手動指派，或設定為使用 DHCP。 如果使用 DHCP，則建議為伺服器的 IP 位址使用持續保留。
• MAPI 網路通常會使用預設閘道，但是不一定要使用。
• 至少必須設定一個 DNS 伺服器位址。 建議使用多個 DNS 伺服器以提供備援。
• 不應該選擇 [在 DNS 中登錄這個連線的位址]]核取方塊。

複寫網路介面卡組態

預定用於複寫網路的網路介面卡應以如下表中所述的方式來設定。

複寫網路介面卡的 TCP/IP v4 內容設定如下：

• DAG 成員之複寫網路的 IP 位址可以手動指派，或設定為使用 DHCP。 如果使用 DHCP，則建議為伺服器的 IP 位址使用持續保留。
• 複寫網路通常沒有預設閘道，如果 MAPI 網路有預設閘道，則其他網路都不應有預設閘道。 您可以使用能夠在複寫網路間進行路由傳送的閘道位址，在其他 DAG 成員上對應網路的持續、靜態路由，來設定複寫網路上網路流量的路由。 不符合此路由的其他所有流量將由 MAPI 網路的介面卡上設定的預設閘道來處理。
• 不應該設定 DNS 伺服器位址。
• The Register this connection's addresses in DNS check box shouldn't be selected.

見證伺服器需求

「見證伺服器」是 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 會識別作為提供高可用性和站台恢復之解決方案設計基礎的兩個特定元素：復原時間目標和復原點目標。 這兩個值會以分鐘為測量單位。 復原時間目標是還原服務所需的時間。 復原點目標是指在復原作業完成之後，資料目前的狀況。 SLA 也可定義為在主要資料中心的問題解決後還原至完整服務。

解決方案的建構者和系統管理員也會識別哪一組使用者需要站台恢復保護，並決定多站台解決方案是主動/被動或主動/主動組態。 在主動/被動組態中，待命資料中心通常不主控使用者。 在主動/主動組態中，兩個位置都主控使用者，而解決方案中資料庫總數的特定百分比在另一個資料中心具有慣用的主動位置。 當一個資料中心的使用者服務失敗時，會在其他資料中心啟動這些使用者。

建構適當的 SLA 時，通常需要回答下列基本問題：

• 主要資料中心失敗後所需的服務等級為何？
• 使用者需要其資料，還是只需要郵件服務？
• 資料需求的急迫性如何？
• 必須支援多少使用者？
• 使用者將如何存取其資料？
• 待命資料中心啟動 SLA 為何？
• 服務如何移回主要資料中心？
• 資源是否為站台恢復解決方案所專用？

您可以藉由回答這些問題，著手為您的郵件解決方案擬定站台恢復設計。 從站台失敗進行復原的核心需求是建立適當的解決方案，將必要的資料移至主控備份郵件服務的備份資料中心。

憑證規劃

在單一資料中心部署 DAG 時，並沒有針對憑證的唯一或特殊設計考量。 不過，如果站台恢復組態中的 DAG 遍佈多個資料中心時，有一些與憑證相關的特定考量。 一般而言，您的憑證設計將取決於使用中的用戶端，以及使用憑證的其他應用程式的憑證需求。 但是，您應該遵守一些關於憑證類型和數目的特定建議和最佳作法。

作為最佳作法，您應該最小化使用的 Exchange 伺服器與反向 Proxy 伺服器憑證數量。 建議您針對每個資料中心的這些所有服務使用單一憑證。 這個方法可以將所需的憑證數目減到最少，同時降低解決方案的成本和和複雜性。

針對 Outlook 無所不在用戶端，建議您在每個資料中心使用單一主體別名 (SAN) 憑證，並在憑證中加入多個主機名稱。 若要在資料庫、伺服器或資料中心轉換後確保 Outlook 無所不在的連線能力，您必須在每個憑證上使用相同的憑證主體名稱，並在 Outlook 中以 Microsoft 標準表單 (msstd) 中相同的主體名稱來設定 Active Directory Provider Configuration 物件。 例如，如果您使用憑證主體名稱 mail.contoso.com，則設定屬性的方式如下。

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

某些與 Exchange 整合的應用程式有可能需要使用更多憑證的特定憑證需求。 Exchange 2013 可與 Office Communications Server (OCS) 共存。 OCS 需要 1024 位元或更大的憑證，這些憑證會使用 OCS 伺服器名稱作為憑證主體名稱。 因為使用 OCS 伺服器名稱作為憑證主體名稱會使 Outlook Anywhere 無法正常運作，所以您必須針對 OCS 環境使用額外和個別的憑證。

網路規劃

除了每個 DAG 必須符合的特定網路需求，以及屬於 DAG 成員的每部伺服器，還有一些網站復原設定特定的需求和建議。 與所有 DAG 一樣，不論是在單一站台或多個站台中部署 DAG 成員，在 DAG 成員之間往返傳回網路延遲時間都不得大於 500 毫秒。 此外，針對遍佈多個站台的 DAG 還有建議的特定組態設定：

• MAPI 網路應該與複寫網路隔離：Windows 網路原則、Windows 防火牆原則或路由器存取控制清單 (ACL) 應該用來封鎖 MAPI 網路與複寫網路之間的流量。 這種組態對於避免發生網路活動訊號干擾是必要的。

• 用戶端面向 DNS 記錄的存留時間 (TTL) 值為 5 分鐘：用戶端體驗的停機時間量不只取決於發生切換的速度，也取決於 DNS 複寫發生的速度，以及用戶端對更新 DNS 資訊的查詢。 內部和外部 DNS 伺服器中所有 Exchange 用戶端服務的 DNS 記錄，包括Outlook Web App、Exchange ActiveSync、Exchange Web 服務、Outlook Anywhere、SMTP、POP3 和 IMAP4，都應該設定為 5 分鐘。

• 使用靜態路由來設定跨複寫網路的聯機能力：若要在每個複寫網路介面卡之間提供網路連線，請使用永續性靜態路由。 此程式是在使用靜態 IP 位址時，于每個 DAG 成員上執行的快速且一次性的設定。 如果使用 DHCP 取得複寫網路的 IP 位址，您還可以使用它來為複寫指派靜態路由，進而簡化組態處理程序。

一般站台恢復規劃

除了以上所列針對高可用性的需求之外，此處有一些用於在站台恢復組態中部署 Exchange 2013 的建議 (例如，將 DAG 延伸至多個資料中心)。 您在規劃階段中所做的規劃，會對站台恢復解決方案的成功與否造成直接的影響。 例如，命名空間設計不良會造成憑證發生問題，而不正確的憑證組態可能會讓使用者無法存取服務。

若要讓啟動另一個資料中心的時間縮到最短，並讓第二個資料中心主控失敗資料中心的服務端點，必須完成適當的規劃。 以下為範例：

• 您必須充分了解並記錄站台恢復解決方案的 SLA 目標。

• 第二個資料中心的伺服器必須有足夠的容量，才可以主控結合兩個資料中心的所有使用者。

• 第二個資料中心必須啟用主要資料中心提供的所有服務 (除非該服務並未包含在站台恢復 SLA 中)。 這些服務包括 Active Directory、網路基礎結構 (例如 DNS 或 TCP/IP) 、電話語音服務 (使用中) ，以及月臺基礎結構 (例如電源或冷卻) 。

• 若要讓某些服務能夠為失敗資料中心的使用者提供服務，必須為這些服務設定正確的伺服器憑證。 某些服務不允許執行個體 (例如 POP3 和 IMAP4) 而僅允許使用單一憑證。 在這些情況下，憑證必須是包含多個名稱的 SAN 憑證，或者多個名稱必須足夠相似，可當做萬用字元憑證使用 (假設組織的安全性原則允許使用萬用字元憑證)。

• 您必須在第二個資料中心定義所需的服務。 例如，如果第一個資料中心在不同的傳輸伺服器上有三個不同的 SMTP 目的地，則必須在第二個資料中心定義適當的設定，才能啟用至少一個 (，如果不是所有三個) 傳輸伺服器來裝載工作負載。

• 所需的網路組態必須就緒，才能支援資料中心轉換。 這項需求可能表示確定負載平衡組態已就緒、已設定全域 DNS，且已啟用網際網路連線，並已設定適當的路由。

• 您必須了解啟用資料中心轉換所需之 DNS 變更的策略。 您必須定義並記錄特定的 DNS 變更 (包括其 TTL 設定) 以有效支援 SLA。

• 您也必須建立用於測試解決方案的策略，並作為因素納入 SLA 中。 定期驗證部署是確保部署的品質和可行性不會隨時間而降低的唯一方式。 驗證部署之後，建議您明確記錄組態的哪些部分會直接影響解決方案成功與否。 此外，建議您增強這些部署區段週邊的變更管理程序。