Linux 集群大全

原贴：http://www.ibm.com/developerworks/cn/linux/cluster/lw-clustering.html

Rawn Shah, LinuxWorld 专栏作家

2000 年 5 月 01 日 Rawn Shah 作为专家，在 Linux 现有的开放源码和封闭源码集群解决方案方面为您指点迷津。

计算 Linux 中集群项目的数量就象计算硅谷中创业公司的数量一样。不象 Windows NT 已经受其自身的封闭环境阻碍，Linux 有大量的集群系统可供选择，适合于不同的用途和需要。但确定应该使用哪一个集群的工作却没有因此变得简单。

问题的部分原因在于术语集群用于不同场合。IT 经理可能关心如何使服务器运行时间更长，或使应用程序运行得更快，而数学家可能更关心在服务器上进行大规模数值计算。两者都需要群集，但是各自需要不同特性的群集。

本文调查了不同形式的集群以及许多实现中的一部分，这些实现可以买到，也可以免费软件形式获得。尽管列出的所有解决方案并不都是开放源码，但是大多数软件都遵循分发 Linux 源码的公共惯例，特别是由于那些实现集群的人还常常希望调整系统性能，以满足需要。

硬件

集群总是涉及到机器之间的硬件连接。在现今大多数情况下，这只是指“快速以太网”网卡和集线器。但在尖端科学领域中，有许多专为集群设计的网络接口卡。

它们包括 Myricom 的 Myrinet、Giganet 的 cLAN 和 IEEE 1596 标准可伸缩一致接口 (SCI)。那些卡的功能不但在群集的节点之间提供高带宽，而且还减少延迟（发送消息所用的时间）。对于在节点间交换状态信息以使其操作保持同步情况，那些延迟是至关重要的。

Myricom

Myricom 提供网卡和交换机，其单向互连速度最高可达到 1.28 Gbps。网卡有两种形式，铜线型和光纤型。铜线型 LAN 可以在 10 英尺距离内以全速进行通信，而在长达 60 英尺距离内以半速进行操作。光纤型 Myrinet 可以在 6.25 英里长的单模光纤或者 340 英尺长的多模光纤上全速运行。Myrinet 只提供直接点到点、基于集线器或基于交换机的网络配置，但在可以连接到一起的交换光纤数量方面没有限制。添加交换光纤只会增加节点间的延迟。两个直接连接的节点之间的平均延迟是 5 到 18 微秒，比以太网快得多。

集群类型

最常见的三种群集类型包括高性能科学群集、负载均衡群集和高可用性群集。

科学群集

通常，第一种涉及为群集开发并行编程应用程序，以解决复杂的科学问题。这是并行计算的基础，尽管它不使用专门的并行超级计算机，这种超级计算机内部由十至上万个独立处理器组成。但它却使用商业系统，如通过高速连接来链接的一组单处理器或双处理器 PC，并且在公共消息传递层上进行通信以运行并行应用程序。因此，您会常常听说又有一种便宜的 Linux 超级计算机问世了。但它实际是一个计算机群集，其处理能力与真的超级计算机相等，通常一套象样的群集配置开销要超过 $100,000。这对一般人来说似乎是太贵了，但与价值上百万美元的专用超级计算机相比还算是便宜的。

负载均衡群集

负载均衡群集为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机群集中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理 负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。 对于网络流量也是如此。通常，网络服务器应用程序接受了太多入网流量，以致无法迅速处理，这就需要将流量发送给在其它节点上运行的网络服务器应用。还可以 根据每个节点上不同的可用资源或网络的特殊环境来进行优化。

高可用性群集

高可用性群集的出现是为了使群集的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性群集中的主节点发生了故障，那么这段时间内将由次节 点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。

在群集的这三种基本类型之间，经常会发生混合与交杂。于是，可以发现高可用性群集也可以在其节点之间均衡用户负载，同时仍试图维持高可用性程度。同样，可 以从要编入应用程序的群集中找到一个并行群集，它可以在节点之间执行负载均衡。尽管集群系统本身独立于它在使用的软件或硬件，但要有效运行系统时，硬件连 接将起关键作用。

Giganet

Giganet 是用于 Linux 平台的虚拟接口 (VI) 体系结构卡的第一家供应商，提供 cLAN 卡和交换机。VI 体系结构是独立于平台的软件和硬件系统，它由 Intel 开发，用于创建群集。它使用自己的网络通信协议在服务器之间直接交换数据，而不是使用 ip，并且它并不打算成为 WAN 可路由的系统。现在，VI 的未来取决于正在进行的“系统 I/O 组”的工作，这个小组本是 Intel 领导的“下一代 I/O”小组与 IBM 和 Compaq 领导的“未来 I/O 小组”的合并。Giganet 产品当前可以在节点之间提供 1 Gbps 单向通信，最小延迟为 7 微秒。

