为Exchange2013客户端访问服务器配置高可用（HA）

简单地说，本文探讨的就是CAS阵列的问题。

要实现高可用，你必须像Exchange2010那样为CAS创建负载均衡阵列。与之前版本不同的是，2013的阵列可以使用基于TCP传输层（四层）的负载均衡设备，这对预算比较拮据的项目来说会是一笔不小的节流。

由于四层负载均衡的局限性，你不再需要配置‘粘度’（Affinity），意思是过去当网络连接一旦创建时，就会一直保持在一台客户端访问服务器上。然而在exchange2013中前端服务器不再做任何数据渲染（Data Rendering），一切应用层交互都发生在后端，即邮箱服务器上。

我知道你在想：这是不是就意味着通过DNS设置（比如RoundRobin）就能实现负载均衡。答案是“是”也是“不是”。是，因为在有多台CAS服务器时，负载被分摊到每一个节点上；不是，因为当有一台CAS当机时，你必须手动移除这台服务器的DNS记录，然后等待原来的记录在客户端超时被清除。从高可用的预算上分析，这几乎实现了零成本，但这在绝大多数案例中并不是理想的解决办法。

自从CAS阵列的概念引入伊始，就一直有这样一个误解存在：基于RPC的客户端访问阵列是不是就是基于http的负载均衡设备？确实来说，CAS阵列的概念是模糊的。但是以上命题绝对是错误的！

Exchange2013摒弃了RPC-over-TCP，由此，建立RPC的客户访问阵列（New-ClientAccessArray）就显得毫无意义。只不过是为Outlook Anywhere配置了多个同名不同机的hostname记录而已。

举个例子以便更好的阐明上述观点：

此例中在一个AD站点内启用了两台CAS服务器，默认情况下Exchange会在这两个节点上平衡访问负载。这意味着第一个请求发给CAS1，第二个发给CAS2，第三个发给CAS1…从某种程度上说这就实现了负载均衡，但却没有实现高可用性。当用户的Outlook连接到CAS1，当CAS1当机时，客户端依然会尝试连接这台服务器。当然最终，它会尝试连接别的CAS服务器，但这期间Outlook客户端已经断线很久了。

如果我们添加一个负载均衡器，我们需要将两台CAS的hostname都设为内部Outlook Anywhere的名字，例如outlook.exblog.be。这个FQDN（outlook.exblog.be）就会指向负载均衡器的虚拟IP，通过均衡器来实现负载均衡。由于有这个负载均衡器的存在，它就会自动检测服务器的在线状态，并将传入连接转发到在线节点。由于没有如上例的‘粘度’的需求，故障转移对于用户来说是透明的。