Compartir vía

Configuración de Pacemaker en SUSE Linux Enterprise Server en Azure

  • Artículo

En este artículo se describe cómo configurar Pacemaker en SUSE Linux Enterprise Server (SLES) en Azure.

Información general

En Azure, tiene dos opciones para configurar barreras en el clúster de Pacemaker para SLES. Puede usar un agente de barrera de Azure, que reinicia un nodo con error a través de las API de Azure, o puede usar un dispositivo SBD.

Uso de un dispositivo SBD

Puede configurar el dispositivo SBD mediante cualquiera de estas dos opciones:

  • SBD con un servidor de destino iSCSI:

    El dispositivo SBD requiere al menos una máquina virtual adicional que actúe como servidor de destino de la Interfaz de sistema de equipos pequeños (iSCSI) de Internet y proporciona un dispositivo SBD. Estos servidores de destino iSCSI, sin embargo, pueden compartirse con otros clústeres de Pacemaker. La ventaja de usar un dispositivo SBD es que, si ya utiliza dispositivos SBD en un entorno local, no se necesitan cambios en el modo de operar con el clúster de Pacemaker.

    Puede utilizar hasta tres dispositivos SBD para un clúster de Pacemaker para permitir que un dispositivo SBD deje de estar disponible, por ejemplo durante la aplicación de revisiones del sistema operativo del servidor de destino iSCSI. Si desea utilizar más de un dispositivo SBD por Pacemaker, asegúrese de implementar varios servidores de destino iSCSI y conectar un SBD desde cada servidor de destino iSCSI. Se recomienda usar un dispositivo SBD o tres. Pacemaker no puede cercar automáticamente un nodo de clúster si solo están configurados dos dispositivos SBD y uno de ellos no está disponible. Si desea poder vallar cuando un servidor de destino iSCSI esté inactivo, deberá usar tres dispositivos SBD y, por tanto, tres servidores de destino iSCSI. Esta es la configuración más resistente cuando se usan SBD.

    Diagrama de resumen de Pacemaker en SLES

    Importante

    Cuando planee e implemente nodos en clúster y dispositivos SBD de Linux Pacemaker, no permita que el enrutamiento entre las máquinas virtuales y las máquinas virtuales que hospedan los dispositivos SBD pase a través de otros dispositivos, como una aplicación virtual de red (NVA).

    Los eventos de mantenimiento y otros problemas con el NVA pueden tener un impacto negativo en la estabilidad y confiabilidad de la configuración general del clúster. Para más información, consulte las reglas de enrutamiento definidas por el usuario.

  • SBD con un disco compartido de Azure:

    Para configurar un dispositivo SBD, debe conectar al menos un disco compartido de Azure a todas las máquinas virtuales que forman parte del clúster de Pacemaker. La ventaja del dispositivo SBD que usa un disco compartido de Azure es que no es necesario implementar máquinas virtuales adicionales.

    Diagrama del dispositivo SBD de disco compartido de Azure para el clúster Pacemaker de SLES

    Estas son algunas consideraciones importantes sobre los dispositivos SBD cuando se usa un disco compartido de Azure:

    • El disco compartido de Azure con SSD prémium se admite como dispositivo SBD.
    • Los dispositivos SBD que usan un disco compartido de Azure se admiten en SLES High Availability 15 SP01 y versiones posteriores.
    • El dispositivo SBD que usa un disco compartido Premium de Azure es compatible con el almacenamiento con redundancia local (LRS) y el almacenamiento con redundancia de zona (ZRS).
    • En función del tipo de implementación, elija el almacenamiento redundante adecuado para un disco compartido de Azure como dispositivo SBD.
    • Un dispositivo SBD que utiliza LRS para el disco compartido prémium de Azure (skuName: Premium_LRS) es compatible con la implementación en el conjunto de disponibilidad.
    • Un dispositivo SBD que utiliza ZRS para un disco compartido prémium de Azure (skuName: Premium_ZRS) es compatible con la implementación en el conjunto de disponibilidad.
    • Un ZRS para el disco administrado no está disponible actualmente en todas las regiones con zonas de disponibilidad. Para más información, consulte la sección "Limitaciones" de ZRS en Opciones de redundancia para discos administrados.
    • No es necesario que el disco compartido de Azure que use para dispositivos SBD sea grande. El valor maxShares determina cuántos nodos de clúster puede usar el disco compartido. Por ejemplo, puede usar tamaños de disco P1 o P2 para el dispositivo SBD en un clúster de dos nodos, como el escalado vertical SAP ASCS/ERS o SAP HANA.
    • Para el escalado horizontal de HANA con la replicación del sistema HANA (HSR) y Pacemaker, puede usar el disco compartido de Azure para el dispositivo SBD en clústeres con hasta cuatro nodos por sitio de replicación debido al límite actual de maxShares.
    • No se recomienda conectar un dispositivo SBD de disco compartido de Azure entre clústeres de Pacemaker.
    • Si usa varios dispositivos SBD de disco compartido de Azure, compruebe el límite para el número máximo de discos de datos que se pueden conectar a la máquina virtual.
    • Para más información sobre las limitaciones del disco compartido de Azure, repase minuciosamente la sección "Limitaciones" de la documentación del disco compartido de Azure.