IEEE SCI

IEEE 标准 SCI 的延迟更少（低于 2.5 微秒），并且其单向速度可达到 400 MB／秒 (3.2 Gbps)。SCI 是基于环拓扑的网络系统，不像以太网是星形拓扑。这将使在较大规模的节点之间通信速度更快。更有用的是环面拓扑网络，它在节点之间有许多环形结构。两维环面可以用 n 乘 m 的网格表示，其中在每一行和每一列都有一个环形网络。三维环面也类似，可以用三维立体节点网格表示，每一层上有一个环形网络。密集超级计算并行系统使用环面拓扑网络，为成百上千个节点之间的通信提供相对最快的路径。

大多数操作系统的限制因素不是操作系统或网络接口，而是服务器的内部 PCI 总线系统。几乎所有台式 PC 通常有基本 32-位，33-MHz PCI，并且大多数低端服务器只提供 133 MB／秒 (1 Gbps)，这限制了那些网卡的能力。一些昂贵的高端服务器，如 Compaq PRoliant 6500 和 IBM Netfinity 7000 系列，都有 64-位， 66-MHz 网卡，它们能够以四倍速度运行。不幸地是，矛盾是更多公司使用低端的系统，因此大多数供应商最终生产和销售更多低端 PCI 网卡。也有专门的 64-位，66-MHz PCI 网卡，但价格要贵许多。例如，Intel 提供了这种类型的“快速以太网”网卡，价格约 400到$400 到$500，几乎是普通 PCI 版本价格的 5 倍。

科学群集

某些并行群集系统可以达到如此高的带宽和低延迟，其原因是它们通常绕过使用网络协议，如 TCP/IP。虽然网际协议对于广域网很重要，但它包含了太多的开销，而这些开销在节点相互已知的封闭网络群集中是不必要的。其实，那些系统中有一部分可以在节点之间使用直接内存访问 (DMA)，它类似于图形卡和其它外围设备在一台机器中的工作方式。因此横跨群集，可以通过任何节点上的任何处理器直接访问一种形式的分布式共享内存。它们也可以使用低开销的消息传递系统，在节点之间进行通信。

消息传递接口 (MPI) 是并行群集系统间消息传递层的最常见实现。MPI 存在几种衍生版本，但在所有情况下，它为开发者访问并行应用程序提供了一个公共 API，这样开发者就不必手工解决如何在群集的节点之间分发代码段。其中一个，Beowulf 系统首先将 MPI 用作公共编程接口。

很难决定使用哪种高性能集群包。许多都提供类似服务，但计算的具体要求才是决定性因素。很多情况下，在那些系统中的研究工作只是解决需求的一半，而且使用那些软件需要集群包开发者的特殊帮助和合作。

Beowulf

当谈到 Linux 集群时，许多人的第一反映是 Beowulf。那是最著名的 Linux 科学软件集群系统。没有一个包叫做 Beowulf。实际上，它是一个术语，适用于在 Linux 内核上运行的一组公共软件工具。其中包括流行的软件消息传递 API，如“消息传送接口”(MPI) 或“并行虚拟机”(PVM)，对 Linux 内核的修改，以允许结合几个以太网接口、高性能网络驱动器，对虚拟内存管理器的更改，以及分布式进程间通信 (DIPC) 服务。公共全局进程标识空间允许使用 DIPC 机制从任何节点访问任何进程。Beowulf 还在节点间支持一系列硬件连通性选件。

Beowulf 可能是考虑 Linux 时注意到的第一个高性能集群系统，这只是因为它的广泛使用和支持。关于这个主题，有许多文档和书籍。Beowulf 与以下一些科学集群系统之间的差异可以是实际的，或者只是在产品名称中有差异。例如，尽管名称不同，Alta Technologies 的 AltaCluster 就是一个 Beowulf 系统。某些供应商，如 ParTec AG，一家德国公司，提供了 Beowulf 模型的衍生版本，以包括其它管理接口和通信协议。

Giganet cLAN

Giganet 提供了一种定制的基于硬件的解决方案，它使用非 IP 协议在一个科学群集的节点间进行通信。如前所述，“虚拟接口”协议通过除去不少协议的开销，如 IP，以支持服务器间更快的通信。另外，硬件系统可按千兆比特速度运行，并且延迟很短，使它非常适合构建最多达 256 个节点的科学群集。该供应商支持 MPI，这样许多并行应用程序就可以在类似的系统（如 Beowulf）上运行。

它也有 Beowulf 的缺点，即不能用作网络负载共享系统，除非想要编写应用程序来监控和分发在服务器间传送的网络包。

Legion

Legion 试图构建一个真正的多计算机系统。这是一个群集，其中每个节点都是一个独立系统，但在用户看来，整个系统只是一台计算机。Legion 设计成支持一台世界范围的计算机，由上百万个主机以及数以万亿计的软件对象组成。在 Legion 中，用户可以创立他们自己的合作小组。

