我们在使用Exchange系统时，都非常想要一个每天可靠而又可用的邮件系统。对于许多公司而言，邮件系统是我们业务连续性计划的一部分，并且在设计邮件服务部署的时候都应考虑站点恢复。基本上，许多站点恢复解决方案都涉及在第二个数据中心部署。
下面是官方给出的一些前期规划：

最终，DAG 的总体设计（其中包括 DAG 的成员数和邮箱数据库副本数）将取决于每个组织的包括各种故障情形的恢复服务级别协议 (SLA)。在规划阶段中，解决方案的结构设计师和管理员将确定部署要求，尤其是站点恢复要求。他们确定要使用的位置和所需的恢复 SLA 目标。SLA 将确定两个特定的元素，这两个元素应是设计高可用性和站点恢复解决方案的基础：恢复时间目标和恢复点目标。这两个值都以分钟为单位度量。恢复时间目标是指恢复服务所需的时间。恢复点目标指在完成恢复操作之后数据的新旧程度。还可以将 SLA 定义为在解决主数据中心的问题之后，将还原为完整服务。
解决方案的结构设计师和管理员还将确定哪一组用户需要站点恢复保护，并确定多网站解决方案是主动/被动配置还是主动/主动配置。在主动/被动配置中，备用数据中心中通常不驻留任何用户。在主动/主动配置中，用户同时驻留在两个位置，在该解决方案中，数据库总数中有一定的百分比在第二个数据中心的首选活动位置。当一个数据中心的用户的服务出现故障时，将在另一数据中心中激活这些用户。
构造适当的 SLA 通常需要考虑以下基本问题：

• > 主数据中心出现故障后，需要什么级别的服务？
• > 用户是需要数据服务还是仅需要邮件服务？
• > 急需数据的程度怎样？
• > 必须支持多少用户？
• > 用户如何访问自已的数据？
• > 什么是备用数据中心激活 SLA？
• > 服务如何移回主数据中心？
• > 资源是否专用于站点恢复解决方案？

通过回答这些问题，我们可以设计出一个邮件解决方案构建站点恢复设计的大致框架。从站点故障进行恢复的核心要求是：创建解决方案，将必要的邮件数据放入承载备用邮件服务的备用数据中心。

在本系列博文中，我们采用的是建立跨站点的DAG实现邮件系统的异地容灾，即假设我公司总部数据中心在北京、上海也有一个数据中心，用来做Exchange邮件系统的数据备份容灾。
当北京数据中心发生灾难时，通过手工的方式启动上海的容灾服务器，从而来实现异地容灾。RTO小于1小时，RPO小于15分钟。

下表是我测试环境的网络信息，全部为虚拟机：

环境拓扑信息如下：

环境准备到此，下一篇我们创建配置路由器！