| Cannot find a valid baseurl for repo: core 错误解决办法 |
| 服务器装完了，准备更新系统，yum check-update
提示错误如下： [root@localhost ~]# yum check-update Setting up repositories core [1/3] Cannot find a valid baseurl for repo: core Error: Cannot find a valid baseurl for repo: core 一堆乱七八糟,在海里劳了半天也没有找到有用的
我用下边的方法解决：
1. 升级yum.conf # mv /etc/yum.conf /otherpath/back 2. 下载配置文件 # wget http://www.fedorafaq.org/samples/yum.conf 3.升级yum #rpm -Uvh http://www.fedorafaq.org/yum OK了.... @_@!
|
谷 珊, 软件测试工程师, IBM
谷珊，IBM 中国开发中心的软件测试工程师。参与过 Tivoli 监控产品和存储产品的功能测试及系统测试工作。对软件测试理论、测试方法有浓厚兴趣。目前参与 IBM Information Archive 产品的高可用性测试工作。
陈志阳, 软件测试工程师, IBM
陈志阳，IBM 中国开发中心的软件测试工程师。于 2008 年加入 IBM, 一直从事测试工作。目前参与 IBM Information Archive 产品的高可用性测试工作。
简介： 高可用性集群系统可以自动实现关键服务在集群中各个机器之间的切换，使得客户机可以继续访问这些资源，以达到提供不间断服务的目的，用以提高系统的稳定性、可靠性等。本文以 Linux 集群环境为背景，在介绍了高可用性集群系统的概念、常用的实现高可用性支持方法的基础上，详细讲解了如何针对这些常用的高可用性实现方法来进行错误注入策略的自动化测试。本文适用于软件系统测试工程师以及任何想了解高可用性测试的读者。
发布日期： 2010 年 3 月 25 日
级别： 初级
平均分 （共 5 个评分 ）
什么是高可用性集群系统
通常，可用性采用“每年故障时间”进行衡量。常规的容错系统可以达到 99.99% 的可靠度，即相当于每年故障 1 小时 ( 每天故障 10 秒钟 )。但高可用性系统则有望达到 99.999% 的业务时间内系统可靠的运行，即每天故障 1 秒钟。这意味着当故障出现时，系统必须能自动处理 ，无需人为干预即可管理故障检测和纠错。因为操作人员难以在很短的时间内移除或掩盖任何故障。
高可用性集群系统是基于两个或两个以上节点的环境，用于合作处理同一任务的系统。在系统中某一节点出现故障时，集群服务器会自动把某些资源转移到其它节点，使得客户机可以继续访问这些资源，以达到提供不间断服务的目的，用以提高系统的稳定性、可靠性等。
高可用性集群系统支持多种操作系统平台，本文着重介绍在 Linux 上高可用性集群系统测试的最佳实践。
回页首
在 Linux 集群系统中实现对高可用性支持的常用方法
并不是所有的 Linux 集群系统都具有高可用性的功能，这需要提供额外的设计来支持。高可用性解决方案用于监控系统和应用程序服务，并在硬件或软件出现故障时重新启动这些服务。通常，可通过增加冗余硬件或软件的方式来实现。下面介绍几种常用的实现高可用性支持的方法，以便针对这些常用方法来进行自动化测试的最佳实践。
多机就绪模式
所谓多机，即集群中的多台机器都是主服务器，共享文件系统，各自运行着一些服务。以包含两个主服务器节点的环境为例，在这两个主服务器节点上，安装着完全相同的软件且共享文件系统。主服务器节点 node1 和 node2 的 CNFS 服务分别在两个节点上各自运行着。可以在 Linux 的命令行利用 ifconfig 命令查看 CNFS IP：
node1:~ # ifconfig
bond0:0 Link encap:Ethernet HWaddr 00:1A::C7:4C:0C
inet addr:9.11.124.11 Bcast:9.11.125.255 Mask:255.255.254.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
node2:~ # ifconfig
bond0:0 Link encap:Ethernet HWaddr 00:1A::C7:4C:54
inet addr:9.11.124.12 Bcast:9.11.125.255 Mask:255.255.254.0
| UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 |
client: #mkdir /mnt/node1_mountpoint
client: #mkdir /mnt/node2_mountpoint
client: # mount 9.11.124.11:/collection/data /mnt/node1_mountpoint
| client: # mount 9.11.124.12:/collection/data /mnt/node2_mountpoint |
node2:~ # ifconfig
bond0:0 Link encap:Ethernet HWaddr 00:1A::C7:4C:54
inet addr:9.11.124.12 Bcast:9.11.125.255 Mask:255.255.254.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
bond0:1 Link encap:Ethernet HWaddr 00:1A::C7:4C:0C
inet addr:9.11.124.11 Bcast:9.11.125.255 Mask:255.255.254.0
| UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 |
利用 Linux 中的 bonding 技术配置冗余网络
Linux 下的 bonding 技术，将多块网卡接口通过绑定虚拟成为一块网卡，在用户看来这个聚合起来的设备好像是一个单独的以太网接口设备，或者说就是多块网卡具有相同的 IP 地址而并行连接聚合成一个逻辑链路工作。
Bonding 技术用于高可靠性，提供最大网络可靠性的配置，通过在主机和其他设备间的冗余或备份设备、链路或交换机，目标是提供最大的网络链接可靠性（要求网络一直可用）。
以每个节点上面有四个网卡接口 (eth10,eth11,eth12,eth13) 为例，它们可被虚拟成两个绑定设备：bond0 和 bond1。bond0 为外部网卡 , 被绑定的网卡接口（也称为 slave 设备）是 eth10 和 eth12；bond1 为内部网卡，被绑定的网卡接口是 eth11 和 eth13。其中 bond0 用于外部通信，bond1 用于节点之间通信。其网络结构如图所示：
图 1. 网络结构图
绑定配置
绑定设备 bond0 和 bond1 分别对应配置信息文件 /proc/net/bonding/bond0 和 /proc/net/bonding/bond1。以 /proc/net/bonding/bond0 为例，其内容如下：
Ethernet Channel Bonding Driver: v3.0.1 (January 9, 2006)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth10
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200
Slave Interface: eth10
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:21:5e:09:61:06
Slave Interface: eth12
MII Status: up
Link Failure Count: 0
| Permanent HW addr: 00:1a::e7:10:d6 |
Primary Slave 指定哪个 slave 成为主设备 (primary device)，取值为字符串，如 eth0，eth1 等。只要指定的设备可用，它将一直是激活的 slave。只有在主设备（primary device）断线时才会切换设备。这在希望某个 slave 设备优先使用的情形下很有用，比如，某个 slave 设备有更高的吞吐率。
Currently Active Slave 为当前被激活的 slave 设备。bond0 设备有两个 slave 设备：eth10 和 eth12。当前被激活的 slave 设备是 eth10。
MII Status 为 MII 监控状态。MII 监控通过监控本地网络接口的载波状态来实现监控链路状态。可以通过 3 种方法之一来实现：通过依赖设备驱动来维护载波状态；通过查询设备的 MII 寄存器；或者通过给设备发送 ethtool 查询。
MII Polling Interval 指定 MII 链路监控频率，这将决定驱动检查每个 slave 链路状态频率，100 为初始参考值。
Up Delay 指定当发现一个链路恢复时，在激活该链路之前的等待时间。
Down Delay 指定一个时间，用于在发现链路故障后，等待一段时间然后禁止一个 slave 设备。
网络配置
网络配置可以通过 ifconfig 命令查看，Bonding 设备会被标上 MASTER 标记，slave 设备会被标上 SLAVE 标记。ifconfig 的输出不包含哪个 slave 设备关联于哪个 Bonding 设备的关系。
# /sbin/ifconfig
bond0 Link encap:Ethernet HWaddr 00:21:5E:09:61:06
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.255.0
inet6 addr: fe80::221:5eff:fe09:6106/ Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:102250 errors:0 dropped:0 overruns:0 frame:0
TX packets:3083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:29734912 (28.3 Mb) TX bytes:3297 (355.7 Kb)
bond1 Link encap:Ethernet HWaddr 00:21:5E:09:61:04
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.248.0
inet6 addr: fe80::221:5eff:fe09:6104/ Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:438007 errors:0 dropped:0 overruns:0 frame:0
TX packets:193184 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:39536092 (37.7 Mb) TX bytes:16723783 (15.9 Mb)
eth10 Link encap:Ethernet HWaddr 00:21:5E:09:61:06
inet6 addr: fe80::221:5eff:fe09:6106/ Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:51369 errors:0 dropped:0 overruns:0 frame:0
TX packets:3080 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:143183 (14.2 Mb) TX bytes:3075 (355.5 Kb)
Interrupt:138 Memory:98000000-98012100
eth11 Link encap:Ethernet HWaddr 00:21:5E:09:61:04
inet6 addr: fe80::221:5eff:fe09:6104/ Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:340168 errors:0 dropped:0 overruns:0 frame:0
TX packets:193180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:33274394 (31.7 Mb) TX bytes:16723497 (15.9 Mb)
Interrupt:169 Memory:96000000-96012100
eth12 Link encap:Ethernet HWaddr 00:21:5E:09:61:06
inet6 addr: fe80::221:5eff:fe09:6106/ Scope:Link
UP BROADCAST RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1
RX packets:50881 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14841729 (14.1 Mb) TX bytes:222 (222.0 b)
Interrupt:146 Memory:94000000-94012100
eth13 Link encap:Ethernet HWaddr 00:21:5E:09:61:04
inet6 addr: fe80::221:5eff:fe09:6104/ Scope:Link
UP BROADCAST RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1
RX packets:97839 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6261698 (5.9 Mb) TX bytes:286 (286.0 b)
| Interrupt:177 Memory:92000000-92012100 |
综上，冗余的网络结构可以保证在某节点出现故障或网卡出现问题时，网络一直可用。
安装远程管理卡 (RSA Card)
远程管理卡提供警告和远程监控等功能。它本身并不会实现高可用性功能，而是利用其远程监控功能，用以恢复不健康节点。
远程管理卡需要被安装在被管理服务器空的 PCI 插槽中，然后在 BIOS 里做相应的配置。以 IBM RSA II 为例来进行配置说明：
∙重启机器，按”F1”进入 BIOS 设置；
∙选择“Advanced Steup”->“RSA II Settings”：
图 2. RSA II Settings 界面
∙在“RSA II Settings”页面，选择用静态 IP 的方式，填入你想分配给该远程管理卡的 IP 地址、子网掩码和网关等信息。
∙填写完后选择“Save Values and Reboot RSA II”退出配置并使其生效。
∙编辑 /etc/hosts 文件，加入远程管理卡的 IP 地址。
配好了远程管理卡对应的 IP 地址后，就可以通过网页或 telnet 方式在 Linux 集群环境中任一机器上访问该远程管理卡了。
∙网页方式：
打开浏览器，在地址栏里输入要连接的远程管理卡的 IP 地址。RSA II 的 http 访问端口默认为 80，所以在地址栏中可不输入端口直接访问。输入用户名和密码，默认值为 USERID 和 PASSW0RD：
图 3. 连接远程管理卡的安全验证窗口
登陆后的管理台页面如下：
图 4. 远程管理卡的图形化管理界面
可点击左侧导航条中“Tasks”下面的各链接对该机器进行远程操作。
∙telnet 方式：
node1:~ # telnet 9.11.125.243
Trying 9.11.125.243...
Connected to 9.11.125.243.
Escape character is '^]'.
username: USERID
password: ********
| SN# K106086T2NC> |
power cycle -s: 重启
power cycle: 马上重启
power off -s: 关闭机器
power off: 马上关闭机器
power state: 查看 RSA 卡的状态
reset -s: 软重启
reset： 马上软重启
power off: 马上关闭机器
power on: 启动机器
例如：SN# K106086T2NC>reset
该服务器将被重启。
增加冗余监控进程
在“多机就绪模式”中我们曾提到健康节点会识别出问题节点，从而接管问题节点上的服务。但如何识别出问题节点呢？这就需要在每个节点上都增加一个监控进程，它的作用就是每隔一段时间去检查邻节点的健康状况。例如一个包含三个节点的 Linux 集群环境，节点 A 上监控进程检查结点 B 的健康状况，节点 B 上的监控进程检查节点 C 的健康状况 , 节点 C 上的监控进程检查节点 A 的健康状况。如下图所示：
图 5. 节点健康状况检查顺序图
当发现出现问题时，会修复问题结点。所谓修复问题结点，包括如下一些操作：
∙重启问题结点：
通过远程管理卡，重启机器以到达恢复此节点的目的。
∙转移问题结点上运行的一些应用或资源（如 CNFS）到健康的节点：
为了用户对于问题节点上运行的一些服务能够在节点被重启的过程中还可用，需要在问题节点不可获得的时间里，把这些服务转移到其他节点上。以至于用户感觉不到问题节点的存在，可继续访问这些服务。
∙在节点恢复健康后，把原来运行在它上面的应用或资源转移回去。
另外，监控进程本身需具有自动修复功能。当监控进程由于某些原因被停掉后，它可自动被重启以保持正常运行。
判断节点健康的标准有：
∙该节点是否可 ping 通；
∙该节点是否可通过 SSH 访问；
∙watchdog 的监控进程是否运行着；
其中任一条不满足，我们都认为该节点不健康。
回页首
利用错误注入策略进行高可用性测试
高可用性测试的方法有很多，比如可通过手工方式拔掉网线、重启机器等，也可通过自动的错误注入策略，把破坏系统健康的操作写到脚本中。结合上一章节中提到的实现高可用性的常用方法，下面主要讲解在实现了这些方法的 Linux 集群环境中如何利用自动错误注入策略来进行自动化的高可用性测试。
所谓自动错误注入策略，就是利用关闭某个节点或杀掉监控进程来模拟机器故障，以此触发系统实施切换功能。根据上面提到的几种判断节点是否健康的标准，我们可以采用如下几种方法模拟节点不健康情况的发生：
∙杀掉监控进程；
∙执行"power cycle"命令，让节点重启；
∙执行"reset -s" 命令，让节点首先关闭所有进程然后重启；
下面以“杀掉监控进程”来模拟机器故障为例 , 分为俩部分来详细讲解如何进行高可用性测试，同时配以 Perl 语句说明如何实现相应操作：
Failover 的过程
检查应用（资源）是否能够在节点失效后被转移到其他节点。通常我们称这个过程为 Failover。
去掉监控进程的执行权限：
由于监控进程具有自我修复能力，能够在停掉后自动重启，因此在采用“杀掉监控进程”这种方式来模拟机器故障前，需要把监控进程的执行权限去掉。我们假设监控进程名为 watchdog, 便于在命令中进行说明：
| chmod 444 watchdog |
得到监控进程的进程 ID，然后杀掉，以此来模拟机器不健康状况的发生：
my $watchdog _record = ps – ef | grep watchdog | grep – v grep;
chomp($watchdog _record);
my $id= (split(/\\s+/,$ watchdog _record))[1];
| kill $id; |
根据上面提到的判断节点健康的标准，可以采用如下对应的方法进行检测：
∙该节点是否可 ping 通：/bin/ping -c 3 ∙该节点是否可通过 SSH 访问 : /usr/bin/ssh -l root ∙监控进程是否运行着 : ps – ef|grep watchdog 在以上任一条件不满足时，即认为该节点不健康。本例中我们采用的是杀掉监控进程致使不满足第三点。在检测出监控进程没有运行时，首先会执行启动监控进程的命令去自我修复，而不是马上重启机器。但由于我们在之前的步骤中已经去掉了监控进程的执行权限，因此在系统尝试几次重启监控进程失败后，就会重启该节点。重启的方法是采用 RSA 卡进行 powercycle, 实现的语句如下： telnet Trying Connected to Escape character is '^]'. username: USERID password: ******** 本例中被转移的资源为 CNFS IP，在不健康节点被重启后， 运行在其上面的 CNFS IP 不会马上切换到别的节点。需要等待一段时间后，才会由集群中的其它节点进行接管。至于由集群中的哪个节点来接管，是随机的，所以需要在每个健康节点上进行判断。 判断它是否被成功转移到其他节点可通过如下方法实现： my $cnfs_record = mmgetifconf | grep bond0: | grep -v grep; chomp($cnfs_record); my $victim_node_cnfsip= (split(/\\s+/,$ cnfs_record))[1]; my $cnfsip = /usr/lpp/mmfs/bin/mmgetifconf | grep $ victim_node_cnfsip; if ($cnfsip ne “”) { print " cNFS IP appeared within the cluster again. Failover successful! \\n"; 在修复好后，检查这些应用（资源）是否能再迁移回原先运行的节点。通常我们称这个过程为 Failback。 检查问题节点是否重启成功： 可通过是否能 ping 的方式检查： 前面的过程中我们曾经去掉了监控进程的执行权限，目的是不让监控进程在停掉后自动重启，用以模拟机器故障，以此触发系统实施切换功能。现在在问题节点被修复后，需要恢复监控进程的执行权限。以便在节点重启后，该进程也能够被自动重启。 检查监控进程是否能够自动重启成功： 不同的产品有不同产品进程需要在节点被修复好后保持正常运行。这也是判断高可用性产品是否成功的重要标准之一。下面仅用一个通用的程序框架来实现检验各进程是否恢复运行： $ problem = 0; $result = ps -ef | grep chomp($result); $pid = (split(/\\s+/,$result))[1]; $date = `date +%Y-%m-%d-%H:%M:%S`; chomp($date); print "$date if ($pid eq "") { $date = `date +%Y-%m-%d-%H:%M:%S`; chomp($date); print "\\n$date WARNING: $ problem++; 以被转移走的 CNFS IP 为例，在原来的问题节点上执行： 回页首 结束语 高可用性测试，作为系统测试中一个很重要的测试类型，用来确保产品可以提供不间断的服务。测试高可用性的方法有很多，即可手工也可自动。为了提高测试效率，如何根据产品自身对高可用性支持的实现方法进行自动化测试是十分重要的。本文就是基于一些常见的高可用性支持的实现方法，通过自动错误注入策略来把破坏系统健康的操作写到脚本中，以此实现高可用测试的自动化。需要注意的是，该脚本并不适用于所以产品的高可用性测试，本文只是提供了一个理念，还需要读者结合实际产品情况，结合您系统采用的高可用性实现方法，对该脚本进行修改。 参考资料 ∙通过 Linux Ethernet Bonding Driver HOWTO: 了解更多如何在 Linux 操作系统下配置和实现 Bonding 技术的知识。 ∙通过 IBM eServer xSeries and BladeCenter Server Management: 了解更多关于 IBM RSA II 的安装和操作方面的知识。 ∙通过 High Availability Fundamentals: 了解更多关于高可用性的概念。 ∙通过 可用性及其测试方法：了解常用的可用性测试方法、案例分析等。 ∙在 developerWorks Linux 专区 寻找为 Linux 开发人员（包括 Linux 新手入门）准备的更多参考资料，查阅我们 最受欢迎的文章和教程。 ∙在 developerWorks 上查阅所有 Linux 技巧 和 Linux 教程。 Linux高性能计算集群 - 概述 窗体顶端 窗体底端 金戈 (jinge@cn.ibm.com), IBM软件工程师, IBM 2002 年 11 月 09 日 本文是Linux高性能集群系列文章的第一部分。这一部分介绍了集群系统的基本知识，并解释了两类主要的集群：高可用集群和高性能集群。本系列文章的后面几部分将围绕Beowulf高性能集群展开。笔者先介绍Beowulf集群的体系结构，然后陆续介绍Beowulf集群的硬件、网络、软件和应用程序的部分的系统构成，最后集群系统管理软件。 1 集群 1.1 什么是集群 简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点（node）。一个理想的集群是，用户从来不会意识到集群系统底层的节点，在他/她们看来，集群是一个系统，而非多个计算机系统。并且集群系统的管理员可以随意增加和删改集群系统的节点。 1.2 为什么需要集群 集群并不是一个全新的概念，其实早在七十年代计算机厂商和研究机构就开始了对集群系统的研究和开发。由于主要用于科学工程计算，所以这些系统并不为大家所熟知。直到Linux集群的出现，集群的概念才得以广为传播。 对集群的研究起源于集群系统的良好的性能可扩展性(scalability)。提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能，于是出现了向量机，对称多处理机(SMP)等。但是当CPU的个数超过某一阈值，象SMP这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反，集群系统的性能随着CPU个数的增加几乎是线性变化的。图1显示了这中情况。 图1. 几种计算机系统的可扩展性 集群系统的优点并不仅在于此。下面列举了集群系统的主要优点： 1.高可扩展性：如上所述。 2.高可用性：集群中的一个节点失效，它的任务可以传递给其他节点。可以有效防止单点失效。 3.高性能：负载平衡集群允许系统同时接入更多的用户。 4.高性价比：可以采用廉价的符合工业标准的硬件构造高性能的系统。 1.2.1 集群系统的分类 虽然 根据集群系统的不同特征可以有多种分类方法，但是一般我们把集群系统分为两类： ∙高可用(High Availability)集群,简称HA集群。这类集群致力于提供高度可靠的服务。 ∙高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。 2.1 什么是高可用性 计算机系统的可用性(availability)是通过系统的可靠性(reliability)和可维护性(maintainability)来度量的。工程上通常用平均无故障时间(MTTF)来度量系统的可靠性，用平均维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为： 表1. 系统可用性分类 (Percent Availability) (downtime/year) 表 2. 停机给企业带来的损失 2.2 高可用集群 高可用集群就是采用集群技术来实现计算机系统的高可用性。高可用集群通常有两种工作方式： ∙容错系统：通常是主从服务器方式。从服务器检测主服务器的状态，当主服务工作正常时，从服务器并不提供服务。但是一旦主服务器失效，从服务器就开始代替主服务器向客户提供服务。 ∙负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。 关于高可用集群的讨论很多，这里就不进行深入的阐述了。 3.1 什么是高性能计算集群 简单的说，高性能计算(High-Performance Computing)是计算机科学的一个分支，它致力于开发超级计算机，研究并行算法和开发相关软件。高性能计算主要研究如下两类问题： ∙大规模科学问题，象天气预报、地形分析和生物制药等； ∙存储和处理海量数据，象数据挖掘、图象处理和基因测序； 顾名思义，高性能集群就是采用集群技术来研究高性能计算。 3.2 高性能计算分类 高性能计算的分类方法很多。这里从并行任务间的关系角度来对高性能计算分类。 3.2.1 高吞吐计算(High-throughput Computing) 有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人（ SETI@HOME -- Search for Extraterrestrial Intelligence at Home ）就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照Flynn的分类，高吞吐计算属于SIMD（Single Instruction/Multiple Data）的范畴。 3.2.2 分布计算(Distributed Computing) 另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD（Multiple Instruction/Multiple Data）的范畴。 3.3 Linux高性能集群系统 当论及Linux高性能集群时，许多人的第一反映就是Beowulf。起初，Beowulf只是一个著名的科学计算集群系统。以后的很多集群都采用Beowulf类似的架构，所以，实际上，现在Beowulf已经成为一类广为接受的高性能集群的类型。尽管名称各异，很多集群系统都是Beowulf集群的衍生物。当然也存在有别于Beowulf的集群系统，COW和Mosix就是另两类著名的集群系统。 3.3.1 Beowulf集群 简单的说，Beowulf是一种能够将多台计算机用于并行计算的体系结构。通常Beowulf系统由通过以太网或其他网络连接的多个计算节点和管理节点构成。管理节点控制整个集群系统，同时为计算节点提供文件服务和对外的网络连接。它使用的是常见的硬件设备，象普通PC、以太网卡和集线器。它很少使用特别定制的硬件和特殊的设备。Beowulf集群的软件也是随处可见的，象Linux、PVM和MPI。 本文的以后几部分将详细介绍Beowulf集群系统的硬件、网络、软件和应用体系结构。 3.3.2 Beowulf集群和COW集群 象Beowulf一样，COW（Cluster Of Workstation）也是由最常见的硬件设备和软件系统搭建而成。通常也是由一个控制节点和多个计算节点构成。COW和Beowulf的主要区别在于： 1.COW中的计算节点主要都是闲置的计算资源，如办公室中的桌面工作站，它们就是普通的PC，采用普通的局域网进行连接。因为这些计算节点白天会作为工作站使用，所以主要的集群计算发生在晚上和周末等空闲时间。而Beowulf中的计算节点都是专职于并行计算，并且进行了性能优化。它们采用高速网（Myrinet或Giganet）上的消息传递（PVM或MPI）进行进程间通信（IPC）。 2.因为COW中的计算节点主要的目的是桌面应用，所以它们都具有显示器、键盘和鼠标等外设。而Beowulf的计算节点通常没有这些外设，对这些计算节点的访问通常是在管理节点上通过网络或串口线实现的。 3.因为连接COW中计算节点的通常是普通的局域网，所以COW上的高性能应用通常是象SETI@HOME 这样的SIMD的高吞吐计算。而Beowulf无论从硬件、网络和软件上都对需要频繁交换数据的MIMD应用做了特别的优化。 3.3.3 Mosix集群 窗体顶端 窗体底端 金戈 (jinge@cn.ibm.com), IBM软件工程师, IBM 2002 年 11 月 20 日 本文是高性能集群系列文章的第三部分。在本文中，笔者以IBM eServer Cluster 1300为例介绍了Beowulf集群中硬件和网络体系结构和组成部分。 1 Beowulf集群硬件和网络体系结构 图 1是Cluster 1300的硬件和网络体系结构图 图 1是Cluster 1300的硬件和网络体系结构图。从图中可以看出，整个系统由5类计算或网络设备和5类网络组成。这5类设备是: ∙主控制节点(Control Node) ∙计算节点 ∙以太网交换机(Ethernet Switch) ∙Myrinet交换机 ∙Terminal Server 5类网络是： ∙集群局域网(Cluster VLAN蓝色) ∙管理网络(Management VLAN 右边绿色) ∙IPC网络(IPC VLAN 棕色) ∙Terminal网络(灰色) ∙Service Processor网络(左边绿色) 本文的以下部分将介绍这些设备和网络的角色，功能和一般的配置。 这一节主要介绍Beowulf集群中的节点，节点的类型和相应的功能。根据功能，我们可以把集群中的节点划分为6种类型： ∙用户节点(User Node) ∙控制节点(Control Node) ∙管理节点(Management Node) ∙存储节点(Storage Node) ∙安装节点(Installation Node) ∙计算节点(Compute Node) 虽然由多种类型的节点，但并不是说一台计算机只能是一种类型的节点。一台计算机所扮演的节点类型要由集群的实际需求和计算机的配置决定。在小型集群系统中，用户节点、控制节点、管理节点、存储节点和安装节点往往就是同一台计算机。下面我们分别解释这些类型节点的作用。 2.1 用户节点(User Node) 用户节点是外部世界访问集群系统的网关。用户通常登录到这个节点上编译并运行作业。 用户节点是外部访问集群系统强大计算或存储能力的唯一入口，是整个系统的关键点。为了保证用户节点的高可用性，应该采用硬件冗余的容错方法，如采用双机热备份。至少应该采用RAID(Redundant Array of Independent Disks)技术保证用户节点的数据安全性。 2.2 控制节点(Control Node) 控制节点主要承担两种任务 ∙为计算节点提供基本的网络服务，如DHCP、DNS和NFS。 ∙调度计算节点上的作业，通常集群的作业调度程序(如PBS)应该运行在这个节点上。 通常控制节点是计算网络中的关键点，如果它失效，所有的计算节点都会失效。所以控制节点也应该有硬件冗余保护。 2.3 管理节点(Management Node) 管理节点是集群系统各种管理措施的控制节点： ∙管理网络的控制点，监控集群中各个节点和网络的运行状况。通常的集群的管理软件也运行在这个节点上。 ∙ASMA的控制点：ASMA(Advanced System Manager Adapter)允许将计算节点通过菊花链连接构成Service Processor网络用于接受计算节点的警报并收集SNMP Trap. 2.4 存储节点(Storage Node) 如果集群系统的应用运行需要大量的数据，还需要一个存储节点。顾名思义，存储节点就是集群系统的数据存储器和数据服务器。如果需要存储TB级的数据，一个存储节点是不够的。这时候你需要一个存储网络。通常存储节点需要如下配置： ∙ServerRAID保护数据的安全性 ∙高速网保证足够的数据传输速度 2.5 安装节点(Installation Node) 安装节点提供安装集群系统的各种软件，包括操作系统、各种运行库、管理软件和应用。它还必须开放文件服务，如FTP或NFS。 2.6 计算节点 计算节点是整个集群系统的计算核心。它的功能就是执行计算。你需要根据你的需要和预算来决定采用什么样的配置。理想的说，最好一个计算节点一个CPU。但是如果考虑到预算，也可以采用SMP。从性价比角度说，两个CPU的SMP优于3或4个CPU的SMP机器。 因为一个计算节点的失效通常不会影响其他节点，所以计算节点不需要冗余的硬件保护。 2.7 集群中节点的部署 虽然由多种类型的节点，但并不是说一台计算机只能是一种类型的节点。一台计算机所扮演的节点类型要由集群的实际需求和计算机的配置决定。在小型集群系统中，用户节点、控制节点、管理节点、存储节点和安装节点往往就是同一台计算机，这台计算机通常成为主节点(Master Node)。在这种情况下，集群就是由多个计算节点和一个主节点构成。 在大型的集群系统中如何部署这些节点是个比较复杂的问题，通常要综合应用需求，拓扑结构和预算等因素决定。 3.1 集群中的网络技术 因为计算节点间的通信需求，IPC网络的性能是Beowulf集群设计中非常重要的话题。由于应用的需求，通常需要高带宽、速度和低延迟的网络。Beowulf集群的主要瓶颈通常也在于双工的网络通信，延迟和全局同步。 有好几种网络技术可以用于IPC网络。它们是快速以太网、千兆以太网和Myrinet。为了达到高带宽，通常需要采用交换机。交换机接受从双绞线传来的数据包，但是它和集线器不一样。它不向所有连接的节点广播这个数据包，它会根据目的地址哪个端口是接受者，然后把这个包传给接受者。 3.2 Beowulf集群网络拓扑 如上所述，通常Beowulf集群系统中有5类网络。其中Service Processor网络是以太网连接起来的菊花链结构，Terminal网络是计算节点和Terminal Server通过串口线连接起来的 星形结构。管理网络、集群网络和IPC网络则是通过交换机相连的。虽然可以把这三个网络配置在一个网段，但是通常我们把它们分化在三个虚拟网中(VLAN)。 图2是Beowulf集群网络结构。 3.2.1 管理网络(Management VLAN) 管理网络用于访问IPC网络交换机、Service Processor网络和Terminal Server。HTTP、Telnet和SNMP等协议被用来管理这些设备。 3.2.2 集群网络(Cluster VLAN) 计算节点和存储节点用这个网络进行通常的网络I/O。 3.2.3 IPC网络(IPC VLAN) 用于计算节点间的高速通信。通常由特殊的高速网络设备构成。 3.2.4 Service Processor网络 以太网连接起来的菊花链结构，用于系统管理目的。 3.2.5 Terminal网络 Terminal网络是计算节点和Terminal Server通过串口线连接起来的星形结构。Terminal Server是外界访问这个网络的接口。 管理节点通过Terminal Server虚拟出来的终端可以登录到其他节点上完成必要的管理工作。 3.2.6 KVM网络 KVM网络是KVM Switch和各节点连接的星形网络。其实把KVM网络称为一个网络并恰当。KVM是指Keyboard、Video和Mouse。通过KVM Switch的切换， 管理员可以在管理各个节点。 Qty .P/N Description IBM Products Compute Nodes 4 865431Y xSeries 330 1000 256 256/OPEN 24X 4 37L7202 18.2GB Ultra160 HDD 4 10K3806 866Mhz 133MHz 256K 12 33L3144 256MB 133MHz ECC SDRAM RDIMM MEMORY 1 06P4792 C2T Cable Kit Management Node 1 865RY xSeries 340,866Mhz,128Mb 1 19k4630 866Mhz 133MHz 256K 4 33L3144 256MB 133MHz ECC SDRAM RDIMM MEMORY 1 37L6091 ServeRAID 4L LVD SCSI Adapter 3 37L7202 18.2GB 7200rpm Ultra160 SCSI Hot-Swap SL H 1 34L1501 Netfinity 10/100 Ethernet PCI Adapter 2 1 34L0301 Netfinity Gigabit Ethernet SX Adapter 1 37L6880 270W Redundant HS Power Supply Shared Resources 1 9306200 Netbay 22 Half Rack 1 3619702 Netbay 22 Rack Extension Kit 1 9411AG1 Monitor (flatpanel) 1 L6888 Flatpanel rack mount kit 1 09N4291 8x2 Console Switch (KVM Switch) 2 94G7447 Console Cable Set 12ft (to KVM switch) 1 28L34 Spacesaver Keyboard/trackpoint 1 28L4707 Keyboard tray 2 37L6866 Netbay Universal Voltage PDU 1 01K7209 ASMA Adapter (Wiseman card) 1 36L9973 1M Fibre Channel Cable 1 03K9308 Short Wave GBIC (Gigabit module) Equinox Products 1 990209 Equinox ELS-16 1 210059 Micro-Transceiver,AUI (DB-15)to 10BaseT 1 790091 ELS Rackmount kit 4 210062 Equinox Serial Adapters 4 690226 10'Serial Cables Myrinet Networking Products 1 M3-E16 Myrinet2000 3-slot Chassis 1 M3-M Management Module 4 M3S-CB-5M Myricom Myrinet LAN cables 4 M3S-PCIB-2 Myrinet LAN Card 1 M3SW16-8S Myrinet 8-port Serial modules Miscellaneous Products 8 3'CAT5 Cables 5 1'CAT5 Cables Extreme Networks Products 窗体顶端 窗体底端 金戈 (jinge@cn.ibm.com), IBM软件工程师, IBM 2002 年 11 月 20 日 本文是高性能集群系列文章的第四部分。本文首先给出了Beowulf集群的软件体系结构。然后分别讨论了集群和操作系统、文件系统的关系。最后讨论了集群应用并行化的问题。 1 Beowulf集群软件结构 图1 是Beowulf集群的软件体系机构。一般来说，Beowulf集群由如下几个软件部分组成： ∙操作系统：勿容置疑，操作系统是任何计算机系统的软件基础。相对于桌面系统而言，集群系统对操作系统的任务调度和文件管理方面的要求更高。 ∙并行开发库：只要是指用于集群中进程通信的软件库。消息传递和线程是两种基本的通信方法。但是对于Beowulf集群而言，消息传递更适合一些。Beowulf集群常用的开发库是MPI和PVM。 ∙作业管理：调度作业并管理集群系统的资源，是集群系统的资源得到最大的利用。 ∙系统管理：管理和监控整个集群系统。 ∙开发环境：开发和调试高效能应用的开发工具。 ∙标准应用：一些标准的高性能应用如CFD。 ∙客户应用：客户特别定制的应用。 并不是每种操作系统都适合高性能集群系统。理论上说，硬件的体系结构、操作系统的任务调度方式和IPC的方式是决定应用并行化效果的主要因素。根据这三个因素，我们可以归纳出如下5种实施应用并行化的平台： ∙单任务操作系统：CPU同时只处理任务队列中的一个任务。MS DOS是这类系统的代表。 ∙多任务操作系统：基于分时技术的多任务操作系统。虽然在同一时间段，所有的进程都在运行，但是在某一时间点，CPU只执行一个进程。这类操作系统可分为抢占式和非抢占式。单CPU的Unix和NT属于这种类型。 ∙多CPU多任务操作系统：和单CPU的多任务操作系统不同的是，由于有多个CPU，所以在某个时间点上，可以有多个进程同时运行。多CPU的Unix和NT属于这种类型。 ∙多CPU多任务操作系统+线程：某些任务当把它分为若干并行的子任务同时在多个CPU上执行时，它会运行的更快，尽管运行这个任务占有的总CPU时间变长了。由于采用多个CPU而使任务结束的时间缩短了。由于应用本身的特性，随着CPU个数的增加，性能并不会线性增加。Amdal法则说明了这种情况。运行在同一主板上多个CPU的Unix和NT＋线程属于这一类型。SMP系统合适采用这种方法。 ∙多CPU多任务操作系统+消息传递：在SMP系统中，由于采用共享内存，所以CPU通信的时间几乎可以忽略。但是在象集群这种系统中，通信时间成为不得不考虑的因素。这时，使用线程是一种很奢侈的方法。这种情况下，消息传递是一种比较好的方法。(本系列文章的第二部分解释了这种情况)。同一个主板或多个主板上的多个CPU+Unix和NT+消息传递属于这种类型。 Beowulf集群使用第5种类型平台。它可以由SMP和PC服务器组成，以Linux为操作系统，以MPI或PVM这种消息传递方式作为通信方法。 文件系统是操作系统的重要组成部分，用于存储程序和数据。如何在各节点间高效、一致和简捷的实现数据共享是集群系统对文件系统提出的挑战。 3.1 集群和文件系统 很明显，那种仅能管理本地存储的文件系统(如EXT和FAT)是无法满足集群系统对文件共享的要求的。在集群环境下，最容易想到，也是最容易实现的文件系统就是分布式文件系统。相当于本地文件系统，分布式文件系统有如下优点： ∙网络透明：对远程和本地的文件访问可以通过相同的系统调用完成。 ∙位置透明：文件的全路径无需和文件存储的服务绑定，也就是说服务器的名称或地址并不是文件路径的一部分。 ∙位置：正是由于服务器的名称或地址并不是文件路径的一部分，所以文件存储的位置的改变并不会导致文件的路径改变。 分布式文件系统可以使集群的节点间简捷地实现共享。但是为了提供性能，分布式文件系统通常需要使用本地的缓存(Cache), 所以它很难保证数据在集群系统范围的一致性。而且往往分布式文件系统中只有一份数据，所以很容易发生单点失效。 建立在共享磁盘(Share-Disk)上的并行文件系统可以克服分布式文件系统的这些缺点。通过使用在节点共享的存储设备，并行文件系统具有很多优点： ∙高可用性：克服了分布式文件系统中那种服务器端的单点失效的缺点，提高了文件系统的可用性。 ∙负载均衡：有多个访问点，彼此可以协调负载。 ∙可扩展性：容易扩展容量和访问的带宽 3.2 集群中的数据共享形式 下面通过给出几个集群中使用具体的数据共享的方法。其中rsync是建立在本地文件系统之上，NFS和Inteemezzo属于分布式文件系统(确切的说，NFS只是网络文件系统)，GFS属于并行文件系统，而Backend-database则属于不同于文件共享的另一种形式的共享。 3.2.1 rsync rsync是一种简单的文件共享实现方式。集群中的每个节点都有一份数据复本，复本间使用rsync进行同步。因为节点需要的数据就在本地，所以这种方法具有很高的可用性，不会出现单点失效现象。 如果需要的共享的数据量很小，而且很少更新时，可以采用这种方式。静态网页和小的FTP站点的可以使用这种共享方式。 3.2.2 NFS 这也是一种容易实现的方式。存储节点通过NFS将自己本地的文件输出，其他节点则把存储节点输出的文件系统mount到本地文件系统。NFS方式的存在两个很大的缺点： ∙性能差：因为所有的文件访问都必须经过网络和NFS服务器，所以在访问流量比较大的情况下，网络带宽和NFS服务器都会成为系统的瓶颈。 ∙单点失效：如果NFS服务器的系统失效或者网络失效都会使得其他节点无法得到数据，从而使整个集群系统瘫痪。 当然使用多个互为备份的NFS服务器可以改善性能和避免单点失效，但是这样又会带来如何实时保持备份服务器间数据一致性的问题。 NFS方式适合于共享访问数据量不大的小型集群系统。 3.2.3 GFS GFS(Global File System)实现了存储设备的网络共享。这些存储设备可以是共享SCSI(Shared SCSI)和共享通道(Fibre Channel - FC)。GFS包装这些存储设备使得它们好像节点本地的文件系统。GFS的主要优点在于： ∙高可用性：如果一个GFS客户失效，数据还可以通过其他GFS客户访问。 ∙扩展性：因为不需要中心服务器，所有很容易扩展存储容量和访问带宽。 GFS可以将物理上分离的存储设备虚拟为一个存储而且能平衡访问负载。GFS还实现了文件锁和实时文件系统。 3.2.4 Intermezzo Intermezzo实现了一个分布式的文件系统。它采用客户/服务器模式。服务器拥有权威的数据，客户节点仅有本地缓冲的版本。它们通过普通的网络进行同步。Intermezzo支持断开连接下文件操作。在下次恢复连接时，它会集成本地的改动到服务器上。Intermezzo拥有象GFS一样的可用性和可扩展性。但是它无法保证数据的实时一致性。 3.2.5 Backend Database 基于后端数据库的共享是完全不同于文件共享的方式。后端数据库系统解决了数据的一致性、性能、可用性和可扩展性问题。但是数据库的访问方法要比文件访问复杂的多。 并行化应用程序，使其更高效的运行是使用Beowulf集群系统的最终目的。一般说，并行化应用程序分为三个步骤： ∙确定应用程序的并发部分 ∙估计并行的效率 ∙实现应用程序的并发 在并行化应用程序的过程中，需要开发环境、并行开发库和各种工具的支持。这些软件都是Beowulf集群软件体系结构中重要的组成部分。 4.1 确定应用程序的并发部分 从实用的角度说，应用程序有两种类型的并发：计算和I/O。尽管在多数情况下这两者是正交的，但是也存在一些应用同时需要这两种并发性。有一些工具可以用来帮助分析应用程序的并发，而且通常这些工具都是专门为Fortran设计的。 4.2 分析并行的效率 分析并行的效率是并行化应用程序中很重要的一个步骤。正确的分析并行的效率可以帮助你在有限的经费下最大化应用的执行效率。往往Beowulf集群的需要和应用的需要有些许的差别。比如，CPU消耗型的应用往往需要的是稍微快一点的CPU和高速低延迟的网络，而I/O消耗型的应用需要的是稍微慢一点的CPU和快速以太网。 如果没有分析工具，你只能使用猜测和估计的办法完成这一步骤。一般来说，如果在应用的一部分中，计算的时间是分钟级而数据传输的时间是秒级，那么这一部分可以并行执行。但是如果并行后计算时间降到秒级，你就需要实际测量一下再做权衡。 另外，对于I/O消耗型的应用，Eadline-Dedkov法则对你做决定有些帮助：如果两个并行系统具有相同的CPU指标，慢CPU和相应具有低速CPU间通信网络的系统反而具有较好的性能。 4.3 实现应用程序的并发 有两种方法去实现应用程序的并发：显式并发和隐式并发。 4.3.1 显式并行化 显式并行化是指由开发者决定程序的并行。开发者通过在程序中增加PVM或MPI消息，或者增加程序执行的线程从而达到程序的并行化。显式并行化通常难以实现和调试。为了简化显式并行化，某些开发库中增加了一些函数用于简化标准并行方法的实现。另外也有专门用于调试并行程序的工具。TotoalView(http://www.etnus.com/Products/TotalView/index.html)就是一个源码级的C、C++和Fortran调试工具。它拥有方便的图形化界面，可以用于调试多线程、多进程和集群应用程序。 4.3.2 隐式并行化 隐式并行化是由编译器来决定程序的并行性，高性能Fortran就是这类编译器。隐式并行化中，程序开发者向编译器提供一些程序并行的特征，编译器根据这些特征做出程序并行化的决定。通常编译器可以给并行应用提供一定程度的效率和移植性，但是不是最好的。 从用户角度看，集群系统就好像一台服务器或者PC。很多用户可以同时使用这个系统。但是当太多的用户使用集群系统时，系统性能会很差。资源管理就是管理用户提交的作业，合理给各个作业分配资源从而保证集群系统高效运行。作业管理通常由资源管理器和作业调度策略器组成。 从系统组成角度说，集群系统是由多台计算机组成的超级计算机。但是从最终用户看来，集群系统是一台计算机，也就是说，集群系统的构成对用户是透明的。所以集群系统的管理的目的就是让集群系统象一台计算机一样利于管理。归纳起来，集群系统管理一般完成如下任务： ∙资源管理 ∙事件管理 ∙配置管理 ∙监控和诊断 ∙硬件控制 ∙系统安装 ∙域管理 窗体顶端 窗体底端 金戈 (jinge@cn.ibm.com), IBM软件工程师, IBM 2002 年 11 月 28 日 本文是Linux高性能集群系列文章的第五部分。这一部分首先介绍集群系统中的资源管理主要任务和系统管理主要任务，然后列举并比较了几种常用的资源管理软件和系统管理软件。 1 集群作业管理 从用户角度看，集群系统就好像一台服务器或者PC。很多用户可以同时使用这个系统。但是当太多的用户使用集群系统时，系统性能会变得很差。资源管理就是管理用户提交的作业，合理给各个作业分配资源从而确保充分利用集群系统计算能力并尽可能快的得到运算结果。简单的说，集群资源由实现如下几个部分： ∙资源管理器：为了确保分配给作业合适的资源，集群资源管理需要维护一个数据库。这个数据库记录了集群系统中各种资源的属性和状态、所有用户提交的请求和正在运行的作业。策略管理器根据这些数据和指定的调度策略生成优先级列表。资源管理器根据这个优先级列表调度作业。资源管理器还应该具有资源预留能力。这样不仅可以保留强大的资源给需要的作业，而且可以预留一定的冗余资源以应付集群中的结点失效和突发的计算。 ∙作业调度策略管理器：策略管理器根据资源管理器得到各个结点上的资源状况和系统的作业信息生成一个优先级列表。这个列表告诉资源管理器何时在哪些结点上运行哪个作业。策略管理器不仅要提供一个复杂的参数集合去定义计算环境和作业，而且要为这个定义提供简捷灵活的表达方式以允许系统管理员实现策略驱动的资源调度。 有很多种选择去管理集群系统中的资源。其中PBS资源管理器和Maui作业调度器最适合集群系统。 2.1 PBS PBS(Portable Batch System)是由NASA开发的灵活的批处理系统。它被用于集群系统、超级计算机和大规模并行系统。PBS主要有如下特征： ∙易用性：为所有的资源提供统一的接口，易于配置以满足不同系统的需求，灵活的作业调度器允许不同系统采用自己的调度策略。 ∙移植性：符合POSIX 1003.2标准，可以用于shell和批处理等各种环境。 ∙适配性：可以适配与各种管理策略，并提供可扩展的认证和安全模型。支持广域网上的负载的动态分发和建立在多个物理位置不同的实体上的虚拟组织。 ∙灵活性：支持交互和批处理作业。 OpenPBS( http://www.OpenPBS.org/)是PBS的Open Source的实现。商业版本的PBS可以参照： http://www.pbspro.com/。 2.2 Maui Maui是一个高级的作业调度器。它采用积极的调度策略优化资源的利用和减少作业的响应时间。Maui的资源和负载管理允许高级的参数配置：作业优先级(Job Priority)、调度和分配(Scheduling and Allocation)、公平性和公平共享(Fairness and Fairshare)和预留策略(Reservation Policy)。Maui的QoS机制允许资源和服务的直接传递、策略解除(Policy Exemption)和指定特征的受限访问。Maui采用高级的资源预留架构可以保证精确控制资源何时、何地、被谁、怎样使用。Maui的预留架构完全支持非入侵式的元调度。 Maui的设计得益于世界最大的高性能计算中心的经验。Maui本身也提供测试工具和模拟器用于估计和调节系统性能。 Maui需要资源管理器与其配合使用。我们可以把Maui想象为PBS中的一个插入部件。 更多Maui的信息可以访问： http://www.supercluster.org 从系统组成角度说，集群系统是由多台计算机组成的超级计算机。但是从最终用户看来，集群系统是一台计算机，也就是说，集群系统的构成对用户是透明的。所以集群系统的管理的目的就是让集群系统象一台计算机一样利于管理。归纳起来，集群系统管理一般完成如下任务： 3.1 资源管理 简单地说，资源管理就是分配系统的资源和监控系统资源的使用状态。这里的资源是个很广泛的概念，各种硬件设备、数据和程序都可以看成资源：如CPU、存储、网卡，甚至系统的事件和log。 3.2 事件服务 事件(Event)就是系统的状态的一次变化。如"CPU的利用率超过90%"就可以理解为一次事件。简单的说，事件服务就是事件通知服务，也就是当一次事件发生时，通知对这类事件感兴趣的个体这个事件发生了。事件服务可以分为Push(也称为Subscribe-Publish)和Pull方式。系统管理员还应该能够通过事件服务设置系统对事件的自动响应。 3.3 分布式命令和文件 分布式命令和文件是指让命令和文件操作同时在整个集群结点或指定的一组结点上并行执行。 分布式命令功能通常通过分布式的Shell来提供。这种Shell一般叫做dsh(distributed shell)或 psh ( parallel shell)。你可以通过rsh或ssh来实现分布式Shell。 分布式文件主要用于指集群中配置文件的同步。集群系统实际上是由多个结点组成，所以对集群系统的一个配置需要发布到每个结点(或一组结点)。比如，需要配置每个结点上的Apache都支持CGI，就需要把/etc/httpd下的配置文件发布到每个结点的/etc/httpd中。简单地说，集群系统地配置管理就是把一个或多个配置文件发布到指定的结点上。有很多开放源码的工具可以帮助完成集群系统的分布式文件功能，如rdist和cfengine。 3.4 监控和诊断 对持续运行的集群系统而言，当系统正常运行时，你需要一些工具监控系统各部分的运行状态，如系统进程、CPU利用率和内存利用率等。在普通的Unix系统上，你可以简单的用ps和top实现这些功能。但是在集群系统中，你确实需要一些特殊工具，而且最好系统的监控可以支持多种网络管理协议，如SNMP和WBEM。当集群系统工作不正常时，你则需要另外一些工具来协助系统诊断。如当系统某个不服务时，你可能需要用ping诊断是不是网络出了问题。而当时多个结点服务时，你则需要并发的ping来诊断是不是网络错误。 3.5 硬件控制 PC机上很简单的管理功能对于集群系统而言可能会很难做到。比如让一组结点重启，就很难手工完成。所以集群系统需要一些特殊的硬件设备完成这些功能。下面是几个需要硬件支持特殊管理功能： ∙远程电源管理：主要是远程关闭、打开和重启结点与查询结点电源状态。在IBM eServer Cluster 1300中采用ASM。 ∙远程控制台：当远程结点出现问题或出现一些特殊的软件需要时，需要直接登录到结点上完成操作。KVM Switch可以满足这种需求，但是当结点很多时，KVM Switch就会很复杂。而且KVM Switch需要手工切换，不能通过软件方法使用。Terminal Server克服了KVM Switch的缺点。Terminal Server与结点的串口相连，并把串口虚拟成管理结点上终端设备，当然这需要对结点的操作系统做些相应的配置。 3.6 系统安装 集群系统的安装主要是指在各个结点上安装操作系统、文件系统、并行程序运行库、作业管理软件和系统管理软件等。它是集群系统投入应用的前提，所以集群系统的安装是一件非常重要的任务。一般集群系统由几十台，甚至上百上千台计算机组成，显然手工安装系统几乎是不可能的。一般集群系统的安装的机制是： 1.网络启动：设置需要的安装的结点网络启动，然后管理结点远程重启需要安装的结点。网络启动的结点启动后从启动服务器获得一个小的操作系统内核。网络启动一般采用Intel的PXE(Pre-Execution Environment)标准。 PXELinux是支持PXE的网络启动服务器。它可以在网络启动的结点启动一个小的Linux核心并运行指定的Init程序。由Init程序负责后续的安装。 2.网络安装：这个操作系统内核负责从安装服务器(通常是一个文件服务器)上取得安装软件包或系统镜像并在本地实施系统安装。有多种Linux工具可以完成基于网络的系统安装。这些工具中的典型代表是：KickStart、ALICE (Automatic Linux Installation and Configuration Environment)、SIS(System Install Suite)和PartImage。这些工具可以分为如下几类： 1.a. 基于Script的安装：这种安装方式中，安装过程由安装脚本(Script)控制，可以通过修改安装脚本来配置安装过程。这种安装方式中，安装服务器实际上是一个文件服务器，它向结点提供要安装的软件包。除了软件包不是来自本地外，这种安装方法和本地安装并没有太大的区别，本地安装的各个步骤(配置硬件、安装软件包、配置系统等)它都要经过。KickStart属于这中安装方法。基于Script的安装比较灵活，但是它是操作系统依赖型的。象KickStart只支持Redhat Linux。 2.b. 基于Imaging的安装：和基于Script的安装不同，基于Imaging的安装并不需要经过本地安装的各个步骤。它只需要把存储在文件服务上的需要安装的系统映象(Image)拷贝到本地的硬盘上。这个系统映象来源于一个已经安装和配置好的样机。Imaging的安装方式是于操作系统，但是它依赖于网络启动的操作系统内核支持的文件系统。Imaging的很大缺点是很难提供于操作系统的配置方法。PartImage属于Imaging安装方法。而SIS是Script和Imaging混合型的安装方式。SIS利用Linux的chroot命令在安装服务器的一个文件目录下安装一个虚拟的操作系统映象。同时SIS支持用户提供Shell脚本完成安装后的配置。 3.c. 基于Cloning的安装：和Imaging安装方式相同的是，Cloning安装也采用系统映象。但是Cloning中的系统映象是样机上硬盘分区的Clone。因此，Cloning安装不需要识别系统镜像中的文件系统类型。所以它是于文件系统的，它只依赖于操作系统内核支持的硬盘设备类型(IDE或SCSI)。和Imaging一样，Cloning的很大缺点是很难提供于操作系统的配置方法。而且相对于Imaging而言，Cloning效率更低。你可以简单的用dd命令实现Clone。 下表归纳了几种安装工具的特点： SuSE Linux Turbo Linux … 你可以简单的把集群系统的域管理理解为结点管理，它主要包括如下简单的功能： ∙加入、删除和列举集群系统中的结点 ∙对集群中的结点分组 实际上，我们也把作业管理纳入集群系统管理的任务。但是相对于其他系统管理任务而言，作业管理在集群系统中具有更重要的作用，而且通常的集群系统管理软件也不直接实现作业管理功能。所以我们把作业管理作为集群系统一个重要的软件部分，而不是集群系统管理的一项任务。 集群系统管理软件和集群系统一样形形色色、多种多样。下面简要介绍几种集群系统管理软件并比较它们实现的功能。 4.1 IBM CSM IBM CSM(Cluster Systems Management )是IBM eServer Cluster 1300上的系统管理软件。IBM的Linux集群战略的一部分就是把运行在RS/6000 SP平台上的PSSP软件移植到基于xSeries的Linux集群系统上。CSM大部分功能来源于SP平台，但是它也集成了WebSM 2000、xSeries、开放源码工具和其他技术。CSM是一款功能很全面的管理工具，而且还在不断的发展中。 4.2 XCAT XCAT是用于IBM eServer Cluster 1300上的系统管理软件。它由Egan Ford开发。它基本上是由shell脚本写成，相当简捷。但是它实现了集群系统管理大部分的内容，是个非常出色的管理软件。 4.3 Mon Mon在Linux平台上开发，但是也以运行在Solaris上而出名。Mon的服务器和客户都是基于perl开发的，所以很容易移植到其他UNIX和类UNIX平台。 下表比较了以上三种集群系统管理软件： ∙Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/ ∙IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/ ∙Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/ ∙Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK ∙Beowulf HOW-TO, http://www.beowulf-underground.org ∙Beowulf Introduction and Overview, http://www.beowulf.org ∙The Mosix Howto, http://www.mosix.org ∙Linux-HA Heartbeat System Design, http://www.linux-ha.org ∙xCAT HOW-TO, http://www.x-CAT.org ∙MPICH, http://www.mcs.anl.gov/mpi/mpich. ∙PVM, http://www.epm.ornl.gov/pvm/pvm_home.html ∙OpenPBS， http://www.openpbs.org/ ∙Maui, http://www.supercluster.org/ ∙Condor Manual, Condor Team, University of Wisconsin-Madison ∙Intermezzo, http://inter-mezzo.org/ ∙Coda, http://www.coda.cs.cmu.edu/ 关于作者 窗体顶端 窗体底端 于策 (lakers.yu@eyou.com), 天津大学计算系硕士研究生 2003 年 7 月 09 日 本文首先对Linux高性能集群Cluster1350及其集群管理系统CSM (Cluster System Management)进行了简要的介绍，然后对CSM的体系结构进行了比较详细的剖析。 一、集群 一般来说，集群是指一组高性能计算机通过高速网络连接起来的，在工作中像一个统一的资源，所有节点使用单一界面的计算系统。集群技术的出现，使得使用多台PC或工作站就可获得同大型机相匹敌的计算能力，同时成本大大降低，从而在很多高性能计算领域内由集群完全取代大型机也将成为可能。 广义上的集群的节点可以是任意类型的计算机，包括PC机、工作站、SMP等等，甚至是大型机。Linux集群是指一类以PC架构计算机为集群节点，以某一版本Linux操作系统为集群节点操作系统的集群。由于Linux本身具有开放源码、稳定、支持PC架构等诸多优势，以及操作系统及节点机价格的因素，Linux集群技术被认为是最具发展潜力的集群技术。 根据典型的集群体系结构，集群中涉及到的关键技术可以归属于四个层次：网络层、节点机及操作系统层、集群系统管理层、应用层。 ∙网络层：网络互联结构、通信协议、信号技术等。 ∙节点机及操作系统层：高性能PC或工作站、分层或基于微内核的操作系统等。 ∙集群系统管理层：资源管理、资源调度、负载平衡、并行I/O、安全等。 ∙应用层：并行程序开发环境、串行应用、并行应用等。 集群技术是以上四个层次的技术有机结合，所有的相关技术虽然解决的问题不同，但都有其不可或缺的重要性。集群系统管理层是集群系统所特有的功能与技术的体现。在未来按需(On Demand)计算的时代，每个集群都应成为业务网格中的一个节点，所以自治性(自我保护、自我配置、自我优化、自我治疗)也将成为集群的一个重要特征。自治性的实现，各种应用的开发与运行，大部分直接依赖于集群的系统管理层，并且，系统管理层的完善程度，决定着集群系统的易用性、稳定性、可扩展性等诸多关键参数。正是集群管理系统将多台机器组织起来，使之可以被称为"集群"。 Cluster1350是IBM公司目标定位于高性能计算市场的Linux集群，包括一套完整的解决方案，集成了众多IBM与非IBM的先进的软硬件技术，有其特有的技术优势与强大的服务支持。Cluster1350集群的体系结构如下图所示： Cluster1350体系结构 ∙High Speed Network Cluster1350的计算网络可选Myrinet超高速网络或者千兆以太网，以及相应的通信协议，用于并行计算时各节点间数据交换。 ∙Manage Node Cluster1350的管理节点为xSeries345 (2U)，操作系统为Linux，目前支持RedHat 7.2与7.3，RedHat AS2.1，以及SuSe 8.0和8.1，SuSe SLES7.2和8.0。自带两个10M/100M/1000M自适应网卡，支持RAID，有RSA适配器接口(PCI插槽)。 ∙Compute Node Cluster1350的计算节点为xSeries335 (1U)，操作系统为Linux，目前支持RedHat 7.3，RedHat AS2.1，以及SuSe 8.0和8.1，SuSe SLES7.2和8.0。自带两个10M/100M/1000M自适应网卡，有RSA适配器接口(PCI插槽)。 ∙RSA (Remote Supervisor Adapter) RSA适配器节点机主板上的ISMP以及C2T Chain等其它相关硬件配合工作，用于实现对集群中各节点的电源管理、机器硬件状态监测、日志报告等管理功能，是Cluster1350中硬件控制的接入点。一个Cluster1350集群中可以有多个RSA配置器，每一个RSA适配器最多可控制24个节点。 ∙Terminal Server 各节点通过串口连接到Terminal Server，通过Terminal Server，管理员在管理节点上可以获得任意受控节点的控制台，而不管该节点在普通网络(Management Network)上是否可达。一个Cluster1350集群根据规模不同，可以有一个或多个Terminal Server。在节点比较少时，也可以不用Terminal Server，而用KVM交换机以及xSeries335前面板上的控制按钮配合来实现控制台切换，不过后一种方式当节点数目增多时连接及操作复杂度会越来越高。 ∙Management Network Cluser1350的集群管理网络由各节点上的ISMP (Integrated Systems Management processor)、C2T Chain (Cable Chain Technology)、RSA适配器、Terminal Server、Management Switch/VLAN构成。其中ISMP内置于安节点主板，由C2T Chain级联，然后通过RSA适配器用网线连接到管理网络；各节点用串口线连接到Terminal Server，Terminal Server也通过网线连接到管理网络。这样，管理节点通过管理网络可以便捷地实现对集群所有节点的控制。 ∙Cluster Network Cluster Network可以是普通的网络，主要用于集群系统管理软件对集群的管理，比如监控节点状态、网络安装各节点操作系统、更新各节点配置文件及软件等。Cluster Network一般不用于并行计算时各节点间数据交换。 ∙Cluster System Management Layer IBM公司为Cluster1350提供功能完备的基于SRC (System Resource Controller)和RSCT (IBM Reliable Scalable Cluster Technology)的CSM (Cluster System management)，GPFS (General Parallel File System)等集群管理软件，可以便捷地完成基本的集群系统管理工作。还可以再选择安装其他用于Linux集群的管理调度软件以实现负载平衡、任务调度等功能。 ∙Application Layer 科学计算、商务服务、信息服务等各种需要大规模计算或高可靠性服务的应用都可以在Cluster1350上运行。Cluster1350不是面向任何特定的应用的设计，应用层根据用户的需要而不同。 此外，根据需要Cluster1350还可以配置专门的存贮节点，通常是xSeries345。 Cluster1350由各节点主板内置硬件和RSA 适配器、C2T Chain级联技术等与CSM等集群系统管理软件相配合，实现了可靠、强大、易用、可扩展的系统管理功能。 ∙整个集群可由单一节点控制。包括所有节点的开机、关机、状态查询、显示远程控制台、安装操作系统、升级各节点系统及应用软件等所有工作在内，都可以在管理节点上完成。一个集群只需一套外置输入/输出设备(键盘、鼠标、显示器)。 ∙可以使管理人员方便地完成集群的部署。xSeries335和xSeries345为集群系统量身定做，安装，连接都很简单。整个集群管理结构只需少量线缆相连。安装配置好集群管理节点的操作系统及CSM后，管理员可以同时进行所有计算节点的安装及配置，而这一过程只需几条命令即可完成。 ∙方便的使用期管理。在CSM的支持下，管理员只需登录到管理节点，便可完成在所有指定计算节点上同时安装/缷载rpm软件、升级CSM客户端、更新配置文件、执行同一shell命令(脚本)等操作，可以对集群节点的进行动态/静态分组管理，删除或新增节点。 ∙有效地监控各节点的资源状况。CSM的后台进行时刻监控所有指定资源的状态，并且及时响应给相应的处理程序或集群管理员，而并不需要很大的带宽。 ∙可以及时检测到系统错误，准确定位错误，并自动解决或记录日志以帮助管理员手工处理错误。 对于普通Linux集群来说，以上这些管理工作在没有专用集群管理系统的情况下工作量是随着集群规模的扩大而急速增长的，有时还会导致硬件资源的浪费。而Cluster1350彻底地解决了这个问题，使管理集群变得像管理一台计算机一样简单方便，使用户可以将主要精力用于应用方案的设计与开发，而不用在这些繁琐的集群管理工作上投入过多不必要的时间。 CSM是IBM公司开发，专门用于集群系统管理的中间件，在Cluster1350解决方案集成。CSM的设计思想与体系结构来自PSSP (IBM Parallel System Support Programs for AIX)与其它一些开源的集群管理软件。还有一些中间件及技术，虽然不直接为用户服务，但构成了CSM的不可或缺的基础，包括RMC、SRC、RSCT等。 CSM的体系结构如下图所示。 CSM体系结构 (引用自Linux Clustering with CSM and GPFS, IBM Redbook) 其中CSM Server只安装运行于管理节点，CSM Client安装运行于所有受控节点。CSM体系结构中各模块功能详细说明如下： ∙Database and Distributed Management Server (DMS) 管理节点上的CSM系统数据库，用来存贮整个集群的配置信息。比如所有节点的参数，分组等。集群中的每一个计算节点都要注册到此数据库，才能通过CSM由管理节点控制。而CSM的大部分管理命令，都需要从此数据库中读取相关配置信息。 ∙l Managed Node 集群中正常连接并且已经正确安装配置好操作系统及CSM的节点。安装工作正确完成后CSM数据库中对应的节点属性会自动改为Managed，说明该节点已经由管理节点所控制。 ∙Node Group 对CSM系统受控节点的分组管理。默认的几个分组的判断条件是操作系统类型、版本，CSM版本，电源管理方式等。具体管理中可以实现自定义的分组。分组的定义方式类似于SQL中视图的定义，支持多条件及模糊条件，支持分组嵌套。另外CSM节点管理支持动态和静态分组。 ∙Distributed Shell (dsh) 使用dsh可以同时在集群中指定的一个或者多个节点上同时执行同一shell命令。比如 dsh -a date。 ∙Hardware control 硬件控制功能依赖于xSeries335, xSseries345节点机以及RSA卡的支持，以实现对集群节点的一些基本操作，如开机、关机、关闭系统、重新启动等。此功能与节点是否安装操作系统无关，因为这些指令直接由节点机主板上专门的服务处理器执行，只要节点电源正常，便会响应。 ∙Hardware Control Point 这里"硬件控制点"指的是RSA卡。 ∙rpower rpower是CSM的一个重要的管理命令，用来控制节点的开机、关机、重新起动、状态查询等。一个典型的查询命令是这样的：rpower -n node01 query，表示查询名为node01的节点当前状态，正常结果on或off。 ∙Configuration File Management (CFM) CFM的主要功能是保持所有节点配置文件同步更新。比如管理员要修改所有节点/etc目录下某个配置文件，他只需在管理节点编辑好一个同名文件，放在特定目录下，然后执行一个简单的命令CFM就可以将配置文件更新到所有指定的节点。CFM也可用于普通文件的管理，其过程和管理配置文件相同。 ∙rdist rdist是CFM的一个内部命令，完成更新指定节点指定文件的功能。 ∙Remote Console 借助MRV In-Reach Terminal Server 或者Equinox Serial Provider (ESP)，可以在管理节点上切换至任意一个在CSM数据库中定义的节点的控制台，而与其是否已经安装操作系统无关。 ∙Event Response Resource Manager (ERRM) CSM的ERRM模块可以响应已定义的事件，执行命令或脚本。一些重要的事件已经由CSM预先定义，用户也可以根据需要定制新的事件。ERRM可以监控的资源包括文件系统、节点可达性、程序运行状况等。 ∙Sensors Sensors是用户自己编写的脚本，以获得系统的某个特定参数，并将其发送给ERRM，再由ERRM做出响应。 ∙Install (kickstart, NIM, SIS) 此功能模块使得集群在安装配置好管理节点后可以同时安装所有计算节点的操作系统及CSM。kickstart安装方式只支持RedHat Linux，SIS方式支持的Linux类型比较多，如RedHat, SuSe等。 ∙Logging 利用CSM日志记录，可以方便地定位错误，帮助分析系统状态。 ∙RMC Daemon (Resource Monitoring and Controlling) RMC Daemon后台进程运行于集群的所有节点，监控资源状态，发送、接收、执行CSM命令。CSM中所有的管理功能，除了基本的硬件控制之外，全部都需要RMC Daemon的支持。 Linux集群技术近年来有了令人瞩目的发展，越来越多的服务商和研究人员致力于Linux集群各方面技术的研究，出现了各种各样的Linux集群系统解决方案。Cluster1350是其中一个优秀的方案，它融合了一些已经很成熟的UNIX集群的思想与技术，也不排斥当前可用于Linux集群的开源软件，并且诸多技术可以适应未来的随需应变的电子商务时代及实现集群的自主计算。Cluster1350将成为集群相关的商务应用和网格计算、高性能计算、高可用计算等技术研究的重要基础。 关于作者
检查应用（资源）是否能够在节点失效后被转移到其他节点： SN# K106086T2N1> power cycle
Failback 的过程 }
恢复监控进程的执行权限： system("ping -c 1 system("sudo chmod 755 watchdog > /dev/null 2> /dev/null");
检查产品需要的其它进程是否恢复运行： ps – ef|grep watchdog
检查应用（资源）是否能再迁移回原先运行的节点： }
若返回值不为空，说明被转移走的 cNFS IP 在该节点被修复好了又迁移回来了。 mmgetifconf | grep 文档选项
级别： 初级打印本页 将此页作为电子邮件发送
2 高可用集群回页首
业界根据可用性把计算机系统分为如下几类：MTTF/(MTTF+MTTR)*100%
对于关键业务，停机通常是灾难性的。因为停机带来的损失也是巨大的。下面的统计数字列举了不同类型企业应用系统停机所带来的损失。可用比例 年停机时间 可用性分类 99.5 3.7天 常规系统(Conventional) 99.9 8.8小时 可用系统(Available) 99.99 52.6分钟 高可用系统(Highly Available) 99.999 5.3分钟 Fault Resilient 99.9999 32秒 Fault Tolerant
随着企业越来越依赖于信息技术，由于系统停机而带来的损失也越拉越大。应用系统 每分钟损失(美元) 呼叫中心(Call Center) 27000 企业资源计划(ERP)系统 13000 供应链管理(SCM)系统 11000 电子商务(eCommerce)系统 10000 客户服务(Customer Service Center)系统 27000
3 高性能计算集群回页首
Linux高性能集群 - 硬件和网络体系结构实际上把Mosix集群放在高性能集群这一节是相当牵强的，但是和Beowulf等其他集群相比， Mosix集群确实是种非常特别的集群， 它致力于在Linux系统上实现集群系统的单一系统映象SSI(Single System Image)。Mosix集群将网络上运行Linux的计算机连接成一个集群系统。系统自动均衡节点间的负载。因为Mosix是在Linux系统内核中实现的集群，所以用户态的应用程序不需要任何修改就可以在Mosix集群上运行。通常用户很少会注意到Linux和Mosix的差别。对于他来说，Mosix集群就是运行Linux的一台PC。尽管现在存在着不少的问题，Mosix始终是引人注目的集群系统。 文档选项
级别： 初级打印本页 将此页作为电子邮件发送
2 Beowulf集群中的节点回页首
3 Beowulf集群的网络结构回页首
4 附录：一个Cluster 1300集群系统的配置清单回页首
Linux高性能集群 - 软件体系结构1 13020 Summit24 -Full Layer 3-X 文档选项
级别： 初级打印本页 将此页作为电子邮件发送
2 操作系统回页首
3 文件系统回页首
4 并行化应用程序回页首
5 作业管理（资源管理）回页首
6 系统管理回页首
Linux高性能集群 - 资源管理和系统管理本系列文章的第五部分将详细介绍集群系统的作业管理和系统管理。 文档选项
级别： 初级打印本页 将此页作为电子邮件发送
2 Beowulf集群中的作业管理软件回页首
3 集群系统管理回页首
3.7 域管理安装工具 安装方法 支持的系统 支持的网络协议 KickStart Script Redhat Linux NFS、FTP SIS Script和Imaging混合 Redhat Linux rsync PartImage Imaging EXT2、FAT、NTFS、HPFS… 私有协议
4 几种集群系统管理软件回页首
参考资料 项目 CSM XCAT Mon 支持的集群系统 IBM eServer Cluster 1300 IBM eServer Cluster 1300 不特定于某个集群系统 支持的操作系统 Redhat、SuSE Redhat，结点可以采用Imaging和Cloning安装其他操作系统，甚至于Windows 在Linux上开发，但是以运行在Solaris而著名。很容易移植到其他Unix和非Unix操作系统上 资源管理 提供统一的、可扩展的，全面的资源管理，但是由于强大而使用起来很复杂。 基本没有 基本没有 事件服务 提供事件订阅发布机制，并预先定义了很多系统事件和对事件的响应 将来会于Mon集成以完成事件服务 支持 配置管理 支持 无 无 监控和诊断 支持分布式Shell(dsh)、支持SNMP 支持并发Shell(psh)、并发ping(pping) 支持SNMP 硬件控制 远程电源管理(rpower)远程控制台(rconsole) 远程电源管理(rpower) 远程控制台(rcon、wcon) 无 系统安装 支持KickStart和SIS 支持PXE 支持KickStart、Imaging和Cloning 支持PXE和etherboot 无 域管理 全面 基本没有 基本没有 集成性 除了必须的开放源码软件包，不与任何其他软件集成。但是底层资源管理和事件服务提供编程接口，集成很方便。上层可以通过命令调用集成。 自动安装PBS、Maui、Myrinet和MPI。将来会支持 SgridEngine Scheduler 基本没有，应该可以通过命令行集成 易用性 提供强大命令行工具和简单的GUI工具 命令行工具，将来会和Ganglia集成提供一定的GUI 提供命令行和基于Web的工具
IBM Cluster 1350与CSM金戈，IBM软件工程师，在IBM中国开发中心主持Linux集群系统开发工作。你可以通过 jinge@cn.ibm.com和他联系。 文档选项
级别： 初级打印本页 将此页作为电子邮件发送
二、集群系统管理回页首
三、IBM Cluster1350，Linux高性能集群回页首
四、CSM (Cluster System Management)回页首
五、小结回页首 于策，天津大学计算系硕士研究生，研究方向为集群技术及网格技术，E-mail： lakers.yu@eyou.com，Tel: +86-22-27404544
Copyright © 2019-2025 51dongshi.net 版权所有
违法及侵权请联系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
