Exchange Server 2016 架构前瞻

re2323

在Ignite 2015上，Exchange产品组介绍了Exchange2016的一些新功能，这里主要总结一下架构更改方面的东西，并分享给大家，其中的一些内容可能在以后不久发生更改，一切以最终发行的正式版文档为准：

附上：Exchange@Ignite2015视频集锦

在Exchange 2016当中，引入了“积木式架构”这样一种概念，移除了CAS角色，在MBX角色上添加了客户端访问这样一个服务（Client Access Service）。目的嘛，就是微软常说的简化代码，增强性能之类的……

Ex2016当中的MailBox角色：

1、负责传输逻辑

2、负责所有的处理、渲染（对邮件进行处理）、存储邮件的组件和协议

客户端无法直接连接到MBX的后端终结点；而是首先连接到客户端访问服务，然后经由客户端访问服务来进行路由（本地或远程代理）到拥有该用户邮箱数据库的活动副本的MBX服务器

Ex2016中的DAG增强：

1、创建DAG的时候不再需要DatabaseAvailabilityGroupIpAddresses ，故障转移群集在建立的时候，不会同时在AD里面建立计算机账户，也就是管理访问点。（Ex2013 SP1就支持这个功能：http://jaapwesselius.com/2014/11 ... availability-group/）

2、默认打开延迟滞后重播功能（-ReplayLagManageEnabled $True :https://technet.microsoft.com/zh-cn/library/dd979786(v=exchg.150).aspx）

3、基于磁盘的延迟，智能减少已经延迟滞后的数据库的复制，以保证目前的活动用户不受影响

4、数据库故障转移时间比Exchange 2013减少了33%

移除了所有的CAS组件并不会影响服务器间的通信，服务器间通信仍然保持在协议的层面。（跟2013的服务器间通信其实差不多：http://blogs.technet.com/b/excha ... e-architecture.aspx）

对于给定的邮箱连接，使用的协议永远是由该邮箱实例所位于的活动数据库副本所提供。

负载均衡配置不会被这种架构更改所影响。在协议的层面来看一次客户端的邮箱连接请求：

1、客户端解析了DNS命名空间到负载均衡的虚拟ip。

2、负载均衡将此连接会话分配给负载均衡池里的MBX服务器

3、MBX服务器认证请求，尔后经由活动目录进行服务发现，查询该请求，收到以下信息：

    a、邮箱版本（假设为一个Ex2016邮箱）

    b、邮箱位置信息（所属的数据库信息）

4、MBX服务器决定是代理该请求或是重定向该请求到同一个森林中的其他邮箱服务器

5、MBX服务器查询活动数据库实例管理器，得知哪个MBX服务器拥有该邮箱的活动数据库副本

6、MBX代理该请求到拥有该邮箱活动数据库副本的MBX服务器

第六步所用的协议取决于客户端用那种协议去连接客户端访问服务（Client Access Serices）,如果客户端使用HTTP请求，那么服务器间也使用HTTP（使用自签名证书的SSL加密）。如果客户端使用IMAP或者POP，那么在服务器间使用的也是IMAP或者POP。

第六步中，如果是一个电话请求，则不会被MBX服务器进行代理，而是直接重定向到活动数据库副本所在MBX服务器。因为电话设备支持重定向，并且需要与MBX服务器上的UM服务建立直接的SIP和RTP连接。

至于为什么移除CAS角色，产品组的解释是：

1、我们希望你所有的Exchange服务器都是相同的配置，相同的硬件，以便于你采购、维护、管理

2、我们本来就推荐角色协同并置，以充分利用Cpu和磁盘。试想你在Ex2010环境里专门为了Hub角色单独放一台物理服务器该多浪费啊

3、所以我们的目的是为了减少你的服务器数量……减少硬件开支……

其他关键性的加强：

加强搜索：

