使用FreeBSD构建HPC群集

se9en

***************************************************************************************************
作者：Brooks Davis, Michael AuYeung, Gary Green, Craig Lee
The Aerospace Corporation
El Segundo, CA
{brooks,lee,mauyeung} at aero.org, Gary.B.Green at notes.aero.org © 2003 The Aerospace Corporation
翻译: A. CHENG( http://www.bsdplus.org/)
原文链接: http://people.freebsd.org/~brooks/papers/bsdcon2003/
转载请保留本部分内容
****************************************************************************************************
1. 简介
上个十年的大部分时间里，高性能计算（HPC）开发方面的主要进展都集中在商业群集（commodity clusters）方面，也就是平常所说的Beowulf群集。这些群集使用市场上普通的硬件，构建出的系统性能在很多应用中却能和那些传统的超级计算机相媲美，甚至有过之而无不及。所需的成本也大约只有后者的十分之一甚至更少。并不是每一种应用都适用群集，但大部分的科学应用都可以通过小的改动而采用群集系统。
在几个需要超级计算能力的用户的驱动下， Aerospace 公司2001年决定放弃继续购买小型群集和SMP系统的方案，转而建立一个整合的计算群集，并最终命名为Fellowship。这个决定主要是出于缩减管理成本和更有效地利用现有计算资源的考虑。用户需求的多样性也导致了我们的设计和大多数群集都有较大差异，尤其是在操作系统的选择（FreeBSD）和配置管理方面（完全网络启动节点）。
Fellowship正被用于解决一些重要的现实问题并运作良好。目前为止，浮点运算的最好的测试成绩为183 GFlops。这一成绩可在2002年群集系统Top 500中跻身前100位。
这篇文章中，我们先对群集的配置作一个概述。包括基本的硬件和软件，系统的物理和逻辑结构以及基本操作。然后我们详细讨论设计过程中遇到的主要问题以及对相应解决方案的选择，并讨论这些选择的结果；第三，我们讨论这个过程中的教训以及我们希望整个并行计算社区需要注意的相应的事项；第四，我们谈一下未来的方向，比如如何进行进一步的改善和群集计算的新方案的研究；最后，我们总结一下目前的成果以及未来的发展方向。表二给出了一个URL列表，让读者更好地了解我们提到的项目和产品。
2.Fellowship 概览

Figure 1: Fellowship Circa April 2003


Fellowship基本的物理和逻辑结构和大部分群集相似。共由三个核心系统构成：151个双处理器节点，一个网络交换机和位于Aerospace内部网中的多种远程管理设备。各个节点都位于10.5/16网段。所有的节点和服务器都运行FreeBSD4.8-stable。这些设备都装在一行7英尺高的双机位的机架中，放置在Carlifornia州ElSegundo市Aerospace总部的地下数据中心。Figure 1摄于2003年4月。机柜1中节点的布局如Figure 2所示。



Figure 2: Layout of Node Rack 1



核心系统包括一个用户或SHELL服务器，一个数据服务器，用于提供NFS共享SCRATCH磁盘空间和备份服务，一个管理服务器，上面运行了任务调度程序，NIS服务和节点管理服务。用户服务器，fellowship，是用户访问群集的网关，用户登录到网关上并在那里运行他们的工作。用户主目录储存在fellowship上，并通过NFS导出到各个节点；数据服务器，gamgee，提供了271GB的共享SCRATCH空间供用户在计算过程使用，它还运行了MySQL数据库服务器程序用于存储计算结果和用于备份主群集系统的AMANDA程序；管理服务器，frodo，则运行了一些列不同的服务，包括通过NIS导出用户信息，节点的网络启动和用户工作的调度。
节点的配置为双CPUX86系统，频率从1GHz的PIII到2.4GHz的Xeon不等，1GB的内存。表1列出了Fellowship使用的CPU类型和主频。所有的PIII节点在购买是都配置了一个40GB的IDE磁盘，Xeon系统则是80GB的磁盘。在PIII系统磁盘故障时会被一个80GB磁盘取代。节点通过一个Cisco Catalyst 6513交换机的千兆以太网相连。PIII系统是Tyan Thunder Le（1Ghz）和TyanThunderLE-T，LE-T通过扩展槽配置了3Com的千兆网卡。服务器都放置在一个14英寸机架上并通过iXsystems整合在一起。Xeon系统是配备了双千兆网卡的Intel 1U机型。购自Iron Systems公司。
Table 1: CPUS in Fellowship nodes

CPU Type Nodes CPUs
                      Pentium III 1GHz 8 16
                      Pentium III 1.26GHz 40 80
                      Pentium III 1.4GHz 39 78
                      Xeon (P4) 2.4GHz 64 128
                      Total 151 302


虽然每个节点都有自己的硬盘，我们仍然通过网卡的PXE功能进行网络启动。frodo上配置了DHCP，TFTP，NFS根磁盘以及NIS用户账户。启动时会自动检查磁盘以验证他们是否按照我们的环境要求进行分区。如果没有的话，他们会被自动重新分区。这意味着我们不需要对节点进行手工配置，除了安装时要获得他们的MAC地址以外。
对群集的本地控制是通过一个KVM开关完成的，它连在一个机架上的机架键盘和LCD显示器上。远程访问则通过CycladesTS系列的终端服务器来完成。所有的节点和服务器以及网络设备都链接在这些终端服务器上，而且所有FreeBSD机器上的控制台重定向也都被启用了。在Xeon系统上，BIOS重定向也被启用了，但由于一个bug的原因，PIII系统上并没有启用BIOS重定向，因为那个bug会引起系统宕机，即使在非常低的波特率下也是如此。除了控制台访问以外，除终端服务器以外的所有机器都链接在一个BayTechRPC4-15串行远程电源控制器上。这样我们可以通过合适的终端服务器连接到这个控制器上，从而可以远程重启任何系统。
除了这些基础设施以外，对节点的访问是由Sun GridEngine（SGE）来控制的。SGE是一个计划任务控制程序，也是一个POSIX批量环境服务标准的超集的实现。SGE可以让用户提交交互和批处理任务脚本到群集系统上。用户可以任意使用分配给他们的处理器资源，他们可以运行多个互不相关的进程或者单个由大量并行运算组成的任务。
为充分利用Fellowship，我们提供了一个基础的UNIX编程环境和一个并行编程工具箱以及一个商业化的并行应用程序。对于并行编程工具箱，我们提供了并行虚拟机以及一个MPICH和LAM版本的MPI（message PassingInterface）。目前，我们唯一的商业化的并行应用程序是Grid Mathematica，同时我们也是他的第一个客户。

se9en

3 设计
多样化的用户基础是我们建造Fellowship的最大挑战之一。在最初的Fellowship架构讨论会议上，有的用户使用的是联系紧密的应用，有的则是相互之间关联不大的程序；有的用户使用数据密集性的应用，还有非数据密集型程序用户；有些应用是用于日常生产环境中，有的则是高性能计算的研究。这样的用户和应用程序的多样性就导致了在现行的设计中存在的一些妥协。这一部分我们将重点讨论Fellowship建造过程中的一些主要的设计决策。
3.1 操作系统的选择
任何群集需要面对的第一个主要决定就是操作系统的选择。目前流行的选择是某个Linux的发行版。毫无疑问，这条选择的困难最少，而且大部分都以为，如果这是一个群集系统，它就会运行Linux。但事实上，群集可以运行任何一个操作系统。现行的群集运行的操作系统包括Solaris【SciClone】， HP-UX，AIX，MacOS X，FreeBSD，甚至是Windows。ASCI的拥有48个 128-CPU的blueMountain群集实际上运行的是Irix系统【SGI】。
对于一个只考虑计算要求而没有操作系统倾向性的机构来讲，运行linux是阻力最小的一个选择，因为大量的面向Linux的免费群集工具的存在，像是NPACI的Rocks Cluster发行版。其他的情况下，操作系统的选择就比较复杂。需要考虑的重要因素包括硬件平台，本地是否有富有经验的系统管理员，是否有需要使用的应用程序，维护是否方便，系统性能以及是否有必要对操作系统做必要的更改。
出于多方面的考虑，我们选择了FreeBSD来构建Fellowship。最现实的原因是，FreeBSD内建的对无盘系统的支持非常好，我们可以轻松地更改它来适应我们的网络启动模式。这一部分在实际中工作良好。
另外，FreeBSD几乎是Fellowship主架构师唯一使用的操作系统，而且他也是一个FreeBSD的Committer。这意味着我们拥有更多的 FreeBSD经验，而且我们可以对FreeBSD做一些更改从而简化系统升级过程。实际中，我们对FreeBSD系统的核心所做的更改取得了部分成功。我们在其中加入了一些小的更改，但是网络启动脚本的针对所有节点的更改并没有加入，因为我们没有足够的时间整理由此引起的对系统主体部分相互矛盾的更改； ports软件集是我们看中的FreeBSD的另一个优势，它可以让我们轻松地安装和维护用户需要的应用程序。有些时候，现有的ports也不能完全满足我们的需求，但大部分时候它工作得很好。同时，FreeBSD的Linux仿真功能也意味着我们并没有在应用程序的兼容性方面放弃很多。参照 FreeBSD手册中的Grid Mathematica安装文档，我们成功地安装并运行了这一应用。
使用FreeBSD的不利因素，对于我们的环境来讲，就是FreeBSD对对称多处理器（SMP）和线程功能的支持不好。在高性能计算社区的一个普遍存在的观点认为，如果群集不是一个商业化的超级计算机，那它一定是一个Linux系统。截至目前，SMP支持并没有对我们的用户引起很大的问题。我们的工作的大部分都是计算密集型的，在大量 IO情况下SMP性能的好坏就难以定论了。线程功能到时我们需要应对的一个主要问题。部分用户需要此功能来实现SMP扩展。我们期望这个情况在我们升级至 FreeBSD 5.x后可以有所改善。
HPC社区对Linux的专注给我们带来了一些问题。实际上，很多软件要么缺乏对FreeBSD的支持，要么就是测试很差，在FreeBSD上根本无法运行。另外，现代FORTRAN语言编译器的缺乏也是一个明显的缺点。
3.2 硬件架构
对硬件架构的选择其实是和操作系统的选择同时做出的，因为二者之间有非常紧密的联系。现在大部分的群集系统都是基于Intel或者是AMD X86的CPU，但也有很多其他的选择。64位的SPARC和Alpha相对较常见，Mac商店里的群集则是基于Apple的XServer平台。选择硬件架构的主要因素有价格，性能，耗电量和操作系统兼容性。比如，intel的Itanium2性能出众，但是价格昂贵，耗电量大，支持的操作系统也比较少。考虑到操作系统的一致性，基于X86的系统是一个最方便的选择。
当我们在2001年选择硬件架构的时候，主要的竞争者就是基于X86 的Intel，AMD和Alpha。我们很快就放弃了Alpha，因为以前建造的一个小型的Alpha群集在实际过程中经常出现过热的问题。同时也因为 Alpha不再像90年代末期那样享有很大的性能优势。我们考察了基于PIII和Athlon的系统，但最后选择了PIII，考虑到他们之间的性能和价格相差不大，而Athlon的能耗则可能引起很大的问题。

在Fellowship的使用过程中，我们还考察了其他的节点类型，包括新的Athlon，Xeon，Apple Xservers和AMD的Opteron。但在扩张时我们购买了Xeon。Athlon的能耗/性能比还是要比Intel的系统差。同样地， Xservers有些吸引力，但是它的能耗改善不大，性能优势不明显，而且是一个和其余系统不兼容的架构。我们会等到本年底，看一下硬件市场的情况再做决定。但是初步的报告显示，随着FreeBSD可以移植到AMD64架构上，我们可以探索在维持X86兼容性的同时使用更大内存的系统，这对于那些不想考虑他们的应用程序到底运行在什么机器上的用户来说是个好消息。
3.3 节点架构
对于节点类型的选择主要取决于硬件架构，群集形式以及网络接口。剩下的选择就是单CPU还是多CPU。由于单处理器不存在对内存，磁盘和网络访问的竞争而具有更高的CPU利用率，而多处理器系统则可以让不同类型的应用程序直接共享数据，减少通讯开销。另外，多处理器系统可以拥有更高性能的外部接口。
其他的选择包括处理器速度，内存和磁盘容量。我们发现，瞄准价格曲线的低位帮了我们不小的忙，因为没有任何一个特定的用户可以主导我们的决定。在其他环境里，高端处理器，大容量磁盘和内存可能也会成为选择，虽然他们会导致成本成指数级增长。
对于Fellowship，我们选择双CPU系统。主要动机是想研究那些可以充分利用群集中SMP系统的代码，相对于单处理器更高的密度以及单处理器上没有和千兆级网卡想对应的64位的PCI接口。结果是，我们购买了比实现系统性能峰值速度略低的CPU，2-4跟容量略小的内存以及相当于中端的桌面级系统的磁盘。这也是我们在表3中列出的结果。表4显示的是最近的节点配置。
Table 3: Configuration of first Fellowship nodes.
CPU         2 x Pentium III 1GHz
Network Interface         3Com 3C996B-T
RAM         1GB
Disk         40GB 7200RPM IDE
Table 4: Configuration of latest Fellowship nodes.
CPU         2 x Xeon 2.4GHz
Network Interface         On board gigabit
RAM         2GB
Disk         80GB 7200RPM IDE

3.4 网络互联
和硬件架构一样，网络接口的选择也是一个在价格和性能之间寻找平衡的过程，而性能的主要指标是带宽和延迟。一个特定的群集需要的网络接口和群集本身运行的任务密切相关。对于输入和输出数据集都很小且相互之间关联不大的任务来说，带宽需求就比较小，因此100MB的网卡就足够了；对于其他的任务，低延迟高带宽的（2Gbps+2Gbps）Myrinet才是一个正确的选择。其他的接口，比如说即将出现的InfiniBand的产品，也为高速接口提供了一个替代的选择。
Fellowship的千兆网卡的选择也是一个在价格和性能之间平衡的结果。而且我们页计划在不远的将来将网卡升级到JumboFrames（9000byte MTU）连接器来提升网络的性能。
当我们开始搭建Fellowship的时候，千兆网卡的成本几乎占了每个节点的成本的1/3.而如果选用Myrinet的话，成本要增加一倍还要多。展望一下明年的扩展计划，届时千兆网卡已经成为主板的标配。考虑到我们的群集所需的交换机，届时每个端口的成本比百兆网卡多不到20%。同时我们也在考虑在 Fellowship内部创建带有更高速网络接口，比如Myrinet，的子群集。
3.5 寻址与命名
为一个群集中的节点分配IP地址有三种方式。对于小的群集，许多架构就简单地把他们放在已有的网络中。这样做的话，群集中的节点不需要另外的路由开销即可和随机的外部数据源进行通讯；缺点就是IP地址和物理节点并不会一一对应，因而很难区分各个节点；另外，群集之间没有子网划分也使得节点之间的通讯很容易影响到外部网络。另外的两种方式都是把群集放在一个单独的子网中，无论是使用私有IP或者是公网IP（RFC1918）。使用公网IP的好处是，群集节点可以通过一个适当的路由器和随机的外部数据进行通讯和数据交换。在一个子网中，（通过某一特定的方式分配之后，）IP地址可以帮助管理员记忆某一IP属于哪个节点。使用公网IP的缺点就是这一资源正变得越来越稀缺因而很难获得大批的连续公网IP，即使可以也是非常昂贵的。使用10/8的私有IP地址空间就免掉了这一压力。当然缺点就是群集节点无法直接和外部数据进行交换。如果他们需要的只是HTTP或者FTP访问的话，可以使用代理服务器来解决这一问题。但是许多网格计算工具通常假定所有计算中的机器都是位于可完全路由的网络中。
在Fellowship中，我们选择使用10.5/16的私有地址空间。选择这种方式是因为我们需要一个自己的子网以避免消耗其他的网络资源。而且我们需要至少/23的子网掩码，在当时也无法得到这样的连续地址空间。在我们的网络中，10.5.0/24专门为核心设备预留下来。10.5.244/24则用于临时的DHCP分配，这样可以让网络设备在他们的MAC地址被记录在DHCP的配置文件之前就可以获得一个IP。10.5.X/24地址块分配给位于机架1上的节点。本来10.5.X.0分配给那个机架上的终端服务器，10.5.X.Y（0<Y<255)则对应于那个机架上的节点Y。但后来因为他们不支持JumboFrames，我们把终端服务器移到企业内网中。如果使用公网IP的话，这种分配方式则是不可能的。
选择节点名称则是群集架构师徐哟面对的另一个问题。通常的主机命名规则【RFC1178】可以用来命名核心服务器。然而，除非是一个群集非常小而且以后不会扩展，数字化的命名方案，比如node00，node01等，可能是一个比较好的选择。
对于Fellowship，我们选择用Fellowship of the Ring（Tolkien）外加数字的方案来命名核心服务器。有时候我们把名字都用完了，不得不使用Lord of the Ring中的其他人物名称，但仍然可以分辨的出来他们是核心服务器而非节点。
对于节点，我们使用它们所在的机架号以及他们在机架上的次序来命名他们。比如第一个机架上的第一个节点就是r01n01。终端服务器的名称使用r&#35;&#35;ts，但后来核心服务器的终端服务器被命名为gimli，所以其他的终端服务器就改名为gimli-r&#35;&#35;。这样的命名规范使得我们很容易把一个节点的IP地址和它的名称对应起来。
域名称使得命名过程显得稍微复杂了一点。通常群集使用一个自己的DNS域会比较好一些。对于Fellowship，所有外部系统都位于aero.org域中，内部节点都使用fellow.aero.org域。这样做的缺点是，某些软件倾向于所有的主机位于同一个域区中。
3.6 核心服务器和服务
在Fellowship 上，我们把除了节点和远程管理服务器以外的硬件设备称为核心服务器。在许多群集上，由单一的核心服务器来提供所有的核心服务已经足够。实际上，一些群集只是简单得选择某一个节点来作为核心服务器。一些大的群集提供多个前端，并提供负载均衡和故障转移（failover）来提高系统在线时间。
核心服务指的是那些用户使用群集时所必须的服务，比如用户至少需要一个帐号和home目录。他们还需要某种方式来配置他们的任务并让这些任务可以到达各个节点。通常，提供这些服务的方式是通过NFS来提供共享的Home目录和应用程序目录，通过诸如NIS之类的目录服务来分发账户信息。一个群集架构还可能提供其他的核心服务，比如批量任务定时程序，可以用来存储计算结果的数据库服务以及对存档存储设备的访问权限。为这些核心服务指定服务器的方式从实际的角度出发是无限的。
Fellowship有算个核心服务器：数据服务器，用户服务器和管理服务器。所有这些服务器都是1GHz的PIII， SCSI RAID5的系统。数据服务器，gamgee，通过NFS提供250GB scratch volume，运行一个MySQL数据库让用户存储计算结果并使用AMANDA每夜将数据库备份到一个磁带库上。用户服务器，fellowship，提供 NFS home目录，用户可以从这里登录进来并编译、运行他们的程序；管理服务器，frodo，提供定时任务程序，NIS和我们的共享，挂载在 /usr/aero目录下的应用程序层级架构。另外，管理服务器还提供DHCP，TFTP和NFS来完成节点的网络启动。
这些服务被彼此分开主要是出于性能方面的考量。在我们的模型中，点击共享的scratch 空间并不会导致普通的编译过程减速，而编译过程也不会使scratch空间访问变慢。我们发现，服务分离的模式确实有效，但这也会导致系统脆弱性增加，因为各个系统之间是相互依赖的，当其中一个出现问题时也会导致其他的系统无法正常工作。我们为这个问题找到了解决方案，但是类似这样的服务分离模型应该仔细规划，可能的话，有冗余将会更好。考虑到资金有限，我们可能会将大部分的NFS服务转移到一个专门的存储设备上，比如一个NetApp的文件服务器。

