集群的可扩展性及其分布式体系结构(5)

核心提示：概念介绍本质上讲，网络负载平衡是分布式作业调度系统的一种实现，集群的可扩展性及其分布式体系结构(5)，平衡器作为作业分配的控制者，根据集群节点的当前处理能力，而没有独立的会话管理层，本质上，集中的或分布的对作业进行调配，并且在作业的生命周期里监控执行节点的有效状态

概念介绍

本质上讲，网络负载平衡是分布式作业调度系统的一种实现。平衡器作为作业分配的控制者，根据集群节点的当前处理能力，集中的或分布的对作业进行调配，并且在作业的生命周期里监控执行节点的有效状态，一般的说，平衡器对作业的调度具备以下的特征：

作业必须是可管理的

作业的分配对用户是透明的

最好能够提供异构系统的支持

能够依据集群节点的资源情况进行分配

"平衡"是通过专有的外部设备实现的，外部设备在集群的处理节点中分配工作负载或网络流量。可以静态预先设置或根据当前的网络状态来决定负载分发到哪个特定的节点，节点在集群内部可以互相连接，它们 必须与平衡器直接或间接相连。

网络平衡器特指在网络层次上看到的作业调度系统，大多数网络负载平衡器能够在网络的相应层次上实现SSI。这里，平衡器可静态或动态配置，用一种或多种算法决定哪个节点获得下个"作业"（网络连接）请求，这些节点可以针对特殊应用来优化性能；或者仅与网络协议及流量有关而与应用无关。这两种方法有不同的需求和不同的算法：

与网络有关的方法中，平衡器监视进来的数据，根据网络协议和流量信息来进行分配。

与应用有关的方法中，分配算法基于特定的应用，它在网络通信模型中出于高层。

也可以综合二者，在网络相关方法的基础上构建基于应用层的负载平衡系统，形成更高级、更复杂的平衡环境，在技术上是可能的。

由于现有的大多数网络应用基于TCP/IP 协议，那么我们在分析网络负载平衡的时候主要的参考体系就定在TCP/IP协议栈上。

平衡之根本

在TCP/IP协议中，数据包含有必要的网络信息，因而在网络缓存或网络平衡的具体实现算法里，数据包的信息很重要。但由于数据包是面向分组的（IP）和面向连接的（TCP），且经常被分片，没有与应用有关的完整信息，特别是和作业会话（会话层Session，不是指TCP的会话）相关的状态信息。必须从连接的角度看待数据包--从源地址到目的地址。此外，在源和目的之间的TCP会话也会影响分配算法。

众所周知，TCP/IP是简化了的四层结构协议，TCP并没有实现OSI参考模型的会话层。准确的说，TCP仅仅完成了传输层的功能和部分会话能力--SYN和FIN标记一个TCP会话，而主要的会话层功能由应用协议进行实现和管理。因此，在TCP/IP里，不建全的会话功能成为许多网络负载平衡技术设计时考虑的重点。

平衡考虑的另一个要素就是节点的资源使用状态。由于"负载平衡"是这类系统的最终目的，那么及时、准确的把握节点负载状况就是平衡器不得不考虑的问题了。

一般情况下，集群节点可以提供诸如处理器负载，应用系统负载、活跃用户数、可用的网络协议缓存以及其他的资源信息。信息通过高效的消息机制传给平衡器，平衡器监视所有处理节点的状态，主动决定下个任务传给谁。平衡器可以是单个设备，也可以使一组平行或树状分布的设备。

平衡方法一览

平衡器集中处理网络作业，可通过几个基本的方法来获得网络负载平衡，这些方法可以结合使用，形成更高级的系统。平衡器统一过滤所有的网络流量（单向或者双向），并且实时监控集群节点的资源状态，决定新的流量在集群节点中的分配。这种分配行为要受到多方面因素的影响，这些因素将制约平衡器的调度行为。见下表：

备注：由于网络上对诸如NAT、域名轮训等负载方法已有太多的文章讨论，这里仅仅将其主要的原理和问题列出。

平衡基准方法	基本原理	优点以及适用面	问题以及限制
NAT网络地址转换	将内部或专用网络地址和路由信息转换为外部或公用网络地址和路由	1、节省IPv4地址空间，平衡器能够起到一定程度的防火墙作用2、适用于将企业内部网络进行外连	1、无法同intenet IpSec 这样的安全标准兼容2、负载平衡器容易成为集群系统的瓶颈
域名轮询	Bind8.2以上支持的特性。通过将单一域名映射到多个虚拟域名，实现主机对虚拟域名的轮询。典型如：www CNAME www1www CNAME www2	1、实现简单，因为大多数的类UNIX服务器都能够支持。2、平衡器负载轻，可以快速进行轮询，实现高效的负载均衡。	1、无法探测节点是否正常，造成访问失效。2、由于客户端缓存域名，造成实际的负载不平衡。3、不区别节点差异，无法结合动态负载平衡算法，负载平衡效果差。
逆向代理服务器	以高速磁盘作为页面缓存提供页面响应服务。代理代替客户发送HTTP请求，Web节点仅处理代理服务器的请求，结果由代理从磁盘缓存直接返回。	由于针对磁盘I/O性能进行了优化，既保证Web服务器被安全地隔离，又能快速地进行静态页面甚至动态页面的响应服务。	1、每次的响应都要维护双倍的TCP连接，可扩展性差。 2、与部分CGI不太兼容
嵌入客户端应用的负载平衡	在客户端的应用软件里集成负载平衡功能,由客户端主动选择集群节点	由于实际上集群呈现为对等网的模式，灵活性可以最大化	部署和实现都很不经济
基于TCP/IP的流量均衡	根据数据包的源、目的地址进行连接识别，按照均衡算法将连接分配到不同节点	1、处理速度快，可扩展性高2、兼容大多数的网络应用3、节点可以实现异构性	1、不识别具体的应用协议内容，无法处理应用级会话2、要求节点的应用内容完全一致，而且必须是静态内容3、如果需要服务动态数据，则需有集中的数据存放点
应用依赖的负载均衡	在第应用进行作业负载均衡，通过分析应用协议数据头，根据匹配规则将应用请求发往指定节点	1、面向应用协议会话2、性能上可以针对性的进行优化3、兼容RFC应用协议相关标准4、集群节点独立部署，允许内容不一致	1、分析应用协议数据头的工作比较消耗CPU资源，容易造成CPU瓶颈2、针对不同的协议需要编写独立的协议数据分析模块