Legion 提供了高性能并行、负载均衡、分布式数据管理和容错性。

Legion 提供了高性能并行、负载均衡、分布式数据管理和容错性。它通过其容错管理和成员节点间的动态重新配置来支持高可用性。它还有一个可扩充核心，该核心可以在 出现新的改进和进展时动态替换或升级。系统并不是只接受单一控制，而是可以由任意数量的组织管理，而每个组织都支持整体的自治部分。Legion API 通过其内置的并行性提供了高性能计算。

Legion 需要使用特别编写的软件，以使它可以使用其 API 库。它位于用户计算机操作系统之上，协调本地资源和分布式资源。它自动处理资源调度和安全性，还管理上下文空间以描述和访问整个系统中上亿种可能之外的对象。然而，在每个节点上运行时，不需要使用系统管理员特权，并且可以使用无特权的用户帐号进行工作。这将增加加入 Legion 的节点和用户的灵活性。

Cplant

Sandia National Lab 中的 Computational Plant 是一个大规模整体并行群集，用于实现 TeraFLOP（万亿次浮点运算）计算并构建在商业组件上。整个系统由“可伸缩单元”组成，这些“可伸缩单元”可以划分成适合不同目的（计算、磁盘 I/O、网络 I/O、服务管理）。群集中的每个节点都是一个 Linux 系统，带有专门开发的、提供分区服务的内核级模块。每个分区的功能可以通过装入和卸载内核级模块来修改。

项目分三个阶段完成，开始阶段是原型，有 128 个基于 433-MHz DEC Alpha 21164 的系统，其中每个都有 192 MB RAM 和 2 GB 驱动器，相互之间用 Myrinet 网卡和 8-端口的 SAN 交换机连接。第 1 阶段将它扩充为 400 个基于 21164 的工作站，这些工作站的运行速度为 500 MHz，有 192 MB RAM，没有存储器，用 16-端口的 SAN 交换机以超立方体结构连接起来，并且运行 Red Hat 5.1。当前的第 2 阶段有 592 台基于 DEC 21264 的机器，它们的运行速度为 500 MHz，有 256 MB RAM，没有驱动器。每个节点都使用 64-位，33-MHz PCI Myrinet 网卡，并且仍使用 16-端口交换机以超立方体结构连接。

在 Cplant 上运行的应用程序包括解决稀疏线性系统、流体力学和结构力学中计算系统的优化、分子力学的模拟、线性结构力学的有限元分析，以及并行应用程序的动态负载均衡库。

JESSICA 2

香港大学的系统研究小组有一个基于 java 的群集，叫做支持 Java 的单系统映像计算体系结构 (JESSICA)，它作为一个中间件层以完成单系统映像的幻想。该层是每个使用分布式共享内存 (DSM) 系统进行通信的节点上运行的所有线程的一个全局线程空间。该项目使用 ThreadMark DSM，但最终将用他们自己创建的 JiaJia Using Migrating-home Protocol (JUMP)。他们使用定制的基于 Java 的 ClusterProbe 软件来管理群集的 50 个节点。

PARIS

法国的 IRISA 研究所的“大规模数字模拟应用程序的编程并行和分布式系统”(PARIS) 项目提供了几种用于创建 Linux 服务器群集的工具。该项目由三部分组成：群集的资源管理软件、并行编程语言的运行时环境，以及分布式数字模拟的软件工具。

资源管理软件包括用于共享内存、磁盘和处理器资源的 Globelins 分布式系统，及其 Dupleix 和 Mome 分布式共享内存系统。

负载均衡群集

负载均衡群集在多节点之间分发网络或计算处理负载。在这种情况下，区别在于缺少跨节点运行的单并行程序。大多数情况下，那种群集中的每个节点都是运行单独 软件的独立系统。但是，不管是在节点之间进行直接通信，还是通过中央负载均衡服务器来控制每个节点的负载，在节点之间都有一种公共关系。通常，使用特定的 算法来分发该负载。

网络流量负载均衡是一个过程，它检查到某个群集的入网流量，然后将流量分发到各个节点以进行适当处理。它最适合大型网络应用程序，如 Web 或 FTP 服务器。负载均衡网络应用服务要求群集软件检查每个节点的当前负载，并确定哪些节点可以接受新的作业。这最适合运行如数据分析等串行和批处理作业。那些系统还可以配置成关注某特定节点的硬件或操作系统功能：这样，群集中的节点就没有必要是一致的。

Linux 虚拟服务器

“Linux 虚拟服务器”项目已经实现了许多内核补丁，它们为入网 TCP/IP 流量创建了负载均衡系统。LVS 软件检查入网流量，然后根据负载均衡算法，将流量重定向到一组充当群集的服务器。这允许网络应用程序，如 Web 服务器，在节点群集上运行以支持大量用户。

