客户端关联性（已死~）
由于之前提到的CAS架构的改动，我们提到，Exchange 2013的CAS里不再需要客户端关联性。客户端关联性就是指在一次客户端连接过程中，一直是与同一台CAS服务器进行通信；换句话说，当客户端连接到了一个特定的CAS之后，该CAS会一直对该客户端提供服务直到该连接断开为止。为了达到这个目的，CAS必须维持该会话状态，在连接过程中经过的负载均衡器（支持客户端关联性的Load Balancer）才能知道是哪一个CAS正在处理该连接，从而进行正确的分流。如果负载均衡器或者是反向代理解析不支持客户端关联性，那么在Exchange 2007和Exchange 2010的环境中会产生重验证的问题（用户连接到了一个不同的CAS）。
在Exchange 2013环境里，因为客户端不论是连接到了那一台CAS服务器，该连接都始终能被正确的代理到拥有该邮箱活动数据库副本的MBX服务器。这个特性适用于所有的协议，比如Outlook Web App。所以在负载均衡这一次层上，不再特别需要负载局衡器产品支持客户端关联性。
让我再啰嗦几句，从邮箱连接的层面上升到网页连接请求的层面。前面已经提过了，老版本的Exchange在没有客户端关联性支持的负载均衡下，会出现要求客户端重新进行验证的问题（常见于IE9访问Exchange2010 的OutlookWebApp，然后采用DNS轮询进行CAS负载均衡）。Exchange 2013改进了Cookie里缓存验证信息的方式。在Exchange 2010当中
当客户端通过验证后，它所连接到的CAS会提供一个加密的cookie给客户端，这个加密的cookie是其他CAS服务器所无法读取的（具体是啥加密的，我也不知道……）。然而到了Exchange 2013当中，这个加密的Cookie由CAS服务器的证书的公钥进行加密，这样所有拥有该证书的Ex2013 CAS服务器都可以进行解密。关于证书管理，我在今后的章节也会跟大家聊一聊，微软推荐的就是我们常用的，一张证书走天下~
负载均衡方案
稍微接触过网络的人都知道OSI七层网络模型，物数网传会表应(Please Do Not Throw Sausage Pizza Away)，所以我们常说的4层负载均衡和7层负载均衡，其实就是指传输级别的负载均衡（还有一说是网络级别的负载均衡，名字而已不要纠结）与应用级别的负载均衡。
四层负载均衡
基于IP+端口的负载均衡，只关心客户端的原地址+端口与目的地的地址和端口，其他的内容则毫不关心也无法关心，因为它只认识四层的调前，没法解开数据包最里头的具体内容，只能根据包头请求的目的地来决定数据包的转发。
七层负载均衡
七层负载均衡器就比较聪明，它们可以看到应用层的流量并进行识别分析，从而实现应用感知。举一个例子，如果一个移动设备的客户端正在请求URL:
https://mail.contoso.com/Microsoft-Server-ActiveSync?jQAJBBCz0DFoa3Zf/Y1CsFFhMg2bBErZMzwCV1A=HTTP/1.1；如果是四层负载均衡收到该请求，它只会识别到目的地址，即Mail.contoso.com，以及请求端口号，即Https对应443.而七层负载均衡不光看到这些信息，它们还可以识别后面的参数对应哪一个应用的虚拟目录(/Microsoft-server-activesync/)，以及中间的同步Key值(那一大串儿)。
Exchange中好几种协议与服务的终结点都是IIS的虚拟目录，那么如果此次请求的目标CAS服务器出问题了，这些协议里有一个协议挂了，比方是EWS挂了。（Exchange 2013里的新功能Managed Availablity（可用性管理）会尝试去解决问题，同时还会对客户端进行通知，解决方法可能是对应用程序池进行回收，或者是重启IIS）一个四层负载均衡设备接收到请求，它只会将CAS服务器看成是一个整体，而并不细化到协议层面，这样导致客户端对EWS的请求和对OWA的请求还照常转发给这台CAS。如果是七层负载均衡的话，它就知道这台CAS上，Outlook Web App没问题，OK我把请求继续转发过来，EWS挂了，我把EWS的请求重定向给其他的CAS服务器；因为它基于应用层面，将每一个服务细化至其具体路径。
四层负载均衡设备对于负载均衡场的可用性检测只有ping一下目标IP地址，看看是up或者是down，一些高端点的L4还能发起HTTP请求，进行HTTP健康检测，但仅限于单一的虚拟ip地址；换句话说，一台开着的、插着网线的服务器，无论他上面有没有装Exchange的CAS角色，对于四层负载均衡设备看起来都是一样的。这对于一些要求高可用性的场景里，肯定不合需求。而一台七层的负载均衡设备不光能知道服务器的网络是否畅通，还可以知道客户端请求的服务是否处于正常状态。很多七层设备上都支持针对特定的应用和服务进行健康检查，于是它们就可以感知到这些应用啥时候失效了，又在啥时候恢复正常，然后根据这些信息进行流量的导向。
Managed Availablity服务就提供了这样一个特性：通过访问相应虚拟目录的/healthcheck.htm页面（比如/owa/healthcheck.htm），得到其返回的HTTP值，如果返回HTTP 200的话，说明该应用为正常状态。这样就方便在负载均衡设备或者是监控设备上调用这个页面，即可实现HealthCheck功能。
DNS轮询
严格来讲，DNS轮询也属于负载均衡技术的一种，虽然看起来不怎么起眼。当你为一个域名配置了多个ip地址时，DNS服务器会将这些地址全部告诉给来查询该域名的客户端，并轮流调换这两个地址的前后顺序；也就是说，两个客户端同时来请求这个域名，他们获得的是相同的两个ip地址，但是是不同的顺序。大多数客户端会采用第一个地址，所以这就达到了一个简单的负载分流效果。微软号称有一些比较聪明的HTTP客户端（Outlook 2010，Outlook2013，以及一些ExchangeActiveSync客户端）在其获得了DNS轮询的结果之后，会对所有的结果进行尝试。这在Exchange 2013的CAS看来是没问题的，无所谓你连接到哪一台。但是微软并没有具体的说，哪些哪些客户端是“比较聪明的”，比如Mac OS X的 Safari 6.X支持这种行为，但是Safari for Windows不支持……（虽然已经停止开发了哈）。也就是说尽管微软官方支持这种做法，君不见Lync 2013的文档库里大量DNS负载均衡的长篇大论。但是在实际应用当中还是需要慎之又慎。
即使我们抛开这些聪明不聪明的问题，还应该注意到DNS轮询的致命弱点，那就是缺少可用性检测行为，比方说：当前我配置了一条dns记录mail.contoso.com给192.168.0.100和192.168.0.200，如果其中的192.168.0.200挂掉了，那么就有一半的用户会连不上服务器，即使你马上把192.168.0.200记录删掉，这些用户的机器上还有DNS缓存，你的设置还不会马上生效。这种成本低廉又容易被配置的负载均衡方式一般用在SMTP上，因为SMTP原本就是无状态的，一次发不过来自动再重试就是了。
Windows Network Load Balancing（Windows网络负载均衡）
微软在Win2000里开始提供Windows网络负载均衡服务（以下简称wNLB），虽然它是windows操作系统自带，而且经历过这么多版本的迭代也算的上是稳定的产品。但在Exchange环境中，真正采用wNLB的其实不多。主要是因为没有可用性检测，除非wNLB群集内的主机关机或者是断网超过重试时间了，否则它都会照常将请求发过去。
还有一点众所周知，那就是部署了DAG的服务器上不能够再部署wNLB，因为wNLB与windows故障转移群集服务（WFC）无法共存，也就是说如果你是两台全角色的Exchange服务器，那就对wNLB说拜拜吧；想省钱，用DNS轮询呗。
如何取舍这些负载均衡方案：
无论你选择哪一种负载均衡方案，他们所达到的目的都差不多：
- 如果你使用的是负载均衡设备或者wNLB，客户端会连接到一个虚拟的ip地址，对应一个统一的FQDN命名空间。如果使用的是DNS轮询，那么负载均衡场里的每一台服务器，自身的地址也得是可以被客户端解析且访问的到。
- 负载均衡场里的服务器数量由负载均衡器决定，比如Windows 2012的wNLB就限制32个节点，其他的方案就具体看其参数了。
- 进来的客户端连接到达负载均衡器后，负载均衡器来决定将请求发送给谁。L4只看目的地IP地址和端口，L7会看连接内容，这就意味着L7负载均衡需要能终结SSL连接，即SSL terminate，拆开SSL封包后解析内容，然后确定适当的服务器进行连接。
当这些概念你已经确定下来之后，下一步就是在功能性和成本上进行选择了。L4的价格不贵，但是相对L7设备来讲功能不足。但是我们换个角度思考一下，如果我们将每一种协议的命名空间分拆开来，并且给予不同的虚拟ip地址，好像也可以使L4区分开不同的服务请求哦。如果这么干的时间成本大于买个F5，那还是老老实实买个F5吧（笑）。
还有最后一点忘记说了，物理的负载均衡器还是虚拟化的负载均衡应用呢？现在软件定义网络（SDN）已经越来越普及，这在以后肯定也是一个有意思的问题。现在虚拟交换机和路由器实际应用的并不多，大多数都是Hypervisor集成的一些交换机。但是你仔细想想SCVMM那个SDN模型，在里面加入一个虚拟负载均衡器的概念，是不是也挺靠谱的？当下的大中型企业环境里，就像上面说的，一大部分还是停留在Hypervisor自身的虚拟交换机层面，那还是用硬件负载均衡吧…当然如果你们环境非常小，采用VM的负载均衡应用也是没有问题，节省成本，功能也差不多。
好了，又给大家扯了了一大通，下一章就给大家讲Outlook AnyWhere这个Exchange 2013中的重点玩意儿。
广告咱就不继续打了……先放一放，等正式上线了咱再接着打。