采用哪一种平衡方法是根据集群部署的特点决定的。这些影响因素反映了平衡器的能力和局限性，最基本的因素是TCP/IP协议，包括网际协议、网际控制报文协议、传输控制协议和用户数据报协议，此外还有其他的一些因素：

节点操作系统的限制

某些操作系统对处理包的速度，支持的连接数和流量类型有限制，高速网络在新包到来时会产生大量系统中断，过度的中断调用在设计不太良好的系统里简直就是一场CPU的灾难。此外，操作系统处理TCP/IP协议栈的组件构架设计也可能带来问题，或许由于高度的封装，这些组件处理不同层次数据的能力受到限制，导致无法支持底层的网络协议数据流相关操作。

平衡器的限制

很多平衡器在理论上具有无限可扩展能力。但由于内存、CPU等部件存在数量和速度的上限，不可能无限制地支持平衡器的处理。在网络流量负载中，平衡器需要在一定时间内保留连接信息（有时候甚至是双倍的连接信息）和节点状态，限制了集群规模和流量处理速度。如果需要处理复杂协议的网络负载，还要引入对协议数据包头的解析，更增加了平衡器CPU的负担。此外，在小规模集群中运行很好的平衡方法也许不能扩展到大规模集群中，甚至一定环境下（如基于节点的TCP/IP流负载，主要在LAN集群中）的负载平衡方法在另一环境中（如Internet）可能无效。另一个比较不引人注意的是平衡器采用的操作系统的限制。操作系统在平衡器上工作的好坏也直接影响均衡的效率。例如，在SMP环境下，Kernel 2.4核心处理网络流量的效率就要比Linux Kernel 2.2 高的多，因为2.2的TCP/IP协议栈实现是单线程的，而在Kernel 2.4中是多线程的。

TCP/IP协议会话限制

TCP会话通常由一组含有顺序号的IP包组成，平衡器通常在连接表中纪录活动的TCP连接，使TCP流量适当地流向某个节点，现有的平衡算法大都含有基于TCP会话的流量分配机制。一个TCP会话以TCP包的源头发出的SYN同步位标记为开始，经过握手协议确认无误后进行顺序的数据包发送。当会话要结束时，通过源头发送一个TCP会话结束标记--FIN--给对方，表示会话结束。平衡器查找数据包中的SYN和FIN作为会话的起始和结束，并将属于同一会话的负载发送到集群的特定节点上。但是UDP不支持这种会话功能，UDP包互相独立，包也不必相互连续。在应用层从同一台机器上接收UDP包还算可靠，但如果在集群中将UDP保分散到各节点，可能导致应用层的混乱。这种情况可以用以下的方式解决：记录源节点发出的数据报，对于一个会话，建立时间限制；在该超时时间内，所有该源节点新来的UDP包都将发往同一个节点。如果超时时间过后仍然没有新的UDP包则中断这次UDP"会话"。在实现算法上也把这种策略叫做基于源映射的调度算法。

应用协议的相关性

某些应用要求一旦将第一个连接定向到给某个节点，以后的"同类"连接都到同一节点，这在节点间相互独立的非共享集群中是常见的。比如在具有Session特性的电子商务环境中，用户在特定的服务器上认证后，需要将客户后继的请求发往初始认证的节点，以避免重复进行认证。目前，可通过修改应用代码来建立基于集群的应用，比如Apache服务器是目前大量使用的一种电子商务服务器，可以编写Apache 的扩展模块来处理同一个Session的用户请求重定向问题。但这并不是总可行。这种不考虑已有负载而将用户请求定向到特定服务器的会话方式，称为持续会话。为TCP/IP网络的应用需要而设计的网络负载平衡系统常称为第4层优化系统或第4层交换网络，以表明优化是在ISO网络模型的传输层进行的，有些厂商甚至将产品标为第5层（会话层）交换系统以表明是基于TCP会话。然而，TCP/IP协议栈并没有区分会话与传输，TCP会话是TCP协议的一个特征，而没有独立的会话管理层。本质上，这些产品和第4层产品是一样的。