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

[アーティクル]
08/26/2024

この記事では、Azure の SUSE Linux Enterprise Server (SLES) で Pacemaker を設定する方法について説明します。

概要

Azure には、SLES の Pacemaker クラスターにフェンスを設定するためのオプションが 2 つあります。 Azure API で障害が発生したノードを再起動する Azure のフェンスエージェントを使用するか、SBD デバイスを使用できます。

SBD デバイスを使用する

SBD デバイスを構成するには、次の 2 つのオプションのいずれかを使用します。

SBD と iSCSI ターゲットサーバー:

SBD デバイスを使う場合、Internet Small Computer System Interface (iSCSI) ターゲットサーバーとして機能しつつ SBD デバイスを提供する仮想マシン (VM) が、少なくとも 1 つ、追加で必要となります。ただし、これらの iSCSI ターゲットサーバーは他の Pacemaker クラスターと共有することができます。 SBD デバイスを使う利点は、SBD デバイスを既にオンプレミスで使用している場合、Pacemaker クラスターの運用方法に変更を加える必要は一切ないことです。

特定の SBD デバイスが利用できなくなる状況 (たとえば、iSCSI ターゲットサーバーの OS 修正プログラムの適用時など) に備えるにあたっては、1 つの Pacemaker クラスターに対し、最大 3 つの SBD デバイスを使用できます。 Pacemaker あたり 2 つ以上の SBD デバイスを使用する場合は、複数の iSCSI ターゲットサーバーをデプロイし、各 iSCSI ターゲットサーバーから 1 つの SBD を接続するようにしてください。 SBD デバイスは、1 つまたは 3 つ使用することをお勧めします。 2 つの SBD デバイスのみが構成されていて、そのうちの 1 つが使用できない場合、Pacemaker はクラスターノードを自動的にフェンスできません。 1 つの iSCSI ターゲットサーバーがダウンした場合にフェンシングを行えるようにするには、3 つの SBD デバイスと、3 つの iSCSI ターゲットサーバーを使用する必要があります。これは、SBD を使用しているときの回復力が最も高い構成です。

重要

Linux Pacemaker クラスターノードと SBD デバイスを計画してデプロイする場合、仮想マシンと、ネットワーク仮想アプライアンス (NVA) など、他のデバイスを通過するための SBD デバイスをホストする VM 間をルーティングしないようにする必要があります。

メンテナンスイベントと NVA の問題がクラスター構成全体の安定性と信頼性に負の影響を与える可能性があります。詳細については、「ユーザー定義のルール」を参照してください。
SBD と Azure 共有ディスク:

SBD デバイスを構成するには、Pacemaker クラスターに属しているすべての仮想マシンに、Azure 共有ディスクを少なくとも 1 つアタッチする必要があります。 Azure 共有ディスクを使用する SBD デバイスの利点は、仮想マシンを別途デプロイする必要がないことです。

Azure 共有ディスクを使用している場合の SBD デバイスに関する重要な考慮事項を次に示します。
- Premium SSD を使用した Azure 共有ディスクが SBD デバイスとしてサポートされます。
- Azure 共有ディスクを使用する SBD デバイスは、SLES High Availability 15 SP01 以降でサポートされています。
- Azure Premium 共有ディスクを使用する SBD デバイスは、ローカル冗長ストレージ (LRS) およびゾーン冗長ストレージ (ZRS) でサポートされます。
- デプロイの種類に応じて、Azure 共有ディスクの適切な冗長ストレージを SBD デバイスとして選択します。
- Azure Premium 共有ディスクに LRS を使用する SBD デバイス (skuName - Premium_LRS) は、可用性セットへのデプロイでのみサポートされます。
- 可用性ゾーンへのデプロイには、Azure Premium 共有ディスクに ZRS を使用する SBD デバイス (skuName - Premium_ZRS) が推奨されます。
- 可用性ゾーンがある一部のリージョンでは現在、マネージドディスクの ZRS が利用できません。詳細については、「管理ディスクの冗長オプション」の ZRS の「制限事項」セクションを参照してください。
- SBD デバイスに使用する Azure 共有ディスクは、大きなサイズである必要はありません。共有ディスクを使用できるクラスターノードの数は、maxShares 値によって決まります。たとえば、SAP ASCS/ERS、SAP HANA スケールアップなどの 2 ノードクラスターでは、SBD デバイスに P1 または P2 のディスクサイズを使用できます。
- HANA システムレプリケーション (HSR) と Pacemaker を含む HANA スケールアウトの場合、SBD デバイスに Azure 共有ディスクを使用できるのは、現在の maxShares の制限により、レプリケーションサイトあたり最大 4 ノードのクラスターとなります。
- Azure 共有ディスクの SBD デバイスを Pacemaker クラスター全体にアタッチすることはお勧めできません。
- Azure 共有ディスクの SBD デバイスを複数使用する場合は、VM にアタッチできる最大データディスク数の上限を確認してください。
- Azure 共有ディスクの制限事項の詳細については、Azure 共有ディスクのドキュメントの「制限事項」セクションを参照してください。

Azure フェンスエージェントを使用する

フェンスは、Azure フェンスエージェントを使用して設定できます。 Azure フェンスエージェントでは、クラスター VM のマネージド ID か、障害が発生したノードの再起動を Azure API 経由で管理するサービスプリンシパルが必要です。 Azure フェンスエージェントでは、追加の仮想マシンをデプロイする必要はありません。

