集群 对于不同的人有不同的含义。在本文的上下文中，集群最好定义为横向扩展（scale-out）—— 横向扩展集群一般包含大量相同类型的组件，比如 Web 场、表示场和高性能计算 (HPC) 系统。管理员会告诉您，对于横向扩展集群，必须百千次地重复修改，无论修改是多么小；最懒惰的管理员精通横向扩展管理技术，因此无论节点的数量有多少，需要的工作量都是相同的。在本文中，作者将泄露世界上最懒惰的 Linux® 管理员的秘诀。

自从世界上最快的 500 台计算机清单于 1998 年首次发布以来，Linux 集群已经从科学实验项目发展成了当今超级计算领域的主流技术。实际上，在 1998 年的 Top 500 清单中 Linux 集群只占据一席（一个集群，一个 Linux 操作系统），但是在 2008 年的清单中占据了五分之四（400 个集群，458 个 Linux 操作系统）。

管理 Linux 集群需要很独特的技能，单一系统或小型连网系统的 IT 管理员往往不具备这些技能。管理 Linux 集群要求管理员深入理解连网、操作系统和体系结构中的所有子系统。

但是，不仅如此：它还要求采取另一种态度。它要求 “懒惰”。它要求管理员听从 Scrooge McDuck 在 Duckburg 中对侄子们的教导：“工作越巧妙，就越轻松” 。

在本文中，我们讨论最懒惰的 Linux 集群管理员的一些秘诀。尽管它们并不是真正的秘诀，但是由于某种原因，人们要么不了解这些思想，要么低估了它们的作用。为了纠正这个问题，我们在讨论这些秘诀的同时会解释它们的重要性。

这些秘诀是：

1. 不要开发已有的东西。
2. 使用开放源码软件。
3. 将所有东西自动化。
4. 在设计时就考虑到可伸缩性 —— 从一开始就要计划偷懒。
5. 在设计时就考虑到硬件的可管理性。
6. 使用出色的集群管理软件 —— 工欲善其事，必先利其器。
7. 使用开放源码的监视解决方案。
8. 用队列系统控制用户。
9. 检验付出所得到的回报 —— 执行基准测试！
10. 管理集群管理员交流。
11. 不断寻找更懒惰的办法。

1. 不要开发已有的东西

懒惰的 Linux 集群管理员不会开发已有的东西；他们主要依靠别人的成果来完成自己的任务。如果已经有免费的得到良好支持的解决方案，那么浪费时间开发应用程序又有什么意义呢？

世界上最稀少的东西之一是独创的思想或首次出现的问题，在 Linux 集群环境中尤其如此。很少会遇到在 2004 年出现并且没有解决的问题。这是好事情；您应该相信实际上没有什么问题是不能解决的（从技术上说是这样，但是在政治和社会方面就不一定了）。因此，要接受这个现实：大多数问题都已经被发现、诊断和解决了。

为了少浪费时间，有经验的管理员会在以下方面多花些时间：

• 研究现有的解决方案并根据自己的需要采用它们。牛顿在评价自己的成就时曾经引用 Bernard of Chartres 的话说，他是站在 “巨人的肩膀上”。如果他没有首先尝试理解欧几里得原理，就不可能建立自己的理论体系，但是这并不会抹杀他的成就。
• 对开放源码项目做贡献或进行定制，而不是重新发明已经存在的东西 —— 他完全明白，如果自己编写软件，那么在他跳槽时很可能会留下一个烂摊子，因为没有别人了解他写的软件。

我们并不想扼杀您的创造力 —— 其实正好相反。利用别人已经完成的成果会帮助您进入更高的层次，这会使您的环境比其他组织的 IT 环境更出色更高效。

2. 使用开放源码软件

我们认识的最成功的 Linux 集群管理员都非常了解当前的开放源码项目。他们是邮件列表的积极参与者，当在网络上搜索时会发现他们的名字常常与热门的项目联系在一起。他们常常在 http://sourceforge.net 和 http://freshmeat.net 上寻找感兴趣的新项目。

