hacmpV5.1的规划(翻译红皮书)

2.2.6 规划网络安全
 规划网络安全是避免无授权的存取集群节点的重要方法.
 从hacmp5.1开始,引入了一个新的安全机制,提供了一个通用的通信基础(daemon)配置在所有的相关的节点通信之间.
 引入新的集群通信的daemon(clomdES)提供了增强的安全性也加速了相关的配置操作.
 有三个层次的通信安全:
 1.标准的.
 缺省的安全层次,有集群通信daemon(clomdES)直接实现,使用hacmp的odm类和/usr/es/sbin/cluster/rhosts文件去探测合法的节点.
 2.增强的安全性
 在SP集群中使用,提供了基于第三方kerberos提供的认证方法去增强认证.
 3.VPN
 在aix中配置VPN,然后配置hacmp的所有内置节点使用VPN来连接通信的操作.
 通过使用集群安全通信子系统,hacmp消除了需要/.rhosts或者kerberos在每个节点上的配置.然而,/.rhosts仍然在支持一些应用操作的远程通信机制时使用.
 注意:不是所有的集群通信都是通过clomdES实现安全的,其他的daemons有他们自己的通信机制(不是基于r的命令).
 1.集群管理(clstrmgrES) 2.集群锁daemon(cllockES) 3.集群多对等扩展通信daemon(clsmuxpdES).
 clcomdES用来作集群的同步,集群管理(C-SPOC)和动态重配置等操作.
 集群通信的后台进程,clomdES,通过最小特权的原则提供了安全的远程命令执行和hacmpODM配置文件的更新.因此,仅仅在/usr/es/sbin/cluster的程序可以被root执行,其他的全部都用nobody来运行,除了clcomdES,下面的程序也被使用:
 1.cl_rsh 集群的远程shell执行程序
 2.clrexec root用来作特殊的,危险的操作,例如改变/etc下的文件.
 3.cl_rcp 用来拷贝aix的配置文件
 这些命令是固化在clomdES中并且不支持被用户执行.
 clcomdES(集群通信的后台程序)有如下的特性:
 1.从此集群的通信不再使用标准的aix r* 命令,依赖文件/.rhosts已经被移出,因此即使在标准的安全模式,集群的安全性也被增强了.
 2.为其他节点的odm复制到本地提供可靠的缓存机制.节点同步命令执行时.
 3.限制了在远程节点上以root用户运行的命令(仅仅/usr/es/sbin/hacmp下的)
 4.本身被/etc/inittab启动并作为系统资源管理器被管理.
 5.提供了自己的心跳机制,发现活动的节点(甚至集群管理和RSCT没有运行时)
 注意:clcomdES提供了执行例如clverify,godm.rsh和rexec等hacmp服务的一个透明的机制.
 ClcomdES认证进程确定进入的连接基于检查节点的下列文件:
 1.hacmp适配器ODM类(IP lables 定义在这个类中)
 2.hacmp节点ODM类(集群中节点的通信路径使用的IP地址和标签)
 3./usr/sbin/hacmp/etc/rhosts 文件
 如果/usr/sbin/cluster/etc/rhosts文件不存在或者不包含(ip地址或者可理解的IP标签)远程初始化的节点,那么接入的连接将被拒绝.
 如果上述三者均为空,那么clcomdES认为hacmp是在第一次(就一次)始化配置阶段接受连接,然后加入对等的peer的节点的ip地址到/usr/sbin/cluster/etc/rhosts文件.
 如果连接的请求匹配一个上述定位中的标签,然后clcomdES反向连接到请求的节点查询对应的ip地址,如果ip label和ip地址相匹配,那么认证将成功的完成.
 注意:如果不能解析label在/usr/es/sbin/cluster/etc/rhosts文件,那么远程节点所有的连接被拒绝.