Uso de un agente de barrera de Azure

Puede configurar barreras mediante un agente de barrera de Azure. El agente de barrera de Azure requiere identidades administradas para las máquinas virtuales del clúster o una entidad de servicio que administre el reinicio de los nodos con errores mediante las API de Azure. Los agentes de barrera de Azure no requieren la implementación de máquinas virtuales adicionales.

Configuración de un servidor de destino iSCSI

Para usar un dispositivo SBD que usa un servidor de destino iSCSI para la barrera, siga las instrucciones de las secciones siguientes.

Configuración del servidor de destino iSCSI

En primer lugar, debe crear las máquinas virtuales de destino iSCSI. Puede compartir servidores de destino iSCSI con varios clústeres de Pacemaker.

  1. Implemente nuevas máquinas virtuales SLES 12 SP3 o superior y conéctelas mediante SSH. No es necesario que las máquinas sean grandes. Los tamaños de máquina virtual como Standard_E2s_v3 o Standard_D2s_v3 son suficientes. Asegúrese de usar almacenamiento Premium en el disco del sistema operativo.

  2. Ejecute los siguientes comandos en las máquinas virtuales de destino iSCSI.

    a. Actualice SLES.

    sudo zypper update

    Nota

    Es posible que tenga que reiniciar el sistema operativo después de actualizarlo.

    b. Quite los paquetes

    Para evitar un problema conocido con targetcli y SLES 12 SP3, desinstale los siguientes paquetes. Puede omitir los errores acerca de los paquetes que no se encuentran.

    sudo zypper remove lio-utils python-rtslib python-configshell targetcli

    c. Instale paquetes de destino iSCSI.

    sudo zypper install targetcli-fb dbus-1-python

    d. Habilite el servicio de destino iSCSI.

    sudo systemctl enable targetcli
sudo systemctl start targetcli

Creación de un dispositivo iSCSI en el servidor de destino iSCSI

Para crear los discos iSCSI para los clústeres utilizados por los sistemas SAP, ejecute los siguientes comandos en todas las máquinas virtuales de destino iSCSI. En el ejemplo siguiente, se crean dispositivos SBD para varios clústeres. Se muestra cómo se podría usar un servidor de destino iSCSI para varios clústeres. Los dispositivos SBD se colocan en el disco del sistema operativo. Asegúrese de que dispone de suficiente espacio.

  • nfs: identifica el clúster NFS.
  • nfs: identifica el clúster NFS de NW1.
  • dbnw1: identifica la versión de la base de datos NW1.
  • nfs-0 y nfs-1: los nombres de host de los nodos del clúster NFS.
  • nw1-xscs-0 y nw1-xscs-1: los nombres de host de los nodos del clúster NW1.
  • nw1-db-0 y nw1-db-1: los nombres de host de los nodos del clúster de base de datos.

