web集群服务的负载均衡方案选择与实现

 

转自 http://hi.baidu.com/k_boy/item/0104f2f19932dbb530c19943

 

web 应用服务器集群系统，是由一群同时运行同一个 web 应用的服务器组成的集群系统，在外界看来，就像是一个服务器一样。为了均衡集群服务器的负载，达到优化系统性能的目的，集群服务器将众多的访问请求，分散 到系统中的不同节点进行处理。从而实现了更高的有效性和稳定性，而这也正是基于 Web 的企业应用所必须具备的特性。 高可靠性可以看作为系统的一种冗余设定。对于一个特定的请求，如果所申请的服务器不能进行处理的话，那么其他的服务器能不能对之进行有效的处理呢？对于一 个高效的系统，如果一个 Web 服务器失败的话，其他的服务器可以马上取代它的位置，对所申请的请求进行处理，而且这一过程对用户来说，要尽可能的透明，使用户察觉不到！ 稳定性决定了应用程序能否支持不断增长的用户请求数量，它是应用程序自身的一种能力。稳定性是影响系统性能的众多因素的一种有效的测量手段，包括机群系统 所能支持的同时访问系统的最大用户数目以及处理一个请求所需要的时间。 在现有众多的均衡服务器负载的方法中，广泛研究并使用的是以下两个方法：

• DNS负载平衡的方法RR-DNS(Round-Robin Domain Name System)
• 负载均衡器

以下，我们将就这两种方法进行讨论。 DNS 轮流排程   RR-DNS(Round-Robin Domain Name System) 域名服务器（ Domain Name Server ）中的数据文件将主机名字映射到其 IP 地址。当你在浏览器中键入一个 URL 时（例如： www.loadbalancedsite.com ），浏览器则将请求发送到 DNS ，要求其返回相应站点的 IP 地址，这被称为 DNS 查询。当浏览器获得该站点的 IP 地址后，便通过该 IP 地址连接到所要访问的站点，将页面展现在用户面前。 域名服务器（ DNS ）通常包含一个单一的 IP 地址与该 IP 地址所映射的站点的名称的列表。在我们上面所假象的例子中， www.loadbalancedsite.com   这个站点的映射 IP 地址为 203.24.23.3 。 为了利用 DNS 均衡服务器的负载，对于同一个站点来讲，在 DNS 服务器中同时拥有几个不同的 IP 地址。这几个 IP 地址代表集群中不同的机器，并在逻辑上映射到同一个站点名。通过我们的例子可以更好的理解这一点， www.loadbalancedsite.com 将通过下面的三个 IP 地址发布到一个集群中的三台机器上： 203.34.23.3 203.34.23.4 203.34.23.5 在本例中， DNS 服务器中包含下面的映射表： www.loadbalancedsite.com 203.34.23.3 www.loadbalancedsite.com 203.34.23.4 www.loadbalancedsite.com 203.34.23.5 当第一个请求到达 DNS 服务器时，返回的是第一台机器的 IP 地址 203.34.23.3 ；当第二个请求到达时，返回的是第二台机器的 IP 地址 203.34.23.4 ，以此类推。当第四个请求到达时，第一台机器的 IP 地址将被再次返回，循环调用。 利用上述的 DNS Round Robin 技术，对于某一个站点的所有请求将被平均的分配到及群中的机器上。因此，在这种技术中，集群中的所有的节点对于网络来说都是可见的。 DNS  轮流排程的优势     DNS Round Robin 的最大的优点就是易于实现和代价低廉：

• 代价低，易于建立。   为了支持轮流排程，系统管理员只需要在DNS服务器上作一些改动，而且在许多比较新的版本的DNS服务器上已经增加了这种功能。对于Web应用来说，不需要对代码作任何的修改；事实上，Web应用本身并不会意识到负载均衡配置，即使在它面前。
• 简单.   不需要网络专家来对之进行设定，或在出现问题时对之进行维护。

DNS  轮流排程的缺点       这种基于软件的负载均衡方法主要存在两处不足，一是不实时支持服务期间的关联，一是不具有高可靠性。     •   不支持服务器间的一致性 。服务器一致性是负载均衡系统所应具备的一种能力，通过它，系统可以根据会话信息是属于服务器端的，还是底层数据库级别的，继而将用户的请求导向相应的服 务器。而 DNS 轮流排程则不具备这种智能化的特性。它是通过 cookie 、隐藏域、重写 URL 三种方法中的一种来进行相似的判断的。当用户通过上述基于文本标志的方法与服务器建立连接之后，其所有的后续访问均是连接到同一个服务器上。问题是，服务 器的 IP 是被浏览器暂时存放在缓存中，一旦记录过期，则需要重新建立连接，那么同一个用户的请求很可能被不同的服务器进行处理，则先前的所有会话信息便会丢失。

