こんにちは。
サイオステクノロジーの宇野です。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 サーバーのリソース構成としました。
ノード監視処理は、コミュニケーションパスを経由して送信するハートビートによって行われます。初期設定では以下の値が使用されますので、正常時は5秒間隔でハートビートを送信し、死活監視を行います。
LCMHBEATTIME,=5 # ハートビートの送信間隔 (秒)
LCMNUMHBEATS=3 # ハートビート切断と判定するまでの試行回数
コミュニケーションパスが切断された場合は5秒をリミットとしてハートビートを送信し、3回失敗するとコミュニケーションパス障害となります。その為、コミュニケーションパスの障害検出まで約15秒かかります。
全てのコミュニケーションパスが障害として判定された場合、ノード障害と判定されノードフェイルオーバーが発生します。
ハートビートの送信間隔、試行回数を指定するパラメータの値を短くすることで、障害検出までの時間を短縮できます。今回は、これら2つのパラメータの短縮ににチャレンジしたいと思います。
Contents
事前準備
パラメータを変更する前に、短縮したことが原因で発生するコミュニケーションパスの障害誤検知が、最終的にノード障害フェイルオーバーへとつながらないよう、事前にノード障害フェイルオーバーを停止します。これにより、短縮時間の測定テストで不要なノード障害フェイルオーバーの発生を抑止します。
ノード障害フェイルオーバーを無効化するためには、LifeKeeper GUI のノードで右クリックをして、Properties を選択します。以下のProperties Panel画面が開きますので、”Set Confirm Failover On”で該当するサーバーに全てチェックを入れてください。この項目にチェックすることでノード障害フェイルオーバーが発生しなくなります。この処理は念のため全てのノードを対象に行います。
パラメータの調整
ノード障害フェイルオーバーを停止した後、パラメータの値を調整して、コミュニケーションパスに流れるハートビートが途切れないかどうかログを監視します。最初に全ノードに対して、各パラメータの最小値を設定しました。最小値は以下となります。
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 # ハートビート切断と判定するまでの試行回数
- 両ノードの時間が一致している事を確認しました。
[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 ~]# - pd108がアクティブ、pd109 がスタンバイノードという状態で、pd108で以下のコマンドを実行してカーネルパニックを起こします。
# date ; sleep 1 ; echo c > /proc/sysrq-trigger
2016年 8月 25日 木曜日 17:25:43 JST
＊上記の時間の1秒後にカーネルパニックを引き起こしています。 - 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 - 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 # ハートビート切断と判定するまでの試行回数
- 両ノードの時間が一致している事を確認します。
[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 ~]# - pd108がアクティブ、pd109 がスタンバイノードの状態で、pd108で以下のコマンドを実行してカーネルパニックを起こします。
[root@pd108 ~]# date ; sleep 1 ; echo c > /proc/sysrq-trigger
2016年 8月 25日 木曜日 18:04:21 JST
＊上記の時間の1秒後にカーネルパニックを引き起こしています。 - 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 - 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はコミュニケーションパス障害を検出しますので、障害の誤検知となる場合もあります。
次回は、可用性を高めるその他の施策について確認します。
>>第3回 “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。～その他の短縮方法を考える を読む
