使用网络地址转换实现多服务器负载均衡(2) Llmax为服务器集群中最高硬件配置的服务器的Ll值。当确定了每个服务器的负载之后，中心控制负载分配的服务器就能将负载正确的分发给最空闲的服务器，从而不会象其他的负载分配策略那样会导致负载分配不均匀的情况。 3. 实现方法及实验结果 我们的服务器系统由使用快速以太网连接起来的多台FreeBSD系统组成。每台后端服务器上运行一个守护进程来动态获得自己的负载状态，而使用FreeBSD实现的中心控制网关就通过这些守护进程刷新各个服务器的负载，以进行正确的负载分配。 3.1支持负载均衡的网关 在FreeBSD系统下，提供了divert接口以支持网络地址转换能力。IP数据包通过系统内核的ipfw过滤功能被发送到divert接口中，以便外部守护进程natd能接收原始数据包，处理之后再发回系统内核进行正常的IP分发[5]。 因此根据FreeBSD的地址转换结构，可以创建自己的网络地址转换守护进程，以支持负载均衡功能，这样就能将FreeBSD系统作为一个支持负载均衡的网关。由于它是软件实现的方式，很容易支持非标准的协议及应用优化的负载均衡策略，具备很大的灵活性。 3.2实验及分析 为测试这种实现的可用性，我们针对最常见的HTTP协议进行我们的测试实验。为了区分不同的请求种类，设计了三个不同类型的测试，以测试不同方面的性能。 CGI程序产生的动态文档：用于测试在服务器的处理能力的负载均衡状态。 小型静态文档：使用尺寸较小的静态文档，用于测试频繁连接下负载均衡的状态； 大型静态文档：使用较大的文档，测试磁盘及网络I/O的负载均衡状态； 测试结果以单台服务器每秒钟完成请求的性能为基准，显示使用多台服务器进行负载均衡时每秒种完成的请求数与基准请求次数的比率。 图1：负载均衡性能 从上图中的第一条曲线a是处理动态文档请求的，此时随着服务器数量的增加，其性能是成倍增加的；而第二条曲线b为处理小尺寸静态文档请求的，在使用三台服务器时性能改善就不明显了；而处理大尺寸静态文档请求的第三条曲线c则几乎没有发生性能变化。为了找到负载均衡系统达不到理想状态的原因，我们考察了服务器资源的利用率： 表1.服务器资源的利用率 处理类型 负载均衡网关 服务器1 服务器2 服务器3 a 53% 97% 95% 98% b 76% 43% 39% 41% c 94% 32% 31% 35% 从这个表中可以看出，当处理动态文档a时三台服务器都处于全速运行状态，负载被均匀分配，这是一种理想的状态。当处理静态文档类型b和c时，负载虽然被均匀分配给三台服务器，但每台服务器都没有处于全速运行状态。尤其在处理大尺寸文档时，负载均衡设备中的natd进程则占据了大部分处理资源。由于所有的网络流量都要经过它进行转换，因此在网络流量和并发连接数量相当大时，natd进程的负载就增加上去了。实验中使用不同数量的后端服务器时，流经负载均衡网关的实际网络带宽为： 表2：提供大尺寸文档时服务器集群的带宽 服务器数量 1台 2台 3台 网络速度（Kb/s） 10042.14 11015.10 11442.67 可以看出带宽限制在10MB/s左右，显然这是这个测试使用的负载均衡进程的带宽限制，事实上该程序使用了链表来维护网络地址转换的状态，这就大大限制了它的网络性能，通过提高硬件性能和改善算法，完全可以进一步提高其性能。 4.讨论 从上面的实验中可以看出，基于网络地址转换的负载均衡器可以有效的解决服务器端的CPU和磁盘I/O负载，然而负载均衡器本身的性能受网络I/O的限制，在一定硬件条件下具有一定的带宽限制，但可以通过改善算法和提高运行负载均衡程序的硬件性能，来提高这个带宽限制。同时也可以看出，不同的服务类型对不同的服务器资源进行占用，我们使用的负载衡量策略是使用同一个负载进行评估，这对于大多数条件是适合的，然而最好的办法是针对不同的资源，如CPU、磁盘I/O或网络I/O等，分别监视服务器负载，由中心控制器选择最合适的服务器分发客户请求。我们以后的工作将从这两个方面入手，完善这个负载均衡控制器。