在Ex2016当中，在活动副本和被动副本之间的复制带宽降低了40%。这是由于本地的搜索实例将只从本地的数据库读取数据进行索引，意味着如果被动副本要更新它的索引，只需要等待复制，然后从其自身的数据库进行索引，而非每一次都去找活动副本。

另一方面，则是改进在线模式的客户端的搜索体验（比如OWA客户端），降低其获得搜索结果的时间。当用户输入完搜索关键词之前，就开始执行多此异步磁盘读取，以缓存与关键词相关的信息；通过这样来降低查询延迟

文档协同：

在之前的Ex2013版本中，OWA已经可以在线预览office和PDF文件。Sharepoint+Office Web Apps服务器也可以实现这些功能。在office 365当中，已经完全使用Office Web Apps来提供统一文档预览和协同编辑功能。

这个特性移植到了Ex2016上，集成office web apps服务器的Exchange2016在OWA里会拥有富文本编辑以及预览功能。

下一代Office Web App服务器将不能与Exchange服务器进行并置，所以得部署独立的Office Web App服务器场来实现这功能，这个服务器场需要独立的命名空间，以及能够保持会话关联的负载均衡器。

Exchange支持非绑定的命名空间，而Office Web App需要绑定的命名空间，（但是不会由于访问位置发生改变而改变）。所以整个架构看起来就像下图一样

可扩展性：

Ex2016引入了O365使用的REST（Representational State Transfer） API，拥有更好的开放性与灵活性。这些api允许开发者从任何平台连接，比如web、pc、移动SDK（Android、IOS、.NET）或者nodejs，ruby，python，Cordova、CORS……

被抛弃的EWS在哪哭泣……

Outlook连接：

在Exchange 2013 SP1当中，outlook连接已经默认使用MAPI over HTTP，在Ex2016当中，Mapi Over HTTP已经是默认设置了；并且在此连接模型之上，加入了每用户控制，以及控制某种协议是否对外部用户可用。

注意：Ex2016不再支持通过MAPI/CDO库直接连接，第三方产品需要迁移到EWS或者是REST APIs来访问Exchange数据。

与Exchange 2013共存：

在Ex2013当中，CAS角色只代理连接，不负责处理任何内容。所以当你在环境中引入了一台Ex2016的时候，是不需要去更改命名空间的，因为Ex2013的CAS架构完全能够将用户请求代理给拥有该邮箱活动数据库副本的Ex2016服务器。也就是说，你可以在同一个负载均衡池里同时存在Ex2013和Ex2016，然后可以一台一台的升级13到16，加一台16，减一台13.

架构需要：

Exchange 2016只支持Windows server 2012 R2和 Windows Server 10操作系统

AD层面：     
    Windows 2008 R2 或者更新的AD服务器

Windows 2008 R2或者更新的林功能级别以及域功能级别

共存：

Exchange 2013 CU11

Exchange 2010 SP3 RU11

（这俩都没出来呢……）

最佳实践架构：

与Ex2013的PA差不多：数据中心配对之上建立DAG，DAG中的MBX服务器交错分布所有的活动数据库副本，数据库副本基于JBOD存储，每块盘4个副本，其中一个副本为延迟滞后副本。客户端通过统一的命名空间进行访问，负载均衡到整个站点。

1、Ex2016 的非绑定命名空间模型使得跨越整个数据中心的7层负载均衡在配置上不需要保持会话关联性

2、你需要在每个数据中心中部署一个Office Web Apps场，每个场有其独立的命名空间，负载均衡器需要打开回话关联性

3、DAG的部署不再需要管理访问点。

4、服务器：双CPU插槽，有20-24个处理器和最高196G内存，以及带电池的写入缓存控制器

5、所有数据存储卷都被格式化为ReFS（https://technet.microsoft.com/zh-cn/library/hh831724.aspx）

总结：

Exchange 2016还是在减少服务器角色架构复杂度和引入从O365移植的成熟的设计思想两方面下功夫。如果看过视频就知道。。几乎每一项新功能前面都会加上，we learn from O365 blablabla的……