LVS 支持作为负载均衡服务器直接连接到同一个 LAN 的群集节点，但它还能够以通道传送 IP 包的方式连接到远程服务器。后一种方法包括压缩 IP 包中的均衡请求，这些 IP 信息包从负载均衡服务器直接发送到远程群集节点。尽管 LVS 可以远程支持网站的负载均衡，但它使用的负载均衡算法现在对于虚拟群集中的广域 Web 服务器仍无效。因此，如果 Web 服务器都在同一个 LAN 中，LVS 最好当作负载均衡服务器使用。

负载均衡系统的几种硬件实现比在通用操作系统，如 Linux，上运行得更快。它们包括来自 Alteon 和 Foundry 的硬件，其硬件逻辑和最少操作系统可以在硬件中执行流量管理，并且速度比纯软件快。它们的价格也很高，通常都在 $10,000 以上。如果需要简单和便宜的解决方案，一个有很多内存 (256 MB) 的中等 Linux 系统将会是一个好的负载均衡系统。

TurboLinux TurboCluster 和 enFuzion

TurboLinux 有一个产品叫 TurboCluster，它最初以“Linux 虚拟服务器”项目开发的内核补丁为基础。因此，它可以得到大部分优点，但它的缺点也与原来的项目一样。TurboLinux 为此还开发了一些工具，用于监控增加产品实用性的群集行为。一家主要供应商的商业支持也使它对于大型网站更具吸引力。

EnFuzion 支持在节点之间实现自动负载均衡和资源共享，而且可以自动重新安排失败的作业。

EnFuzion 是 TurboLinux 即将推出的科学群集产品，它并不基于 Beowulf。但是，它可以支持上百个节点以及许多不同的非 Linux 平台，包括 Solaris、Windows NT、HP-UX、IBM AIX、SGI Irix 和 Tru64。EnFuzion 非常有趣，因为它运行所有现有软件，并且不需要为环境编写定制的并行应用程序。它支持在节点间实现自动负载均衡和资源共享，而且可以自动重新安排失败的作业。

Platform Computing 的 LSF 批处理

Platform Computing 是群集计算领域的老手，现在提供了 Linux 平台上的“负载均衡设施 (LSF) 批处理”软件。LSF 批处理允许中央控制器安排作业在群集中任意数量的节点上运行。在概念上，它类似于 TurboLinux enFuzion 软件，并且支持在节点上运行任何类型的应用程序。

这种方法对于群集大小是非常灵活的，因为可以明确选择节点的数量，甚至是运行应用程序的节点。于是，可以将 64 个节点的群集分成更小的逻辑群集，每个逻辑群集都运行自己的批处理应用程序。而且，如果应用程序或节点失败，它可以在其它服务器上重新安排作业。

Platform 的产品在主要 Unix 系统和 Windows NT 上运行。目前，只有它们的 LSF 批处理产品已经移植到 Linux 上。最终，LSF Suite 组件的其余部分也将紧随其后移植到 Linux 上。

Resonate Dispatch 系列

Resonate 有一种基于软件的负载均衡方法，类似于 Linux 虚拟服务器。但是，它支持更多特性，以及一些更好的负载均衡算法。例如，使用 Resonate，可以在每个群集节点装入一个代理，以确定该节点当前的系统负载。然后，负载均衡服务器检查每个节点的代理，以确定哪个节点的负载最少，并且将新的流量发送给它。另外，Resonate 还可以使用它的 Global Dispatch 产品更有效地支持地区性分布式服务器。

Resonate 已经在 Red Hat Linux 上彻底测试了该软件，相信它也可以在其它发行版上运行。Resonate 的软件还可以在其它各种平台上运行，包括 Solaris、AIX、Windows NT，并且它还可以在混合环境中进行负载均衡。

MOSIX

MOSIX 使用 Linux 内核新版本来实现进程负载均衡集群系统。该群集中，任何服务器或工作站可以按指定加入或离开，即添加到群集的总处理能力，或从中除去。根据其文档，MOSIX 使用自适应进程负载均衡和内存引导算法使整体性能最大化。应用程序进程可以在节点之间抢先迁移，以利用最好的资源，这类似于对称多处理器系统可以在各个处理器之间切换应用程序。

MOSIX 在应用层是完全透明的，并且不需要重新编译或者重新链接到新的库，因为所有一切都发生在内核级上。可以有几种方法将它配置成多用户共享环境群集。所有服务 器可以共享一个池，系统可以是群集的一部分，或者群集可以动态地分成几个子群集，每种方法都有不同的用途。Linux 工作站还可以是群集的一部分，可以是固定的，也可以是临时的，或者只是作为批处理作业提交者。作为临时群集节点，工作站可以在其空闲时用于增加群集处理能 力。也允许只以批处理方式使用群集，在这种方式中，群集被配置成通过队列接受批处理作业。然后，守护程序取走作业并将它们发送到群集节点进行处理。

