ソリューション

- LifeKeeper Core -

アクションを実行する前に LifeKeeper が起動するのに十分な時間を与える

ソリューションの詳細

問題:

LifeKeeper を介してアクションを実行する前に起動するための十分な時間が許可されていない場合、特定のプロセスの初期化が完了していない可能性があるため、アクションが失敗するべきではないときにアクションが失敗するという特定のシナリオが発生する可能性があります。LifeKeeper の起動とプロセスの初期化に十分な時間を確保することが重要です。

同じアクティビティの一部として複数のノードで LifeKeeper を開始する場合、1 つのノードで lkstart を実行するときは、次のノードで lkstart を実行する前に終了するのに十分な時間を与えることが重要です。

ソリューション:

起動時に実行されるいくつかのプロセスにはさまざまな時間がかかるため、他の場所で LifeKeeper を起動したり、アクションを実行したりする前に待機すべき時間は決まっていません。同様に、起動のたびに同じ時間がかかるわけではないので、一度測定した時間が常に正確であると仮定しないでください。

代わりに、LifeKeeper のログを使用して、起動と初期化がいつ完了したかを判断してください。 LifeKeeper が起動時に最後に行うことは、LifeKeeper リソースの初期化です。 LifeKeeper の最新の起動後に「RESOURCE INITIALIZATION FINISHED」というログメッセージが表示されたら、クラスタ内の次のノードで起動するか、LifeKeeper GUI または CLI を介してアクションを実行しても問題ありません。

- Storage Quorum -

SPS for Linux: Storage Quorumを使用する際のハートビートに関する推奨事項

ソリューションの詳細

問題:
Storage Quorumを使用する際のハートビートに関する推奨事項について

ソリューション:

Storage Quorum を使用する 場合、 SIOS では LCMNUMHBEATS を増やして、パスが障害と判定されるまでの時間を長くすることを推奨しています。これにより、タイムアウト期間がデフォルトの15秒から45秒に変更されます。

LCMNUMHBEATS を 9 に変更します

LCMNUMHBEATS=9

コアパラメータを変更することになるので、LifeKeeperを再起動する必要があります。

サービスの停止時間を最小限に抑える には, “lkstop -f“ を使用するとリソースを実行したままにすることができます。
LifeKeeperが停止している間は、保護されたリソースの障害は検出または対処されません。

# lkstop -f

# lkstart

SPS for Linux: ノード間の通信が失われたときに、Storage Quorumはフェイルオーバーを防止できない

ソリューションの詳細

問題:
Storage Quorumの構成が不完全なため、通信処理が失われたときに障害が発生する

ソリューション:

qwk_storage_init をクラスター内の各ノードで実行する前に、クラスターノード間のすべてのコミュニケーションパスを作成し、 “ALIVE” にする必要があります。

これがうまくいかない場合 は、すべてのコミュニケーションパスが ALIVE になってから、以下のコマンドを実行して Storage Quorum 構成を再初期化してください。

# /opt/LifeKeeper/bin/qwk_storage_exit

# /opt/LifeKeeper/bin/qwk_storage_init

SPS for Linux: Amazon S3 ストレージを使用する場合の storage quorum パラメーターの推奨値

ソリューションの詳細

問題:
Amazon S3 ストレージを使用する場合の storage quorum パラメーターの推奨値について

ソリューション:

ドキュメントに従って storage quorum を設定したら、ハートビートのパラメーターを設定します。
詳細はこちら

いくつかの方法 で、あなたの環境においてデフォルトの設定が十分なものになっているか確認することができます。

2つの主要なパラメーターがあります。

QWK_STORAGE_HBEATTIME (デフォルト値: 6) – QWK オブジェクトを読み書きする間隔を 秒単位 で指定します。
QWK_STORAGE_NUMHBEATS (デフォルト値 :4) – Witness チェックで対象ノードに障害が発生していると判断するための値を指定します。QWK オブジェクトの読み込みにおいて、このパラメーターに指定した 回数以上更新が停止 していると、対象ノードに障害が発生していると判断します。

Amazon S3 bucketを使用してQWK オブジェクトを保存する場合 (QWK_STORAGE_TYPE=aws_s3)、ご利用の環境において以下のコマンドを実行して接続に 問題がないこと を確認することを 推奨します 。

ping s3.amazonaws.com を実行し、応答時間が1秒以下であることを確認してください。この操作により、EC2 ノードからグローバル AWS ドメインへの正常な 接続性が確保 されます。

ping <bucketname>.s3.amazonaws.com を実行することで、ホストするS3 サービスの IP アドレスを解決します。こちらも1秒以下である必要があります。