2.3 hacmp心跳
 和其他许多类型的集群一样,心跳用来检测网络接口,通信设备,ip标签(服务的,非服务的,持久的ip)以及节点本身的可用性.
 从hacmp5.1开始,心跳是专有的,基于RSCT拓扑的服务(这样,hacmp5.1仅有:"Enhanced Scalability",经典的通过网络模块的心跳,直接被集群管理后台控制.)心跳是通过集群中每两个节点间的每个通信设备传递和交换的信息(keep alive包).每一个集群中的节点定时的间隔发送心跳信号到其他节点,并且预期的接受心跳信号从相应的节点.如果接受的信号中断了,RSCT认可这一个错误并告诉hacmp,hacmp将执行合适的恢复动作.
 心跳信息通过TCP/IP网络和非IP网络传送.
 为了避免hacmp集群的分离,hacmp必须能区分节点故障和tcp/ip网络故障.tcp/ip网络可以因为不完美的网络元素(交换机,集线器和电缆等)而发生故障,当这种情况发生时,集群中的节点不能通过ip发送心跳信号,所以每个节点考虑到对方节点故障而都去尝试获得资源,这将导致一个潜在数据问题,特别是使用了并发的资源组时.
 非IP网络是在两个节点间直接的点对点连接,不再使用ip进行心跳信号的交换,也因此减少了ip网络的故障.假如这样的网络类型使用了,那么当ip网络故障时,节点仍然可以交换信息,可以判定网络故障而不会发生资源组的接管操作.
 为了避免hacmp被分开,我们推荐配置冗余的网络(ip的和非ip的),同时使用这两种网络.
 2.3.1 通过磁盘的心跳信号
 通过磁盘的心跳是hacmp5.1的新特性,提供了对集群分开和单个非ip网络的附加的保护,特别是当rs232和ssa等连接太复杂时.
 这种类型的网络可以使用许多类型的共享磁盘存储(光纤通道,SSA和scsi等),子盘用来交换KA信息是作为aix增强并发卷组的一部分.磁盘不是排外性的作为这个目的使用,他们仍然可以用来存贮应用共享的数据.
 客户需要使用target模式的光纤通道连接,但是对于异构的FC环境(adapter,存储子系统,sAN交换机),这将很难实施和支持.
 使用共享磁盘来交换信息是更可靠的非ip网络,并且不依赖于特定的硬件.此外,在一个SAN环境中,当使用光纤连接设备,非ip网络的光纤的长度仅仅是SAN的限制,因此允许非常长的点对点的网络.
 当定义一个磁盘作为增强的并发卷组,这个磁盘的一部分(一部分扇区)将不能给lvm使用,将用来在两个节点间交换信息.
 使用基于磁盘的心跳的详细说明如下:
 一个磁盘可以用来作两个节点间的一个网络,这个磁盘在两个节点上使用相同的唯一的特定的标识的PVID.推荐在一个存储范围内的一对节点间的一个磁盘配置磁盘心跳网络.该磁盘需要是增强并发卷组的一部分,虽然并不要求卷组激活或者是资源组的一部分.仅仅的限制是VG必须同时定义在两个节点上.
 注意:集群中并发卷组的锁机制不再需要保留磁盘的一部分来通信,而是以RSCT组服务替代.
 2.3.2 通过IP别名的心跳
 对于IP网络,引入了一个新的心跳机制:通过ip别名的心跳.这使得集群不再需要或者可能在改变通信接口基本ip地址.
 在ip别名上的心跳信号是配置在当hacmp服务启动时已经存在的ip地址上的.用来做这个的ip地址子网必须和已存在的每一个ip子网都不相同,并且不被定义在(/etc/hosts,BIND等)名称解析中.这样的配置不需要一个附加的可路由的子网.
 作为基础和boot ip地址交换心跳信息的替代,RSCT使用hacmp定义的ip别名去完成每一个通信接口的通信组(心跳环).
 注意:当使用了ip别名的心跳,base/bootip地址不在被RSCT拓扑服务监控.将通过分配的ip别名去监控这些通信接口.
 虽然有这些技术,hacmp仍然需要所有接口的可以和其他接口通信(可以看到节点的每一个MAC地址).ip别名使用的子网掩码和服务ip之一的掩码一致.当定义用来做心跳的ip地址时,你必须保证有足够的子网可用并不会冲突.例如:在三个网卡每节点的三节点集群中,你需要三个非路由的子网.
 假定每一个节点有三个网卡(en0,en1,en2),网络掩码是255.255.255.0,那么分配给每一个接口的别名如下表:
adapter/node      node1               node2               node3
en0  172.16.100.1 172.16.100.2  172.16.100.3
en1  172.16.101.1 172.16.101.2  172.16.101.3
en2  172.16.102.1 172.16.102.2  172.16.102.3

通过ip别名实现得心跳得ip地址在集群同步时存储在hacmp adapterODM库中.
 在hacmp5.1中,ip别名得心跳可以配置在建立ipbase得心跳环,使用任何一种IPAT得类型(ip别名和IP重置).IPAT配置得类型探测hacmp是怎样操作服务ip地址(label).:
 IPAT通过ip重置服务标签在base/boot地址上,没有心跳得别名.
 ip别名得IPAT,服务ip地址作为别名和baseip一起在通信接口上,并且使用别名心跳.
 ip别名的心跳定义为hacmp的一个网络特性并且作为hacmp拓扑的一部分.要使用这个工具,用户必须指定起始的地址在hacmp的网络定义中.
 要设置这个属性,你必须使用扩展的smit菜单(cluster topology).这可以在定义网络时定义,也可以在晚点改变这个配置.
 2.4 共享存储的配置
 大部分的hacmp配置需要共享的存储.ibm支持的多主机存取磁盘子系统包括scsi,ssa,ESS,FastT.也有许多第三方的存储设备可以使用,虽然许多没有ibm的认证的使用.情参考制造商的web.
 hacmp支持的ibm存储设备的列表,包括ESS,SSA等,也支持磁带设备的存储,不支持磁带的并发.
2.4.1共享lvm的需求.
 为hacmp规划共享的LVM依赖于共享磁盘存取的方法和设备的类型.共享LVM需要考虑这些元素:数据保护的方法,存储存取的方法,存储硬件的冗余.
 注意:hacmp本身不支持存储的保护,存储的保护通过aix的LVM镜像和硬件raid的实现.
 在这一段中,我们提供了在存储层保护数据的方法,也讨论了lvm共享磁盘存取的模式.
 非并发的,并发的(clvm,hacmp的并发逻辑卷管理),增强并发模式(ECM,aix5.1以后新特性).