En las instrucciones siguientes, reemplace y ajuste los nombres de host de los nodos del clúster y el SID del sistema SAP.

  1. Cree la carpeta raíz para todos los dispositivos SBD.

    sudo mkdir /sbd

  2. Cree el dispositivo SBD para el servidor NFS.

    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

  3. Cree el dispositivo SBD para el servidor ASCS del sistema SAP 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.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

  4. Cree el dispositivo SBD para el clúster de base de datos del sistema SAP NW1.

    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

  5. Guarde los cambios de targetcli.

    sudo targetcli saveconfig

  6. Compruebe que todo se ha configurado correctamente.

    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]

Configuración del dispositivo SBD del servidor de destino iSCSI

Conéctese al dispositivo iSCSI que se creó en el último paso desde el clúster. Ejecute los siguientes comandos en los nodos del clúster nuevo que desea crear.

Nota

  • [A]: se aplica a todos los nodos.
  • [1]: se aplica solo al nodo 1.
  • [2]: Se aplica solo al nodo 2.

  1. [A] Instale el paquete iSCSI.

    sudo zypper install open-iscsi

  2. [A] Conecte a los dispositivos iSCSI. En primer lugar, habilite los servicios iSCSI y SBD.

    sudo systemctl enable iscsid
sudo systemctl enable iscsi
sudo systemctl enable sbd

  3. [1] Cambie el nombre del iniciador en el primer nodo.

    sudo vi /etc/iscsi/initiatorname.iscsi

  4. [1] Cambie el contenido del archivo para que coincida con las listas de control de acceso (ACL) que utilizó al crear el dispositivo iSCSI en el servidor de destino iSCSI (por ejemplo, para el servidor NFS).

    InitiatorName=iqn.2006-04.nfs-0.local:nfs-0

  5. [2] Cambie el nombre del iniciador en el segundo nodo.

    sudo vi /etc/iscsi/initiatorname.iscsi

  6. [2] Cambie el contenido del archivo para que coincida con las ACL que utilizó al crear el dispositivo iSCSI en el servidor de destino iSCSI.

    InitiatorName=iqn.2006-04.nfs-1.local:nfs-1

  7. [A] Reinicie ahora el servicio iSCSI para aplicar el cambio.

    sudo systemctl restart iscsid
