ソリューション

- Licensing -

サブスクリプションライセンスの有効期限を確認する方法

問題:

サブスクリプションライセンスの有効期限を確認するにはどうすればよいですか?

ソリューション:

1. 以下を入力します。
　 /opt/LifeKeeper/bin/lklicmgr

2. Expiry欄に、サブスクリプションライセンスの有効期限が表示されます。

- LifeKeeper Core -

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

ソリューションの詳細

問題:

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

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

ソリューション:

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

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

- NFS -

steeleye-lighttpdに必要なポートをNFSが使用しないように制限する方法

プロセスが使用する開始ポートを制限するには、次の手順を実行します。

NFS サーバー上

/etc/exports内

予約されていないポート (1024以上) へのアクセスを許可するには、“insecure”オプションを追加します。

例： /nfsmnt node-c(rw,insecure) node-d(rw,insecure)

NFSサーバーを再起動します。

例： exportfs -ra

NFSクライアント上

以下のファイルでポートの最小値と最大値を設定する。

/sys/module/sunrpc/parameters/min_resvport

/sys/module/sunrpc/parameters/max_resvport

“-o noresvport”オプションを使用してクライアントでfsをマウントします。

例：mount -t nfs -o noresvport scsi-targetA:/nfsmnt/ /nfsmnt/

例：mount -t nfs -o noresvport 11.0.13.138:/nfsmnt/ /nfsmnt/

netstatを使用して、NFSサーバーがマウントに使用しているポートを確認します。

例：netstat | grep scsi-targetA:nfs

　　out: tcp 0 0 node-d:4620 scsi-targetA:nfs ESTABLISHED

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

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

ソリューションの詳細

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

ソリューション:

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

LCMNUMHBEATS を 9 に変更します

LCMNUMHBEATS=9

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

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

# lkstop -f

# lkstart

*注意: これらの変更は、クラスター内の各ノードで行う必要があります。

LifeKeeper 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 が再初期化されます。

LifeKeeper 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

- 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は、バックアップサーバーの準備ができていると判断すると、プライマリーサーバーからバックアップサーバーへの再同期を開始します。

!以下の順序でシステムを起動しないと、data_corruptフラグが立ってしまい、ユーザーの介入が必要になる場合があります。

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

- SAP

Polkitを使用したSAPおよびS/4HANA 2022の導入

一部のデプロイメントでは、ASCSおよびERSのインスタンスを異なるクラスターノードにインストールし、共有ストレージを使用して各インスタンスのプロファイルをファイル共有経由で利用可能にする場合があります。sapmntおよびインスタンスディレクトリー(/sapmnt/<SID> and /usr/sap/<SID>/{ASCS10,ERS20,SYS}) がファイル共有上に存在する場合、ASCSおよびERSの各インスタンスを一つのノードにのみインストールすることでも、すべてのインスタンスファイル（およびプロファイルなど）をすべてのノードで利用可能にします。

以下の項目に進む前に、S/4HANA 2022を使用するデプロイメントのための以下の依存関係が満たされていることを確認してください。

• S/4HANA 2022を使用する場合は、“compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm“パッケージをダウンロードしてインストールします。
• 上記のパッケージをインストールした後、/usr/sap/libディレクトリーを作成します（mkdir -p /usr/sap/lib）
• /usr/sap/lib/libstdc++.so.6からのシンボリックリンクを/opt/rh/SAP/lib64/compat-sap-c++-10.soに作成します（ln -s /opt/rh/SAP/lib64/compat-sap-c++-10.so /usr/sap/lib/libstdc++.so.6）
• /usr/sap/lib ディレクトリーとそのファイルの所有権を変更します（ chown -R <SID>adm:sapsys /usr/sap/lib）
  
  このようなデプロイメントでは、SAP/S4HANAリソースを確実に保護するために、以下に列挙する追加の手順を実行する必要があります。
  
  
• /usr/sap/sapservicesファイルは、各クラスターノードごとに不完全であり、そのクラスターノードにインストールされているインスタンスの情報のみが含まれます。各ノードのsapservicesファイルをマージし、それを各クラスターノードの/usr/sap/sapservicesにコピーする必要があります。以下に、このマージが完了したsapservicesファイルのサンプルです。
  
  /usr/sap/sapservicesファイルのサンプル：
  
  

