Menyiapkan Pacemaker di Red Hat Enterprise Linux di Azure

Artikel
07/25/2024

Artikel ini menjelaskan cara mengonfigurasi kluster Pacemaker dasar di Red Hat Enterprise Server (RHEL). Instruksinya mencakup RHEL 7, RHEL 8, dan RHEL 9.

Prasyarat

Baca Catatan dan artikel SAP berikut terlebih dahulu:

Dokumentasi RHEL High Availability (HA)
- Mengonfigurasi dan mengelola kluster ketersediaan tinggi.
- Kebijakan Dukungan untuk Kluster Ketersediaan Tinggi RHEL - sbd dan fence_sbd.
- Kebijakan Dukungan untuk kluster Ketersediaan Tinggi RHEL - fence_azure_arm.
- Batasan Yang Diketahui Watchdog yang Ditiru Perangkat Lunak.
- Menjelajahi Komponen Ketersediaan Tinggi RHEL - sbd dan fence_sbd.
- Panduan Desain untuk Kluster Ketersediaan Tinggi RHEL - Pertimbangan sbd.
- Pertimbangan dalam mengadopsi RHEL 8 - Ketersediaan Tinggi dan Kluster
Dokumentasi RHEL khusus Azure
- Kebijakan Dukungan untuk Kluster Ketersediaan Tinggi RHEL - Microsoft Azure Virtual Machines sebagai Anggota Kluster.
- Panduan Desain untuk Kluster Ketersediaan Tinggi RHEL - Microsoft Azure Virtual Machines sebagai Anggota Kluster.
Dokumentasi RHEL untuk penawaran SAP

Gambaran Umum

Penting

Kluster pacemaker yang mencakup beberapa jaringan Virtual (VNet)/subnet tidak tercakup oleh kebijakan dukungan standar.

Ada dua opsi yang tersedia di Azure untuk mengonfigurasi pagar dalam kluster pacu jantung untuk RHEL: Agen pagar Azure, yang memulai ulang simpul yang gagal melalui API Azure, atau Anda dapat menggunakan perangkat SBD.

Penting

Di Azure, kluster ketersediaan tinggi RHEL dengan pagar berbasis penyimpanan (fence_sbd) menggunakan pengawas yang ditiru perangkat lunak. Penting untuk meninjau Batasan dan Kebijakan Dukungan Watchdog yang Ditiru Perangkat Lunak untuk Kluster Ketersediaan Tinggi RHEL - sbd dan fence_sbd saat memilih SBD sebagai mekanisme pagar.

Menggunakan perangkat SBD

Catatan

Mekanisme pagar dengan SBD didukung pada RHEL 8.8 dan yang lebih tinggi, dan RHEL 9.0 dan yang lebih tinggi.

Anda dapat mengonfigurasi perangkat SBD dengan menggunakan salah satu dari dua opsi:

SBD dengan server target iSCSI

Perangkat SBD memerlukan setidaknya satu komputer virtual (VM) tambahan yang bertindak sebagai server target Internet Small Compute System Interface (iSCSI) dan menyediakan perangkat SBD. Namun, server target iSCSI ini dapat dibagikan dengan kluster pacemaker lainnya. Keuntungan menggunakan perangkat SBD adalah bahwa jika Anda sudah menggunakan perangkat SBD lokal, perangkat tersebut tidak memerlukan perubahan apa pun pada cara Anda mengoperasikan kluster pacemaker.

Anda dapat menggunakan hingga tiga perangkat SBD untuk kluster pacu jantung untuk memungkinkan perangkat SBD menjadi tidak tersedia (misalnya, selama patching OS server target iSCSI). Jika Anda ingin menggunakan lebih dari satu perangkat SBD per pacu jantung, pastikan untuk menyebarkan beberapa server target iSCSI dan menyambungkan satu SBD dari setiap server target iSCSI. Sebaiknya gunakan satu atau tiga perangkat SBD. Pacemaker tidak dapat secara otomatis memagari node kluster jika hanya dua perangkat SBD yang dikonfigurasi dan satu perangkat tidak tersedia. Jika Anda ingin dapat memagari ketika satu server target iSCSI mati, Anda harus menggunakan tiga perangkat SBD dan oleh karena itu tiga server target iSCSI. Itu adalah konfigurasi yang paling tangguh saat Anda menggunakan SBD.

Penting

Saat Anda berencana untuk menyebarkan dan mengonfigurasi simpul kluster pacemaker Linux dan perangkat SBD, jangan izinkan perutean antara komputer virtual Anda dan VM yang menghosting perangkat SBD untuk melewati perangkat lain, seperti appliance virtual jaringan (NVA).

Masalah dan kejadian pemeliharaan dengan NVA dapat berdampak negatif pada stabilitas dan keandalan konfigurasi kluster secara keseluruhan. Untuk informasi selengkapnya, lihat aturan perutean yang ditentukan pengguna.
SBD dengan disk bersama Azure

Untuk mengonfigurasi perangkat SBD, Anda perlu melampirkan setidaknya satu disk bersama Azure ke semua komputer virtual yang merupakan bagian dari kluster pacemaker. Keuntungan perangkat SBD menggunakan disk bersama Azure adalah Anda tidak perlu menyebarkan dan mengonfigurasi komputer virtual tambahan.

