共用方式為

Exchange 2019 慣用架構

  • 發行項

在內部部署客戶的每個新Exchange Server版本中，我們會更新慣用架構，並討論希望客戶注意的變更。 Exchange Server 2013 為我們帶來新式 Exchange 歷程記錄中的第一個慣用架構，接著為 2016 Exchange Server重新整理，為 2016 版隨附的變更提供精簡。 在 Exchange Server 2019 的這項更新中，我們將逐一查看先前的 PA，以利用新技術和改進功能。

慣用的架構

PA 是Exchange Server工程小組的最佳做法建議，我們認為這是內部部署環境中Exchange Server 2019 的最佳部署架構。

雖然 Exchange 2019 為內部部署提供各種不同的架構選擇，但這裡所討論的架構是最仔細探討的架構。 雖然還有其他支援的部署架構，但這不是我們建議的做法。

遵循 PA 可協助客戶成為具有類似Exchange Server部署之組織社群的成員。 此策略可讓您更輕鬆地共用知識，並針對未預期的情況提供更快速的回應。 我們自己的支援組織知道Exchange Server PA 部署的外觀，並防止他們花費冗長的週期學習及瞭解客戶的高度自訂環境，然後再與他們合作以達成支援案例解決。

PA 的設計考慮了數個商務需求，例如架構能夠滿足的需求：

  • 同時包含資料中心內的高可用性，以及資料中心之間的月臺復原能力

  • 支援每個資料庫的多個複本，因而允許快速啟用

  • 降低傳訊基礎結構的成本

  • 藉由優化失敗網域並降低複雜度來提高可用性

PA 的特定規範本質表示並非每個客戶都能逐字部署。 例如，並非所有客戶都有多個資料中心。 有些客戶可能有不同的商務需求或必須遵守的內部原則，因此需要不同的部署架構。 如果您分成這些類別，而且想要部署 Exchange 內部部署，則盡可能遵守 PA 仍有優點，而且只有在您的需求或原則強制您有所不同時才會偏離。 或者，您也可以一律考慮 Microsoft 365 或Office 365，您不再需要部署或管理大量伺服器。

PA 會在必要時移除複雜性和備援，以將架構驅動至可預測的復原模式：當失敗發生時，會啟動受影響資料庫的另一個複本。

PA 涵蓋下列四個重點領域：

  1. 命名空間設計

  2. 網站復原資料中心配對設計

  3. 伺服器設計

  4. 資料庫可用性群組設計

在 2019 Exchange Server，我們對於 2016 Exchange Server慣用架構的四個類別中，有三個類別沒有任何變更。 命名空間設計、資料中心設計和 DAG 設計的區域不會收到任何重大變更。 我們很高興客戶部署密切遵循 Exchange Server 2016 PA，併發現不需要偏離這些區域中的建議。

Exchange Server 2019 PA 中最值得注意的變更，著重于伺服器設計領域，因為有一些全新且令人興奮的技術。

命名空間設計

在 Exchange Server 2016 的命名空間規劃和負載平衡原則文章中，Smith Smith IV 概述 Exchange 2016 提供的各種設定選項，而這些概念會繼續適用于 2019 Exchange Server。 針對命名空間，選擇是部署 系結的命名空間 ， (讓使用者偏好在特定資料中心) 外操作，或使用 未系結的命名空間 (讓使用者連線到任何資料中心，而不需要喜好設定) 。

建議的方法是使用未系結的模型，針對月臺復原資料中心配對部署每個用戶端通訊協定的單一 Exchange 命名空間 (其中假設每個資料中心代表自己的 Active Directory 網站 - 請參閱下列) 的詳細資料。 例如：

  • 針對自動探索服務：autodiscover.contoso.com

  • 針對 HTTP 用戶端：mail.contoso.com

  • 針對 IMAP 用戶端：imap.contoso.com

  • 針對 SMTP 用戶端：smtp.contoso.com