• 不支持高可靠性 。设想一个具有 N 个节点的集群。如果其中的一个节点毁坏，那么所有的访问该节点的请求将不会有所回应，这是任何人都不愿意看到的。比较先进的路由器可以通过每隔一定的时间 间隔，对节点检查，如果有毁坏的节点，则将之从列表中去除的方法，解决这个问题。但是，由于在 Internet 上， ISPs 将众多的 DNS 存放在缓存中，以节省访问时间，因此， DNS 的更新就会变得非常缓慢，以至于有的用户可能会访问一些已经不存在的站点，或者一些新的站点得不到访问。所以，尽管 DNS 轮流排程在一定程度上解决了负载均衡问题，但这种状况的改变并不是十分乐观和有效的。

除了上面介绍的轮流排程方法外，还有三种 DNS 负载均衡处理分配方法，将这四种方法列出如下： Ø            Round robin (RRS) ：  将工作平均的分配到服务器   ( 用于实际服务主机性能一致 ) Ø            Least-connections (LCS) ：  向较少连接的服务器分配较多的工作 (IPVS  表存储了所有的活动的连接。用于实际服务主机性能一致。 ) Ø            Weighted round robin (WRRS) ：  向较大容量的服务器分配较多的工作。可以根据负载信息动态的向上或向下调整。   ( 用于实际服务主机性能不一致时 ) Ø            Weighted least-connections (WLC) ：  考虑它们的容量向较少连接的服务器分配较多的工作。容量通过用户指定的砝码来说明，可以根据装载信息动态的向上或向下调整。 ( 用于实际服务主机性能不一致时 )  负载均衡器 负载均衡器通过虚拟 IP 地址方法，解决了轮流排程所面临的许多问题。使用了负载均衡器集群系统，在外部看来，像是具有一个 IP 地址的单一服务器一样，当然，这个 IP 地址是虚拟的，它映射了集群中的每一台机器的地址。所以，在某种程度上，负载均衡器是将整个集群的 IP 地址报漏给外部网络。 当请求到达负载均衡器时，它会重写该请求的头文件，并将之指定到集群中的机器上。如果某台机器被从集群中移除了，请求不会别发往已经不存在的服务器上，因 为所有的机器表面上都具有同一个 IP 地址，即使集群中的某个节点被移除了，该地址也不会发生变化。而且， internet 上缓存的 DNS 条目也不再是问题了。当返回一个应答时，客户端看到的只是从负载均衡器上所返回的结果。也就是说，客户端操作的对象是负载均衡器，对于其更后端的操作，对 客户端来讲，是完全透明的。 负载均衡器的优点     •   服务器一致性 .  负载均衡器读取客户端发出的每一个请求中所包含的 cookies 或 url 解释。基于所读出的这些信息，负载均衡器就可以重写报头并将请求发往集群中合适的节点上，该节点维护着相应客户端请求的会话信息。在 HTTP 通信中，负载均衡器可以提供服务器一致性，但并不是通过一个安全的途径（例如： HTTPS ）来提供这种服务。当消息被加密后（ SSL ），负载均衡器就不能读出隐藏在其中的会话信息。   •   通过故障恢复机制获得高可靠性 . 故障恢复发生在当集群中某个节点不能处理请求，需将请求重新导向到其他节点时。主要有两种故障恢复： •  请求级故障恢复。当集群中的一个节点不能处理请求时（通常是由于 down 机），请求被发送到其他节点。当然，在导向到其他节点的同时，保存在原节点上的会话信息将会丢失。 •  透明会话故障恢复。当一个引用失败后，负载均衡器会将之发送到集群中其他的节点上， 以完成操作，这一点对用户来说是透明的。由于透明会话故障恢复需要节点具备相应的操作信息，因此为了实现该功能，集群中的所有节点必须具有公共存储区域或 通用数据库，存储会话信息数据，以提供每个节点在进行单独进程会话故障恢复时所需要的操作信息。      •  统计计量。 既然所有的 Web 应用请求都必须经过负载均衡系统，那么系统就可以确定活动会话的数量，在任何实例访问中的活动会话的数目，应答的次数，高峰负载次数，以及在高峰期和低谷期的会话的数目，还有其他更多的。所有的这些统计信息都可以被很好的用来调整整个系统的性能。 负载均衡器的缺点       硬件路由的缺点在于费用、复杂性以及单点失败的。由于所有的请求均是通过一个单一的硬件负载均衡器来传递，因此，负载均衡器上的任何故障都将导致整个站点的崩溃。 HTTPS 请求的负载均衡       正如上面所提到的，很难在那些来自 HTTPS 的请求上进行负载均衡和会话信息维护处理。因为，这些请求中的信息已经被加密了。负载均衡器没有能力处理这类请求。不过，这里有两种方法可以解决这一问题：

• 代理网络服务器
• 硬件 SSL 解码器

      代理服务器位于服务器集群之前，首先由它接受所有的请求并对之进行解密，然后将这些处理后的请求根据头信息重新发往相应的节点上，这种方式不需要硬件上的 支持，但会增加代理服务器的额外的负担。       硬件 SSL 解码器，则是在请求到达负载均衡器之前，先经由它进行解密处理。这种方式比代理服务器的处理速度要快捷一些。但代价也高，而且实现比较复杂。