运营商级 Web 服务器上的 Linux
ARIES(互联网电子服务器高级研究)项目于 2000 年 1 月在加拿大爱立信研究院启动。其目标是寻找和原型化必要的技术,以证明集群互联网服务器的可行性,该服务器使用 Linux 和开源软件作为基础技术来展示电信级特性。这些特性包括保证持续可用性、保证响应时间、高可扩展性和高性能。
流量分配是主要研究课题之一,因为我们需要一个基于软件的解决方案,该解决方案非常可靠、高性能且高度可扩展,以便在集群内的多个 CPU 之间分配 Web 流量。我们进行的第一个活动是调查开源社区,看看已经实施了哪些解决方案,在我们的实验性 Linux 集群上试用它们,并看看哪些解决方案最符合我们的要求(或部分要求)。
本文介绍了我们在 Linux Virtual Server (LVS) 方面的经验,LVS 是一个在 Linux 之上提供流量分配的软件包。我们将解释 LVS 的架构、操作和算法,并描述我们的测试系统和基准测试环境,以及我们为测试 LVS 的稳健性和可扩展性而进行的实验。
互联网上的流量每六个月增长超过 100%。因此,服务器上的工作负载迅速增加,这些服务器很容易过载。
为了克服这个问题,有几种解决方案。最有趣的一种是多服务器解决方案,它包括在服务器集群上构建可扩展的服务器。当负载增加时,可以在集群中添加更多服务器以满足不断增长的请求。多服务器架构提供了良好的灵活性(添加和删除节点)和可用性,因为它没有与之相关的停机时间。第二个优点是真正的服务器不需要是同构的,这允许回收一些旧的工作站。第三个优点是透明性:集群作为一个单一 IP 地址呈现给用户,该 IP 地址将请求映射到后端的多个服务器。
Linux Virtual Server 遵循多服务器模型,并提供基于软件的流量分配解决方案,而不是基于硬件的解决方案。
我们在 ARIES 项目中的研究方向是能够实现线性可扩展性的多服务器架构,这种可扩展性通过持续增长来满足不断增长的需求,通过在架构的所有级别构建冗余来实现持续的服务可用性,以及在不影响系统正常运行时间的情况下实现易用性和完整的管理。
我们自然对 LVS 作为 HTTP 流量分配解决方案感兴趣,因为集群的架构对于最终用户是透明的,因此整个系统将以单个 IP 地址出现。此外,LVS 声称通过检测节点或守护程序故障并适当地重新配置系统来达到高可用性,以便工作负载可以由集群中的其余节点接管。对于面向高可用性的系统来说,这是一个非常重要的特性。
LVS 项目是一个开源项目,旨在将多个服务器集群在一起,形成一个高可用性和高性能的虚拟服务器,该服务器提供良好的可扩展性、可靠性和可维护性。LVS 调度器提供 IP 级别的负载均衡,使集群的并行服务在单个 IP 地址上显示为虚拟服务。
LVS 项目目前正在与 High Availability Linux Project 合作,该项目旨在为 Linux 提供高可用性(集群)解决方案,通过社区开发工作来提升可靠性、可用性和可维护性 (RAS)。
在 LVS 设置中,真正的服务器可以通过高速 LAN 或地理上分散的 WAN 互连。另一方面,真正服务器的前端(称为调度器)是一个负载均衡器,它将请求分配给不同的服务器。所有请求都发送到具有虚拟 IP 地址的前端调度器,集群在单个 IP 地址上显示为虚拟服务。
这种架构非常灵活,因为它允许透明地添加或删除真正的服务器节点,并且它面向高可用性,通过自动检测节点或守护程序故障并适当地重新配置系统。为了增加可用性,我们可以设置第二个调度器作为主调度器的热备,从而消除可能的单点故障。
LVS 以三种 IP 负载均衡技术实现。一种是通过网络地址转换 (NAT) 的虚拟服务器,第二种是通过 IP 隧道技术的虚拟服务器,第三种是通过直接路由的虚拟服务器。当我们进行这项活动时,NAT 实现与其他实现相比非常稳定。因此,我们决定使用 NAT 设置 LVS。
由于私有地址的大量使用,LVS-NAT 实现是必要的。由于许多原因,包括 IPv4 中 IP 地址的短缺以及安全原因,越来越多的网络正在使用无法在网络外部使用的私有 IP 地址。
网络地址转换依赖于以下事实:可以适当地调整互联网协议的标头,以便客户端相信他们正在联系一个 IP 地址,但不同 IP 地址的服务器相信他们正在被客户端直接联系。此功能可用于构建虚拟服务器,即,不同 IP 地址的并行服务可以通过 NAT 在单个 IP 地址上显示为虚拟服务。
通过 NAT 的虚拟服务器的架构如图 2 所示。负载均衡器和真正的服务器通过交换机或集线器互连。真正的服务器通常运行相同的服务,并且它们具有相同的内容集。内容在每个服务器的本地磁盘上复制,在网络文件系统上共享,或由分布式文件系统提供服务。负载均衡器通过 NAT 将请求分发到不同的真正服务器。
地址转换过程分为几个步骤
用户访问服务器集群提供的服务。
请求数据包通过负载均衡器的外部 IP 地址到达负载均衡器。
负载均衡器检查数据包的目标地址和端口号。如果它们与虚拟服务器服务匹配(根据虚拟服务器规则表),则通过调度算法从集群中选择一个真正的服务器,并将连接添加到哈希表中,该哈希表记录所有已建立的连接。
数据包的目标地址和端口被重写为所选服务器的地址和端口,并且数据包被转发到真正的服务器。
当传入数据包属于此连接,并且可以在哈希表中找到已建立的连接时,数据包将被重写并转发到所选服务器。
当回复数据包从真正的服务器返回到负载均衡器时,负载均衡器将数据包的源地址和端口重写为虚拟服务的地址和端口。
当连接终止或超时时,连接记录将从哈希表中删除。
LVS 支持四种调度算法:轮询调度、加权轮询调度、最少连接调度和加权最少连接调度。轮询调度算法以轮询方式将网络连接定向到不同的服务器。它将所有真正的服务器视为平等,而不管连接数或响应时间如何。加权轮询调度能够处理具有不同处理能力的真正服务器。每个服务器可以分配一个权重和整数值,表示其处理能力,调度器根据服务器的权重以轮询方式调度请求。
最少连接调度算法将网络连接定向到已建立连接数最少的服务器。这是一种动态调度算法,因为它需要动态地计算每个服务器的活动连接数。在虚拟服务器中,当有一组性能相似的服务器时,最少连接调度非常适合在请求负载变化很大时平滑分配,因为所有长时间的请求都不会有机会被定向到一台服务器。
加权最少连接调度是最少连接调度的超集,您可以在其中为每个真正的服务器分配性能权重。权重值较高的服务器在任何时候都会收到更大比例的活动连接。虚拟服务器管理员可以为每个真正的服务器分配权重,并且网络连接被调度到每个服务器,其中当前活动连接数的百分比与其权重的比率。默认权重为 1。
为了测试和评估 LVS 的性能,我们在蒙特利尔的爱立信研究实验室建立了一个强大的测试环境,该环境由八个 CompactPCI 无盘 Pentium III CPU 卡组成,运行频率为 500MHz,配备 512MB RAM。CPU 有两个板载以太网端口,每个 CPU 都与一个四端口 ZNYX 以太网卡配对。我们的设置还包括一个 CPU,其配置与其他 CPU 相同,只是它有三个 SCSI 磁盘:每个 18GB,配置为 RAID-1 和 RAID-5 设置。此 CPU 充当其他 CPU 的 NFS、DHCP、Bpbatch 和 TFTP 服务器。
CPU 使用 Linux 内核 2.2.14-5.0,该内核随 Red Hat 6.2 发行版一起提供。当我们启动 CPU 时,它们从 LAN 启动并向网络上的所有地址广播 DHCP 请求。DHCP 服务器(带有磁盘的 CPU)将回复 DHCP offer,并将向 CPU 发送它们配置网络设置所需的信息,例如 IP 地址(每个接口一个,eth0 和 eth1)、网关、子网掩码、域名、引导服务器的 IP 地址和引导文件的名称。使用 bpbatch(一种免费的预启动软件),无盘 CPU 将下载并启动 bpbatch 配置文件中指定的引导文件。引导文件是位于 bpbatch 服务器上 /tftpboot 目录下的内核镜像。最后,CPU 将下载 RAM 磁盘并启动 Apache Web 服务器。
Apache Web 服务器是 CPU 下载的 RAM 磁盘的一部分。因为我们有一个同构环境,所以所有 CPU 共享相同的配置文件并提供相同的内容,这些内容通过 NFS 提供。
为了进行基准测试活动,我们建立了一个硬件和软件基准测试环境。在硬件层面,我们使用了 18 台 Intel Celeron 500MHz 1U 机架式单元,每台配备 512MB RAM。这些机器用于使用 WebBench 生成 Web 流量,WebBench 是 zdnet.com 提供的免费工具。

