SAP 高可用性構成のトラブルシューティング

Google Cloud 上の SAP 高可用性構成で問題が発生した場合、その根本原因はクラスタリング ソフトウェア、SAP ソフトウェア、Google Cloud インフラストラクチャ、またはこれらの組み合わせに存在する可能性があります。

Cloud Logging で Pacemaker ログを分析する

次の動画では、Cloud Logging を使用して Google Cloud 上の SAP の高可用性構成のトラブルシューティングを行う方法を説明します。

Linux クラスタ内の障害ノードがフェイルオーバー後に正しく再起動しない

Linux 高可用性クラスタが fence_gce フェンス エージェントを使用していて、フェンシングされた VM がフェイルオーバー後にクラスタに再参加できない場合は、フェンシングされた VM の再起動時に Corosync ソフトウェアの起動を遅らせる必要があります。

問題

fence_gce エージェントは、フェイルオーバー時に障害のある Compute Engine VM をフェンシングします。これにより、Pacemaker がフェンス アクションを完了と登録する前に、クラスタが再起動して再接続されます。フェンス アクションは登録されていないため、再起動された VM は Pacemaker サービスと Corosync サービスをシャットダウンし、クラスタから離れます。

診断

これが問題かどうか確認するには:

• クラスタが fence_gce エージェントを使用していることを確認します。

  RHEL

  pcs config

  SLES

  crm config show

  フェンス エージェントの定義には fence_gce が含まれています。

  RHEL

  Stonith Devices:
  Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce)
  Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a
  Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s)
  Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce)
  Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c
  Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)
  

  SLES

  primitive fence-example-ha-vm1 stonith:fence_gce \
   op monitor interval=300s timeout=120s \
   op start interval=0 timeout=60s \
   params port=example-ha-vm1 zone=us-central1-a project=example-project-123456
  primitive fence-example-ha-vm2 stonith:fence_gce \
   op monitor interval=300s timeout=120s \
   op start interval=0 timeout=60s \
   params port=example-ha-vm2 zone=us-central1-c project=example-project-123456

• システムログで次のメッセージを確認します。

  DATESTAMP> node2 stonith-ng[1106]:  notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK
  DATESTAMP> node2 stonith-ng[1106]:   error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL
  DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply
  DATESTAMP> node2 crmd[1110]:    crit: We were allegedly just fenced by node1 for node1!
  DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure

解決策

Corosync の起動を遅らせるように両方のクラスタノードのオペレーティング システムを構成し、フェンス アクションで新しいプライマリ ノードの Pacemaker が完了登録を行う時間を確保します。また、遅延に対応するため、Pacemaker の再起動タイムアウト値を設定します。

Corosync の遅延起動を構成するには:

1. クラスタをメンテナンス モードにします。

   RHEL

   pcs property set maintenance-mode=true

   SLES

   crm configure property maintenance-mode="true"

2. root として、各クラスタノードで Corosync の起動遅延を設定します。

   1. systemd ドロップイン ファイルを作成します。

      systemctl edit corosync.service

   2. このファイルに次の行を追加します。

      [Service]
      ExecStartPre=/bin/sleep 60

   3. ファイルを保存し、エディタを終了します。

   4. systemd マネージャー構成を再読み込みします。

      systemctl daemon-reload

3. ルートとしたいずれかのクラスタノードで、再起動するまでの Pacemaker のタイムアウト値が両方のフェンス エージェントに設定されていることを確認します。

   1. pcmk_reboot_timeout の値を確認します。

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      FENCE_AGENT_NAME は、フェンス エージェントの名前に置き換えます。

   2. pcmk_reboot_timeout パラメータが見つからない場合、またはその値が 300 より小さい値に設定されている場合は、両方のフェンス エージェントで値を設定します。

      crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300

      FENCE_AGENT_NAME は、フェンス エージェントの名前に置き換えます。

      pcmk_reboot_timeout の値は、以下の合計値よりも大きい値とする必要があります。

      • Corosync token のタイムアウト
      • デフォルトでは、Corosync コンセンサスのタイムアウトは token × 1.2 です。
      • 遅延属性を含め、再起動が完了するまでの時間の長さ。

      Google Cloud の場合、ほとんどのクラスタで 300 秒あれば十分です。

   3. 新しい pcmk_reboot_timeout 値を確認します。

      crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout

      FENCE_AGENT_NAME は、フェンス エージェントの名前に置き換えます。

