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

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

1、能够借助Forefront来充当裁判的角色

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

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

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

2、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服务器之间进行不停的转换。抓住这两个主要的差别点，而后结合企业的实际状况，来判断到底该采用哪一种实现方式。