2.4.2非并发的,并发的和增强并发的.
 在非并发存取的配置下,在同一时间只有一个节点可以存取共享的存储.如果一个包含共享磁盘空间的资源组移动到另一个节点,那么新的节点会激活磁盘,并检查卷组,逻辑卷和文件系统的当前状态.
 在非并发的模式下,磁盘可以配置共享为:裸物理卷,裸逻辑卷,文件系统.
 在并发存取模式下,存储在磁盘上的数据同时对所有的节点可用.这种模式不支持文件系统.
 快速磁盘切换
 在hacmp5.1中,开发使用了一个新的aix增强并发的LVM,在aix5L5.2中,必须使用增强并发模式去创建新的并发卷组.增强并发的卷组也可以使用文件系统(共享的和非共享的).当发生故障切换的状态时.这可以使快速磁盘切换选项加速共享文件系统的切换.
 增强并发的卷组在资源组中所有节点下被激活,hacmp去调整数据的存取控制.仅仅在激活资源组的节点上激活卷组在"并发的激活状态"模式,其他节点将激活卷组在"被动"模式.在被动模式时,在卷组上不允许有高级的操作.
 注意:当使用了资源组的快速磁盘切换选项,非常重要的就是要有冗余的网络和非ip网络.这可以消除和避免数据的不一致性.
 RAID和SSA并发模式
 RAID并发模式的卷组是陈旧的定义,从增强并发卷组模式提供了附加的性能,但是RAID并发卷组将继续被支持一段时间.raid和ssa并发卷组在hacmp5.1中都被支持但有一些重要的限制:
 并发资源组的增强卷组需要运行64位内核的节点支持.
 ssa的并发模式不支持64位的内核
 ssa磁盘在32位内核模式仍然可以使用ssa并发模式.
 C-SPOC单元不能支持raid并发卷组.你不得不转换这些卷组到增强并发模式(否则,aix视为非并发的卷组).
 在aix5.1中,可能创建一个ssa并发卷组(32位),但在5.2中,不可能创建一个hacmp并行的,所有的新的卷组必须使用增强并发模式.
 LVM需求
 这里叙述了lvm管理的概念.
 强迫激活卷组
 hacmp5.1提供了新的工具,去强制激活节点上的卷组.如果在故障切换的进程中,正常的varyon命令不能激活卷组(lack of quorum),hacmp将确保在接管节点激活卷组前至少每一个Lv有一个有效的LPcopy是可用的.
 强迫性的激活卷组可以让你一直保持资源组中卷组的在线状态并且有一个有效的数据copy.你仅仅可以在卷组包含镜像的逻辑卷时使用这个选项.还要小心的注意到避免创建一个分开的集群.
 注意:你必须指定一个非常严格的lv分配策略来使用这个强制激活的选项.在这种方法下,LVM确定lv的copy总是在分开的磁盘上,可以增加失效时强制激活的成功概率.
 这个选项当一个vg的vgda丢失时的接管是很有用的.如果没有使用这个选项,资源组将不能在接管的节点上激活,因而导致应用的不可用.
 当使用了强制激活选项发生接管时,hacmp首先尝试正常的varyonvg.如果尝试因缺少quorum失效,hacmp在尝试强制卷组在线时首先检查数据的完整性-确定所有数据在卷组中都至少有一个可用的copy.如果是这样,他执行varyonvg -f,如果不能,卷组仍然离线并且资源组有一个错误的报告.
 2.4.3选择磁盘的拓扑
 hacmp5.1支持下列存储的拓扑:scsi,ssa和光纤通道(TastT和ESS磁盘子系统).完整支持的外部存储的列表可以在ibm网站找到.
 hacmp支持下列的ibm 磁盘技术在hacmp中作为外部共享磁盘使用.
 IBM 2105 企业存储服务器
 ibm2105企业存储服务器提供并发的连接和磁盘存储共享在多种开放的系统平台上.除了ibm的p系列服务器机器,许多其他的平台也被支持.
 由于共享存储环境得多平台得支持,为了避免冲突,非常重要得就是配置适当得LUN标记和zone配置来提供安全得数据存取.ESS使用ibm得ssa磁盘技术.ESS提供了内建的可用性和数据保护.RAID技术用来保护数据,同时,磁盘有故障前期分析特性预测将会出现故障.使数据保持可用.ESS事实上有所有的组件冗余避免内部组件损坏而导致故障,从而提供了保护.ess管理两个节点的集群通过内部的高速总线连接到内部的存储(ssa磁盘),每个节点上有精确等同的定义.因此,当内部节点失效,存储对系统仍然有效(可用性).
 更多的信息参考ibm网站.
 一个典型的使用ESS的hacmp集群的例子如下图.

 ibm FastT700和900中等存储服务器
 IBMFatsT900和700存储服务器传输超越磁盘性能和突出的可靠性来为苛刻的应用程序提供良好的计算环境.
 IBMFatsT系列存储子系统是提供好的可测量的,高性能的和数据保护的中等解决方案.在FatsT架构中,虽然不是作为久经考验的ESS实现,仍然提供基于冗余组件(存储控制器,电源支持和存储连接器)的可靠性.
 FastT700和900架构实现了在主机和存储端的本地的光纤通道协议.他不再支持scsi,并且不专注于提供两个控制器之间的高速度,但是提供了控制器的无间断的错误切换和主机端的数据缓存.
 需要完整的信息关于ibm的存储解决方案,请访问ibm的网站.
 典型的FatsT连接的hacmp图示.
 IBM串行存储架构磁盘子系统
 SSA存储架构提供一个更离散组件的解决方案,提供了减少单点故障的特性.
 SSA存储在hacmp环境通过冗余硬件提供了高可用的和电源,磁盘热切换的特性(在线维护).
 SSA存储也提供了RAID在hba(host bus adapter)层.
 注意:如果使用ssa的raid特性,那么hacmp只能连接两个节点.
 ibm的7133子系统能在hacmp中提供并发存取的配置.图示等请参阅7133相关配置.
2.5 软件规划
 在hacmp规划的进程中,很重要的一步就是选择集群节点中软件运行的层次.
 节点软件规划的考虑因素有:
 操作系统需求:aix版本和推荐层次
 应用的兼容性:确保应用的所有需求适合.并且在hacmp环境中支持.
 资源:使用资源的类型(ip地址,存储配置等).
2.5.1 AIX和相关的需求:
 红皮书书写时的推荐层次:
 hacmp版本 aix   aix apars rsct
 5.1  5100-05  IY50579,48331 2.2.1.30或根高.
 5.1  5200-02  IY48180,44290 2.3.1.0或更高
 5.2  5100-06  IY54018,53707
     IY54140,55017 2.2.1.30或更高
 5.2  5200-03  IY56213  2.3.3.0或更高
 最新的信息请参考ibm网站
 下列操作系统BOS选项需要在hacmp之前安装:
 bos.adt.lib
 bos.adt.libm
 bos.adt.syscalls
 bos.net.tcp.client
 bos.net.tcp.server
 bos.rte.SRC
 bos.rte.libc
 bos.rte.libcfg
 bos.rte.libcur
 bos.rte.libpathreads
 bos.rte.odm
 bos.data
 当使用增强并发资源管理,下列组件需要:
 bos.rte.lvm.5.1.0.25
 bos.clvm.enh
 完整的列表,参考ibm网站
2.5.2  应用兼容性
 hacmp是可伸缩的高可用的解决方案,事实上看到的是虚拟的在独立的aix节点上运行的应用.
 当开始一个应用的规划时,需要考虑下面的方面:
 应用兼容性在aix系统的版本上
 应用的兼容性在实现高可用的存储方法上
 你必须知道所有应用和平台相互依赖的东西,应用程序所有的文件分布.
 你必须提供一个无人照料的应用启动和停止的脚本.并且应用可以在错误后恢复启动.
 注意:不要加入在独立节点上就不能正确执行的应用或者你不能确定应用依赖的文件等!!!
 如果你计划使用应用的监控,你应该提供应用的监控工具(方法,行为和脚本).
 应用客户端的依赖.当服务器重启时客户端的行为.
 应用网络的依赖.sockets.route等.
 许可证的问题,如果应用依赖于cpu的id,你应该考虑购买标准的lic在每个节点上,同时,如果应用lic基于处理器个数,那么要确定,当错误切换时,lic不被破坏.
 应用服务器
 依照hacmp的定义,一个应用服务器是hacmp当激活资源组时启动应用和资源组离线时停止应用的脚本的集合.一旦应用启动,hacmp能监视应用,并且当应用运行不正确时执行动作.应用监控可以在进程级,也可以使用定制的方法(例如,一个多处理的进程数据库引擎等.)
 注意:应用监控在hacmp/es4.4中引入,是基于RSCT事件管理的定义.从hacmp5.2开始,事件管理被资源监控和控制(RMC)替代.等价的定义,但是提供了更多的弹性,从5.2开始,也可以去监控应用的启动.
 hacmp也提供了应用可用的分析工具,可以审计所有的应用可用性,用来评估集群的环境.
 需要应用服务器和其他资源的信息,参考128页.