在不使用會話親和性的第 7 層組態中，每個 Exchange 命名空間會在兩個資料中心之間進行負載平衡，導致 50% 的流量在資料中心之間進行 Proxy 處理。 流量會透過迴圈配置資源 DNS、異地 DNS 或其他類似的解決方案，平均分散到網站復原配對中的資料中心。 從我們的觀點來看，較簡單的解決方案最不復雜且更容易管理，因此我們的建議是使用迴圈配置資源 DNS。

我們對於客戶的一個警告是，確保您為任何與 Exchange 架構相關聯的 DNS 記錄指派低 TTL (存留時間) 值。 如果您使用迴圈配置資源 DNS 時發生完整的資料中心中斷，您必須維持快速更新 DNS 記錄的能力。 您必須從離線資料中心移除 IP 位址，以免傳回 DNS 查詢的 IP 位址。 例如，如果您的 DNS 記錄具有 24 小時的較長 TTL 值，則下游 DNS 快取最多可能需要一天的時間才能正確更新。 如果您未執行此步驟，您可能會發現某些用戶端無法正確轉換至剩餘資料中心內仍然可用的 IP 位址。 當您先前離線的資料中心復原並準備好再次裝載服務時，別忘了將 IP 位址新增回您的 DNS 記錄。

Office Online Server伺服器陣列需要資料中心親和性，因此每個資料中心都會使用第 7 層的負載平衡器來部署命名空間，並透過以 Cookie 為基礎的持續性來維護會話親和性。

範例 Exchange 2019 組織架構配置。

如果您的環境中有多個月臺復原資料中心配對，則必須決定要有單一全球命名空間，還是要使用區域命名空間來控制每個特定資料中心的流量。 您的決策取決於您的網路拓撲，以及使用未系結模型的相關成本;例如，如果您的資料中心位於北美洲和南非，這些區域之間的網路連結可能不僅成本高昂，還可能會有高延遲，這可能會造成使用者的困難和操作問題。 在此情況下，針對每個區域部署具有個別命名空間的系結模型是合理的。 不過，地理 DNS 等選項可讓您部署單一統一命名空間，即使您有昂貴的網路連結也一樣;geo-DNS 可讓使用者根據其用戶端的 IP 位址，導向至最接近的資料中心。

網站復原資料中心配對設計

若要達到高可用 性和 月臺復原架構，您必須有兩個或多個在理想情況下連線良好的資料中心 (，您想要低的來回網路延遲，否則複寫和用戶端體驗會對) 造成負面影響。 此外，資料中心應該透過不同作業貨運公司所提供的備援網路路徑來連線。

雖然我們支援跨多個資料中心延展 Active Directory 月臺，但針對 PA，我們建議每個資料中心都是自己的 Active Directory 月臺。 原因有兩個：

  1. 只有當 DAG 的成員位於多個 Active Directory 網站時，才能透過Exchange Server 和安全網中的陰影備援來傳輸月臺復原Exchange Server。

  2. Active Directory 已 發佈指引 ，指出當子網之間的來回延遲大於 10 毫秒時，子網應該放在不同的 Active Directory 月臺中。

伺服器設計

在 PA 中，所有伺服器都是實體伺服器，並使用本機連結的儲存體。 部署實體硬體而不是虛擬化硬體有兩個原因：

  1. 伺服器會調整為在最差失敗模式期間使用 80% 的資源。

  2. 虛擬化會稍微降低效能，並增加額外的管理和複雜度層級，這會導入不會增加價值的其他復原模式，特別是因為Exchange Server原生提供相同的功能。

商用伺服器

商用伺服器平臺用於 PA。 目前的商用平臺包括：

  • 2U，具有最多 48 個實體處理器核心的雙重通訊端伺服器 (從 Exchange 2016 中的 24 個核心增加)

  • 最多 256 GB 的記憶體 (從 Exchange 2016 中的 192 GB 增加)

  • 電池支援的寫入快取控制器

  • 伺服器底座內有 12 個以上的磁片磁碟機機架

  • 能夠混合傳統旋轉的磁片 (HDD) 和固態儲存體， (SSD) 相同的底座內。