se9en

3.7 节点配置管理
由于一个群集中节点往往是数量最多的，那么有效的节点配置管理就成为至关重要的一环。许多系统在每个节点上安装操作系统，并对每个节点唯一的部分进行手工配置。其他的系统使用Etherboot，PXE或者LinuxBIOS工具从网络上启动各个节点。关键的一点就是集中管理和自动化。我们看到很多的群集上的节点不到万不得已的时候就不会更新，因为糟糕的群集架构设计使得节点升级不切实际。
节点配置管理可能是Fellowship架构中最独特的部分了。我们从基本的FreeBSD无盘启动过程开始，然后我们使用无盘的重新挂载功能来加载/etc 到/conf/base/etc并覆盖节点上的SSH密钥。对许多应用程序来说，这个配置应该已经足够了。然而，我们有一些应用程序需要大量的本地 Scratch空间，所以每个节点都拥有一个磁盘。通常，处理这些磁盘的方式是在系统安装的时候手工的在这些磁盘上创建合适的目录结构，然后让这些节点在每次启动的时候来挂载这些磁盘并运行fsck程序检查磁盘。我们认为这样做对Fellowship来说是不切实际的，因为节点都是批量安装的。另外，我们也需要从新配置磁盘的能力，就像对操作系统一样。所以，我们没有采用手工配置的方式，而是写了一个程序（diskmark）。这个程序利用了MBR分区表中的一个无效的表项来存储一个神奇数（magic number）和一个代表了当前分区方案的版本号。启动的时候，我们使用一个脚本来检查这个表项来确定磁盘的当前布局是否是我们所希望的。这个脚本会在 rc.diskless2之前运行。如果磁盘布局需要改变的话，diskless脚本会自动使用Warner Losh的diskprep脚本按照我们的希望初始化相应的磁盘。
有了这个配置以后，添加节点就非常简单了。基本的过程就是把他们装到机架上，接上电源然后启动。然后我们从交换机的管理控制台中获得它的MAC地址并把它添加到DHCP的配置中去，这个节点就可以获得一个众所周知的IP。在运行了脚本告知任务定时器关于这个节点的信息并重启节点之后，节点就可以使用了。
网路启动的镜像文件的维护是通过chroot到安装的 root账户然后按照标准的过程来升级操作系统和ports来完成的。对操作系统升级，我们会拷贝整个/root目录到另外的地方，将升级完成，然后使用几个节点进行测试；确定新的文件没有问题之后就修改DHCP的配置，然后重启所有的节点从而让他们使用新的root目录启动。如果需要安装新的软件，我们使用标准的ports安装过程并使用portupgrade来管理整个过程。对于ports中不存在的软件，他们将被安装的单独的/usr/aero目录下。
在原来的计划中，Fellowship的所有节点会利用BIOS对PXE的支持进行网络启动。PXE对服务器级别的主板来说是一个标准配置，但是看起来制造商对这一功能的测试比较差劲。我们的供应商不止一次地需要将主板送回到制造商处，让他们作出新的BIOS来修正PXE的问题。我们发现几乎所有的平台上的PXE都不怎么可靠，都会偶尔出现网络启动失败，但找不到明显原因。这时系统会试图从硬盘启动，当然这会失败，因为我们没有配置硬盘启动的任何信息。其中的一些问题看起来是由系统和Cisco交换机之间的互动引起的。最近，我们正在创建一个增强版本的diskprep程序，它可以让我们创建一个FreeDOS分区，自动重启机器并无限次地尝试网络启动。
3.8 任务调度计划
对于群集的架构师来讲，任务调度可说是最复杂最有争议的问题之一。主要的选项包括：无计划运行，手工调度，批量队列以及面向域（domain specific）的计划调度。
在一个小的环境中，用户的目标相互兼容，这时可以让他们在私下里相互协商的基础上任意使用计算资源。在很多时候，这个选项工作的很好。对于比较大的群集系统，一定程度的计划是必要的。即使用户的目标并不相互冲突，在成百上千的节点之间做出决定也是很困难的。另外，许多群集是多用途的，相互之间要有一定的平衡。在许多环境下，批量队列是个很好的调度方式。这有很多例子，比如OpenPBS，PBSPro，Sun Grid Engine，LSF，NQS和DQS。这些系统一般都带有一个计划调度程序（Scheduler)，但是许多系统也支持运行Maui backfill计划程序。OpenPBS和SGE是可以免费获得的开源应用程序，也是群集计划调度的最流行的选择。
对一些应用程序来说，批量队列并不是一个好的答案，因为他们需要运行非常大量的任务，或者是他们的各个子任务需要的运行时间差别非常大。比如，我们听说过一个计算型的生物科技应用程序，它每天都需要检测成千上万的测试案例，其中一些几秒钟就可以完成，而有的则要花上一整天的时间。在这种情况下，一个面向域的计划调度程序通常是必须的。一个通常的解决方案是，将这些测试案例存储一个数据库中，每个节点上的应用程序查询数据库取得工作单元，进行必要的处理然后将结果存储在数据库中，如此往复。
在Fellowship上，我们的应用程序也是多种多样，有些是可以以计划任务方式运行的小的任务，也有一些运行时间无法确定的程序。我们目前的策略是实现一个批量队列并期望这种调度方式可以帮助我们发现一种处理需要长时间运行的程序的方式。起初我们计划使用 OpenPBS，因为它已经存在于FreeBSD的ports中，而且是一个开源程序。然而不幸的是，我们发现OpenPBS在FreeBSD上有很严重的稳定性问题。就在我们准备好放弃OpenPBS的时候，SUN将SGE作为开源软件发布出来。FreeBSD并不在SGE的初始支持列表中，但是我们通过在邮件列表中的一些补丁程序将SGE移植到FreeBSD上，并且这部分源码也被返还到SGE的源码树中。
3.9 安全
对于绝大多数的群集来说，把它作为一个单一的系统来对待是最实际的安全策略。这样，对于那些和Internet并不直接相连的节点来说，就像 Fellowship上的那些节点，多有的漏洞都是本地的。这就意味着，对于一个给定的群集，它的安全策略是一个本地问题。对于有节点和Internet 相连的群集，安全管理就变得比较复杂，因为每一个节点上的漏洞都是一个可能的远程攻击对象。这种情况下，也有必要采取行动来保证已经被攻击者控制的节点不会危及其余的节点以及整个系统。在群集系统内部使用加密的通讯协议是一个针对这种情况的选项，但是要牢记加密协议对群集的性能影响。
一个例外的情形是群集本身就采取多层安全策略。我们对对这种系统有兴趣，但是目前为止还没有认真的调研。
我们的选择是将整个Fellowship从外围网络中保护起来。采取的主要措施包括，保持核心系统的持续更新，所有的通讯要采用加密的通讯协议，如SSH。在群集内部，我们鼓励使用SSH连接到各个节点，但同时也允许RSH连接。SGE的安装使用了基于PKI的用户验证体系。我们发现这一点是必需的，因为 SGE的缺省权限模式比RSH还要糟糕，它甚至不要求对低数字端口的保护。出于性能方面的考虑，节点间通讯是没有加密的。
3.10 系统监测
系统监测工具的使用可以帮助群集更稳定的运行。大多数常用的监测工具也适用于群集，比如Nagios和Big Sister。但有些类型的工具并不适用于群集，比如那种为每个节点发送常规email类型的。那样的话，即使少数几个节点产生的email也是管理员没有时间阅读的。除了标准的监测工具，也有一些专门针对群集的工具，比如Ganglia Cluster Monitor。大部分的任务调度程序也都包含监测功能。
我们在目前在Fellowship上运行的是Ganglia Cluster Monitor系统，核心系统上运行一些定期执行的脚本。GCM以前曾被移植到FreeBSD上，但我们还是创建了一个FreeBSD的port，让它的安装更容易，也更具BSD风格。GCM的一个主要的优势在。它不需要任何额外的配置就可以添加节点，他们会以组播的方式被自动发现。我们也考虑过使用 Nagios来监控节点，但是还未能成功部署它。监测也是fellowship上一个需要改进的领域。曾有一次重启后发生了硬盘故障，但任何人都没有发现，因为FreeBSD无盘系统的缺省行为让系统可以继续启动。节点可以继续工作是个不错的消息，但是我们惊奇地发现一些机器使用的是基于内存的非常小的 /tmp目录，而不是36+GB、基于磁盘的/tmp目录。
3.11 系统的物理管理
每个系统管理员都会发现他们在某一个时间需要通过系统的物理控制台来访问或者需要通过电源开关来重启系统。对于只有少数节点的系统，为每个系统加装显示器或者使用KVM系统，手工控制电源开关是一个合理的选择。对于一个大的群集系统，安装串行终端服务器和远程电源控制器来进行远程控制则是一个更合理的选择。
在Fellowship 的架构里，我们对远程管理是相当重视的。群集系统位于我们有权限控制的数据中心里，这也让物理访问相当麻烦。另外，主架构师和管理员都住在离这个数据中心 1000英里外的地方，这也让直接的物理访问更加困难。因此，我们为每个节点都做了可以远程访问的配置，包括控制台和电源。这可以让我们可以任意地重启任何系统，极大地帮助了我们进行系统回复和错误诊断。这样不能解决所有的问题，但是绝大部分都可以。我们成功地诊断了由于网络资源耗尽引起的重启，但对于 RAID控制卡硬件故障引起的宕机却无能为力。对于BIOS控制台访问功能也是成败参半：在Intel Xeon系统上它工作良好，但是Tyan PIII主板在BIOS重定向功能启用的时候就会无法启动。这两种情况下，我们都可以访问FreeBSD的控制台这一非常有用的功能。
3.12 外形因素（form factor）
系统形式的选择大体上就是放置在平台上的桌面系统和放在机柜上的服务器系统之间的选择。对于小型的群集来说，机架是一个更常见的选择，因为他们价格相对便宜，而且不大可能拥有一个冷却系统；不利之处在于，他们需要占用更大的空间，电缆线/网线管理的缺乏导致维护更加困难，而且看起来也不大漂亮。另外，大部分的这些系统违反了地震安全管理规范。
机架系统一般会更昂贵一些，因为他们的生产数量要少得多，同时也是服务器市场上的高利润产品。另外，机架或者橱柜的成本也比金属架高。作为高消费的回报，机架系统带来的是高密度，整合的线缆管理和更好的审美享受。
但是高密度是一把双刃剑。低端的机架经常是设计很差，测试也不足。狭窄的服务器槽以及糟糕的布线容易引起系统过热。同时，单个机架就可能产生很大的热量。我们估计，Fellowship的Xeon机架前后端的温差会有20-30度，尽管它们都位于温控良好的地下数据中心。每个机架的电能消耗峰值都可以达到 6000W。
机架系统还有一个很小的问题是橱柜式和开放的telco风格的机架之间的选择。橱柜看起来更加精致，理论上可以随意移动；它的缺点是成本进一步增加，空间的缺乏会让安装和调试服务器更加困难，空气流通困难也会更易于产生过热现象。Telco机架看上去没那么整齐，一般也是固定在地板上的，但是他们布线容易，空气流通也更顺畅。Fellowship使用的是带门的垂直式线缆管理，在没有橱柜的情况下看上去也不错。
Fellowship 的预期容量也让我们毫不犹豫地选择了机架配置。我们计划从项目开始到结束至少配备300颗CPU，使用常规的机柜的话将会占用过多的空间。我们的机架中唯一工作的不太好的地方就是它的六英寸宽的垂直线缆槽有时会显得非常拥挤。等下一个财政年度我们采购第二行机架时将会采用十英寸宽的线槽。
4. 经验教训
我们从中吸取的最大的经验就是硬件损耗是一个实实在在的问题。虽然我们没有遇到任何难以追踪的稳定性问题，但是几乎每次整栋楼断电时，不管是计划中的还是计划外的，我们都会失去至少一台机器。这也让我们认识到拥有一个能够快速修复系统的供应商是非常重要的。节点宕机比我们当初预计的要更加常见这一事实也意味着整齐的布线比我们当初想象的还要关键。当时的部署中我们为了节约成本而将各个节点直接连接到了交换机上，从而造成很多网线连接松垮，在移除和重新安装节点时造成了很多困难。下一年当我们将群集扩充到第二行机架时，我们计划在每个机架顶端放置一个面板，然后从这个面板连接到交换机旁的面板上。
我们也认识到，虽然大部分的HPC软件在FreeBSD上运行良好，但是HPC社区强烈的相信这个世界是一个Linux机。当问题出现时，常常难以断定是由于代码在FreeBSD的测试不足还是别的什么原因。我们希望更多的FreeBSD用户会考虑使用FreeBSD运行群集系统。
系统的自动化比我们当初设想的还要重要。比如说，为电力中断做准备而关闭系统可以远程完成，但是现在的系统需要我们登录到所有的20个电源控制器上。目前我们正在想办法将这个工作自动化，同时也让节点在外部电源中断时自动关闭。

