天天看點

MFS+corosync+pacemaker+ISCSI叢集配置過程的一個錯誤以及排錯過程

  • 錯誤
Failed actions:
    fence_start_0 on server7.com 'unknown error' (1): call=, status=Timed Out, last-rc-change='Thu Mar 22 21:30:11 2018'
, queued=ms, exec=ms
    fence_start_0 on server6.com 'unknown error' (): call=, status=Timed Out, last-rc-change='Thu Mar 22 21:29:49 2018'
, queued=ms, exec=ms
           
  • 分析
  • 首先想到的是解析的問題,但是解析在一開始是同一個每個節點進行配置的,是以這個就排除了;
  • 其次想到的是

    iptables

    的問題,因為在

    /var/log/messages

    出現了這樣的資訊
Mar  :: server6 cib[]:   notice: cib:diff: ++           <op name="monitor" interval="60s" id="fence-monitor-60s"/>
Mar  :: server6 stonith-ng[]:   notice: stonith_device_register: Added 'fence' to the device list ( active devices)
Mar  :: server6 pengine[]:  warning: unpack_rsc_op: Processing failed op start for fence on server7.com: unknown error ()
Mar  :: server6 pengine[]:  warning: unpack_rsc_op: Processing failed op start for fence on server6.com: unknown error ()
Mar  :: server6 pengine[]:  warning: common_apply_stickiness: Forcing fence away from server6.com after  failures (max=)
Mar  :: server6 pengine[]:  warning: common_apply_stickiness: Forcing fence away from server7.com after  failures (max=)
           
  • 這裡有提示在嘗試了很多次,之後,仍然不能夠啟動,資訊是這個

    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

    時,就發現了了錯誤,因為橋接的網卡.在上次網絡出現故障時,已經重建立立橋接了;
  • 一直沒有想到這個問題是因為真機在啟動

    [[email protected] Desktop]# systemctl start fence_virtd.service

    這個服務的過程中,沒有出現錯誤提示,在配置過程中,顯示這個服務的狀态是正常的;
  • 在出現錯誤的時候,首先應該劃定錯誤出現的時間,确定故障的最大可能存在時間
  • 其次确定故障可能發生的區域,是權限問題,網絡問題,服務的配置問題
  • 然後找出這段時間内,你的操作可能對于上面的那些區域産生可影響,并且在操作的過程中可能出現的錯誤是否和現在出現的錯誤存在雷同;
  • 同時在排查錯誤的過程中,最好是結合日志檔案進行分析,,雖然這次日志檔案的提示作用并不是很大;
  • 在配置服務的過程中,應該有這樣一個習慣,就是一邊配置,一邊檢查,這樣可以從時間和空間上面确定故障可能發生時間的最小時間段,和區域;

繼續閱讀