sudo systemctl restart iscsi

  8. [A] Conecte los dispositivos iSCSI. En el ejemplo siguiente, 10.0.0.17 es la dirección IP del servidor de destino iSCSI y 3260 es el puerto predeterminado. iqn.2006-04.nfs.local:nfs es uno de los nombres de destino que aparece cuando se ejecuta el primer comando iscsiadm -m discovery.

    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

  9. [A] Si desea usar varios dispositivos SBD, conéctese también al segundo servidor de destino 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

  10. [A] Si desea usar varios dispositivos SBD, conéctese también al tercer servidor de destino 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

  11. [A] Asegúrese de que los dispositivos iSCSI están disponibles y anote el nombre del dispositivo (en el ejemplo siguiente /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

  12. [A] Recupere los identificadores de los dispositivos iSCSI.

    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

    El comando presenta tres identificadores de dispositivo para cada dispositivo SBD. Se recomienda usar el identificador que empieza por scsi-3. En el ejemplo anterior, los identificadores son:

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

  13. [1] Cree el dispositivo SBD.

    a. Use el identificador de dispositivo de los dispositivos iSCSI para crear dispositivos SBD en el primer nodo del clúster.

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

    b. Cree también el segundo y tercer dispositivo SBD si desea usar más de uno.

    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

  14. [A] Adapte la configuración de SBD.

    a. Abra el archivo de configuración de SBD.

    sudo vi /etc/sysconfig/sbd

    b. Cambie la propiedad del dispositivo SBD, habilite la integración de Pacemaker y cambie el modo de inicio del 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"
[...]

    Nota:

    Si el valor de la propiedad SBD_DELAY_START está establecido en "no", cambie el valor a "yes". También debe comprobar el archivo de servicio SBD para asegurarse de que el valor de TimeoutStartSec sea mayor que el valor de SBD_DELAY_START. Para más información, consulte Configuración del archivo SBD.

  15. [A] Cree el archivo de configuración softdog.

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

  16. [A] Cargue el módulo.

    sudo modprobe -v softdog

SBD con un disco compartido de Azure

Esta sección solo se aplica si quiere usar un dispositivo SBD con un disco compartido de Azure.

Creación y conexión de un disco compartido de Azure con PowerShell

  1. Ajuste los valores del grupo de recursos, la región de Azure, las máquinas virtuales, los números de unidad lógica (LUN), entre otros.

    $ResourceGroup = "MyResourceGroup"
$Location = "MyAzureRegion"

  2. Defina el tamaño del disco en función del tamaño de disco disponible para discos SSD prémium. En este ejemplo, se menciona el tamaño de disco P1 de 4G.

    $DiskSizeInGB = 4
$DiskName = "SBD-disk1"

  3. Con el parámetro -MaxSharesCount, defina el número máximo de nodos de clúster para conectar el disco compartido para el dispositivo SBD.

    $ShareNodes = 2

  4. Para un dispositivo SBD que usa LRS para un disco compartido prémium de Azure, use el siguiente skuName de almacenamiento:

    $SkuName = "Premium_LRS"

  5. Para un dispositivo SBD que usa ZRS para un disco compartido prémium de Azure, use el siguiente skuName de almacenamiento:

    $SkuName = "Premium_ZRS"

  6. Configure un disco compartido de Azure.

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

  7. Conecte el disco a las máquinas virtuales del clúster.

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

    a. Agregue el disco compartido de Azure al nodo de clúster 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. Agregue el disco compartido de Azure al nodo de clúster 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

Si desea implementar recursos mediante la CLI de Azure o Azure Portal, también puede consultar el documento Implementación de un disco ZRS.

Configuración del dispositivo SBD de disco compartido de Azure

  1. [A] Habilitar los servicios SBD.

    sudo systemctl enable sbd

  2. [A] Asegúrese de que el disco conectado esté disponible.

    # 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

  3. [A] Recupere los IDs de los discos conectados.

    # 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

    Los comandos enumeran los identificadores de dispositivo para el dispositivo SBD. Se recomienda usar el identificador que empieza por scsi-3. En el ejemplo anterior, el identificador es /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19.

  4. [1] Cree el dispositivo SBD.

    Use el identificador de dispositivo del paso 2 para crear dispositivos SBD en el primer nodo del clúster.

    # sudo sbd -d /dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19 -1 60 -4 120 create

  5. [A] Adapte la configuración de SBD.

    a. Abra el archivo de configuración de SBD.

    sudo vi /etc/sysconfig/sbd

    b. Cambie la propiedad del dispositivo SBD, habilite la integración de Pacemaker y cambie el modo de inicio del SBD.

    [...]
SBD_DEVICE="/dev/disk/by-id/scsi-3600224804208a67da8073b2a9728af19"
[...]
SBD_PACEMAKER="yes"
[...]
SBD_STARTMODE="always"
[...]

    Nota:

    Si el valor de la propiedad SBD_DELAY_START está establecido en "no", cambie el valor a "yes". También debe comprobar el archivo de servicio SBD para asegurarse de que el valor de TimeoutStartSec sea mayor que el valor de SBD_DELAY_START. Para más información, consulte Configuración del archivo SBD.

  6. Cree el archivo de configuración de softdog.

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

  7. Cargue el módulo.

    sudo modprobe -v softdog

Uso de un agente de barrera de Azure

Esta sección solo se aplica si quiere usar un dispositivo de barrera con un agente de barrera de Azure.

Creación de un dispositivo de agente de barrera de Azure

Esta sección solo se aplica si usa un dispositivo de barrera basado en un agente de barrera de Azure. El dispositivo de barrera usa una identidad administrada o un entidad de servicio para la autorización en Microsoft Azure.

Para crear una identidad administrada (MSI), cree una identidad administrada asignada por el sistema para cada máquina virtual del clúster. Si ya existe una identidad administrada asignada por el sistema, se usará. En este momento, no se deben usar identidades administradas asignadas por el usuario con Pacemaker. El agente de barrera de Azure, basado en la identidad administrada, es compatible con SLES 12 SP5 y SLES 15 SP1 y versiones posteriores.

[1] Creación de un rol personalizado para el agente de barrera

De forma predeterminada, ni la identidad administrada ni la entidad de servicio tienen permisos para acceder a los recursos de Azure. Debe concedérselos para iniciar y detener (desasignar) todas las máquinas virtuales del clúster. Si no ha creado aún el rol personalizado, puede crearlo mediante PowerShell o la CLI de Azure.

Utilice el siguiente contenido para el archivo de entrada. Debe adaptar el contenido a las suscripciones. Es decir, reemplace xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx y aaaay-aaaa-aaaa-aaaa-aaaay por sus propios identificadores de suscripción. Si solo tiene una suscripción, quite la segunda entrada en 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": []
}

