更快更穩的 DAG 複寫運行：Exchange Server 2016 信箱資料庫備援實戰

by admin · Published 2017 年 03 月 03 日 · Updated 2017 年 04 月 03 日

更快更穩的 DAG 複寫運行：Exchange Server 2016 信箱資料庫備援實戰

現代的企業非常仰賴資訊系統，其中 Email 的使用更勝過於辦公室電話、行動電話、IM，因為若沒有它對於許多資訊工作者而言，等同停止今天的一切工作。既然 Mail Server 的持續運行是那麼重要，那麼您在當初規劃時，就必須考量到自動化備援的可行性方案。在 Exchange Server 2016 中不僅提供了高效能的信箱自動化備援解決方案，更重要的是它相當易於部署與後續的維護管理。究竟是如何辦到的呢？讓我們趕緊來動手學習一下相關的實戰內容。

一個 DAG(Database Availability Group)的運行基礎就是 Mailbox Server 角色，每一個 DAG 群組的 Mailbox Server 數量可高達 16 部來同時提供全自動化資料庫層級的相互備援機制，以保護 DAG 運行過程中，因自然災害或人為因素，導致某些伺服器或資料庫失敗的問題，像是主機硬碟損毀、網路中斷、服務失敗等等。而這一些受保護的 DAG 成員伺服器，可以是自實體主機或虛擬機器中的 Exchange Server 2016 Mailbox Server 角色。

DAG 技術的起源

Exchange Server 資料庫可用性群組((Database Availability Group，DAG))的技術最早起源於 Exchange Server 2010 版本，演化至今不僅運作效能更好與更穩，在建立與管理上也變得容易許多，其中在 DAG 網路的配置上，系統已能夠自動依據現行的網路連線狀態來完成設定，這包括了自動識別出 MAPI 與 Replication 網路並完成設定，當然管理者也可以自行手動調整。

關於 DAG 架構下的 Mailbox Server 相互備援的機制是很容易理解的。我們假設只有兩部 Mailbox Server 成員，以及一個名為 DB1 的信箱資料庫，其複寫的相互備援關係分別是 Mailbox Server 1 主動節點，以及擔任被動節點 Mailbox Server 2。當接收到用戶端所傳遞的 E-mail 並且儲存至 Mailbox Server 1 時，DAG 將會自動把這一封訊息以 Log Shipping 的方式複寫至被動節點 Mailbox Server 2，值得注意的是如果此時還有 Mailbox Server 3、Mailbox Server 4 或更多，則這些被動節點的成員，也會成為異動時的複寫目標之一。然而假設發生了在 Mailbox Server 1 中的 DB1 無法正常運作時，便會透過 Exchange 2016 DAG 容錯移轉的機制，自動導向到 Mailbox Server 2 來繼續提供用戶端進行連線存取。

請注意！在相同的 DAG 架構中，所有的 Exchange Server 成員必須是採用相同的版本，這意味著您無法將前一版的 Exchange Server 2013 和目前的 Exchange Server 2016 建構在同一個 DAG 中。

更快更穩的 DAG 複寫運行：Exchange Server 2016 信箱資料庫備援實戰

You may also like...

發佈留言

HKITBLOG

更快更穩的 DAG 複寫運行：Exchange Server 2016 信箱資料庫備援實戰