その他に検討する事は、このノードでのS3のアクティビティ全体に対して渡される データの量 です。ファイル転送で確認することもできます。ping を使用して応答時間の測定をすることも可能です。(上記の ping フォーマット) を参照してください。

トラフィックがある場合とない場合を比較し、上記のハートビートの回数(QWK_STORAGE_NUMHBEATS) およびハートビートの時間 (QWK_STORAGE_HBEATTIME) を調整することが可能です。

上記パラメーターは qwk_storage_init を実行する前に指定する必要があります。

ほとんどの場合 また ping 応答が1秒以下の場合はデフォルト値で十分ですが、S3 が遅延するもしくはデグレードしているように見える場合は、 QWK_STORAGE_HBEATTIME の値を増やすことをお勧めします。デフォルトの 6 から 7 へ変更してください。これによりタイムアウト値が 24 秒 (6 × 4) から 28 秒 (7 × 4) に増加します。タイムアウト値を 30 秒以上にすることは推奨しません。

デフォルト値を変更する場合は、 クラスター内の各ノード で変更を行い、すべてのコミュニケーションパスが ALIVE になっている状態で、クラスター内の各ノードで以下のコマンドを実行して Storage Quorum 構成を再初期化してください。

# /opt/LifeKeeper/bin/qwk_storage_exit

# /opt/LifeKeeper/bin/qwk_storage_init

- Majority Mode -

Witnessノードを使用したLifeKeeperのシャットダウンと再起動の手順

1. lkstop を使用してバックアップ（ターゲット）サーバーを停止します。

lkstop コマンドが完了するのを待ちます。lkstop が完了したことをログエントリーで確認します。

NOTIFY:shutdown:::010055:LifeKeeper stopped

Quorum メッセージ:

NOTIFY:event.comm_down:::010469:We do have quorum on comm_down, continuing

通常は2分未満で完了します

2. lkstop を使用してプライマリー（ソース）サーバーを停止します。

lkstop コマンドが完了するのを待ちます。lkstop が完了したことをログエントリーで確認します。

NOTIFY:shutdown:::010055:LifeKeeper stopped

Quorum メッセージ:

NOTIFY:event.comm_down:::010469:We do have quorum on comm_down, continuing

通常は2分未満で完了します

3. lkstop を使用して、WitnessノードでLifeKeeperを停止します。

lkstop コマンドが完了するのを待ちます。lkstop が完了したことをログエントリーで確認します。

NOTIFY:shutdown:::010055:LifeKeeper stopped

通常は2分未満で完了します

4. lkstart を使用してWitnessサーバーを起動します。

lkstart コマンドが完了するのを待ちます。lkstart が完了したことをログエントリーで確認します。

INFO:event.lcm_avail:::010479:RESOURCE INITIALIZATION FINISHED

通常は2分未満で完了します

5. lkstart を使用してバックアップ（ターゲット）サーバーを起動します。

lkstart コマンドが完了するのを待ちます。lkstart が完了したことをログエントリーで確認します。

INFO:event.lcm_avail:::010479:RESOURCE INITIALIZATION FINISHED

Quorum メッセージ:

INFO:event.comm_up:::010490:We do have quorum on comm_up to <node>, putting resources into service if needed

通常は2分未満で完了します

6. lkstart を使用してプライマリー（ソース）サーバーを起動します。

lkstart コマンドが完了するのを待ちます。lkstart が完了したことをログエントリーで確認します。

INFO:event.lcm_avail:::010479:RESOURCE INITIALIZATION FINISHED

Quorum メッセージ:

INFO:event.comm_up:::010490:We do have quorum on comm_up to <node>, putting resources into service if needed

通常は2分未満で完了します

この順序でサーバーを停止することにより、リソースはプライマリーサーバーでIn-Serviceのままになります（フェイルオーバーは開始されません）。バックアップサーバーが停止したときにミラーはIn-Serviceではなかったため、サーバーが復旧してもミラーはIn-Serviceにならず、Out-of-Service（OSU）状態のままになります。

LifeKeeperがプライマリーサーバーで起動すると、LKはミラーをIn-Serviceにします。これは、LifeKeeperがダウンしたときにミラーがISPであり、バックアップサーバーではIn-Serviceになっていないためです。LifeKeeperは、バックアップサーバーの準備ができていると判断すると、プライマリーサーバーからバックアップサーバーへの再同期を開始します。

- SAP HANA -

HANA データベースにパッチを適用する手順

ソリューションの詳細

