linux集群管理

自从世界上最快的 500 台计算机清单于 1998 年首次发布以来，Linux 集群已经从科学实验项目发展成了当今超级计算领域的主流技术。实际上，在 1998 年的 Top 500 清单中 Linux 集群只占据一席（一个集群，一个 Linux 操作系统），但是在 2008 年的清单中占据了五分之四（400 个集群，458 个 Linux 操作系统）。
第三个秘诀（自动化）是一个大目标，但它只是实现完全清闲 的过程中的一个步骤。对于最懒惰的管理员，“完全清闲” 只能通过自治的横向扩展管理来实现。实现此目标的第一步是在系统中避免不可伸缩的操作。
大型横向扩展集群的主要麻烦是瓶颈。大多数横向扩展集群管理员使用 TFTP 执行网络引导或安装大量计算机。任何有经验的横向扩展集群管理员都会告诉您，TFTP 不可靠而且不可伸缩。如果没有适当的远程硬件控制，那么只要发生一次大规模的 TFTP 故障，管理员就不得不从椅子里跳起来，直奔数据中心，复位每台计算机（够他忙的）！即使有适当的远程硬件控制，管理员也必须长时间停止玩 WoW，因为必须一次又一次向集群中的节点发送复位命令（这也不轻松）。
10管理集群管理员交流。
不断寻找更懒惰的办法。
1. 不要开发已有的东西
懒惰的 Linux 集群管理员不会开发已有的东西；他们主要依靠别人的成果来完成自己的任务。如果已经有免费的得到良好支持的解决方案，那么浪费时间开发应用程序又有什么意义呢？
世界上最稀少的东西之一是独创的思想或首次出现的问题，在 集群环境中尤其如此。很少会遇到在 2004 年出现并且没有解决的问题。这是好事情；您应该相信实际上没有什么问题是不能解决的（从技术上说是这样，但是在政治和社会方面就不一定了）。因此，要接受这个现实：大多数问题都已经被发现、诊断和解决了。
中心管理节点和服务节点有一个私有的物理或虚拟网络，因此从服务节点发送出的信息和发送到服务节点的数据不会干扰其他集群的通信流。我们把此网络、管理节点和服务节点称为层次化管理云 (hierarchal management cloud, HMC)。它的设置和操作只在管理员的域中进行。
这种 “集群的集群” 方式使懒惰的管理员设计的系统能够超过预期规模，支持集中的管理控制，同时不必担心大规模操作失败。
硬件厂商非常重视客户对远程管理系统标准的需求。当前，IPMI 2.0 已经成为大多数 Linux 集群的标准。IPMI 提供了远程控制机器电源的方法，还提供远程控制台，可以观察计算机的 BIOS 引导过程。在我们的一位客户的站点上，我们能够坐在客户的办公室中，舒舒服服地对 60 英里外的计算机进行调试。（这位客户的 Linux 管理员真的很懒惰，他的办公室只用墙上昏暗的霓虹灯来照明。这间办公室简直成了单身汉的公寓，这里有两个冰箱，装满了饮料和甜食。不用说，我们不愿意离开那里）。
集群 对于不同的人有不同的含义。在本文的上下文中，集群最好定义为横向扩展（scale-out）—— 横向扩展集群一般包含大量相同类型的组件，比如 Web 场、表示场和高性能计算 (HPC) 系统。管理员会告诉您，对于横向扩展集群，必须百千次地重复修改，无论修改是多么小；最懒惰的管理员精通横向扩展管理技术，因此无论节点的数量有多少，需要的工作量都是相同的。在本文中，作者将泄露世界上最懒惰的 Linux? 管理员的秘诀。
●对开放源码项目做贡献或进行定制，而不是重新发明已经存在的东西 —— 他完全明白，如果自己编写软件，那么在他跳槽时很可能会留下一个烂摊子，因为没有别人了解他写的软件。
我们并不想扼杀您的创造力 —— 其实正好相反。利用别人已经完成的成果会帮助您进入更高的层次，这会使您的环境比其他组织的 IT 环境更出色更高效。
瓶颈 3：不要贪多嚼不烂
在设计大型横向扩展集群时，我们采取 “集群的集群” 方式。每个子集群（即可伸缩单元，SU）是一个构造块，其本身可以针对所有集群操作（例如，安装、网络引导、BIOS 更新、监视等）扩展。每个 SU 有一个或多个服务节点（数量取决于 SU 的规模），它们提供对 SU 中所有节点进行控制、监视和供应所需的服务。为了进一步帮助可伸缩管理，每个 SU 有自己的广播域（路由 SU-to-SU 和 SU-to-World 通信 —— 检查瓶颈）。
3. 将所有东西自动化
在命令行上使用脚本和其他快速工具在 Linux 管理员的工作中占很大部分。脚本（只要不是重新发明任何东西）有两个优点：
●最显著的优点是，它节省了输入命令的时间，提供可重复执行的命令模式。
●第二个优点是，它可以说明本身的用途，便于以后重用。
我们常常遇到一些组织有黄金映像，他们自 2000 年以来一直使用这些映像。最大的原因是：他们不知道如何重新构建它。第二个（可能更重要的）原因是：他们的应用程序已经在此映像上测试和 “认证” 过了。认证 是经常会遇到的词，但是它的定义与云计算 一样含糊不清（顺便说一句，“云计算” 这个词汇不是专利，也不是商标词）。
只需提前做一点计划管理，就可以避免瓶颈（比如下面的瓶颈）。
瓶颈 1：供应服务
DHCP、TFTP、HTTP、NFS 和 DNS 是集群最常用的服务。它们都会形成瓶颈 —— 在集群扩展时，TFTP 是最糟糕的。幸运的是，很容易通过复制它们来帮助伸缩。
提示：把 DHCP 和 TFTP 隔离在另一个 NIC 中，这会极大地提高可伸缩性。例如，如果与其他供应服务共享 NIC，我们度量出的 TFTP 伸缩比是 40:1；如果不共享或者采用无状态引导，结果是 80:1。
我们常常发现，有经验的管理员会在自己的计算机上用专门的目录存储他们编写的脚本。这些脚本的用途五花八门，从检查节点上的防火墙版本到映射 InfiniBand 集群中的 GUID。
非常适合使用脚本的一种情况是生成操作系统映像（无论是无状态的还是有状态的）。如果管理员有一个 “黄金映像”，需要把它传播到系统中的每个计算节点，那么他应该了解其中包含的内容。创建此映像的脚本就是最好的文档，因为它精确地解释了执行的操作，而且是可重复执行的。如果没有构建映像的脚本，就会发生映像膨胀，导致占用的空间增加和系统速度下降。
管理 Linux 集群需要很独特的技能，单一系统或小型连网系统的 IT 管理员往往不具备这些技能。管理 Linux 集群要求管理员深入理解连网、操作系统和体系结构中的所有子系统。
但是，不仅如此：它还要求采取另一种态度。它要求 “懒惰”。它要求管理员听从 Scrooge McDuck 在 Duckburg 中对侄子们的教导：“工作越巧妙，就越轻松” 。
2. 使用开放源码软件
我们认识的最成功的 Linux 集群管理员都非常了解当前的开放源码项目。他们是邮件列表的积极参与者，当在网络上搜索时会发现他们的名字常常与热门的项目联系在一起。他们常常在 和 上寻找感兴趣的新项目。
有了 IPMI，Linux 集群中就不太需要其他软件了，那些软件只提供运行 IPMI 的豪华界面，而不是管理节点。实际上，我们建议使用开放源码工具，比如大多数 Linux 发行版已经附带的 ipmitool。我们发现最懒惰的 Linux 集群管理员依赖于命令行。
IPMI 是强大的 —— 我们可以修改 BIOS 设置，重新启动节点，观察它们的引导过程，查看屏幕转储，而根本不需要看到物理机器 —— 它应该安装在所有集群中。您至少需要以下功能：
●远程控制机器的电源
●远程控制台或观察机器引导过程的更好方法，从而应付可能发生的引导问题
我们的前一篇文章 ““懒惰” Linux 管理员的 10 个关键技巧” 中的技巧 8 和技巧 10 讲解了我们常用的几种命令行脚本编程技术。还有其他许多方法，而且其中一部分可能效率更高，这些技巧只是提供一个思路，促使您思考脚本可以完成哪些工作。
4. 在设计时就考虑到可伸缩性，从一开始就要计划偷懒
为了少浪费时间，有经验的管理员会在以下方面多花些时间：
●研究现有的解决方案并根据自己的需要采用它们。牛顿在评价自己的成就时曾经引用 Bernard of Chartres 的话说，他是站在 “巨人的肩膀上”。如果他没有首先尝试理解欧几里得原理，就不可能建立自己的理论体系，但是这并不会抹杀他的成就。
3将所有东西自动化。
4在设计时就考虑到可伸缩性 —— 从一开始就要计划偷懒。
5在设计时就考虑到硬件的可管理性。
6使用出色的集群管理软件 —— 工欲善其事，必先利其器。
7使用开放源码的监视解决方案。
8用队列系统控制用户。
9检验付出所得到的回报 —— 执行基准测试！
开放源码工具的性质使它们的寿命很长，对于流行的工具尤其如此。例如，尽管 Ganglia、Nagios 和 TORQUE 等工具已经存在很长时间了，但是仍然有不少人在使用它们。它们很出色，能够帮助管理员节省软件成本并避免许可协议的限制。
最懒惰的集群管理员的另一个特点是，他们对开放源码运动都非常热心，愿意在自己的工作中使用开放源码软件。他们可能在家里建立自己的 Web 服务器，或者在 Linux 笔记本计算机上运行应用程序。您会发现最懒惰的 Linux 管理员除了在工作中负责管理的集群之外，在他们生活中的其他方面也常常运行 Linux，包括 Pidgin 和 Firefox 等各种软件。
应该把工作自动化的原因是：避免工作比实际做工作需要更多的脑力。懒惰的 Linux 集群管理员不会做那些让他们的脑子变得迟钝的工作。如果您不得不在集群中的每台计算机上启动 ssh 并运行一个命令，那么您就是不够懒。对节点执行的所有命令都应该通过并行命令或过程自动执行。如果硬件厂商没有提供自动化的 Linux 工具来更新 BIOS 或刷新子系统，那么在考虑成本时要算上这个因素。
瓶颈 2：网络
网络常常是设计中最容易被忽视的部分。这里说的网络是指用于管理的 GigE 网络，而不是专门用于应用程序通信的高性能网络。尽管在许多情况下只有一个网络必须是共享的（用于数据和管理），但是这可能导致许多伸缩问题。