开放源码工具的性质使它们的寿命很长，对于流行的工具尤其如此。例如，尽管 Ganglia、Nagios 和 TORQUE 等工具已经存在很长时间了，但是仍然有不少人在使用它们。它们很出色，能够帮助管理员节省软件成本并避免许可协议的限制。

最懒惰的集群管理员的另一个特点是，他们对开放源码运动都非常热心，愿意在自己的工作中使用开放源码软件。他们可能在家里建立自己的 Web 服务器，或者在 Linux 笔记本计算机上运行应用程序。您会发现最懒惰的 Linux 管理员除了在工作中负责管理的集群之外，在他们生活中的其他方面也常常运行 Linux，包括 Pidgin 和 Firefox 等各种软件。

3. 将所有东西自动化

在命令行上使用脚本和其他快速工具在 Linux 管理员的工作中占很大部分。脚本（只要不是重新发明任何东西）有两个优点：

• 最显著的优点是，它节省了输入命令的时间，提供可重复执行的命令模式。
• 第二个优点是，它可以说明本身的用途，便于以后重用。

我们常常发现，有经验的管理员会在自己的计算机上用专门的目录存储他们编写的脚本。这些脚本的用途五花八门，从检查节点上的防火墙版本到映射 InfiniBand 集群中的 GUID。

非常适合使用脚本的一种情况是生成操作系统映像（无论是无状态的还是有状态的）。如果管理员有一个 “黄金映像”，需要把它传播到系统中的每个计算节点，那么他应该了解其中包含的内容。创建此映像的脚本就是最好的文档，因为它精确地解释了执行的操作，而且是可重复执行的。如果没有构建映像的脚本，就会发生映像膨胀，导致占用的空间增加和系统速度下降。

我们常常遇到一些组织有黄金映像，他们自 2000 年以来一直使用这些映像。最大的原因是：他们不知道如何重新构建它。第二个（可能更重要的）原因是：他们的应用程序已经在此映像上测试和 “认证” 过了。认证 是经常会遇到的词，但是它的定义与云计算 一样含糊不清（顺便说一句，“云计算” 这个词汇不是专利，也不是商标词）。

应该把工作自动化的原因是：避免工作比实际做工作需要更多的脑力。懒惰的 Linux 集群管理员不会做那些让他们的脑子变得迟钝的工作。如果您不得不在集群中的每台计算机上启动 ssh 并运行一个命令，那么您就是不够懒。对节点执行的所有命令都应该通过并行命令或过程自动执行。如果硬件厂商没有提供自动化的 Linux 工具来更新 BIOS 或刷新子系统，那么在考虑成本时要算上这个因素。

我们的前一篇文章 ““懒惰” Linux 管理员的 10 个关键技巧” 中的技巧 8 和技巧 10 讲解了我们常用的几种命令行脚本编程技术。还有其他许多方法，而且其中一部分可能效率更高，这些技巧只是提供一个思路，促使您思考脚本可以完成哪些工作。

4. 在设计时就考虑到可伸缩性，从一开始就要计划偷懒

第三个秘诀（自动化）是一个大目标，但它只是实现完全清闲 的过程中的一个步骤。对于最懒惰的管理员，“完全清闲” 只能通过自治的横向扩展管理来实现。实现此目标的第一步是在系统中避免不可伸缩的操作。

大型横向扩展集群的主要麻烦是瓶颈。大多数横向扩展集群管理员使用 TFTP 执行网络引导或安装大量计算机。任何有经验的横向扩展集群管理员都会告诉您，TFTP 不可靠而且不可伸缩。如果没有适当的远程硬件控制，那么只要发生一次大规模的 TFTP 故障，管理员就不得不从椅子里跳起来，直奔数据中心，复位每台计算机（够他忙的）！即使有适当的远程硬件控制，管理员也必须长时间停止玩 WoW，因为必须一次又一次向集群中的节点发送复位命令（这也不轻松）。

只需提前做一点计划管理，就可以避免瓶颈（比如下面的瓶颈）。

瓶颈 1：供应服务

