由于集群的保障对象，即服务程序和应用程序在功能和结构上千差万别，集群软件系统的提供商很难了解应用软件的内部结构和功能，所以集群一般都是采用通用的容错方式对待应用软件，对于资源检测和故障转移只能采用与软件功能没有相关性的方法。也就是说集群只能从系统层上对应用软件状态进行检测，只有在发现应用软件出现异常中止和进程结束时才对应用程序进行故障转移，而对于业务软件在应用层上的错误并不予关注，但应用层上的错误往往会导致错误的结果却并不会导致程序的异常中止，这样一来集群就无法做到故障转移了。实际上，集群停掉错误节点并在备用服务上重新启动业务软件的时候并没有考虑到对业务软件的错误现场的捕获和业务状态的恢复，这对于关键业务系统来说当然是不行的。
- 最近看了一些关于集群的资料，收获颇多，决定阶段性的整理一下。以后再慢慢的补充。
1、集群的概念(Cluster Technology Concept)
现在在许多关键业务系统(Mission Critical System)：如金融、电信领域等。对计算机系统提出了很高的要求，要求系统具有长时间持续稳定运行以及容错和可恢复性。集群技术就是在这样的背景下产生的。
集群是一种计算机系统，它通过软件和硬件把多台计算机以特殊的方式连接起来，作为一个整体为客户端提供服务。集群分为同构和异构两种，他们的区别在于组成集群系统的计算机之间的体系结构是否相同。
下面是一个典型的双机集群的物理结构图：
- 系统主要由两台服务器，一台磁盘阵列构成，每台服务器有各自独立的硬盘，通过SCSI (Small Computer System Interface) 连接线连接到磁盘阵列。磁盘阵列有自己的CPU和内存，采用RAID技术提高读写能力。
- RAID (Redundant Array of Inexpensive Disks)技术是一种高效磁盘读写算法，分为raid0(磁盘条带化)，raid1(磁盘镜像)，raid0+1(磁盘条带化和镜像)，raid3(磁盘条带化并具有专用校验盘)，raid5(磁盘条带化并具有分布式校验)等不同的raid级。现在常用的raid5技术采用磁盘条带化即数据分块，在读写时以并行的方式对每个硬盘同时进行操作，提供了高性能的数据访问，而分布式校验则是按照某种规则将奇偶校验信息均匀分布在阵列所属的硬盘上，所以在每块硬盘上既有数据信息又有校验信息，解决了raid3中争用校验盘的情况。
2、集群的工作方式
磁盘阵列在集群中有两种工作模式：共享模式和非共享模式。目前集群一般采用非共享模式，即某一时刻只能有一方拥有磁盘阵列的访问和控制权。
集群中的每台服务器都要建立两条通信通道，一条通过以太网卡连接到外网（一般采用TCP/IP网络协议）来实现服务器与客户端之间的通信；一条则是集群内的每台服务器之间心跳信号通信（一般采用串行通讯线路RS232或TCP/IP网络和共享磁盘阵列互相传递信号），心跳线路最好使用两条不同的通信路径达到监视线路冗余的效果。
常见的双机工作模式有三种：并发访问模式、互备模式、热备模式。其中并发访问模式是为针对Oracle Parallel Server环境设计，允许多个节点在同一时刻访问同一块数据；互备模式是两台服务器均为客户端提供自己的应用服务，并互相监视对方的运行状态，当一台出现故障时，另一台接管对方的应用服务；热备模式则是一台为工作机，一台为备份机，工作机在为客户端提供服务的时候，备用机监视其状态，当工作机故障时，备用机接管工作机的应用继续为客户端提供服务。
下图是一个双机集群的逻辑结构图：以热备模式为例
由Node A 和Node B组成的双机集群，对于客户端来说体现为一台虚拟的服务器Server C。通过资源注册，将需要管理的资源，如共享文件、服务程序等提交给集群管理器。在集群内部，通过集群服务器，客户端发送给Server C的服务请求由Node A节点接收，运行在Node A上的服务程序或应用程序从磁盘阵列中读取业务数据处理以后透过集群服务器返还给客户端。节点B通过心跳信号(Heart Beat)监视节点A状态，当集群服务器发现处于Active的节点发生故障（如硬件故障，核心软件崩溃等）则关闭节点A上的服务和应用程序，同时释放节点A对主机名，IP地址，磁盘阵列等的控制权由节点B接管，再启动节点B上的服务和应用程序。
3、高可用性集群技术软件(High Availability)
市场上有许多流行的高可用性集群技术软件，都能够帮助提供冗余和容错的恢复能力，可方便有效的管理集群系统，并且能够做到当某台服务器上的应用出现故障时立即自动将应用切换到其他服务器上。
可是，由于集群的保障对象，即服务程序和应用程序在功能和结构上千差万别，集群软件系统的提供商很难了解应用软件的内部结构和功能，所以集群一般都是采用通用的容错方式对待应用软件，对于资源检测和故障转移只能采用与软件功能没有相关性的方法。也就是说集群只能从系统层上对应用软件状态进行检测，只有在发现应用软件出现异常中止和进程结束时才对应用程序进行故障转移，而对于业务软件在应用层上的错误并不予关注，但应用层上的错误往往会导致错误的结果却并不会导致程序的异常中止，这样一来集群就无法做到故障转移了。实际上，集群停掉错误节点并在备用服务上重新启动业务软件的时候并没有考虑到对业务软件的错误现场的捕获和业务状态的恢复，这对于关键业务系统来说当然是不行的。
基于此，就需要针对关键业务软件的结构和功能进行改动，以实现其对自身业务程序运行情况的监测并能在应用层出错的时候进行故障转移。如Oracle就开发了针对数据库的RAC ( Real Application Cluster ) ，在RAC中所有节点都工作在Active模式下，节点之间同步复制工作状态，使得在单个节点出现故障时，其他节点可以快速接管出错节点的事务。因此，对于关键业务系统，可以根据自己的需要加入集群管理模块，以提高程序的可用性。
4、集群管理模块的一种设计思路
我们知道Microsoft的SQL Server在集群环境下工作时采用事件日志来捕获和记录当前服务状态，以供故障转移后恢复服务状态。因此集群管理模块的设计也可以参照这一思路，即通过应用程序内部的集群管理模块来对业务状态进行监测，并进行日志的记录，当管理模块发现错误时进行故障转移，由新节点从日志中恢复之前的业务状态。
下面进行详细的介绍。