MOSIX 的不利之处是它更改 Linux 内核行为的一些核心部分，于是系统级应用程序将不会按期望运行。

除了高性能科学计算，MOSIX 提供了一个有趣的选项，用于以共同设置创建集群环境。通过使用服务器和工作站上的闲置资源，它可以更快更有效地创建和运行应用程序。由于访问了多台服务器，并且可以动态调整群集大小和更改负载均衡规则，它还可以提供高度的服务器可用性。MOSIX 的不利之处是它更改 Linux 内核行为的一些核心部分，于是系统级应用程序将不会按期望运行。要使用网络应用程序时，而该程序使用基于单个服务器地址的套接字连接，MOSIX 通常也会受到限制。这意味着网络应用程序在一个服务器节点上开始运行时，如果 IP 地址与套接字绑定，那么它必须继续在该节点上运行。显然，MOSIX 还正在开始迁移套接字，因此这很快就变成了争论的焦点。

高可用性群集

高可用性 (HA) 群集致力于使服务器系统的运行速度和响应速度尽可能快。它们经常使用在多台机器上运行的冗余节点和服务，用来相互跟踪。如果某个节点失败，它的替补将在几秒钟或更短时间内接管它的职责。因此，对于用户而言，群集永远不会停机。

某 些 HA 群集也可以维护节点间冗余应用程序。因此，用户的应用程序将继续运行，即使他或她使用的节点出了故障。正在运行的应用程序会在几秒之内迁移到另一个节点， 而所有用户只会察觉到响应稍微慢了一点。但是，这种应用程序级冗余要求将软件设计成具有群集意识的，并且知道节点失败时应该做什么。但对于 Linux，大多数现在还做不到。因为 Linux 系统没有 HA 集群标准，并且也没有公共 API 可供应用程序开发者构建有群集意识的软件。

HA 群集可以执行负载均衡，但通常主服务器运行作业，而系统使辅助服务器保持闲置。辅助服务器通常是主服务器操作系统设置的镜像，尽管硬件本身稍有不同。辅助 节点对主服务器进行活动监控或心跳观察，以查看它是否仍在运行。如果心跳计时器没有接收到主服务器的响应，则辅助节点将接管网络和系统身份（如果是 Linux 系统，则是 IP 主机名和地址）。

但是，Linux 在这一领域仍有一点忽略。好消息是有一家著名的供应商正在努力尽快研制高可用性群集，因为它是企业级服务器都必需的功能。

Linux-HA 项目