DHCP、TFTP、HTTP、NFS 和 DNS 是集群最常用的服务。它们都会形成瓶颈 —— 在集群扩展时，TFTP 是最糟糕的。幸运的是，很容易通过复制它们来帮助伸缩。

提示：把 DHCP 和 TFTP 隔离在另一个 NIC 中，这会极大地提高可伸缩性。例如，如果与其他供应服务共享 NIC，我们度量出的 TFTP 伸缩比是 40:1；如果不共享或者采用无状态引导，结果是 80:1。

瓶颈 2：网络

网络常常是设计中最容易被忽视的部分。这里说的网络是指用于管理的 GigE 网络，而不是专门用于应用程序通信的高性能网络。尽管在许多情况下只有一个网络必须是共享的（用于数据和管理），但是这可能导致许多伸缩问题。

在设计层次化网络时，一定要注意，不要太保守。如果要求节点与服务节点比例达到 80:1，那么要确保在整个结构中保持或超过此比例。

瓶颈 3：不要贪多嚼不烂

在设计大型横向扩展集群时，我们采取 “集群的集群” 方式。每个子集群（即可伸缩单元，SU）是一个构造块，其本身可以针对所有集群操作（例如，安装、网络引导、BIOS 更新、监视等）扩展。每个 SU 有一个或多个服务节点（数量取决于 SU 的规模），它们提供对 SU 中所有节点进行控制、监视和供应所需的服务。为了进一步帮助可伸缩管理，每个 SU 有自己的广播域（路由 SU-to-SU 和 SU-to-World 通信 —— 检查瓶颈）。

中心管理节点和服务节点有一个私有的物理或虚拟网络，因此从服务节点发送出的信息和发送到服务节点的数据不会干扰其他集群的通信流。我们把此网络、管理节点和服务节点称为层次化管理云 (hierarchal management cloud, HMC)。它的设置和操作只在管理员的域中进行。

这种 “集群的集群” 方式使懒惰的管理员设计的系统能够超过预期规模，支持集中的管理控制，同时不必担心大规模操作失败。

5. 在设计时就考虑到硬件的可管理性

许多管理员在设计集群时并没有考虑到 “可控制” 方面。高效的管理员都操作可控制集群，也就是说他们的集群放置在黑屋子中，远离工作人员，在理想情况下人们几周或几个月都不必看到他们每天操作的物理机器。在某些情况下，他们从来都没见过这些物理机器，因为他们是在世界的另一端管理它们。当然，最懒惰的管理员甚至不知道数据中心的具体位置 —— 对于他们来说，数据中心仅仅是一组主机名或 IP 地址。

数据中心噪音很大，有时候很冷，甚至可能有危险；懒惰的管理员应该尽可能避免到数据中心去。有人甚至认为呆在充满大量机器的房间里可能有对健康有害，尽管还没有发现这方面的证据。随着电力/制冷/人力成本的上升，越来越多的数据中心被转移到运营成本比较低的地方。因此，绝对的远程控制现在对于管理 Linux 集群越来越重要了，在不远的将来此功能可能是必需的。

硬件厂商非常重视客户对远程管理系统标准的需求。当前，IPMI 2.0 已经成为大多数 Linux 集群的标准。IPMI 提供了远程控制机器电源的方法，还提供远程控制台，可以观察计算机的 BIOS 引导过程。在我们的一位客户的站点上，我们能够坐在客户的办公室中，舒舒服服地对 60 英里外的计算机进行调试。（这位客户的 Linux 管理员真的很懒惰，他的办公室只用墙上昏暗的霓虹灯来照明。这间办公室简直成了单身汉的公寓，这里有两个冰箱，装满了饮料和甜食。不用说，我们不愿意离开那里）。

IPMI 是强大的 —— 我们可以修改 BIOS 设置，重新启动节点，观察它们的引导过程，查看屏幕转储，而根本不需要看到物理机器 —— 它应该安装在所有集群中。您至少需要以下功能：

• 远程控制机器的电源
• 远程控制台或观察机器引导过程的更好方法，从而应付可能发生的引导问题