問題:
HANA データベースのパッチ適用手順について教えてください。

ソリューション:

Node 1 = source
Node 2 = backup

Node 1で quickCheck を無効にします。 /etc/default/LifeKeeperファイルのLKCHECKINTERVAL の値を 0 に設定し、killall コマンドで lkcheck プロセスをkillしてください。
Node 2で “lkstop -f” を実行して LifeKeeper を停止してください。
1. a.HSRがNode 1と2で実行されていることを確認してください。
Node 2で HANA を停止してパッチを適用してください。
Node 2で HANA を起動してください。
1. a.HSR が引き続き実行中であることを確認してください。
Node 2で “lkstart” を実行して LifeKeeper を起動してください。
Node 2へ HANA に関連するリソースをスイッチオーバーします。
上記の手順を繰り返し、Node 1にパッチを適用します
必要に応じてNode 1にリソースをスイッチオーバーしてください。
quickCheck を有効にします。
　/etc/default/LifeKeeperファイルの LKCHECKINTERVAL を変更前の値に設定してください。

- ミラーの Quickcheck が常に失敗と回復を繰り返す -

ミラーの Quickcheck が常に失敗と回復を繰り返す

ソリューションの詳細

問題:
lifekeeper.log を見ると、ミラーが常にクイックチェックに失敗していることがわかりますが、recover は常に機能しています。

メッセージの例:

NOTIFY:lcd.recmain:recover:datarep-data:011115:BEGIN recover of “datarep-data” (class=netraid event=recover)
INFO:dr:recover:datarep-data:104008:/dev/md0: merging bitmap from target “SV-GCS-LIVEB”*
*Oct 5 05:57:07 SP-GCS-LIVEA recover [11754]: INFO:dr:recover:datarep-data:104009:/dev/md0: bitmap merged, resyncing 2.3
*Oct 5 05:57:12 SP-GCS-LIVEA recover [11754]:
INFO:dr:recover:datarep-data:104095:Partial resynchronization of component “/dev/nbd1” has begun for mirror “/dev/md0”*

これは通常、nbd とメッセージログのエラーが一致します。

Oct 5 05:56:59 SP-GCS-LIVEA kernel: [5499433.410998] nbd (pid 7278: nbd-client) got signal 9
Oct 5 05:56:59 SP-GCS-LIVEA kernel: [5499433.411003] nbd1: shutting down socket
Oct 5 05:56:59 SP-GCS-LIVEA kernel: [5499433.411015] nbd1: Receive control failed (result -4)
Oct 5 05:56:59 SP-GCS-LIVEA kernel: [5499433.411039] nbd1: queue cleared

Oct 5 05:57:11 SP-GCS-LIVEA nbd-client: Begin Negotiation
Oct 5 05:57:11 SP-GCS-LIVEA nbd-client: size = 268434407424
Oct 5 05:57:11 SP-GCS-LIVEA nbd… (truncated, see original email for full text)

解決方法:

これらのメッセージは、レプリケーション接続を切断させる nbd の問題を示しているようです。 LifeKeeper ログ内の recover による再同期は、切断された接続を再確立するための反応です。

ミラーが作成されると、その状態は quickCheck とソースの mdadm プロセスによって監視されます。quickCheck プロセスはいくつかの項目をチェックし、 (/proc/mdstat の情報から) ミラーが同期していないことを検出した場合、ターゲットに ping できない場合、ターゲットの状態がアクティブでない場合、または nbd-client/nbd-server プロセスが実行されていないことを検出した場合に、recover イベントを発行します。

recover は、mdadm 監視プロセスを介した md ドライバーからのイベントに基づいても開始されます。これには、Fail、FailSpare、および DegradedArray イベントが含まれます (これらは mdadm のマニュアルページに記載されています) 。

これらのイベントは、md ドライバーが検出した問題を示しており、LifeKeeper はドライバーと同じ状態になるように対応する必要があります。さらに、ミラーが使用しているコミュニケーションパスがダウンした場合も、recover イベントが発生します。

1 つのチューニングオプションがあります。

NBD_XMIT_TIMEOUT パラメータの値を大きくします。NBD_XMIT_TIMEOUT のデフォルト値は 6 秒です。

この値をあまり大きくしないように注意してください。この値によりパケット転送での実際のハング状態が検出され、接続をリセットしてミラーリングを再開します。待機時間が長すぎると、ソースでの書き込みがハングし、最終的にはシステムがハングする可能性があります。

トラブルシューティング

SPS/LifeKeeper が開始するフェイルオーバの一般的な原因