http://freeze.blog.51cto.com/1846439/388957
此文凝聚笔者不少心血请尊重笔者劳动，转载请注明出处。http://freeze.blog.51cto.com/
随着Internet技术的迅猛发展，网络技术、性能的不断提高，高可伸缩性、高可用性、可管理性、价格有效性的网络服务技术将成为网络服务技术的主导。各种平台下的技术方案应运而生。本文试图以一篇完整的理论+实践性的文字来介绍如何在优秀的开源操作系统Linux下创建低成本、高性能、高可用的服务集群系统（也叫集群系统），希望通过笔者努力，让您对集群有一定的了解。
高可扩展性：如上所述。
高可用性：集群中的一个节点失效，它的任务可以传递给其他节点。可以有效防止单点失效。
高性能：负载平衡集群允许系统同时接入更多的用户。
高性价比：可以采用廉价的符合工业标准的硬件构造高性能的系统。
集群类型 ： 最常见的三种集群类型包括： 负载均衡集群： LB: load balancing 高可用性集群： HA：High Availability 高性能也叫科学集群：HP : High Performance
负载均衡集群 (LB:load balancing) 负载均衡集群为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机集群中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也是如此。通常，网络服务器应用程序接受了太多入网流量，以致无法迅速处理，这就需要将流量发送给在其它节点上运行的网络服务器应用。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。
高可用性集群 (HA:High Availability) 高可用性集群的出现是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。 在集群的这三种基本类型之间，经常会发生混合与交杂。于是，可以发现高可用性集群也可以在其节点之间均衡用户负载，同时仍试图维持高可用性程度。同样，可以从要编入应用程序的集群中找到一个并行集群，它可以在节点之间执行负载均衡。尽管集群系统本身独立于它在使用的软件或硬件，但要有效运行系统时，硬件连接将起关键作用。
高性能集群 (HP :High Performance ) 通常，第一种涉及为集群开发并行编程应用程序，以解决复杂的科学问题。这是并行计算的基础，尽管它不使用专门的并行超级计算机，这种超级计算机内部由十至上万个独立处理器组成。但它却使用商业系统，如通过高速连接来链接的一组单处理器或双处理器 PC，并且在公共消息传递层上进行通信以运行并行应用程序。因此，您会常常听说又有一种便宜的 Linux 超级计算机问世了。但它实际是一个计算机集群，其处理能力与真的超级计算机相等，通常一套象样的集群配置开销要超过 $100,000。这对一般人来说似乎是太贵了，但与价值上百万美元的专用超级计算机相比还算是便宜的。 |
下面笔者着重介绍前两种集群方式，也是企业中最常用的。（不是做科学研究，模拟×××爆炸，宇宙曲线计算等的大型项目高性能集群一般用不到）
一、负载均衡集群 (LB:load balancing)
负载均衡技术主要应用 1、DNS负载均衡 最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法，因此，对于同一个名字，不同的客户端会得到不同的地址，他们也就连结不同地址上的Web服务器，从而达到负载平衡的目的。例如 : 当客户端连结 www.51cto.com这名称时，DNS 有能力依序将名称解析到 202.1.1.1 、 202.1.1.2 、202.1.1.3和 202.1.1.4等不同的网络地址，而这些是提供相同服务的主机，让客户端不自觉有不同 . |
笔者用一幅图为例，简单介绍下负载均衡原理：
用户通过互联网访问到某个网站时，，前端的Load Balancer（类似负载均衡器）根据不同的算法或某种特定的方式，将请求转发到后端真正的服务器（节点），后台多台服务器共同分担整个网站的压力。后台的某个节点如果有宕机，其他节点也可以提供服务，从而维持整个网站的正常运行.
负载均衡可以针对不同的网路层次
链路聚合技术（第二层负载均衡）是将多条物理链路当作一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中所有物理链路共同承担，由此在逻辑上增大了链路的容量，使其能满足带宽增加的需求.
现在经常使用的是4至7层的负载均衡。
第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次TCP连接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术得到广泛的应用，一个目标地址是服务器群VIP（虚拟IP，Virtual IP address）连接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略，在服务器IP和VIP间进行映射，选取服务器群中最好的服务器来处理连接请求。
第七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。
第七层负载均衡优点表现在如下几个方面：
1。通过对HTTP报头的检查，可以检测出HTTP400、500和600系列的错误信息，因而能透明地将连接请求重新定向到另一台服务器，避免应用层故障。
2。可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增加系统性能。
3。能根据连接请求的类型，如是普通文本、图象等静态文档请求，还是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提高系统的性能及安全性。
缺点: 第七层负载均衡受到其所支持的协议限制（一般只有HTTP），这样就限制了它应用的广泛性，并且检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量连接请求的情况下，负载均衡设备自身容易成为网络整体性能的瓶颈。
实现负载均衡有两种方式：
1、硬件：
如果我们搜一搜"负载均衡",会发现大量的关于F5等负载均衡设备的内容，基于硬件的方式，能够直接通过智能交换机实现,处理能力更强，而且与系统无关，这就是其存在的理由．但其缺点也很明显：
首先是贵，这个贵不仅是体现在一台设备上，而且体现在冗余配置上．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置，一旦出了问题就全趴了．
第二是对服务器及应用状态的掌握：硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）。
所以硬件方式更适用于一大堆设备、大访问量、简单应用。
一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。
在网站上搜索了一些硬件负载均衡设备的报价.是不是很吓人.动则几十万，贵则上百万.
硬件load balance厂商和产品列表: 公司名称: Alteon Websystems(Nortel): 产品 ACEDirector, AceSwitch 180等 http://products.nortel.com/go/product_content.jsp?segId=0&parId=0&prod_id=37160&locale=en-US ------------------------------------------------------------------------------------------------------------------------------------------公司名称: F5 networks:
产品: BIG-IP http://www.f5networks.co.jp/ http://www.f5networks.co.jp/product/bigip/ltm/index.html http://www.f5.com/products/bigip/ ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Arrow Point(Cisco): 产品: CS-100 http://www.ecrunch.com/listingview.php?listingID=59&PHPSESSID=3c21a8f95a6459132a120d4335dcf506 ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Cisco 产品: Local Director 400 series http://www.cisco.com/en/US/products/hw/contnetw/ps1894/index.html ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: RADWARE 产品: APP Director (Web server director) http://www.radware.com/ http://www.radware.com/content/products/appdirector/default.asp ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Abocom（友旺） 产品: MH系列多路负载均衡器 http://www.abocom.com.cn/product.asp?xlflid=12 台湾公司，生产家用和企业用负载均衡器， 看上去比较 业余 ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Intel 产品: NetStructure(网擎) 7170 traffic director http://www.intel.com/support/netstructure/sb/cs-009599.htm ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Coyote Point http://www.coyotepoint.com/ 专门做硬件load balance的公司好称性价比超过F5的公司 ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: Foundry Networks 产品: ServerIron http://www.foundrynet.com/products/webswitches/serveriron/index.html ------------------------------------------------------------------------------------------------------------------------------------------ 公司名称: HydraWeb 产品: HydraWeb Dispatcher |
可以看出，硬件设备的昂贵程度不是每个企业都可以用起的，而且实际上如果几台服务器，用F5之类的绝对是杀鸡用牛刀（而且得用两把牛刀），而用软件就要合算得多，因为服务器同时还可以跑应用，呵呵，下面来看看可以在linux平台实现负载均衡的软件。
2、软件：
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。
著名项目：开源软件最著名的是LVS.
LVS提供了两大类负载均衡技术及其配套集群管理软件
★★★LVS系统结构与特点
1. Linux Virtual Server:简称LVS｡是由中国一个Linux程序员章文嵩博士发起和领导的,基于Linux系统的服务器集群解决方案,其实现目标是创建一个具有良好的扩展性､高可靠性､高性能和高可用性的体系｡许多商业的集群产品,比如RedHat的Piranha､ Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代码的｡
2. 体系结构:使用LVS架设的服务器集群系统从体系结构上看是透明的,最终用户只感觉到一个虚拟服务器｡物理服务器之间可以通过高速的 LAN或分布在各地的WAN相连｡最前端是负载均衡器,它负责将各种服务请求分发给后面的物理服务器,让整个集群表现得像一个服务于同一IP地址的虚拟服务器｡
3. LVS的三种模式工作原理和优缺点: Linux Virtual Server主要是在负载均衡器上实现的,负载均衡器是一台加了 LVS Patch的2.2.x版内核的Linux系统｡LVS Patch可以通过重新编译内核的方法加入内核,也可以当作一个动态的模块插入现在的内核中｡
功能
有实现三种IP负载均衡技术和八种连接调度算法的IPVS软件。在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相关的ICMP消息（有些商品化的系统反而不能）。虚拟服务的设置数目没有限制，每个虚拟服务有自己的服务器集。它支持持久的虚拟服务（如HTTP Cookie和HTTPS等需要该功能的支持），并提供详尽的统计数据，如连接的处理速率和报文的流量等。针对大规模拒绝服务（Deny of Service）***，实现了三种防卫策略。
负载均衡器可以运行在以下三种模式下:
简单说明下图简称：以下CIP为客户端IP,VIP为服务器向外提供服务的IP，DIP为Director与内部服务器节点通信的IP，RIP为内部真实服务器的IP。
(1)Virtual Server via NAT(VS-NAT):用地址翻译实现虚拟服务器｡地址转换器有能被外界访问到的合法IP地址,它修改来自专有网络的流出包的地址｡外界看起来包是来自地址转换器本身,当外界包送到转换器时,它能判断出应该将包送到内部网的哪个节点｡优点是节省IP 地址,能对内部进行伪装;缺点是效率低,因为返回给请求方的流量经过转换器｡
整个过程如图所示：CIP为客户Client的IP，VIP为服务器对外的IP，RIP为内部真实服务器的IP
(2)Virtual Server via Direct Routing(VS-DR):用直接路由技术实现虚拟服务器｡当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法,控制管理的计算机接收到请求包时直接送到参与集群的节点｡直接路由模式比较特别，很难说和什么方面相似，前2种模式基本上都是工作在网络层上（三层），而直接路由模式则应该是工作在数据链路层上（二层）。其原理 为，DR和REAL SERVER都使用同一个IP对外服务。但只有DR对ARP请求进行响应，所有REAL SERVER对本身这个IP的ARP请求保持静默。也就是说，网关会把对这个服务IP的请求全部定向给DR，而DR收到数据包后根据调度算法，找出对应的 REAL SERVER，把目的MAC地址改为REAL SERVER的MAC并发给这台REAL SERVER。这时REAL SERVER收到这个数据包，则等于直接从客户端收到这个数据包无异，处理后直接返回给客户端。由于DR要对二层包头进行改换，所以DR和REAL SERVER之间必须在一个广播域，也可以简单的理解为在同一台交换机上。
DR模式：DR模式是这样工作的，当CIP访问VIP后，VIP把数据包通过DIP转交给RIP,RIP在收到数据包后通过网卡别名欺骗（节点的网卡配置别名，IP为VIP），直接用别名的VIP相应客户端，从而加快了回应速度，也避免了Director成为地址转换的单点故障.目前主要应用的为DR模式的负载均衡.
(3)Virtual Server via IP Tunneling (VS-TUN):用IP隧道技术实现虚拟服务器｡这种方式是在集群的节点不在同一个网段时可用的转发机制,是将IP包封装在其他网络流量中的方法｡为了安全的考虑,应该使用隧道技术中的×××,也可使用租用专线｡ 集群所能提供的服务是基于TCP/IP的Web服务､Mail服务､News服务､DNS服务､Proxy服务器等等.
TUN模式:采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。(通过重写ip来实现，真实服务器直接回复客户端。tun原理请参阅×××原理！），与上图比较，注意节点的VIP和RIP的区别.
介绍完上面3种负载均衡模式，下面来看看负载均衡调度算法.
IPVS调度器实现了如下八种负载调度算法
·1.轮叫（Round Robin） 调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。 ·2.加权轮叫（Weighted Round Robin） 调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 ·3.最少链接（Least Connections） 调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。 ·4.加权最少链接（Weighted Least Connections） 在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 ·5.基于局部性的最少链接（Locality-Based Least Connections） "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务器，将请求发送到该服务器。 ·6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication） "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。 ·7.目标地址散列（Destination Hashing） "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 ·8.源地址散列（Source Hashing） "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 |
IPVS的缺点
在基于IP负载调度技术中不会区分内容！所以就要求后端服务器提供相同的服务。而事实呢很多web应用总后端服务器都担任不同的角色，比如专门存放html的、专门存放图片的、专门存放CGI的
★★★内核Layer-7交换机KTCPVS（基于内容转发可以提高单台服务器cache的命中率）
KTCPVS工作流程
在基于IP负载调度技术中，当一个TCP连接的初始SYN报文到达时，调度器就选择一台服务器，将报文转发给它。此后通过查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到该服务器。这样，IPVS无法检查到请求的内容再选择服务器，这就要求后端服务器组提供相同的服务，不管请求被发送到哪一台服务器，返回结果都是一样的。但是，在有些应用中后端服务器功能不一，有的提供HTML文档，有的提供图片，有的提供CGI，这就需要基于内容的调度 (Content-Based Scheduling)。
由于用户空间TCP Gateway的开销太大
他们提出在操作系统的内核中实现Layer-7交换方法，来避免用户空间与核心空间的切换和内存复制的开销。在Linux操作系统的内核中，我们实现了Layer-7交换，称之为KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已经能对HTTP请求进行基于内容的调度，但它还不很成熟，在其调度算法和各种协议的功能支持等方面，有大量的工作需要做。
虽然应用层交换处理复杂，它的伸缩性有限，但应用层交换带来以下好处：
相同页面的请求被发送到同一服务器，可以提高单台服务器的Cache命中率。
一些研究[5]表明WEB访问流中存在局部性。Layer-7交换可以充分利用访问的局部性，将相同类型的请求发送到同一台服务器，使得每台服务器收到的请求具有更好的相似性，可进一步提高单台服务器的Cache命中率。
后端服务器可运行不同类型的服务，如文档服务，图片服务，CGI服务和数据库服务等。
----------------------------------------------------------------------------------------------------------------------------------------------------
二、 高可用性集群 (HA:High Availability)
1、什么是高可用集群
高可用集群，英文原文为High Availability Cluster，简称HA Cluster，是指以减少服务中断（如因服务器宕机等引起的服务中断）时间为目的的服务器集群技术。简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点（node）。
高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。
只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。
2、为什么要使用高可用集群？
先来看一组数据说明：
|
可用比例
(Percent Availability) |
年停机时间
(downtime/year) |
可用性分类
|
|
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
|
随着企业越来越依赖于信息技术，由于系统停机而带来的损失也越拉越大。
高可用集群主要是在linux平台搭建的，在linux上实现高可用的解决方案有哪些：
| Linux平台常见的高可用集群 有这些: 1. 开放源代码的 HA 项目 (http://www.linux-ha.org/)
|
笔者以最常用的heartbeat为例介绍高可用集群：
下图是一个Heartbeat集群的一般拓扑图。在实际应用中，由于节点的数目、网络结构和磁盘类型配置的不同，拓扑结构可能会有不同。
Heartbeat的组成：
Heartbeat提供了高可用集群最基本的功能，例如，节点间的内部通信方式、集群合作管理机制、监控工具和失效切换功能等。目前的最新版本是Heartbeat 2.x，这里的讲述也是以Heartbeat 2.x为主。下面介绍Heartbeat 2.0的内部组成，主要分为以下几大部分。
heartbeat：节点间通信检测模块。
ha-logd：集群事件日志服务。
CCM（Consensus Cluster Membership）：集群成员一致性管理模块。
LRM（Local Resource Manager）：本地资源管理模块。
Stonith Daemon：使出现问题的节点从集群环境中脱离。
CRM（Cluster Resource Management）：集群资源管理模块。
Cluster policy engine：集群策略引擎。
Cluster transition engine：集群转移引擎。
| 从上图中可以看出，Heartbeat内部结构由三大部分组成。 （1）集群成员一致性管理模块（CCM） CCM用于管理集群节点成员，同时管理成员之间的关系和节点间资源的分配。Heartbeat模块负责检测主次节点的运行状态，以决定节点是否失效。ha-logd模块用于记录集群中所有模块和服务的运行信息。 （2）本地资源管理器（LRM） LRM负责本地资源的启动、停止和监控，一般由LRM守护进程lrmd和节点监控进程Stonith Daemon组成。lrmd守护进程负责节点间的通信；Stonith Daemon通常是一个Fence设备，主要用于监控节点状态，当一个节点出现问题时处于正常状态的节点会通过Fence设备将其重启或关机以释放IP、磁盘等资源，始终保持资源被一个节点拥有，防止资源争用的发生。 （3）集群资源管理模块（CRM） CRM用于处理节点和资源之间的依赖关系，同时，管理节点对资源的使用，一般由CRM守护进程crmd、集群策略引擎和集群转移引擎3个部分组成。集群策略引擎（Cluster policy engine）具体实施这些管理和依赖；集群转移引擎（Cluster transition engine）监控CRM模块的状态，当一个节点出现故障时，负责协调另一个节点上的进程进行合理的资源接管。 在Heartbeat集群中，最核心的是Heartbeat模块的心跳监测部分和集群资源管理模块的资源接管部分。心跳监测一般由串行接口通过串口线来实现，两个节点之间通过串口线相互发送报文来告诉对方自己当前的状态。如果在指定的时间内未受到对方发送的报文，就认为对方失效，这时资源接管模块将启动，用来接管运行在对方主机上的资源或者服务 |
---------------------------------------------------------------------------------------------------------------------------------------------------- 三.高性能集群 (HP :High Performance )
这种集群一般企业或者个人很少应用到， 高性能计算群集HPC。它可以解决世界上最为复杂和艰巨的计算难题，并且能够轻松处理。在气象建模、模拟撞车试验、人体基因绘图以及核爆炸模拟等多种与人类生命相关的重要领域都要用到HPC。随着其性能突飞猛进的提高和成本的急剧下降，HPC迅速走出科学研究实验室，步入主流商业领域。通过将集群和大型SMP系统的性能进行完美结合，HPC正在步入网格计算时代，它将使任何人都能随时随地、经济高效地进行计算，在商业上得到更好的应用。众多企业都被其几乎不可抗拒特性和优势所打动，并争相进行部署。除政府、教育和国家实验室等公共部门之外，HPC在制造、金融、能源、生命科学和数字媒体等行业都广受青睐。（此类集群应用有一定局限性，笔者接触不多，不做过多介绍。）
下面是一张某公司的高性能集群组成图：
基础架构：聚合结点、网络以及存储等硬件子系统的基础设施，提供整个集群系统的供电、散热、布线等功能<登录结点：用户登录到集群的工作场所，用户通过它来完成程序的编译调试等工作
计算结点：用于执行用户程序的结点服务器。
存储结点：是挂接存储设备、向系统中的其它结点提供存储服务的服务器。
监控结点：用来监控系统各部分的运行状态、进行远程电源管理和事件告警服务等工作。
存储交换网络：用来连接存储结点和磁盘阵列。
计算网：计算结点在运行程序时的通信设施。由高速的通信网络构成，如Infiniband网络。
管理网：用于集群系统管理的网络，一般采用千兆以太网。
视频切换系统：通过它可以将选定结点机的keyboard、video和mouse重定向到监控台上，从而可以在监控台上对结点进行各种终端的操作
集群软件系统结构图：
设备系统固件层：通信软件和外部设备在适配器上的固件程序
结点系统软件层：结点操作系统及其核心扩展，如操作系统、设备驱动程序、文件系统扩展等
集群系统软件层：集群单一映象的操作管理软件。包括集群管理系统、集群监控系统、作业调度系统等
应用支撑环境层：科学计算应用的支撑平台。如并行环境、数学库、多核线程调试工具等
应用程序层：科学工程计算类的实际应用。
高性能集群笔者接触不多就不过多介绍了，笔者上传一个惠普公司的一个高性能集群案例，在附件里，要想深入了解的话可以看下。