1. ホーム /
  2. やってみた /
  3. “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。（第2回）～ノード監視処理
  • 2016.09.13

“Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。（第2回）～ノード監視処理

    quickcheck-script-error

    こんにちは。
    サイオステクノロジーの宇野です。LifeKeeperの開発を担当しています。

    前回は、各リソースの状態をチェックするリソース監視処理に要する時間を測定して、可能な範囲での監視間隔の短縮にチャレンジしてみました。今回は、ノード監視に要する時間の短縮にチャレンジしたいと思います。

    使用した環境は、リソース監視処理の短縮でも使用した以下の環境です。

    Server : VM(vSphere6) x2
    CPU: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (4 core)
    MemTotal: 8073684 kB
    Disk: /dev/sda: 17.2 GB
              /dev/sdb: 10.7 GB
    Network: 1000Mbps x2
    OS : CentOS Linux release 7.2.1511
    Kernel Version: 3.10.0-327.el7.x86_64
    DB:PostgreSQL v9.4.8

    上記の構成のサーバーにProtection Suite for Linux v9.1をインストールし、2ノードクラスター＋Quorum/Witness サーバーのリソース構成としました。

    lifekeeper-gui-structure
    LifeKeeperのGUIでリソース構成を確認します。

    ノード監視処理は、コミュニケーションパスを経由して送信するハートビートによって行われます。初期設定では以下の値が使用されますので、正常時は5秒間隔でハートビートを送信し、死活監視を行います。

    LCMHBEATTIME,=5 # ハートビートの送信間隔 (秒)
    LCMNUMHBEATS=3 # ハートビート切断と判定するまでの試行回数

    正常時のハートビート
    正常時は5秒間隔でハートビートを送信

    コミュニケーションパスが切断された場合は5秒をリミットとしてハートビートを送信し、3回失敗するとコミュニケーションパス障害となります。その為、コミュニケーションパスの障害検出まで約15秒かかります。

    コミュニケーションパス切断時のハートビート
    5秒をリミットとしてハートビートを送信し、3回失敗するとコミュニケーションパス障害となる

     

    全てのコミュニケーションパスが障害として判定された場合、ノード障害と判定されノードフェイルオーバーが発生します。

    ハートビートの送信間隔、試行回数を指定するパラメータの値を短くすることで、障害検出までの時間を短縮できます。今回は、これら2つのパラメータの短縮ににチャレンジしたいと思います。

    Contents hide

    事前準備

    パラメータを変更する前に、短縮したことが原因で発生するコミュニケーションパスの障害誤検知が、最終的にノード障害フェイルオーバーへとつながらないよう、事前にノード障害フェイルオーバーを停止します。これにより、短縮時間の測定テストで不要なノード障害フェイルオーバーの発生を抑止します。

    ノード障害フェイルオーバーを無効化するためには、LifeKeeper GUI のノードで右クリックをして、Properties を選択します。以下のProperties Panel画面が開きますので、”Set Confirm Failover On”で該当するサーバーに全てチェックを入れてください。この項目にチェックすることでノード障害フェイルオーバーが発生しなくなります。この処理は念のため全てのノードを対象に行います。

    server-propertiesパネル
    server-propertiesパネル

     

     パラメータの調整

    ノード障害フェイルオーバーを停止した後、パラメータの値を調整して、コミュニケーションパスに流れるハートビートが途切れないかどうかログを監視します。最初に全ノードに対して、各パラメータの最小値を設定しました。最小値は以下となります。

    LCMHBEATTIME,=1 # ハートビートの送信間隔 (秒)
    LCMNUMHBEATS=2 # ハートビート切断と判定するまでの試行回数

    パラメータの設定変更後は、LifeKeeperを再起動する必要があります。
    # lkstop –f ; lkstart

    最小値に変更した場合、ネットワークは正常にもかかわらず以下のメッセージを出力し、ハートビート喪失を検出しました。
    Aug 25 14:14:31 pd109 lcm[3281]: INFO:lcm.tli_hand:::005257:missed heartbeat 1 of 2 on dev 10.1.6.109/10.1.6.108 (lcm driver number = 1256).

    設定後に上記のメッセージが出力する場合は、ノード間のコミュニケーションパスでのハートビートが正常に届いていない事を示しています。その為ため、この監視間隔、試行回数では正常に監視が行えませんので、パラメータの値を以下の値まで増やしました。

    LCMHBEATTIME,=2 # ハートビートの送信間隔 (秒)
    LCMNUMHBEATS=2 # ハートビート切断と判定するまでの試行回数

    パラメータの設定変更後は、LifeKeeperを再起動する必要があります。
    # lkstop –f ; lkstart

    第1回のブログで使用したTPCC-UVa のRun testを実行して、通常の運用時の状態を24時間再現しました。それにより、上記の値であっても、通常の運用には耐えられることを確認しました。

    フェイルオーバーテスト

    最小値が分かりましたので、デフォルト値と最小値でノード障害テストを行い、フェイルオーバーが完了するまでの時間を確認しました。

    先にデフォルト値でフェイルオーバーに要する時間を測定しました。誤検知によるフェイルオーバーを防ぐために行った、ノード障害フェイルオーバーの停止を解除してからテストを行います。

    デフォルト値：
    LCMHBEATTIME,=5 # ハートビートの送信間隔 (秒)
    LCMNUMHBEATS=3 # ハートビート切断と判定するまでの試行回数

    1. 両ノードの時間が一致している事を確認しました。
      [root@pd108 ~]# ssh pd109 “hostname;date”; hostname;date
      root@pd109’s password:
      pd109.labs.sios.com
      2016年 8月 25日 木曜日 17:24:11 JST
      pd108.labs.sios.com
      2016年 8月 25日 木曜日 17:24:11 JST
      [root@pd108 ~]#
    2. pd108がアクティブ、pd109 がスタンバイノードという状態で、pd108で以下のコマンドを実行してカーネルパニックを起こします。
      # date ; sleep 1 ; echo c > /proc/sysrq-trigger
      2016年 8月 25日 木曜日 17:25:43 JST
      ＊上記の時間の1秒後にカーネルパニックを引き起こしています。
    3. pd109でコミュニケーションパス障害を検出した時間は以下のとおりでした。
      Aug 25 17:26:02 pd109 eventslcm[15651]: WARN:lcd.net:::004258:Communication to pd108.labs.sios.com by 172.16.1.109/172.16.1.108 FAILED
      Aug 25 17:26:02 pd109 eventslcm[15654]: WARN:lcd.net:::004258:Communication to pd108.labs.sios.com by 10.1.6.109/10.1.6.108 FAILED
      Aug 25 17:26:02 pd109 eventslcm[15654]: WARN:lcd.net:::004261:COMMUNICATIONS failover from system “pd108.labs.sios.com” will be started.
      Aug 25 17:26:02 pd109 lifekeeper[15710]: NOTIFY:event.comm_down:::010466:COMMUNICATIONS pd108.labs.sios.com FAILED
    4.  Pd109でフェイルオーバーが完了したのは、以下の時間でした。
      Aug 25 17:26:13 pd109 lcdmachfail[15806]: NOTIFY:lcd.lcdmf:::011065:FAILOVER RECOVERY OF MACHINE pd108.labs.sios.com FINISHED

    デフォルト値での障害検出には、18秒かかり、ノードフェイルオーバーが完了するまでには29秒の時間が必要でした。

    続いて、設定可能な最小値でフェイルオーバーテストを実施します。

    最小値：
    LCMHBEATTIME,=2 # ハートビートの送信間隔 (秒)
    LCMNUMHBEATS=2 # ハートビート切断と判定するまでの試行回数

    1. 両ノードの時間が一致している事を確認します。
      [root@pd108 ~]# ssh pd109 “hostname;date”; hostname;date
      root@pd109’s password:
      pd109.labs.sios.com
      2016年 8月 25日 木曜日 18:03:42 JST
      pd108.labs.sios.com
      2016年 8月 25日 木曜日 18:03:42 JST
      [root@pd108 ~]#
    2. pd108がアクティブ、pd109 がスタンバイノードの状態で、pd108で以下のコマンドを実行してカーネルパニックを起こします。
      [root@pd108 ~]# date ; sleep 1 ; echo c > /proc/sysrq-trigger
      2016年 8月 25日 木曜日 18:04:21 JST
      ＊上記の時間の1秒後にカーネルパニックを引き起こしています。
    3.  pd109でコミュニケーションパス障害を検出した時間は以下でした。
      Aug 25 18:04:27 pd109 eventslcm[22480]: WARN:lcd.net:::004258:Communication to pd108.labs.sios.com by 10.1.6.109/10.1.6.108 FAILED
      Aug 25 18:04:27 pd109 eventslcm[22483]: WARN:lcd.net:::004258:Communication to pd108.labs.sios.com by 172.16.1.109/172.16.1.108 FAILED
      Aug 25 18:04:27 pd109 eventslcm[22483]: WARN:lcd.net:::004261:COMMUNICATIONS failover from system “pd108.labs.sios.com” will be started.
      Aug 25 18:04:27 pd109 lifekeeper[22538]: NOTIFY:event.comm_down:::010466:COMMUNICATIONS pd108.labs.sios.com FAILED
    4. pd109でフェイルオーバーが完了したのは以下の時間でした。
      Aug 25 18:04:38 pd109 lcdmachfail[22602]: NOTIFY:lcd.lcdmf:::011065:FAILOVER RECOVERY OF MACHINE pd108.labs.sios.com FINISHED

    最小値での障害検出には、5秒かかり、ノードフェイルオーバーが完了するまでには16秒の時間が必要でした。

    結論

    今回の検証では、最小値を使用する事で、障害の復旧が13秒早くなりました。

    注意事項としては、今回の検証環境は上記の設定ではハートビートの応答が4秒止まるだけでコミュニケーションパスの障害を検出します。つまり、ノード障害やネットワーク障害が発生していなくても、4秒以上応答が止まるようなシステム状況が発生した場合、LifeKeeperはコミュニケーションパス障害を検出しますので、障害の誤検知となる場合もあります。

    次回は、可用性を高めるその他の施策について確認します。

     

    >>第1回から読む

    >>第3回　“Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。～その他の短縮方法を考える　を読む