4. クラスタのメンテナンス モードを終了します。

   RHEL

   pcs property set maintenance-mode=false

   SLES

   crm configure property maintenance-mode="false"

特定のノードを優先する意図しないノード アフィニティ

クラスタ コマンドを使用して高可用性クラスタ内のリソースを手動で移動すると、特定のノードを優先するように自動アフィニティまたはクライアントが設定されます。

問題

SAP HANA または SAP NetWeaver の Linux Pacemaker 高可用性クラスタで、SAP HANA システムや SAP NetWeaver セントラル サービスなどのリソースが特定のクラスタノードでのみ実行され、ノード障害イベント中に想定どおりにフェイルオーバーされません。

その結果、次のような問題が発生する可能性があります。

• リソースのクラスタノードへの Pacemaker コマンド（move）を発行して SAP NetWeaver ASCS サービスのフェイルオーバーをトリガーすると、リソースは開始されず、ステータス stopped が表示されます。

• 一方のクラスタノードに standby コマンドを実行して、すべてのリソースをもう一方のノードに強制的に移動しても、リソースが開始しません。

診断

• Pacemaker ログで、特定のリソースが稼働できないことを示すメッセージを確認します。次に例を示します。

  2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info:
   Resource NW1-ASCS01 cannot run anywhere

• Pacemaker ロケーション制約の構成を確認して、特定のクラスタノードでのリソースの実行を妨げる可能性のある制約を特定します。

  Pacemaker ロケーション制約の構成を確認する手順は次のとおりです。

  1. ロケーション制約を表示します。

     cibadmin --query --scope constraints | grep rsc_location

  2. ロケーション制約を確認します。

     • 明示的なロケーション制約: スコアが INFINITY（ノードを優先）または -INFINITY（ノードを回避）のロケーション制約を見つけます。次に例を示します。

       <rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>

       フェンス エージェント以外に、スコアが INFINITY または -INFINITY のロケーション制約があってはなりません。フェンス エージェントは、フェンシング ターゲットであるノードでの動作を防ぐため、すべての HA クラスタでスコアが -INFINITY のロケーション制約に定義されています。

     • 暗黙的なロケーション制約: Pacemaker コマンドを実行してクラスタをクラスタノードに移動するか、クラスタノードでのリソースの実行を禁止すると、接頭辞が cli-ban または cli-prefer の暗黙的なロケーション制約が制約 ID に追加されます。次に例を示します。

       <rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>

解決策

• ロケーション制約が、次のデプロイガイドで説明されているように指定されていることを確認します。

  • RHEL での SAP HANA の HA スケールアップ クラスタ構成ガイド
  • SLES での SAP HANA の HA スケールアップ クラスタの構成ガイド
  • RHEL での SAP NetWeaver HA クラスタの手動構成ガイド
  • SLES での SAP NetWeaver HA クラスタの手動構成ガイド

• 明示的なロケーション制約を修正するには、ロケーション制約を削除します。

  RHEL

  pcs constraint remove RESOURCE_LOCATION_ID

  SLES

  crm configure delete RESOURCE_LOCATION_ID

  RESOURCE_LOCATION_ID は、ロケーション制約 ID に置き換えます。

• 暗黙的なロケーション制約を修正するには、指定したリソースで定義されているすべての制約を削除します。

  リソースの移動または禁止に使用するコマンドを実行するたびに、次のコマンドを実行して、すべての制約を削除します。

  RHEL

  pcs resource clear RESOURCE_NAME

  SLES

  crm resource clear RESOURCE_NAME

  RESOURCE_NAME は、移動するリソースの名前に置き換えます。