图 3. WebBench 架构
WebBench 是一种用于测量 Web 服务器性能的软件工具。它由一个控制器和多个客户端组成(图 3)。控制器提供设置、启动、停止和监控 WebBench 测试的方法。它还负责收集和分析从客户端报告的数据(图 4)。另一方面,客户端执行 WebBench 测试并向服务器发送请求。
为了构建设置,我们决定使用带有磁盘的 CPU 作为 Linux Virtual Server,并使用运行 Apache 服务器的八个无盘 CPU 作为流量处理器。
如前所述,我们使用的是 Red Hat 6.2 提供的 Linux 内核。此内核附带 LVS 支持,因此无需在内核级别进行任何工作。我们只需要执行配置。对于那些喜欢 GUI 配置工具的人来说,他们会发现 LVS GUI 配置工具绝对是一个优势。它是一个完整的工具,用于设置和管理 LVS 环境,并且易于使用。但是,我们手动执行了配置——这只是个人偏好问题。
如果您没有使用 Red Hat(6.1 或更高版本)提供的内核,则需要构建一个新的内核并手动设置 IP 伪装和 IP 链规则。您构建的内核必须支持以下选项:网络防火墙、IP 转发/网关、IP 防火墙、IP 伪装、IP: ipportfw masq 和 Virtual Server 支持。
同时,您需要从以下调度算法中选择一个:加权轮询、最少连接或加权最少连接。
完成此操作后,您编译内核,更新系统并重新启动。使用新内核重新启动后,您需要为 NAT 调度器设置 IP 配置,其中包括设置一个别名 IP 地址以供从集群外部访问,以及为 NAT 路由器设置一个别名以供从集群内部访问,并在 NAT 调度器上启用 ip_forward 和 ip_always_defrag。
当我们完成这些步骤后,我们通过编辑 lvs.conf 文件配置了 LVS,并启动了 Red Hat 附带的 lvs 二进制文件。它为 LVS 服务器和真正的服务器执行了必要的 ipvsadm 命令。
请注意,如果您没有使用 Red Hat 发行版,则需要手动启动 ipvsadm 命令。之后,您需要使用 forward 和 MASQ 选项启动 ipchains。
如果您计划在 LAN 环境中部署 LVS,则在将真正的服务器与 LAN 的其余部分和外部世界隔离时必须小心。从任何真正的服务器到 Web 客户端都不能有直接路由。这非常重要,因为如果 HTTP 响应数据包通过 NAT 调度器以外的方式到达客户端,它们将被客户端丢弃。实现此目的的一种简单方法是构建您自己的私有子网,并将 NAT 调度器用作您连接到 LAN 其余部分的网关。
基准测试的目标是测试 LVS-NAT 实现的可扩展性。为此,我们进行了两种类型的测试:第一种是直接方法,包括直接向 CPU 发送流量;第二种方法是将流量定向到 NAT 调度器,NAT 调度器是 CPU 的前端服务器。
对于在没有 LVS 的情况下进行的测试,我们将 HTTP 请求直接发送到真正的服务器。WebBench 通过生成 Web 流量并将它们发送到多个服务器来支持此配置(图 5)。至于使用 LVS 的测试(图 6),我们将 WebBench 配置为将 HTTP 请求发送到 LVS 服务器(NAT 调度器),然后 LVS 服务器将流量定向到真正的服务器。

