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

本文系转载文章,出自http://sodaxu.blog.51cto.com,作者Sodaxu。


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角色的服务器。

image


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


image

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

具体来说,CAS提供以下服务:

1、IMAP、POP、Outlook Web App、Exchange管理中心(EAC)、Exchange ActiveSync和Exchange Web Service(EWS)。CAS代理或是重定向这些协议的流量到适当的MBX服务器

2、为离线通讯簿(OAB)代理请求,发送到适当的MBX服务器,使客户端获得及时的OAB更新

3、Autodiscover,提供客户端导向服务。使移动或者桌面客户端的邮箱访问、Outlook Web App访问、移动设备同步或是统一消息行为能够获得正确的服务端点。

4、前端传输(Front End Transport - FET)接收入站的SMTP流量,并代理给Exchange2013的MBX服务器或Exchange2007/2010的HUB服务器。FET不会存储或是队列任何邮件。

5、统一消息呼叫路由服务(UMCR)将入站的统一消息请求重定向给恰当的MBX服务器

6、代理可用性服务的用户连接,也就是提供忙闲信息的服务。

7、邮箱复制服务(MRS)的代理引擎,MRS代理会接受外部组织的跨林邮箱移动请求,重定向给恰当的MBX服务器

8、所有受其支持的服务的初始验证,例如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的几种验证方法。



你可能感兴趣的:(服务器,文章,客户端,角色,Exchange,微软)