Berikut adalah beberapa pertimbangan penting tentang perangkat SBD saat mengonfigurasi menggunakan Disk Bersama Azure:
- Disk bersama Azure dengan SSD Premium didukung sebagai perangkat SBD.
- Perangkat SBD yang menggunakan disk bersama Azure didukung pada RHEL 8.8 dan yang lebih baru.
- Perangkat SBD yang menggunakan disk berbagi premium Azure didukung pada penyimpanan redundan lokal (LRS) dan penyimpanan zona redundan (ZRS).
- Bergantung pada jenis penyebaran Anda, pilih penyimpanan redundan yang sesuai untuk disk bersama Azure sebagai perangkat SBD Anda.
- Perangkat SBD yang menggunakan LRS untuk disk bersama premium Azure (skuName - Premium_LRS) hanya didukung dengan penyebaran regional seperti set ketersediaan.
- Perangkat SBD yang menggunakan ZRS untuk disk bersama premium Azure (skuName - Premium_ZRS) direkomendasikan dengan penyebaran zona seperti zona ketersediaan, atau set skala dengan FD=1.
- ZRS untuk disk terkelola saat ini tersedia di wilayah yang tercantum dalam dokumen ketersediaan regional.
- Disk bersama Azure yang Anda gunakan untuk perangkat SBD tidak perlu besar. Nilai maxShares disk bersama Azure menentukan berapa banyak simpul kluster yang dapat menggunakan disk bersama. Misalnya, Anda dapat menggunakan ukuran disk P1 atau P2 untuk perangkat SBD Anda pada kluster dua simpul seperti SAP ASCS/ERS atau SAP Hana scale-up.
- Untuk peluasan skala HANA dengan replikasi sistem HANA (HSR) dan alat pacu jantung, Anda dapat menggunakan disk bersama Azure untuk perangkat SBD dalam kluster dengan hingga lima simpul per situs replikasi karena batas maxShares saat ini.
- Kami tidak menyarankan untuk melampirkan perangkat SBD disk bersama Azure di seluruh kluster pacemaker.
- Jika Anda menggunakan beberapa perangkat SBD disk bersama Azure, periksa batas jumlah maksimum disk data yang dapat dilampirkan ke VM.
- Untuk informasi selengkapnya tentang batasan untuk disk bersama Azure, tinjau dengan cermat bagian "Batasan" dari dokumentasi disk bersama Azure.

Menggunakan agen pagar Azure

Anda dapat mengatur STONITH dengan menggunakan agen pagar Azure. Agen pagar Azure memerlukan identitas terkelola untuk VM kluster atau perwakilan layanan atau identitas sistem terkelola (MSI) yang berhasil memulai ulang node yang gagal melalui API Azure. Agen pagar Azure tidak memerlukan penyebaran mesin virtual tambahan.

SBD dengan server target iSCSI:

Untuk menggunakan perangkat SBD yang menggunakan server target iSCSI untuk pagar, ikuti petunjuk di bagian berikutnya.

Menyiapkan server target iSCSI

Pertama-tama Anda perlu membuat komputer virtual target iSCSI. Anda dapat berbagi server target iSCSI dengan beberapa kluster pacemaker.

Sebarkan komputer virtual yang berjalan pada versi RHEL OS yang didukung, dan sambungkan melalui SSH. VM tidak harus berukuran besar. Ukuran VM seperti Standard_E2s_v3 atau Standard_D2s_v3 sudah cukup. Pastikan untuk menggunakan penyimpanan Premium untuk disk OS.
Tidak perlu menggunakan RHEL untuk SAP dengan HA dan Update Services, atau RHEL untuk gambar OS Aplikasi SAP untuk server target iSCSI. Gambar RHEL OS standar dapat digunakan sebagai gantinya. Namun, perlu diketahui bahwa siklus hidup dukungan bervariasi di antara rilis produk OS yang berbeda.
Jalankan perintah berikut pada semua komputer virtual target iSCSI.
1. Perbarui RHEL.
```
sudo yum -y update
```
  Catatan
  
  Anda mungkin perlu me-reboot simpul setelah meningkatkan atau memperbarui OS.
2. Instal paket target iSCSI.
```
sudo yum install targetcli
```
3. Mulai dan konfigurasikan target untuk memulai pada waktu boot.
```
sudo systemctl start target
sudo systemctl enable target
```
4. Buka port 3260 di firewall
```
sudo firewall-cmd --add-port=3260/tcp --permanent
sudo firewall-cmd --add-port=3260/tcp
```

Membuat perangkat iSCSI di server target iSCSI

Untuk membuat disk iSCSI untuk kluster sistem SAP Anda, jalankan perintah berikut pada setiap komputer virtual target iSCSI. Contoh ini menggambarkan pembuatan Perangkat SBD untuk beberapa kluster, menunjukkan penggunaan satu server target iSCSI untuk beberapa kluster. Perangkat SBD dikonfigurasi pada disk OS, jadi pastikan ada cukup ruang.

ascsnw1: Mewakili kluster ASCS/ERS NW1.
dbhn1: Mewakili kluster database HN1.
sap-cl1 dan sap-cl2: Nama host dari node kluster NW1 ASCS/ERS.
hn1-db-0 dan hn1-db-1: Nama host dari node kluster database.

Dalam instruksi berikut, ubah perintah dengan nama host dan SID spesifik Anda sesuai kebutuhan.

Buat folder root untuk semua perangkat SBD.
```
sudo mkdir /sbd
```

Buat perangkat SBD untuk server ASCS/ERS sistem NW1.

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.sap-cl1.local:sap-cl1
sudo targetcli iscsi/iqn.2006-04.ascsnw1.local:ascsnw1/tpg1/acls/ create iqn.2006-04.sap-cl2.local:sap-cl2

Buat perangkat SBD untuk kluster database sistem HN1.

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

Simpan konfigurasi targetcli.
```
sudo targetcli saveconfig
```