图 5. 没有 LVS 的基准测试设置

图 6. 带有 LVS-NAT 的基准测试设置
图 7 显示了我们的 LVS 设置能够实现的每秒请求数与没有 LVS 的直接设置的对比。它清楚地表明,一旦 LVS-NAT 实现达到每秒 2,000 个请求,就会在调度器级别遇到瓶颈。

图 7. LVS 与非 LVS 结果
我们决定进行第三次测试,仅使用一台机器通过 WebBench 生成流量。我们测得回答 HTTP 请求的延迟为 0.3 毫秒。LVS 成功处理了负载,每秒回答超过 178 个请求。
在分析结果后,我们得出结论,瓶颈问题是由于 LVS 调度器每秒可以处理的并发 TCP 连接数。结果表明,LVS 同时处理的最大连接数不超过每秒 1,790 个有效 TCP 连接。在不使用 LVS 的情况下,通过将请求直接发送到服务器,我们已经能够实现每秒超过 7,116 个有效 TCP 连接。我们计划在未来几周内更详细地调查这个问题。
LVS 的 NAT 实现有几个优点。首先,真正的服务器可以运行任何支持 TCP/IP 协议的操作系统,并且它们可以使用私有互联网地址。因此,整个设置只需要负载均衡器的一个 IP 地址。
但是,使用 NAT 实现的缺点是虚拟服务器的可扩展性。正如我们在基准测试中看到的那样,负载均衡器是整个系统的瓶颈。
通过 NAT 的 LVS 可以满足许多中小型服务器的性能请求。当负载均衡器成为瓶颈时,您需要考虑 LVS 提供的其他两种方法:IP 隧道或直接路由。
我们在一个工业环境中测试了 LVS,其中包含一台 LVS 服务器和八台流量 CPU。我们发现在重负载下使用 LVS 时存在一些限制。但是,我们也发现 LVS 易于安装和管理,并且非常有用。
我们认为 LVS 是需要基于软件的流量分配解决方案的中小型 Web 场的一个潜在解决方案。但是,对于我们正在构建的服务器类型,所需的每秒事务数高于 LVS 的 NAT 实现可以处理的数量。
LVS 的未来充满希望,它决心为通过 IP 隧道技术的虚拟服务器添加更多负载均衡算法和基于地理位置的调度。另一个有希望的未来特性是将心跳代码和 CODA 分布式容错文件系统集成到虚拟服务器中。LVS 的开发人员还计划探索更高程度的容错能力以及如何在 IPv6 中实现虚拟服务器。
与其他软件包相比,LVS 提供了许多独特的功能,例如支持多种调度算法和各种请求转发方法(NAT、直接路由、隧道)。我们关于 LVS 的下一步是尝试其他两种实现(直接路由和 IP 隧道),并将性能与相同设置下的 NAT 实现进行比较。
感谢加拿大爱立信研究院系统研究部批准发表本文。
感谢加拿大爱立信研究院的 Evangeline Paquin 对整体 LVS 相关活动的贡献。
感谢加拿大爱立信研究院的 Marc Chatel 在 ECUR 实验室提供的巨大帮助。
感谢 LVS 项目的 Wensong Zhang 允许使用 LVS 网站上的图 1 和图 2。