縮放理論

請務必注意，即使我們已在 2019 年Exchange Server增加允許的處理器和記憶體容量，Exchange Server PG 的建議仍會保持向外延展，而不是擴大。 相應放大與相應增加表示我們更想要看到您部署的伺服器數目較多，且每部伺服器的資源稍微較少，而不是使用最大資源並填入大量信箱的更少量密集伺服器。 藉由在伺服器內尋找合理的信箱數目，您可以減少任何計劃性或非計劃性中斷的影響，並降低探索其他系統瓶頸的風險。

系統資源的增加不應導致假設您會在 2019 年 Exchange Server中看到線性效能提升，並在將允許的資源上限與 Exchange 2016 允許的最大資源進行比較時看到。 每個新版本的 Exchange 都會帶來新的進程和更新，進而讓您難以比較目前的版本與舊版。 判斷您的伺服器設計時，請遵循 Microsoft 的任何和所有大小調整指引。

儲存體

視信箱數目、信箱大小和伺服器的資源延展性而定，其他磁片磁碟機機架可能會直接連接每部伺服器。

每部伺服器都裝載作業系統、Exchange 二進位檔、通訊協定/用戶端記錄和傳輸資料庫的單一 RAID1 磁片配對。

剩餘的儲存體會設定為 JBOD (只有一堆磁片) 。 請注意，某些硬體儲存體控制器可能需要將每個磁片設定為單一磁片 RAID0 群組，才能使用寫入快取。 請洽詢您的硬體製造商，以確認您的系統有適當的設定，保證會使用寫入快取。

Exchange Server 2019 PA 的新功能是針對先前提及的 RAID1 磁片配對上尚未找到的所有專案，提供兩種儲存體類別的建議。

傳統儲存類別

這個儲存類別包含Exchange Server資料庫檔案和Exchange Server交易記錄檔。 這些磁片是大型容量 7.2 K RPM 串列連接 SCSI (SAS) 磁片。 雖然 SATA 磁片也可供使用，但我們觀察到使用 SAS 對等專案時，IO 會更好，且每年失敗率也較低。

為確保每個磁片的容量和 IO 盡可能有效率地使用，每個磁片最多會部署四個資料庫複本。 一般執行時間複製配置可確保每個磁片的單一作用中資料庫複本不超過一個。

傳統存放磁片集區中至少有一個磁片會保留為熱備援。 已啟用AutoReseed，並藉由啟用熱備援並起始資料庫複本重新儲存，在磁片失敗後快速還原資料庫備援。

固態儲存類別

這個儲存類別包含 Exchange 2019 的新 MetaCache Database (MCDB) 檔案。 這些固態硬碟可能會有不同的尺寸，例如，但不限於傳統 2.5「/3.5」 SAS 連線或 M.2 PCIe 連線的磁片磁碟機。

客戶應該預期會將大約 5-10% 的額外儲存體部署為固態儲存體。 例如，如果單一伺服器預期在傳統儲存體上保留 28 TB 的信箱資料庫檔案，則也建議將額外的 1.4-2.8 TB 固態儲存體作為相同伺服器的額外儲存體。

在可能的情況下，應該以 3：1 的比例部署傳統和固態磁片。 針對伺服器內的每三個傳統磁片，將會部署單一固態磁片。 這些固態磁片會保留三個相關聯傳統磁片內所有 DB 的 MCDB。 此建議會限制固態硬碟故障可能會對系統造成的失敗網域。 當 SSD 失敗時，Exchange 2019 會使用該 SSD 為其 MCDB 將所有資料庫複本容錯移轉至另一個 DAG 節點，其中包含受影響資料庫的健康 MCDB 資源。 如果有更多的資料庫共用較少的固態硬碟磁碟機，則限制資料庫容錯移轉數目可減少影響使用者的機會。