5.结论以及未来方向
目前Fellowship工作良好。但是仍然有可以改进的地方，尤其是在系统管理自动化和计划调度方面。
我们已经制定了一个改良系统的计划，但是还没有开始替换旧的系统，所以无法断言这个计划的实际工作情况。很明显，到某个时间点后，节点的价值将会比它消耗的能量还要小，但我们还不知道这个时间点什么时候会到来。对FLOPS/Watt比值的测量将会有助于决定这个时间点。我们也不知道将来是否全体系统都会开始宕机或者是他们在一个很长的时间段里慢慢死掉。
另一个我们需要改进的地方关于计划调度。我们需要更好地处理那些用户清楚地知道运行时间，而又无法融入到目前的批量队列模型中的任务。有时一些用户的任务需要运行一周或者一个月，所以这是一个相对紧急的问题。我们目前正在申请内部资金来进一步探讨这个问题。
另外一个感兴趣的方面是所谓的“按需群集（cluster-on-demand)”模式，它可以让我们在不同的时间以不同的方式使用群集系统。一种可能是创建一个Emulab子群集，让它在没有用于网络仿真的时候来进行运算。
FreeBSD上的GFS式的分布式文件系统和BProc式的分布式进程模型是另外一个我们想要进一步探索的领域。目前Linux在这方面已经做了大量的工作，但是面向FreeBSD的几乎没有。
目前我们正在开发一个更高层的编程工具箱对一些具体的应用程序提供支持，比如用于计算流体动力学模型的Mesh Generation。同时也在部署Globus工具箱，它可以让我们的用户运行一些需要在不同的计算资源上（包括Fellowship， Aerospace的其他群集和一些SMP系统，像是SGI Origins）完成的应用程序。这样的应用程序可以用GridRPC之类的工具来开发。
作为一个中期计划，我们将迁移至FreeBSD 5.x系统以提高SMP的性能和对多线程功能的支持。即使时仅对多线程的支持，这对我们来说也是非常重要的一步。这个过程中有一些有很大的挑战需要克服。其中最重大的一个就是将我们的网络启动基础设施升级到源于NetBSD的rc.d启动脚本【Mewburn】和GEOM磁盘子系统【Kamp】。

