基于Linux的集群系统(二)关键技术分析

 进程的放置和迁移

进程的放置

在集群系统中，进程的到达时间和新到达进程所需的资源量都是不可预测的，因此进程的放置和迁移是非常重要的问题。由于集群系统中的不可预测性，进程有时就会被放置在不合适的机器上，进程迁移就给了系统一个弥补这样的错误的机会。通过较好的算法将新创建的进程放置到合适的节点上执行，并且对某些进程进行迁移可以缩短任务的平均执行时间，因此从整体上提高了系统的性能。

进程的放置问题是非常复杂的，因为集群中的资源是异构的，如：内存、CPU、进程间通讯等等。衡量这些资源耗费的方法也是不同的：内存的单位是字节，CPU的单位是循环、通讯资源的单位是带宽。

进程的放置策略分为静态放置策略和动态放置策略。静态放置策略通过预先定义的规则对新创建的进程进行分配，它不使用运行时的信息。而动态放置策略则根据系统状态的变化将进程重新放置到最适宜的节点上。

常见的静态放置策略由三种：Round Robin（RR）、Best-Fit(BF)、RoundRobin Next-Fit (NF)。

RoundRobin将新创建的进程以轮转的形式放置到集群中的各节点上。这种方法的缺陷在于如果新创建的进程所需的内存量大于将要分配到其上的节点的可用内存大小，则会导致算法的失败。

一种改进的方法是使用Best-Fit方法，进程将被放置到具有最大可用内存的节点上。

Round Robin Next-fit以RoundRobin的方式扫描各节点，并且将进程发送到第一个有足够大内存的节点上。它的缺点就是可能会导致负载不均衡地分配到各个节点。

三种进程放置策略的性能如图1-1所示。（进程的平均大小是16MB）

从该图可以看出，NF算法能够最充分地利用内存资源。当集群中的节点数增加时，BF算法和RR的算法的性能也随之有明显的下降，之所以产生这种情况是因为当节点数增加时，集群中的内存总量也随之成比例地增加，而且新增加的节点也会创建新的进程，这也就意味着大进程的数量也会随之增多，这些大进程对于BF算法和RR算法而言是很难放置的，因此会导致它们的性能的下降。

一种动态的进程放置策略叫做MS（Migrate the Smallestprocess），它以RoundRobin的形式扫描所有的节点，并且将新进程放置到下一个节点上。与RoundRobin不同的是，如果要放置的节点的内存不足以提供给新来的进程使用，则MS算法将迁移走一个进程。将要被迁移的进程是该节点上所有进程中最小的一个但是迁移走它刚好能满足新进程所需内存，而且也有其它的节点能够容纳这个将被迁移的节点，这种方法有较小的网络开销，如果不存在这样的节点，如其它的所有节点都没有足够大的内存空间，则算法失败。MS算法和NF算法的比较如下图所示。当进程的平均大小为1M时，两种算法都取得了将近100%的内存利用率，但是如图1-2所示当进程的平均大小为16M时，MS算法比NF 算法高了20多个百分点。

以上各种算法都是集中式的进程放置策略，都需要使用全局信息来决定放置策略，不利于可扩展性，不能有效地在拥有多个节点的集群上执行。一种基于MS的分布式进程放置算法(WindowedMS)是这样实现的：它将迁移的进程放置到从信息窗口中选出的具有最大可用内存的节点上。所谓信息窗口指的是一个缓冲区，里面保存着其它节点的可用内存的信息。每隔一定的时间就会将其它各节点的内存信息收集到信息窗口中，并对信息窗口进行更新。

图1-1 进程放置策略性能比较图 图1-2 进程放置策略性能比较图



回页首

进程的迁移

早在20世纪80年代，人们就开始了进程迁移的研究。大多数的研究主要着眼于如何用更好的方法在机器之间传送进程的状态。同构的进程迁移指的是进程迁移的原始和目标机器的体系结构相同，而异构的进程迁移指的是不同体系结构的机器之间的进程迁移。同构的进程迁移系统的例子有：VCharllote 、DEMOS/MP、 Sprite、 Condor、 Accent；异构的进程迁移系统有：Tui、Emerald、HMF(Heterogeneous MigrationFacility )等。进程迁移主要用于以下几种情况下。

