Azure で SUSE Linux Enterprise Server に Pacemaker をセットアップする

この記事では、AzureのSUSE Linux Enterprise Server(SLES)上で基本的な2ノードのPacemakerクラスタのセットアップと設定方法を説明します。 これらの指示は SLES for SAP 12 SP5SLES for SAP 15 SP 4+SLES for SAP 16をカバーしています。

前提条件

概要

このガイドは、必要なリソースグループ、Azureの仮想ネットワーク、サブネット、仮想マシン(VM)をすでに展開している前提です。

Linux上で動くクラスターは、不健康なノードをフェンシングするためにフェンシングエージェントが必要です。 この作業をAzureで行うには、以下のいずれかの方法を用いてください。

  • Azure Shared Disk を用いた Storage Based Death (SBD)
  • iSCSIターゲットを用いたストレージベースデス(SBD)
  • Azure Fencing Agent (Azure フェンシング エージェント)

Note

本文書で使用されている接頭辞は以下の通りです:

  • [A]: すべてのノードに当てはまります。
  • [1]: ノード 1 にのみ当てはまります。
  • [2]: ノード 2 にのみ当てはまります。

Azure共有ディスクでのSBD使用方法

Azure Shared Disksを使うことで、クラスター内のすべての仮想マシンに同じディスクをマウントできます。 SBDデバイスをその共有ディスク上でホストすれば、追加のインフラ要件なしで可能です。

Pacemakerクラスタ内のSBDデバイスとしてのAzure共有ディスクの図。

Benefits

  • 追加のリソースを必要としない、SBD向けのネイティブなAzure共有ブロックデバイスオプションを提供します。
  • 仮想マシンはマネージドディスクを直接接続し、追加のネットワーク要素への依存を減らすことができます。

重要な考慮事項

  • Premium SSD SKU の Azure 共有ディスクを SBD デバイスとして使用できます。
  • サポートされているオペレーティングシステムの一覧を確認してください。
  • Azureプレミアム共有ディスクを使用するSBDデバイスは、ローカル冗長ストレージ(LRS)およびゾーン冗長ストレージ(ZRS)をサポートします。
  • デプロイの種類に応じて、Azure 共有ディスクの適切な冗長ストレージを SBD デバイスとして選択します。
    • Azure Premium Shared Disk(skuName - Premium_LRS)で LRS を使用する SBD デバイスは、可用性セットでのデプロイのみをサポートします。
    • Azureプレミアム共有ディスク(skuName - Premium_ZRS)にZRSを使用するSBDデバイスは、可用性ゾーンでの展開に推奨されます。
  • SBD デバイスに使用する Azure 共有ディスクは、大きなサイズである必要はありません。 共有ディスクを使用できるクラスター ノードの数は、maxShares 値によって決まります。 例えば、SAP ASCS/ERSやSAP HANAのスケールアップのような2ノードクラスタで、SBDデバイスにP1またはP2のディスクサイズを使用できます。
    • ノードが2つ以上あるクラスタの場合は、選択したディスクの文書化された maxShares を参照してください。
  • Azure共有ディスクSBDデバイスを異なるPacemakerクラスタ間に接続しないでください。
  • Azure 共有ディスクの SBD デバイスを複数使用する場合は、VM にアタッチできる最大データ ディスク数の上限を確認してください。
  • Azure 共有ディスクの制限事項の詳細については、Azure 共有ディスクのドキュメントの「制限事項」セクションを参照してください。

iSCSIターゲットを用いたSBDの使用

このソリューションでは、少なくとも1台の追加仮想マシン(VM)上でInternet Small Computer System Interface(iSCSI)ターゲットをホストする必要があります。

Pacemakerクラスタ内のSBDデバイス用iSCSIターゲットをホストするiSCSIサーバーの図。

Benefits

  • これらのiSCSIホストサーバーは、同じリージョン内の他のPacemakerクラスターのiSCSIターゲットもホストできます。
  • すでにオンプレミスで使っている場合、Pacemakerクラスタの運用方法を変更する必要はありません。