フェンス エージェントのオペレーション エラー

フェンス エージェントからクラスタのエラー ステータスが報告されました。

問題

SAP HANA または SAP NetWeaver の Linux Pacemaker 高可用性クラスタで、フェンス エージェントがクラスタのエラー ステータスを報告しました。例:

Failed Resource Actions:
   STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='',  last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms

診断

SAP HANA または SAP NetWeaver 高可用性クラスタにデプロイされたフェンス エージェントは、Compute Engine API サーバーに定期的にアクセスして、フェンス ターゲット インスタンスのステータスを確認します。API 呼び出しのレスポンスに一時的な遅延が発生したり、ネットワークの中断が発生した場合、フェンス エージェントのモニタリング オペレーションが失敗するか、タイムアウトする可能性があります。

フェンス エージェントのステータスを確認するには、次のコマンドを実行します。

RHEL

pcs status

SLES

crm status

フェンス エージェントのステータスが stopped の場合、以下の解決策のいずれかを行ってエラーを解決します。

フェンス エージェントのオペレーション エラーでフェンス エージェントが停止する可能性がありますが、Pacemaker はフェンシング イベントで停止ディレクティブを使用してフェンス エージェントを呼び出します。

解決策

フェンス エージェントのステータスが stopped の場合は、次のいずれかを行います。

• 次のコマンドを実行して、障害カウントを手動でリセットし、フェンス エージェントを再起動します。

  RHEL

  pcs resource cleanup FENCE_AGENT_NAME

  SLES

  crm resource cleanup FENCE_AGENT_NAME

  FENCE_AGENT_NAME は、フェンス エージェントの名前に置き換えます。

• フェンス エージェントのオペレーション エラーを自動的に削除するには、failure-timeout パラメータを構成します。

  failure-timeout パラメータは、指定された期間が経過すると障害カウントをリセットし、オペレーション エラーをすべてクリアします。このパラメータを適用するために、クラスタを再起動したり、クラスタをメンテナンス モードにする必要はありません。

  failure-timeout パラメータを構成するには、次のコマンドを実行します。

  crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION

  次のように置き換えます。

  • FENCE_AGENT_NAME: フェンス エージェントの名前。
  • DURATION: 最後のオペレーションの失敗後、障害カウントがリセットされてフェンス エージェントが再起動されるまでの時間。

フェンス エージェント gcpstonith のサポート終了

構成でフェンス エージェント gcpstonith が有効になっています。このエージェントはサポートが終了しており、カスタマーケアから fence_gce への切り替えの必要性をお知らせしています。

問題

SUSE Linux 上の SAP HANA 用の Linux Pacemaker 高可用性クラスタで、フェンス エージェント gcpstonith が使用されています。例:

 # crm status | grep gcpstonith
   * STONITH-hana-vm1   (stonith:external/gcpstonith):   Started hana-vm2
   * STONITH-hana-vm2   (stonith:external/gcpstonith):   Started hana-vm1

診断

SAP HANA 高可用性クラスタにデプロイされたフェンス エージェントを更新して、OS バンドルの fence_gce フェンス エージェントを代わりに使用する必要があります。gcpstonith エージェント スクリプトは以前のシステムで提供されていましたが、fence_gce に置き換えられました。fence_gce は、fence-agents SUSE Linux パッケージの一部として提供されます。gcpstonith は、SUSE Linux HANA デプロイメントの一部としてのみ提供されていました。

解決策

SUSE Linux の gcpstonith から移行する手順は次のとおりです。

1. オペレーティング システムに固有の次の追加パッケージをインストールします。

   • SLES 15 の場合: python3-oauth2client、python3-google-api-python-client

   • SLES 12 の場合: python-google-api-python-client、python-oauth2client、python-oauth2client-gce

   これらのパッケージをオペレーティング システムにインストールするには、次のコマンドを使用します。

   SLES 15

   zypper in -y python3-oauth2client python3-google-api-python-client

   SLES 12

   zypper in -y python-google-api-python-client python-oauth2client python-oauth2client-gce