1. 当失效的机器修复了错误，重新进入集群系统时，需要将某些该机器上原来运行的进程重新迁移回来。
2. 在集群系统中进行负载共享。为了让一个进程使用尽可能多的CPU时间，需要将它迁移到能提供大部分指令和I/O操作的机器上执行。但是有时候负载共享也有缺陷，因为大部分的进程只需一少部分的CPU时间，考虑到进程迁移的开销，如果对那些简单的可以在本地运行的进程进行迁移是得不偿失的，但是对于那些需要大量的处理时间的程序如仿真程序，迁移进程是非常有效的。
3. 提高通讯性能。如果一个进程需要与其它进程频繁地进行通讯，这时将这些进程放置得近一些就会减少通讯的开销。具体的迁移方法就是将一个进程迁移到其它进程所在的CPU上。
4. 可用性。当网络上的某台机器失效时，通过进程迁移可以将进程迁移到其它机器上继续执行，这样就保证了系统在遇到灾难时的可用性。
5. 重新配置。当对集群进行管理时，有时需要将服务从一个节点移到另一个节点，透明的进程迁移可以在不停机的情况下迁移服务。
6. 使用集群中的某些机器的特殊能力。如果某个进程能够从集群中的某台特定机器上受益，它就应该在那台机器上执行。如进行数值计算的程序能够通过使用数学协处理器或超级计算机中的多个处理器来大大缩短程序执行时间。

尽管进程迁移已经在实验环境中成功地实现了，但是它还没有被广泛地接受。一个原因是占主流的平台如MSDOS、MicrosoftWindows以及许多种类的UNIX操作系统都没有对进程迁移的支持。另一个原因是因为进程迁移开销可能比不迁移进程时的开销还要大。但是当前，两种新的计算领域又促进了进程迁移的发展，一个是移动计算，另一个是广域计算。移动计算指的是那些便携式的小型计算机的计算问题。而广域计算是指广域网中的机器的计算问题。

进程迁移将一个正在执行的进程从一个节点迁移到通过网络连接的另一个节点上（也就是说，不使用本地共享内存机制）。进程所在的原始节点上的操作系统应该将进程的所有状态都包装起来，这样目的机就可以继续执行此进程。

要完成进程迁移需要迁移进程的状态，尤其是进程的地址空间，对其它进程的访问（如套接口、管道等），代码（可以组成地址空间的一部分）以及执行状态（寄存器、堆栈等）。除了这些，还需要将那些对原始的进程所有访问都重新链接到新的进程拷贝上，不然迁移就不是无缝的，就会导致错误。整个进程迁移操作必须是原子操作，这样才能避免进程的丢失或者是有两个拷贝。

为了进行进程迁移需要再进行以下的修改：

1. 必须对文件系统进行一定的修改使每个机器看到相同的名字空间。
2. 必须传送足够的状态从而确保正常的核心调用能够在远端机器上正常执行。
3. 一些特殊的核心系统调用如gettimeofday、getpgrp应该发回到原始节点执行。

下面通过一个异构进程迁移的例子来说明进程迁移的整个过程。图1-3说明了进程是如何在Tui进程迁移系统中从一个机器上迁移到另一个机器上的。

1. 首先是对一个程序进行编译，针对Tui支持的四种体系结构，将程序分别编译四次。
2. 程序在原始机上以普通方式执行。（如命令行方式）
3. 当选定一个迁移的进程时，migrout程序首先为进程设置检查点，然后挂起进程，然后进行内存映像，接着扫描全局变量、堆栈和堆来定位所有的数据。再把所有的这些都转化为一种中介的格式传送给目标机。最后，杀死原始机器上的进程。
4. 在目标机上，migrin程序取得中介值并创建新的进程，由于程序已经根据目标机的体系结构进行了编译，因此正文段的信息和数据报的类型信息都是可用的。然后通过重新创建全局变量、堆和堆栈，程序从检查点处继续执行。

经过统计，选择空闲主机并且开始一个新的进程需要0.1秒的时间，平均迁移时间是330毫秒。通过进程迁移可以将性能提高近5倍。

