Linux Enterprise Cluster NOtes

有你才完美WoW

本章进一步讲解haresources文件的配置和heartbeat日常的维护问题。

1. /etc/ha.d/haresources文件中的每一行都将定义resource，每一行的书写语法是这样的：

resource-owner-hostname [IPaddress] resource1[::arg1::arg2] [resource2[::arg1::arg2]

上面可以看到，第一列写的是拥有该项资源的primary server的hostname；然后第二列是一个可选项，如果填写的话，写的是IP   Alias的IP地址，比如209.100.100.3上提供http服务，实际是由209.100.100.2这个网卡提供的，那么 209.100.100.3就是一个IP  Alias；第三列填写的是resoure的名字（该resource要能在/etc/init.d或/etc/ha.d/resource.d目录下找 到），紧跟着resource名字的后面，是可以传给该resource的参数列表，每个参数用两个冒号分隔。

2. Example.

primary.mydomain.com 209.100.100.3 sendmail httpd
sendmail, httpd两个资源，primary server是primary.domain.com，工作在虚拟IP地址209.100.100.3上。

3. heartbeat在设置IP Alias的时候，其实会把IP  Alias传给IPAddr这个脚本（前面几章中提过这个脚本），IPAddr脚本呢，会调用heartbeat的一个叫做findif的程序，这个程序 将自动根据我们给定的IP  Alias，来找出要将这个IP绑定在哪块网卡上。书中写了一些findif工作的细节，我们没必要详细了解。大概的经过是这样的，findif查询本机 的路由表（netstat -n或在/proc/net/route文件中），然后将我们给定的IP  Alias地址和路由表中的每项IP地址比对，如果发现路由表中有个IP地址和我们的IP  Alias的IP地址在一个网段，那么就绑定在这快网卡上；如果找到多个IP都和IP  Alias在一个网段上，那么findif自动查找hops数最少的那块网卡。如果我们不想让findif自作聪明的帮我们查找网卡，那么可以这样：

primary.mydomain.com 209.100.100.3/24/eth0/209.100.100.255 httpd
指定IP ALias地址，子网掩码，网卡设备名称和广播地址，这样就一点想象力都没有了，我们手动指明绑定的网卡。

4. 在resource这一列，我们可以在一行中写入多个resource，这是可以的。heartbeat会按照顺序逐一调用－－不过我个人不推荐这样的做法，会比较凌乱，写成多行好了。resource可以带参数，比如：

primary.mydomain.com myresource::FILE1::UNAME=JOHN::L3

这样heartbeat调用这个resource的status状态时，是这样调用的：

/etc/ha.d/resource.d/myresource FILE1 UNAME=JOHN L3 status

当我们在一行内写入多个resource的时候，我们称这些resource为一个resource group，对于一个resource  group，heartbeat只会调用该group中第一个resource的状态来确定整个group的状态（如果第一个resource返回状态不 是OK，那么，heartbeat将会start这个group中的所有resource），这样做有一个意义，比如，我们希望在真正的resource   start之前，做另外一个脚本的动作，那么，就可以将这个脚本和真正的资源写在一行并保证这个脚本在真正的资源之前，那么，就可以让这个脚本先执行了。　　

　　
5. Load sharing with Heartbeat.本节介绍了一些利用heartbeat来做一些负载均衡的工作，有点小意思。

6. 比如，第一个例子：我们有两个应用http和sendmail，常规思路下，这两个应用都跑在primary  server上，backup server在primary  server正常的情况下永远standby。现在可以这样：primary和backup  server都各跑一个应用，这样，起到了一定的负载均衡的效果，当任何一台机器down掉的时候，剩下的那台就会将两个应用都跑到自己上面来。如图：附 件1

这种情况，haresources中应该这样配置：
primary.mydomain.com 209.100.100.3 sendmail
backup.mydomain.com 209.100.100.4 httpd

7. 再来第二个例子－Round-Robin DNS。这个例子利用DNS的round-robin的特性来做load  sharing。原理很简单，DNS有一个叫做round-robin的好玩的特性，就是当我们在做DNS解析的时候，可以对一个域名做两次解析，比如：

;Round-robin entry for www.mydomain.com
www.mydomain.com    IN  A  209.100.100.3
www.mydomain.com    IN  A  209.100.100.4

3         IN PTR www.mydomain.com
4         IN PTR www.mydomain.com

在这种情况下，bind会这样处理：第一个解析请求，bind返回IP 209.100.100.4，第二次请求，bind返回IP 209.100.100.3，第三次又返回209.100.100.4，这样一来，我们就可以做一个这样的HA：

primary.mydomain.com 209.100.100.3 httpd
backup.mydomain.com 209.100.100.4 httpd

这样，两台服务器都将各自承受一半的http请求，当一台down掉之后，剩下的一台将完全负担起工作。

但是这种方式是有问题的，最简单的一个问题就是，客户端都会cache  DNS解析的结果，这样一来，就根本达不到上述的效果了，因为client根本不做DNS解析了，针对这种情况，有人说，可以将DNS的TTL值调小阿！ 问题是，如果真把DNS的TTL调小了，会非常大程度上造成DNS的高负载和不稳定，得不偿失了。

8. wide-area load balancing.  这个和heartbeat没什么关系，他其实就是一个根据地理位置的远近来选择服务器的东西，比如client在南京，那么，系统会选择一个在上海的服务 器给他服务而不是选择一个在北京的服务器给他服务。这个东西也有专门的软件来实现，书中介绍的软件是：super sparrow, http://www.supersparrow.org
　　
9. Audible Alarm. 一个配置小技巧，当failover发生的时候，往往我们希望得到通知，heartbeat为我们提供了两个特定的resource：AudibleAlarm和MailTo，可以这样配置：

primarynode AudibleAlarm::primarynode

可以看到，我们给这个资源传递了一个参数叫primarynode，通过这个参数，AudibleAlarm资源知道了自己的owner是一个主 机名为primarynode的机器，那么，他会做这样的事情，当AudibleAlarm发现自己正在primarynode上运行时，他不会做任何 事；当failover发生，backup server接管了AudibleAlarm后，AudibleAlarm发现自己运行在backup  server上时，他会开始发出beep，一秒钟一次，有意思吧？这样就通知我们，failover发生过了。简单吧，就是增加一个resource就 OK了。

更进一步，如果我们的机器上有软驱，操作系统又安装了fdutils这个包后，AudibleAlarm还可以让我们软驱上的灯亮起来，以此提示failover的发生。

10. EMail Alerts。和AudibleAlarm类似：

primarynode MailTo::operator@mailhost.com,root@mailhost.com::Mysubject
　　
　　
11. heartbeat的维护。第一，当我们修改了/etc/ha.d/authkeys或/etc/ha.d/ha.cf文件后，想让修改生效的话，不需要重启heartbeat，只需要这样：
/etc/init.d/heartbeat reload  或
service heartbeat reload

但是，如果/etc/ha.d/haresources文件有改动，比如新增了一个resource，那么必须重启heartbeat:

/etc/init.d/heartbeat restart  或
service heartbeat restart

12. auto_failback。这个配置项存在于ha.cf中，当primary server down后，backup  server接管，然后primary server恢复时，backup server会自动放弃资源，primary  server会自动将资源接管回来，这种行为叫做auto_failback，默认这个选项是on，我们可以将这个选项设成off，这样primary  server恢复后，也不会自动将资源接管回来。这样配置有一个好处，就是如果我们想对primary  server做一些维修，比如硬件更换，然后进入OS做一些配置时，就很好，因为primary  server不会将资源接管回来。当我们对primary  server的维护完成后，可以手动将资源接管回来：将auto_failback重新修改成on，然后在backup server上"service  heartbeat reload"，最后在primary server上"service heartbeat restart"，就OK了！

13. 手动强行让primary server standby。执行这个命令即可：

#/usr/lib/heartbeat/hb_standby

当我们想对primary server做检修的时候，这个命令很有用。

14. 在heartbeat的日志中经常会看到这样的信息：

heartbeat: info: RealMalloc stats: 976 total malloc bytes. pid [369/HBREAD
heartbeat: info: MSG stats: 0/441708 age 0 [pid370/MST_STATUS]
heartbeat: info: ha_malloc stats: 0/9035987 0/0

这些信息是正常的，不用担心。经过一段时间的运行后，total bytes used这项数值将不再增长。

15. respawn和cl_respawn，前面一章讲解过了。

16. License Manager Failover。这个也有点意思，有些软件的License采用license  server的方式来架构，比如lmgrd，我们可以对这个license server做一个HA，保证license  server的HA。唯一需要注意的是，license  server启动的时候会检查本地的license文件，这个文件中哟hostid的相关信息，那么，我们必须将两台机器的hostid都分别制作 license文件，否则failover发生了，但是在backup  server上run不了lmgrd就搞笑了。据说lmgrd这个软件在卖的时候，如果说清楚我们做HA license  server（同时只会run一台license server），那么，软件商会给我们两个license，但只会收一份钱哦！