重要な考慮事項

  • クラスタのレジリエンシーを最高レベルにするには、3台のiSCSIホストサーバーを使用する必要があります。
    • サーバーを1台しか使用しないと、単一障害点が生じ、そのサーバーが停止した場合にクラスタはフェンシングできなくなります。
    • ペースメーカーは、ターゲットが2つしかなく、そのうち1人が倒れている場合はフェンシングを許可しません。
  • iSCSIのターゲットホストサーバーは、クラスタと同じリージョンに存在しなければなりません。
  • クラスタとiSCSIホストサーバー間のネットワークルーティングは、非冗長なネットワークデバイス( 例えばネットワーク仮想アプライアンス)を経由してはなりません。
    • ネットワーク機器のメンテナンスイベントやその他の問題は、クラスタ全体の安定性と信頼性に悪影響を及ぼすことがあります。

Azure Fence Agentの使用

Azure Fence Agentを使うことで、クラスターはAzure APIを直接呼び出してノードをフェンス化し、失敗したノードを再起動できます。

Pacemaker ClusterにおけるAzure Fence Agentの図。

Benefits

  • 追加のリソースは必要ありません。
  • 管理されたIDは認証情報のメンテナンスを一切削除します。

重要な考慮事項

  • 認証にはマネージドIDを使いましょう。 現在サービスプリンシパルを使っている場合は、Azure Fence AgentをSPNからMSIに更新してください。
  • Azure fence agentはパブリックAzureエンドポイントへのアウトバウンド接続が必要です。 考えられる解決策と詳細については、「標準 ILB を使用した VM のパブリック エンドポイント接続」を参照してください。
  • 監視およびフェンス操作は逆シリアル化されます。 その結果、長時間実行されている監視操作と同時フェンス イベントがある場合、既に実行されている監視操作により、クラスターのフェールオーバーに遅延は発生しません。

SBD 用の Azure Shared Disk をデプロイする

PowerShellを使ってAzure共有ディスクを作成・接続するには、以下のコマンドを実行します。 Azure CLIやAzureポータルを使ってリソースをデプロイしたい場合は、「ZRSディスクをデプロイする」をご覧ください。

$ResourceGroup = "<ResourceGroupName>"
$DiskSizeInGB = 4
$DiskName = "<SBDDiskName>"
# Must be Equal to or greater than the Number of Nodes in the Cluster
$ShareNodes = 2 
# Options are "Premium_LRS" or "Premium_ZRS"
$SKUName = "<DiskSKU>"
# VMs to attach the disk to
$vmNames = @("sap-cl1", "sap-cl2")
# Lun to attach the disk to. You should use the same lun on all servers in the cluster.
$lunNumber = <lunNumber>

$diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes

$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig

# Attach SBD disk to cluster VMs
foreach ($vmName in $vmNames) 
{
  $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $lunNumber
  Update-AzVM -VM $vm -ResourceGroupName $resourceGroup -Verbose
}

iSCSIターゲットの使用

iSCSIターゲットホストサーバーを構築する

  1. サポートされているSLES OSバージョンで動作する3台の仮想マシンを展開します。 VMは必ずしも大きくする必要はありません。 Standard_E2sやStandard_D2sなどのVMサイズで十分です。

    Note

    iSCSIターゲットサーバーのSAP Applications OSイメージにはSLESを使う必要はありません。 代わりに標準のSLES OSイメージを使うこともできます。 ただし、サポートライフサイクルは、OS 製品リリースによって異なります。

  2. 最新のアップデートをインストールし、必要なら再起動してください。

    sudo zypper -n update
    
  3. iSCSIターゲットパッケージをインストールしてください。

    sudo zypper -n install targetcli-fb
    
  4. iSCSIサービスを有効化し、開始します。

    sudo systemctl start targetcli
    sudo systemctl enable targetcli
    

iSCSIターゲットの作成

