HACMP工作原理.doc

HACMP工作原理1.HACMP网络HACMP的工作原理是利用LAN来监控主机及网络、网卡的状态。在一个HACMP环境中有TCP/IP网络和非TCP/IP网络。TCP/IP网络即client访问的公共网，如果是一个并行数据库环境，那么还必需一个不允许client访问的私网，用以lock manager对数据进行协同工作。当然本方案中只需一个普通的公网即可，该网可以是大多数AIX所支持 的网络，如Ethernet，T.R.，FDDI，ATM，SOCC，SLIP，等等，在本方案中是10M/100M以太网。非TCP/IP网络用来为HACMP对cluster中的各节点进行监控而提供的一个替代TCP/IP的通讯路径，它可以是用RS232将各节点连接起来，也可以是将各节点的SCSI卡或SSA卡设置成Target Mode方式。为了简单方便，本方案中我们采用RS232串口连接的方式，这也是绝大多数用户采用的方式。2.HACMP故障类型HACMP将诊测并响应于三种类型的故障：1网卡故障，2网络故障，3节点故障。下面就这三种故障分别进行介绍。网卡故障前面讲到，HACMP的群集结构中，除了TCP/IP网络以外，还有一个非TCP/IP网络，方案中为RS232连接，它实际上是一根“心跳”线，专门用来诊测是节点死机还是仅仅是网络发生故障。如下图所示，一旦节点加入了cluster（即该节点上的HACMP已正常运行），该节点上的各个网卡、RS232串口和Target-Mode SSA 或 SCSI 就会不断地接收并发送Keep-Alive信号包，K-A的参数是可调的，针对以太网，当处于normal状态时，将每隔0.5秒发送一个K-A包，如果12个包丢失后HACMP确认对方网卡、或网络、或节点发生故障。如果在slow或fast状态，参数值又有所变化，不过这种变化对于整个的接管时间的影响非常之小，以至通常可以不用去考虑。因此，有了K-A后，HACMP可以很轻易地发现网卡故障，因为一旦某块网卡发生故障，发往该块网卡的K-A就会丢失。此时nodeA上的cluster manager(HACMP的“大脑”)会产生一个swap-adapter的事件，并执行该事件的script（HACMP中提供了大部分通用事件的scripts，它们是用标准的AIX命令和HACMP工具来写的）。其过程如下图所示。每个节点上都有至少两块网卡，一块是serviceadapter，提供对外服务，另一块是standby adapter，它的存在只有cluster manager知道，应用和client并不知道。一旦发生swap-adapter事件后，cluster manager将原来的service adapter的 IP地址转移到standby adapter上，而standby地址转移到故障网卡上，同时网络上其他节点进行ARP的刷新。网卡互换(swap-adapter)通常在几秒内就可完成，以太网为3秒，并且这种转换对应用和client来说是透明的，只发生延迟但连接并不中断。网络故障如果发往node A上的 service 和 standby网卡上的K-A包全都丢失，而RS232上的K-A仍然存在，那么HACMP断定nodeA仍然正常，是网络发生故障。此时HACMP执行一个network-down 的事件的script，通常这个script并不做什么事，只提供一个用户自行定义其行为的接口，用户可以根据自己的网络结构，用户数，是否有替代路径，使用的通讯软件，应用软件等来自行设计网络发生故障后应采取的行为。节点故障如果不仅网络上的K-A全部丢失，而且RS232上的K-A也丢失，那么HACMP断定该节点发生故障，一个node-down事件发生。此时将有资源的接管发生，即放在共享磁盘陈列上的资源将由 备份节点接管，接管包括一系列操作：Aquire disks，Varyon VG， Mount file systems，Export NFS file systems，Assume IP network Address，Restart highly available aplications，其中，IP地址接管和应用的重启是由HACMP来实现，而其它是由AIX来完成。当整个节点发生故障时，HACMP将故障节点的service IP address 转移到备份节点上，使网络上的client仍然使用这个IP地址，这个过程称为IP地址接管(IPAT)，如上图所示。当一个节点down掉后，如果设置了IP地址接管，网络上的clients会自动连接到接管节点上；同样，如果设置了应用接管，该应用会在接管节点上自动重启，从而使系统能继续对外服务。对于要实现接管的应用，只需在HACMP中把它们设置成application server，并告诉HACMP启动这个应用的start script的全路径名和停止该应用的stopscript的全路径名。由此可见，应用接管的配置在HACMP中十分简单，重要的是start script和stop script的写作，这需要用户对自己应用的了解。其他故障HACMP只去检测网卡、网络和节点是否发生故障，并作出相应的地址转换、资源接管动作，那么，如果是这三种故障之外的其他故障时，HACMP就不做任何事了吗？答案是，如果你不作任何设置，那么HACMP缺省不作任何动作，但你可以作一定的设置，使HACMP可以发挥它的作用缺。下面我们就来看看HACMP还可以做些什么。硬盘故障一般我们都将硬盘设置成RAID-5方式或mirror方式，从而提供硬盘的高可用性。RAID-5将奇偶较验位分散在硬盘组中，因此当一组内的一个硬盘坏掉，组内的其他硬盘可以通过奇偶较验位将该硬盘上的数据恢复出来。RAID-5方式一般是由硬件实现的，如7135的SCSI controller。但如果同一组内的两个硬盘同时坏掉，该组硬盘的数据很可能就会全部丢失。mirror 方式是将同一个数据写到至少两个物理位置上，因此它的效率没有RAID-5高，而且需要一倍于实际数据量的容量，但 mirror 的硬盘的安全性比 RAID-5高，而且它易于实现，只需通过AIX中的LVM就可以很方便地设置。以前只有SCSI设备才能做到HACMP环境下的RAID-5，但从今年7月31日开始，7133-SSA也支持HACMP下的RAID-5。因此，当硬盘发生故障时，AIX和硬盘自己可以提供其可用性，HACMP不需要做任何事情。硬盘控制卡存储设备连接到主机上都必须通过一块控制卡，SCSI设备是SCSI adapter，SSA设备是SSA adapter，如果这块卡坏掉，与之连接的外设就无法被利用。有几种办法可以解决这个问题。一种办法是在主机上用多个adapter。如图所示，每个主机上都有三块adapter，分别连接三份mirror的数据，因此无论是硬盘坏掉，还是adaptor坏掉，所有的好的数据还是可以被主机访问，不会出现单点故障。这种方法实现起来并不难，但必须配置多块adapter,而且必须采用数据mirror方式。这种方法也不用HACMP。另一种方法可以只用一块adapter，它是利用HACMP所提供的Error Notification Facility(错误通告机制)来解决。Error Notification Facility是HACMP提供的一个监控工具，任何报告给AIX的错误(error)都能被捕获被采取相应措施。HACMP提供了一个Smit界面，使配置非常简单。举几个例子。上例中，当adapter0发生永久性故障并报告给AIX时，AIX将执行halt -q 的命令，这将使adapter故障升级为节点故障，这时HACMP将接手工作。这种将设备故障升级为节点故障的方法有时十分有用。例2中，error-notify-1是一个script，它是这样写的：其中参数为： $1 Sequence Number$ 2 Error ID$ 3 Error Class$ 4 Error Type$ 5 Alert flag value$ 6 Resource name$ 7 Resource type$ 8 Resource class它们都是AIX的错误报告中的参数，可以在AIX中用errpt命令来看。因此，一旦有永久性的软件故障报告给AIX，AIX将执行script：error_notify_1，使在屏幕上显示出错提示，并将有关出错信息mail给系统管理员。这个例子中HACMP实际上仍未做任何动作，但它提供了一个错误监控的工具和界面。我们已知道，用LVM可实现硬盘镜像，当一个盘坏掉，仍有一份数据在镜像盘里，数据仍可进行读写，但此时数据不再有可用性，若镜像盘也坏掉则数据会全部丢失。所以在此例中，PV丢失(LVM_PVMISS)的信息会大幅地显示在控制台屏幕上，从而提醒用户去仔细查看 error log，找出故障并修复它。同样，此例中HACMP提供了对发生的故障的监控界面。应用故障如果用户的应用中有 kernal call的调用，或以root身份来启动等，一旦应用发生故障，很容易导致操作系统down掉，发生死机，这时实际等于节点故障，所以HACMP会采取相应的接管措施。但如果只是应用自身死掉，AIX仍正常运行，这时HACMP最多利用Error Notification Facility来提供监控功能，对应用本身不采取任何动作。但如果应用中调用了AIX的SRC(System Resource Controller)机制所提供的API接口，就可以使应用在down掉后能够自动重新启动。除了SRC提供的API接口外，HACMP中的clinfo也提供这样的API。clinfo是cluster Information daemon,它负责维护整个cluster的状态的信息，clinfo API允许应用程序利用这些状态信息从而采取相应行动。HACMP故障如果cluster中节点的HACMP进程down掉，HACMP会将其升级为节点故障，从而发生资源的接管。现在我们来小结一下。可以看到，HACMP只全权负责诊断网卡故障、网络故障和节点故障这三大类故障，并负责实现IP地址转换或接管，以及整个系统资源(硬件、文件、系统、应用程序，等等)的接管的工作。对于这三类故障外的其他故障，可以结合AIX基本功能和HACMP提供的一些机制，如Error Notification Facility, clinfo API等，同样可以实现对故障的监控并促使AIX或者HACMP采取相应措施。3.资源接管方式下面我们来了解一下HACMP的工作方式，也即有故障发生时资源被接管的方式。首先，一个cluster中资源都包括些什么？通常它包括：应用程序、硬盘、卷组(VG)、文件系统、NFS文件系统、IP地址。资源都属于某个资源组(Resource Group)，有三种类型的资源组：-Cascading(层递式)-Rotating(替换式)-Concurrent(同时存取式)不同类型的资源组对应不同的接管方式。一个cluster中可以有好几个资源组，它们可以分别是不同类型，因此，资源接管的方式可以多种多样，配置十分灵活。以最简单的2-node集群为例。node A和 node B都是资源组a的成员，该资源组a被设置成cascading方式，node A对其拥有最高优先级。因此node A在cluster中处于active状态时，它会控制资源组a中的所有资源，此时node B相对应资源组a是处于闲置(idle)状态，仅当node A down掉，nodeB才会接管资源组a，而且一旦node A重新加入cluster，node B将不得不释放资源组a, node A将重新控制资源组a。如果node B发生任何故障，不会发生任何事件。该过程如图1所示。 图11图12图13图2 idle-standby示意图如果一个cluster中不仅仅只有一个资源组a，还有资源组b，例如，有两个应用程序都需要被自动接管，此时就需要定义两个资源组，每个资源组中各有一个application server。这时，可以把资源组a 和b都由server A来控制，server B仍处于完全的idle状态，这叫idle standby。其过程示意图见图2。但是也可以把资源组a和资源组b分开来，node A对资源组a拥有最高优先级，node B对资源组b拥有最高优先级，因此，当node A和node B在cluster中都处于正常状态时，如图31所示，node A 控制资源组a，node B控制资源组 b；当node A down掉后，node B会接管资源组a，如图32所示；当node A恢复并加入 cluster后， node A重新获得对资源组a的控制权，如图33所示。反之，当node B down后亦然。这种不同 node 控制各自的资源组的方式，也称之为相互接管(mutual takeover)。图31图32 图33上面介绍的是cascading方式，这种方式实现起来简单明了，故障的接管和恢复也易于控制，因此本方案建议使用idle standby方式。即平常node 1完成所有工作， node 2始终处于闲置状态；一旦node 1 down掉，node 2将接管所有任务；一旦node1恢复并重新加入cluster，任务又全部交还给 node 1， node 2又恢复成idle standby 。rotating方式与 cascading方式所不同的是，采用rotating方式的资源组不是固定地分配给某个 node，而是第一个加入 cluster的node拥有第一个可用的资源组，第二个加入cluster的node获得第二个可用的资源组，直至最后一个资源组被动态分配完为止，没有获得资源组的节点将作为standby节点。当一个节点失败后，拥有最高优先级的standby节点将接管资源。当故障节点恢复并重新加入cluster后，该恢复节点不能重新获得原有的资源组，而只能成为standby节点。concurrent 方式所专门针对Oracle Parallel Server环境设计而成，它允许多个节点在同一时刻访问同一块数据。 concurrent方式不支持 AIX的 JFS，因此应用重新必须建立在裸逻辑卷 (raw logical volumes)上。concurrent 方式的资源组中包括有