高可用性 Linux 项目，根据其目标声明，旨在为 Linux 提供高可用性解决方案，以通过社区开发成果提高可靠性、可用性和服务能力。Linux 达到高可用性集群时，这是一种试图给予 Linux 与先进的 Unix 系统，如 Solaris、AIX 和 HP/UX，一样具有竞争力的特性。因此，项目的目标是在 2001 年之前达到 Unix 集群比较报告 ( http://www.sun.com/clusters/dh.brown.pdf) 中分析专家组 D. H. Brown 特定功能性级别。

项目中有可以维护节点间心跳并接管失败节点的 IP 地址的软件。如果一个节点失败，它使用“伪造冗余 IP”软件包将失败节点的地址添加到工作节点以承担它的职责。于是，可以在几毫秒时间内自动替换失败的节点。实际使用中，心跳通常在几秒范围内，除非在节点之间有专用网络链接。因此，失败系统中的用户应用程序仍需要在新的节点上重新启动。

无处不在的集群

对于 Linux，有许多集群系统可供选用。同时，那些项目中有几个是非商业性的，甚至是实验性质的。虽然对学术界和某些组织这也没有形成问题，但大公司通常首选著名供应商的商业支持平台。供应商，如 IBM、SGI、HP 和 Sun，提供了用于在 Linux 中构建科学群集的产品和服务，因为群集很流行，并且可以销售大量的服务器设备。一旦商业机构认为其它形式的集群是可靠的，那些相同的服务器供应商或许会围绕着开放源码集群解决方案创建自己的产品。

Linux 作为服务器平台的重要性依赖于支持大型服务器和服务器群集的能力。这就使它可以与 Sun、HP、IBM 和其它公司的 UNIX 服务器在更高层面上竞争。虽然 Windows NT 和 2000 不支持 Linux 能够支持的集群范围，但是 HA 集群正规方法的可用性以及用于构建有群集意识的 API 也使它能够参与竞争。

如果正在考虑构建一个群集，那么您应当仔细检查那些可能性，并将它们与您的需求做比较。您也许会发现想要实现的目标还不能成为一个完整的解决方案，或许会发现已经有了现成的解决方案。不管是哪种情况，请相信许多现有公司将他们的应用程序托付给进行深度计算并提供大量网页的 Linux 系统群集。集群是一种企业系统服务，已经在 Linux 下成功测试过。尽管新的集群将出现，但选择的多样性正是 Linux 超过其它系统，如 Windows NT，的优势。 经由 LinuxWorld 杂志授权重印。Copyright Web Publishing Inc., IDG 通信公司的子公司。 请注册以加入编者的邮件列表。

关于作者

Rawn Shah 是居住在亚利桑那州图森市的一位独立顾问。他多年来与多平台问题打交道并撰写相关文章，但常常令他不解的是很少有人知道有用的系统工具。

========================================================= 随着Internet技术的迅猛发展，网络技术、性能的不断提高，高可伸缩性、高可用性、可管理性、价格有效性的网络服务技术将成为网络服务技术的主导。各 种平台下的技术方案应运而生。本文试图以一篇完整的理论+实践性的文字来介绍如何在优秀的开源操作系统Linux下创建低成本、高性能、高可用的服务集群 系统。文中所使用的系统和软件包均为最新版本。希望通过对本文的阅读能使你对如何创建Linux下的集群系统有所帮助。

1.Linux下的解决方案

Linux下的集群系统通常可以分为三类：

HA容错集群 (Fail-over Cluster)

高可用性集群（High available）用于不可间断服务的环境下。提供冗余的容错备份，在主节点失效后，能够立即接管相关资源及继续提供相应服务。

负载均衡集群 (Load Balancing Cluster)在应用服务的高负载情况下运用该技术，由多台节点提供高可伸缩的，高负载的服务器组。以保证对外提供良好的服务响应。

HPC高性能计算机集群 (High Performance Computing)

本文所要介绍的是前两类集群的一个完美的组合。

1.1. Linux Virtual Server项目

在1998 年5月，由章文嵩博士成立了Linux Virtual Server的自由软件项目，进行Linux服务器集群的开发工作。同时，Linux Virtual Server项目也是国内最早出现的自由软件项目之一。该项目针对高可伸缩、高可用网络服务的需求，给出了基于IP层和基于内容请求分发的负载平衡调度解 决方法，它通过前端一个负载调度器（Load Balancer）无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、 高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检测节点或服务进 程故障和正确地重置系统达到高可用性。并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。

虚拟服务器的体系结构如图2所示。

图2：虚拟服务器的结构

1.1.1. LVS的核心软件IPVS

在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）VS/NAT技术的基础上，IPVS软件实现了三种IP负载均衡技术：

1)Virtual Server via Network Address Translation（VS/NAT） 网络地址转换 (如图1) 2)Virtual Server via IP Tunneling（VS/TUN） 隧道技术 (如图2) 3)Virtual Server via Direct Routing（VS/DR） 直接路由 (如图3)

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下十种负载调度算法：

其中9－10是最新1.09版IPVS软件包中新增的调度算法，这十种调度算法将会在后面的ipvsadm配置文件中用到，通常用英文单词的第一个字母的缩写来表示。例如：轮叫（Round Robin）表示为rr。

三种IP负载均衡技术的优缺点比较

服务器(OS) 任意 支持隧道 多数(支持Non-arp ) 服务器网络 私有网络 局域网/广域网 局域网 服务器数目(100M网络) 10~20 100 多(100) 服务器网关 负载均衡器 自己的路由 自己的路由 效率 一般 高 最高

三种IP负载均衡技术中特别是后两种技术VS/TUN，VS/DR极大地提高系统的伸缩性，它们的相关技术原理不是本文讨论的重点，若需了解详细内容，请参看章文嵩博士的相关撰文。

图1

图2

图3

1.2. High Availability of LVS

较为成熟的方案有mon+heartbeat+fake+coda 和ldirectord+heartbeat 方案，本文我们采用的是ldirectord+heartbeat 方案。

1.2.1. Heartbeat

Linux-HA 项目开始于 1998 年，是 Linux-HA HOWTO（Haranld Milz 著）的产物。该项目目前由 Alan Robertson 领导，许多其他代码提供者也参与其中。1.0.3版本是2003年6月发布的最新稳定版本。

Heartbeat 通过通信介质（通常是串行设备和以太网）监控节点的”健康”状况。最好有多个冗余介质，以便我们既可以使用串行线又可以使用以太网链接。每个节点运行一个 守护程序进程（称为”心跳”）。主守护程序派生出读和写每个心跳介质的子进程，以及状态进程。当检测到某个节点发生故障时，Heartbeat 运行 shell 脚本来启动（或停止）辅助节点上的服务。按照设计，这些脚本使用与系统 init 脚本（通常位于 /etc/init.d 中）相同的语法。缺省脚本是为文件系统、Web 服务器和虚拟 IP 故障转移提供的。

1.2.2. Ldirectord

“ldirectord”(Linux Director Daemon)是Jacob Rief编程实现的一个独立进程，以实现对服务和物理服务器的监测，广泛地用于http和https等服务, Ldirectord与mon相比，优点如下：

ldirectord是专门为LVS 监控而编写的。

ldirectored可以方便地被heartbeat管理启动和停止。

它能从heartbeat的配置文件/etc/ha.d/xxx.cf中读取所有有关IPVS路由表配置的信息。当 ldirectord 运行后,IPVS路由表将被适当地配置。你也可以将不同的虚拟服务器配置保存在不同的配置文件里, 所以你可以单独修改某种服务的参数而不用停止其它的服务

1.2.3. ldirectord+heartbeat的绝妙组合

ldirectord +heartbeat方案前端负载调度器采用双机热备份方式，双机均安装双网卡，一个网卡用于连接集群系统，另一个作为冗余心跳线路连接双机。采用串口线 ＋ 以太网口做为冗余心跳线路，以确保双机热备份的可靠性，消除由于主负载调度器或心跳线故障带来的集群单点故障。

在主负载 调度器及备份负载调度器同时安装ldirectord及heartbeat，并同时运行Heartbeat，相互监视”健康”状况，一旦备份负载调度器监 测到主负载调度器发生故障，备份服务器通过运行shell脚本来启动备份调度器上服务来完成虚拟 IP 故障转移，通过ipvsadm启动LVS及ldirectord，完成负载调度器的整体接管。一旦主负载调度器恢复正常工作，备份负载将通过脚本停掉备份 负载调度器上的LVS及ldirectord，同时完成虚拟 IP 故障转移，主负载调度器重新恢复接管LVS及ldirectord监控服务。这样负载调度器就完成了一个标准的接管及恢复过程。

该方案结构清晰明了，安装简便，并且ldirectord是专门为LVS所开发，针对性强，无缝衔接，配合默契，堪称绝妙组合。

2. LVS在Red Hat 9.0上的具体实现

2.1. 实现目标：

实 现以常用、效率最高的LVS-DR IP负载技术为基础，以高可用性（HA）＋ 高性能 ＋ 高性能/价格比 ＋ 高可伸缩性为最终目的。负载均衡器采用HA技术构架，采用Heartbeat软件包，heartbeat采用串口、网络口冗余线路，保证24X7不间断运 行。结构如图：

Setup LVS using LVS-DR forwarding

2.2. 设备要求：

因 为负载均衡器和真实服务器节点均有软硬件冗余保障，所以硬件设备可以根据具体资金情况及提供服务规模而定。当然最好采用支持RAID，SCSI，内存 ECC校验，热插拔等技术的专用服务器，以提供稳定高效的服务。对于非关键业务服务，也可以考虑采用最新支持IDE RAID(0,1,0＋1,1.5,5)的服务器，可以获得一个良好的性能/价格比。当然，如果你是一个对硬件技术细节非常熟悉，说话又有分量，对自己非 常有信心，敢冒风险，崇尚节约、实用性的人，那么DIY一组高性价比的服务器集群，也是一件非常有意义而且充满乐趣的工作。

2.3.原始软件环境：

Red Hat 9.0 完全安装 Red Hat 9.0 （kernel-2.4.20-8 ） gcc -3.2.2-5

如果你使用的是Red Hat 8 ，那么你很幸运。Red Hat 8 (kernel-2.4.18-14)已经预先打了ipvs的补丁，在预安装的内核中已将ipvs编译成模块，可以通过检查 /lib/modules/2.4.18-14/kernel/net/ipv4/ipvs 是否存在来判断。可以直接安装ipvsadm。从Red Hat 9 (kernel-2.4.20-8),Red Hat 取消了ipvs的补丁及预编译ipvs为模块的内核，且Red Hat 9 自带的kernel-2.4.20-8的内核无法通过ipvs补丁linux-2.4.20-ipvs-1.0.9 .patch.gz的编译，至少在我的两台P4的机器上都没有通过编译。标准内核linux-2.4.20.tar.gz则可以通过编译。所以我们将采用 www.kernel.org上的标准内核kernel-2.4.20.tar.gz来构造我们的集群系统。

2.4.需下载软件包：

$Linux kernel http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.gz

$ipvs patch http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.20-ipvs-1.0.9.patch.gz

$ipvs tar ball http://www.linuxvirtualserver.org/software/kernel-2.4/ipvs-1.0.9.tar.gz

$hidden patch（已经包括在ipvs-1.0.9.tar.gz，可不用下载） http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff（解决arp 问题 for LVS-DR/LVS-Tun）

$ipvsadm (已包含在ipvs-1.0.9.tar.gz包中, 可不用下载)

