Azure の Red Hat Enterprise Linux に Pacemaker を設定する

  • [アーティクル]

この記事では、Red Hat Enterprise Server (RHEL) で基本的な Pacemaker クラスターを構成する方法について説明します。 この手順では、RHEL 7、RHEL 8、RHEL 9 について説明します。

前提条件

はじめに、次の SAP Note およびガイドを確認してください

クラスターのインストール

Diagram that shows an overview of Pacemaker on RHEL.

Note

Red Hat では、ソフトウェアでエミュレートするウォッチドッグはサポートしていません。 Red Hat では、クラウド プラットフォームの SBD はサポートしていません。 詳細については、「Support Policies for RHEL High Availability Clusters - sbd and fence_sbd」(RHEL 高可用性クラスターのサポートポリシー - sbd と fence_sbd) に関するページを参照してください。

Azure 上の Pacemaker が使用された RHEL クラスターでサポートされるフェンス メカニズムは、Azure フェンス エージェントのみです。

以下の項目には、次のいずれかのプレフィックスが付いています:

  • [A] :すべてのノードに適用できます
  • [1]: ノード 1 にのみ当てはまる
  • [2]: ノード 2 にのみ当てはまる

コマンドまたは RHEL 7 と RHEL 8/RHEL 9 の構成の違いは、ドキュメントでマークされています。

  1. [A] 登録します。 この手順は省略可能です。 RHEL SAP の HA が有効になっているイメージを使用する場合、この手順は必要ありません。

    たとえば、RHEL 7 にデプロイする場合は、VM を登録し、RHEL 7 のリポジトリを含むプールにアタッチします。

    sudo subscription-manager register
# List the available pools
sudo subscription-manager list --available --matches '*SAP*'
sudo subscription-manager attach --pool=<pool id>

    Azure Marketplace の従量課金制 RHEL イメージにプールをアタッチすると、RHEL の使用量に対して実質的に 2 倍の課金が行われます。 従量課金制イメージに対して 1 回、アタッチするプールの RHEL エンタイトルメントに対して 1 回課金されます。 この状況を防ぐ目的で、Azure では Bring-Your-Own-Subscription (BYOS) RHEL イメージが提供されるようになりました。 詳細については、Red Hat Enterprise Linux のサブスクリプション持ち込み Azure イメージに関するページを参照してください。

  2. [A] SAP のリポジトリ用に RHEL を有効にします。 この手順は省略可能です。 RHEL SAP の HA が有効になっているイメージを使用する場合、この手順は必要ありません。

    必要なパッケージを RHEL 7 にインストールするには、次のリポジトリを有効にします。

    sudo subscription-manager repos --disable "*"