目前Fellowship运行一系列不同类型的任务，用于对各种不同的空间系统做出决策。我们认为FreeBSD工作良好，为我们的工作提供了坚实的基础，对HPC的支持也不错。我们鼓励其他的用户考虑使用FreeBSD作为他们的HPC群集的基础。
致谢：
我们想要对GPS和STSS程序办公室的支持表示感谢。Aerospace计算机系统部门也为我们提供了很大帮助。同时，我们也想说，没有管理成本的资金支持，就没有今天的Fellowship。
参考资料:
Becker
    Donald J. Becker, Thomas Sterling, Daniel Savarese, John E. Dorband, Udaya A. Ranawak, Charles V. Packer, Beowulf: A Parallel Workstation for Scientific Computation Proceedings, International Conference on Parallel Processing, 1995.
Moore
    Justin Moore, David Irwin, Laura Grit, Sara Sprenkle, and Jeff Chase. Managing Mixed-Use Clusters with Cluster-on-Demand. Department of Computer Science. Duke University.
    http://issg.cs.duke.edu/cod-arch.pdf
Kamp
    Kamp, Poul-Henning. geom(4). GEOM - modular disk I/O request transformation framework. FreeBSD Kernel Interfaces Manual FreeBSD 5.1.
Perlstein
    Perlstein, Alfred. FreeBSD Jumpstart Guide.
    http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/