2. fence-agents パッケージを更新して、最新バージョンがインストールされている状態にします。

   zypper update -y fence-agents

3. クラスタをメンテナンス モードにします。

   crm configure property maintenance-mode=true

4. クラスタからすべてのフェンシング デバイスを削除します。最後のフェンシング デバイスを削除するときに、クラスタに STONITH リソースが定義されていないことを確認するよう求められる場合があります。

   crm configure delete FENCING_RESOURCE_PRIMARY

   crm configure delete FENCING_RESOURCE_SECONDARY

5. プライマリ インスタンスのフェンシング デバイスを再作成します。

   crm configure primitive FENCING_RESOURCE_PRIMARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="PRIMARY_INSTANCE_NAME" zone="PRIMARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

6. セカンダリ インスタンスのフェンシング デバイスを再作成します。

   crm configure primitive FENCING_RESOURCE_SECONDARY stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="SECONDARY_INSTANCE_NAME" zone="SECONDARY_ZONE" \
    project="PROJECT_ID" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

7. ロケーションの制約を設定します。

   crm configure location FENCING_LOCATION_NAME_PRIMARY \
    FENCING_RESOURCE_PRIMARY -inf: "PRIMARY_INSTANCE_NAME"
   
   crm configure location FENCING_LOCATION_NAME_SECONDARY \
    FENCING_RESOURCE_SECONDARY -inf: "SECONDARY_INSTANCE_NAME"
   

8. クラスタのメンテナンス モードを終了します。

   crm configure property maintenance-mode=false

9. 構成を確認します。

   crm config show related:FENCING_RESOURCE_PRIMARY
   

10. クラスタのステータスを確認します。

    # crm status | grep fence_gce
      STONITH-hana-vm1   (stonith:fence_gce):   Started hana-vm2
      STONITH-hana-vm2   (stonith:fence_gce):   Started hana-vm1
    

リソース エージェントが停止している

リソース エージェントの起動に失敗したため、ステータスが Stopped のままになっています。

問題

SAP HANA または SAP NetWeaver の Linux Pacemaker 高可用性クラスタで、リソース エージェントがクラスタのエラー ステータスを報告しました。次に例を示します。

Failed Resource Actions:
   rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms

診断

実行中のリソース エージェントが失敗した場合、Pacemaker はエージェントを停止して再起動しようとします。なんらかの理由で開始オペレーションが失敗した場合、Pacemaker はリソースの障害カウントを INFINITY に設定し、別のノードでエージェントを起動しようとします。いずれかのノードでリソース エージェントが起動に失敗した場合、リソース エージェントは Stopped ステータスのままになります。

リソース エージェントのステータスを確認するには、次のコマンドを実行します。

RHEL

pcs status

SLES

crm status

次の例は、SAP HANA のノード hana-b 上でステータスが Stopped のリソース エージェントを示しています。

Full List of Resources:
  * STONITH-hana-a        (stonith:fence_gce):   Started hana-b
  * STONITH-hana-b        (stonith:fence_gce):   Started hana-a
  * Resource Group: g-primary:
    * rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-a
    * rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-a
  * Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
    * Started: [ hana-a hana-b ]
  * Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
    * Masters: [ hana-a ]
    * Stopped: [ hana-b ]
  * STONITH-scaleup-majority    (stonith:fence_gce):   Started hana-b

解決策

リソース エージェントのステータスが Stopped の場合は、次の操作を行います。

1. 障害カウントをリセットして、リソース エージェントを手動で起動します。

   RHEL

   pcs resource cleanup RESOURCE_AGENT_NAME

   SLES

   crm resource cleanup RESOURCE_AGENT_NAME

   RESOURCE_AGENT_NAME は、リソース エージェントの名前に置き換えます。例: rsc_SAPHana_DV0_HDB00

2. リソース エージェントのステータスが Started になっていることを確認します。

   crm_mon

   それでもリソース エージェントが起動しない場合は、関連する診断情報を収集して、サポートにお問い合わせください。