[A] Asignación del rol personalizado

Use la identidad administrada o la entidad de servicio.

Asigne el rol personalizado "Rol del agente de barrera de Linux" que se creó en el último capítulo para cada identidad administrada de las máquinas virtuales del clúster. Cada identidad administrada asignada por el sistema de la máquina virtual necesita el rol asignado para cada recurso de máquina virtual del clúster. Para conocer los pasos detallados, consulte Asignación de acceso de una identidad administrada a un recurso mediante Azure Portal. Compruebe que la asignación de roles de identidad administrada de cada máquina virtual contiene todas las máquinas virtuales del clúster.

Importante

Tenga en cuenta que la asignación y eliminación de la autorización con identidades administradas se puede retrasar hasta que sea efectiva.

Instalación del clúster

Nota

  • [A]: se aplica a todos los nodos.
  • [1]: se aplica solo al nodo 1.
  • [2]: Se aplica solo al nodo 2.

  1. [A] Actualice SLES.

    sudo zypper update

    Nota:

    Para SLES 15 SP4, compruebe las versiones de los paquetes crmsh y pacemaker para asegurarse de que cumplen los requisitos mínimos de versión:

    • crmsh-4.4.0+20221028.3e41444-150400.3.9.1 o posterior
    • pacemaker-2.1.2+20211124.ada5c3b36-150400.4.6.1 o posterior

    Importante

    • SLES 12 SP5: si python-azure-core-1.23.1-2.12.8 está instalado, es posible que el agente de barrera de Azure no se inicie en un clúster de Pacemaker y muestre el mensaje de error "el SDK de Python de Azure Resource Manager no se encuentra o no es accesible" en /var/log/messages. Siga las instrucciones de SUSE KBA 21532 para obtener más detalles.
    • SLES 15 SP4+: después de actualizar el sistema operativo, las bibliotecas de Azure para Python podrían usar el intérprete de Python 3.11, lo que provoca que el agente de barrera de Azure no se inicie en un clúster de Pacemaker. El mensaje de error "el SDK de Python de Azure Resource Manager no se encuentra o no es accesible" aparecerá en /var/log/messages. Siga las instrucciones de SUSE KBA 21504 para obtener más detalles.

  2. [A] Instale el componente, que necesitará para los recursos del clúster.

    sudo zypper in socat

  3. [A] Instale el componente azure-lb, que necesitará para los recursos del clúster.

    sudo zypper in resource-agents

    Nota:

    Compruebe la versión del paquete resource-agents y asegúrese de que se cumplen los requisitos de versión mínimos:

    • SLES 12 SP4/SP5: la versión debe ser, al menos, resource-agents-4.3.018.a7fb5035-3.30.1.
    • SLES 15/15 SP1: la versión debe ser al menos resource-agents-4.3.0184.6ee15eb2-4.13.1.

  4. [A] Configure el sistema operativo.

    a. Pacemaker crea en ocasiones muchos procesos, lo que puede agotar el número permitido. Cuando esto ocurre, un latido entre los nodos del clúster podría producir un error y dar lugar a la conmutación por error de los recursos. Se recomienda aumentar los procesos máximos permitidos al establecer el parámetro siguiente.

    # 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. Reduzca el tamaño de la caché de datos incorrectos. Para más información, consulte Low write performance on SLES 11/12 servers with large RAM (Bajo rendimiento de escritura en servidores SLES 11/12 con RAM grande).

    sudo vi /etc/sysctl.conf