有了 IPMI，Linux 集群中就不太需要其他软件了，那些软件只提供运行 IPMI 的豪华界面，而不是管理节点。实际上，我们建议使用开放源码工具，比如大多数 Linux 发行版已经附带的 ipmitool。我们发现最懒惰的 Linux 集群管理员依赖于命令行。

对于 IPMI 远程控制台的可靠性还有争议。我们意识到，有时候真正的带外终端服务器是很有价值的。Cyclades ACS48 等终端服务器是合理的投资，它们提供带外访问和 IPMI 不具备的可靠性。

另外，IPMI 1.5 不是最可靠的 IOHO（这是一个全行业范围的问题）。IPMI 2.0 在这方面好多了，而且许多厂商围绕它添加了新颖的网页，使它看起来更容易使用。是包含终端服务器，还是只在机器上直接使用 IPMI，对于这个问题还有争议。我们的大多数客户的想法是这样的：每个懒惰的 Linux 管理员都知道，需要花费大量时间排除 5% 的节点的故障，而 95% 的节点都是正常的。在这种情况下，更好的办法是多购买 5% 的节点（而不是基础设施）当作备份。这意味着花费在计算能力上的预算比花费在基础设施上的预算多一些。

考虑到这一点，如果使用终端服务器可以避免管理员长途赶去排除节点的故障，那么终端服务器就是物有所值的。我们让懒惰的 Linux 管理员自己做决定 —— 毕竟，必须去赶飞机的是他。我们看到争论的双方似乎都有一定的道理。

6. 使用出色的集群管理软件 —— 工欲善其事，必先利其器

自从 1999 年 Linux 集群首次出现以来，集群工具已经有了长足的进步。在当时，可用的集群管理工具并不多，因此大多数管理员用自己开发的工具集来部署、监视和管理他们的集群。

最懒惰的管理员已经接受了开放源码工具，或者把他们在 1999 年开发的工具贡献给了社区。很少有开放源码工具无法应付的极其独特的集群环境。在大多数情况下，坚持使用自己的工具的管理员都很孤独，当他们离开组织时，他们的工具也就随其消失了。但是，我们发现在许多站点上仍然在使用定制的工具。

如果您对自制的工具不满意，正在寻找更好的工具，那么可以考虑几个开放源码工具。最受欢迎的集群管理工具包括 OSCAR (System Imager)、ROCKS、Perceus 和我们喜爱的 xCAT 2。它们都是开放源码的。

当今最流行的开放源码集群部署/控制解决方案可能是 ROCKS。ROCKS 是由 UCSD 开发和维护的，他们在集群的用户友好性方面完成了出色的工作。我们对它惟一的不满之处是，它的灵活性不足，主要在操作系统级。ROCKS 基于 Red Hat 发行版，这对于大多数人是合适的，但是对于使用 SUSE 或者希望使用在 RH 6.2 发行版上创建的映像的人就不合适了。另外，ROCKS 不是克隆解决方案，而我们发现许多 IT 组织都使用克隆解决方案。

Perceus 是另一个流行的解决方案。它与 ROCKS 的不同之处在于，它是无状态的。对于本文的上下文，我们把无状态计算定义为在内存中运行操作系统，而不是把操作系统放在磁盘上。不需要磁盘，但是可以使用磁盘执行本地操作或交换。

与其他解决方案相比，我们更喜欢 xCAT（当然，我们必须坦白，我们向 xCAT 项目贡献了代码并积极参与开发，所以推荐它有点儿 “自买自夸”）。它的优点是比其他任何工具都要灵活、可伸缩且更强大。（它的代码贡献者也是最英俊最聪明的）。世界上最快的超级计算机 LANL RoadRunner 系统就是用 xCAT 来管理的（此系统是 Cell/B.E.™/Opteron™ 的混合体，是第一个 one-petaflops 系统，也是第一个 one-petaflops Linux 集群）。

xCAT 可以针对几乎所有企业 Linux 发行版实现映像生成、kickstart、autoyast、iscsi 和无状态。另外，它还提供命令行工具，这些工具对从远程电源控制到控制台设置的各种 IPMI 命令进行抽象，可以在同一框架中使用它们。xCAT 的开发从 1999 年 10 月 31 日开始，IBM 在 2007 年开放了它的源代码。