#ASCSを開始するためのルール
systemctl --no-ask-password start SAP<SID>_10 # sapstartsrv pf=/usr/sap/<SID>/SYS/profile/<SID>_ASCS10_<ascs-vhost>

#ERSを開始するためのルール
systemctl --no-ask-password start SAP<SID>_20 # sapstartsrv pf=/usr/sap/<SID>/SYS/profile/<SID>_ERS20_<ers-vhost>

S/4 HANA 2022以降を使用する場合、各インスタンスのSAP Start Service（sapstartsrv）はsystemdによって管理されます。このサービスのファイルは/etc/systemd/system/SAP<SID>_<InstNo>.serviceにあります。以下の手順は、S/4 HANA 2022以降を使用するデプロイメントのためのものです。

• ASCSインスタンスサービスは、インストールされた1つのノードにのみ存在します。ファイル /etc/systemd/system/SAP<SID>_<InstNo>.service をクラスター内の他のノードの同じパスにコピーします。
  

• ERSインスタンスサービスは、インストールされた1つのノードにのみ存在します。ファイル /etc/systemd/system/SAP<SID>_<InstNo>.service をクラスター内の他のノードの同じパスにコピーします。

<sid>admユーザーは、PolicyKit（またはpolkitとも呼ばれる）のルールを通じて、前述のsystemdサービスの管理を許可する権限を付与する必要があります。これらのルールが設定されていない場合、SAPリソースのスイッチオーバー試行は“interactive authentication required（対話型認証が必要です）“というエラーで失敗します。polkit が正しく構成されていることを確認するには、次の項目を参照してください。

• ASCS インスタンスは単一ノードにのみインストールされているため、ファイル/etc/polkit-1/rules.d/10-SAP<SID>-<InstNo>.rules は他のクラスターノードには存在しません。 このファイルは、スイッチオーバー実行時の認証ベースのエラーを防ぐために、 ASCSインストールを保持するノードから他のクラスターノードにコピーする必要があります。

• ERS インスタンスは単一ノードにのみインストールされているため、ファイル /etc/polkit-1/rules.d/10-SAP<SID>-<InstNo>.rules は他のクラスターノードには存在しません。 このファイルは、スイッチオーバー実行時の認証ベースのエラーを防ぐために、ERSインストールを保持するノードから他のクラスターノードにコピーする必要があります。

• 上記の 2 つの手順を完了したら、polkit を再起動し (systemctl restart polkit)、新しいルールを有効にします。

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

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

- EC2 -

Curl 呼び出しが失敗しました (err=7)(output=curl: (7) 接続に失敗しました (EC2 Kit)

ソリューションの詳細

ISSUE:
AWS CLI と EC2 Recovery Kit で問題が発生します。
ログには、Curl 呼び出し (AWS CLI から IMDS) が err=7 で失敗し、その後、quickcheck スクリプトがチェックを誤りフェイルオーバーがトリガーされたことが示されています。 フェイルオーバーは、curl 呼び出しのタイムアウトが 5 秒と短すぎて、AWS の断続的なネットワーク問題によってトリガーされたため、フェイルオーバーは必要ありませんでした。curl 呼び出しにもう少し時間があれば、フェイルオーバーは防止できます。

エラーメッセージ：
ERROR:ec2:quickCheck:ec2-1.1.1.1:123456:curl call failed
(err=7)(output=curl: (7) Failed to connect to 169.254.169.254 port 80:
Connection refused)

169.254.169.254 port 80 is the AWS Instance MetaData Service

ソリューション:
このような不必要なフェイルオーバーの発生を防ぐために、/etc/defaults/LifeKeeper で変更できる調整可能なパラメーターがあります。 変更するパラメーターは次のとおりです。
LK_CURL_TIMEOUT=X

• このパラメーターのデフォルト値は 5 です。
• /etc/defaults/LifeKeeper ファイルに調整可能な行が存在しない場合、値は 5 に設定されます。

変更するには、数値を変更するか、パラメーターが存在しない場合は次の行を追加します。
LK_CURL_TIMEOUT=10

ご利用の環境で発生する可能性のある、断続的なネットワーク障害の長さに基づいて、タイムアウト値を少しずつ増やしてください。
一般的に、タイムアウト値を 10 にすると、ほとんどのネットワーク障害の問題が回避されるようです。

注意:
10 に変更しても問題が再び発生する場合は、値を数秒増やしてください。