2.5.3规划NFS配置
 hacmp的一个典型的应用就是对客户机和应用服务提供高可用的ha-NFS.这是有用的,特别是集群运行一个相互接管的交叉挂接的NFS.从hacmp4.4开始,ha-NFS已经整合到hacmp中,不再是一个单独的产品.
 使用NFS的一些注意事项:
 在aix中,当你输出文件系统和目录使用mknfsexp时,/etc/exports文件被创建和更新.
 对于要输出为NFS的共享卷组来说,卷组的major number在所有服务文件系统的vg的所有集群节点上是一样的.在hacmp中,文件系统和目录输出为nfs必须在资源组中配置.如果你需要配置这些文件系统的选项,那么需要创建 /usr/es/sbin/cluster/etc/exports文件.
 对于所有输出文件系统的资源组来说,"file system mounted before IP address config"属性必须置为"true".
 hacmp的脚本包括缺省的NFS行为.你需要去改变这些脚本去详细的适合你的配置.在hacmp5.1中,在附加的cascading 资源组.你能配置高可用的NFS,也可一在rotating和定制资源组中配置.
 注意:NFS 锁定功能 限制为两个节点,这个功能提供了可靠的允许备份的进程去恢复当前的NFS行为当主NFS服务失效.保留NFS文件系统的锁定和dupcache.
 2.5.4 授权
 许多的软件卖主需要你的每一个应用在每一台机器上甚至每个cpu有唯一的授权.通常的,lic在软件安装时输入.可是,在hacmp环境中,在切换的状态时,如果应用在另一个节点启动,你必须确定你在新的机器有必须的激活码(lic).否则,应用不能正确的启动.
 应用页可能有唯一的节点绑定的lic(每一个机器上有不同的lic文件).
 一些应用限制限制集群中漂移的应用的lic的数量.要避免这个问题,你许要有足够的lic,这些应用可以同时在多个节点上执行,甚至是并发的应用.
 2.5.5 客户端连接
 当资源组切换时,应用在另一个节点上启动,应用必须知道这个动作.在某些情况下,应用客户端使用arp缓存去连接服务器.在这种情况下,有两种可能得情况:
 1.保留有服务ip得网络使用通过ip置换得ipat实现了本地mac地址得切换(因此,客户端机器arp缓存没有被更新)
 2.hacmp使用clinfo程序调用/usr/es/sbin/cluster/etc/clinfo.rc脚本当事件发生时,缺省得,这个动作更新系统得arp缓存并且指定客户端得arp缓存响应网络得改变.你可以定制这个脚本进一步满足需求.
 clients运行clinfo后台守护进程能在集群事件后快速的连接到集群.
 注意:如果你使用IP别名的IPAT,确保你的客户端支持支持arp刷新功能.
 如果hacmp节点客户端在同一个子网上,客户端不需要运行clinfo,你可以间接的在集群节点上通过ping客户端来刷新客户端的arp缓存.
 你可以在集群节点上通过添加你想要通知的客户端的iplabel和地址到clinfo.rc脚本中的PING_CLIENT_LIST变量.一旦集群事件发生,这个脚本就会运行下面的命令到PING_CLIENT_LIST中的每一个主机: #ping  -cl   $host
 当client在不同的子网时,确保route的arp cache在集群事件时得到更新.否则,客户端在重连时会又预期的延迟.
