Linux 高可用性(HA)集群探讨

保证持续稳定的系统运行时间变得越来越重要，而传统意义上的小型机系统让普通用户望而却步。用户需要的是更高的可用性以及更低的成本。高可用性(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 中增加一行：

1. 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 集群技术的应用亦将日益广泛。 

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

原文链接