MOSIX：Linux 集群负载均衡解决方案
在过去的几年中，软件集群技术一直在发展，并且由于几个原因，目前正获得巨大的发展势头。这些原因包括部署商品化的、现成的硬件（价格低廉的高性能 PC）的优势，使用廉价的高速网络（如快速以太网），以及使用 Linux 所带来的好处。Linux 似乎是一个极佳的选择，因为它具有强大的内核、提供的灵活性、支持的各种网络功能以及 IP 版本的早期可用性。
随着集群技术的日益普及，我们决定启动一个项目，旨在寻找并原型化必要的技术，以证明集群式 Linux 互联网服务器的可行性，该服务器应展现电信级特性。因此，一个明星诞生了，它被命名为 ARIES（互联网电子服务器高级研究）。
ARIES 于 2000 年 1 月在爱立信核心研究部门启动，其目标是使用 Linux 内核作为基础技术，并依靠开源软件来构建理想的系统，该系统应具有以下特性：保证可用性和响应时间、线性可扩展性、高性能以及在不影响其可用性的情况下维护系统的能力。
流量分配和负载均衡是两个主要的研究领域。遵循的策略是调查开源世界，检查这些领域中可用的解决方案，对其进行测试，并确定它们在多大程度上满足我们针对近电信级 Linux 互联网服务器的要求。
本文介绍了我们在 MOSIX（耶路撒冷希伯来大学开发的软件包）方面的经验。我们阐述了 MOSIX 技术、开发的算法及其运行方式，并描述了我们如何在实验性 Linux 集群上安装 MOSIX。我们还讨论了 MOSIX 的优势和劣势，以帮助其他人决定 MOSIX 是否适合他们。
MOSIX 是一个用于 Linux 的软件包，它将独立的 Linux 机器转换为一个集群，该集群像单个系统一样工作，并跨集群节点为特定进程执行负载均衡。MOSIX 的设计目的是增强 Linux 内核的集群计算能力，并为集群范围资源的有效管理提供手段。它由内核级的自适应资源共享算法组成，这些算法旨在实现高性能、无开销的可扩展性和易于使用可扩展的计算集群。
MOSIX 的核心是其使多个服务器节点协同工作，如同单个系统一部分的能力。MOSIX 的算法旨在通过将进程从一个节点迁移到另一个节点（抢占式和透明地）来响应节点之间资源使用情况的变化，从而实现负载均衡并防止任何节点出现内存耗尽。通过这样做，MOSIX 通过动态地在集群中的节点之间分配和重新分配工作负载和资源来提高整体性能。
MOSIX 对应用程序透明地运行，并允许顺序和并行应用程序的执行，而无需考虑进程在哪里运行或集群的其他用户在做什么。
在创建新进程后不久，MOSIX 会尝试将其分配给当时最佳的可用节点。然后，MOSIX 继续监视新进程以及所有其他进程，并在节点之间移动它，以最大化整体性能。这是在不更改 Linux 接口的情况下完成的，用户可以继续查看（和控制）他们的进程，就好像它们在本地节点上运行一样。
用户可以使用 QPS（一个贡献程序，不是 MOSIX 的一部分，但支持 MOSIX 特定的字段）来监视节点上的进程迁移和内存使用情况。QPS 是一个可视化进程管理器，是 “top” 和 “ps” 的 X11 版本，它在一个窗口中显示进程，并允许用户对其进行排序和操作。它支持特殊字段（见图 1），例如进程在哪个节点上启动、当前在哪个节点上运行、它正在使用的内存百分比及其当前工作目录。
图 1. QPS 支持的字段
由于 MOSIX 的算法是去中心化的，因此每个节点既是本地创建进程的主节点，又是从其他节点迁移过来的进程的服务器。这意味着可以随时向集群添加或从中删除节点，而对正在运行的进程的干扰最小。
MOSIX 通过更好地利用网络范围的资源并使系统更易于使用来提高整体性能。MOSIX 的系统映像模型基于主节点模型。在此模型中，所有用户的进程似乎都在用户登录节点上运行。每个新进程都在与其父进程相同的节点上创建。迁移的进程通过用户的主节点与用户环境交互，但在可能的情况下，它们使用本地资源。只要用户登录节点的负载保持在阈值以下，所有用户的进程都将被限制在该节点上。但是，当此负载升至阈值以上时，某些进程可能会（透明地）迁移到其他节点。
MOSIX 在当前负载最低的节点中调度新启动的程序。但是，如果负载级别最低的机器向集群中的所有节点宣布自己，则所有节点都会将新启动的作业迁移到负载最低的节点，并且很快该节点就会过载。但是，MOSIX 并非以这种方式运行。相反，每个节点都会将其当前负载状态发送到随机的节点列表。这可以防止单个节点被所有其他节点视为最空闲的节点，并防止任何节点过载。
MOSIX 如何决定哪个节点是所有集群节点中最空闲的节点？这是一个很好的问题；但是，答案很简单。
MOSIX 自带监控算法，可以检测每个节点的速度、已用和可用内存，以及每个进程的 IPC 和 I/O 速率。此信息用于就进程的放置位置做出接近最优的决策。这些算法非常有趣，因为它们尝试根据经济学原理和竞争分析来协调不同的资源（带宽、内存和 CPU 周期）。使用此策略，MOSIX 将内存和 CPU 等多种异构资源的总使用量转换为单个同构成本。然后将作业分配给成本最低的机器。此策略为计算、通信、内存和 I/O 资源的分配提供了一个统一的算法框架。它还允许开发用于分配和共享这些资源的接近最优的在线算法。
MOSIX 使用其自己的文件系统 MFS，使整个 MOSIX 集群中的所有目录和常规文件都可从所有节点访问，就像它们在单个文件系统内一样。MFS 的优势之一是，它通过在服务器磁盘节点维护一个缓存，为从不同节点查看的文件提供缓存一致性。
MFS 符合直接文件系统访问 (DFSA) 标准，该标准扩展了迁移进程在当前节点本地执行某些 I/O 操作的能力。此规定减少了 I/O 密集型进程与主节点通信的需求，从而允许此类进程（以及混合 I/O 和 CPU 进程）在集群的节点之间更自由地迁移，以进行负载均衡和并行文件和 I/O 操作。这也允许通过正确的文件分布进行并行文件访问，其中每个进程都迁移到具有其文件的节点。
通过满足 DFSA 规定，允许在进程的当前节点本地执行系统调用，MFS 减少了执行迁移进程的面向 I/O 的系统调用的额外开销。
为了测试 MOSIX，我们设置了以下环境：1) 一个机柜，由 13 个奔腾级 CPU 卡组成，每个卡以 233MHz 运行，配备 256MB RAM；以及 2) 一台基于奔腾的服务器机器 PC1，以 233MHz 运行，配备 256MB RAM。这台机器用作 13 个无盘 CPU 的 NFS 和 DHCP/TFTP 服务器。
当我们启动 CPU 时，它们从 LAN 启动并向网络上的所有地址广播 DHCP 请求。PC1（DHCP 服务器）将侦听并回复 DHCP 提供，并将向 CPU 发送配置网络设置所需的信息，例如 IP 地址（每个接口 eth0 和 eth1 各一个）、网关、网络掩码、域名、引导服务器 (PC1) 的 IP 地址和引导文件名。然后，CPU 将下载并引导 DHCP 配置文件中指定的引导文件，该文件是位于 PC1 上 /tftpboot 目录下的内核映像。接下来，CPU 将下载一个 ramdisk 并启动三个 Web 服务器（Apache、Jigsaw 和 TomCat）和两个流媒体服务器（Real System Server 和 IceCast Internet Radio）。
对于此设置，我们使用了 Red Hat 6.2 附带的 Linux Kernel 2.2.14-5.0。在我们进行此活动时，MOSIX 尚不可用于 Red Hat；因此，我们必须移植 MOSIX 以使其与 Red Hat 内核一起工作。我们的计划是准备一个 MOSIX 集群，该集群由服务器 PC1 和 13 个无盘 CPU 组成。因此，我们需要在服务器上有一个启用 MOSIX 的内核，并且我们希望在 TFTP 服务器目录下具有相同的启用 MOSIX 的内核映像，以便在启动时由 CPU 下载和启动。将 MOSIX 移植到 Red Hat 后，我们启动了 MOSIX 修改的安装脚本 “mosix.install”，该脚本将补丁应用于 PC1 上的 2.2.14-5.0 内核树。
完成内核配置并启用 MOSIX 功能（使用 $make xconfig）后，我们对其进行编译以获取内核映像
cd /usr/src/linux make clean ; make dep ; modules_install
接下来，我们将新的内核映像从 /usr/src/linux/arch/i386/boot 复制到 /boot，并更新了 System.map 文件
cp /usr/src/linux/arch/i386/boot/bzImage cp /usr/src/linux/arch/i386/boot/System.map ln /boot/System.map.mosix /boot/System.map修改的配置文件之一是 lilo.conf。我们为 MOSIX 内核添加了一个新条目，以使服务器默认启动为 MOSIX 节点。PC1 上更新的 lilo.conf 如列表 1 所示。
完成此操作后，我们需要完成配置步骤。在 /etc/profile 中，我们添加了一行来指定 MOSIX 集群中的节点数
# Add to /etc/profile NODES=1-14
我们创建了 /etc/mosix.map，允许本地 MOSIX 节点查看所有其他 MOSIX 节点。mosix.map 如下所示
# Starting node IP Number of Nodes 1 x.x.x.x 13 14 y.y.y.y 1我们创建了 /mfs 目录，用作 MOSIX 文件系统的挂载点。我们将 mosix.o 添加到 /lib/modules/2.2.14-5.0/misc/，以便可以在启动时由 MOSIX 启动文件加载。然后，我们将相同的修改应用于将在启动时由无盘 CPU 下载的 ramdisk。
完成这些步骤后，我们重新启动了 PC1，当它启动并运行时，我们重新启动了无盘 CPU。重新启动后，无盘 CPU 接收到它们的 IP 地址，使用启用 MOSIX 的内核启动，并使用 TFTP 协议下载了 ramdisk。 瞧！ 所有 14 个节点都将 /mfs 挂载为 MOSIX 文件系统目录。图 2 显示了 CPU10 上 /mfs 的快照。
图 2. CPU10 上的 MFS 挂载点
在将 14 个节点作为 MOSIX 集群启动后，我们想要测试我们的安装。默认情况下，所有无盘 CPU 都在 PC1 上挂载一个 NFS 目录。因此，我们将 Linux 内核 2.2.14 源代码目录放在该 NFS 空间下，使其对所有节点可见，并使用 MExec/MPMake（并行 make，一种贡献软件，可将新进程分配给最佳可用集群节点（可从 MOSIX 网站下载））启动内核编译过程。
图 3、4、5 和 6 显示了 mon（一个 MOSIX 工具，显示所有节点上的负载）的快照。如图 3 所示，节点 14 上的负载很高，因为它是编译启动的节点。几秒钟后，图 4 和 5 显示 CPU 14 上的负载较小，然后图 6 显示了负载在所有节点之间的良好分布。
图 3、4、5 和 6. 工作中的 MOSIX 分配负载
可扩展性
MOSIX 支持具有大量计算机的配置，且最小的扩展开销不会损害性能。您可以拥有由通过以太网连接的几台 PC 组成的简单低端设置，另一方面，您可以拥有更大的配置，其中包括通过更高速 LAN（如快速以太网）连接的工作站和服务器。高端配置还可以包括通过高性能 LAN（如千兆以太网）连接的大量 SMP 和非 SMP 工作站和服务器。
我们的最后一个实验将包括在一个新的自包含 NEBS 兼容机柜上测试 MOSIX，该机柜由 16 个奔腾 III 处理器供电，配备 512MB RAM，以 500MHz 运行。每个 CPU 都有两个板载以太网端口，并且还与一个四端口 ZNYX 以太网卡配对（用于提供以太网冗余）。八个 CPU 具有 RAID 设置（RAID 0 和 RAID 5），配备三个 18GB SCSI 磁盘。
MOSIX 允许我们卸载并清理它修改过的内核源代码。在初始安装期间，mosix.install 修改了以下系统配置文件：/etc/inittab、/etc/inetd.conf、/etc/lilo.conf、/etc/rc.d/init.d/atd 和 /etc/cron.daily/slocate.cron。
这些文件的原始内容以 .pre_mosix 扩展名保存，对内核文件所做的更改记录到内核源代码目录中的 mos_uninstall.log 文件中。要卸载 MOSIX，请运行命令 ./mosix.install uninstall 并回答问题。当询问您是否要清理 Linux 内核源代码时，回答 “yes”。然后，脚本将尝试还原先前 MOSIX 安装期间所做的所有更改。最后，您需要重新启动节点，以便将其启动为普通 Linux 节点。
集群提供了几个优势，这些优势导致资源共享和实现更高性能的能力。如果您对使用高效负载均衡软件集群服务器感兴趣，并且需要高性能支持，那么 MOSIX 当然对您有用。它易于安装和配置，并且可以工作。
但是，我们最初对 MOSIX 的兴趣是了解其算法并研究将其用于有效分配跨多个处理器的 Web 流量的可能性。我们发现 MOSIX 不直接适用于我们为近电信互联网服务器原型所期望的功能类型，主要是因为它缺少用于面向事务的负载均衡的前端工具，例如 HTTP 请求。
在 MOSIX 邮件列表中，有许多关于使用 MOSIX 进行 HTTP 流量分配的请求。我相信，如果作者将此功能添加到 MOSIX 中，MOSIX 将成为 Linux 集群最流行的软件包之一。
Evangeline Paquin (lmcevpa@lmc.ericsson.se) 是蒙特利尔 UQAM 大学的计算机科学学生。她在爱立信加拿大研究公司完成了 Linux 集群解决方案的合作培训，目前她是系统研究部的兼职员工。
