- 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)、ご利用の環境において以下のコマンドを実行して接続に 問題がないこと を確認することを 推奨します

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

  1. 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

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

フィードバック

フィードバックありがとうございました

このトピックへフィードバック

送信