保证持续稳定的系统运行时间变得越来越重要，而传统意义上的小型机系统让普通用户望而却步。用户需要的是更高的可用性以及更低的成本。高可用性 (HA)技术能自动检测服务器节点和服务进程错误、失效，并且当发生这种情况时能够自动适当地重新配置系统，使得集群中的其他节点能够自动承担这些服务，以实现服务不中断。

Cluster应用可分为三方面：High-Availability(HA)(高可用性集群)、Load Balance (负载均衡集群)、Scientific(科学集群)。在集群的这三种基本类型之间，经常会发生混合与交杂。于是，可以发现高可用性集群也可以在其节点之间均衡用户负载，同时仍试图维持高可用性程度。同样，可以从要编入应用程序的集群中找到一个并行群集，它可以在节点之间执行负载均衡。而本文则侧重于介绍基于Linux的HA解决方案方面的问题。 基于LVS的HA方案 Linux要进入高端市场就必须在这方面有相应的措施，所以许多公司都在这方面加大了研究力度。现在，我们可以使用一些现存的软件去构筑具有高可用性的LVS系统。下面列出两种方案，以供参考。 ［方案一］mon heartbeat fake coda 我们可以使用“mon”、“heart beat”、“fake”和“coda”四个软件来构筑具有高可用性的Virtual Server(虚拟服务器)。“mon”是一个大众化的资源管理系统，用来监控网络上的服务器节点和网络服务。“heartbeat”实现在两台计算机间通过在串行线上使用UDP协议传送“心跳信息”。“Fake”是一个使用ARP欺骗的方法来实现IP接管。 当服务器故障时，处理过程如下：“mon”进程运行在负载均衡器上，负责监测整个集群的服务器节点和服务进程。在配置文件“fping.monitor”中写入要检测服务器节点，然后“mon”进程将会隔t秒检查一下相应的服务器节点是否还活着。 另外相关的服务监视器也要做相应的配置，这样“mon”进程将每m秒检测一下所有节点的相应服务进程。例如：http.monitor：用于配置监控http服务；ftp.monitor：用于配置监控ftp服务；以此类推。当配置完成后，某个服务器节点失效或重新生效、服务进程失效或重新生效时都会发送一个通告信息，因此，负载均衡器能够知道服务器节点是否能接受服务。 现在，负载均衡器成为了整个系统的单点失效。为了防止这一现象，我们必须安装一个负载均衡器的备份服务器。“fake”软件实现当负载均衡器失效时，备份服务器自动接管IP地址，并继续服务。而“heartbeat”则随时根据负载均衡器的状态自动激活/关闭备份服务器上的“fake”进程。在负载均衡器和备份服务器上都运行着一个“heartbeat”进程，它们通过串行线周期性地发送“I\’m alive ”消息。如果备份服务器在一个预定时间内接收不到来自负载均衡器的“I\’m alive”信息时，将自动激活“fake”进程接管负载均衡器的IP地址，并开始提供负载均衡服务；而当再次收到来自负载均衡器的“I\’m alive ”消息时，备份服务器将自动将“fake”进程关闭，释放出它接管的服务器，负载均衡器重新开始工作。 但是，如果负载均衡器在客户正在请求时失效，这时会引起客户请求失败，客户必须重新发出请求信息。 “coda”是一个容错的分布式文件系统，源于Andrew文件系统。服务器上的目录能够存储在“coda”上，所以文件能够实现高可用性，并且易于管理。 ［方案二］ldirectord heartbeat “ldirectord”(Linux Director Daemon)是Jacob Rief编程实现的一个独立进程，以实现对服务和物理服务器的监测，广泛地用于http和https服务。 “ldirectord”安装简单，能很好地与“heartbeat”配合工作。“ldirectord”程序包含在“ipvs”包中的“contrib”目录中。 以下是“ldirectord”的一些优点： “ldirectord”是专门撰写的LVS监测程序。 它从/etc/ha.d/xxx.cf文件中读取所有关于IPVS路由表的配置信息。当“ldirectord”运行起来后，IPVS路由表将会被适当地配置。 可以将Virtual service配置放在多个配置文件中，所以可以单独修改某一种服务的参数，而不影响其他的服务。“ldirectord”能被“heartbeat”轻松地管理—-启动、关闭。 将“ldirectord”放到/etc/ha.d/resource.d/目录下，然后在/etc/ha.d/haresources中增加一行： node1 IPaddr::10.0.0.3ldirectord::www ldirectord::mail “ldirectord”能够手动开启、关闭。可以在无备份负载均衡器的LVS集群中使用它。 Xlinux的LATCH HA方案 正如前面所述，高可用性解决方案(HA)是极为重要的，许多厂商为此投入了大量的研究。其中，Xlinux发行版就提供LATCH HA解决方案。下面我们就一起看看LATCH HA方案。 LATCH HA解决方案的最典型的系统结构：两台主机A、B共享一个磁盘阵列，A为工作机，B为备份机。它们之间用一根心跳线来连接，这称为“心跳检测”，主要通过一条RS232检测链路来完成。LATCH HA也采用了用Ping来验证系统宕机的方法。安装在主机上的HA软件通过心跳线来实时监测对方的运行状态，一旦正在工作的主机A因为各种硬件故障导致系统发生故障，主机B立即投入工作。怎么样，与IBM的HACMP有点像吧！ LATCH HA实现了“高可靠性共享存储”架构。该架构由两个或三个冗余服务器、一个共享冗余磁盘阵列、一个可选DBMS及LATCH HA系统软件构成。在LATCH HA的保护下，企业的计算机系统能够提供不间断的信息服务，避免由于硬件故障或日常维护所带来的宕机，因而能够保障最佳的可靠性及最大程度地减少宕机时间。 方案应用 LATCH HA能够应用在各种集中式、客户机/服务器模式或OLTP系统中。同时其与市场上各种主流的数据库系统与OLTP软件(如：Oracle、SYBASE、 Informix、Tuxedo)也都保持兼容。LATCH HA同时提供了各种应用程序接口。因此，客户能够在其私有软件中集成各种功能来保证系统的高可靠性。 LATCH HA /HS2000 在线待机模式 在这种模式下，一个服务器作为主服务器。正常情况下其承当所有的服务。另外一台服务器作为待机服务器(正常情况下除了监控主服务器的状态，不进行其他的操作)。一旦主服务器宕机，待机服务器就接手工作，成为新的主服务器。客户仍然可以拥有同样的服务器IP地址、NFS、数据、数据库及其他……这种应用模式近似于上面介绍的典型应用模式(两台服务器实际上是在完成同一个功能应用)，安装在主机上的HA软件通过心跳线来实时监测对方的运行状态，一旦正在工作的主机A因为各种硬件故障，如电源失效、主要部件失效或者启动盘失效等导致系统发生故障,主机B立即投入工作。 LATCH HA /DA2000双机就绪模式 在这种模式下，两个主机都作为主服务器，共享自己的磁盘阵列，各自承当一部分服务。例如：服务器A在执行应用A, 服务器B在执行应用B, 两个主机在正常情况下各自独立运行自己的应用逻辑，两个主机同时又都作为对方的待机服务器，通过心跳线监控对方的状态。一旦某一服务器宕机，另一台服务器就承担所有的服务，为所有的客户服务。一旦服务器A发生故障，服务器B马上接管服务器A上原来的应用；或者服务器B发生故障，服务器A马上接管服务器B上原来的应用，这是一种互为冗余的模式。 很明显，一旦某一服务器宕机，另一台服务器的工作负担就比较重，于是就有了三主机模式。 LATCH HA /HC2000 三主机模式 这种应用模式是最高端的HA应用模式，它既保证了系统的设备冗余，避免系统宕机，而且又能保证在一旦宕机的情况下有足够的系统资源可供使用。 在这种模式中，待机服务器C同时监控主服务器A与B的状态。一旦服务器A或B宕机，服务器C将承担其服务，为客户服务。这种系统结构既保证了系统的安全运行，又保证了系统资源。 Linux HA的解决方案当然不限于上述两种，但其核心思想是一致的，即提供不间断的服务。近年来随着Linux操作系统不断走向成熟，功能不断增强，特别是其遵循 GPL和标准化的PVM、MPI消息传递机制的特性和在普通PC机上越来越好的高性能网络的支持，所有这些为基于Linux的集群系统的发展提供了坚实的技术基础，在把技术转化为具体的应用过程中，高端的HA应用以其稳定可靠的性能和与Unix相比价格上的优势而脱颖而出。随着基于Intel平台的服务器业已成为关键性业务和应用的主流服务器，Linux HA集群技术的应用亦将日益广泛。  

 

(17.56 KB)

2011-2-9 12:00

HA集群结构图 HA实际上是两台(或更多)计算机通过一定方式互相监听，实现热备份。当其中Primary server出现问题时，Standby server能够自动立即接替工作，使用户感觉不到停机。在Primary server恢复正常之后，Standby server又会把工作还给Primary server。

 

      本文转自glying 51CTO博客，原文链接：http://blog.51cto.com/liying/967685，如需转载请自行联系原作者