Exchange 2016異地容災系列-環境準備（一）

咱們在使用Exchange系統時，都很是想要一個天天可靠而又可用的郵件系統。對於許多公司而言，郵件系統是咱們業務連續性計劃的一部分，而且在設計郵件服務部署的時候都應考慮站點恢復。基本上，許多站點恢復解決方案都涉及在第二個數據中心部署。
下面是官方給出的一些前期規劃：

最終，DAG 的整體設計（其中包括 DAG 的成員數和郵箱數據庫副本數）將取決於每一個組織的包括各類故障情形的恢復服務級別協議 (SLA)。在規劃階段中，解決方案的結構設計師和管理員將肯定部署要求，尤爲是站點恢復要求。他們肯定要使用的位置和所需的恢復 SLA 目標。SLA 將肯定兩個特定的元素，這兩個元素應是設計高可用性和站點恢復解決方案的基礎：恢復時間目標和恢復點目標。這兩個值都以分鐘爲單位度量。恢復時間目標是指恢復服務所需的時間。恢復點目標指在完成恢復操做以後數據的新舊程度。還能夠將 SLA 定義爲在解決主數據中心的問題以後，將還原爲完整服務。
解決方案的結構設計師和管理員還將肯定哪一組用戶須要站點恢復保護，並肯定多網站解決方案是主動/被動配置仍是主動/主動配置。在主動/被動配置中，備用數據中心中一般不駐留任何用戶。在主動/主動配置中，用戶同時駐留在兩個位置，在該解決方案中，數據庫總數中有必定的百分比在第二個數據中心的首選活動位置。當一個數據中心的用戶的服務出現故障時，將在另外一數據中心中激活這些用戶。
構造適當的 SLA 一般須要考慮如下基本問題：

• > 主數據中心出現故障後，須要什麼級別的服務？
• > 用戶是須要數據服務仍是僅須要郵件服務？
• > 急需數據的程度怎樣？
• > 必須支持多少用戶？
• > 用戶如何訪問自已的數據？
• > 什麼是備用數據中心激活 SLA？
• > 服務如何移回主數據中心？
• > 資源是否專用於站點恢復解決方案？

經過回答這些問題，咱們能夠設計出一個郵件解決方案構建站點恢復設計的大體框架。從站點故障進行恢復的核心要求是：建立解決方案，將必要的郵件數據放入承載備用郵件服務的備用數據中心。

在本系列博文中，咱們採用的是創建跨站點的DAG實現郵件系統的異地容災，即假設我公司總部數據中心在北京、上海也有一個數據中心，用來作Exchange郵件系統的數據備份容災。
當北京數據中心發生災難時，經過手工的方式啓動上海的容災服務器，從而來實現異地容災。RTO小於1小時，RPO小於15分鐘。

下表是我測試環境的網絡信息，所有爲虛擬機：

服務器名稱	操做系統	IP地址	網關	DNS	角色
BJAD01	windows server 2012 R2	10.1.1.1	10.1.1.10	10.1.1.1	北京域控01
BJEX01	windows server 2012 R2	10.1.1.2	10.1.1.10	10.1.1.1	北京Exchange01
BJEX02	windows server 2012 R2	10.1.1.4	10.1.1.10	10.1.1.1	北京Exchange02
SHAD01	windows server 2012 R2	172.16.1.1	172.16.1.10	10.1.1.1	上海域控01
SHEX01	windows server 2012 R2	172.16.1.2	172.16.1.10	172.16.1.1	上海Exchange01
SHEX02	windows server 2012 R2	172.16.1.3	172.16.1.10	172.16.1.1	上海Exchange02
Router	windows server 2012 R2	10.1.1.10 172.16.1.10	\	\	路由器

環境拓撲信息以下：

環境準備到此，下一篇咱們建立配置路由器！