Configuración de Pacemaker en Red Hat Enterprise Linux en Azure
En este artículo se describe cómo configurar un clúster básico de Pacemaker en Red Hat Enterprise Server (RHEL). Las instrucciones cubren RHEL 7, RHEL 8 y RHEL 9.
Requisitos previos
Lea primero las notas y los documentos de SAP siguientes:
- Nota de SAP 1928533, que incluye:
- Una lista de tamaños de máquina virtual (VM) de Azure que se admiten para la implementación de software de SAP.
- Información importante sobre capacidad para los tamaños de máquina virtual de Azure.
- Las combinaciones admitidas de software y sistema operativo (SO) y base de datos de SAP.
- La versión del kernel de SAP necesaria para Windows y Linux en Microsoft Azure.
- La nota de SAP 2015553 enumera los requisitos previos para las implementaciones de software de SAP admitidas por SAP en Azure.
- La nota de SAP 2002167 recomienda la configuración del sistema operativo para Red Hat Enterprise Linux.
- La nota de SAP 3108316 recomienda la configuración del sistema operativo para Red Hat Enterprise Linux 9.x.
- La nota de SAP 2009879 contiene las instrucciones de SAP HANA para Red Hat Enterprise Linux.
- La nota de SAP 3108302 tiene directrices de SAP HANA para Red Hat Enterprise Linux 9.x.
- La nota de SAP 2178632 contiene información detallada sobre todas las métricas de supervisión notificadas para SAP en Azure.
- La nota de SAP 2191498 incluye la versión de SAP Host Agent necesaria para Linux en Azure.
- La nota de SAP 2243692 incluye información acerca de las licencias de SAP en Linux en Azure.
- La nota de SAP 1999351 contiene más información de solución de problemas sobre la extensión de supervisión mejorada de Azure para SAP.
- La WIKI de la comunidad SAP contiene todas las notas de SAP que se necesitan para Linux.
- Planeación e implementación de Azure Virtual Machines para SAP en Linux
- Implementación de Azure Virtual Machines para SAP en Linux (este artículo)
- Implementación de DBMS de Azure Virtual Machines para SAP en Linux
- Replicación del sistema sap HANA en el clúster de Pacemaker
- Documentación general de RHEL:
- Documentación de RHEL específica para Azure:
- Directivas de soporte técnico para clústeres de alta disponibilidad de RHEL: Microsoft Azure Virtual Machines como miembros del clúster
- Instalación y configuración de un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.4 (y versiones posteriores) en Microsoft Azure
- Consideraciones sobre la adopción de RHEL 8: alta disponibilidad y clústeres
- Configuración de SAP S/4HANA ASCS/ERS con el servidor 2 de puesta en cola independiente (ENSA2) en Pacemaker en RHEL 7.6
- RHEL para ofertas SAP en Azure
Instalación del clúster
Nota:
Red Hat no admite un guardián emulado por software. Red Hat no es compatible con SBD en plataformas en la nube. Para obtener más información, consulte Directivas de soporte técnico para clústeres de alta disponibilidad de RHEL: sbd y fence_sbd.
El único mecanismo de barrera admitido para los clústeres de RHEL de Pacemaker en Azure es un agente de barrera de Azure.
Los siguientes elementos llevan delante:
- [A] : Aplicable a todos los nodos
- [1]: solo aplicable al nodo 1
- [2]: solo aplicable al nodo 2
Las diferencias en los comandos o la configuración entre RHEL 7 y RHEL 8/RHEL 9 se marcan en el documento.
[A] Registro. Este paso es opcional. Si usa imágenes habilitadas para alta disponibilidad de SAP de RHEL, este paso no es necesario.
Por ejemplo, si va a implementar en RHEL 7, registre la máquina virtual y conéctela a un grupo que contenga repositorios para RHEL 7.
sudo subscription-manager register # List the available pools sudo subscription-manager list --available --matches '*SAP*' sudo subscription-manager attach --pool=<pool id>
Al adjuntar un grupo a una imagen de RHEL de pago por uso de Azure Marketplace, se le factura de forma eficaz el uso de RHEL. Se le factura una vez por la imagen de pago por uso y una vez por el derecho de RHEL en el grupo que adjunte. Para mitigar esta situación, Azure ahora proporciona imágenes de RHEL bring-your-own-subscription. Para más información, consulte Imágenes Gold de tipo "Bring-your-own-subscription" (BYOS) de Red Hat Enterprise Linux en Azure.
[A] Habilitación de RHEL para los repositorios SAP. Este paso es opcional. Si usa imágenes habilitadas para alta disponibilidad de SAP de RHEL, este paso no es necesario.
Para instalar los paquetes necesarios en RHEL 7, habilite los repositorios siguientes:
sudo subscription-manager repos --disable "*" sudo subscription-manager repos --enable=rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms
[A] Instale el complemento de alta disponibilidad de RHEL.
sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat
Importante
Se recomiendan las siguientes versiones del agente de barrera de Azure (o posterior) para que los clientes se beneficien de un tiempo de conmutación por error más rápido, si se produce un error en una detención de recursos o los nodos del clúster ya no se pueden comunicar entre sí:
RHEL 7.7 o superior usan la versión más reciente disponible del paquete de agentes de barrera.
RHEL 7.6: fence-agents-4.2.1-11.el7_6.8
RHEL 7.5: fence-agents-4.0.11-86.el7_5.8
RHEL 7.4: fence-agents-4.0.11-66.el7_4.12
Para más información, consulte La máquina virtual de Azure que se ejecuta como miembro del clúster de alta disponibilidad de RHEL tarda mucho tiempo en estar cercada o se produce un error o se agota el tiempo de espera antes de que se cierre la máquina virtual.
Importante
Se recomiendan las siguientes versiones del agente de barrera de Azure (o posterior) para los clientes que quieran usar identidades administradas para recursos de Azure en lugar de nombres de entidad de seguridad de servicio para el agente de barrera:
RHEL 8.4: fence-agents-4.2.1-54.el8.
RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.
Importante
En RHEL 9, se recomiendan las siguientes versiones de paquete (o posteriores) para evitar problemas con el agente de barrera de Azure:
fence-agents-4.10.0-20.el9_0.7
fence-agents-common-4.10.0-20.el9_0.6
ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm
Compruebe la versión del agente de delimitación de Azure. Si es necesario, actualícelo a la versión mínima necesaria o posterior.
# Check the version of the Azure Fence Agent sudo yum info fence-agents-azure-arm
Importante
Si necesita actualizar el agente de barrera de Azure y, si usa un rol personalizado, asegúrese de actualizar el rol personalizado para incluir la acción powerOff. Para obtener más información, consulte Creación de un rol personalizado para el agente de barrera.
Si va a implementar en RHEL 9, instale también los agentes de recursos para la implementación en la nube.
sudo yum install -y resource-agents-cloud
[A] Configure la resolución de nombres 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 fundamental tener una resolución confiable de nombres de host. Se produce un error en la comunicación del clúster si los nombres no están disponibles, lo que puede provocar retrasos en la conmutación por error del clúster.
La ventaja de usar
/etc/hosts
es que el clúster se convierte en independiente de DNS, lo que podría ser también un único punto de errores.sudo vi /etc/hosts
Inserte las líneas siguientes en
/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
[A] Cambie la
hacluster
contraseña a la misma contraseña.sudo passwd hacluster
[A] Agregue reglas de firewall para Pacemaker.
Agregue las siguientes reglas de firewall para todas las comunicaciones entre los nodos del clúster.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --add-service=high-availability
[A] Habilite los servicios de clúster básicos.
Ejecute los comandos siguientes para habilitar el servicio de Pacemaker e inícielo.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service
[1] Cree un clúster de Pacemaker.
Ejecute los comandos siguientes para autenticar los nodos y crear el clúster. Establezca el token en 30000 para permitir el mantenimiento de conservación de memoria. Para más información, consulte este artículo para Linux.
Si va a compilar un clúster en RHEL 7.x, use los siguientes comandos:
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
Si va a compilar un clúster en RHEL 8.x/RHEL 9.x, use los siguientes comandos:
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
Para comprobar el estado del clúster, ejecute el comando siguiente:
# 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] Establezca los votos esperados.
# 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
Sugerencia
Si va a crear un clúster de varios nodos, es decir, un clúster con más de dos nodos, no establezca los votos en 2.
[1] Permitir acciones simultáneas de barrera.
sudo pcs property set concurrent-fencing=true
Creación de un dispositivo de barrera
El dispositivo de barrera usa una identidad administrada para un recurso de Azure o una entidad de servicio para autorizarla en 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 usa. No use identidades administradas asignadas por el usuario con Pacemaker en este momento. Un dispositivo de barrera, basado en la identidad administrada, se admite en RHEL 7.9 y RHEL 8.x/RHEL 9.x.
[1] Creación de un rol personalizado para el agente de barrera
La identidad administrada y la entidad de servicio no tienen permisos para acceder a los recursos de Azure de forma predeterminada. Debe conceder a la identidad administrada o a la entidad de servicio permisos para iniciar y detener (apagar) todas las máquinas virtuales del clúster. Si aún no ha creado 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, reemplazar y yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
por xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
los identificadores de la 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 Linux Fence Agent Role
personalizado que se creó en la última sección a 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 más información, 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.
[1] Creación de los dispositivos de barrera
Después de editar los permisos de las máquinas virtuales, puede configurar los dispositivos de barrera en el clúster.
sudo pcs property set stonith-timeout=900
Nota:
La opción pcmk_host_map
solo es necesaria en el comando si los nombres de host de RHEL y los nombres de máquina virtual de Azure no son idénticos. Especifique la asignación en el formato hostname:nombre-VM.
Consulte la sección en negrita en el comando. Para obtener más información, consulte ¿Qué formato debo usar para especificar asignaciones de nodos a dispositivos de barrera en pcmk_host_map?.
Para configurar el dispositivo de barrera en RHEL 7.X, use el comando siguiente:
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
Para RHEL 8.x/9.x, use el siguiente comando para configurar el dispositivo de barrera:
# 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
Si usa un dispositivo de barrera basado en la configuración de la entidad de servicio, lea Cambio de SPN a MSI para clústeres de Pacemaker mediante el uso de barreras de Azure y aprenda a convertir a la configuración de identidad administrada.
Sugerencia
- Para evitar carreras de barrera dentro de un clúster de pacemaker de dos nodos, puede configurar la
priority-fencing-delay
propiedad del clúster. 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 ¿Puede Pacemaker cercar el nodo de clúster con los recursos en ejecución más pequeños?. - La propiedad
priority-fencing-delay
es aplicable a Pacemaker versión 2.0.4-6.el8 o posterior y en un clúster de dos nodos. Si configura lapriority-fencing-delay
propiedad de clúster, no es necesario establecer lapcmk_delay_max
propiedad . Pero si la versión de Pacemaker es menor que 2.0.4-6.el8, debe establecer lapcmk_delay_max
propiedad . - Para obtener instrucciones sobre cómo establecer la
priority-fencing-delay
propiedad del clúster, consulte los documentos de alta disponibilidad de escalado vertical de SAP ASCS/ERS y SAP HANA correspondientes.
Las operaciones de supervisión y barrera se deserializan. Como resultado, si hay una operación de supervisión de ejecución más larga y un evento de barrera simultánea, no hay ningún retraso en la conmutación por error del clúster porque la operación de supervisión ya se está ejecutando.
[1] Habilite el uso de un dispositivo de barrera
sudo pcs property set stonith-enabled=true
Sugerencia
El agente de barrera de Azure requiere conectividad saliente a puntos de conexión públicos. Para más información junto con las posibles soluciones, consulte Conectividad de punto de conexión público para máquinas virtuales que usan ILB estándar.
Configuración de Pacemaker para eventos programados de Azure
Azure ofrece eventos programados. Los eventos programados se envían a través del servicio de metadatos y permiten que la aplicación se prepare para dichos eventos.
El agente azure-events-az
de recursos de Pacemaker supervisa los eventos programados de Azure. Si se detectan eventos y el agente de recursos determina que hay otro nodo de clúster disponible, establece un atributo de mantenimiento del clúster.
Cuando se establece el atributo de mantenimiento del clúster para un nodo, la restricción de ubicación se desencadena y todos los recursos con nombres que no empiezan por health-
se migran del nodo con el evento programado. Después de que el nodo de clúster afectado esté libre de ejecutar recursos de clúster, el evento programado se confirma y puede ejecutar su acción, como un reinicio.
[A] Asegúrese de que el paquete del
azure-events-az
agente ya está instalado y actualizado.RHEL 8.x: sudo dnf info resource-agents RHEL 9.x: sudo dnf info resource-agents-cloud
Requisitos mínimos de versión:
- 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 y versiones posteriores:
resource-agents-cloud-4.10.0-34.1
- RHEL 8.4:
[1] Configure los recursos en Pacemaker.
#Place the cluster in maintenance mode sudo pcs property set maintenance-mode=true
[1] Establezca la estrategia y la restricción del nodo de mantenimiento del clúster de Pacemaker.
sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ defined '#uname'
Importante
No defina ningún otro recurso del clúster a
health-
partir de los recursos descritos en los pasos siguientes.[1] Establezca el valor inicial de los atributos del clúster. Ejecute para cada nodo de clúster y para entornos de escalado horizontal, incluida la máquina virtual creadora de mayoría.
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] Configure los recursos en Pacemaker. Asegúrese de que los recursos comienzan por
health-azure
.sudo pcs resource create health-azure-events \ ocf:heartbeat:azure-events-az op monitor interval=10s sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true
Sacar el clúster de Pacemaker fuera del modo de mantenimiento.
sudo pcs property set maintenance-mode=false
Borre los errores durante la habilitación y compruebe que los
health-azure-events
recursos se han iniciado correctamente en todos los nodos del clúster.sudo pcs resource cleanup
La primera vez que la ejecución de consultas para eventos programados puede tardar hasta dos 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 obtener más información, consulte Eventos programados.
Configuración de barreras opcionales
Sugerencia
Esta sección solo es aplicable si desea configurar el dispositivo fence_kdump
de barrera especial .
Si necesita recopilar información de diagnóstico dentro de la máquina virtual, puede resultar útil configurar otro dispositivo de barrera en función del agente fence_kdump
de barrera. El fence_kdump
agente puede detectar que un nodo entró en la recuperación de bloqueos de kdump y puede permitir que se complete el servicio de recuperación de bloqueos antes de que se invoquen otros métodos de barrera. Tenga en cuenta que fence_kdump
no es un reemplazo de los mecanismos de barrera tradicionales, como el agente de barrera de Azure, cuando se usan máquinas virtuales de Azure.
Importante
Tenga en cuenta que cuando fence_kdump
se configura como un dispositivo de barrera de primer nivel, presenta retrasos en las operaciones de barrera y, respectivamente, retrasos en la conmutación por error de los recursos de la aplicación.
Si se detecta correctamente un volcado de memoria, la barrera se retrasa hasta que se completa el servicio de recuperación de bloqueos. Si el nodo con error no es accesible o si no responde, la barrera se retrasa por tiempo determinado, el número configurado de iteraciones y el fence_kdump
tiempo de espera. Para más información, consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.
Es posible que sea necesario adaptar el tiempo de espera propuesto fence_kdump
al entorno específico.
Se recomienda configurar fence_kdump
la barrera solo cuando sea necesario para recopilar diagnósticos dentro de la máquina virtual y siempre en combinación con métodos de barrera tradicionales, como el agente de barrera de Azure.
Los siguientes artículos de Kb de Red Hat contienen información importante sobre la configuración de fence_kdump
barreras:
- Consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.
- Consulte Configuración y administración de niveles de barrera en un clúster de RHEL con Pacemaker.
- Consulte fence_kdump produce un error con "tiempo de espera después de X segundos" en un clúster de alta disponibilidad de RHEL 6 o 7 con herramientas kexec anteriores a 2.0.14.
- Para obtener información sobre cómo cambiar el tiempo de espera predeterminado, consulte Cómo configurar kdump para su uso con el complemento RHEL 6, 7, 8 HA?
- Para obtener información sobre cómo reducir el retraso de conmutación por error al usar
fence_kdump
, consulte ¿Puedo reducir el retraso esperado de la conmutación por error al agregar fence_kdump configuración?.
Ejecute los siguientes pasos opcionales para agregar fence_kdump
como una configuración de barrera de primer nivel, además de la configuración del agente de barrera de Azure.
[A] Compruebe que
kdump
está activo y configurado.systemctl is-active kdump # Expected result # active
[A] Instale el agente de barrera
fence_kdump
.yum install fence-agents-kdump
[1] Cree un
fence_kdump
dispositivo de barrera en el clúster.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30
[1] Configure los niveles de barrera para que el
fence_kdump
mecanismo de barrera se active primero.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" pcs stonith level add 1 prod-cl1-0 rsc_st_kdump pcs stonith level add 1 prod-cl1-1 rsc_st_kdump pcs stonith level add 2 prod-cl1-0 rsc_st_azure pcs stonith level add 2 prod-cl1-1 rsc_st_azure # Check the fencing level configuration pcs stonith level # Example output # Target: prod-cl1-0 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure # Target: prod-cl1-1 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure
[A] Permita los puertos necesarios para
fence_kdump
a través del firewall.firewall-cmd --add-port=7410/udp firewall-cmd --add-port=7410/udp --permanent
[A] Asegúrese de que el
initramfs
archivo de imagen contiene losfence_kdump
archivos yhosts
. Para más información, consulte Cómo configuración de fence_kdump en un clúster de 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
[A] Realice la
fence_kdump_nodes
configuración en/etc/kdump.conf
para evitar quefence_kdump
se produzca un error con un tiempo de espera para algunaskexec-tools
versiones. Para obtener más información, consulte fence_kdump tiempos de espera cuando no se especifica fence_kdump_nodes con kexec-tools versión 2.0.15 o posterior y fence_kdump produce un error en "tiempo de espera después de X segundos" en un clúster de alta disponibilidad de RHEL 6 o 7 con versiones anteriores a 2.0.14. Aquí se presenta la configuración de ejemplo de un clúster de dos nodos. Después de realizar un cambio en/etc/kdump.conf
, la imagen kdump debe volver a generarse. Para volver a generarlo, reinicie elkdump
servicio.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
Pruebe la configuración bloqueando un nodo. Para más información, consulte Cómo configuración de fence_kdump en un clúster de Red Hat Pacemaker.
Importante
Si el clúster ya está en uso productivo, planee la prueba en consecuencia porque bloquear un nodo tiene un impacto en la aplicación.
echo c > /proc/sysrq-trigger
Pasos siguientes
- Consulte Planeamiento e implementación de Azure Virtual Machines para SAP.
- Consulte Implementación de Azure Virtual Machines para SAP.
- Consulte Implementación de DBMS de Azure Virtual Machines para SAP.
- Para obtener información sobre cómo establecer alta disponibilidad y planear la recuperación ante desastres de SAP HANA en máquinas virtuales de Azure, consulte Alta disponibilidad de SAP HANA en Azure Virtual Machines.