$Ldirectord http://www.linux-ha.org/download/heartbeat-ldirectord-1.0.3-1.i386.rpm

$heartbeat http://www.linux-ha.org/download/heartbeat-1.0.3.tar.gz http://www.linux-ha.org/download/heartbeat-1.0.3-1.src.rpm http://www.linux-ha.org/download/heartbeat-1.0.3-1.i386.rpm http://www.linux-ha.org/download/heartbeat-pils-1.0.3-1.i386.rpm http://www.linux-ha.org/download/heartbeat-stonith-1.0.3-1.i386.rpm

2.5. 安装要求：

2.5.1 Director:

2.5.2 RealServes: （在LVS-NAT方式下，不需要打任何补丁）

内核打arp的补丁hidden-2.4.20pre10-1.diff （arp problem for LVS-DR/LVS-Tun）编译新内核。

如果你不知道你的内核源代码是否已经预打过ipvs的补丁, 可以询问你的Linux发行版的制造商或查看相关ipvs 文件，文件名类似于 /usr/src/linux-2.4/net/ipv4/ip_vs_*.c。

2.6. 安装步骤：

2.6.1 Director或RealServer上内核的安装:

相关网络内核选项：

相关LVS内核选项：

如果要安装该内核在其它机器上:

2.6.2 Director上ipvsadm 的安装：

用打过ipvs和hidden（for LVS-DR/LVS-Tun）补丁的新内核启动linux

检查ipvsadm 探测到内核的ipvs的补丁可以运行

如果成功你会看到类似于如下内容：

说明安装成功

运行lsmod | grep ip_vs 可以看到ip_vs模块已经被插入内核运行。

2.6.3. 运行脚本( Run Scripts )

以下以最常用的LVS-DR模式来介绍相关的脚本设置

( 以Telnet服务, 轮叫(rr)策略为例 )

2.6.3.1 Director上:

该段运行脚本对于熟悉Linux网络配 置的读者来说应该很容易理解。由于LVS是通过对标准内核打补丁，在内核级提供支持，所以在LVS-DR模式下，首先是进行内核的相关设置。要关闭标准内 核下的ip_forward转发方式，即置为0。同时因为LVS-DR模式下，集群的网关是外部网关，而不是负载均衡器。所以要打开icmp包的重定向设 置send_redirects 置为1。接着就是绑定集群的虚拟服务器的IP地址，并添加一条到该IP地址的主机路由。然后对该虚拟IP做一些必要的自我检测，同时列出路由表。最后是有 关ipvasdm的设置，首先清空ipvasdm表，然后添加需要提供负载均衡的服务及调度策略，这里例举的是telnet服务，也可以直接使用端口号， 调度策略为轮叫(rr)策略。最后添加转发到真实服务器的直接路由，如果有多台RealServer或需要提供多种服务的负载均衡，依次添加。再做一些到 RealServer的网络测试（也可不要），最后显示ipvasdm所有的设置信息。

注意：

ipvs -1.0.9.tar.gz中包含的ipvsadm是1.21版，安装后在/etc/rc.d/init.d/目录下自动生成了标准的init服务脚本， 如果你的Director没有安装备份服务器，你可以通过服务管理工具让它在相应的运行级里自动运行，如果Director是HA系统，则由 heartbeat控制运行。

另外该服务脚本提供了配置保存功能。配置文件为：/etc/sysconfig/ipvsadm 你必须手工建立。然后在其中输入规则和策略：

例如：

然后存盘。 或直接运行：

然后运行：/etc/rc.d/init.d/ipvsadm save

就可以保存当前配置到/etc/sysconfig/ipvsadm文件中。

在具有HA系统的Director上，ipvsadm可以方便地被Heartbeat管理－启动、停止。Director上的VIP（虚拟）服务器地址由Heartbeat负责设置和切换。

做法如下：

在Heartbeat的配置文件haresources中加类似入如下一行：

linuxha1 IPaddr::192.168.7.110/24/192.168.7.255 ipvsadm ldirectord::www ldirectord::mail

2.6.3.2. RealServers上:

该段脚本和上面的脚本比较类似，相信不 用再多做介绍了。需要注意的是：LVS-DR模式下，缺省网关的设置。集群的网关是外部网关，而不是负载均衡器。还有就是RealServer上绑定的 VIP地址的设备lo:0。另外不要忘了开启not arp补丁的设置开关。相信你已经很清楚了。 你也可以把以上脚本改写成符合init语法的标准脚本，放到/etc/rc.d/init.d/下面运行，或直接加到/etc/init.d/rc.local下运行。 改写为标准init语法脚本如下：

然后：

cp rc.lvs /etc/rc.d/init.d/hiddend chmod 755 /etc/rc.d/init/d/hiddend chkconfig - -add hiddend