如果固態硬碟發生失敗，Exchange 高可用性服務會嘗試將受影響的資料庫掛接在不同 DAG 節點上，其中每個受影響的資料庫仍有狀況良好的 MCDB。 如果其中一個受影響的資料庫因為某些原因而沒有狀況良好的 MCDB，則 Exchange 高可用性服務會讓本機受影響的資料庫複本繼續執行，而不會有 MCDB 的效能優勢。

例如，如果客戶要部署能夠保存 20 個磁片磁碟機的系統，則其配置可能會如下所示。

  • 2 個 HDD 用於 OS 鏡像、Exchange 二進位檔和傳輸資料庫

  • 12 個 HDD 用於 Exchange 資料庫儲存體

  • 1 個 HDD 作為自動備援備援

  • 4 個 Exchange MCDB SSD，提供 5-10% 的累計資料庫儲存體容量。

  • 客戶可以選擇新增備用 SSD 或第二個 AutoReseed 磁片磁碟機。

您可以使用下圖將此組態視覺化：

範例 Exchange 2019 Mailbox Server 磁片配置。

在上述範例中，我們有 120 TB 的 Exchange 資料庫儲存體和 7.68 TB 的 MCDB 儲存體，大約是傳統資料庫儲存空間的 6.4%。 有了此數量的 MCBD 儲存體，我們完全符合 5-10% 的指引。 10 TB 磁片磁碟機中的每一個都會保存四個資料庫複本，而每個 MCDB 磁片磁碟機會保留 12 個 MCDB。

一般儲存體設定

不論是傳統或固態，所有存放 Exchange 資料的磁片都會使用 ReFS (格式化，且已停用完整性功能) 且 DAG 已設定，讓 AutoReseed 使用 ReFS 格式化磁片：

Set-DatabaseAvailabilityGroup -Identity <DAGIdentity> -FileSystem ReFS

BitLocker 可用來加密每個磁片，藉此提供待用資料加密，並減輕資料竊取或磁片更換的疑慮。 如需詳細資訊，請 參閱在 Exchange Server 上啟用 BitLocker。

資料庫可用性群組設計

在每個具有網站復原能力的資料中心配對中，您將會有一或多個 DAG。 不建議跨兩個以上的資料中心延展 DAG。

DAG 組態

如同命名空間模型，網站復原資料中心配對內的每個 DAG 都會在未系結的模型中運作，且作用中複本平均分散在 DAG 中的所有伺服器上。 此模型：

  1. 確保在正常作業期間，會驗證每個 DAG 成員 (用戶端連線、複寫管線、傳輸等服務的完整堆疊。) 。

  2. 在失敗案例期間，盡可能將負載分散到任意數量的伺服器，因此只會以累加方式增加 DAG 內其餘成員的資源使用量。

每個資料中心都是對稱的，每個資料中心內的 DAG 成員數目相等。 這表示每個 DAG 都有偶數的伺服器，並使用見證伺服器進行仲裁維護。

DAG 是 Exchange 2019 中的基本建置組塊。 就 DAG 大小而言，具有較多參與成員節點的 DAG 可提供更多備援和資源。 在 PA 中，目標是部署具有更多成員節點的 DAG，通常從八個成員的 DAG 開始，並視需要增加伺服器數目以符合您的需求。 只有在延展性導致對現有資料庫複製配置的顧慮時，才應該建立新的 DAG。

DAG 網路設計

PA 會針對用戶端連線能力和資料複寫使用單一的非小組網路介面。 單一網路介面是所有必要專案，因為最終我們的目標是要達到標準復原模式，無論失敗 - 伺服器失敗發生或發生網路失敗，結果都相同：在 DAG 內的另一部伺服器上啟用資料庫複本。 此架構變更可簡化網路堆疊，並消除手動消除活動訊號交叉交談的需求。

