heartbeat 3.0集群（3）heartbeat配置

janneyabc

　　对HA的配置分为两个部分，配置heartbeat和pacemaker，与heartbeat版本相对应，配置文件也有两个版本，即为heartbeat1.x的1.x style版本和heartbeat2.1.x版本之后的2.1.x style版本
　　我们可以借助1.x style的集群资源配置文件转换为2.x style的格式，同时，在heartbeat2.1.x版本之后使用CRM来管理整个集群。集群开始时，通过在各节点间选举产生一个节点成为DC（Designated Coordinator），所有配置操作都在该DC主机上进行，并由其分发到集群下的各个节点上。下面依次讲述。
　　（1）1.x和2.x配置文件对比ü/usr/local/ha/etc/ha.d/authkeys 该文件在两个版本作用是完全相同的，都必须设置，并且保证每个节点（node）内容一样ü/usr/local/ha/etc/ha.d/ha.cf 这个是主要配置文件，由其决定v1或v2 style格式/usr/local/ha/etc/haresources 这是v1的资源配置文件ü/usr/local/ha/var/lib/heartbeat/crm/cib.xml 这是v2的资源配置文件，两者根据ha.cf的设定只能选其一.v2版本使用CRM管理集群，而cib.xml文件有如下几种方式来编写：
　　a）人工编写XML文件；
　　b）使用admintools工具，其已经包含在heartbeat包中；
　　c）使用GUI图形工具配置，也包含在heartbeat-gui包里面，这个一会介绍；
　　d）使用python脚本转换1.x style的格式配置文件到2.x style格式。

　　这四种方法实质都是相同的，并且以python脚本转换最为简单容易。为此，可以先配置好1.x style的格式，然后通过python脚本进行转换。
　　

　　（2）：配置heartbeat
　　首先拷贝模板配置文件，如果没有安装模版的话就要手动配置

　　cp /usr/local/ha/share/doc/authkeys   /usr/local/ha/etc/ha.d
　　cp  /usr/local/ha/share/doc/ha.cf       /usr/local/ha/etc/ha.d
　　cp  /usr/local/ha/share/doc/haresources    /usr/local/ha/etc/ha.d
　　
　　（3）主配置文件(/etc/ha.d/ha.cf)
　　logfile /var/log/ha-log#指名heartbeat的日志存放位置。

　　#crm yes #是否开启Cluster Resource Manager（集群资源管理）功能。
　　serial /dev/ttyS0
    使用串口heartbeat－如果不使用串口heartbeat，则必须使用其他的介质，如bcast（以太网）heartbeat。用适当的设备文件代替/dev/ttyS0。
    watchdog /dev/watchdog
    该选项是可选配置。通过Watchdog 功能可以获得提供最少功能的系统，该系统不提供heartbeat，可以在持续一份钟的不正常状态后重新启动。该功能有助于避免一台机器在被认定已经死亡之后恢复heartbeat的情况。如果这种情况发生并且磁盘挂载因故障而迁移（fail over），便有可能有两个节点同时挂载一块磁盘。如果要使用这项功能，则除了这行之外，也需要加载“softdog”内核模块，并创建相应的设备文件。方法是使用命令“insmod softdog”加载模块。然后输入“grep misc /proc/devices”并记住得到的数字（应该是10）。然后输入”cat /proc/misc | grep watchdog”并记住输出的数字（应该是130）。根据以上得到的信息可以创建设备文件，“mknod /dev/watchdog c 10 130”。
    bcast eth1
    表示在eth1接口上使用广播heartbeat（将eth1替换为eth0，eth2，或者您使用的任何接口）。