图1-3 进程迁移过程示意图




高可用性

计算机系统的可靠性用平均无故障时间（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。可维护性用平均维修时间（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR)*100%。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。

计算机产业界通常用如下表所示的"9"的个数来划分计算机系统可用性的类型。

可用性分类可用水平每年停机时间容错可用性99．9999< 1 min极高可用性99．9995 min具有故障自动恢复能力的可用性99．9953 min高可用性99．98.8 h商品可用性9943.8h

通过硬件冗余或软件的方法都可以从很大程度上提高系统的可用性。硬件冗余主要是通过在系统中维护多个冗余部件如硬盘、网线等来保证工作部件失效时可以继续使用冗余部件来提供服务；而软件的方法是通过软件对集群中的多台机器的运行状态进行监测，在某台机器失效时启动备用机器接管失效机器的工作来继续提供服务。

一般来说，需要保证集群管理器的高可用性和节点的高可用性。Eddie、LinuxVirtual Server、Turbolinux、Piranha和Ultramonkey都采用了类似于图1的高可用性解决方案。

图1 高可用性解决方案示意图

集群管理器的高可用性

为了屏蔽集群管理器的失效，需要为它建立一个备份机。主管理器和备份管理器上都运行着heartbeat程序，通过传送诸如"我活着"这样的信息来监测对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就激活fake程序，让备份管理器接管主管理器继续提供服务；当备份管理器又从主管理器收到"我活着"这样的信息时，它就使fake程序无效，从而释放IP地址，这样主管理器就开始再次进行集群管理的工作了。

回页首

节点的高可用性

节点的高可用性可以通过不断监视节点的状态以及节点上的应用程序的运行状态来实现，当发现节点已经失效时，可以重新配置系统并且将工作负载交给那些运行正常的节点来完成。如图1所示，系统通过在集群管理器上运行mon精灵程序来监视集群中的实际服务器上的服务程序的运行状况。例如使用fping.monitor以一定的时间间隔来监视实际服务器是否还在正常运转；使用http.monitor来监测http服务，使用ftp.monitor来监测ftp服务等等。如果发现某个实际服务器出了故障，或者是其上的服务已失败，则在集群管理器中删除有关这个实际服务器的所有规则。反之，如果不久以后发现系统已经重新能够提供服务，则增加相应的所有规则。通过这种方法，集群管理器可以自动屏蔽服务器和其上运行的服务程序的失效，并且当实际服务器正常运转时能将它们重新加入到集群系统中。

文件系统

集群计算的发展需要发展并升级文件系统，此文件系统不仅能够对多个文件提供并行的访问，而且能在对同一文件进行访问的进程间提供cache一致性。大多数传统的网络文件系统如NFS、AFS、Coda对于并行处理而言是远远不够的，因为它们都依赖中心文件服务器。但是，随着越来越多的客户的加入，服务器的cpu很快就成为了性能的瓶颈。为了解决这个问题，处理能力更强的服务器已经被制造了出来，而且文件系统的设计者们也试图将更多的工作交给客户来完成，但是即使是这样，服务器的速度仍然是文件系统可升级性的瓶颈。新一代的文件系统如GlobalFile System(GFS) 、XFS和 Frangipani比较适合于集群系统。因为这些系统都在集群系统中的机器上分配存储器、cache和控制权，并且提供了并行文件访问和cache一致性的解决方法。

Coda文件系统

Coda文件系统(Coda FileSystem)适用于分布式网络环境。它是在1987年在卡耐基梅隆大学以AFS2为原型开发出来的。LinuxVirtualServer就采用了Coda文件系统。Coda提供了以下适用于网络文件系统的特性。

1. 为移动的客户提供了断开操作。
2. 它是一种自由软件。
3. 通过客户访问的持续缓存提供了高可用性。
4. 服务器复制功能。
5. 提供了认证的安全模型、加密和访问控制。
6. 部分网络失效后能够继续工作。
7. 具有网络带宽适应性。
8. 较好的可扩展性。
9. 即使在网络失效时也为共享定义了良好的语法。