sudo subscription-manager repos --enable=rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms

  3. [A] RHEL HA アドオンをインストールします。

     sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat

    重要

    リソースの停止に失敗した場合や、クラスター ノードが互いに通信できなくなった場合に、お客様がフェールオーバー時間の高速化の恩恵を受けられるよう、次のバージョン (またはこれら以降) の Azure Fence Agent をおすすめします。

    RHEL 7.7 以降では、使用可能な最新バージョンの fence-agents パッケージが使用されます。

    RHEL 7.6: fence-agents-4.2.1-11.el7_6.8

    RHEL 7.5: fence-agents-4.0.11-86.el7_5.8

    RHEL 7.4: fence-agents-4.0.11-66.el7_4.12

    詳細については、「Azure VM running as a RHEL High-Availability cluster member take a very long time to be fenced, or fencing fails/times out before the VM shuts down」 (RHEL 高可用性クラスターのメンバーを実行している Azure VM のフェンシングに非常に長い時間がかかる、フェンシングが失敗する、VM がシャットダウンする前にタイムアウトする) をご覧ください。

    重要

    フェンス エージェントのサービス プリンシパル名ではなく、Azure リソースのマネージド ID を使用することを希望するお客様には、次のバージョンの Azure Fence Agent (またはそれ以降) をおすすめします。

    RHEL 8.4: fence-agents-4.2.1-54.el8.

    RHEL 8.2: fence-agents-4.2.1-41.el8_2.4

    RHEL 8.1: fence-agents-4.2.1-30.el8_1.4

    RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.

    重要

    RHEL 9 では、Azure Fence Agent の問題を回避するために、次のパッケージ バージョン (またはそれ以降) をおすすめします。

    fence-agents-4.10.0-20.el9_0.7

    fence-agents-common-4.10.0-20.el9_0.6

    ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm

    Azure Fence Agent のバージョンを確認します。 必要に応じて、最低限必要なバージョン以降に更新します。

    # Check the version of the Azure Fence Agent
 sudo yum info fence-agents-azure-arm

    重要

    Azure Fence Agent を更新する必要があり、カスタム ロールを使用している場合は、カスタム ロールを更新してアクション powerOff を含めるようにします。 詳細については、「フェンス エージェントのカスタム ロールを作成する」を参照してください。

  4. RHEL 9 にデプロイしている場合は、クラウド デプロイ用のリソース エージェントもインストールします。

    sudo yum install -y resource-agents-cloud

  5. [A] ホスト名解決を設定します。

    DNS サーバーを使用するか、すべてのノードの /etc/hosts ファイルを変更することができます。 この例では、/etc/hosts ファイルを使用する方法を示します。 次のコマンドの IP アドレスとホスト名を置き換えます。

    重要

    クラスター構成でホスト名を使用している場合は、信頼性の高いホスト名解決が不可欠です。 名前が使用できず、クラスターのフェールオーバーの遅延につながる可能性がある場合、クラスター通信は失敗します。

    /etc/hosts を使用する利点は、単一障害点になる可能性もある DNS からクラスターを独立させられることです。

    sudo vi /etc/hosts

    /etc/hosts に次の行を挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します。

    # IP address of the first cluster node
10.0.0.6 prod-cl1-0
# IP address of the second cluster node
10.0.0.7 prod-cl1-1

  6. [A]hacluster のパスワードを同じパスワードに変更します。

    sudo passwd hacluster

  7. [A] Pacemaker のファイアウォール規則を追加します。

    クラスター ノード間のすべてのクラスターの通信用に、次のファイアウォール規則を追加します。

    sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability

  8. [A] 基本的なクラスター サービスを有効にします。

    次のコマンドを実行し、Pacemaker サービスを有効にして、それを開始します。

    sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service

  9. [1] Pacemaker クラスターを作成します。

    次のコマンドを実行し、ノードを認証してクラスターを作成します。 トークンを 30000 に設定してメモリ保持メンテナンスを可能にします。 詳細については、Linux のこの記事を参照してください。

    RHEL 7.x でクラスターをビルドしている場合は、次のコマンドを使用します。

    sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
sudo pcs cluster start --all

    RHEL 8.x/RHEL 9.x でクラスターをビルドしている場合は、次のコマンドを使用します。

    sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
sudo pcs cluster start --all

    次のコマンドを実行して、クラスターの状態を確認します。

    # Run the following command until the status of both nodes is online
sudo pcs status

# Cluster name: nw1-azr
# WARNING: no stonith devices and stonith-enabled is not false
# Stack: corosync
# Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
# Last updated: Fri Aug 17 09:18:24 2018
# Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
#
# 2 nodes configured
# 0 resources configured
#
# Online: [ prod-cl1-0 prod-cl1-1 ]
#
# No resources
#
# Daemon Status:
#   corosync: active/disabled
#   pacemaker: active/disabled
#   pcsd: active/enabled

  10. [A] 予想される票を設定します。

    # Check the quorum votes 
pcs quorum status

# If the quorum votes are not set to 2, execute the next command
sudo pcs quorum expected-votes 2

    ヒント

    マルチノード クラスター (2 つ以上のノードを持つクラスター) をビルドしている場合は、投票を 2 に設定しないでください。

  11. [1] 同時フェンス アクションを許可します。

    sudo pcs property set concurrent-fencing=true

フェンス デバイスを作成する

