IK000203 HPUX双机ISSUE10Word格式.docx
《IK000203 HPUX双机ISSUE10Word格式.docx》由会员分享，可在线阅读，更多相关《IK000203 HPUX双机ISSUE10Word格式.docx（23页珍藏版）》请在冰点文库上搜索。
本课程的主要内容如下：
HP群集系统介绍。
课程目标
完成本课程的学习后，您应该能够：
●了解HP群集系统的组成
●了解HP群集系统的工作原理
●掌握HP群集系统的配置
●掌握HP群集系统的维护
相关资料
《HPMC/SGconfigration》
《HP_MCsgcommand》
《HP_ManageMC》
第1章HP群集系统简介
1.1概述
在HP-UX操作系统平台上，可使用MC/ServiceGuard来创建高可用性的计算机系统，也称之为群集系统。
MC/ServiceGuard群集系统由一组联网的HP9000服务器（称之为节点的主机系统）组成，最大可支持16个节点，具有软硬件的冗余。
但共享SCSI设备最多同时被连接（物理上）到四个节点上（所以这种情况下实际上，一个package的后备节点最多配3个）。
但使用光纤接口的共享设备或其他不使用共享总线的设备能同时被连接到16个节点上（在这种情况下实际上，一个package可以配置成在16个节点间切换，当然，对于我们热双机，都是访问本地数据，不访问共享设备，可以配置成package在任意多个节点间切换）。
当其中某个节点出现故障时，MC/ServiceGuard可以自动把该节点中的应用程序包的控制权转移到其他的节点来控制。
应用服务（单个的HP-UX进程）形成packages。
只要packages中的单个进程出现失败，就会被MC/ServiceGuard所侦测到，MC/ServiceGuard就会将包的控制权转移到Cluster中的其他节点上，使package中的服务得以延续。
典型的群集系统配置如图1-1所示：
图1-1典型群集配置
在上图中，节点1中运行包A，节点2中运行包B。
每个节点都有单独的磁盘与之相关联，其中包含有应用程序包所需的数据和这些数据的镜像。
当package发生转移后，你可以配置成一旦该package的主用节点online后，该package立即切回，当然也可以配置成必须手动切换。
说明：
两个节点都与两组镜像磁盘有物理连接，但一次只能有一个节点存取指定磁盘组中的数据，在图1-1中，实线表示有独占访问权，虚线表示有物理连接，但没有访问权限。
MC/ServiceGuard被设计成要同其他HP的ha产品配合使用。
比如MirrorDisk/UX、EMS、RAID等。
为了提供高可用性，典型的Cluster使用具有冗余功能的系统组件。
主要是为了消除单点失败。
除了硬件上的冗余外，还必须具有能控制冗余硬件间的切换的软件，MC/ServiceGuard提供如下支持：
●如果LAN失败，MC/ServiceGuard切换到备用网络（如备用网卡）或备用节点。
●如果SPU失败，应用自动在最短的事件内从失败的SPU切换到可用的SPU上。
●其他资源，如磁盘接口失败，package能被移到另外一个节点上。
●若软件失败，应用能在同一个节点或在另外一个节点被重启。
通过不同电缆连接的网络硬件，可在两个节点上提供冗余的网络接口。
MC/ServiceGuard使用TCP/IP网络服务在群集的节点间提供可靠的通信。
在创建应用程序包时，可指定一个主节点和一个代管节点，在正常情况下，MC/ServiceGuard群集检视每个节点的运行情况，当某个节点或网络通信出现故障时，MC/ServiceGuard可以把对此应用程序包的控制转换给代管节点，如图1-2所示：
图1-2故障转换后的群集
包含两个节点的群集系统，通常又称为双机系统。
以下篇幅中介绍的群集系统，未作说明的，即默认为双机系统。
1.2群集系统的组成
1.2.1硬件组成
为了提供高级别的可用性，群集系统使用冗余的系统组件，如两个或多个SPU和两个或多个独立磁盘。
通常来说，冗余越多，出现故障时，访问应用程序、数据的可靠性也就越大。
1.冗余的网络组件
群集系统访问的各个子网都要求有冗余的网络接口，为了防止电缆出现故障，还需要冗余电缆。
在双机系统中，每个节点都至少配备有三块以太网卡，分别为主网卡、备网卡和心跳网卡
注意：
其实，心跳网卡是可选的，因为主用网卡本来就可以传送心跳信号。
冗余的心跳信号就是由主用数据网卡和专门的心跳网卡提供。
由于心跳信号同时被主用网卡和心跳网卡传送，所以本地的切换是不需要的。
如果主用网卡数据拥塞，心跳网卡将阻止心跳失败的诊断。
即这种情况下，并不认为心跳失败）。
备用网卡作为主网卡的备份，当主网卡通信出现故障时，备用网卡便对主网卡的IP地址和通信任务进行接管（由MC/ServiceGuard侦测到并控制切换），使该节点的通信得以继续（主用网卡有IP地址与之绑定，备用网卡没有IP地址与之绑定）；
心跳网卡传递双机间的心跳信息，用来监测对方节点的当前状况，备用节点因此能够决定是否对主节点进行应用接管动作。
需要注意的是，应尽量保证数据网卡的数据量不是很大，以防止如果心跳网卡失败后，心跳信号传输不充分。
MC/ServiceGuard也支持用RS232串口线仅仅传输心跳（仅限于两个节点），作为一个备用的心跳途径。
如果这样配置了，MC/ServiceGuard会同时传送心跳信号在串口线和被配置了可传心跳的LAN上。
即便是在串口上配置传心跳信号，但LAN配置成传心跳仍然是必需的。
因为串口线可以弥补LAN的拥塞，但无法作为LAN失败的后备，因为MC/ServiceGuard要求TCP/IP作为Cluster中的节点间的私有通信。
如果一个节点的两个网卡都失败了，串口线传输心跳信号能够保持Cluster处于启动状态，并让MC/ServiceGuard有足够的事件侦测到LAN的失败，让健康节点处于保持状态，并接管所有的packages，然后将该节点失败掉。
主用网卡和心跳网卡的IP地址应该分布在两个不同的物理网段中。
如果每个节点中的网卡多于三块，也可以为心跳网卡配置备份网卡，或为主用网卡配置多个备用网卡。
在MC/ServiceGuard中，IP地址分为固定IP和浮动IP，其中固定IP又分为心跳IP和非心跳IP，它们的区别如表1-1所示：
表1-1IP地址的划分
固定IP
心跳IP
只能在一个节点中使用，但可以在主备用网卡间切换；
可以传送心跳信息和其他数据信息
非心跳IP
只能在一个节点中使用，但可以在主备用网卡间切换，不能传送心跳信息，只能传送其他数据信息
浮动IP
可以在两个节点之间以及主备用网卡间切换
2.冗余的磁盘存储器
群集系统中的每个节点都有自己的根磁盘，但各个节点还与其他的磁盘建立物理连接。
这种方式使多个节点都可以获取与此节点配置的应用程序包相关的数据和程序的访问权。
一个磁盘卷组同时只能由一个节点激活，但在应用程序包的控制权发生转移时，此卷组可由代管节点激活。
通过使用磁盘镜像或RAID实现数据保护。
1.2.2软件组成
MC/ServiceGuard的软件体系机构如图1-3所示：
图1-1MC/ServiceGuard软件结构
MC/ServiceGuard由以下三个核心部分组成：
（1）程序包管理器
程序包管理器又称之为程序包协调程序，主要完成以下功能：
●确定运行、停止和移动程序包的时间和地点；
（packagecoordinator的功能）
●执行用户定义的控制脚本来运行和停止应用程序包和服务；
（其余节点的功能）
●对处于监视下的资源状态的改变做出反应。
补充：
在Cluster中的每一个节点都会运行一个程序包管理器的实例。
在Clustercoordinate的节点上运行的实例被称为packagecoordinator。
一个package在Cluster启动时在适当的节点上启动，在packagecoordinator在一个新的节点上初始化package的启动时package失败切换。
决定何时和哪儿去运行和停止packages：
每一个package通过package配置文件单独配置。
可以通过sam或手工修改。
这个文件指定package的名字以及该package能够运行的节点列表，并表示其优先权（例如，在列表中的第一个节点具有最高的优先权）。
另外，PACKAGE_SWITCHING_ENABLED
、FAILOVER_POLICY、FAILBACK_POLICY三个参数决定package的切换行为。
描述如下：
●package的切换：
PACKAGE_SWITCHING_ENABLED参数在Cluster启动时定义package的全局特性，即：
在失败发生时，package是否应该自动在一个新的节点上重起，和在Cluster启动后，该package是否应该自动被启动。
一旦Cluster处于运行状态，每一个package的该特性能够被cmmodpkg所修改。
（即该特性是可以随时被设置的）
●失败切换策略：
package管理器选中哪一个节点去运行package的依据是package配置文件中的节点列表的优先权和FAILOVER_POLICY参数。
失败切换策略支配package管理器怎样去选择哪一个节点运行package，这个节点可能并没有被识别。
这不仅适用于切换，而且适用于package的启动或初始化启动。
FAILOVER_POLICY可选选项为CONFIGURED_NODE（缺省）和MIN_PACKAGE_NODE。
如果CONFIGURED_NODE是所选参数，package将在节点列表中有效节点中的优先权最高的节点启动，当失败切换发生时，package将移到下节点列表中下一个优先权最高的节点上运行。
如果MIN_PACKAGE_NODE是所选参数，package将在目前运行其他packages最少的节点上启动。
注意，这里说的package的个数最少的节点，而并不是最轻负载的节点。
●切回策略：
FAILBACK_POLICY参数决定当主节点重新可用，但package现在没有运行在主节点上，是否允许package切回原主节点。
可选的参数是AUTOMATIC和MANUAL。
（2）群集管理器
用户初始化群集，监视群集的状态，在出现节点故障时加以识别，当有节点加入或离开群集时，对群集进行重组。
群集管理器作为一个监护进程存在运行于每一个节点上。
在群集启动或重组时，一个节点被选中作为Clustercoordinator。
虽然所有的节点执行一些群集管理的功能，但Clustercoordinator节点是节点间相互通信的中间点。
配置Cluster：
系统管理员配置Cluster的参数并使Cluster初始化成功。
从那以后，在普通的操作中Cluster就直接规范自己，并不需要人为干预。
配置参数包括Cluster名、节点名、传输心跳的网络参数、Cluster锁盘信息和时间参数。
这些参数可以通过sam或一个ASCII的模板文件来配置。
你输入的这些参数用于建立一个二进制的配置文件，并传播应用到这个群集的所有节点中去，并且每个节点的配置参数必需相同。
群集管理器运行的核心是在群集的节点之间发送和接收心跳信息。
Cluster中的每个节点通过固定IP或串口线发送心跳信号给Clustercoordinator（注意：
并非各节点相互乱发心跳信号一气）。
Clustercoordinator守候着各个节点发过来的心跳信号，如果在规定的时间内没有收到心跳信号，Cluster将会重建。
在重建的最后，组成Cluster的节点信息将会传递给packagecoordinator。
在新的配置中，在新的Cluster中将消失的节点上运行的package将转移到它的后备节点上。
注意，如果只是短时间的心跳信号丢失，新组成的Cluster中的节点可能和以前的一样，在这种情况下，packages将不会宕掉或切换，虽然在重建的过程中应用将经历短暂的性能影响。
如果心跳和数据通过同样的子网传送，数据的拥塞可能导致心跳的拥塞从而使得不必要的Cluster重建。
为了防止这种情况，推荐采用专门的网络或rs232用于传送心跳信号。
专门用于传送心跳的网络不是必需的，但应该事先对可能潜在的心跳信号丢失作一个分析。
多重的心跳信号的传送是并行的。
所以推荐所有的子网都配置成能传送心跳信号，这样可以不增加额外的耗费但能增加Cluster的容错性。
每个节点发送心跳信号的频率都是一定的，都在配置文件中所配置。
自动Cluster重起：
自动Cluster重起在Cluster中所有节点都失败的情况下发生。
这种情况通常是电源失败或所有的SPU失败。
为了达到这个目的，所有节点的配置文件都在生效中、或在试图正在形成一个Cluster中、并能够相互通信。
如果在/etc/rc.config.d/cmcluster文件中的AUTOSTART_CMCLD标志被设置为1，即可实现这个功能。
重建不等于重配置。
重建只是可能发生故障后的一个临时的情况。
Cluster的Quorum在重建中的应用：
Cluster将严格重建在原来运行节点的超过50％的节点上。
但是实际上，50％的节点就可以形成一个新的Cluster，那就必需要阻止另外50％的节点重组为Cluster。
这种情况下，就需要一个tie-breaker。
例如两节点的Cluster，如果两节点的通信失败，则两个节点都将试图重组Cluster，这时MC/ServiceGuard仅仅允许一个节点重组成功，这个可以通过使用Lock来实现。
ClusterLock（锁盘）的使用：
ClusterLock是给两个节点共享的volumegroup中的磁盘区。
ClusterLock的卷组名和物理卷名在Cluster配置文件中指定。
锁盘仅仅在一个Cluster失败了的场合下作为一个tie-breaker之用。
因为MC/ServiceGuard试图去形成一个新的Cluster，Cluster将被分割成两个规模相同的子Cluster。
每一个子Cluster都试图去获取锁盘，获得锁盘的子Cluster将形成新的Cluster。
如果两个子Cluster是不同的规模，则超过50％节点的子Cluster形成新的Cluster，此时锁盘无用。
两节点的Cluster，必需配置Lock。
在重组后，没有加入新Cluster的节点将会shutdown。
注意，如果在Cluster试图获取Lock时，Lock失败了，Cluster将会halt。
注意：
尽量让锁盘使用独立电源供电，不要同任何一个节点共用电源，目的是为了不让其中一个节点电源失败后导致锁盘电源失败，从而导致整个Cluster失败。
如果要让锁盘和节点共用电源，则需要配置双锁盘。
尽量要在3个或3个以下节点组成的Cluster中使用锁盘，但4个节点组成的Cluster，锁盘通常是不需要的。
因为这种情况下，被分割成同样规模大小的子Cluster的机会很微小。
而4个以上节点组成的Cluster中锁盘是不允许存在的。
Lock的卷组和物理卷被创建以后，尽量使用vgcfgbackup命令备份其信息，以后可以在更换Lock后用vgcfgrestore命令恢复其信息。
（3）网络管理器
网络管理器的目的是检测网卡和电缆故障，并从中恢复，以便保持高可用性的网络服务。
实际上，意思就是分配给每一个package的当前运行节点的主用网卡一个IP地址，并监控所有网卡的健康（及时备用网卡故障也会被检测出来），必要时进行切换。
固定和浮动IP地址：
每一个节点在其激活的网卡上都应该被分配一个固定IP地址，配置在/etc/rc.config.d/netconf文件中。
固定IP地址不会在节点间切换，但是可能在主备用网卡之间切换。
固定IP地址并不和package发生联系，但用于传送心跳信息和数据信息。
除了固定IP以外，通常需要给每一个package分配一个或多个单独的IP地址（比较怪的概念：
一个package可以被分配多个浮动IP地址）。
packageIP地址在package启动时由package控制脚本中定义的cmmodnet命令分配到主用网卡。
与package相联系的IP地址称为浮动IP地址（也称为packageIP地址），因为该地址可以在一个Cluster中的各个节点间切换。
你可以在一个Cluster中超过30个package上使用200多个浮动IP地址。
一个IP地址像一个虚拟主机IP被分配给package。
推荐通过DNS分配给package浮动IP。
浮动IP和固定IP同样都可以在主用网卡失效的情况下迁移到备用网卡上，而且浮动IP可以被package切换到的节点所接管，即可以在不知道package在哪个节点上，应用就可以通过浮动IP访问到package。
浮动IP同样是在package的控制脚本中用cmmodnet命令来控制在package启动时分配，停止时删除。
IP地址可以仅仅分配给主用网卡，备用网卡不分配IP地址，但多个IP在同一个网卡上必需被分配在同一个子网中（即主用IP和浮动IP必需在同一个子网中）。
同一个节点上的多个服务可以共用一个IP地址，但如果一个服务移到新的节点上，其他的服务也会被移动（因为共用的IP迁移了）。
可以给每个服务一个package，这样每个服务都有一个package，拥有一个单独的IP，可以达到负载均衡的目的。
监控网卡和侦测失败：
按照一定的间隔，MC/ServiceGuard将会轮询所有Cluster配置文件中指定的网卡（应该只是本机网卡，不包括另一个节点的网卡）。
网络失败是这样被检测到的：
在桥接网络中的一个网卡被指定为轮询者，这个轮询者将会轮询所有的主用和备用网卡看是否健康。
通常，轮询者是一个备用网卡，如果没有备用网卡在桥接网络中，主用网卡将被指定为轮询者。
轮询者发送LAN包到所有在桥接网络中的其他网卡并接收他们的相应，如果一个网卡不能接收或发送信息，并且这个网卡在一定时间内发送和接收的信息包并没有增加，这个网卡被视作失败（当然这样网线和hub的失败都能被检测出来，当作网卡失败同样对待）。
本地切换：
本地切换包括失败的检测以及网卡间的切换，备用网卡一定不能有IP地址。
发生本地切换时，对于以太网的TCP/IP连接不会丢失（但IEEE802.3会丢失）。
以太网、令牌环、和FDDI使用ARP协议，并且HP－UX发送一个主动提供的ARP消息去通知远端主机IP地址和MAC地址新的对应关系。
但IEEE802.3并不具有rearp功能。
在转换过程中，IP包会丢失，但是tcp会重传包。
但udp就不会自动重传了，由于udp本来就是不可靠的协议，所以在应用层应当考虑进去如何对付这种情况。
注意，本地切换只支持在同种网卡间的切换。
远端切换：
远端切换包括移动package和相联系的IP地址到新的系统上。
远端切换过程中，tcp连接会失败，tcp的应用需要去重连以获得连通性，并且这不能被自动处理。
当一个浮动IP移到新的网卡上，不管是本地还是远端，都会有一个ARP信息广播以通知其他主机更新IP地址与mac地址的映射。
目前，arp信息在IP地址被加到新网卡上后发送，并以arp请求的格式发送，发送和接收方的arp请求消息的协议地址域都被填入同一个浮动IP地址，这样可以确保接收到信息的节点不会反馈响应消息。
1.3失败的响应流程
MC/ServiceGuard对于不同的失败做出不同的响应。
对于大多数的硬件失败，响应通常不是用户所能配置的，但是对于package和service的失败，你可以有限地选择系统的响应。
当节点失败时转移控制（TOC）：
在一个MC/ServiceGuardCluster中最值得注意的失败响应是HP-UXTOC，TOC是一个非正常关机的SPU立即失败响应（外观看起来就像是立即重起了）。
TOC用作保护你数据的完整性。
如果内核挂起、内核失败、实时进程处理的失败、MC/ServiceGuard进程cmcld失败将会导致TOC。
在这些事件中，一个系统dump将被完成，并在console上输出以下信息：
MC/ServiceGuard：
Unabletomaintaincontactwithcmclddaemon.
PerformingTOCtoensuredataintegrity.
一个TOC也可能在特定的环境下被MC/ServiceGuard自己所初始化。
如果service的failfast参数在package配置文件中设为enable，不管指定service任何失败都会导致节点全部失败并作TOC，如果package的failfast参数（NODE_FAIL_FAST_ENABLED）在package的配置文件中设置为enable，任何导致package控制脚本exit的错误都会导致整个节点失败并作TOC。
另外，与package和service无关的事件也可能导致节点级的失败。
心跳信号的丢失（所以有时候心跳信号丢失了，有一个节点会重起）、MC/ServiceGuard或其他关键守护进程的丢失都可能导致节点失败。
在一些情况下，试图重起可能会优先于TOC，如果在安全极限时间内完成重起，则不会作TOC，否则，package将会很快地移到另外的节点上去。
硬件失败的响应：
硬件失败被MC/ServiceGuard侦测到，通常是切换package。
如果网卡失败，会作一个本节点的切换，但如果心跳网卡失败，并且没有配置备用网卡，这个节点将会作TOC的失败，如果数据网卡失败，并且没有配置备用网卡，当package的failfast的参数enable时，节点作TOC的失败。
MC/ServiceGuard并不直接响应电源的失败。
尽管一个单独的组件的电源失败看起来像是组件失败，但只是导致适当的切换。
电源依靠hp的其他供电设置来保护，包括磁盘也是由其他装置如MirrorDisk/UX或EMS来保证。
Package和Service失败响应：
缺省情况下，一个package或package中的service失败将导致运行该package的节点运行带stop参数的控制脚本来shutdown，并且在代替节点上重起。
如果包管理器收到ems的资源失败的事件报告，则该package失败。
网络通信失败响应：
网络的健康是Cluster的一个重要因素。
每一个节点停来自其他节点的心跳信息，以确保所有的节点能相互通信。
如果一个节点在指定的事件内不能听见这些信息，节点超时发生了，将会导致一个TOC。
在含有两个节点的Cluster中，RS232可以阻止心跳信号暂时丢失引起的TOC。
1.4群集系统的配置
1.4.1配置前的规划
建立一个群集系统，应从规划阶段开始，在此阶段需要收集所有的硬件、软件信息。
规划阶段主要完成以下工作：
1.一般规划
在该阶段必须明确群集系统所要达到的高可用性的目标和要求，如哪些应用程序必须在故障时仍继续可用；
需要哪些系统资源来支持这些应用；
如何将资源分配到群集中的节点上等。
如果今后希望
升级会员 