但是公正地说，xCAT 也有缺点：

• 它的设置比较难；由于灵活性很强，它有许多可配置参数。我们建立了一个 wiki 来帮助管理员设置 xCAT，还可以通过邮件列表和 IRC 频道获得大量帮助。
• xCAT 2 完全改写了古老的 xCAT 1.3，因此管理员需要学习许多新东西。
• 与许多开放源码工具一样，文档还有待改进。

还有许多其他集群管理解决方案，我们可以就这个主题滔滔不绝地谈下去。但是，我们还是就此打住：如果您要寻找更好的工具或思想，请试试 xCAT。

7. 使用开放源码的监视解决方案

在去年的 SC'07 上，我们遇到了在几家美国大型实验室工作的朋友，我们谈到了在监视 Linux 集群方面遇到的难题。这促使我们在 2008 年初多次讨论这个问题。监视的困难源于几个原因：

• 随着集群的增长，收集的数据越来越多，接收这些监视信息的计算机的性能就越来越差。例如，如果有 2,000 台计算机，每台计算机都把性能指标发送到一个基础设施节点，此节点就会非常缓慢。
• 在计算节点上通过代理收集数据会与用户的作业争夺内存和 CPU 时间。许多站点不希望节点上有代理，因为它会降低应用程序的性能。这就需要回答一个问题：花费 CPU 时间获取监视数据是值得的吗？
• 我们还没有找到一种可伸缩工具能够把用户作业与计算机性能联系起来，从而有效且直观地分析作业。
• 还没有任何工具能够完全满足管理员的需求。这可能就是这个领域中最大的问题：使用的工具的功能不全面，至少缺乏人人都需要的某种功能。大多数管理员会结合使用两三种管理工具。我们常常听到一些集群监视产品宣称比所有其他解决方案都优秀，但是我们很怀疑这种说法：每个集群都不一样，真的有万灵药吗？定制的监视解决方案似乎是惟一的解决之道。

既然监视的复杂性这么大，那么最懒惰的管理员会怎么解决这个问题呢？

在大型集群上（包括著名大学和政府的实验室），最常见的解决方案是使用 Nagios 实现报警，使用 Ganglia 进行监视。通过结合使用这两种可定制性很强的工具，管理员可以很好地了解集群中发生的大多数情况。事实证明 Ganglia 的可伸缩性非常强。

但是，其他人也有不同的观点。在 USC，Garrick Staples 编写了 pbstop 作为 TORQUE 的插件，它可以显示当前正在运行的每个作业以及运行的位置。他说，这就是他需要监视的，他不需要使用其他任何工具。

我们看到横向扩展集群使用的最流行的开放源码监视工具包括：

• Nagios
• Ganglia
• Cacti
• Zenoss
• CluMon

我们可以说这些工具的实现大多利用了 RRDtool。CluMon 还在底层使用 Performance Co-Pilot (PCP)，PCP 也很流行。xCAT 在未来的版本中将支持 Ganglia 和 PCP。

重申一下，懒惰的 Linux 集群管理员知道：

• 没有适合所有集群的监视解决方案。监视对于不同的人有不同的含义。一些人只对计算机报警感兴趣，一些人需要监视性能指标，一些人需要作业分析，其他人只希望知道某些服务或应用程序是否在运行。
• 对于不同的站点或相同站点中的不同集群，定制的方式也不一样。
• 要在监视的目标、监视的用途和所需的资源之间找到平衡点。

8. 用队列调度程序控制/管理用户

懒惰的管理员都知道，用户是所有问题的根源。因此，防止用户获得根权限是极其重要的。甚至可以这样说：您应该尽一切努力把用户挡在您的计算机之外。

队列系统就提供这样的功能：用户提交作业，队列系统决定在哪些节点上运行此作业。除了运行作业之外，用户应该完全影响不了系统。