2.6 操作系统空间需求.
 在hacmp5.1中,包括集群效验程序(clverify)和新的集群通信后台(clcomdES)都需要/var文件系统下附加的空间.
 预期的详细的消息和附加的debug信息,在每个节点的/var下需要满足
 20M.一次,/var/hacmp/clcomd/clcomd.log  2M
  /var/hacmp/clcomd/clcomddiag.log 18M
 附加的:1M*集群中的节点数  存储在/var/hacmp/odmcache 目录下.
 4M每个节点集群的效验数据.
 2M的集群效验log.例如:(就是上面数据的例子)
 在集群的每个节点中,效验单元在/var下需要4M的空间,clverify可以在同一时间保持四份节点效验数据的拷贝(节点初始化和同步时).
 /var/hacmp/clverify/current/<nodename>/*当前执行的效验的日志.
 /var/hacmp/clverify/pass/<nodename>/*最后通过的效验的日志.
 /var/hacmp/clverify/pass.prev/<nodename>/*倒数第二次通过效验的日志.
 /var/hacmp/clverify/fail/<nodename>/*最后一次失败的效验日志.
 同时,/var/hacmp/clverify/clverify.log和她的拷贝代表性的消耗1-2M的磁盘空间.
2.7 资源组的规划
 资源组是一个包含hacmp执行高可用的资源的一个逻辑的单元.资源包括:
 1.存储空间(应用程序的代码和数据)
 -文件系统
 -网络文件系统
 -裸逻辑卷
 -裸的物理磁盘
 2.服务ip和labels(客户端连接应用)
 3.应用服务器
 -应用启动的脚本
 -应用停止的脚本
 要通过hacmp实现高可用,每一个资源都必须包含在资源组中. 
 hacmp在集群事件时达到要改变的情形通过在节点间移动资源组来确保集群资源的可用性.hacmp在下列状态时控制资源组的行为:
 集群启动
 节点失效
 节点重组
 集群关闭
 在上述的每一个集群的阶段,hacmp的资源组的行为定义为:
 当节点,或者几个节点在集群启动时需要资源组
 当拥有资源的节点失效时接管节点接管资源组时
 不管资源组恢复倒刚刚发生故障而恢复的节点,还是当前拥有的节点.
 集群中的节点优先级关系决定了哪一个节点最初控制资源组并且当一个最初的节点在失效后重新加入集群接管对资源组的控制.
 资源组接管关系定义为:
 层叠式的.轮转的.并发的.定制的.
 层叠的,轮转的和并发的资源组是在5.1以前的类型.因为定义这些类型的难于理解,新的定制类型资源组在hacmp5.1中引进.
 这里仅仅有一个常化hacmp术语和让hacmp的概念容易理解的步骤.从hacmpV5.2开始,仅仅有定制资源组存在.
 2.7.1层叠式资源组
 层叠式资源组定义了一个所有可以控制资源组的节点列表并且每一个节点有一个托管资源组的优先级.
 一个层叠式资源组的行为如下:
 在集群启动时,层叠式资源组在缺省的节点上激活(资源组的最高优先级的节点上).
 附加的,另一个称为"无活动的接管"属性的可以用来指定如果高优先级的节点在集群启动时不可用的时候在低优先级的节点上激活.
 当一个节点失效时,一个层叠式资源组在资源组优先级列表中的下一个节点上激活.
 附加的,可以指定"动态节点优先级"失效切换的进程将根据动态的属性(高cpu空闲等)确定接管资源组的节点.
 当失效节点重新接入集群,层叠式资源组将重新切换到缺省的节点上.
 附加的,可以指定"层叠不需要回退",资源组将依然保持在接管节点上即使一个高优先级的节点重新接入集群.
 总结一下,层叠式资源组有下面的属性.
 就是上面附加的三点,添加了在最后的属性中,可以手动的移动资源组在合适的时候.
 2.7.2 轮转式资源组
 对于一个轮转式资源组来说,节点的优先级列表仅仅用来决定哪一个节点来接管失效的节点.
 在集群启动时,第一个可用的节点将激活资源组,一旦在一个接管的节点上激活,她不会切换回高优先级的节点即使高优先级节点重新可用.没有动态的节点优先级可用.当配置多个轮转的资源组在同一个节点上,为了控制首选的资源组的定位,每一组都要从节点群中分配一个不同的高优先级节点.当集群启动时,每一个节点将尝试去获取她自己有高优先级的资源组.
 如果所有的轮转资源组已启动,新节点的加入仅仅作为这些资源组的后备节点.如果所有的资源组都没有激活,新加入的节点将仅仅去获得这些资源组的一个.其他的资源组仍然保持非激活状态.
 无论如何,如果多个网络存在,一个节点可能获得多个资源组.每一个网络上一个.
 2.7.3 并发的资源组
 和名称一样.一个并发的资源组可以在多个节点上同时激活,当集群启动时,资源组将在列表的所有节点上激活,没有顺序.
 对并发资源组来说,没有节点间的优先级,他们是平等的节点,如果一个节点失效,其他的节点仍然一样提供服务,资源组不能被移出.
 附加的并发软件可能是必须的去管理并发的存取应用的数据.
 2.7.4 定制资源组
 为了简化资源组的管理和理解,hacmpV5.1引入了定制资源组的类型.资源组指定的名称可能会使新的用户(层叠,轮转和并发)混淆.
 1.他们不能清晰的指出潜在的资源组的行为.
 2.附加的资源组参数将进一步使定义资源组变得复杂:层叠的两个参数(1.2.)
 同时,在一些情况下,用户需要联合一些行为,他们不是被标准的rg定义的.
 hacmpV5.1引入了定制的资源组
 -用户必须明确的指定启动的需求,切换和回来的行为.
 -RG启动和切回能通过用户设定和FAllback计时器控制.
 -RG接管也可以通过用户的定义动态节点优先级影响.
 局限性:(仅仅hacmpV5.1)
 -定制资源组仅支持IPAT-via-别名服务ip的标签和地址.
 -没有站点和复制资源(hacmp-XD)支持.
 启动参数选择
 -online ON home node only:在节点启动时,RG将仅仅使得高优先级的节点在线,这个行为等价于层叠RG行为.
 -online on first available node:在节点启动时,RG将在第一个节点上激活,这个行为等价于rotating RG或者cascadingRG with 非活动的接管.如果一个设定的时间配置了,她将影响RG的这个行为.
 online on all available nodes:RG将在资源组的所有节点上激活.这等价于并发的rg行为.这个启动参数将不考虑某些fall-over和fall-back参数.
 fallover 参数选择
 -fallover to next priority node in the list:RG将切换到下一个可用的节点上.这个行为等价于cascading和rotatingRG.
 -fallover using dynamic node priority:RG将基于DNP计算结果去切换,资源组必须指定DNP的优先级.
 -bring offline(仅仅在错误的节点上):RG在错误时不发生切换,而是简单的置为离线.这个行为大部分的类似于并发的资源组.
 fallBACK 参数选择
 -fallback to higher priority node:RG 将在一个节点重新可用时切换倒高优先级的节点上.这个行为等价于层叠的资源组的行为.一个fall-back计时器将影响这个行为.
 -never fallback:资源组将待在她在的地方,即使一个高优先级的节点重新在线.这个行为类似于rotatingRG的行为.
 2.7.5 应用监控.
 作为一个附加的资源组管理方面,hacmp也能通过下列两种方法监控应用:
 -应用的进程监控:探测死进程,使用RSCT事件管理能力.
 -应用定制的监控:基于自定义的监控方法(程序或脚本)监视应用的健康状态.
 注意:你不能使用应用进程监控一个shell脚本启动的应用,或者应用的进程对应用来说不能反映应用的健康状态.
 要监控一个shell脚本的应用,你将不得不定制监控的方法(例如,Apache web server).
 当应用监控是激活状态时,hacmp有下列的行为:
 -对应用监控进程来说,一个通知集群管理器的内核的钩子监控倒进程已经死掉的话,集群开始应用的恢复进程.
 当恢复的动作执行时,你必须提供一个方法清除和重新启动应用(定义的应用起停的脚本可能会用上).
 hacmp在发送警告信息或者移动到另一个节点前会尝试重新启动应用和等待应用稳定一段时间.
 -对于定制应用监控(定制的方法)除了应用清理和重新启动的方法,你还必须提供一个程序或者脚本用来执行一个周期的测试.
 去规划和配置一个进程的监控,检查下列方面:
 -检查应用是否能被进程监控.
 -指定和核查要监控的进程的名称,在配置应用监控时必须强制的使用准确的进程名称.
 -指定要监控的应用的实例数(进程的数量).缺省的值是一个实例.
 -指定开始监控等待的时间(秒).
 注意:在很多情况下,这个值不能设为零.例如,在一个数据库应用中,你希望延迟一些监控知道启动脚本和初始化数据库完成.
 -重启的计数,表示在执行其他动作时尝试去重启应用的次数.
 -间断(秒).是应用在重新设置重启计数前保持稳定的时间.