SBD と iSCSI ターゲットサーバー

フェンスに iSCSI ターゲットサーバーを使用する SBD デバイスを使用するには、次のセクションの手順に従います。

iSCSI ターゲットサーバーをセットアップする

まず、iSCSI ターゲット仮想マシンを作成する必要があります。 iSCSI ターゲットサーバーは、複数の Pacemaker クラスターと共有することができます。

新しい SLES 12 SP3 以降の仮想マシンをデプロイし、SSH 経由でそれらに接続します。サイズの大きいマシンは必要ありません。 Standard_E2s_v3 または Standard_D2s_v3 などの仮想マシンサイズで十分です。 OS ディスクには Premium ストレージを使用してください。
iSCSI ターゲット仮想マシンに対し、次のコマンドを実行します。

a. SLES を更新します。
```
sudo zypper update
```
注意

OS のアップグレード後または更新後に、OS の再起動が必要になる場合があります。

b. パッケージを削除します。

targetcli および SLES 12 SP3 に関する既知の問題を回避するには、次のパッケージをアンインストールします。見つからないパッケージに関するエラーは無視できます。
```
sudo zypper remove lio-utils python-rtslib python-configshell targetcli
```
c. iSCSI ターゲットパッケージをインストールします。
```
sudo zypper install targetcli-fb dbus-1-python
```
d. iSCSI ターゲットサービスを有効にします。
```
sudo systemctl enable targetcli
sudo systemctl start targetcli
```

iSCSI ターゲットサーバーに iSCSI デバイスを作成する

SAP システムによって使用されるクラスター用の iSCSI ディスクを作成するには、すべての iSCSI ターゲット仮想マシンで次のコマンドを実行します。この例では、複数のクラスターに対して SBD デバイスが作成されています。ここでは、複数のクラスターに対して 1 つの iSCSI ターゲットサーバーを使用する方法を示しています。 SBD デバイスは OS ディスク上に配置されます。十分な容量があることを確認してください。

nfs: NFS クラスターを識別します。
ascsnw1: NW1 の ACS クラスターを識別します。
dbnw1: NW1 のデータベースクラスターを識別します。
nfs-0 と nfs-1: NFS クラスターノードのホスト名。
nw1-xscs-0 と nw1-xscs-1: NW1 ASCS クラスターノードのホスト名。
nw1-db-0 と nw1-db-1: データベースクラスターノードのホスト名。

以下の手順では、クラスターノードのホスト名と SAP システムの SID を置き換えて調整します。

すべての SBD デバイスのルートフォルダーを作成します。
```
sudo mkdir /sbd
```

NFS サーバー用の SBD デバイスを作成します。

sudo targetcli backstores/fileio create sbdnfs /sbd/sbdnfs 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.nfs.local:nfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/luns/ create /backstores/fileio/sbdnfs
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-0.local:nfs-0
sudo targetcli iscsi/iqn.2006-04.nfs.local:nfs/tpg1/acls/ create iqn.2006-04.nfs-1.local:nfs-1

SAP System NW1 の ASCS サーバー用の SBD デバイスを作成します。

sudo targetcli backstores/fileio create sbdascsnw1 /sbd/sbdascsnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.ascsnw1.local:ascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/luns/ create /backstores/fileio/sbdascsnw1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1

SAP System NW1 のデータベースクラスター用の SBD デバイスを作成します。

sudo targetcli backstores/fileio create sbddbnw1 /sbd/sbddbnw1 50M write_back=false
sudo targetcli iscsi/ create iqn.2006-04.dbnw1.local:dbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/luns/ create /backstores/fileio/sbddbnw1
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-0.local:nw1-db-0
sudo targetcli iscsi/iqn.2006-04.dbnw1.local:dbnw1/tpg1/acls/ create iqn.2006-04.nw1-db-1.local:nw1-db-1

targetcli の変更を保存します。
```
sudo targetcli saveconfig
```

すべてが正しく設定されていることを確認します。

sudo targetcli ls