当今流行的队列系统包括一些付费产品，比如 LSF 和 PBS Pro。许多商业客户、政府实验室和大学使用这些产品。但是，对于许多系统，一般的开放源码解决方案（比如 TORQUE 和 SLURM）就很好了。

我们喜欢结合使用 TORQUE 和 Maui 调度程序来把用户挡在集群之外（除了运行作业）。在 Linux 上，这需要先设置 /etc/security/access.conf 文件，只允许根用户登录，拒绝其他任何人。例如，如果在每个节点上运行命令：

echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf

那么只有根用户能够登录此计算机。接下来，创建一个 TORQUE 序言脚本，它运行下面这样的命令：

perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf

（提示：$USER 变量是在运行脚本时 TORQUE 传递给脚本的第二个变量）。因为根用户运行序言脚本，所以此用户被允许登录集群。当作业完成时，运行收尾脚本，该脚本从 /etc/security/access.conf 中删除此用户，因此他无法再登录节点：perl -pi -e "s/ $USER\b//g" /etc/security/access.conf。这会防止用户相互冲突。

我们在集群上看到的一些 “性能” 问题实际上与计算机本身无关；真正的问题是多个用户在同一台计算机上运行作业，而他们运行的作业都要求占用全部 CPU 时间。

众所周知，用户管理是必需的。但是，在排除故障时，管理员常常没有认识到用户本身正是问题的根源。我们强烈建议把用户挡在系统之外，只允许他们通过受控的环境（比如资源调度程序）进入系统。另外，我们建议集群网络本身（千兆管理或用户网络）应该与公司或校园 WAN 的其余部分分开，只允许某些用户节点提供访问点。

9. 执行基准测试！提前发现性能问题

很多人只有在集群性能急剧下降、计算结果不正确时，才会意识到危险迫在眉睫。所以要记住，在判断集群的性能时硬件诊断常常是惟一的测试方法，但是硬件诊断提供的信息可能不完整。

硬件诊断常常以厂商指定的阈值作为成功/失败的评判标准 —— 实际的阈值可能高些，也可能低些。如果硬件诊断测试失败了，那么您就遇到问题了；但是，即使没有失败，也不意味着没问题。

下面的这些问题会对系统性能产生实质性影响，但厂商无法诊断出这些问题：

• 双位内存错误
• 单位内存错误
• SRAM 奇偶错误
• PCI 总线错误
• 数字错误
• 缓存错误
• 磁盘错误
• 性能不一致

问题常常与硬件无关，而是与软件相关。应用程序、库、编译器、固件和操作系统的任何部分都可能是问题的根源，而硬件诊断探测不出这些问题。运行硬件诊断的运行时环境常常与应用程序的环境不一样，而且子系统承受的压力也不一样 —— 所以无法重现软件造成的问题。

显然，需要在操作环境中运行某种相应的工作负载，从而检查集群的实际工作情况。这可以通过运行几个行业认可的基准测试来完成。基准测试的目的不是要获得最好的结果，而是要获得一致的、可重复的、精确的结果（当然，这也是最好的结果）。

如何知道结果是否是最好的？集群可以划分为下面的主要子系统：

• 内存
• CPU
• 磁盘
• 网络

硬件厂商应该有基准测试数据，这些数据说明预期的内存、CPU (FLOPS)、磁盘和网络性能。

如何知道结果是否是一致的？

采用统计学技术。在每个节点（对于多节点测试，是节点集）上运行每个基准测试一次或多次，然后把每个节点（或节点集）的最具代表性的数据集中在一起，并进行分析。结果的分布形态比结果本身更有意义。本文中所有基准测试的经验证明，结果都应该形成正态分布。正态分布是典型的钟形曲线，这在统计学中经常出现。它是更小的独立（可能无法察觉到的）恒等分布的变量或随机事件的综合结果。

基准测试也有许多很小的独立（可能无法察觉到的）恒等分布的变量，这些变量可能会影响性能，比如：

• 小的竞争进程
• 上下文切换
• 硬件中断
• 软件中断
• 内存管理
• 进程/线程调度
• 宇宙射线

这些变量可能是不可避免的，但是它们是形成正态分布的原因之一。