# Change/set the following settings
vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800

    c. Asegúrese de que vm.swappiness está establecido en 10 para reducir el uso de intercambio y favorecer la memoria.

    sudo vi /etc/sysctl.conf
# Change/set the following setting
vm.swappiness = 10

  5. [A] Compruebe la versión del paquete cloud-netconfig-azure.

    Compruebe la versión instalada del paquete cloud-netconfig-azure, para lo que debe ejecutar zypper info cloud-netconfig-azure. Si la versión es inferior a la 1.3, se recomienda actualizar el paquete cloud-netconfig-azure a la última versión disponible.

    Sugerencia

    Si la versión del entorno es la 1.3 o superior, ya no es necesario suprimir la administración de las interfaces de red por el complemento de red en la nube.

    Solo si la versión de cloud-netconfig-azure es inferior a la 1.3, cambie el archivo de configuración de la interfaz de red como se muestra en el código siguiente para evitar que el complemento de red de nube quite la dirección IP virtual (Pacemaker debe controlar la asignación). Para más información, consulte KB 7023633 de SUSE.

    # Edit the configuration file
sudo vi /etc/sysconfig/network/ifcfg-eth0 

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

  6. [1] Habilite el acceso de 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

  7. [2] Habilite el acceso de 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

  8. [1] Habilite el acceso de 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

  9. [A] Instale el paquete fence-agents si usa el dispositivo de barrera, basado en el agente de barrera de Azure.

    sudo zypper install fence-agents

    Importante

    La versión instalada del paquete fence-agents debe ser al menos la 4.4.0 para beneficiarse de los tiempos de conmutación por error rápida con el agente de barrera de Azure, si se delimita un nodo del clúster. Si ejecuta una versión anterior, se recomienda actualizar el paquete.

    Importante

    Si usa la identidad administrada, la versión instalada del paquete fence-agentes debe ser -

    • SLES 12 SP5: fence-agents 4.9.0+git.1624456340.8d746be9-3.35.2 o superior.
    • SLES 15 SP1 y versiones posteriores: agentes de barrera 4.5.2+git.1592573838.1eee0863 o posterior.

    Las versiones anteriores no funcionarán correctamente con una configuración de identidad administrada.

  10. [A] Instale el paquete fence-agents-azure-arm.

    Para SLES 12 SP5, si usa fence-agents versión 4.9.0+git.1624456340.8d746be9-3.41.3 o posterior, y para SLES 15 SP4 y versiones posteriores, debe instalar el paquete fence-agents-azure-arm. Este paquete incluirá todas las dependencias necesarias.

    # 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

  11. [A] Instale el SDK de Azure Python y el módulo de Python para Azure Identity.

    Para SLES 12 SP5, si la versión de fence-agents es inferior a 4.9.0+git.1624456340.8d746be9-3.41.3, y para SLES 15 SP3 y versiones anteriores, debe instalar los siguientes paquetes adicionales.

    # 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

    Importante

    En función de su tipo de imagen y versión, es posible que tenga que activar la extensión de nube pública para la versión del sistema operativo, antes de poder instalar el SDK de Python de Azure. Puede comprobar la extensión ejecutando SUSEConnect ---list-extensions. Para lograr los tiempos de conmutación por error más rápida con el agente de barrera de Azure:

    • En SLES 12 SP5, instale la versión 4.6.2 o posterior del paquete python-azure-mgmt-compute.
    • Si la versión de python-azure-mgmt-compute o python3-azure-mgmt-compute es 17.0.0-6.7.1, siga las instrucciones de SUSE KBA para actualizar la versión de los agentes de barrera e instalar la biblioteca cliente de Azure Identity para el módulo Python si falta.

  12. [A] Configure la resolución del nombre de host.

    Puede usar un servidor DNS o modificar el archivo /etc/hosts en todos los nodos. En este ejemplo se muestra cómo utilizar el archivo /etc/hosts.

    Reemplace la dirección IP y el nombre de host en los siguientes comandos.

    Importante

    Si usa nombres de host en la configuración del clúster, es esencial tener una resolución de nombre de host confiable. Si los nombres no están disponibles, se producirá un error en la comunicación con el clúster y esto puede provocar retrasos en la conmutación por error del clúster.

    La ventaja de usar /etc/hosts es que el clúster es independiente de DNS, lo que también podría representar un único punto de error.

    sudo vi /etc/hosts

    Inserte las líneas siguientes en el archivo /etc/hosts. Cambie la dirección IP y el nombre de host para que coincidan con su entorno.

    # 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

  13. [1] Instalación del clúster

    • Si usa dispositivos SBD para la barrera (para el servidor de destino iSCSI o el disco compartido de 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

    • Si no usa dispositivos SBD como barreras:

      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

  14. [2] Agregue el nodo al clúster.

    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

  15. [A] Cambie la contraseña de hacluster a la misma contraseña.

    sudo passwd hacluster

  16. [A] Ajuste la configuración de corosync.

    sudo vi /etc/corosync/corosync.conf

    a. Compruebe la sección siguiente del archivo y, si los valores no están ahí o son diferentes, ajústela. No olvide cambiar el token a 30 000 para permitir el mantenimiento con conservación de memoria. Para más información, consulte el artículo "Mantenimiento de máquinas virtuales en Azure" para Linux o 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. Reinicie el servicio corosync.

    sudo service corosync restart

Creación de un dispositivo de barrera en un clúster de Pacemaker

Sugerencia

  • Para evitar carreras de barrera dentro de un clúster de Pacemaker de dos nodos, puede configurar la propiedad adicional del clúster "priority-fencing-delay". Esta propiedad introduce un retraso adicional en la limitación de un nodo que tiene una prioridad de recurso total mayor cuando se produce un escenario de cerebro dividido. Para más información, consulte la guía de administración de extensiones de alta disponibilidad de SUSE Linux Enterprise Server.
  • La instrucción sobre cómo establecer la propiedad del clúster "priority-fencing-delay" se puede encontrar en el documento correspondiente sobre alta disponibilidad de escalabilidad vertical de SAP ASCS/ERS (aplicable solo en ENSA2) y SAP HANA.

  1. [1] Si está usando un dispositivo SDB (servidor de destino iSCSI o disco compartido de Azure) como dispositivo de barrera, ejecute los siguientes comandos. Habilite el uso de un dispositivo de barrera y establezca el retraso de la barrera.

    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"

  2. [1] Si usa un agente de barrera de Azure como barrera, ejecute los siguientes comandos. Después de asignar roles a ambos nodos de clúster, puede configurar los dispositivos de barrera en el clúster.

    sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true

    Nota

    La opción "pcmk_host_map" solo es necesaria en el comando si los nombres de host y los nombres de máquina virtual de Azure no son idénticos. Especifique la asignación en el formato hostname:vm-name.

# 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

Si usa un dispositivo de barrera, según la configuración de la entidad de servicio, lea Cambio de SPN a MSI para clústeres de Pacemaker mediante barreras de Azure y aprenda a realizar la conversión a la configuración de identidad administrada.

Importante

Las operaciones de supervisión y barrera se deserializan. Como resultado, si hay una operación de supervisión más larga y un evento de barrera simultánea, no habrá ningún retraso en la conmutación por error del clúster porque la operación de supervisión ya se está ejecutando.

Sugerencia

El agente de barrera de Azure requiere conectividad saliente a los punto de conexión públicos como se documenta, junto con las posibles soluciones, en Conectividad del punto de conexión público para las máquinas virtuales que usan el ILB estándar.

Configuración de Pacemaker para eventos programados de Azure

Azure ofrece eventos programados. Los eventos programados se proporcionan a través del servicio de metadatos y dan tiempo a la aplicación para prepararse para dichos eventos. El agente de recursos azure-events-az supervisa los eventos de Azure programados. Si se detectan eventos y el agente de recursos determina que hay otro nodo de clúster disponible, se establece un atributo de mantenimiento del clúster. Cuando el atributo de mantenimiento del clúster se establece para un nodo, se desencadena la restricción de ubicación y todos los recursos cuyo nombre no comience por "health-" se migran fuera del nodo con evento programado. Una vez que el nodo de clúster afectado queda libre de ejecutar recursos de clúster, se confirma el evento programado y puede ejecutar su acción, como reiniciar.

Importante

Anteriormente, en este documento se describía el uso de azure-events del agente de recursos. El nuevo agente de recursos azure-events-az es totalmente compatible con los entornos de Azure implementados en diferentes zonas de disponibilidad. Se recomienda usar el agente azure-events-az más reciente para todos los sistemas de alta disponibilidad de SAP con Pacemaker.

  1. [A] Asegúrese de que el paquete del agente de azure-events ya está instalado y actualizado.

    sudo zypper info resource-agents

    Requisitos mínimos de versión:

    • 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 y versiones posteriores: resource-agents-4.10.0+git40.0f4de473-150400.3.19.1

  2. [1] Configure los recursos en Pacemaker.

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

  3. [1] Establezca la estrategia y la restricción de los nodos de mantenimiento del clúster de Pacemaker.

    sudo crm configure property node-health-strategy=custom
sudo crm configure location loc_azure_health \
/'!health-.*'/ rule '#health-azure': defined '#uname'

    Importante

    No defina ningún otro recurso del clúster que empiece por "health-", aparte de los recursos descritos en los pasos siguientes de la documentación.

  4. [1] Establezca el valor inicial de los atributos del clúster. Ejecútelo para cada nodo del clúster. Para entornos de escalabilidad horizontal que incluyan la mayoría de máquinas virtuales de Pacemaker.

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

  5. [1] Configure los recursos en Pacemaker. Importante: Los recursos deben empezar por "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

    Nota:

    Al configurar el recurso "health-azure-events", se puede omitir el siguiente mensaje de advertencia.

    ADVERTENCIA: health-azure-events: atributo desconocido ”allow-unhealthy-nodes”.

  6. Sacar el clúster de Pacemaker del modo de mantenimiento

    sudo crm configure property maintenance-mode=false

  7. Borre los posibles errores durante la habilitación y compruebe que los recursos health-azure-events se han iniciado correctamente en todos los nodos del clúster.

    sudo crm resource cleanup

    La primera vez, la ejecución de consultas para eventos programados puede tardar hasta 2 minutos. Las pruebas de Pacemaker con eventos programados pueden usar acciones de reinicio o reimplementación para las máquinas virtuales del clúster. Para más información, consulte la documentación sobre eventos programados.

    Nota:

    Después de configurar los recursos de Pacemaker para el agente de azure-events, si coloca el clúster dentro y fuera del modo de mantenimiento, es posible que reciba mensajes de advertencia como estos:

    ADVERTENCIA: cib-bootstrap-options: atributo desconocido ”hostName_hostname”
    ADVERTENCIA: cib-bootstrap-options: atributo desconocido "azure-events_globalPullState"
    ADVERTENCIA: cib-bootstrap-options: atributo desconocido "hostName_ hostname"
    Estos mensajes de advertencia pueden ignorarse.

Pasos siguientes