Mewburn
    Mewburn, Luke. The Design and Implemenation of the NetBSD rc.d system.
    http://www.mewburn.net/luke/papers/rc.d.pdf
MPI
    Message Passing Interface Forum. MPI: A Message-Passing Interface Standard.
    http://www.mpi-forum.org/docs/mpi-11.ps
SGI
    Silicon Graphics, Inc. Energy Department';s Blue Mountain Supercomputer Achieves Record-Breaking Run.
    http://www.sgi.com/newsroom/press_releases/2000/may/blue_mountain.html
Jeong
    Garrett Jeong, David Moffett. Welcome to ACME - The Advanced Computer Matrix for Engineering.
    http://acme.ecn.purdue.edu/
Schweitzer
    A. Schweitzer. The Klingon bird of Prey PC cluster.
    http://phoenix.physast.uga.edu/klingon/
SciClone
    The College of William and Mary. SciClone Cluster Project.
    http://www.compsci.wm.edu/SciClone/
RFC1918
    Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. Address Allocation for Private Internets.
RFC1178
    D. Libes. Choosing a Name for Your Computer.
Tolkien
    J.R.R. Tolkien. The Lord of the Rings 1955.
White
    B. White et al. An Integrated Experimental Environment for Distributed Systems and Networks. In 5th Symposium on Operating Systems Design and Implementation, December 2002.
Seymour
    Seymour, K., Nakada, H., Matsuoka, S., Dongarra, J., Lee, C., Casanova, H., An Overview of GridRPC: A Remote Procedure Call API for Grid Computing. 3rd International Workshop on Grid Computing, November, 2002.