フェンス デバイスは、Azure リソースのマネージド IDまたはサービス プリンシパルのいずれかを使用して、Azure に対する認可を行います。

マネージド ID (MSI) を作成するには、クラスター内の VM ごとにシステム割り当てマネージド ID を作成します。 システム割り当てマネージド ID が既に存在する場合は、それが使用されます。 現時点では、Pacemaker でユーザー割り当てマネージド ID を使用しないでください。 マネージド ID に基づくフェンス デバイスは、RHEL 7.9 および RHEL 8.x/RHEL 9.x でサポートされています。

[1] フェンス エージェントのカスタム ロールを作成する

既定では、マネージド ID とサービス プリンシパルのどちらにも、Azure リソースにアクセスするためのアクセス許可はありません。 クラスターのすべての VM を開始および停止 (電源オフ) するアクセス許可をマネージド ID またはサービス プリンシパルに付与する必要があります。 まだカスタム ロールを作成していない場合は、PowerShell または Azure CLI を使って作成できます。

入力ファイルには次の内容を使用します。 コンテンツをサブスクリプションに合わせる必要があります。つまり、xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx と yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy をサブスクリプションの ID に置き換えます。 ご利用のサブスクリプションが 1 つしかない場合は、AssignableScopes の 2 つ目のエントリは削除してください。