o- / .......................................................................................................... [...]
o- backstores ............................................................................................... [...]
| o- block ................................................................................... [Storage Objects: 0]
| o- fileio .................................................................................. [Storage Objects: 3]
| | o- sbdascsnw1 ................................................ [/sbd/sbdascsnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbddbnw1 .................................................... [/sbd/sbddbnw1 (50.0MiB) write-thru activated]
| | | o- alua .................................................................................... [ALUA Groups: 1]
| | |   o- default_tg_pt_gp ........................................................ [ALUA state: Active/optimized]
| | o- sbdnfs ........................................................ [/sbd/sbdnfs (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: 3]
| o- iqn.2006-04.ascsnw1.local:ascsnw1 .................................................................. [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-xscs-0.local:nw1-xscs-0 ............................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 ............................................................ [lun0 fileio/sbdascsnw1 (rw)]
| |   | o- iqn.2006-04.nw1-xscs-1.local:nw1-xscs-1 ............................................... [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- iqn.2006-04.dbnw1.local:dbnw1 ...................................................................... [TPGs: 1]
| | o- tpg1 ................................................................................ [no-gen-acls, no-auth]
| |   o- acls ........................................................................................... [ACLs: 2]
| |   | o- iqn.2006-04.nw1-db-0.local:nw1-db-0 ................................................... [Mapped LUNs: 1]
| |   | | o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   | o- iqn.2006-04.nw1-db-1.local:nw1-db-1 ................................................... [Mapped LUNs: 1]
| |   |   o- mapped_lun0 .............................................................. [lun0 fileio/sbddbnw1 (rw)]
| |   o- luns ........................................................................................... [LUNs: 1]
| |   | o- lun0 .............................................. [fileio/sbddbnw1 (/sbd/sbddbnw1) (default_tg_pt_gp)]
| |   o- portals ..................................................................................... [Portals: 1]
| |     o- 0.0.0.0:3260 ...................................................................................... [OK]
| o- iqn.2006-04.nfs.local:nfs .......................................................................... [TPGs: 1]
|   o- tpg1 ................................................................................ [no-gen-acls, no-auth]
|     o- acls ........................................................................................... [ACLs: 2]
|     | o- iqn.2006-04.nfs-0.local:nfs-0 ......................................................... [Mapped LUNs: 1]
|     | | o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     | o- iqn.2006-04.nfs-1.local:nfs-1 ......................................................... [Mapped LUNs: 1]
|     |   o- mapped_lun0 ................................................................ [lun0 fileio/sbdnfs (rw)]
|     o- luns ........................................................................................... [LUNs: 1]
|     | o- lun0 .................................................. [fileio/sbdnfs (/sbd/sbdnfs) (default_tg_pt_gp)]
|     o- portals ..................................................................................... [Portals: 1]
|       o- 0.0.0.0:3260 ...................................................................................... [OK]
o- loopback .......................................................................................... [Targets: 0]
o- vhost ............................................................................................. [Targets: 0]
o- xen-pvscsi ........................................................................................ [Targets: 0]

iSCSI ターゲットサーバーの SBD デバイスをセットアップする

最後の手順で作成した iSCSI デバイスにクラスターから接続します。以下のコマンドは、作成する新しいクラスターの各ノード上で実行します。

注意

[A]: すべてのノードに適用されます。
[1]: ノード 1 にのみ適用されます。
[2]: ノード 2 にのみ適用されます。

[A] iSCSI パッケージをインストールします。
```
sudo zypper install open-iscsi
```
[A] iSCSI デバイスに接続します。まず、iSCSI サービスと SBD サービスを有効にします。
```
sudo systemctl enable iscsid
sudo systemctl enable iscsi
sudo systemctl enable sbd
```
[1] 1 つ目のノードでイニシエーターの名前を変更します。
```
sudo vi /etc/iscsi/initiatorname.iscsi
```
[1] iSCSI ターゲットサーバーに iSCSI デバイスを作成したときに使ったアクセス制御リスト (ACL) に合わせて、ファイルの内容を変更します (たとえば、NFS サーバー用に)。
```
InitiatorName=iqn.2006-04.nfs-0.local:nfs-0
```
[2] 2 つ目のノードでイニシエーターの名前を変更します。
```
sudo vi /etc/iscsi/initiatorname.iscsi
```
[2] iSCSI ターゲットサーバーに iSCSI デバイスを作成したときに使った ACL に合わせてファイルの内容を変更します。
```
InitiatorName=iqn.2006-04.nfs-1.local:nfs-1
```
[A] ここで iSCSI サービスを再起動すると、変更が適用されます。
```
sudo systemctl restart iscsid
sudo systemctl restart iscsi
```
[A] iSCSI デバイスを接続します。下の例の 10.0.0.17 は iSCSI ターゲットサーバーの IP アドレス、3260 は既定のポートです。 iqn.2006-04.nfs.local:nfs は、次の 1 つ目のコマンド (iscsiadm -m discovery) を実行したときに表示されるターゲット名の 1 つです。
```
sudo iscsiadm -m discovery --type=st --portal=10.0.0.17:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.17:3260
sudo iscsiadm -m node -p 10.0.0.17:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic
```

[A] 複数の SBD デバイスを使用する場合は、2 つ目の iSCSI ターゲットサーバーにも接続します。

sudo iscsiadm -m discovery --type=st --portal=10.0.0.18:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.18:3260
sudo iscsiadm -m node -p 10.0.0.18:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

[A] 複数の SBD デバイスを使用する場合は、3 つ目の iSCSI ターゲットサーバーにも接続します。

sudo iscsiadm -m discovery --type=st --portal=10.0.0.19:3260   
sudo iscsiadm -m node -T iqn.2006-04.nfs.local:nfs --login --portal=10.0.0.19:3260
sudo iscsiadm -m node -p 10.0.0.19:3260 -T iqn.2006-04.nfs.local:nfs --op=update --name=node.startup --value=automatic

[A] iSCSI デバイスが利用可能な状態であることを確認し、デバイス名を書き留めておいてください (次の例では /dev/sde)。

lsscsi

# [2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc
# [5:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdd
# [6:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdd
# [7:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sde
# [8:0:0:0]    disk    LIO-ORG  sbdnfs           4.0   /dev/sdf

[A] ここで、iSCSI デバイスの ID を取得します。

ls -l /dev/disk/by-id/scsi-* | grep sdd

# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -> ../../sdd
# lrwxrwxrwx 1 root root  9 Aug  9 13:20 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_afb0ba8d-3a3c-413b-8cc2-cca03e63ef42 -> ../../sdd

ls -l /dev/disk/by-id/scsi-* | grep sde

# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-1LIO-ORG_cl1:3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -> ../../sde
# lrwxrwxrwx 1 root root  9 Feb  7 12:39 /dev/disk/by-id/scsi-SLIO-ORG_cl1_3fe4da37-1a5a-4bb6-9a41-9a4df57770e4 -> ../../sde

ls -l /dev/disk/by-id/scsi-* | grep sdf

# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-1LIO-ORG_sbdnfs:f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -> ../../sdf
# lrwxrwxrwx 1 root root  9 Aug  9 13:32 /dev/disk/by-id/scsi-SLIO-ORG_sbdnfs_f88f30e7-c968-4678-bc87-fe7bfcbdb625 -> ../../sdf

このコマンドを実行すると、SBD デバイスごとに 3 つのデバイス ID が一覧表示されます。 scsi-3 で始まる ID を使用することをお勧めします。前の例では、ID は次のようになります。

/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03
/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df
/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf

[1] SBD デバイスを作成します。

a. iSCSI デバイスのデバイス ID を使用して、1 つ目のクラスターノードに新しい SBD デバイスを作成します。
```
sudo sbd -d /dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03 -1 60 -4 120 create
```
b. 複数の SBD デバイスを使用する場合は、2 つ目と 3 つ目の SBD デバイスも作成します。
```
sudo sbd -d /dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df -1 60 -4 120 create
sudo sbd -d /dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf -1 60 -4 120 create
```
[A] SBD の構成を調整します。

a. SBD の構成ファイルを開きます。
```
sudo vi /etc/sysconfig/sbd
```
b. SBD デバイスのプロパティを変更し、Pacemaker の統合を有効にして、SBD の起動モードを変更します。
```
[...]
SBD_DEVICE="/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-360014053fe4da371a5a4bb69a419a4df;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]
```
Note

SBD_DELAY_START プロパティ値が "no" に設定されている場合は、値を "yes" に変更します。また、SBD サービスファイルを確認して、TimeoutStartSec の値が SBD_DELAY_START の値より大きいことを確認する必要があります。詳細については、SBD ファイル構成に関するページを参照してください

[A]softdog 構成ファイルを作成します。

echo softdog | sudo tee /etc/modules-load.d/softdog.conf

[A] モジュールを読み込みます。
```
sudo modprobe -v softdog
```

SBD と Azure 共有ディスク

このセクションは、Azure 共有ディスクで SBD デバイスを使用する場合にのみ適用されます。

PowerShell を使用して Azure 共有ディスクを作成および接続する

リソースグループ、Azure リージョン、仮想マシン、論理ユニット番号 (LUN) などの値は適宜調整してください。
```
$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
```
Premium SSD の使用可能なディスクサイズに基づいて、ディスクのサイズを定義します。この例では、4G の P1 ディスクサイズについて説明します。
```
$DiskSizeInGB = 4
$DiskName = "SBD-disk1"
```
-MaxSharesCount パラメーターで、SBD デバイスの共有ディスクをアタッチするクラスターノードの最大数を定義します。
```
$ShareNodes = 2
```
Azure Premium 共有ディスクに LRS を使用する SBD デバイスの場合は、次の SkuName を使用します。
```
$SkuName = "Premium_LRS"
```
Azure Premium 共有ディスクに ZRS を使用する SBD デバイスの場合は、次の SkuName を使用します。
```
$SkuName = "Premium_ZRS"
```

Azure 共有ディスクをセットアップします。

$diskConfig = New-AzDiskConfig -Location $Location -SkuName $SkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $diskConfig

クラスター VM にディスクをアタッチします。

$VM1 = "prod-cl1-0"
$VM2 = "prod-cl1-1"

a. Azure 共有ディスクをクラスターノード 1 に追加します。

$vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM1
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

b. Azure 共有ディスクをクラスターノード 2 に追加します。

$vm = Get-AzVM -ResourceGroupName $ResourceGroup -Name $VM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroup -Verbose

Azure CLI または Azure portal を使用してリソースをデプロイしたい場合は、「ZRS ディスクのデプロイ」も参照してください。

Azure 共有ディスクの SBD デバイスをセットアップする

[A] SBD サービスを有効にします。
```
sudo systemctl enable sbd
```

[A] アタッチされているディスクが利用可能であることを確認します。

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0      2:0    1    4K  0 disk
sda      8:0    0   30G  0 disk
├─sda1   8:1    0    2M  0 part
├─sda2   8:2    0  512M  0 part /boot/efi
├─sda3   8:3    0    1G  0 part /boot
├─sda4   8:4    0 28.5G  0 part /
sdb      8:16   0  256G  0 disk
├─sdb1   8:17   0  256G  0 part /mnt
sdc      8:32   0    4G  0 disk
sr0     11:0    1 1024M  0 rom

# lsscsi
[1:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0
[2:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[3:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[5:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdc

[A] アタッチされているディスクの ID を取得します。
```
# ls -l /dev/disk/by-id/scsi-* | grep sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-14d534654202020204208a67da80744439b513b2a9728af19 -> ../../sdc
lrwxrwxrwx 1 root root  9 Nov  8 16:55 /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -> ../../sdc
```
コマンドを使用すると、SBD デバイスのデバイス ID が一覧表示されます。 scsi-3 で始まる ID を使用することをお勧めします。前の例では、ID は /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 です。
[1] SBD デバイスを作成します。

手順 2. のデバイス ID を使用して、1 つ目のクラスターノードに新しい SBD デバイスを作成します。
```
# sudo sbd -d /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -1 60 -4 120 create
```
[A] SBD の構成を調整します。

a. SBD の構成ファイルを開きます。
```
sudo vi /etc/sysconfig/sbd
```
b. SBD デバイスのプロパティを変更し、Pacemaker の統合を有効にして、SBD デバイスの起動モードを変更します。
```
[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]
```
Note

SBD_DELAY_START プロパティ値が "no" に設定されている場合は、値を "yes" に変更します。また、SBD サービスファイルを確認して、TimeoutStartSec の値が SBD_DELAY_START の値より大きいことを確認する必要があります。詳細については、SBD ファイル構成に関するページを参照してください

softdog 構成ファイルを作成します。

echo softdog | sudo tee /etc/modules-load.d/softdog.conf

モジュールを読み込みます。
```
sudo modprobe -v softdog
```

Azure フェンスエージェントを使用する

このセクションは、Azure フェンスエージェントでフェンスデバイスを使用する場合にのみ適用されます。

Azure フェンスエージェントデバイスを作成する

このセクションは、Azure フェンスエージェントに基づくフェンスデバイスを使用している場合にのみ適用されます。フェンスデバイスは、マネージド ID またはサービスプリンシパルを使用して、Microsoft Azure に対する認可を行います。

マネージド ID
サービスプリンシパル

マネージド ID (MSI) を作成するには、クラスター内の VM ごとにシステム割り当てマネージド ID を作成します。システム割り当てマネージド ID が既に存在する場合は、それが使用されます。現時点では、Pacemaker でユーザー割り当てマネージド ID を使用しないでください。マネージド ID に基づく Azure フェンスエージェントは、SLES 12 SP5 および SLES 15 SP1 以降でサポートされています。

サービスプリンシパルを作成するには、次の手順を実行します。

Azure portal から、[Microsoft Entra ID]>[プロパティ] の順に選び、[ディレクトリ ID] を書き留めます。これは、テナント ID です。
[アプリの登録] を選択します。
[新規登録] を選択します。
登録の名前を入力し、[この組織ディレクトリ内のアカウントのみ] を選択します。
[アプリケーションの種類] では [Web] を選択し、サインオン URL (http://localhost など) を入力して [追加] を選択します。
サインオン URL は使用されず、任意の有効な URL を指定することができます。
[証明書とシークレット] を選択してから、[新しいクライアントシークレット] を選択します。
新しいキーの説明を入力し、[2 年間] を選択して、[追加] を選択します。
サービスプリンシパルのパスワードとして使用する値を書き留めます。
[概要] を選択し、サービスプリンシパルのユーザー名として使用するアプリケーション ID を書き留めます。

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

既定では、マネージド ID とサービスプリンシパルのどちらにも、Azure リソースにアクセスするためのアクセス許可はありません。クラスターのすべての仮想マシンを開始および停止 (割り当て解除) するアクセス許可をマネージド 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 またはサービスプリンシパルを使用します。

マネージド ID
サービスプリンシパル

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

重要

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

クラスターをインストールする

注意

[A]: すべてのノードに適用されます。
[1]: ノード 1 にのみ適用されます。
[2]: ノード 2 にのみ適用されます。

[A] SLES を更新します。
```
sudo zypper update
```
Note

SLES 15 SP4 の場合、crmsh および pacemaker パッケージのバージョンを確認し、最小バージョン要件を満たしていることを確認します。
- crmsh-4.4.0+20221028.3e41444-150400.3.9.1 以降
- pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 以降
重要
- SLES 12 SP5: python-azure-core-1.23.1-2.12.8 がインストールされている場合、Pacemaker クラスターで Azure フェンスエージェントが起動せず、/var/log/messages に "Azure Resource Manager Python SDK が見つからないかアクセスできません" というエラーメッセージが表示されることがあります。詳細については、SUSE KBA 21532 の手順に従ってください。
- SLES 15 SP4 以降: OS の更新後、Python 用 Azure ライブラリで Python 3.11 インタープリターを使用すると、Pacemaker クラスターで Azure フェンスエージェントが起動しなくなることがあります。 /var/log/messages に "Azure Resource Manager Python SDK が見つからないかアクセスできません" というエラーメッセージが表示されます。詳細については、SUSE KBA 21504 の手順に従ってください。
[A] クラスターリソースに必要なコンポーネントをインストールします。
```
sudo zypper in socat
```
[A] クラスターリソースに必要な azure-lb コンポーネントをインストールします。
```
sudo zypper in resource-agents
```
Note

resource-agents パッケージのバージョンを確認し、最小バージョン要件が満たされていることを確認します。
- SLES 12 SP4/SP5: バージョンは resource-agents-4.3.018.a7fb5035-3.30.1 以上である必要があります。
- SLES 15/15 SP1: バージョンは resource-agents-4.3.0184.6ee15eb2-4.13.1 以上である必要があります。
[A] オペレーティングシステムを構成します。

a. Pacemaker では、許可された数を使い果たす可能性がある多数のプロセスが作成される場合があります。その場合、クラスターノード間のハートビートが失敗し、リソースのフェールオーバーが発生する可能性があります。次のパラメーターを設定して、許可されるプロセスの最大数を増やすことをお勧めします。
```
# Edit the configuration file
sudo vi /etc/systemd/system.conf

# Change the DefaultTasksMax
#DefaultTasksMax=512
DefaultTasksMax=4096

# Activate this setting
sudo systemctl daemon-reload

# Test to ensure that the change was successful
sudo systemctl --no-pager show | grep DefaultTasksMax
```
b. ダーティキャッシュのサイズを小さくします。詳しくは、「Low write performance on SLES 11/12 servers with large RAM」(大容量 RAM を備えた SLES 11/12 サーバーでの書き込みのパフォーマンスの低さ) をご覧ください。
```
sudo vi /etc/sysctl.conf
# Change/set the following settings
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800
```
c. スワップの使用量を減らし、メモリを優先するには、vm.swapiness が 10 に設定されていることを確認します。
```
sudo vi /etc/sysctl.conf
# Change/set the following setting
vm.swappiness = 10
```
[A] cloud-netconfig-azure パッケージのバージョンを確認します。

zypper info cloud-netconfig-azure を実行して、cloud-netconfig-azure パッケージのインストールされているバージョンを確認します。バージョンが 1.3 より前の場合は、cloud-netconfig-azure パッケージを利用可能な最新バージョンに更新することをお勧めします。

ヒント

環境内のバージョンが 1.3 以降である場合、クラウドネットワークプラグインによるネットワークインターフェイスの管理を抑制する必要はなくなりました。

cloud-netconfig-azure のバージョンが 1.3 未満の場合のみ、次のコードに示すように、ネットワークインターフェイスの構成ファイルを変更して、クラウドネットワークプラグインが仮想 IP アドレスを削除しないようにします (Pacemaker で割り当てを制御する必要があります)。詳細については、SUSE KB 7023633 を参照してください。
```
# Edit the configuration file
sudo vi /etc/sysconfig/network/ifcfg-eth0 

# Change CLOUD_NETCONFIG_MANAGE
# CLOUD_NETCONFIG_MANAGE="yes"
CLOUD_NETCONFIG_MANAGE="no"
```

[1] SSH アクセスを有効にします。

sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

[2] SSH アクセスを有効にします。

sudo ssh-keygen

# Enter file in which to save the key (/root/.ssh/id_rsa), and then select Enter
# Enter passphrase (empty for no passphrase), and then select Enter
# Enter same passphrase again, and then select Enter

# Insert the public key you copied in the last step into the authorized keys file on the second server
sudo vi /root/.ssh/authorized_keys   

# copy the public key
sudo cat /root/.ssh/id_rsa.pub

[1] SSH アクセスを有効にします。

# insert the public key you copied in the last step into the authorized keys file on the first server
sudo vi /root/.ssh/authorized_keys

[A] フェンスデバイスを使用している場合は、Azure フェンスエージェントに基づいて、fence-agents パッケージをインストールします。
```
sudo zypper install fence-agents
```
重要

クラスターノードがフェンスされる場合に、Azure フェンスエージェントの短縮されたフェールオーバー時間の恩恵を受けるには、インストールされている fence-agents パッケージのバージョンが 4.4.0 以上である必要があります。以前のバージョンを実行している場合は、パッケージを更新することをお勧めします。
重要

マネージド ID を使用する場合、インストールされている fence-agents パッケージのバージョンは、次のとおりである必要があります。
- SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 以降
- SLES 15 SP1 以降: fence-agents 4.5.2+git.1592573838.1eee0863 以降。
以前のバージョンは、マネージド ID 構成では正しく動作しません。

[A] fence-agents-azure-arm パッケージをインストールします。

SLES 12 SP5 で fence-agents バージョン 4.9.0+git.1624456340.8d746be9-3.41.3 以降を使用している場合と、SLES 15 SP4 以降の場合は、fence-agents-azure-arm パッケージをインストールする必要があります。このパッケージには、必要な依存関係がすべて含まれます。

# On SLES 12 SP5 with fence-agents version 4.9.0+git.1624456340.8d746be9-3.41.3 or higher. You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install fence-agents-azure-arm

# On SLES 15 SP4 and later. You might need to activate the public cloud extension first. In this example, the SUSEConnect 
SUSEConnect -p sle-module-public-cloud/15.4/x86_64
sudo zypper install fence-agents-azure-arm

[A] Azure Python SDK と Azure Identity Python モジュールをインストールします。

SLES 12 SP5 で、お使いの fence-agents のバージョンが 4.9.0+git.1624456340.8d746be9-3.41.3 より前の場合と、SLES 15 SP3 以降の場合は、以下の追加パッケージをインストールする必要があります。
```
# You might need to activate the public cloud extension first
SUSEConnect -p sle-module-public-cloud/12/x86_64
sudo zypper install python-azure-mgmt-compute
sudo zypper install python-azure-identity

# You might need to activate the public cloud extension first. In this example, the SUSEConnect command is for SLES 15 SP1
SUSEConnect -p sle-module-public-cloud/15.1/x86_64
sudo zypper install python3-azure-mgmt-compute
sudo zypper install python3-azure-identity
```
重要

バージョンとイメージの種類によっては、Azure Python SDK をインストールする前に、使用している OS リリースのパブリッククラウド拡張機能をアクティブにする必要がある場合があります。拡張機能は、SUSEConnect ---list-extensions を実行して確認できます。 Azure フェンスエージェントでフェールオーバー時間を短縮するには、次のようにします。
- SLES 12 SP5 の場合、python-azure-mgmt-compute パッケージのバージョン 4.6.2 以降をインストールします。
- python-azure-mgmt-comput または python3-azure-mgmt-compute のバージョンが 17.0.0-6.7.1 の場合は、SUSE KBA の手順に従って、fence-agents のバージョンを更新し、Azure Identity Client Library for Python モジュールが存在しない場合はインストールします。
[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
```

[1] クラスターをインストールします。

フェンスに SBD デバイス (iSCSI ターゲットサーバーまたは Azure 共有ディスク) を使用する場合:

sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# SBD is already configured to use /dev/disk/by-id/scsi-36001405639245768818458b930abdf69;/dev/disk/by-id/scsi-36001405afb0ba8d3a3c413b8cc2cca03;/dev/disk/by-id/scsi-36001405f88f30e7c9684678bc87fe7bf - overwrite (y/n)? n
# Do you wish to configure an administration IP (y/n)? n

フェンスに SBD デバイスを使用していない場合:

sudo crm cluster init
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n
# Address for ring0 [10.0.0.6] Select Enter
# Port for ring0 [5405] Select Enter
# Do you wish to use SBD (y/n)? n
# WARNING: Not configuring SBD - STONITH will be disabled.
# Do you wish to configure an administration IP (y/n)? n

[2] クラスターにノードを追加します。

sudo crm cluster join
# ! NTP is not configured to start at system boot.
# Do you want to continue anyway (y/n)? y
# IP address or hostname of existing node (for example, 192.168.1.1) []10.0.0.6
# /root/.ssh/id_rsa already exists - overwrite (y/n)? n

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

[A] corosync の設定を調整します。

sudo vi /etc/corosync/corosync.conf

a. ファイル内の次のセクションを確認し、値が存在しないか異なる場合は調整します。トークンを 30000 に変更してメモリ保持メンテナンスを可能にします。詳細については、Linux または Windows の「仮想マシンのメンテナンス」の記事を参照してください。

[...]
  token:          30000
  token_retransmits_before_loss_const: 10
  join:           60
  consensus:      36000
  max_messages:   20

  interface { 
     [...] 
  }
  transport:      udpu
} 
nodelist {
  node {
   ring0_addr:10.0.0.6
  }
  node {
   ring0_addr:10.0.0.7
  } 
}
logging {
  [...]
}
quorum {
     # Enable and configure quorum subsystem (default: off)
     # See also corosync.conf.5 and votequorum.5
     provider: corosync_votequorum
     expected_votes: 2
     two_node: 1
}

b. corosync サービスを再起動します。

sudo service corosync restart

Pacemaker クラスターにフェンスデバイスを作成する

ヒント

2 ノードの Pacemaker クラスター内でのフェンスレースを回避するには、追加の "priority-fencing-delay" クラスタープロパティを構成します。このプロパティを使用すると、スプリットブレインシナリオが発生したときに、リソースの優先度の合計が高いノードをフェンスする際に、さらに遅延が発生するようになります。詳細については、SUSE Linux Enteprise Server の High Availability Extension 管理ガイドを参照してください。
"priority-fencing-delay" クラスタープロパティの設定手順については、SAP ASCS/ERS (ENSA2 でのみ適用可能) と SAP HANA スケールアップ高可用性ドキュメントを参照してください。

[1] SBD デバイス (iSCSI ターゲットサーバーまたは Azure 共有ディスク) をフェンスデバイスとして使用する場合は、次のコマンドを実行します。フェンスデバイスの使用を有効にし、フェンスの遅延を設定します。

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

# List the resources to find the name of the SBD device
sudo crm resource list
sudo crm resource stop stonith-sbd
sudo crm configure delete stonith-sbd
sudo crm configure primitive stonith-sbd stonith:external/sbd \
   params pcmk_delay_max="15" \
   op monitor interval="600" timeout="15"

[1] フェンスに Azure フェンスエージェントを使用している場合は、次のコマンドを実行します。両方のクラスターノードにロールを割り当てたら、クラスターのフェンスデバイスを構成できます。
```
sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true
```
注意

"pcmk_host_map" オプションは、ホスト名と Azure VM 名が同一でない場合のみ、このコマンドで必要です。 hostname:vm-name の形式でマッピングを指定します。

マネージド ID
サービスプリンシパル

# Adjust the command with your subscription ID and resource group of the VM

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
params msi=true subscriptionId="subscription ID" resourceGroup="resource group" \
pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_delay_max=15 pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
op monitor interval=3600 timeout=120

sudo crm configure property stonith-timeout=900

# Adjust the command with your subscription ID, resource group of the VM, tenant ID, service principal application ID and password

sudo crm configure primitive rsc_st_azure stonith:fence_azure_arm \
params subscriptionId="subscription ID" resourceGroup="resource group" tenantId="tenant ID" login="application ID" passwd="password" \
pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_delay_max=15 pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
op monitor interval=3600 timeout=120

sudo crm configure property stonith-timeout=900

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

重要

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

ヒント

Azure フェンスエージェントでは、「標準 ILB を使用した VM 用のパブリックエンドポイント接続」で説明されているように、使用可能なソリューションと共に、パブリックエンドポイントへの送信接続が必要です。

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

Azure では、スケジュール化されたイベントが提供されています。スケジュール化されたイベントは、メタデータサービスを介して指定され、このようなイベントに対して準備する時間をアプリケーションに与えます。リソースエージェント azure-events-az では、スケジュール化された Azure イベントが監視されます。イベントが検出され、リソースエージェントが別のクラスターノードが使用可能であると判断した場合は、クラスター正常性属性が設定されます。ノードにクラスター正常性属性が設定されると、場所制約がトリガーされ、その名前が "health-" で始まらないすべてのリソースが、スケジュール化されたイベントを含むノードから移行されます。影響を受けるクラスターノードが実行中のクラスターリソースを解放すると、スケジュール化されたイベントが確認され、再起動などのアクションを実行できます。

重要

前回は、リソースエージェント azure-events の使用について説明しました。新しいリソースエージェント azure-events-az は、さまざまな可用性ゾーンに展開された Azure 環境を完全にサポートします。 Pacemaker を使用するすべての SAP 高可用性システムには、新しい azure-events-az エージェントを使用することをお勧めします。

[A] azure-events エージェントのパッケージが既にインストールされ、最新であることを確認します。
```
sudo zypper info resource-agents
```
最小バージョンの要件:
- SLES 12 SP5: resource-agents-4.3.018.a7fb5035-3.98.1
- SLES 15 SP1: resource-agents-4.3.0184.6ee15eb2-150100.4.72.1
- SLES 15 SP2: resource-agents-4.4.0+git57.70549516-150200.3.56.1
- SLES 15 SP3: resource-agents-4.8.0+git30.d0077df0-150300.8.31.1
- SLES 15 SP4 以降: resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

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

#Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true

[1] Pacemaker クラスター正常性ノードの戦略と制約を設定します。
```
sudo crm configure property node-health-strategy=custom
sudo crm configure location loc_azure_health \
/'!health-.*'/ rule '#health-azure': defined '#uname'
```
重要

ドキュメントの次の手順で説明するリソース以外に、"health-" で始まるクラスター内の他のリソースは定義しないでください。
[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
```
[1] Pacemaker 内でリソースを構成します。重要: リソースは、'health-azure' で始まる必要があります。
```
sudo crm configure primitive health-azure-events ocf:heartbeat:azure-events-az \
meta allow-unhealthy-nodes=true failure-timeout=120s \
op start start-delay=60s \
op monitor interval=10s

sudo crm configure clone health-azure-events-cln health-azure-events
```
Note

'health-azure-events' リソースを構成する場合、次の警告メッセージは無視できます。

警告: health-azure-events: 未知の属性 'allow-unhealthy-nodes'。
Pacemaker クラスターのメンテナンスモードを解除する
```
sudo crm configure property maintenance-mode=false
```
有効化中にエラーをクリアし、health-azure-events リソースがすべてのクラスターノードで正常に開始されたことを確認します。
```
sudo crm resource cleanup
```
スケジュール化されたイベントに対する初回クエリの実行には、最大 2 分かかることがあります。スケジュール化されたイベントを使用した Pacemaker テストでは、クラスター VM の再起動または再デプロイアクションを使用できます。詳細については、「スケジュールされたイベント」のドキュメントを参照してください。

Note

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

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

次のステップ

SAP のための Azure Virtual Machines の計画と実装
SAP のための Azure Virtual Machines のデプロイ
SAP のための Azure Virtual Machines DBMS のデプロイ
SUSE Linux Enterprise Server 上の Azure VM での NFS の高可用性
SUSE Linux Enterprise Server for SAP Applications 上の Azure VM での SAP NetWeaver の高可用性
Azure VM 上の SAP HANA の高可用性を確保し、ディザスターリカバリーを計画する方法を確認するには、「Azure Virtual Machines 上の SAP HANA の高可用性」を参照してください。

次の方法で共有

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

概要

SBD デバイスを使用する

Azure フェンスエージェントを使用する

SBD と iSCSI ターゲットサーバー

iSCSI ターゲットサーバーをセットアップする

iSCSI ターゲットサーバーに iSCSI デバイスを作成する

iSCSI ターゲットサーバーの SBD デバイスをセットアップする

SBD と Azure 共有ディスク

PowerShell を使用して Azure 共有ディスクを作成および接続する

Azure 共有ディスクの SBD デバイスをセットアップする

Azure フェンスエージェントを使用する

Azure フェンスエージェントデバイスを作成する

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

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

クラスターをインストールする

Pacemaker クラスターにフェンスデバイスを作成する

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

概要

SBD デバイスを使用する

Azure フェンス エージェントを使用する

SBD と iSCSI ターゲット サーバー

iSCSI ターゲット サーバーをセットアップする

iSCSI ターゲット サーバーに iSCSI デバイスを作成する

iSCSI ターゲット サーバーの SBD デバイスをセットアップする

SBD と Azure 共有ディスク

PowerShell を使用して Azure 共有ディスクを作成および接続する

Azure 共有ディスクの SBD デバイスをセットアップする

Azure フェンス エージェントを使用する

Azure フェンス エージェント デバイスを作成する

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

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

クラスターをインストールする

Pacemaker クラスターにフェンス デバイスを作成する

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

次のステップ

フィードバック

その他のリソース

Azure フェンスエージェントを使用する

SBD と iSCSI ターゲットサーバー

iSCSI ターゲットサーバーをセットアップする

iSCSI ターゲットサーバーに iSCSI デバイスを作成する

iSCSI ターゲットサーバーの SBD デバイスをセットアップする

Azure フェンスエージェントを使用する

Azure フェンスエージェントデバイスを作成する

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

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

Pacemaker クラスターにフェンスデバイスを作成する