　　    #ucast eth0 192.168.1.2#采用网卡eth0的udp单播来组织心跳，后面跟的IP地址应为双机对方的IP地址。
　　    #mcast eth0 225.0.0.1 694 1 0#采用网卡eth0的Udp多播来组织心跳，一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播，是组织心跳的三种方式，任选其一即可。
    keepalive 2
    设定heartbeat之间的时间间隔为2秒。
    warntime 10
    在日志中发出“late heartbeat“警告之前等待的时间，单位为秒。
    deadtime 30
    在30秒后宣布节点死亡。
    initdead 120
    在某些配置下，重启后网络需要一些时间才能正常工作。这个单独的”deadtime”选项可以处理这种情况。它的取值至少应该为通常deadtime的两倍。
    baud 19200
    波特率，串口通信的速度。
    udpport 694
    使用端口694进行bcast和ucast通信。这是默认的，并且在IANA官方注册的端口号。
    auto_failback on
    该选项是必须配置的。对于那些熟悉Tru64 Unix的人来说，heartbeat的工作方式类似于“favored member“模式。在failover之前，haresources文件中列出的主节点掌握所有的资源，之后从节点接管这些资源。当auto_failback设置为on时，一旦主节点重新恢复联机，将从从节点取回所有资源。若该选项设置为off，主节点便不能重新获得资源。该选项与废弃的nice_failback选项类似。如果要从一个nice_failback设置为off的集群升级到这个或更新的版本，需要特别注意一些事项以防止flash cut。请参阅FAQ中关于如何处理这类情况的章节。
    node primary.mydomain.com
    该选项是必须配置的。集群中机器的主机名，与“uname –n”的输出相同。
    node backup.mydomain.com
    该选项是必须配置的。同上。
    respawn   
    该选项是可选配置的：列出将要执行和监控的命令。例如：要执行ccm守护进程，则要添加如下的内容：


　　    #stonith baytech /etc/ha.d/conf/stonith.baytech# stonith的主要作用是使出现问题的节点从集群环境中脱离，进而释放集群资源，避免两个节点争用一个资源的情形发生。保证共享数据的安全性和完整性。
　　    ping 192.168.12.1#选择ping的节点，ping 节点选择的越好，HA集群就越强壮，可以选择固定的路由器作为ping节点，但是最好不要选择集群中的成员作为ping节点，ping节点仅仅用来测试网络连接。
　　ping_group group1 192.168.12.251 192.168.12.239
　　   #类似于ping。
　　#respawn hacluster /usr/local/ha/lib/heartbeat/ipfail
　　apiauth pingd gid=haclient uid=hacluster

　　respawn hacluster /usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s

　　#该选项是可选配置，列出与heartbeat一起启动和关闭的进程，该进程一般是和heartbeat集成的插件，这些进程遇到故障可以自动重新启动。最常用的进程是pingd，此进程用于检测和监控网卡状态，需要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动pingd进程的身份。#下面的配置是关键，也就是激活crm管理，开始使用v2 style格式crm respawn#注意，还可以使用crm yes的写法，但这样写的话，如果后面的cib.xml配置有问题#会导致heartbeat直接重启该服务器，所以，测试时建议使用respawn的写法#下面是对传输的数据进行压缩，是可选项compressionbz2compression_threshold 2注意，v2 style不支持ipfail功能，须使用pingd代替
　　

　　（4）资源文件(/etc/ha.d/haresources)

　　Haresources文件用于指定双机系统的主节点、集群IP、子网掩码、广播地址以及启动的服务等集群资源，文件每一行可以包含一个或多个资源脚本名，资源之间使用空格隔开，参数之间使用两个冒号隔开，在两个HA节点上该文件必须完全一致，此文件的一般格式为：
　　node-name network

　　node-name表示主节点的主机名，必须和ha.cf文件中指定的节点名一致，network用于设定集群的IP地址、子网掩码、网络设备标识等，需要注意的是，这里指定的IP地址就是集群对外服务的IP地址，resource-group用来指定需要heartbeat托管的服务，也就是这些服务可以由heartbeat来启动和关闭，如果要托管这些服务，必须将服务写成可以通过start/stop来启动和关闭的脚步，然后放到/etc/init.d/或者/etc/ha.d/resource.d/目录下，heartbeat会根据脚本的名称自动去/etc/init.d或者/etc/ha.d/resource.d/目录下找到相应脚步进行启动或关闭操作。LSB： Linux标准脚本文件（init script），通常放在/etc/init.d/目录下，heartbeat1.x版本之前的管理脚本一半放在/etc/ha.d/resource.d，在这里是/usr/local/ha/etc/ha.d/resource.d
　　OCF：Open Cluster Framework，默认放在/usr/lib/resource.d/heartbeat/目录下；在这里是/usr/local/ha/etc/ha.d/resource.d
　　
　　下面介绍一下ocf和lsb格式的区别：LSB格式的脚本必须支持status功能，必须能接收start,stop,status,三个参数；而如果是OCF格式,则必须支持start,stop,monitor三个参数.其中status和monitor参数是用来监控资源的,非常重要. 例如LSB风格的脚本,运行./Mysql status时候，返回值包含OK或则running则表示资源正常返回值包含stopped或者No则表示资源不正常。假如是OCF风格的脚本,运行./Mysql monitor时候, 返回0表示资源是正常的, 返回7表示资源出现问题.
　　

