PowerHA完全手册.docx
《PowerHA完全手册.docx》由会员分享，可在线阅读，更多相关《PowerHA完全手册.docx（126页珍藏版）》请在冰点文库上搜索。
PowerHA完全手册
PowerHA完全手册
（一）
前言
自2008年4月02日笔者在IBMDevelopWork网站首次发表《HACMP5.X完全手册》以来，加上各网站的转载，应该已过了10万的阅读量，在此非常感谢大家的认可和支持。
转眼已经5年过去了，期间非常感谢不少同仁指出了该文的各种不足，并且HACMP已经改名为HACMP了，由于软件版本的更新和本人当时的技术水准有限，同时也存储不少同仁的希望，在原文基础上进行了补充和修订完善，也就有了本文。
正是由于AIX专家俱乐部的兴起，对AIX和HACMP的技术感兴趣的技术人员又更多了。
因此选择本杂志作为原创发表，就是希望能对更多的同仁日常工作有所帮助。
此外，虽然本文号称“完全手册”，一是为了吸引眼球，二也只是相对于其他只谈安装配置的文档而言。
由于HACMP现在已相当复杂，本文范围也主要关注于最常用的双节点，还望大家谅解。
即便如此，本文篇幅可能仍然较长，虽然也建议大家先通读一下，但实际使用使用时可根据具体目的按章节直接查阅操作。
这是因为一方面本文所述操作笔者都加以验证过；一方面也是全中文，省得大家去查一大堆原版资料。
希望能帮助大家在集成和运维HACMP的过程中节省精力、降低实施风险，这也是本文编写的初衷。
同时还望那些被部分摘抄文章的同仁也能理解，你们都是笔者的老师，这里也一一谢过。
虽笔者端正态度，尽力认真编写，但由于能力有限，恐仍有错漏之处，还望众多同仁多多指正海涵，在此先行谢过。
1. 为什么需要PowerHA/HACMP
随着业务需求日益增加，IT的系统架构中核心应用必须一直可用，系统必须对故障必须有容忍能力，已经是现代IT高可用系统架构的基本要求。
10年前各厂商现有的UNIX服务器就已拥有很高的可靠性，在这一点上IBM的Power系列服务器表现尤为突出。
但所有UNIX服务器均无法达到如原来IBM大型主机S/390那样的可靠性级别，这是开放平台服务器的体系结构和应用环境所决定的，这一点，即使科技发展到云计算的今天仍然如此。
因此，我们需要通过软件提供这些能力，同时这个软件还应该是经济有效的。
它可以有效确保解决方案的任何组件的故障都不会导致用户无法使用应用程序及其数据。
实现这一目标的方法是通过消除单一故障点消除或掩盖计划内和计划外停机。
另外，保持应用程序高可用性并不需要特殊的硬件。
IBM高可用性集群软件--PowerHA/HACMP也就应运而生，即使到了今天，对比x86平台的linux、windows甚至包括其他UNIX操作系统的高可用性集群，至少从笔者20年的IT从业实际经历来看，IBMPowerHA/HACMP高可用性解决方案虽然复杂，需要更高水平工程师的精心维护，但的确相对更成熟更有效。
PowerHA的前身为HACMP，或者说PowerHA和HACMP这两个词对IBM来说可以互换使用。
基于这一点，也由于实际使用过程中PowerHA软件的名称、菜单名、日志等均仍为HACMP，因此后面论述时我们仍均称为PowerHA为HACMP，以免造成理解的困难。
2. PowerHA的版本
由于IBM对软件的整合，目前PowerHA其实不仅仅只包含之前的HACMP软件，我们先来看看下图：
大家可以看到，我们通常的HACMP其实现在准确名称是 PowerHA SystemMirror ，它有2个平台4个主要大版本，for AIX ，i系统；企业版和标准版；企业版扩展了异地容灾相关的功能；而其他小版本，则是在其企业版和标准版基础之外的支持；比如最近比较热的PowerHA SystemMirror HyperSwap®的数据中心双活的解决方案 ，就是利用HyperSwap版本对存储DS8000容错的扩展支持来得以实现。
我们说的PowerHApureScale，则是和类oracleRAC的IBMDB2pureScale解决方案相配合的高可用性套件，不再是我们通常意义上的HACMP。
由于本文的重点为AIX的本地高可用性，因此除非特别声明，我们缺省说PowerHA时都是指PowerHASystemMirrorStandard的版本。
3. HACMP的工作原理
HACMP是HighAvailabilityClusterMulti-Processing的缩写；也就是IBM公司在P系列AIX操作系统上的高可靠集群软件，配置冗余，消除单点故障，保证整个系统连续可用性和安全可靠性。
HACMP是通过侦测主机及网卡的状况，搭配AIX所提供的LVM等管理功能，在主机、网卡、硬盘控制卡或网络发生故障时，自动切换到另一套备用元件上重新工作;若是主机故障还切换至备机上继续应用系统的运行。
作为双机系统的两台服务器同时运行HACMP软件；
◆两台服务器的备份方式大体有二种:
⏹一台服务器运行应用，另外一台服务器做为备份
⏹两台服务器除正常运行本机的应用外，同时又作为对方的备份主机;
◆两台主机系统在整个运行过程中，通过"心跳线"相互监测对方的运行情况（包括系统的软硬件运行、网络通讯和应用运行情况等）;
◆一旦发现对方主机的运行不正常（出故障）时，故障机上的应用就会立即停止运行，本机（故障机的备份机）就会立即在自己的机器上启动故障机上的应用，把故障机的应用及其资源（包括用到的IP地址和磁盘空间等）接管过来，使故障机上的应用在本机继续运行;
◆应用和资源的接管过程由HACMP软件自动完成，无需人工干预;
◆当两台主机正常工作时，也可以根据需要将其中一台机上的应用人为切换到另一台机（备份机）上运行。
4. HACMP术语：
为方便大家阅读，我们这里简单介绍一下HACMP主要术语。
它们可以分为拓扑组件和资源组件两类。
拓扑组件（Clustertopology）基本上是物理组件。
它们包括：
∙节点（Nodes）：
运行AIX操作系统的Power服务器上的分区或微分区。
实际目前节点现分为2种，一个是服务器节点（Server节点），运行核心服务和共享磁盘的应用的机器；一个是客户端节点（Client）节点，前台使用集群服务的应用的机器。
比如中间件软件等无需共享磁盘安装在客户端节点的机器上，数据库软件安装在服务器节点的机器上。
像监控节点的信息收集程序clinfo就是只运行在客户节点上。
而对于2个节点的集群，则简化掉这些分别，即节点为二合一。
∙网络（Networks）：
IP网络和非IP网络
∙通信接口（Communicationinterfaces）：
以太网或令牌环网适配器
∙通信设备（Communicationdevices）：
RS232或磁盘的心跳机制
拓扑组件示意图
资源组件（Clusterresources）是需要保持高可用性的逻辑实体。
它们包括：
∙应用服务器（Applicationservers）：
它涉及应用程序的启动/停止脚本。
∙服务IP地址（ServiceIPlabels/addresses）：
最终用户一般通过IP地址连接应用程序。
这个IP地址映射到实际运行应用程序的节点。
因为IP地址需要保持高可用性，所以它属于资源组。
∙文件系统（Filesystems）：
许多应用程序需要挂载文件系统。
∙卷组（Volumegroups）：
许多应用程序需要高可用的卷组。
所有资源一起组成资源组实体。
HACMP把资源组当作单一单元处理。
它会保持资源组高可用性。
资源组件示意图
此外，还存在资源组有与其相关联的策略。
这些策略包括：
1.启动策略（Clusterstartup）：
这决定资源组应该激活哪个节点。
2.故障转移策略（Resource/Nodefailure）：
当发生故障时，这决定故障转移目标节点。
3.故障恢复策略（Resource/Noderecovery）：
这决定资源组是否执行故障恢复。
当发生故障时，HACMP寻找这些策略并执行相应的操作。
5. 实验环境说明：
以双机互备中相对复杂的多业务网络的情况为例，其他类似设置可适当简化。
1） 机器一览表
节点机器名
操作系统
应用软件
HA版本
host1
AIX6.1.7
ORACLE11g
HA6.1.10
host2
AIX6.1.7
TUXEDO11
HA6.1.10
2） 磁盘和VG规划表
节点机器名
磁盘
VG
VGMajorNumber
host1
hdisk2
host1vg
101
host2
hdisk3
host2vg
201
3） 用户和组规划表
用户
USERID
组
组ID
使用节点
orarunc
610
dba
601
host1
tuxrun
301
tux
301
host1
bsx1
302
tux
301
host1
xcom
401
dba
601
host1
orarun
609
dba
601
host2
4） 逻辑卷和文件系统规划表
PPsize:
128M
节点机器名
逻辑卷
文件系统
大小（pp）
所有者
用途
host1
ora11runclv
/ora11runc
40
orarunc
ORACLE客户端软件
tux11runlv
/tux11run
30
tuxedo
Tuxedo软件
bsx1lv
/bsx1
30
bsx1
宝信MES应用程序
xcomlv
/xcom
30
xcom
宝信xcom通信软件
host2
ora11runlv
/ora11run
60
orarun
ORACLE数据库软件
oradatalv
/oradata
80
orarun
数据库
5） 路由规划表
节点名
目的
路由
host1
default
10.2.100.254
10.2.200
10.2.1.254
10.3.300
10.2.1.254
host2
default
10.2.100.254
6） HACMP结构表
集群名:
test_cluster
适配器名
功能
网络名
网络类型
属性
节点名
IP地址
MAC地址
host1_tty0
heartbeat
host1_net_rs232
rs232
serial
host1
host1_l2_boot1
boot1
host2_net_ether_2
ether
public
host1
10.2.2.1
host1_l1_boot1
boot1
host2_net_ether_1
ether
public
host1
10.2.1.21
host1_l2_svc
Service
host1_net_ether_2
ether
public
host1
10.2.200.1
host1_l1_svc1
Service
host1_net_ether_1
ether
public
host1
10.2.100.1
host1_l1_svc2
Service
host1_net_ether_1
ether
public
host1
10.2.101.1
host1_l2_boot2
boot2
host1_net_ether_2
ether
public
host1
10.2.12.1
host1_l1_boot2
boot2
host1_net_ether_1
ether
public
host1
10.2.11.1
host2_tty0
heartbeat
host2_net_rs232
rs232
serial
host2
host2_l2_boot1
boot1
host2_net_ether_2
ether
public
host2
10.2.2.2
host2_l1_boot1
boot1
host2_net_ether_1
ether
public
host2
10.2.1.22
host2_l2_svc
service
host2_net_ether_2
ether
public
host2
10.2.200.2
host2_l1_svc1
service
host2_net_ether_1
ether
public
host2
10.2.100.2
host2_l1_svc2
service
host2_net_ether_1
ether
public
host2
10.2.101.2
host2_l2_boot2
boot2
host2_net_ether_2
ether
public
host2
10.2.12.2
host2_l1_boot2
boot2
host2_net_ether_1
ether
public
host2
10.2.11.2
7） HACMP示意图
8） 实验环境示意图
9） 应用脚本起停设计
Østart_host1:
添加网关
运行start_host1_app
Østop_host1:
运行stop_host1_app
清理vg进程
Østart_host2:
添加网关
运行start_host2_app
Østop_host2:
运行stop_host1_app
清理vg进程
Østart_host1_app:
确认host2已启动
整理路由
启动主应用程序
启动通信程序
Østop_host1_app:
停通信程序
停应用主程序
清理路由
Østart_host2_app:
如在host1机器上执行stop_host1_app
起Oracle数据库及listener
如在host1机器上执行start_host1
Østop_host2_app:
停数据库及listener
第一部分--规划篇
万事开头难，对于一个有经验的HACMP工程师来说，会深知规划的重要性，一个错误或混乱的规划将直接导致实施的失败和不可维护性。
HACMP实施的根本目的不是安装测试通过，而是在今后运行的某个时刻突然故障中，能顺利的发生自动切换或处理，使得服务只是短暂中断即可自动恢复，使高可用性成为现实。
2.1. 规划前的需求调研
在做规划之前，或者说一个准备实施HACMP来保证高可用性的系统初步设计之前，至少需要调查了解系统的以下相关情况，这些都可能影响到HACMP的配置。
Ø 应用特点
1） 对负荷的需求，如CPU、内存、网络等特别是I/O的负载的侧重。
2） 对起停的要求，如数据库重起可能需要应用重起等等。
3） 对于自动化的限制，如重起需要人工判断或得到命令，需要在控制台执行。
Ø 网络状况和规划
包括网段的划分、路由、网络设备的冗余等等在系统上线前的状况和可提供条件，以及实施运行过程中可能出现的变更。
Ø 操作系统情况
目前IBM的HACMP除了AIX，还支持Linux。
目前新装机器都是AIX5.3，即使安装HA5.4也没有问题。
但如果安装可能是在老机器上进行升级，需要仔细了解操作系统版本及补丁情况。
Ø 主机设计
1） 可能实施的机器网卡的数量,网卡是否只能是双口或更多。
2） 是否有槽位增加异步卡
3） 主机之间的距离，这影响到串口线的长度。
Ø 预计实施高可用性的情况
1） 希望实施HACMP的机器数量
2） 希望方式，如一备一，双机互备，一备多，环形互备等等。
2.2. PowerHA/HACMP版本确定
IBMHACMP自从出了5.2版本后，到了5.205后比较稳定，并经过我们自己充分的测试（见测试篇）和实践证明（已有多个系统成功自动切换）。
之前个人觉得HACMP5.3后变化较快快，功能增加多，稳定性不够，相当长时间还是一直推荐HA5.209。
这也是本文出了第一版完全手册之后一直没有修订的原因之一。
随着Power主机和AIX的更新换代，名称也在变化，虽然目前最新版为PowerHASystemMirror7.1,又增加了不少绚丽夺目的功能，但个人以为作为高可用性软件，其成熟度为第一要素，其稳定性有待进一步验证。
而经过我们这2年来的充分实施经验，目前可以放心推荐版本为PowerHA6.1的6.1.10及以上。
2.3. IP地址设计
IP地址切换（IPAT）方式 有3种方式:
图1a，1b，和1c中描述了三个主要的IPAT配置场景。
◆ 第一个拓扑模式:
IPATviaReplacement
在分开的子网中包含boot和standby网卡。
当集群服务启动的时候boot地址被换成service地址。
尽管这种方式有效性强，但是在需要实现多服务IP地址的环境下这种方式是不可取的。
集群的管理员不得不利用pre-和post-events定制其环境建立额外的别名，
并且需要确认这些别名在下一次接管发生前被删除。
◆ 第二个拓扑模式：
IPATviaAliasing
HACMP4.5开始引入了IPATviaAliasing作为缺省的拓扑模式。
在这种新的模式中，standby网卡的功能被另外一个boot网卡替换。
子网需求的不同点是还需要一个另外的子网，每一个boot网卡需要它自己的子网，并且任何service或persistent的IP将在其本身的子网上操作，所以一共三个子网。
当集群服务启动并且需要serviceIP的时候，bootIP并不消失。
这个设计和第一种是不同的，在同一个HACMP网络中有多个serviceIP存在并且通过别名来控制。
◆ 第三种模式:
EthernetChannel（EC）
这种模式把底层的以太网卡藏到一个单一的“ent”接口之后。
该模式不是对前述任何一种方式的替换，而是可以和前述的任一种模式共同存在。
因为在每一个节点EC都被配置成冗余方式，可以在HACMP中使用IP别名定义它们每一个作为单一网卡网络。
因为在每个节点只有一个网卡被定义，所以只有两个子网，一个是用作boot（每个节点的基本IP地址），另一个是用于提供高可用服务。
本文讨论实际工作中使用最多的为第2种:
别名方式（IPATviaAliasing），即使到今天，其使用仍然最为广泛，对交换机要求也最低。
对于新型核心交换机和网络人员可紧密配合的，则推荐第3种，由于第3种更为简单，切换时间更短。
但本文这里以第2种为主加以讨论。
这样设计时就需要注意以下事情：
1. 网段设计：
一个服务地址需要3个网段对应，boot地址网段不能和服务地址一致。
避免网络变更造成的系统不可用，boot地址的网段不要和实际其他系统的网段一致。
在网段比较紧张的地方，建议设计时询问网络人员。
举例来说，下面的地址将会由于网络变更后打通合一后可能造成冲突：
设计人
机器名
服务地址
boot1地址
boot2地址
张三
app1_db
10.66.1.1
10.10.1.1
10.10.1.1
张三
app1_app
10.66.1.2
10.10.2.2
10.10.2.2
李四
app2_db
10.66.2.1
10.66.3.1
10.66.1.1
李四
app2_app
10.66.2.2
10.66.3.2
10.10.1.2
王五
app3_db
10.66.3.1
10.66.1.1
10.66.2.1
王五
app3_app
10.66.3.2
10.66.1.2
10.10.2.2
2. boot地址的设计：
不要和实际其他同网段机器的boot地址冲突，最好不同网段。
即这个规划不能只考虑系统本身，还需要从同网段的高度考虑。
举例来说，下面的地址由于2个系统分开设计，同时开启将直接导致2个系统不可用。
boot地址的设计表1
设计人
机器名
服务地址
boot1地址
boot2地址
张三
app1_db
10.66.3.1
10.10.1.1
10.10.1.1
张三
app1_app
10.66.3.2
10.10.1.2
10.10.1.2
李四
app2_db
10.66.3.11
10.10.1.1
10.10.1.1
李四
app2_app
10.66.3.12
10.10.1.2
10.10.1.2
所以在设计时，我们建议boot地址的IP地址最后一段参照服务地址，这样虽然可记忆性不是很好，但即使设计在同一网段，也可以避免上述错误发生。
更改设计如下：
boot地址的设计表2
设计人
机器名
服务地址
boot1地址
boot2地址
张三
app1_db
10.66.3.1
10.10.1.1
10.10.1.1
张三
app1_app
10.66.3.2
10.10.1.2
10.10.1.2
李四
app2_db
10.66.3.11
10.10.1.11
10.10.1.11
李四
app2_app
10.66.3.12
10.10.1.12
10.10.1.12
此外，如果是每个网卡多个网口，记得设计时必须注意同一网络的boot地址要分开到2块网卡，以保证真正的冗余。
2.4. 心跳设计
配置HACMP的过程中，除了TCP/IP网络之外，您也可以在其它形式的网络上，如串行网络和磁盘总线上配置心跳网络。
1. TCP/IP网络
优点：
要求低，不需要任何额外硬件或软件，即可实现。
缺点：
占用IP地址，不能避免由于TCP/IP的软件问题导致HACMP崩溃，系统不可用。
2. 串口网络
优点：
真正实现高可用性，不占用IP地址。
缺点：
需要硬件支持，需要新增异步卡，而中低端的机器的插槽有限。
3. 磁盘心跳
优点:
不占用插槽，磁盘总线上的心跳网络能够在TCP/IP网络资源有限的情况下提供额外的HACMP节点间的通信手段，并且能够防止HACMP节点之间由于TCP/IP软件出现问题而无法相互通信。
缺点：
需要操作系统和存储支持，如使用增强型卷组，此外对于I/O读写负荷高的应用，也需要慎用。
正如IBM红皮书所说，条件许可的情况下，强烈推荐使用串口网络，其次是磁盘心跳。
不过我们也注意到HACMP7.1将不再支持串口心
升级会员 