ソリューション

- 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

*注意: これにより、Storage Quorum が再初期化されます。

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 ドメインへの正常な 接続性が確保 されます。
   
   

*注意: S3 はグローバルサービスであっても、S3 バケットはリージョンにあります。

2. ping <bucketname>.s3.amazonaws.com を実行することで、ホストするS3 サービスの IP アドレスを解決します。こちらも1秒以下である必要があります。
   
   その他に検討する事は、このノードでのS3のアクティビティ全体に対して渡される データの量 です。ファイル転送で確認することもできます。ping を使用して応答時間の測定をすることも可能です。(上記の ping フォーマット) を参照してください。

*注意: AWS においては、S3 はグローバルサービスですが、EC2 ノードはリージョンサービスです。S3 URI (Amazon S3 storage Uniform Resource Identifier またはそのウェブアドレス) は、 特定のリージョン にあることがあります。

トラフィックがある場合とない場合を比較し、上記のハートビートの回数(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

- ミラーの 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 秒です。

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