各クラスターごとに、各iSCSIホストサーバーにiSCSIディスクをプロビジョニングし、すべてのクラスタノードにそのディスクへのアクセスを許可する必要があります。 この例では、2つの異なるクラスターごとにディスクを作成します:

  • ascsnw1:NW1のASCS/ERSクラスター
  • hdbnw1:NW1用のHANAデータベースクラスター
  • sap-cl1およびsap-cl2:NW1 ASCS/ERSクラスタノードのホスト名
  • sap-db1およびsap-db2:NW1 HANAクラスタノードのホスト名
  1. すべての SBD デバイスのルート フォルダーを作成します。
    sudo mkdir /sbd
    
  2. 最初のクラスタ(ascsnw1)用のSBDデバイスを作成します。
    # Create Storage Object
    sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
    # Create iSCSI Target
    sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
    # Creates the LUN and attaches it to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
    # Grant Cluster Node 1 (sap-cl1) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl1.local:sap-cl1
    # Grant Cluster Node 2 (sap-cl2) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2
    
  3. 2つ目のクラスター(hdbnw1)用のSBDデバイスを作成します。
    # Create Storage Object
    sudo targetcli backstores/fileio create sbdhdbnw1 /sbd/sbdhdbnw1 50M write_back=false
    # Create iSCSI Target
    sudo targetcli iscsi/ create iqn.2006-04.hdbnw1.local:hdbnw1
    # Creates the LUN and attaches it to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/luns/ create /backstores/fileio/sbdhdbnw1
    # Grant Cluster Node 1 (sap-db1) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db1.local:sap-db1
    # Grant Cluster Node 2 (sap-db2) access to the iSCSI Target
    sudo targetcli iscsi/iqn.2006-04.hdbnw1.local:hdbnw1/tpg1/acls/ create iqn.2006-04.sap-db2.local:sap-db2
    
  4. 構成を保存します。
    sudo targetcli saveconfig
    
  5. セットアップを確認してください。
    sudo targetcli ls
    
    o- / ............................................................................................... [...]
      o- backstores .................................................................................... [...]
      | o- block ........................................................................ [Storage Objects: 0]
      | o- fileio ....................................................................... [Storage Objects: 2]
      | | o- sbdascsnw1 ..................................... [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
      | | | o- alua ......................................................................... [ALUA Groups: 1]
      | | |   o- default_tg_pt_gp ............................................. [ALUA state: Active/optimized]
      | | o- sbdhdbnw1 ....................................... [/sbd/sbdhdbnw1 (50.0MiB) write-thru activated]
      | |   o- alua ......................................................................... [ALUA Groups: 1]
      | |     o- default_tg_pt_gp ............................................. [ALUA state: Active/optimized]
      | o- pscsi ........................................................................ [Storage Objects: 0]
      | o- ramdisk ...................................................................... [Storage Objects: 0]
      o- iscsi .................................................................................. [Targets: 2]
      | o- iqn.2006-04.hdbnw1.local:hdbnw1 ......................................................... [TPGs: 1]
      | | o- tpg1 ..................................................................... [no-gen-acls, no-auth]
      | |   o- acls ................................................................................ [ACLs: 2]
      | |   | o- iqn.2006-04.sap-db1.local:sap-db1 .......................................... [Mapped LUNs: 1]
      | |   | | o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)]
      | |   | o- iqn.2006-04.sap-db2.local:sap-db2 .......................................... [Mapped LUNs: 1]
      | |   |   o- mapped_lun0 ..................................................... [lun0 fileio/sbdhdb (rw)]
      | |   o- luns ................................................................................ [LUNs: 1]
      | |   | o- lun0 ................................. [fileio/sbdhdbnw1 (/sbd/sbdhdbnw1) (default_tg_pt_gp)]
      | |   o- portals .......................................................................... [Portals: 1]
      | |     o- 0.0.0.0:3260 ........................................................................... [OK]
      | o- iqn.2006-04.ascsnw1.local:ascsnw1 ....................................................... [TPGs: 1]
      |   o- tpg1 ..................................................................... [no-gen-acls, no-auth]
      |     o- acls ................................................................................ [ACLs: 2]
      |     | o- iqn.2006-04.sap-cl1.local:sap-cl1 .......................................... [Mapped LUNs: 1]
      |     | | o- mapped_lun0 ................................................. [lun0 fileio/sbdascsnw1 (rw)]
      |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .......................................... [Mapped LUNs: 1]
      |     |   o- mapped_lun0 ................................................. [lun0 fileio/sbdascsnw1 (rw)]
      |     o- luns ................................................................................ [LUNs: 1]
      |     | o- lun0 ............................... [fileio/sbdascsnw1 (/sbd/sbdascsnw1) (default_tg_pt_gp)]
      |     o- portals .......................................................................... [Portals: 1]
      |       o- 0.0.0.0:3260 ........................................................................... [OK]
      o- loopback ............................................................................... [Targets: 0]
    

