「深入 Exchange 2013」01 客户端访问角色架构

321312

  Exchange 2013当中CAS角色的重要性不用多说。在Exchange Server4.0、5.0和5.5版本中，都没有特定的一个客户端访问功能角色，Exchange 2000引入了前端服务器的概念（front-end），这种服务器不存放任何邮箱数据，只提供客户端连接。一直到Exchange 2007，带来了第一次CAS角色的迭代；尔后在后面的产品中不断被加强改善。在Exchange 2007的时候，CAS角色就已经负责以下三种类型的流量：

• 外部连接
  
• 内部连接
  
• 被其他CAS服务器重定向，或是被代理过来的连接。
  
  

        对以上三种流量处理的方式，这些Exchange支持的连接协议，和如何实现协议支持的原理，都在Exchange2013当中发生了巨大改变。现在Exchange2013的CAS只有两个重点任务

• 认证用户请求
  
• 定位正确的服务器以传递用户请求
  
  
  

微软推崇紧密耦合的架构概念，于是随着时间的推移，慢慢将Exchange的代码分成了三大功能类：

• Storage:负责邮箱的存储、传输和处理。即众所周知的Information store服务就是该类代码之一。
  
• 协议层，服务端：负责与客户端交互、从邮箱里检索邮件信息、为特定的客户端格式化邮件信息，提供客户端服务例如同步、邮件寻址等…
  
• Exchange的业务逻辑层：负责确认一个请求或者数据是否是有效的，比如说创建一个结束时间早于开始时间的日历项，创建一个已经存在的联系人等。
  
  
  
  

        
        下图显示了上述三个代码块在Exchange2010里的通信模型，左边的协议层与右边的Storage层和协议层通信（图中少了根线），业务逻辑层则与Storage和协议层通信。这里就会引起一些潜在的问题：面对某些的发往新版CAS服务器的流量或是协议请求，旧版的CAS服务器可能没办法为其进行代理。
这种架构在层与层之间也存在很多依赖性，你得保证每个有Mailbox角色的站点里面都得有CAS和HUB Transport角色的服务器。

而Exchange2013将上图的组件通信模式完全改变了，消除了不同层的跨服务器的通信行为，协议层就只能与协议层通信。every server is an island。

        如上图所示，注意其中协议层的通信对象，是每种协议一对一的关系。这也使得CAS角色成为一个无状态的代理，CAS角色不用再维持客户端的会话状态，不用处理任何的客户端数据（当然它会给客户端发一些数据）。CAS只验证用户连接，对其请求的服务或协议确定正确的目标，接着将用户连接代理或是重定向到这些目标。

        具体来说，CAS提供以下服务：

• IMAP、POP、Outlook Web App、Exchange管理中心（EAC）、Exchange ActiveSync和Exchange Web Service（EWS）。CAS代理或是重定向这些协议的流量到适当的MBX服务器
  
• 为离线通讯簿（OAB）代理请求，发送到适当的MBX服务器，使客户端获得及时的OAB更新
  
• Autodiscover，提供客户端导向服务。使移动或者桌面客户端的邮箱访问、Outlook Web App访问、移动设备同步或是统一消息行为能够获得正确的服务端点。
  
• 前端传输(Front End Transport - FET)接收入站的SMTP流量，并代理给Exchange2013的MBX服务器或Exchange2007/2010的HUB服务器。FET不会存储或是队列任何邮件。
  
• 统一消息呼叫路由服务（UMCR）将入站的统一消息请求重定向给恰当的MBX服务器
  
• 代理可用性服务的用户连接，也就是提供忙闲信息的服务。
  
• 邮箱复制服务（MRS）的代理引擎，MRS代理会接受外部组织的跨林邮箱移动请求，重定向给恰当的MBX服务器
  
• 所有受其支持的服务的初始验证，例如CAS会对入站的EWS请求在发给别的组件之前进行初始验证。
  
  

        同样的，我们还得注意CAS不提供什么。首当其冲的是，CAS不再提供MAPI客户端通过RPC over TCP的直接连接，这个改动也就意味着Exchange2013的CAS上边没有RPC客户端访问层了（现在改在了MBX角色上），CAS现在只接受Outlook Anywhere的直接连接 （MAPI over HTTP/HTTPs）。
        为啥要这么改动呢，微软的解释是：第一，增强客户端到MBX连接的健壮性；第二，简化代码。其实这些都是从O365搬过来的~


        记住在2013的CAS架构中，请求邮箱数据的连接总是会被丢给拥有该邮箱活动数据库副本（Active Copy）的MBX服务器。这就意味这2013的CAS需要有一种方法来定位到该服务器。在2007当中，客户端连接到RPC终结点；2010当中，客户端会连接到一个可以代表RPC终结点的FQDN（数据库通过RPCClientAccessServer这个属性来进行连接，记得嘛？），这个FQDN可能代表一个客户端访问阵列（CAS Array）或者是一台单独的CAS服务器。当一个用户的客户端正连接的邮箱所在数据库的MBX服务器发生了故障转移，或是进行了数据库切换。那么该客户端需要更新其本地的MAPI连接配置文件来反应此次切换，这时候需要客户端进行重启动操作了。


        而在2013当中，Outlook使用了全局唯一标识符（GUID）来代表邮箱，以作为连接的终结点名称。每个邮箱都会有一个GUID属性，所以无论哪一台MBX服务器拥有当前用户邮箱所处的数据库活动副本，CAS都能通过GUID来解析当前有是哪台服务器包含该活动副本。这个改动就让CAS可以无缝切换连接到新的数据库活动副本，客户端完全体会不到后端数据库的副本切换动作。

        同样的由于这个改动的产生，RpcClientAccessServer属性就没啥用了，反正你MBX切来切去，我CAS拿着一个GUID万变不离其宗。
        RPC ClientAccessArray 也没了，CAS Array的设计初衷是为了提供统一的客户端访问点。然而在2013当中，客户端请求不管到达哪一台CAS都可以正确的连接到恰当的MBX，所以这样一个逻辑对象就没必要存在了。
        当然针对负载均衡器来说，这样的逻辑对象还是存在的（负载均衡服务器场），2010里我们需要把cas array的ip地址指向到负载均衡的虚拟ip，2013里面就没这个过程了。

OK，这一章就写到这里，下一章我们来聊聊CAS的几种验证方法。