クラスタソフトであるLifeKeeperを運用する上で覚えておくべきことをまとめておく。
【概要】
【構成】
【コマンド】
【障害時の動作と復旧方法】
【メンテナンス方法】
【ログ】
【プロセス】
【構成】
以下の構成で組んでいるものとする。
物理サーバ node1
論理リソース app1(アプリケーションリソース)
物理サーバ node2
論理リソース app2(アプリケーションリソース)
データの高可用性化方式としては以下の２つがある。
① 共有ディスク構成
外部ストレージを共有ディスクとして用いる
実装には外部ストレージが必要となる。
② データレプリケーション構成
サーバ毎に接続されたローカルディスクをレプリケーションすることで、
ミラーボリュームを作成し、共有ディスクとして扱う。
ここでは②を採用したものとして説明する。
②を選んだ理由は高価な外部ストレージが必要ないということが一番のメリットとなるだろう。
サーバ毎に接続されたローカルディスクをレプリケーションすることで、
ミラーボリュームを作成し、共有ディスクとして扱う。
物理的な制約がなくなるため、遠隔地へのフェイルオーバーも可能である。
デメリットとしてはスプリットブレインが発生する可能性があることだろうか。
共有ストレージ構成の場合は、それぞれのI/Oフェンシング機能によって、
両ノードでリソースがアクティブにならないように動作する。
しかし、データレプリケーション構成の場合には、そのような仕組みが無いため、
一次ノードのリソース状態に関係無く引継ノードでリソースの起動を開始しようとする。
スプリットブレイン発生時の復旧方法は後ほど記載する。
※ スプリットブレインを防ぐために、Quorum/Witness Server Kit パッケージの
導入を検討してもいいかもしれない。
２つのモードを選択できる。
・Quorum Check
・Witness Check
【コマンド】
◆ 確認コマンド
● バージョン確認
直接確かめる手段がなかったためパッケージから確認している。
RedHat系でrpmからインスタンスしていることを前提。
$ rpm -q steeleye-lk
steeleye-lk-*.*.*
下記の3プロセスが表示されれば正常に起動している。
# lktest
lcm
ttymonlcm
lcd
● フェールオーバ時の動作確認
# lcdstatus | grep strategy
The shutdown strategy is set to: switchover.
下のコマンドあたりでも確認できるだろう。
# flg_list
● リソース状況の確認
node1とnode2でクラスタを組んでおりnode1側で実行したとする。
# lcdstatus -q
-q : query
LOCAL TAG ID STATE PRIO PRIMARY
node1 app1 application1 ISP 1 node1 ← アプリケーションリソース
node1 ip1 192.168.0.1 ISP 1 node1 ← 共有IPリソース
node1 fs1 /fs1 ISP 1 node1 ← ファイルシステムリソース
node1 datarep1 /dev/sda ISP 1 node1 ← データレプリケーションリソース
node1 app2 application2 OSU 10 node2 ← アプリケーションリソース
node1 ip2 192.168.0.2 OSU 10 node2 ← 共有IPリソース
node1 fs2 /fs2 OSU 10 node2 ← ファイルシステムリソース
node1 datarep2 /dev/sda OSU 10 node2 ← データレプリケーションリソース
MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO
node2 TCP 192.168.1.1/192.168.1.2 ALIVE 1
node2 TCP 192.168.2.1/192.168.2.2 ALIVE 2
見方について一部説明しておく。
・リソースステータス
各種リソースのステータスである。
ISP : In Service Protected
リソースが正常に起動している状態
OSU : Out of Service Unimpaired
リソースが停止している状態
OSF : Out of Service Failed
直前にリソース停止や起動に失敗した状態
・コミュニケーションパスのステータス
ハートビートさせるネットワークのステータスである。
ALIVE
パスが接続している状態
DEAD
パスが断絶している状態
コミュニケーションパスのステータスはnode1側で確認すれば、
node2との通信状態が表示される。
・その他
ファイルシステムリソースとデータレプリケーションリソースが階層構造になっている。
データレプリケーションリソースはこのファイルシステムリソースにあるという意味である。
● データ同期の状態確認
※以後赤字は変数とする
# mirror_status データレプリケーションリソースタグ名
(例)
# mirror_status datarep1
Status: Fully Operational
[===================>] 100%
Type: Synchronous
Bitmap: 9193195 bits (chunks), 130385 dirty (1.4%)
フェールオーバ直後はすぐにデータレプリケーションリソースのミラーの同期ができない。
3分程度で同期できるまでそのリソースはフェールオーバをかけてはならない。
dirtyについては1chunks(クラスタ間の転送単位)中の溢れであり、
この%の高低は問題ない。
このprocファイル内でも進捗が確認できる。
# cat /proc/mdstat
● ポリシーの確認
リソース毎に障害が発生した場合のフェイルオーバ動作のポリシーを確認できる。
# lkpolicy --get-policies --verbose
◆ 操作コマンド
● クラスタの起動
# lkstart
● クラスタの停止
# lkstop
● リソースの起動
起動対象ノードにて最上位リソースを指定することで、
リソースグループ内の全てのリソースが起動する。
フェールオーバ先のノードで実行すること。
# perform_action -t リソースタグ名 -a restore
-t : tag name
-a : action name
(例)
node1側でnode1のリソースグループすべてを起動する。
# perform_action -t app1 -a restore
● 個別のリソースの起動
個別のリソースタグ名を指定し、-bオプションを付与するととそのリソースだけが起動する。
# perform_action -t ip1 -a restore -b
-b : changes this behavior
あるリソースがOSFになれば基本フェールオーバするが、
特定のリソースがOSFになってもフェールオーバさせないポリシーに
していることもあるだろう。そのような場合に利用することになる。
● リソースの停止
起動時とは異なり、指定したリソースタグ名より階層構造で上位に位置するリソースが全て停止する。
# perform_action -t リソースタグ名 -a remove
(例)
node1側でapp1のアプリケーションリソースのみを停止する。
# perform_action -t app1 -a remove
(例)
node1側で全リソースを停止する。
# perform_action -t datarep1 -a remove
● フェールオーバ
リソースの起動と同じである。
フェールオーバ先のノードで実行すること。
# perform_action -t リソースタグ名 -a restore
ログインしているノードでない場合は以下も利用できる。
# lcdremexec -d フェイルオーバ先ノード名 -- perform_action -t リソースタグ名 -a restore
(例)
node2側でnode1のリソースグループすべてを起動する。
# lcdremexec -d node2 --perform_action -t app1 -a restore
◆ 設定変更コマンド
● ポリシーの変更
両ノードで実行が必要である。
# lkpolicy --set-policy [Failover|LocalRecovery] --[on|off] tag=リソースタグ名
(例)
node1ノードのリソース共有IPリソースのフェイルオーバポリシーをオフにする。
# lkpolicy --set-policy Failover --off tag=ip1
● フェールオーバ動作の設定
フェールオーバさせる場合
# flg_create -f shutdown_switchover
フェールオーバさせない場合
# flg_remove -f shutdown_switchover
【障害時の動作と復旧方法】
● 物理故障時
① node1が物理故障
② node1のリソースがnode2へフェールオーバ
③ クラスタサービスの停止(まだnode1が動作している場合)
# lkstop
※念のためnode1サーバもシャットダウンしておいたほうがいいだろう。
④ node1が復旧
⑤ クラスタサービスの起動
# lkstart
⑥ 全てのデータレプリケーションリソースが同期状態であることを確認
# mirror_status datarep1
⑦ 手動フェールバック
# perform_action -t app1 -a restore
● スプリットブレイン発生時
コミュニケーションパス(クラスタノード間でクラスタやリソースの
情報のやりとりを行うために使う通信経路)が切断された場合に発生する可能性がある。
最初にも書いたが、共有ストレージ構成の場合は、それぞれのI/Oフェンシング機能によって、
両ノードでリソースがアクティブにならないように動作する。
しかし、データレプリケーション構成の場合には、そのような仕組みが無いため、
一次ノードのリソース状態に関係無く引継ノードでリソースの起動を開始しようとする。
① 引継ノード側で起動してしまったデータレプリケーションリソースと
ファイルシステムリソースを停止する。
node1側
# perform_action -t datarep2 -a remove
node2側
# perform_action -t datarep1 -a remove
② 引継ノード側で起動エラーとなった共有IPリソースのステータスをOSUに戻す
node1側
# perform_action -t ip2 -a remove
node2側
# perform_action -t ip1 -a remove
③ コミュニケーションパスの断線を復旧させる
④ コミュニケーションパスが復旧したことを確認する
# lcdstatus -q
MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO
nodeX TCP 192.168.1.1/192.168.1.2 ALIVE 1
nodeX TCP 192.168.2.1/192.168.2.2 ALIVE 2
⑤ 一次ノードから引継ノードにディスクの再同期が自動的に行われる
⑥ 全てのデータレプリケーションリソースが同期状態であることを確認する
# mirror_status datarep1
# mirror_status datarep2
● OSFの状態からなおらずフェールオーバできない場合
状況判断：下記のようなエラーログが出力される。
※リソース名は適時読み替えること
ERROR:dr:restore:datarep1:104086:The "datarep1_data_corrupt" flag is set
in "/opt/LifeKeeper/subsys/scsi/resources/netraid/" on system "node1".
To avoid data corruption, LifeKeeper will not restore the resource.
① OSFを含むデータレプレケーションリソースを外す。
・フェールオーバ先のノード(node1)で実行する場合
# perform_action -t datarep1 -a remove
・別クラスタノード(node2)から実行する場合
# lcdremexec -d node1 -- perform_action -t datarep1 -a remove
② flagファイルを削除
両ノードでできている可能性があるので両ノードで確認すること
# rm /opt/LifeKeeper/subsys/scsi/resources/netraid/<リソース名>_data_corrupt
③ リソース起動
・フェールオーバ先のノード(node1)で実行する場合
# perform_action -t datarep1 -a restore
・別クラスタノード(node2)から実行する場合
# lcdremexec -d node1 -- perform_action -t app1 -a restore
④ 同期確認
# mirror_status datarep1
● データの同期が取れない場合
もし、ファイルシステムのマウントに失敗してしまった場合は、
データ同期を強制的に行うことで復旧させることができる。
# mirror_action データレプリケーションリソース force 同期元となるサーバ名
(例）node1のdatarep1を強制同期する。
# mirror_action datarep1 force node1
【メンテナンス方法】
● システム全停止時の対応
① node1ノードにnode2ノードで管理しているリソースをフェイルオーバさせる
node1側
# perform_action -t app2 -a restore
② 全てのリソースステータスがISPになっていることを確認する
# lcdstatus -e
③ シャットダウンストラテジーを無効にする
node1側
# flg_remove -f shutdown_switchover
node2側
# flg_remove -f shutdown_switchover
④ シャットダウンする
node1側
# shutdown -h now
node2側
# shutdown -h now
● システム全起動時の対応
① サーバ起動
node1、node2で実施
② 全てのデータレプリケーションリソースが同期状態であることを確認
# mirror_status datarep1
# mirror_status datarep2
③ シャットダウン・ストラテジーを無効にする
node1側
# flg_create -f shutdown_switchover
node2側
# flg_create -f shutdown_switchover
● OSネットワークを再起動したい時
node1のnetworkをrestartするとする。
① フェールオーバ
# lcdremexec -d node2 -- perform_action -t app1 -a restore
② ネットワークを再起動するノードのクラスタ停止
# lkstop
③ ネットワーク再起動
# ネットワーク設定の変更
# /etc/init.d/network restart
④ クラスタ起動
# lkstart
⑤ フェールバック
# lcdremexec -d node1 -- perform_action -t app1 -a restore
【ログ】
ディフォルトはここである。
# tail -f /var/log/lifekeeper.log
INFO : 無視で問題なし
NOTIFY : 無視で問題なし
WARN : 調査必要
調査用に必要なシステム情報を一括で取得するコマンドもある。
# lksupport
30s程度で収集が終わる。
ファイル群はtar.gzされ、/tmp/配下に保存されたことが示される。
【プロセス】
プロセス名 役割
プロセス停止時にシステム影響あり
/opt/LifeKeeper/bin/lcm TCPによるハートビート通信の管理やクラスタを構成するノード間の通信についての管理を行うプロセス
/opt/LifeKeeper/bin/lcd LifeKeeper Configuration Database (LCD) を制御するプロセス
/opt/LifeKeeper/bin/ttymonlcm tty によるハートビート通信を監視しているプロセス
/opt/LifeKeeper/bin/lkcheck リソースの監視を管理するプロセス
システム影響はないがログが出なくなる
/opt/LifeKeeper/bin/lk_logmgr ログを管理するプロセス
システム影響なし(構成によって起動させていない場合もある)
/opt/LifeKeeper/bin/lkscsid リザベーションコマンドの発行により共有ディスクの監視を行うプロセス
/opt/LifeKeeper/bin/lkvmhad LifeKeeper を仮想環境にて使用するためのプロセス
/opt/LifeKeeper/bin/lkguiserver lkGUIserverコマンドによって制御されるGUIサーバのプロセス
/opt/LifeKeeper/sbin/steeleye-lighttpd Web ブラウザ経由で GUI を表示するために使用するサーバ
