MFS+corosync+pacemaker+ISCSI集群配置过程的一个错误以及排错过程

• 错误

Failed actions:
    fence_start_0 on server7.com 'unknown error' (1): call=34, status=Timed Out, last-rc-change='Thu Mar 22 21:30:11 2018'
, queued=20004ms, exec=0ms
    fence_start_0 on server6.com 'unknown error' (1): call=34, status=Timed Out, last-rc-change='Thu Mar 22 21:29:49 2018'
, queued=20006ms, exec=0ms

• 分析
• 首先想到的是解析的问题,但是解析在一开始是同一个每个节点进行配置的,所以这个就排除了;
• 其次想到的是iptables的问题,因为在/var/log/messages出现了这样的信息

Mar 22 22:23:10 server6 cib[2914]:   notice: cib:diff: ++           name="monitor" interval="60s" id="fence-monitor-60s"/>
Mar 22 22:23:10 server6 stonith-ng[2915]:   notice: stonith_device_register: Added 'fence' to the device list (1 active devices)
Mar 22 22:23:10 server6 pengine[2918]:  warning: unpack_rsc_op: Processing failed op start for fence on server7.com: unknown error (1)
Mar 22 22:23:10 server6 pengine[2918]:  warning: unpack_rsc_op: Processing failed op start for fence on server6.com: unknown error (1)
Mar 22 22:23:10 server6 pengine[2918]:  warning: common_apply_stickiness: Forcing fence away from server6.com after 1000000 failures (max=1000000)
Mar 22 22:23:10 server6 pengine[2918]:  warning: common_apply_stickiness: Forcing fence away from server7.com after 1000000 failures (max=1000000)

• 这里有提示在尝试了很多次,之后,仍然不能够启动,信息是这个Mar 22 22:23:10 server6 pengine[2918]: warning: common_apply_stickiness:,看到这里也就排除了iptables的问题,因为fence设备在server7.com上面也是无法进行启动的,但是server7.com是运行corosync的,不需要通过防火墙出去;
• 接下来想到的是配置资源可能出错的,在crm(live)configure# verify之后,并没有错误信息出现,所以这个问题也是可以排除的;

• 为了排除不是在配置corosync集群中出现的错误,重新使用两台虚拟机,重新将进行了配置,结果出现了同样的错误,在这个过程中,感觉应该是真机的配置文件可能有问题,

• 这个错误出现的原因是因为真机fence的配置文件设置错误

listeners {
    multicast {
        port = "1229";
        family = "ipv4";
        interface = "br0";  //这个是因为桥接网卡改变了,引起的错误
        address = "225.0.0.12";
        key_file = "/etc/cluster/fence_xvm.key";                                
    }   

}

• 看到配置文件提示的interface=br0时,就发现了了错误,因为桥接的网卡.在上次网络出现故障时,已经重新建立桥接了;
• 一直没有想到这个问题是因为真机在启动[root@my Desktop]# systemctl start fence_virtd.service 这个服务的过程中,没有出现错误提示,在配置过程中,显示这个服务的状态是正常的;
• 在出现错误的时候,首先应该划定错误出现的时间,确定故障的最大可能存在时间
• 其次确定故障可能发生的区域,是权限问题,网络问题,服务的配置问题
• 然后找出这段时间内,你的操作可能对于上面的那些区域产生可影响,并且在操作的过程中可能出现的错误是否和现在出现的错误存在雷同;

• 同时在排查错误的过程中,最好是结合日志文件进行分析,,虽然这次日志文件的提示作用并不是很大;

• 在配置服务的过程中,应该有这样一个习惯,就是一边配置,一边检查,这样可以从时间和空间上面确定故障可能发生时间的最小时间段,和区域;