　　下面对配置方法进行具体说明：
　　node1 IPaddr::192.168.60.200/24/eth0/Filesystem::/dev/sdb5::/webdata::ext3httpd tomcat

　　其中，node1是HA集群的主节点，IPaddr为heartbeat自带的一个执行脚步，heartbeat首先将执行/etc/ha.d/resource.d/IPaddr 192.168.60.135/24 start的操作，也就是虚拟出一个子网掩码为255.255.255.0，IP为192.168.12.135的地址，此IP为heartbeat对外提供服务的网络地址，同时指定此IP使用的网络接口为eth0，接着，heartbeat将执行共享磁盘分区的挂载操作，
　　“Filesystem::/dev/sdf1::/data1::ext3”相当于在命令行下执行mount操作，
　　即“mount –t ext3 /dev/sdf1 /data1”，最后依次启动httpd和tomcat服务。

　　

　　（5）认证文件(/etc/ha.d/authkeys)

　　authkeys文件用于设定heartbeat的认证方式，共有三种可用的认证方式：
　　crc、md5和sha1，三种认证方式的安全性依次提高，但是占用的系统资源也依次增加。如果heartbeat集群运行在安全的网络上，可以使用crc方式，如果HA每个节点的硬件配置很高，建议使用sha1，这种认证方式安全级别最高，如果是处于网络安全和系统资源之间，可以使用md5认证方式。
　　这里我们使用crc认证方式，设置如下：auth 11 crc#2 sha1 sha1_any_password#3 md5 md5_any_password需要说明的一点是：无论auth后面指定的是什么数字，在下一行必须作为关键字再次出现，例如指定了“auth 6”，下面一定要有一行“6 认证类型”。最后确保这个文件的权限是600（即-rw-------）。
　　

　　（6）配置pacemaker
　　

　　在使用CRM管理的时候，也就是heartbeat第二种配置格式，就需要配置pacemaker了。
　　通过pacemaker可以对集群资源进行监控和配置。在HA环境中，所有资源的信息，和对其的配置都是以xml格式进行存储的，所以对其进行管理监控配置都是对xml文件进行读写。
　　所以对pacemaker进行配置其实就是对cib.xml文件进行读写，这个文件在不同环境中存在于不同位置，在我们的环境中存在于/usr/local/ha/var/lib/heartbeat/crm/cib.xml，可以用vi对其进行查看。但需要说明的是对其的改写一定不能用vi或其他编辑器进行，而是要通过提供的工具，如cibadmin, crm等命令来进行。这是基于以下原因：[size=72%]üxml不易读写，而crm提供了具体的，对应的命令来进行资源信息的监控，配置管理。
　　[size=72%]ü这个文件的修改直接作用于HA环境的变更，如果在里面执行了一个删除服务的操作，那么这个操作可能会破坏整个环境的运行，所以HA提供了一套机制来避免这种状况的发生，这个机制名为shadow。即我们在通过命令工具修改这个文件时，会将修改后的配置尝试运行，检测一遍，看是否有错误，如果有错则会不能进行修改的提交，这样就保证了配置的正确性和环境的稳定性。因为手动直接修改这个文件无法应用这个机制，所以不能使用手动修改。另外需要说明的是这个文件在所有节点上会自动保持同步，如果有一个节点上面的cib.xml有变更，则其他节点会自动进行该文件的增量拷贝。