AFS和Coda文件系统都将所有的文件放于同一个目录下，如AFS是/afs，Coda是/coda，这意味着所有的客户都可以使用相同的配置，所有的用户看到的是相同的文件树。对于大的安装而言这是非常重要的。对于NFS文件系统而言，客户需要服务器的最新列表而在Coda中只需要找到根目录/coda。

当在客户端敲入"cat/coda/tmp/foo"这样的请求时，cat将调用系统调用向核心请求服务，核心首先找到对应的文件索引节点并返回与该文件相关的文件句柄。索引节点包含文件的一些相关信息，文件句柄用于打开文件。系统调用首先进入核心的虚拟文件系统（VFS），然后它将请求传送给核心中的Coda文件系统模块进行处理。Coda文件系统模块包含着从VFS来的最近的一些请求，然后它将此请求交给Coda缓冲管理器venus进行处理。Venus通过察看硬盘缓冲区、向服务器发请求等方式来定位文件的所在地。如果在硬盘缓冲区中没有找到匹配的文件，则通过远程系统调用向服务器发请求，并且将取到的文件放在cache中，这时，这个文件就是一个普通的文件了，因此可以通过本地文件系统对该文件进行读写的操作。如果在硬盘缓冲区找到了此文件，则可以直接使用这个文件。当对此文件进行了一定的修改并且关闭了以后，venus将把新文件传送给服务器从而来更新服务器上的文件。其它的操作如修改文件系统，创建新目录，删除文件，去除符号链接等都可以传送给服务器。

但是由于网络有时会出现问题，因此如何保证文件的连续性是一个非常重要的问题。当venus意识到服务器不可用时，它就将客户端对文件的更新存储在修改日志中，当服务器重新可用时，便根据修改日志对服务器上的相应的文件进行更新。

回页首

Global 文件系统

Global 文件系统（Global File System,GFS）允许多个Linux机器通过网络共享存储设备。每一台机器都可以将网络共享磁盘看作是本地磁盘，而且GFS自己也以本地文件系统的形式出现。如果某台机器对某个文件执行了些操作，则后来访问此文件的机器就会读到写以后的结果。GFS文件系统的使用示意图如图1所示。

图1 GFS文件系统使用示意图





回页首

xFS文件系统

xFS试图通过将服务器的功能如保持cache的一致性、定位数据和处理磁盘请求分布在各个客户上来提供对文件系统数据的低延迟、高带宽的访问。

为了保持cache一致性，xFS采用了如下的方法。它将客户方的所有的内存空间看为一个大的cache，这样就减少了客户方的数据缓存，利用了闲置机器的内存，这种合作型的缓存可以通过减少到达磁盘的请求量来降低读延迟。

为了将定位数据的功能分布到每个客户端，xFS让每个客户都必须对文件的一个子集对应的请求进行处理。文件数据在多个客户端加以分类从而提供更高的带宽，这些分类数据包括一些奇偶信息，通过这些信息可以在机器失效时恢复分类的数据报。这种方法可以保证没有任何节点会产生单点失效的情况。

回页首

MOSIX文件系统

MOSIX集群使用了自己的文件系统MFS文件系统。MFS将集群中的所有文件系统和目录都看作是一个文件系统，而且它提供了对所有节点上的所有文件系统的统一访问，它还通过只提供一个cache保证了cache的一致性。

MFS包含了许多位于不同节点上的文件子树，因此它就允许对多个文件进行并行操作和cache一致性。

在MOSIX集群中进行进程迁移时，如果此进程主要占用的是CPU资源，则迁移此进程对于提供系统性能是非常有效的，但是如果此进程需要进行大量的I/O操作，则迁移进程非常不利。这是因为每个I/O操作都需要与该进程原来所处的节点进行通讯。

因此MFS增加了对DFSA(Direct File SystemAcess)的支持。DFSA的目的就是让那些需要进行大量I/O操作的进程迁移到远端节点上，该远端节点拥有大多数I/O操作将会涉及到的文件，因此大多数的I/O操作都能在远端节点上完成，而且在远端节点上可以通过本地访问来访问数据。如果一个系统调用是节点无关的，此系统调用就会在远端节点上执行，否则就在本地执行。MFS比其它网络文件系统优越的地方就是它允许使用本地文件系统，这样就减少了进程和文件服务器之间的通讯开销。