基准测试还可能有非 恒等分布的可观察到的变量，它们也会影响性能：

• 大的竞争进程
• 内存配置
• BIOS 版本和设置
• 处理器速度
• 操作系统
• 内核类型（比如 NUMA、SMP 和 UNI）和版本
• 坏内存（比如过多的 ECC）
• 芯片组修订
• 超线程或 SMT
• 不均衡的竞争进程（比如在某些节点上运行 httpd，但是在其他节点上不运行）
• 共享库版本

这些变量是可避免的。可避免的不一致性可能导致多重模态分布或非正态分布，可能会对应用程序性能造成可度量的影响。

由于我们的目标是一致的、可重复的、精确的结果，所以最好先尽可能减少变量。首先进行单节点基准测试，比如 STREAM。如果所有计算机都产生相似的 STREAM 结果，那么在其他基准测试出现异常时，就可以排除内存这个因素。接下来，做处理器和磁盘基准测试，然后是两节点（并行）基准测试，再执行多节点（并行）基准测试。在完成每个更复杂的基准测试阶段之后，检查结果是否是一致的、可重复的、精确的，之后才能执行下一个测试。

下面是我们推荐的基准测试次序（报告组件性能的基准测试以粗体显示）。

• 单节点（串行）基准测试：
  1. STREAM（内存 MBps）
  2. NPB Serial（单处理器 FLOPS 和内存）
  3. NPB OpenMP（多处理器 FLOPS 和内存）
  4. HPL MPI Shared Memory（多处理器 FLOPS 和内存）
  5. IOzone（磁盘 MBps、内存和处理器）
• 并行基准测试（只针对 MPI 系统）：
  1. Ping-Pong（互连 microsec 和 MBps）
  2. NAS Parallel（多节点 FLOPS、内存和互连）
  3. HPL MPI Distributed Memory（多节点 FLOPS、内存和互连）

等一下，听起来要做的工作太多了！

是这样的，但是如果您希望以后清闲的话，这也是必要的。幸运的是，可以通过工具和文档简化这些工作。提前做一点儿计划，以后就能够避免许多麻烦。我们将在以后的一篇文章中讨论基准测试工具和图表；在未来的 xCAT RPM 中也会提供这些工具，这会极大地提高生产力。

10. 管理集群管理员交流

设置 MediaWiki 要想设置 MediaWiki，首先要指定一个驻留它的服务器。如果没有其他节点可用的话，我们常常使用管理服务器： ssh mgmt 现在，确保安装 http 服务器、mysql 服务器和 php5。如果使用 Red Hat 5.1 或其衍生版本，那么输入： yum install http mysql php5 mysql-server 接下来，配置 mysql： service mysqld start mysql_install_db mysqladmin -u root password 'mypasswd' 下载安装媒体 wiki： cd /tmp/ wget http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.0.tar.gz tar zxvf mediawiki-1.13.0.tar.gz mv mediawiki-1.13.0 /var/www/html/wiki chmod a+x /var/www/html/wiki/config 完成这些步骤之后，在 Web 浏览器中访问 http://localhost/wiki。然后，只需按照菜单安装其余部分。 安装完成之后，会提示您执行命令： cd /var/www/html/wiki mv config/LocalSettings.php

收集系统的相关信息之后，应该把这些信息存储在某个方便的位置，让其他集群管理员可以轻松地访问。请回想一下 2000 年的情况，那时候文档大都采用 Word 或 Excel 格式，这既不酷，效率也不高。目前，生产力最高的文档共享方法是设置一个内部 wiki。这是因为懒惰的管理员不喜欢反复回答相同的问题。有了 wiki，管理员就不必这么做了，他只需说：“您自己去查看 wiki”。然后就不关他的事儿了。

每个站点都应该维护一个内部 wiki，其中应该包含所有常常被问到的集群相关信息，比如：

• 系统修改的日志记录，包括在集群上执行管理操作的时间。
• 集群的资产清单：固件版本、型号、序号、集群中的节点数量、处理器类型、内存。
• 向厂商要求技术支持的链接和获取更新的地址。
• 关于使用管理软件执行常见任务的文档。
• 关于创建操作系统映像的过程的信息。