見證伺服器位置

見證伺服器的位置會決定架構是否可以提供自動資料中心容錯移轉功能，或是否需要手動啟用才能在發生月臺失敗時啟用服務。

如果您的組織有第三個位置，其網路基礎結構與影響 DAG 部署所在月臺復原資料中心配對的網路失敗隔離，則建議您將 DAG 的見證伺服器部署到該第三個位置。 此設定可讓 DAG 自動將資料庫容錯移轉至另一個資料中心，以回應資料中心層級的失敗事件，無論哪一個資料中心發生中斷。

如果您的組織沒有第三個位置，請考慮將伺服器見證放在 Azure中;或者，將見證伺服器放在月臺復原資料中心配對內的其中一個資料中心。 如果您在月臺復原資料中心配對內有多個 DAG，則請將所有 DAG 的見證伺服器放在相同的資料中心 (通常是大部分使用者實際位於) 的資料中心。 此外，請確定每個 DAG 的主要 Active Manager (PAM) 也位於相同的資料中心。

Exchange Server 2019 和所有舊版都不支援使用 Windows Server 2016 容錯移轉叢集中首次引進的雲端見證功能。

資料復原

部署多個資料庫複本可實現資料復原。 在 PA 中，資料庫複本會分散到月臺復原的資料中心配對，藉此確保信箱資料受到保護，避免軟體、硬體甚至資料中心失敗。

每個資料庫都有四個複本，每個資料中心有兩個複本，這表示 PA 至少需要四部伺服器。 在這四個複本中，有三個會設定為高可用性。 第四個複本 (啟用喜好設定編號最高的複本，) 設定為延遲的資料庫複本。 由於伺服器設計，資料庫的每個複本都會與其他複本隔離，藉此減少失敗網域，並增加解決方案的整體可用性，如 DAG： Beyond the 「A」中所述。

延遲資料庫複本的目的是要針對整個系統的重大邏輯損毀的罕見事件，提供復原機制。 其不適用於個別信箱復原或信箱專案復原。

延遲的資料庫複本設定為 7 天的 ReplayLagTime。 此外，重新執行延遲管理員也可在可用性因遺失不延遲的複本而遭入侵時，為延遲的複本提供動態記錄檔播放。

透過這種方式使用延遲的資料庫複本，請務必瞭解延遲的資料庫複本不是保證的時間點備份。 延遲的資料庫複本會有可用性閾值，通常約為 90%，因為包含延遲複本的磁片因磁片失敗而遺失、延遲的複本因自動播放) 而變成 HA 複製 (，以及延遲的資料庫複本重建重新執行佇列的期間。

為了防止意外 (或惡意) 刪除專案，會使用 單一專案復原 或 就地保留 技術，並將 [刪除的專案保留 ] 視窗設定為符合或超過任何已定義專案層級復原 SLA 的值。

所有這些技術都已運作，因此不需要傳統的備份;因此，PA 會使用 Exchange 原生資料保護。

Office Online Server設計

您至少會想要在裝載 Exchange 2019 伺服器的每個資料中心內部署至少具有兩個 OOS 節點的 Office Online Server (OOS) 伺服器陣列。 每個Office Online Server應該至少有 8 個處理器核心、32 GB 的記憶體，以及至少 40 GB 的記錄檔專用空間。 Exchange 2019 信箱伺服器應設定為依賴其資料中心內的本機 OOS 伺服器陣列，以確保伺服器之間可能的最低延遲和最高的頻寬，以將檔案內容轉譯給使用者。

摘要

Exchange Server 2019 會持續改善舊版 Exchange 中所引進的投資，並引進原先在 Microsoft 365 和 Office 365 中使用的額外技術。

藉由與慣用架構一致，您將利用這些變更，並盡可能提供最佳的內部部署使用者體驗。 您將繼續擁有高度可靠、可預測且具復原性的 Exchange 部署傳統。