Azure フェンス エージェントを構成する

  1. ID の作成

    マネージドアイデンティティ(MSI)を作成するには、クラスタ内の各VMごとに システム割り当てのマネージドアイデンティティを作成します 。 現時点ではユーザー割り当てのマネージドIDはサポートされていません。

  2. カスタム ロールを作成する。

    あなたのアイデンティティは、VMに対してフェンシングアクションを行うためにAzure RBACの許可が必要です。 最小権限アクセス(LPA)セキュリティモデルに準拠するために、 カスタムRBACロールを作成します

    必要に応じてサブスクリプションIDを置き換え、あなたの役割には以下の定義を用いてください。

    {
          "Name": "Linux Fence Agent",
          "description": "Allowed to power-off and start virtual machines",
          "assignableScopes": [
                  "/subscriptions/<Subscription 1 ID (GUID)>",
                  "/subscriptions/<Subscription N ID (GUID)>"
          ],
          "actions": [
                  "Microsoft.Compute/*/read",
                  "Microsoft.Compute/virtualMachines/powerOff/action",
                  "Microsoft.Compute/virtualMachines/start/action"
          ],
          "notActions": [],
          "dataActions": [],
          "notDataActions": []
    }
    
  3. カスタムロールをあなたのアイデンティティに割り当ててください。

    クラスタ内の各VMごとに、その管理IDをクラスタ内のすべてのVM(自身も含む)のカスタム「Linux Fence Agent」ロールに割り当てます。 詳細な手順については、「Azure portal を使用してリソースにマネージド ID アクセスを割り当てる」を参照してください。

    重要

    マネージドIDでの権限の割り当ておよび解除は、有効期限まで 遅延する可能性がある ことに注意してください。

クラスタの作成と構成

  1. [A] OSを更新し、必要に応じて再起動してください。

    sudo zypper -n update
    
  2. [A] 必要なクラスタパッケージをインストールしてください。

    sudo zypper -n install socat pacemaker resource-agents 
    
  3. [A] 必要なフェンスパッケージを設置してください。

    sudo zypper -n install sbd
    
    sudo zypper -n install sbd open-iscsi
    
    sudo zypper -n install fence-agents-azure-arm
    
  4. [A] DNSの設定を。

    DNS サーバーを使用するか、すべてのノードで /etc/hosts を変更できます。 この例では、/etc/hosts ファイルを使用する方法を示します。

    項目をお使いのIPアドレスとホスト名に一致するように更新してください。

    sudo vi /etc/hosts
    [...]
    # IP address of cluster node 1
    10.27.0.6    sap-cl1
    # IP address of cluster node 2
    10.27.0.7    sap-cl2
    
    sudo vi /etc/hosts
    [...]
    # IP address of cluster node 1
    10.0.0.6    sap-cl1
    # IP address of cluster node 2
    10.0.0.7    sap-cl2
    # IP address of iSCSI Target Host Server 1
    10.0.0.17   sbd-iscsi1
    # IP address of iSCSI Target Host Server 1
    10.0.0.18   sbd-iscsi2
    # IP address of iSCSI Target Host Server 1
    10.0.0.19   sbd-iscsi3
    
  5. [A] ノード間でSSHルートキーをExchangeします。

    sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519
    sudo cat /root/.ssh/id_ed25519.pub
    sudo vi /root/.ssh/authorized_keys
    [...]
    <Contents from cat command on other server>
    
  6. [A] オペレーティング システムを構成します。

    1. 高メモリシステムのNFSクライアント用にダーティキャッシュを調整してください。 詳細は この記事 をご覧ください。
      sudoedit /etc/sysctl.d/30-nfs.conf && sudo sysctl --system
      
      vm.dirty_bytes = 629145600
      vm.dirty_background_bytes = 314572800
      
    2. スワップ使用を減らしメモリを優先するために vm.swappiness を10に設定してください。
      sudoedit /etc/sysctl.d/31-memswap.conf && sudo sysctl --system
      
      vm.swappiness = 10
      
    3. SLES 12 SP 5のみ:ペースメーカーは時折多くのプロセスを生成し、許可された数を使い果たすことがあります。 その場合、クラスター ノード間のハートビートが失敗し、リソースのフェールオーバーが発生する可能性があります。 以下のパラメータを設定することで、許容される最大プロセス数を増やします:
      # Edit the configuration file
      sudo vi /etc/systemd/system.conf
      [...]
      DefaultTasksMax=4096
      [...]
      
      # Activate this setting
      sudo systemctl daemon-reload
      
      # Test to ensure that the change was successful
      sudo systemctl --no-pager show | grep DefaultTasksMax
      
  7. [1] クラスターを作成してください。

    sudo crm cluster init --yes --name ascsnw1 --node sap-cl1 --node sap-cl2
    
  8. [1] クラスタ設定の設定を設定してください。

    sudo crm corosync set totem.token 30000
    sudo csync2 -xv
    sudo crm cluster run "corosync-cfgtool -R"
    
  9. Pacemakerの起動遅延を設定してください。

    起動直後にPacemakerを起動すると、フェイルオーバー完了前にノードがクラスタに再加入し、フェイルオーバーや回復遅延を防ぐ可能性があります。 この問題を解決するには、再起動時のペースメーカー起動を遅らせるタイマーサービスを使う方法があります。

    1. [A] タイマーサービスの設定。
      sudo vi /etc/systemd/system/pacemaker.timer   
      
      [Unit]
      Description=Delay start of pacemaker.service after boot
      [Timer]
      OnBootSec=216
      Unit=pacemaker.service
      [Install]
      WantedBy=timers.target
      
    2. [A] タイマーサービスを有効にしてください。
      sudo systemctl daemon-reload
      sudo systemctl enable pacemaker.timer
      
    3. [1] ペースメーカーサービスを無効化。
      sudo crm cluster disable --all
      
  10. クラスターの検証。

    1. [1] ペースメーカークラスターの検証。
      sudo crm status
      
      Cluster Summary:
        * Stack: corosync (Pacemaker is running)
        * Current DC: sap-cl1 (version 2.1.7+20231219.0f7f88312-150600.6.15.1-2.1.7+20231219.0f7f88312) - partition with quorum
        * Last updated: Tue Aug  4 17:50:24 2026 on sap-cl1
        * Last change:  Thu Jul 30 19:02:56 2026 by hacluster via hacluster on sap-cl1
        * 2 nodes configured
        * 0 resource instances configured
      
      Node List:
        * Online: [ sap-cl1 sap-cl2 ]
      
      Full List of Resources:
      
    2. [A] サービスの検証。
      systemctl list-unit-files pacemaker.timer pacemaker.service corosync.service
      
      UNIT FILE         STATE    PRESET
      corosync.service  disabled disabled
      pacemaker.service disabled disabled
      pacemaker.timer   enabled  disabled
      