简单地说，这个 wiki 包含的信息应该足够全面，如果有人询问关于此集群的问题，管理员只需回答 “您自己去查看 wiki”。另一方面，如果有人询问了一个 wiki 中没有涉及的问题，而您回答了他，那么您应该告诉他，作为回报他应该把您告诉他的知识添加到 wiki 中。另外，这也是对他的奖励，因为他发现了别人没有注意到的东西，这会让他在狂野的 IT 世界中获得尊敬。

为什么 wiki 比其他文档形式更好？

• wiki 是可编辑的，位于一个中心位置，可以根据需要授予用户对它的访问权。我们见过保存在共享信息库中的文档，但是要想查看这些文档，用户必须先导航到信息库，然后把文档保存到自己的硬盘上，然后再打开。效率太低了。对于 wiki，只需单击链接，这更快更简便。
• Word 文档或电子表格中的信息是静态的，修改起来比较麻烦（编辑、重新保存和发送修订后的文档）。更不用说，常常会看到同一文档的许多修订版，人们无法确定他们手里的版本是不是最新的。如果多个人编辑同一文档，就更混乱了。实际上，把文档放在 wiki 上，它们的寿命就会长得多。

设置 wiki 是极其容易的。我们使用 MediaWiki。它是免费的，很容易安装和配置。（请参见边栏）。

Wiki 的语法比 HTML 简单得多，而且网上有许多讲解如何使用 wiki 的参考资料。还有一些用来突出显示 perl 或 bash 中的代码语法的扩展。

当我们提议通过安装 wiki 帮助管理员变得更懒惰时，没有遇到过任何阻力。

11. 不断寻找更懒惰的办法

我们常常看到集群管理员总是按照自己的方式做事，这是因为他们习惯了。我们认为，这对于 Linux 集群不是好现象，这会磨灭管理员的才能，丧失进一步挖掘集群的潜力的机会。变化是很重要的，并且新的思想常常伴随变化出现。

当然，我们并不指望任何人能够研究他们遇到的每个新思想，但是是否熟悉新的趋势是区分优秀的管理员和平庸的管理员的重要标志。在这个快速变化的世界里，没人能够知晓所有东西，并且只很少一部分人精通某些东西。但是，优秀的管理员了解那些非常好的东西，乐于测试新产品，而且对于以前没听说过的东西很好奇。

因此，如果有人谈到以前没听说过的东西，懒惰的 Linux 管理员会追问下去，因为他实在太懒了，很希望找到更偷懒的方法。他还会通过搜索引擎查找相关信息。最糟糕的 Linux 集群管理员就是那些从来不提问题的。懒惰的 Linux 集群管理员不怕承认自己不知道某个东西。他对自己的本事很自信，即使他不知道某个产品，也能很快掌握它。

目前，在 Linux 集群管理领域有一些非常好的趋势。我们最感兴趣的是：

1. 越来越多的集群向无状态计算迁移。这会使映像的管理和保持节点同步更加轻松。
2. 从数据中心的角度看待集群。这意味着会考虑三年或更长时间内的电力、制冷和人员成本，而不仅仅考虑最初的采购成本。
3. 从气体制冷向液体制冷发展。您知道吗？液体制冷的效率比气体制冷高 90%。
4. 自适应式管理。按照这种管理方式，队列系统能够根据需要供应节点。这是真正的云计算，我们已经用 Moab 和 xCAT 证明了它的优越性。这是实现完全清闲 的最后一步。

结束语

如果本文达到了它的目的，那么您现在应该有了一些偷懒的好主意，应该会尝试减轻自己的工作，同时更好地控制您现有的 Linux 集群环境，还计划在下一个集群中更偷懒。我们相信本文提供的思想和实践有助于更好地使用集群，促使集群管理成为更专业的科学，帮助造就更高效的集群管理员。

问题越少，要开的会和要做的工作就越少，管理员就有更多时间玩 WoW、睡觉或做懒鬼们喜欢做的任何事情。 （责任编辑：A6）