{
      "Name": "Linux Fence Agent Role",
      "description": "Allows to power-off and start virtual machines",
      "assignableScopes": [
              "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
      ],
      "actions": [
              "Microsoft.Compute/*/read",
              "Microsoft.Compute/virtualMachines/powerOff/action",
              "Microsoft.Compute/virtualMachines/start/action"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
}

[A] カスタム ロールを割り当てる

マネージド ID またはサービス プリンシパルを使用します。

最後のセクションで作成したカスタム ロール Linux Fence Agent Role をクラスター VM の各マネージド ID に割り当てます。 各 VM のシステム割り当てマネージド ID には、クラスター VM のリソースごとにロールを割り当てる必要があります。 詳細については、[Azure portal を使用してリソースにマネージド ID アクセスを割り当てる] を参照してください。 各 VM のマネージド ID ロールの割り当てにすべてのクラスター VM が含まれていることを確認します。

重要

マネージド ID による認可の割り当てと削除は、有効になるまで遅延する場合があることに注意してください。

[1] フェンス デバイスを作成する

VM のアクセス許可を編集した後で、クラスターのフェンス デバイスを構成できます。

sudo pcs property set stonith-timeout=900

Note

pcmk_host_map のオプションは、RHEL ホスト名と Azure VM 名が同一でない場合のみ、このコマンドで必要です。 hostname:vm-name の形式でマッピングを指定します。 このコマンドの太字のセクションを参照してください。 詳細については、pcmk_host_map でフェンス デバイスへのノード マッピングを指定する場合に使用する形式に関するページを参照してください。

RHEL 7.x の場合は、次のコマンドを使用してフェンス デバイスを構成します。

sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

RHEL 8.x/9.x の場合は、次のコマンドを使用してフェンス デバイスを構成します。

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

サービス プリンシパルの構成に基づいてフェンス デバイスを使用している場合は、「Azure フェンシングを使用した Pacemaker クラスターの SPN から MSI への変更」を参照し、マネージド ID 構成に変換する方法について学習します。

ヒント

  • 2 ノードの Pacemaker クラスター内でのフェンス レースを回避するには、priority-fencing-delay クラスター プロパティを構成します。 このプロパティを使用すると、スプリット ブレイン シナリオが発生したときに、リソースの優先度の合計が高いノードをフェンスする際に、さらに遅延が発生するようになります。 詳細については、実行中のリソースが最も少ないクラスター ノードの Pacemaker によるフェンスに関するページを参照してください。
  • priority-fencing-delay プロパティは、Pacemaker バージョン 2.0.4-6.el8 以降および 2 ノード クラスターに適用されます。 priority-fencing-delay クラスター プロパティを構成する場合は、pcmk_delay_max プロパティを設定する必要はありません。 ただし、Pacemaker のバージョンが 2.0.4-6.el8 未満の場合は、pcmk_delay_max プロパティを設定する必要があります。
  • priority-fencing-delay クラスター プロパティを設定する方法については、SAP ASCS/ERS および SAP HANA スケールアップ HA のそれぞれのドキュメントを参照してください。

監視およびフェンス操作は逆シリアル化されます。 その結果、長時間実行されている監視操作と同時フェンス イベントがある場合、既に実行されている監視操作により、クラスターのフェールオーバーに遅延は発生しません。

[1] フェンス デバイスの使用を有効にする

sudo pcs property set stonith-enabled=true

ヒント

Azure フェンス エージェントには、パブリック エンドポイントへの送信接続が必要です。 考えられる解決策と詳細については、「標準 ILB を使用した VM のパブリック エンドポイント接続」を参照してください。

Azure のスケジュール化されたイベント用に Pacemaker を構成する

Azure では、スケジュール化されたイベントが提供されています。 スケジュール化されたイベントは、メタデータ サービスを介して送信され、このようなイベントに対して準備する時間をアプリケーションに与えます。

Pacemaker リソース エージェント azure-events-az では、スケジュール化された Azure イベントが監視されます。 イベントが検出され、リソース エージェントが別のクラスター ノードが使用可能であると判断した場合は、クラスター正常性属性が設定されます。

ノードにクラスター正常性属性が設定されると、場所制約がトリガーされ、health- で始まらない名前を持つすべてのリソースが、スケジュール化されたイベントを含むノードから移行されます。 影響を受けるクラスター ノードが実行中のクラスター リソースを解放すると、スケジュール化されたイベントが確認され、再起動などのアクションを実行できます。

  1. [A]azure-events-az エージェントのパッケージが既にインストールされ、最新であることを確認します。

    RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud

    最小バージョンの要件:

    • RHEL 8.4: resource-agents-4.1.1-90.13
    • RHEL 8.6: resource-agents-4.9.0-16.9
    • RHEL 8.8: resource-agents-4.9.0-40.1
    • RHEL 9.0: resource-agents-cloud-4.10.0-9.6
    • RHEL 9.2 以降: resource-agents-cloud-4.10.0-34.1

  2. [1] Pacemaker 内でリソースを構成します。

    #Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true

  3. [1] Pacemaker クラスター正常性ノードの戦略と制約を設定します。

    sudo pcs property set node-health-strategy=custom
sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
defined '#uname'

    重要

    次の手順で説明するリソース以外に、health- で始まるクラスター内の他のリソースは定義しないでください。

  4. [1] クラスター属性の初期値を設定します。 各クラスター ノードおよびマジョリティ メーカー VM を含むスケールアウト環境に対して実行します。

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0

  5. [1] Pacemaker 内でリソースを構成します。 リソースが health-azureで始まることを確認します。

    sudo pcs resource create health-azure-events \
ocf:heartbeat:azure-events-az op monitor interval=10s
sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true

  6. Pacemaker クラスターのメンテナンス モードを解除します。

    sudo pcs property set maintenance-mode=false

  7. 有効化中にエラーをクリアし、health-azure-events リソースがすべてのクラスター ノードで正常に開始されたことを確認します。

    sudo pcs resource cleanup

    スケジュール化されたイベントに対する初回クエリの実行には、最大 2 分かかることがあります。 スケジュール化されたイベントを使用した Pacemaker テストでは、クラスター VM の再起動または再デプロイ アクションを使用できます。 詳細については、「スケジュールされたイベント」を参照してください。

オプションのフェンス構成

ヒント

このセクションは、特殊なフェンス デバイス fence_kdump を構成する必要がある場合にのみ適用されます。

VM 内で診断情報を収集する必要がある場合は、フェンス エージェント fence_kdump に基づいて別のフェンス デバイスを構成すると有用な場合があります。 fence_kdump エージェントでは、他のフェンス メソッドが呼び出される前に、kdump クラッシュ復旧に入ったノードを検出してクラッシュ復旧サービスを完了できるようにすることができます。 fence_kdump は、Azure VM 使用時の Azure Fence Agent のような、従来のフェンス メカニズムに代わるものではないことに注意してください。

重要

fence_kdump が第 1 レベルのフェンス デバイスとして構成されている場合、それによってフェンス操作で遅延が発生し、アプリケーション リソースのフェールオーバーでそれぞれ遅延が発生することに注意してください。

クラッシュ ダンプが正常に検出された場合、フェンスはクラッシュ復旧サービスが完了するまで遅延されます。 失敗したノードが到達不能な場合や応答しない場合は、構成されている繰り返しの回数と、fence_kdump のタイムアウトによって決まる時間だけフェンスが遅延されます。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。

提案されている fence_kdump のタイムアウトは、実際の環境に合わせて調整する必要がある場合があります。

fence_kdump フェンスを構成するのは、VM 内で診断情報を収集する必要がある場合のみとし、必ず Azure Fence Agent のような従来のフェンス方式と組み合わせることをおすすめします。

以下の Red Hat KB には、fence_kdump フェンスの構成に関する重要な情報が含まれています。

Azure Fence Agent の構成に加えて以下のオプションの手順を実行し、第 1 レベルのフェンス構成として fence_kdump を追加します。

  1. [A]kdump がアクティブになっていて、構成されていることを確認します。

    systemctl is-active kdump
# Expected result
# active

  2. [A]fence_kdump フェンス エージェントをインストールします。

    yum install fence-agents-kdump

  3. [1] クラスター内に fence_kdump フェンス デバイスを作成します。

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30

  4. [1] フェンス レベルを構成して、fence_kdump フェンス メカニズムが最初に動作するようにします。

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
pcs stonith level add 1 prod-cl1-1 rsc_st_kdump
pcs stonith level add 2 prod-cl1-0 rsc_st_azure
pcs stonith level add 2 prod-cl1-1 rsc_st_azure

# Check the fencing level configuration 
pcs stonith level
# Example output
# Target: prod-cl1-0
# Level 1 - rsc_st_kdump
# Level 2 - rsc_st_azure
# Target: prod-cl1-1
# Level 1 - rsc_st_kdump
# Level 2 - rsc_st_azure

  5. [A] ファイアウォールを通過する fence_kdump のために必要なポートを許可します。

    firewall-cmd --add-port=7410/udp
firewall-cmd --add-port=7410/udp --permanent

  6. [A]initramfs イメージ ファイルに fence_kdump と hosts のファイルが含まれることを確認します。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。

    lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
# Example output 
# -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
# -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send

  7. [A]kexec-tools の一部のバージョンでタイムアウトによる fence_kdump の失敗が発生しないように、/etc/kdump.conf で fence_kdump_nodes の構成を実行します。 詳細については、「kexec-tools バージョン 2.0.15 以降の使用時に fence_kdump_nodes が指定されていないと fence_kdump がタイムアウトする」と、「2.0.14 より前のバージョンの kexec-tools の使用時に RHEL 6 または 7 の高可用性クラスターで "X 秒後にタイムアウトします" と表示されて fence_kdump が失敗する」を参照してください。 ここでは、2 ノード クラスターの構成例を示します。 /etc/kdump.conf で変更を加えた後に、kdump イメージを再生成する必要があります。 再生成するには、kdump サービスを再起動します。

    vi /etc/kdump.conf
# On node prod-cl1-0 make sure the following line is added
fence_kdump_nodes  prod-cl1-1
# On node prod-cl1-1 make sure the following line is added
fence_kdump_nodes  prod-cl1-0

# Restart the service on each node
systemctl restart kdump

  8. ノードをクラッシュさせて構成をテストします。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。

    重要

    クラスターが既に運用環境で使用中の場合は、ノードをクラッシュさせるとアプリケーションに影響があるため、それに応じてテストを計画します。

    echo c > /proc/sysrq-trigger

次のステップ