Periksa untuk memastikan bahwa semuanya disiapkan dengan benar

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- sbddbhn1 ................................................................... [/sbd/sbddbhn1 (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.dbhn1.local:dbhn1 ..................................................................................... [TPGs: 1]
  | | o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
  | |   o- acls .......................................................................................................... [ACLs: 2]
  | |   | o- iqn.2006-04.hn1-db-0.local:hn1-db-0 .................................................................. [Mapped LUNs: 1]
  | |   | | o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   | o- iqn.2006-04.hn1-db-1.local:hn1-db-1 .................................................................. [Mapped LUNs: 1]
  | |   |   o- mapped_lun0 ............................................................................... [lun0 fileio/sbdhdb (rw)]
  | |   o- luns .......................................................................................................... [LUNs: 1]
  | |   | o- lun0 ............................................................. [fileio/sbddbhn1 (/sbd/sbddbhn1) (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/sbdascsers (rw)]
  |     | o- iqn.2006-04.sap-cl2.local:sap-cl2 .................................................................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................................................... [lun0 fileio/sbdascsers (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]

Menyiapkan perangkat SBD server target iSCSI

[A]: Berlaku untuk semua simpul. [1]: Berlaku hanya untuk node 1. [2]: Berlaku hanya untuk node 2.

Pada node kluster, sambungkan dan temukan perangkat iSCSI yang dibuat di bagian sebelumnya. Jalankan perintah berikut pada simpul kluster baru yang ingin Anda buat.

[A] Instal atau perbarui utils inisiator iSCSI pada semua node kluster.
```
sudo yum install -y iscsi-initiator-utils
```

[A] Instal paket kluster dan SBD pada semua node kluster.

sudo yum install -y pcs pacemaker sbd fence-agents-sbd

[A] Aktifkan layanan iSCSI.
```
sudo systemctl enable iscsid iscsi
```

[1] Ubah nama inisiator pada node pertama kluster.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl1.local:sap-cl1

[2] Ubah nama inisiator pada node kedua kluster.

sudo vi /etc/iscsi/initiatorname.iscsi

# Change the content of the file to match the access control ists (ACLs) you used when you created the iSCSI device on the iSCSI target server (for example, for the ASCS/ERS servers)
InitiatorName=iqn.2006-04.sap-cl2.local:sap-cl2

[A] Mulai ulang layanan iSCSI untuk menerapkan perubahan.

sudo systemctl restart iscsid 
sudo systemctl restart iscsi

[A]Hubungkan perangkat iSCSI. Dalam contoh di bawah ini, 10.0.0.17 adalah alamat IP dari server target iSCSI dan 3260 adalah port default. Nama iqn.2006-04.ascsnw1.local:ascsnw1 target dicantumkan saat Anda menjalankan perintah iscsiadm -m discoverypertama .

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

[A] Jika Anda menggunakan beberapa perangkat SBD, sambungkan juga ke server target iSCSI kedua.

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

[A] Jika Anda menggunakan beberapa perangkat SBD, sambungkan juga ke server target iSCSI ketiga.

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

[A] Pastikan perangkat iSCSI tersedia dan catat nama perangkat. Dalam contoh berikut, tiga perangkat iSCSI ditemukan dengan menghubungkan simpul ke tiga server target iSCSI.

lsscsi

[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sde
[1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
[1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdb
[1:0:0:2]    disk    Msft     Virtual Disk     1.0   /dev/sdc
[1:0:0:3]    disk    Msft     Virtual Disk     1.0   /dev/sdd
[2:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdf
[3:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdh
[4:0:0:0]    disk    LIO-ORG  sbdascsnw1       4.0   /dev/sdg

[A] Ambil ID perangkat iSCSI.

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -> ../../sdf
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_85d254ed-78e2-4ec4-8b0d-ecac2843e086 -> ../../sdf

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d -> ../../sdh
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_87122bfc-8a0b-4006-b538-d0a6d6821f04 -> ../../sdh

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

# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-1LIO-ORG_sbdhdb:d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 -> ../../sdg
# lrwxrwxrwx 1 root root  9 Jul 15 20:21 /dev/disk/by-id/scsi-SLIO-ORG_sbdhdb_d2ddc548-060c-49e7-bb79-2bb653f0f34a -> ../../sdg

Perintah ini mencantumkan tiga ID perangkat untuk tiap perangkat SBD. Sebaiknya gunakan ID yang dimulai dengan scsi-3. Dalam contoh sebelumnya, IDnya adalah:

/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2
/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d
/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65

[1] Buat perangkat SBD.

Gunakan ID perangkat dari perangkat iSCSI untuk membuat perangkat SBD baru pada simpul kluster pertama.
```
sudo sbd -d /dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2 -1 60 -4 120 create
```

Buat juga perangkat SBD kedua dan ketiga jika Anda ingin menggunakan lebih dari satu.

sudo sbd -d /dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d -1 60 -4 120 create
sudo sbd -d /dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 -1 60 -4 120 create

[A] Sesuaikan konfigurasi SBD

Buka file konfigurasi SBD.
```
sudo vi /etc/sysconfig/sbd
```

Ubah properti perangkat SBD, aktifkan integrasi pacemaker, dan ubah mode mulai SBD.

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2;/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d;/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

[A] Jalankan perintah berikut untuk memuat softdog modul.
```
modprobe softdog
```
[A] Jalankan perintah berikut untuk memastikan softdog dimuat secara otomatis setelah reboot simpul.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[A] Nilai batas waktu layanan SBD diatur ke 90 d secara default. Namun, jika SBD_DELAY_START nilai diatur ke yes, layanan SBD akan menunda mulainya hingga setelah batas msgwait waktu. Oleh karena itu, nilai batas waktu layanan SBD harus melebihi msgwait batas waktu saat SBD_DELAY_START diaktifkan.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s
```

SBD dengan disk bersama Azure

Bagian ini hanya berlaku jika Anda ingin menggunakan Perangkat SBD dengan disk bersama Azure.

Mengonfigurasi disk bersama Azure dengan PowerShell

Untuk membuat dan melampirkan disk bersama Azure dengan PowerShell, jalankan instruksi berikut. Jika Anda ingin menyebarkan sumber daya dengan menggunakan Azure CLI atau portal Azure, Anda juga dapat merujuk ke Menyebarkan disk ZRS.

$ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"
$DiskSizeInGB = 4
$DiskName = "SBD-disk1"
$ShareNodes = 2
$LRSSkuName = "Premium_LRS"
$ZRSSkuName = "Premium_ZRS"  
$vmNames = @("prod-cl1-0", "prod-cl1-1")  # VMs to attach the disk

# ZRS Azure shared disk: Configure an Azure shared disk with ZRS for a premium shared disk
$zrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $ZRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$zrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $zrsDiskConfig

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

# LRS Azure shared disk: Configure an Azure shared disk with LRS for a premium shared disk
$lrsDiskConfig = New-AzDiskConfig -Location $Location -SkuName $LRSSkuName -CreateOption Empty -DiskSizeGB $DiskSizeInGB -MaxSharesCount $ShareNodes
$lrsDataDisk = New-AzDisk -ResourceGroupName $ResourceGroup -DiskName $DiskName -Disk $lrsDiskConfig

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

Menyiapkan perangkat SBD disk bersama Azure

[A] Instal paket kluster dan SBD pada semua node kluster.

sudo yum install -y pcs pacemaker sbd fence-agents-sbd

[A] Pastikan disk yang terpasang tersedia.

lsblk

# NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda                 8:0    0    4G  0 disk
# sdb                 8:16   0   64G  0 disk
# ├─sdb1              8:17   0  500M  0 part /boot
# ├─sdb2              8:18   0   63G  0 part
# │ ├─rootvg-tmplv  253:0    0    2G  0 lvm  /tmp
# │ ├─rootvg-usrlv  253:1    0   10G  0 lvm  /usr
# │ ├─rootvg-homelv 253:2    0    1G  0 lvm  /home
# │ ├─rootvg-varlv  253:3    0    8G  0 lvm  /var
# │ └─rootvg-rootlv 253:4    0    2G  0 lvm  /
# ├─sdb14             8:30   0    4M  0 part
# └─sdb15             8:31   0  495M  0 part /boot/efi
# sr0                11:0    1 1024M  0 rom

lsscsi

# [0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb
# [0:0:0:2]    cd/dvd  Msft     Virtual DVD-ROM  1.0   /dev/sr0
# [1:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda
# [1:0:0:1]    disk    Msft     Virtual Disk     1.0   /dev/sdc

[A] Ambil ID perangkat dari disk bersama yang terpasang.

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

# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-14d534654202020200792c2f5cc7ef14b8a7355cb3cef0107 -> ../../sda
# lrwxrwxrwx 1 root root  9 Jul 15 22:24 /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -> ../../sda

ID perangkat daftar perintah untuk disk bersama yang terpasang. Sebaiknya gunakan ID yang dimulai dengan scsi-3. Dalam contoh ini, ID adalah /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107.

[1] Buat perangkat SBD

# Use the device ID from step 3 to create the new SBD device on the first cluster node
sudo sbd -d /dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107 -1 60 -4 120 create

[A] Sesuaikan konfigurasi SBD

Buka file konfigurasi SBD.
```
sudo vi /etc/sysconfig/sbd
```

Ubah properti perangkat SBD, aktifkan integrasi pacu jantung, dan ubah mode mulai SBD

[...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224800792c2f5cc7e55cb3cef0107"
[...]
SBD_PACEMAKER=yes
[...]
SBD_STARTMODE=always
[...]
SBD_DELAY_START=yes
[...]

[A] Jalankan perintah berikut untuk memuat softdog modul.
```
modprobe softdog
```
[A] Jalankan perintah berikut untuk memastikan softdog dimuat secara otomatis setelah reboot simpul.
```
echo softdog > /etc/modules-load.d/watchdog.conf
systemctl restart systemd-modules-load
```
[A] Nilai batas waktu layanan SBD diatur ke 90 detik secara default. Namun, jika SBD_DELAY_START nilai diatur ke yes, layanan SBD akan menunda mulainya hingga setelah batas msgwait waktu. Oleh karena itu, nilai batas waktu layanan SBD harus melebihi msgwait batas waktu saat SBD_DELAY_START diaktifkan.
```
sudo mkdir /etc/systemd/system/sbd.service.d
echo -e "[Service]\nTimeoutSec=144" | sudo tee /etc/systemd/system/sbd.service.d/sbd_delay_start.conf
sudo systemctl daemon-reload

systemctl show sbd | grep -i timeout
# TimeoutStartUSec=2min 24s
# TimeoutStopUSec=2min 24s
```

Konfigurasi agen pagar Azure

Perangkat anggar menggunakan identitas terkelola untuk sumber daya Azure atau perwakilan layanan untuk mengotorisasi terhadap Azure. Bergantung pada metode manajemen identitas, ikuti prosedur yang sesuai -

Mengonfigurasi manajemen identitas

Gunakan identitas terkelola atau perwakilan layanan.
- Identitas terkelola
- Prinsipal layanan
Untuk membuat identitas terkelola (MSI), buat identitas terkelola yang ditetapkan sistem untuk setiap mesin virtual di kluster. Jika identitas terkelola yang ditetapkan sistem sudah ada, identitas tersebut akan digunakan. Jangan gunakan identitas terkelola yang ditetapkan pengguna dengan Pacemaker saat ini. Perangkat pagar, berdasarkan identitas terkelola, didukung pada RHEL 7.9 dan RHEL 8.x/RHEL 9.x.
Ikuti langkah-langkah ini untuk membuat perwakilan layanan, jika Anda tidak menggunakan identitas terkelola.
1. Buka portal Microsoft Azure.
2. Buka panel ID Microsoft Entra.
3. Buka Properti dan catat ID Direktori. Ini adalah ID penyewa.
4. Pilih Pendaftaran aplikasi.
5. Pilih Pendaftaran Baru.
6. Masukkan Nama dan pilih Akun di direktori organisasi ini saja.
7. Pilih Jenis Aplikasi sebagai Web, masukkan URL masuk (misalnya, http://localhost), dan pilih Tambahkan. URL masuk tidak digunakan dan dapat berupa URL yang valid.
8. Pilih Sertifikat dan Rahasia, lalu pilih Rahasia klien baru.
9. Masukkan deskripsi untuk kunci baru, pilih Dua tahun, dan pilih Tambahkan.
10. Catat Nilai. Ini digunakan sebagai kata sandi untuk perwakilan layanan.
11. Pilih Ikhtisar. Catat ID Aplikasi. Ini digunakan sebagai nama pengguna (ID masuk dalam langkah-langkah berikut) dari perwakilan layanan.
Membuat peran kustom untuk agen anggar

Identitas terkelola dan perwakilan layanan tidak memiliki izin untuk mengakses sumber daya Azure Anda secara default. Anda perlu memberikan izin identitas terkelola atau perwakilan layanan untuk memulai dan menghentikan (mematikan) semua VM kluster. Jika Anda belum membuat peran kustom, Anda dapat membuatnya dengan menggunakan PowerShell atau Azure CLI.

Gunakan konten berikut untuk file input. Anda perlu menyesuaikan konten dengan langganan Anda, yaitu, mengganti xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx dan yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy dengan ID langganan Anda. Jika Anda hanya memiliki satu langganan, hapus entri kedua di AssignableScopes.
```
{
      "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": []
}
```
Menetapkan peran kustom

Gunakan identitas terkelola atau perwakilan layanan.
- Identitas terkelola
- Prinsipal layanan
Tetapkan peran Linux Fence Agent Role kustom yang dibuat di bagian terakhir untuk setiap identitas terkelola VM kluster. Setiap identitas terkelola yang ditetapkan sistem mesin virtual memerlukan peran yang ditetapkan untuk setiap sumber daya mesin virtual kluster. Untuk informasi lebih lanjut, lihat Menetapkan akses ke identitas terkelola untuk mengakses sumber daya menggunakan portal Azure. Verifikasi bahwa setiap penetapan peran identitas terkelola VM berisi semua VM kluster.

Penting

Ketahuilah bahwa penugasan dan penghapusan otorisasi dengan identitas terkelola dapat ditunda hingga efektif.

Tetapkan peran Linux Fence Agent Role kustom yang dibuat di bagian terakhir ke perwakilan layanan. Jangan gunakan peran Pemilik lagi. Untuk informasi selengkapnya, lihat Menetapkan peran Azure menggunakan portal Microsoft Azure.

Pastikan untuk menetapkan peran bagi kedua node kluster.

Penginstalan kluster

Perbedaan dalam perintah atau konfigurasi antara RHEL 7 dan RHEL 8/RHEL 9 ditandai dalam dokumen.

[A] Pasang add-on RHEL HA.

sudo yum install -y pcs pacemaker nmap-ncat

[A] Pada RHEL 9.x, instal agen sumber daya untuk penyebaran cloud.
```
sudo yum install -y resource-agents-cloud
```
[A] Pasang paket agen pagar jika Anda menggunakan perangkat pagar berdasarkan agen pagar Azure.
```
sudo yum install -y fence-agents-azure-arm 
```
Penting

Kami merekomendasikan versi agen pagar Azure berikut (atau yang lebih baru) untuk pelanggan yang ingin menggunakan identitas terkelola untuk sumber daya Azure alih-alih nama perwakilan layanan untuk agen pagar:
- RHEL 8.4: agen pagar-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.
Penting

Pada RHEL 9, kami merekomendasikan versi paket berikut (atau yang lebih baru) untuk menghindari masalah dengan agen pagar Azure:
- agen pagar-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
Periksa versi agen pagar Azure. Jika perlu, perbarui ke versi minimum yang diperlukan atau yang lebih baru.
```
# Check the version of the Azure Fence Agent
sudo yum info fence-agents-azure-arm
```
Penting

Jika Anda perlu memperbarui agen pagar Azure, dan jika Anda menggunakan peran kustom, pastikan untuk memperbarui peran kustom untuk menyertakan powerOff tindakan. Untuk informasi selengkapnya, lihat Membuat peran kustom untuk agen pagar.
[A] Siapkan resolusi nama host.

Anda bisa menggunakan server DNS atau mengubah /etc/hosts file pada semua simpul. Contoh ini memperlihatkan cara menggunakan file /etc/hosts. Ganti alamat IP dan nama host dalam perintah berikut.

Penting

Jika Anda menggunakan nama host dalam konfigurasi kluster, sangat penting untuk memiliki resolusi nama host yang andal. Komunikasi kluster gagal jika nama tidak tersedia, yang dapat menyebabkan penundaan failover kluster.

Manfaat penggunaannya /etc/hosts adalah kluster Anda menjadi independen dari DNS, yang bisa menjadi satu titik kegagalan juga.
```
sudo vi /etc/hosts
```
Sisipkan baris berikut ke /etc/hosts. Ubah alamat IP dan nama host agar sesuai dengan lingkungan Anda.
```
# 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
```
[A] Ubah hacluster kata sandi ke kata sandi yang sama.
```
sudo passwd hacluster
```
[A] Tambahkan aturan firewall untuk Pacemaker.

Tambahkan aturan firewall berikut ke semua komunikasi kluster antara node kluster.
```
sudo firewall-cmd --add-service=high-availability --permanent
sudo firewall-cmd --add-service=high-availability
```
[A] Aktifkan layanan kluster dasar.

Jalankan perintah berikut untuk mengaktifkan layanan Pacemaker dan memulainya.
```
sudo systemctl start pcsd.service
sudo systemctl enable pcsd.service
```

[1] Buat kluster Pacemaker.

Jalankan perintah berikut untuk mengautentikasi node dan membuat kluster. Atur token ke 30000 untuk memungkinkan pemeliharaan yang mempertahankan memori. Untuk informasi selengkapnya, lihat artikel untuk Linux ini.

Jika Anda membangun kluster di RHEL 7.x, gunakan perintah berikut:

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

Jika Anda membangun kluster di RHEL 8.x/RHEL 9.x, gunakan perintah berikut:

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

Verifikasi status kluster dengan menjalankan perintah berikut:

# 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

[A] Tetapkan suara yang diharapkan.

# 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

Tip

Jika Anda membangun kluster multinode, yaitu kluster dengan lebih dari dua node, jangan atur suara ke 2.

[1] Izinkan tindakan pagar bersamaan.

sudo pcs property set concurrent-fencing=true

Membuat perangkat STONITH di kluster Pacemaker

Tip

Untuk menghindari perlombaan pagar dalam kluster pacemaker dua node, Anda dapat mengonfigurasi priority-fencing-delay properti kluster. Properti ini memperkenalkan penundaan tambahan dalam pemagaran simpul yang memiliki prioritas total sumber daya yang lebih tinggi ketika skenario split-brain terjadi. Untuk informasi selengkapnya, lihat Dapatkah Pacemaker memagari node kluster dengan sumber daya terkecil yang berjalan?.
Properti priority-fencing-delay ini berlaku untuk Pacemaker versi 2.0.4-6.el8 atau lebih tinggi dan pada kluster dua node. Jika Anda mengonfigurasi priority-fencing-delay properti kluster, Anda tidak perlu mengatur pcmk_delay_max properti . Tetapi jika versi Pacemaker kurang dari 2.0.4-6.el8, Anda perlu mengatur pcmk_delay_max properti .
Untuk instruksi tentang cara mengatur priority-fencing-delay properti kluster, lihat masing-masing dokumen SAP ASCS/ERS dan SAP Hana scale-up HA.

Berdasarkan mekanisme anggar yang dipilih, ikuti hanya satu bagian untuk instruksi yang relevan: SBD sebagai perangkat anggar atau agen pagar Azure sebagai perangkat anggar.

SBD sebagai perangkat anggar

[A] Aktifkan layanan SBD
```
sudo systemctl enable sbd
```

[1] Untuk perangkat SBD yang dikonfigurasi menggunakan server target iSCSI atau disk bersama Azure, jalankan perintah berikut.

sudo pcs property set stonith-timeout=144
sudo pcs property set stonith-enabled=true

# Replace the device IDs with your device ID. 
pcs stonith create sbd fence_sbd \
devices=/dev/disk/by-id/scsi-3600140585d254ed78e24ec48b0decac2,/dev/disk/by-id/scsi-3600140587122bfc8a0b4006b538d0a6d,/dev/disk/by-id/scsi-36001405d2ddc548060c49e7bb792bb65 \
op monitor interval=600 timeout=15

[1] Hidupkan ulang kluster
```
sudo pcs cluster stop --all

# It would take time to start the cluster as "SBD_DELAY_START" is set to "yes"
sudo pcs cluster start --all
```
Catatan

Jika Anda mengalami kesalahan berikut saat memulai kluster pacemaker, Anda dapat mengabaikan pesan. Atau, Anda dapat memulai kluster menggunakan perintah pcs cluster start --all --request-timeout 140.

Kesalahan: tidak dapat memulai semua node node1/node2: Tidak dapat terhubung ke node1/node2, periksa apakah pcsd berjalan di sana atau coba atur batas waktu yang lebih tinggi dengan --request-timeout opsi (Waktu operasi habis setelah 60000 milidetik dengan 0 byte diterima)

Agen pagar Azure sebagai perangkat anggar

[1] Setelah menetapkan peran ke kedua node kluster, Anda dapat mengonfigurasi perangkat anggar di kluster.
```
sudo pcs property set stonith-timeout=900
sudo pcs property set stonith-enabled=true
```

[1] Jalankan perintah yang sesuai tergantung pada apakah Anda menggunakan identitas terkelola atau perwakilan layanan untuk agen pagar Azure.

Catatan

Opsi pcmk_host_map ini hanya diperlukan dalam perintah jika nama host RHEL dan nama Azure VM tidak identik. Tentukan pemetaan dalam format nama host:vm-name.

Lihat bagian yang ditebalkan dalam perintah. Untuk informasi selengkapnya, lihat Format apa yang harus saya gunakan untuk menentukan pemetaan simpul ke perangkat anggar di pcmk_host_map?.

Identitas terkelola
Prinsipal layanan

Untuk RHEL 7.x, gunakan perintah berikut untuk mengonfigurasi perangkat pagar:

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

Untuk RHEL 8.x/9.x, gunakan perintah berikut untuk mengonfigurasi perangkat pagar:

# 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

Untuk RHEL 7.x, gunakan perintah berikut untuk mengonfigurasi perangkat pagar:

sudo pcs stonith create rsc_st_azure fence_azure_arm login="login ID" passwd="password" \
resourceGroup="resource group" tenantId="tenant ID" 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

Untuk RHEL 8.x/9.x, gunakan perintah berikut untuk mengonfigurasi perangkat pagar:

# 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 username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" 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 username="login ID" password="password" \
resourceGroup="resource group" tenantId="tenant ID" 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

Jika Anda menggunakan perangkat anggar berdasarkan konfigurasi perwakilan layanan, baca Mengubah dari SPN ke MSI untuk kluster Pacemaker dengan menggunakan anggar Azure dan pelajari cara mengonversi ke konfigurasi identitas terkelola.

Operasi pemantauan dan pemagaran tidak dibuat berurutan. Akibatnya, jika ada operasi pemantauan yang berjalan lebih lama dan peristiwa anggar simultan, tidak ada penundaan pada failover kluster karena operasi pemantauan sudah berjalan.

Tip

Agen pagar Azure memerlukan konektivitas keluar ke titik akhir publik. Untuk informasi selengkapnya bersama dengan solusi yang mungkin, lihat Konektivitas titik akhir publik untuk VM menggunakan ILB standar.

Mengonfigurasi Pacemaker untuk acara terjadwal Azure

Azure menawarkan kejadian terjadwal. Peristiwa terjadwal dikirim melalui layanan metadata dan memungkinkan waktu bagi aplikasi untuk mempersiapkan peristiwa tersebut.

Agen azure-events-az sumber daya Pacemaker memantau peristiwa Azure terjadwal. Jika peristiwa terdeteksi dan agen sumber daya menentukan bahwa simpul kluster lain tersedia, peristiwa tersebut mengatur atribut kesehatan kluster.

Ketika atribut kesehatan kluster diatur untuk simpul, batasan lokasi memicu dan semua sumber daya dengan nama yang tidak dimulai health- dimigrasikan jauh dari simpul dengan peristiwa terjadwal. Setelah node kluster yang terpengaruh bebas dari menjalankan sumber daya kluster, peristiwa terjadwal diakui dan dapat menjalankan tindakannya, seperti mulai ulang.

[A] Pastikan bahwa paket untuk azure-events-az agen sudah diinstal dan diperbarui.
```
RHEL 8.x: sudo dnf info resource-agents
RHEL 9.x: sudo dnf info resource-agents-cloud
```
Persyaratan versi minimum:
- 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 dan yang lebih baru: resource-agents-cloud-4.10.0-34.1

[1] Konfigurasikan sumber daya di Pacemaker.

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

[1] Atur strategi dan batasan node kesehatan kluster Pacemaker.
```
sudo pcs property set node-health-strategy=custom

sudo pcs constraint location 'regexp%!health-.*' \
rule score-attribute='#health-azure' \
defined '#uname'
```
Penting

Jangan tentukan sumber daya lain dalam kluster yang dimulai dengan health- selain sumber daya yang dijelaskan di langkah berikutnya.

[1] Tetapkan nilai awal atribut kluster. Jalankan untuk setiap node kluster dan untuk lingkungan peluasan skala termasuk VM pembuat mayoritas.

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] Konfigurasikan sumber daya di Pacemaker. Pastikan sumber daya dimulai dengan health-azure.

sudo pcs resource create health-azure-events \
ocf:heartbeat:azure-events-az \
op monitor interval=10s timeout=240s \
op start timeout=10s start-delay=90s

sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true failure-timeout=120s

Keluarkan kluster Pacemaker dari mode pemeliharaan.
```
sudo pcs property set maintenance-mode=false
```
Hapus kesalahan apa pun selama pengaktifan dan verifikasi bahwa health-azure-events sumber daya telah berhasil dimulai pada semua node kluster.
```
sudo pcs resource cleanup
```
Eksekusi kueri pertama kali untuk peristiwa terjadwal dapat memakan waktu hingga dua menit. Pengujian pacemaker dengan peristiwa terjadwal dapat menggunakan tindakan reboot atau penyebaran ulang untuk VM kluster. Untuk informasi selengkapnya, lihat Peristiwa terjadwal.

Konfigurasi pagar opsional

Tip

Bagian ini hanya berlaku jika Anda ingin mengonfigurasi perangkat fence_kdumppagar khusus .

Jika Anda perlu mengumpulkan informasi diagnostik dalam VM, mungkin berguna untuk mengonfigurasi perangkat pagar lain berdasarkan agen fence_kdumppagar . Agen fence_kdump dapat mendeteksi bahwa node memasuki pemulihan crash kdump dan dapat memungkinkan layanan pemulihan crash selesai sebelum metode anggar lainnya dipanggil. Perhatikan bahwa fence_kdump bukan pengganti mekanisme pagar tradisional, seperti agen pagar SBD atau Azure, saat Anda menggunakan Azure VM.

Penting

Ketahuilah bahwa ketika fence_kdump dikonfigurasi sebagai perangkat anggar tingkat pertama, ia memperkenalkan penundaan dalam operasi pagar dan, masing-masing, keterlambatan dalam failover sumber daya aplikasi.

Jika crash dump berhasil terdeteksi, anggar tertunda hingga layanan pemulihan crash selesai. Jika simpul yang gagal tidak dapat dijangkau atau jika tidak merespons, pagar ditunda oleh waktu yang ditentukan, jumlah iterasi yang dikonfigurasi, dan fence_kdump batas waktu. Untuk informasi selengkapnya, lihat Bagaimana cara mengonfigurasi fence_kdump di kluster Red Hat Pacemaker?.

Batas waktu yang diusulkan fence_kdump mungkin perlu disesuaikan dengan lingkungan tertentu.

Kami menyarankan agar Anda mengonfigurasi fence_kdump pagar hanya jika perlu untuk mengumpulkan diagnostik dalam VM dan selalu dalam kombinasi dengan metode pagar tradisional, seperti SBD atau agen pagar Azure.

Artikel Red Hat KB berikut berisi informasi penting tentang mengonfigurasi fence_kdump pagar:

Lihat Bagaimana cara mengonfigurasi fence_kdump di kluster Red Hat Pacemaker?.
Lihat Cara mengonfigurasi/mengelola tingkat anggar dalam kluster RHEL dengan Pacemaker.
Lihat fence_kdump gagal dengan "batas waktu setelah X detik" dalam kluster RHEL 6 atau 7 HA dengan alat kexec yang lebih lama dari 2.0.14.
Untuk informasi tentang cara mengubah batas waktu default, lihat Bagaimana cara mengonfigurasi kdump untuk digunakan dengan Add-On RHEL 6, 7, 8 HA?.
Untuk informasi tentang cara mengurangi penundaan failover saat Anda menggunakan fence_kdump, lihat Dapatkah saya mengurangi penundaan failover yang diharapkan saat menambahkan konfigurasi fence_kdump?.

Jalankan langkah-langkah opsional berikut untuk ditambahkan fence_kdump sebagai konfigurasi pagar tingkat pertama, selain konfigurasi agen pagar Azure.

[A] Verifikasi bahwa kdump aktif dan dikonfigurasi.

systemctl is-active kdump
# Expected result
# active

[A] Install fence_kdump agen pagar.
```
yum install fence-agents-kdump
```

[1] Buat fence_kdump perangkat anggar di kluster.

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

[1] Konfigurasikan tingkat anggar sehingga fence_kdump mekanisme anggar dilibatkan terlebih dahulu.

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
# Replace <stonith-resource-name> to the resource name of the STONITH resource configured in your pacemaker cluster (example based on above configuration - sbd or rsc_st_azure)
pcs stonith level add 2 prod-cl1-0 <stonith-resource-name>
pcs stonith level add 2 prod-cl1-1 <stonith-resource-name>

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

[A] Izinkan port yang diperlukan untuk fence_kdump melalui firewall.

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

[A] Lakukan fence_kdump_nodes konfigurasi untuk /etc/kdump.conf menghindari fence_kdump kegagalan dengan batas waktu untuk beberapa kexec-tools versi. Untuk informasi selengkapnya, lihat fence_kdump waktu habis saat fence_kdump_nodes tidak ditentukan dengan alat kexec versi 2.0.15 atau yang lebih baru dan fence_kdump gagal dengan "batas waktu setelah X detik" di kluster KETERSEDIAAN TINGGI RHEL 6 atau 7 dengan versi alat kexec yang lebih lama dari 2.0.14. Contoh konfigurasi untuk kluster dua node disajikan di sini. Setelah Anda membuat perubahan dalam /etc/kdump.conf, gambar kdump harus diregenerasi. Untuk meregenerasi, mulai ulang kdump layanan.
```
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
```

[A] Pastikan bahwa initramfs file gambar berisi fence_kdump file dan hosts . Untuk informasi selengkapnya, lihat Bagaimana cara mengonfigurasi fence_kdump di kluster Red Hat Pacemaker?.

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

Uji konfigurasi dengan membuat crash sebuah simpul. Untuk informasi selengkapnya, lihat Bagaimana cara mengonfigurasi fence_kdump di kluster Red Hat Pacemaker?.

Penting

Jika kluster sudah dalam penggunaan produktif, rencanakan pengujian yang sesuai karena crash node berdampak pada aplikasi.
```
echo c > /proc/sysrq-trigger
```

Langkah berikutnya

Lihat Perencanaan dan implementasi Azure Virtual Machines untuk SAP.
Lihat Penyebaran Azure Virtual Machines untuk SAP.
Lihat Penyebaran DBMS Azure Virtual Machines untuk SAP.
Untuk mempelajari cara menetapkan KETERSEDIAAN TINGGI dan merencanakan pemulihan bencana SAP Hana di Azure VM, lihat Ketersediaan Tinggi SAP Hana di Azure Virtual Machines.

Bagikan melalui

Menyiapkan Pacemaker di Red Hat Enterprise Linux di Azure

Prasyarat

Gambaran Umum

Menggunakan perangkat SBD

Menggunakan agen pagar Azure

SBD dengan server target iSCSI:

Menyiapkan server target iSCSI

Membuat perangkat iSCSI di server target iSCSI

Menyiapkan perangkat SBD server target iSCSI

SBD dengan disk bersama Azure

Mengonfigurasi disk bersama Azure dengan PowerShell

Menyiapkan perangkat SBD disk bersama Azure

Konfigurasi agen pagar Azure

Penginstalan kluster

Membuat perangkat STONITH di kluster Pacemaker

SBD sebagai perangkat anggar

Agen pagar Azure sebagai perangkat anggar

Mengonfigurasi Pacemaker untuk acara terjadwal Azure

Konfigurasi pagar opsional

Langkah berikutnya

Saran dan Komentar

Sumber Daya Tambahan: