- SAP/Oracle パッチ適用 -

DataKeeper を使用した Oracle ノード(SAP/Oracle)へのパッチ適用

ソリューションの詳細

ほとんどの Oracle のアップデート/パッチ適用にはシステムテーブルドライブへのアクセスのみが必要であり、データードライブ(保護されたDataKeeperのデータードライブ)へのアクセスは必要ありません。

一般的には以下の手順で行うことができます。

手順を開始する前にプライマリーでブロックフェイルオーバーを設定し、ターゲットでフェイルオーバーを確認します。

  1. スタンバイ/ターゲットサーバーで、以下を実施します。
    1. 適切なアップグレード、パッチなどを適用します。
    2. サーバーを再起動します。
  2. 次に、リソースをアクティブ/ソースサーバーからスタンバイ/ターゲットサーバーにスイッチオーバーします。
    1. Oracle データベースにアクセスできることを確認します。
  3. もう一方のノード(この時点ではスタンバイノード、手順の当初はアクティブ/ソースサーバー)で、以下を実施します。
    1. 適切なアップグレード、パッチなどを適用します。
    2. サーバーを再起動します。
  4. (オプション)再度スイッチオーバーを実行し、元のアクティブ/ソースサーバーの Oracle への接続とアクセスを確認します。

パッチが DataKeeper ボリュームへのアクセスを必要とする場合(例:catsbp の実行など)は、ミラーを一時停止/ロック解除して、スタンバイ/ターゲットシステムでアップグレードを実行する必要があります。

バックアップで Oracle を起動できることを確認してから、バックアップノードで Oracle を停止し、ミラーリングを続行します。次に、ソースシステムでアップグレードを繰り返します。

手順の最後に、プライマリーの「block failover」フラグとターゲットの「confirm failover」フラグを削除します。

- 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 を変更前の値に設定してください。

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

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

フィードバック

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

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

送信