規劃高可用性和月臺復原能力

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

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

一般需求

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

• 必須執行網域名稱系統 (DNS)。 理想的情況是，DNS 伺服器應接受動態更新。 如果 DNS 伺服器不接受動態更新，則必須爲每個 Exchange 伺服器建立 DNS 主機 (A) 記錄。 否則，Exchange 無法正常運作。

• DAG 中的每個信箱伺服器都必須是相同網域中的成員伺服器。

• 不支援將同時是目錄伺服器的 Exchange 信箱伺服器新增至 DAG。

• 您指派給 DAG 的名稱必須是 15 個字元或以下的有效、可用和唯一的電腦名稱。

硬體需求

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

儲存需求

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

軟體需求

DAG 的每個成員都必須執行相同的作業系統。 Windows Server 2012、Windows Server 2012 R2 和 Windows Server 2016 支援 2016 Exchange Server。 Windows Server 2019 和 Windows Server 2022 作業系統支援 Exchange Server 2019。 在特定 DAG 內，所有成員都必須執行相同的支援作業系統。

除了符合安裝Exchange Server的必要條件之外，還必須符合作業系統需求。 DAG 使用 Windows 容錯移轉叢集技術，因此需要標準或資料中心版本的 Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019 或 Windows Server 2022 作業系統。

網路要求

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

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

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

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

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

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

  • 如果發生影響複寫網路的失敗，如果 MAPI 網路不受失敗影響，記錄傳送和植入作業將會還原成使用 MAPI 網路，即使 MAPI 網路的 ReplicationEnabled 屬性設定為 False 也一樣。 當失敗的複寫網路還原至正常狀態，並準備好繼續進行記錄傳送和植入作業時，您必須以手動的方式切換至複寫網路。 要將複寫作業從 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 Server，所有伺服器角色都可以將資料傳送至使用 IPv6 位址的裝置、伺服器和用戶端，並從中接收資料。

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

DAG 名稱和 IP 位址需求

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

在 Windows Server 2012 上執行的每個 DAG 在 MAPI 網路上至少需要一個 IP 位址。 當 MAPI 網路遍佈多個子網路時，DAG 需要額外的 IP 位址。 在未建立叢集系統管理存取點的 Windows Server 2012 R2、Windows Server 2016、Windows Server 2019 或 Windows Server 2022 上執行的 DAG 不需要 IP 位址。

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

DAG 和 MAPI 網路位於相同的子網路上

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

下一個圖說明具備 MAPI 網路且延伸至兩個子網路的 DAG：172.19.18. x 和 172.19.19. x。

DAG 和 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 位址。

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 Server可以與 Office Communications Server (OCS) 共存。 OCS 需要 1024 位元或更大的憑證，這些憑證會使用 OCS 伺服器名稱作為憑證主體名稱。 使用 OCS 伺服器名稱作為憑證主體名稱會使 Outlook 無所不在無法正確運作，因此您需要在 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 Services、Outlook Anywhere、SMTP、POP3 和 IMAP4 的 Outlook 網頁版 (，都應該設定為 5 分鐘。

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

一般站台恢復規劃

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

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

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

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

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

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

• 您必須在第二個資料中心定義所需的服務。 例如，如果在第一個資料中心的不同傳輸伺服器上有三個不同的 SMTP URL，則必須在第二個資料中心定義適當的組態，以便至少啟用一個 (如果不啟用全部三個) 傳輸伺服器來主控工作負載。

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

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

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