Exchange 2016高可用及容灾架构选型参考
钟云福
一 摘要
Exchange 2016作为微软最新最先进的企业级邮件系统，推出已一年多，由于其先进的架构，一脉相承的优秀办公体验，逐步被越来越多的企业所接受。嘉为科技今年已为几个中大规模的企业提供了Exchange 2016实施落地的项目，在方案确定过程中，经常需要讨论邮件架构的规划，现将规划思路和建议做了总结。
二 正文
Exchange 2016邮件角色有较大变化，将原有的前端访问，邮件传输，邮件数据库及统一沟通等角色进行了统一，不再划分CAS/HTS/MBS/UM，在Exchange 2016中，只有两种角色，一是我们不怎么用的Edge，另外一个是MBX。在MBX角色上的功能模块关系如下：
关于通讯协议，新增的MAPI over HTTP（准确来讲，应该是从Exchange 2013 SP1之后新增），提升了连接效率。好处有
n 通过使用基于 HTTP 的协议实现身份验证的未来创新。
n 在通信中断后实现更快的重新连接，因为仅需要重建 TCP 连接（而非 RPC 连接）。通信中断的示例包括：设备休眠，从有线网络更换到无线网络或移动电话网络。
关于客户端版本要求，最低的Outlook版本必须是Outlook 2010 SP2之后。同时也要意识到，Outlook 2010是不支持MAPI over HTTP技术的，只能用回原来的Outlook Anywhere。对于使用Foxmail的用户来说，会受到影响，当前的Foxmail公开版本，不支持Exchange 2013的Exchange模式，2016更不用说了。建议进行终端标准化，尽早放弃Foxmail，开始使用Outlook 2013及以上版本。
鉴于企业邮件办公的持续使用需求，要求邮件系统具有高可用性，因此针对Exchange的高可用架构设计及实现必不可少，一般的建议如下
通过部署多台邮件服务器，构建DAG群集实现高可用，数据库建立多个副本实现冗余。
一般的，用户数超过3000以上，考虑一台故障时对剩余一台的压力可能很大的风险，建议部署3台，用户数如超过10000，可考虑扩展到4台甚至更多。
对于用户访问及前端其他服务的负载均衡，在用户少且预算有限时，可考虑构建DNS轮询或者将统一访问的名称指向DAG IP，实现简单的负载平衡；如果用户数达到8000以上规模，建议更换为硬件的负载均衡器，如F5，Citrix NetScaler等。
随着企业的发展，及对信息化越来越依靠，多数据中心及容灾会被要求考虑在内，针对邮件系统来说，一般有两种适应不同场景的需求：分别是集中式和分布式
下面这张架构图是集中式部署的建议架构
其中，对于北京地区的内网用户，根据深圳和北京的专线带宽情况，可选择走专线或者走互联网进行邮件的收发。
如希望通过深圳和北京两地的数据中心，构建邮件数据的异地容灾，容灾架构建议如下：
通过建立跨站点的DAG实现邮件系统的异地容灾，在北京保存一份完整的邮件数据及服务。当深圳数据中心发生灾难时，通过手工的方式启动北京的容灾服务器。RTO小于1小时，RPO小于15分钟。
下面这张架构图是分布式部署的建议架构：
在一个Exchange组织内，建立两个站点，各部署一套DAG，数据各自存放，提供各地区的用户访问。这种方式适合分布式的管理，且两地区的邮件来往较少，两地区的专线带宽较低的一种情况。能够很好的提升用户的使用体验。
在这个基础情况下，如希望实现容灾，建议的架构是：
显而易见，做法就是为这两个DAG分布构建异地的容灾节点，通过DAG复制技术实现异地容灾。
分析集中式和分布式的优缺点如下，供选型参考。
|
对比项 |
集中式部署 |
分布式部署 |
|
架构描述 |
深圳数据中心部署3台Exchange 2016，并配置DAG高可用 |
深圳和北京数据中心各部署2台Exchange 2016，配置2个DAG |
|
资源需求 |
较低，3台可满足需求 |
较高，两地各两台，至少4台 |
|
带宽需求 |
北京内网用户如访问通过专线使用邮件系统，对带宽的速度要求较高 但对带宽稳定性不敏感，专线中断可以切换到走互联网访问 |
由于各自访问，对专线的带宽占用要求较低， 但如果专线故障，内部两地邮件将无法相互投递 |
|
实施成本 |
较低 |
较高 |
|
用户使用体验 |
北京用户体验取决于专线带宽的宽裕情况，如基本使用Outlook缓存模式，使用体验是一致的 |
较好，如使用Outlook缓存模式，区别不大 |
|
运维管理难度 |
较低 |
较高 |
|
未来容灾部署 |
较简单，仅需要在北京部署容灾服务器 |
较复杂，需要为每个DAG均部署一台容灾服务器 |
|
哪种企业架构合适 |
业务多元化但未划分利润中心，跨部门跨地区经常需要邮件协同 IT管理集中，由统一的管理员进行管理 |
业务分类明显，跨公司或跨地区协同很少，主要是业务单元内部交流； 有不同的管理员分别进行管理 |