フェンシングの設定

  1. [A] SBDサービスを有効にする。
    sudo systemctl enable sbd
    
  2. [A] ソフトウェア ウォッチドッグを有効にする。
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [A] iSCSIデバイスIDを発見。
    1. LUN番号に基づいてマウントポイントを決定します
      ls -l /dev/disk/azure/scsi1/lun1
      lrwxrwxrwx. 1 root root 12 Apr 16 20:22 /dev/disk/azure/scsi1/lun1 -> ../../../sdb
      
    2. マウントからiSCSIデバイスIDを取得してください。
      ls -l /dev/disk/by-id/scsi-3* | grep -i sdb
      lrwxrwxrwx. 1 root root  9 Apr 16 20:22 /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -> ../../sdb
      
  4. [1] SBD デバイスを作成します。
    sudo sbd -d /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617 -1 60 -4 120 create
    
  1. [1] SBDデバイスをクラスタに追加します。
    sudo crm cluster init --yes sbd -s /dev/disk/by-id/scsi-360022480055c9f501a24256ea0f87617
    
  2. [1] SBDの設定を変更してください。
    sudo crm configure property stonith-timeout=210
    sudo crm configure property stonith-enabled=true
    # For the below command, 600 is the interval, and 120 is the timeout
    sudo crm configure monitor stonith-sbd 600:120
    sudo crm configure set stonith-sbd.pcmk_delay_max 15
    
  3. [A] SBDの設定ファイルを検証してください。
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [A] 必要なサービスを有効にしてください。
    sudo systemctl enable sbd iscsi iscsid
    
  2. [A] ソフトウェアウォッチドッグを有効にする。
    echo softdog | sudo tee /etc/modules-load.d/softdog.conf
    sudo modprobe softdog
    
  3. [1] ノード1の InitiatorName を更新してください。
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1
    
  4. [2] ノード2の InitiatorName を更新してください。
    # Node 2
    sudo vi /etc/iscsi/initiatorname.iscsi
    [...]
    InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2
    
  5. [A] iSCSIサービスを再起動してください。
    sudo systemctl restart iscsi iscsid
    
  6. [A] すべてのiSCSIホストサーバーからiSCSIターゲットをマウントします。
    for hostServer in sbd-iscsi1 sbd-iscsi2 sbd-iscsi3; do
       iscsiadm -m discovery --type=st --portal=${hostServer}:3260 
       iscsiadm -m node -T iqn.2006-04.ascsnw1.local:ascsnw1 --login --portal=${hostServer}:3260
       iscsiadm -m node --portal=${hostServer}:3260 -T iqn.2006-04.ascsnw1.local:ascsnw1 --op=update --name=node.startup --value=automatic
    done
    
  7. [A] iSCSIデバイスIDを発見する。
    1. iSCSIのマウントポイントを特定してください。
      lsscsi
      [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
      [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
      [2:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdc
      [3:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdd
      [4:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sde
      
    2. iSCSIデバイスIDを取得してください。
      ls -l /dev/disk/by-id/scsi-3* | grep sd[c,d,e]
      lrwxrwxrwx 1 root root  9 Jul 21 18:02 /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -> ../../sdd
      lrwxrwxrwx 1 root root  9 Jul 21 17:50 /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -> ../../sdc
      lrwxrwxrwx 1 root root  9 Jul 21 18:04 /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -> ../../sde
      
  8. [1] SBDデバイスを作成してください。
    sudo sbd -d /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 -1 60 -4 120 create
    sudo sbd -d /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff -1 60 -4 120 create
    sudo sbd -d /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5 -1 60 -4 120 create
    
  1. [1] SBDデバイスをクラスタに追加します。
    sudo crm cluster init --yes sbd \
       -s /dev/disk/by-id/scsi-3600140537cf4c6d604a4ae4b58f1a528 \
       -s /dev/disk/by-id/scsi-360014056e4d07b80e1148ac973330dff \
       -s /dev/disk/by-id/scsi-360014059f135275c24647d49268123e5
    
  2. [1] SBDの設定を変更してください。
    sudo crm configure property stonith-timeout=210
    sudo crm configure property stonith-enabled=true
    # For the below command, 600 is the interval, and 120 is the timeout
    sudo crm configure monitor stonith-sbd 600:120
    sudo crm configure set stonith-sbd.pcmk_delay_max 15
    
  3. [A] SBDの設定ファイルを検証してください。
    sudo vi /etc/sysconfig/sbd
    
    [...]
    SBD_DELAY_START=no
    [...]
    SBD_PACEMAKER=yes
    [...]
    SBD_STARTMODE=always
    [...]
    
  1. [1] Azure Fence Agent を設定します。

    Note

    政府クラウドAzure使用する場合は、Azure Fence Agentの設定時にcloud=オプションを指定する必要があります。 たとえば、Azure米国政府機関向けクラウドのcloud=usgovなどです。

    sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm params msi=true \ 
       resourceGroup="<ResourceGroupName>" subscriptionId="<SubscriptionID>" \
       pcmk_host_map="sap-cl1:<AzureVMNameCL1>;sap-cl2:<AzureVMNameCL2>" \
       power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 \
       pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
       meta failure-timeout=120s op monitor interval=3600 timeout=120
    
  2. [1] Azure Fence Agent 用にクラスタを設定してください。

    sudo crm configure property stonith-enabled=true
    sudo crm configure property stonith-timeout=900
    

2つ以上のノードを持つPacemakerクラスタの構築

より大きなクラスターを構築する場合は、以下の点を念頭に置いてください:

  1. [1] クラスター構成を調整。

    ノードが3つ以上追加されると、 quorum.two_nodequorum.expected_votes の値は自動的に更新されます。 quorum.two_node0で、quorum.expected_votesがクラスタ内のノード数と等しいかを検証します。

    sudo crm corosync get quorum.two_node
    sudo crm corosync get quorum.expected_votes
    
  2. フェンスの配置を調整してください。

    sudo crm resource param stonith-sbd delete pcmk_delay_max
    sudo crm resource param stonith-sbd set pcmk_action_limit -1
    
    sudo crm resource param rsc_st_azure delete pcmk_delay_max
    sudo crm resource param rsc_st_azure pcmk_action_limit -1
    

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

Scheduled Eventsは、アプリケーションがVMのメンテナンス準備をする時間を与えるAzureメタデータサービスです。 再起動などの今後のメンテナンスイベントに関する情報を提供し、アプリケーションがそれに備えて混乱を抑えられます。

azure-events-az リソースエージェントはこのメタデータサービスを監視します。 エージェントがイベントを検出し、別のクラスタノードが利用可能であると判断すると、ノードレベルのヘルス属性 #health-azure-1000000に設定します。 この値によりクラスタはノードを不健康とみなし、影響を受けたノードからリソースを移動させます。 ロケーション制約により、 health- から始まるリソースは除外されます。なぜなら、azure-events-azエージェントは両方のノードで動作する必要があるからです。 影響を受けたクラスタノードが実行中のクラスタリソースから解放されると、エージェントはメタデータサービスに通知し、スケジュールされたイベントは継続されます。 すべてのイベントが完了すると、リソースエージェントは #health-azure 属性を 0に戻し、ノードを再び健康状態にマークします。

重要

前回は、リソース エージェント azure-events の使用について説明しました。 新しいリソース エージェント azure-events-az は、さまざまな可用性ゾーンに展開された Azure 環境を完全にサポートします。 Pacemakerを使ったすべてのSAPハイアプライシステムには、新しいazure-events-azエージェントを使いましょう。

  1. SLES 12 SP5のみresource-agentsパッケージのバージョンを確認し、必要に応じて更新してください。 SLES 15以降はインストールされたバージョンにデフォルトで含まれています。

    zypper info resource-agents
    

    最低限のバージョンは resource-agents-4.3.018.a7fb5035-3.98.1です。

  2. [1] クラスターをメンテナンスモードに切り替えろ。

    sudo crm configure property maintenance-mode=true
    
  3. [1] ペースメーカークラスターの健康ノード戦略と制約を設定します。

    重要

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

    sudo crm configure property node-health-strategy=custom
    sudo crm configure location loc_azure_health \
       /'!health-.*'/ rule '#health-azure': defined '#uname'
    
  4. [1] クラスター属性の初期値を設定します。

    各クラスタノードごとにコマンドを実行します。 スケールアウト環境には、マジョリティメーカーのVMを含めてください。

    # Node 1
    sudo crm_attribute --node sap-cl1 --name '#health-azure' --update 0
    # Node 2
    sudo crm_attribute --node sap-cl2 --name '#health-azure' --update 0
    # Node N
    sudo crm_attribute --node sap-clN --name '#health-azure' --update 0
    
  5. [1] Pacemaker 内でリソースを構成します。 資源は health-azureから始まらなければなりません。

    sudo crm configure primitive health-azure-events ocf:heartbeat:azure-events-az \
       meta failure-timeout=120s \
       op start start-delay=60s \
       op monitor interval=10s
    
    sudo crm configure clone health-azure-events-cln health-azure-events \
       meta allow-unhealthy-nodes=true
    

    Note

    health-azure-eventsリソースを設定する際、以下の警告メッセージは無視できます。

    警告: health-azure-events: 未知の属性 'allow-unhealthy-nodes'。

  6. ペースメーカーのクラスターをメンテナンスモードから解除し、エラーを消してください。

    sudo crm configure property maintenance-mode=false
    sudo crm resource cleanup
    
  7. すべてのノードで health-azure-events が正常に起動しているか確認してください。

    crm status
    
    Cluster Summary:
      * Stack: corosync (Pacemaker is running)
      * Current DC: sap-cl1 (version 3.0.0+20250218.64cd85422c-160000.4.1-3.0.0+20250218.64cd85422c) - partition with quorum
      * Last updated: Thu Jul 30 19:07:49 2026 on sap-cl1
      * Last change:  Thu Jul 30 19:06:01 2026 by root via root on sap-cl1
      * 2 nodes configured
      * 3 resource instances configured
    
    Node List:
      * Online: [ z04ascs3 z04ascs4 ]
    
    Full List of Resources:
      * stonith-sbd (stonith:fence_sbd):     Started sap-cl1
      * Clone Set: health-azure-events-cln [health-azure-events]:
        * Started: [ sap-cl1 sap-cl2 ]
    

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

    Note

    azure-eventsエージェント用のPacemakerリソースを設定した後、クラスタをメンテナンスモードにするか終了するかすると、次のような警告メッセージが表示されることがあります:

    警告: cib-bootstrap-options: 属性 'hostName_hostname' が不明です
    警告: cib-bootstrap-options: 属性 'azure-events_globalPullState' が不明です
    警告: cib-bootstrap-options: 属性 'hostName_ hostname' が不明です
    これらの警告メッセージは無視しても大丈夫です。

次のステップ