用Forefront管理Web服务器负载均衡

        当Web服务器的用户数量比较多时，通过Web服务器负载均衡来提高用户的访问性能，是一个比较常用的手段。如下图所示。可以在企业中同时设置两台或者两台以上的Web服务器，从而实现在服务期之间负载均衡。如此的话，当有一个用户访问某个网页时，系统会自动挑选一台比较空闲的服务器来应对用户的请求。现在主要的关键点是，由谁来确定，这个访问者应该连接到哪一台服务器呢？给用户选择恰当的服务器，不仅可以提高用户的访问性能，而且还可以提高数据的安全性。

        一、可以借助Forefront来充当裁判的角色

        在搭建服务器负载均衡环境时，很重要的一个问题就是如何来确定哪一台服务器比较空间，或者说用户该连接在那一台服务器上？虽然现在不少的服务器软件都带有这个功能，但是如果采用Forefront安全网关产品的话，还能够带来一些额外的安全收益。

        如现在以上两台Web服务器，虽然是为了实现负载均衡来设置的。但是两台服务器有主次之别。如Web服务器1是主服务器，用户不仅可以在这台服务器上进行查询，而且还可以更新相关的数据。而对于Web服务器来说，其是辅助查询，一般用户只能够查询，而不能够更新。此时为了安全起见，显然会对访问Web服务器1的用户进行限制。如企业内部的用户，只能够访问Web服务器1。而对于外部用户，优先访问的是Web服务器2。当Web服务器2比较繁忙时，才允许外部用户访问Web服务器1。此时显然不是简单的Web服务器负载均衡可以实现的。要完成这个需求的话，必须要借助Forefront的帮助。从而在性能与安全之间达到一个均衡。

        如上图所示，在Forefront安全网关的帮助下，管理员在发布执行相同角色的Web服务器时(即服务器负载均衡)，可以控制各个服务器之间的复杂均衡(即可以是完全的负载均衡，也可以是有条件的负载均衡)，从而实现入站访问的高可用性，并提高Web服务器的安全与性能。

        二、Forefront服务器负载均衡的主要实现方式

        Forefront能够确保负载均衡在无需中断当前端点连接的情况下在可用Web服务器之间平均分布请求。这是微软官方文档上的一句原话。其实将这句话进行分解，可以找到两个关键点。一是在不用断开当前连接的情况下实现Web服务器之间的转换。二是Web服务器之间平均分布请求这是一个相对的概念。换句话说，不可能是多台服务器的负荷量是相等的。而是可以根据一定的规则进行调整。另外Forefront还可以检测脱机的服务器，并实现故障转移等相关的工作。在这里笔者结合自己的工作静态，谈谈其服务器负载均衡的主要实现方式。笔者认为，在了解这些主要实现方式的时候，各位读者主要关注其相同点与差异。因为在各位读者自己配制时，需要根据企业的实际情况来选择合适自己的实现方式。总的来说，Forefront的Web服务器发布负载均衡的配置难度并不大。其主要的难点还在于选择合适企业的实现方式。

        在Forefront安全网关中，关于Web负载均衡主要有三种实现方式，分别为基于源IP的负载均衡、机遇Cookie的负载均衡和循环机制。在后续的内容中，笔者会对这三种方式进行分析，并举例说明其主要的适用场合。希望这些内容能够对各位选择合适的实现方式有所帮助。

        第一种方式是基于IP的负载平衡或者IP关联。简单的说，这就是将客户端的IP地址与服务器相关联。如笔者在文章一开始就提到了一个案例。虽然两个服务器之间的内容是相同的，但是在权限上可能有所差别。此时可以将某些特定的客户端IP地址进行指定，其可以优先访问哪一台服务器，或者只允许访问哪一台服务器。这种方式往往有安全方面的考虑。不过需要注意的是，这种方式并不支持所有的服务器负载均衡。如根据笔者的了解，outlook客户端就不支持这种方式。为此如果需要采用这种负载均衡的实现手段，管理员一定要事先确认，所采取的应用能够支持这种方式。

        第二种方式是基于Cookie的负载平衡或这关联。简单的说，这就是指用户会话语服务器进行关联。这种方式有一个特点，即当重新启动Web服务器时，会话关联仍然可以提供可靠的关联。或者说，Forefront 安全网关可以确保用户在一次路由到特定应用服务器后继续使用这个服务器。举一个简单的例子。如上图所示，现在某个用户已经连接到了Web服务器A。此时由于某种特殊情况，管理员将Web服务器A重新启动了。在重新启动后，会话关联仍然可以提供可靠的关联。为此在一些特定的应用中，往往建立采用会话关联。如某些应用程序，特别强调会话的重要性。如淘宝网站。在淘宝网中有购物车的概念。此时即使用户在不同的网页之间进行切换，但是购物车中的内容能够保证是自己刚才采购的。这主要就是会话在其中起作用。对于类似的应用，就需要采用这种机遇Cookie的负载平衡或者关联。

        第三种方式是循环机制。这个机制主要是在Web服务器成员之间平均分布来自不同的IP地址的请求。循环机制的主要特点，是能够确保在联机服务器之间平均分布针对由Web应用程序的用户请求。而且这种分布机制在故障转移期间也能够保持。而且当发生故障转移时，系统能够检测没有响应的服务器，并在可用服务器之间进行分布均衡。简单的说，循环机制其会循环的检查服务器的可用性。当发现用户连接的某台服务器不可用或者非常繁忙时，会马上中断用户的连接，并将其连接到可用的服务器上。而不管用户当前的会话状态如何。这种方式有缺陷也有优点。缺陷是用户当前会话的相关信息(如果没有保存)则可能会丢失。因为此时相关信息还是保存在内存中。当会话强制关闭时，相关信息就会遗失。而优点是能够提供更高的性能。如现在某个用户在访问某个网页，其是连接在Web服务器1访问的。当其转向到另外一个网页时，此时这个网页的访问量非常的大，基本上都集中在服务器1。而这个网页的Web服务器2访问量则比较小。在这种情况下，如果采用循环机制的话，会将这个客户的请求重新定位到服务器2。目的就是为了给这个用户提供更好的性能。可是问题是，现在换了一个服务器，就相当于新建了一个会话 ，原先的会话也就中断了。其实这种情况在实际工作中也比较多建。如我们打1000号的时候，刚开始可能连接的是湖南长沙的站点(可能这个站点比较空)。然后再交接线员转接到1000号的其他部门，此时这个1000号站点可能就不是长沙了(当转接的目标部门比较忙时就会自动转接到其它部门)。此时由于相关信息比较独立，即使当前会话中断了，丢失相关信息影响也不是很大。或者说，相对于漫长的等待时间来说，这个当前会话信息的丢失所造成的影响可以忽略不计。

        可见不同的实现方式其目的虽然相同，但是在细节上仍然有很大的差异。这导致其应用场合也有所不同。总之，基于IP的负载平衡或者基于Cookies的负载均衡，其主要的特点是确保用户在一次路由到特定应用服务器后(如Web服务器1)后续访问继续路由到这个服务器。而循环机制的话，则可能会因为特定资源访问量的变化，在可用的Web服务器之间进行不停的转换。抓住这两个主要的差异点，然后结合企业的实际情况，来判断到底该采用哪种实现方式。