Configuración de la replicación de sistemas escalables SAP HANA en un clúster Red Hat Enterprise Linux High Availability Add-On
La siguiente información describe la configuración de un clúster Red Hat Enterprise Linux (RHEL) High Availability Add-On para gestionar SAP HANA Scale-Up System Replication. El clúster utiliza instancias de servidor virtual en IBM® Power® Virtual Server como nodos del clúster.
Las instrucciones describen cómo automatizar SAP HANA Scale-Up System Replication para un despliegue de base de datos única en un escenario de rendimiento optimizado en un clúster RHEL HA Add-on.
Esta información va dirigida a arquitectos y especialistas que estén planificando una implantación de alta disponibilidad de SAP HANA en Power Virtual Server.
Antes de empezar
Revise los requisitos generales, la documentación del producto, los artículos de soporte y las notas de SAP que aparecen en Implementación de alta disponibilidad para aplicaciones de SAP en IBM Power Virtual Server Referencias.
Requisitos previos
- Se despliega un clúster de alta disponibilidad Red Hat en dos instancias de servidor virtual en Power Virtual Server.
- Instale y configure el clúster complementario RHEL HA de acuerdo con Implementación de un clúster complementario de alta disponibilidad Red Hat Enterprise Linux.
- Configure y verifique el vallado como se describe en el documento anterior.
- Las instancias de servidor virtual deben cumplir los requisitos de hardware y recursos de los sistemas SAP HANA en cuestión. Siga las directrices del documento Planificación de la implantación.
- Los nombres de host de las instancias del servidor virtual deben cumplir el requisito SAP HANA.
- SAP HANA está instalado en ambas instancias del servidor virtual y SAP HANA System Replication está configurado. La instalación de SAP HANA y la configuración de HANA System Replication no son específicas del entorno Power Virtual Server, y es necesario seguir los procedimientos estándar.
- Se requiere una suscripción válida a RHEL for SAP Applications o RHEL for SAP Solutions para habilitar los repositorios que necesita para instalar SAP HANA y los agentes de recursos para configuraciones HA.
Configuración de la replicación de sistemas SAP HANA en un clúster RHEL HA Add-On en IBM Power Virtual Server
Las instrucciones se basan en la documentación del producto Red Hat y en los artículos que aparecen en Implementación de alta disponibilidad para aplicaciones SAP en IBM Power Virtual Server Referencias.
Preparación de las variables de entorno
Para simplificar la configuración, prepare las siguientes variables de entorno para root en ambos nodos. Estas variables de entorno se utilizan con comandos posteriores del sistema operativo en esta información.
En ambos nodos, establezca las siguientes variables de entorno.
# General settings
export SID=<SID> # SAP HANA System ID (uppercase)
export sid=<sid> # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO> # SAP HANA instance number
# Cluster node 1
export NODE1=<HOSTNAME_1> # Virtual server instance hostname
export DC1="Site1" # HANA System Replication site name
# Cluster node 2
export NODE2=<HOSTNAME_2> # Virtual server instance hostname
export DC2="Site2" # HANA System Replication site name
# Single zone
export VIP=<IP address> # SAP HANA System Replication cluster virtual IP address
# Multizone region
export CLOUD_REGION=<CLOUD_REGION> # Multizone region name
export APIKEY="APIKEY or path to file" # API Key of the IBM Cloud IAM ServiceID for the resource agent
export API_TYPE="private or public" # Use private or public API endpoints
export IBMCLOUD_CRN_1=<IBMCLOUD_CRN_1> # Workspace 1 CRN
export IBMCLOUD_CRN_2=<IBMCLOUD_CRN_2> # Workspace 2 CRN
export POWERVSI_1=<POWERVSI_1> # Virtual server instance 1 id
export POWERVSI_2=<POWERVSI_2> # Virtual server instance 2 id
export SUBNET_NAME="vip-${sid}-net" # Name which is used to define the subnet in IBM Cloud
export CIDR="CIDR of subnet" # CIDR of the subnet containing the service IP address
export VIP="Service IP address" # IP address in the subnet
export JUMBO="true or false" # Enable Jumbo frames
Establecimiento de variables de entorno adicionales para la implantación de una zona única
Revise la información en Reservar direcciones IP virtuales y reserve una dirección IP virtual para el clúster SAP HANA System Replication. Establezca la variable
de entorno VIP
en la dirección IP reservada.
Establecimiento de variables de entorno adicionales para la implantación de una región multizona
Establezca las variables CLOUD_REGION
, APIKEY
, IBMCLOUD_CRN_?
, POWERVSI_?
tal y como se describe en la sección Recopilación de parámetros para configurar un clúster de alta disponibilidad. Establezca la variable API_TYPE
en private
para comunicarse con IBM Cloud IAM y IBM Power Cloud API a través de endpoints privados. La variable SUBNET_NAME
contiene el nombre de la
subred. La variable CIDR
representa la notación Classless Inter-Domain Routing (CIDR ) para la subred en el formato <IPv4_address>/number
. La variable VIP
es la dirección IP del recurso
de dirección IP virtual y debe pertenecer a la CIDR
de la subred. Establezca la variable JUMBO
en true
si desea habilitar la subred para un tamaño de MTU grande.
A continuación se muestra un ejemplo de cómo configurar las variables de entorno adicionales necesarias para la implementación de una región multizona.
export CLOUD_REGION="eu-de"
export IBMCLOUD_CRN_1="crn:v1:bluemix:public:power-iaas:eu-de-2:a/a1b2c3d4e5f60123456789a1b2c3d4e5:a1b2c3d4-0123-4567-89ab-a1b2c3d4e5f6::"
export IBMCLOUD_CRN_2="crn:v1:bluemix:public:power-iaas:eu-de-1:a/a1b2c3d4e5f60123456789a1b2c3d4e5:e5f6a1b2-cdef-0123-4567-a1b2c3d4e5f6::"
export POWERVSI_1="a1b2c3d4-0123-890a-f012-0123456789ab"
export POWERVSI_2="e5f6a1b2-4567-bcde-3456-cdef01234567"
export APIKEY="@/root/.apikey.json"
export API_TYPE="private"
export SUBNET_NAME="vip-mha-net"
export CIDR="10.40.11.100/30"
export VIP="10.40.11.102"
export JUMBO="true"
Instalación de agentes de recursos SAP HANA
Ejecute el siguiente comando para instalar los agentes de recursos RHEL HA Add-On para SAP HANA System Replication.
dnf install -y resource-agents-sap-hana
Puesta en marcha del sistema SAP HANA
Inicie SAP HANA y compruebe que la replicación del sistema HANA está activa. Para más información, consulte 2.4. Comprobación del estado de replicación del sistema SAP HANA.
En ambos nodos, ejecute los siguientes comandos.
sudo -i -u ${sid}adm -- HDB start
sudo -i -u ${sid}adm -- <<EOT
hdbnsutil -sr_state
HDBSettings.sh systemReplicationStatus.py
EOT
Activación del gancho SAP HANA srConnectionChanged( )
Las versiones recientes de SAP HANA proporcionan ganchos para que SAP HANA pueda enviar notificaciones para ciertos eventos. Para obtener más información, consulte Implementación de un proveedor de HA/DR.
El hook srConnectionChanged( ) mejora la capacidad del cluster para detectar un cambio de estado de HANA System Replication que requiera una acción por parte del cluster. El objetivo es evitar la pérdida y corrupción de datos impidiendo las tomas accidentales.
Activación del gancho srConnectionChanged( ) en todas las instancias de SAP HANA
-
Detener el clúster.
En NODE1, ejecute el siguiente comando.
pcs cluster stop --all
-
Instale la secuencia de comandos de gancho proporcionada por el paquete resource-agents-sap-hana en el directorio
/hana/shared/myHooks
para cada instancia de HANA y establezca la propiedad necesaria.En ambos nodos, ejecute los siguientes comandos.
mkdir -p /hana/shared/myHooks
cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
chown -R ${sid}adm:sapsys /hana/shared/myHooks
-
Actualice el archivo
global.ini
en cada nodo HANA para habilitar el script hook.En ambos nodos, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- <<EOT python \$DIR_INSTANCE/exe/python_support/setParameter.py \ -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/provider=SAPHanaSR \ -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/path=/hana/shared/myHooks \ -set SYSTEM/global.ini/ha_dr_provider_SAPHanaSR/execution_order=1 \ -set SYSTEM/global.ini/trace/ha_dr_saphanasr=info EOT
-
Verifique el archivo modificado.
En ambos nodos, ejecute el siguiente comando.
cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
-
Crear configuraciones sudo para el usuario SAP HANA OS.
Necesita la siguiente configuración sudo para permitir que el script de usuario
${sid}adm
pueda actualizar los atributos del nodo cuando se ejecute el hook srConnectionChanged( ).En ambos nodos, ejecute los siguientes comandos.
Cree un archivo con los alias sudo y las especificaciones de usuario necesarias.
cat >> /etc/sudoers.d/20-saphana << EOT Cmnd_Alias DC1_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias DC1_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC1} -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias DC2_SOK = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias DC2_SFAIL = /usr/sbin/crm_attribute -n hana_${sid}_site_srHook_${DC2} -v SFAIL -t crm_config -s SAPHanaSR ${sid}adm ALL=(ALL) NOPASSWD: DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL Defaults!DC1_SOK, DC1_SFAIL, DC2_SOK, DC2_SFAIL !requiretty EOT
Ajuste los permisos y compruebe si hay errores de sintaxis.
chown root:root /etc/sudoers.d/20-saphana
chmod 0440 /etc/sudoers.d/20-saphana
cat /etc/sudoers.d/20-saphana
visudo -c
Cualquier problema reportado por el comando visudo -c
debe ser corregido.
-
Compruebe que el gancho funciona.
- Reinicie ambas instancias de HANA y compruebe que el script de gancho funciona como se espera.
- Realice una acción para activar el gancho, como detener una instancia de HANA.
- Comprueba si el gancho ha registrado algo en los archivos de rastreo.
En ambos nodos, ejecute los siguientes comandos.
Detenga la instancia de HANA.
sudo -i -u ${sid}adm -- HDB stop
Inicie la instancia de HANA.
sudo -i -u ${sid}adm -- HDB start
Compruebe que el gancho ha registrado algunos mensajes en los archivos de rastreo.
sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_SAPHanaSR.*crm_attribute" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,5,17'
Tras comprobar que los ganchos funcionan, puede reiniciar el clúster de HA.
-
Inicie el clúster.
En NODE1, ejecute los siguientes comandos.
Inicie el clúster.
pcs cluster start --all
Compruebe el estado del clúster.
pcs status --full
Configuración de las propiedades generales del clúster
Para evitar la conmutación por error de los recursos durante las pruebas iniciales y posteriores a la producción, establezca los siguientes valores predeterminados para los parámetros de adherencia de recursos y umbral de migración.
Tenga en cuenta que los valores por defecto no se aplican a los recursos que los anulan con sus propios valores definidos.
En NODE1, ejecute los siguientes comandos.
pcs resource defaults update resource-stickiness=1000
pcs resource defaults update migration-threshold=5000
Creación de un recurso clónico SAPHanaTopology
El recurso SAPHanaTopology recurso recoge el estado y la configuración de SAP HANA System Replication en cada nodo. También inicia y supervisa el SAP HostAgent local, que es necesario para iniciar, detener y supervisar instancias SAP HANA.
En NODE1, ejecute los siguientes comandos.
Cree el SAPHanaTopology recurso.
pcs resource create SAPHanaTopology_${SID}_${INSTNO} SAPHanaTopology \
SID=${SID} InstanceNumber=${INSTNO} \
op start timeout=600 \
op stop timeout=300 \
op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true
Compruebe la configuración y el estado del clúster ejecutando los siguientes comandos.
pcs resource config SAPHanaTopology_${SID}_${INSTNO}
pcs resource config SAPHanaTopology_${SID}_${INSTNO}-clone
pcs status --full
Creación de un recurso SAPHana promocionable
El recurso SAPHana gestiona dos instancias de SAP HANA configuradas como nodos de replicación del sistema HANA.
En NODE1, cree el recurso SAPHana ejecutando el siguiente comando.
pcs resource create SAPHana_${SID}_${INSTNO} SAPHana \
SID=${SID} InstanceNumber=${INSTNO} \
PREFER_SITE_TAKEOVER=true \
DUPLICATE_PRIMARY_TIMEOUT=7200 \
AUTOMATED_REGISTER=false \
op start timeout=3600 \
op stop timeout=3600 \
op monitor interval=61 role="Unpromoted" timeout=700 \
op monitor interval=59 role="Promoted" timeout=700 \
op promote timeout=3600 \
op demote timeout=3600 \
promotable notify=true clone-max=2 clone-node-max=1 interleave=true
Compruebe la configuración y el estado del clúster.
pcs resource config SAPHana_${SID}_${INSTNO}
pcs status --full
Creación de un recurso de clúster de direcciones IP virtuales
Dependiendo del escenario, proceda a una de las siguientes secciones:
- Creación de un recurso de clúster de dirección IP virtual en un entorno de zona única si los nodos de clúster se ejecutan en un único espacio de trabajo Power Virtual Server
- Creación de un recurso de clúster de dirección IP virtual en un entorno de región multizona si los nodos de clúster se ejecutan en espacios de trabajo Power Virtual Server independientes
Creación de un recurso de clúster de direcciones IP virtuales en un entorno de zona única
Utilice la dirección IP reservada para crear un recurso de clúster de dirección IP virtual. Esta dirección IP virtual se utiliza para acceder a la instancia primaria de SAP HANA System Replication.
Cree el recurso de cluster de direcciones IP virtuales con el siguiente comando.
pcs resource create vip_${SID}_${INSTNO} IPaddr2 ip=$VIP
Compruebe el recurso de clúster de dirección IP virtual configurado y el estado del clúster.
pcs resource config vip_${SID}_${INSTNO}
pcs status --full
Continúe con la sección Creación de restricciones de recursos de clúster.
Creación de un recurso de clúster de direcciones IP virtuales en un entorno de regiones multizona
Compruebe que ha completado todos los pasos de la sección Preparación de un clúster RHEL HA Add-On multizona para un recurso de dirección IP virtual.
Ejecute el comando pcs resource describe powervs-subnet
para obtener información sobre los parámetros del agente de recursos.
En NODE1, cree un recurso de clúster powervs-subnet
ejecutando el siguiente comando.
pcs resource create vip_${SID}_${INSTNO} powervs-subnet \
api_key=${APIKEY} \
api_type=${API_TYPE} \
cidr=${CIDR} \
ip=${VIP} \
crn_host_map="${NODE1}:${IBMCLOUD_CRN_1};${NODE2}:${IBMCLOUD_CRN_2}" \
vsi_host_map="${NODE1}:${POWERVSI_1};${NODE2}:${POWERVSI_2}" \
jumbo=${JUMBO} \
region=${CLOUD_REGION} \
subnet_name=${SUBNET_NAME} \
op start timeout=720 \
op stop timeout=300 \
op monitor interval=60 timeout=30
Si establece API_TYPE
en public
, también debe especificar un parámetro proxy
.
Asegúrese de que ambas instancias de servidor virtual del clúster tienen el estado Active
y el estado de salud OK
antes de ejecutar el comando pcs resource config
.
Compruebe el recurso de dirección IP virtual configurado y el estado del clúster.
pcs resource config vip_${SID}_${INSTNO}
Salida de ejemplo:
# pcs resource config vip_MHA_00
Resource: vip_MHA_00 (class=ocf provider=heartbeat type=powervs-subnet)
Attributes: vip_MHA_00-instance_attributes
api_key=@/root/.apikey.json
api_type=private
cidr=10.40.11.100/30
crn_host_map=cl-mha-1:crn:v1:bluemix:public:power-iaas:eu-de-2:**********************************:************************************::;cl-mha-2:crn:v1:bluemix:public:power-iaas:eu-
de-1:**********************************:************************************::
ip=10.40.11.102
jumbo=true
proxy=http://10.30.40.4:3128
region=eu-de
subnet_name=vip-mha-net
vsi_host_map=cl-mha-1:************************************;cl-mha-2:************************************
Operations:
monitor: res_vip_MHA_00-monitor-interval-60
interval=60
timeout=60
start: res_vip_MHA_00-start-interval-0s
interval=0s
timeout=720
stop: res_vip_MHA_00-stop-interval-0s
interval=0s
timeout=300
pcs status --full
El siguiente ejemplo es una salida de muestra de un clúster de Replicación del Sistema SAP HANA en una configuración de región multizona.
# pcs status --full
Cluster name: SAP_MHA
Status of pacemakerd: 'Pacemaker is running' (last updated 2024-07-31 11:37:49 +02:00)
Cluster Summary:
* Stack: corosync
* Current DC: cl-mha-2 (2) (version 2.1.5-9.el9_2.4-a3f44794f94) - partition with quorum
* Last updated: Wed Jul 31 11:37:50 2024
* Last change: Wed Jul 31 11:37:31 2024 by root via crm_attribute on cl-mha-1
* 2 nodes configured
* 7 resource instances configured
Node List:
* Node cl-mha-1 (1): online, feature set 3.16.2
* Node cl-mha-2 (2): online, feature set 3.16.2
Full List of Resources:
* fence_node1 (stonith:fence_ibm_powervs): Started cl-mha-1
* fence_node2 (stonith:fence_ibm_powervs): Started cl-mha-2
* Clone Set: SAPHanaTopology_MHA_00-clone [SAPHanaTopology_MHA_00]:
* SAPHanaTopology_MHA_00 (ocf:heartbeat:SAPHanaTopology): Started cl-mha-2
* SAPHanaTopology_MHA_00 (ocf:heartbeat:SAPHanaTopology): Started cl-mha-1
* Clone Set: SAPHana_MHA_00-clone [SAPHana_MHA_00] (promotable):
* SAPHana_MHA_00 (ocf:heartbeat:SAPHana): Unpromoted cl-mha-2
* SAPHana_MHA_00 (ocf:heartbeat:SAPHana): Promoted cl-mha-1
* vip_MHA_00 (ocf:heartbeat:powervs-subnet): Started cl-mha-1
Node Attributes:
* Node: cl-mha-1 (1):
* hana_mha_clone_state : PROMOTED
* hana_mha_op_mode : logreplay
* hana_mha_remoteHost : cl-mha-2
* hana_mha_roles : 4:P:master1:master:worker:master
* hana_mha_site : SiteA
* hana_mha_sra : -
* hana_mha_srah : -
* hana_mha_srmode : syncmem
* hana_mha_sync_state : PRIM
* hana_mha_version : 2.00.075.00
* hana_mha_vhost : cl-mha-1
* lpa_mha_lpt : 1722418651
* master-SAPHana_MHA_00 : 150
* Node: cl-mha-2 (2):
* hana_mha_clone_state : DEMOTED
* hana_mha_op_mode : logreplay
* hana_mha_remoteHost : cl-mha-1
* hana_mha_roles : 4:S:master1:master:worker:master
* hana_mha_site : SiteB
* hana_mha_sra : -
* hana_mha_srah : -
* hana_mha_srmode : syncmem
* hana_mha_sync_state : SOK
* hana_mha_version : 2.00.075.00
* hana_mha_vhost : cl-mha-2
* lpa_mha_lpt : 30
* master-SAPHana_MHA_00 : 100
Migration Summary:
Tickets:
PCSD Status:
cl-mha-1: Online
cl-mha-2: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Continúe con la sección Creación de restricciones de recursos de clúster.
Creación de restricciones de recursos del clúster
Asegúrese de que SAPHanaTopology antes de iniciar los recursos SAPHana.
La dirección IP virtual debe estar presente en el nodo donde se ejecuta el recurso primario de "SAPHana".
-
Cree una restricción de recursos para iniciar "SAPHanaTopology" antes que "SAPHana". Esta restricción impone el orden de inicio de estos recursos.
En NODE1, utilice el siguiente comando para crear la restricción de orden SAPHanaTopology restricción de orden:
pcs constraint order SAPHanaTopology_${SID}_${INSTNO}-clone \ then SAPHana_${SID}_${INSTNO}-clone symmetrical=false
Comprueba la configuración.
pcs constraint
-
Cree una restricción de recursos para colocar la dirección IP virtual con la primaria. Esta restricción coloca el recurso de dirección IP virtual con el recurso SAPHana que fue promovido como primario.
En NODE1, ejecute el siguiente comando para crear la restricción de colocación de direcciones IP virtuales.
pcs constraint colocation add vip_${SID}_${INSTNO} \ with Promoted SAPHana_${SID}_${INSTNO}-clone 2000
Compruebe la configuración y el estado del clúster.
pcs constraint
Salida de ejemplo:
# pcs constraint Location Constraints: Ordering Constraints: start SAPHanaTopology_HDB_00-clone then start SAPHana_HDB_00-clone (kind:Mandatory) (non-symmetrical) Colocation Constraints: vip_HDB_00 with SAPHana_HDB_00-clone (score:2000) (rsc-role:Started) (with-rsc-role:Promoted) Ticket Constraints:
Compruebe el estado del clúster.
pcs status --full
En el nodo de clúster promovido, compruebe que la dirección IP del servicio de clúster está activa.
ip addr show
Activación del gancho SAP HANA srServiceStateChanged( ) (opcional)
SAP HANA dispone de funciones integradas para controlar su indexserver
. En caso de problema, SAP HANA intenta recuperarse automáticamente deteniendo y reiniciando el proceso. Para detener el proceso o limpiarlo después de un fallo,
el núcleo Linux debe liberar toda la memoria asignada por el proceso. En el caso de bases de datos grandes, esta limpieza puede llevar mucho tiempo. Durante este tiempo, SAP HANA sigue funcionando y aceptando nuevas solicitudes de clientes.
Como resultado, la replicación del sistema SAP HANA puede desincronizarse. Si se produce otro error en la instancia SAP HANA antes de que finalice el reinicio y la recuperación de indexserver
, la coherencia de los datos corre
peligro.
El script ChkSrv.py
para el hook srServiceStateChanged()
reacciona ante tal situación y puede detener toda la instancia SAP HANA para una recuperación más rápida. Si automated failover
está habilitado
en el clúster, y el nodo secundario se encuentra en un estado saludable, se inicia una operación de toma de control. En caso contrario, la recuperación debe continuar localmente, pero se acelera mediante el reinicio forzado de la instancia
SAP HANA.
El hook SAP HANA srServiceStateChanged()
está disponible con la versión resource-agents-sap-hana
0.162.3 y posteriores.
El script gancho analiza los eventos de la instancia, aplica filtros a los detalles del evento y desencadena acciones basadas en los resultados. Distingue entre un proceso SAP HANA indexserver
que es detenido y reiniciado por
SAP HANA y el proceso que se detiene durante el apagado de una instancia.
Dependiendo de la configuración del parámetro action_on_lost
, el gancho realiza diferentes acciones:
- Ignorar
- Esta acción simplemente registra los eventos y la información de la decisión en un archivo de registro.
- Detener
- Esta acción desencadena una parada graceful de la instancia SAP HANA mediante el comando sapcontrol.
- Destruir
- Esta acción activa el comando HDB kill-
<signal>
con una señal por defecto 9. La señal se puede configurar.
Tanto la acción de parar como la de matar dan como resultado una instancia de SAP HANA parada, la acción de matar es ligeramente más rápida.
Activación del gancho srServiceStateChanged( ) en todas las instancias de SAP HANA
El hook srServiceStateChanged()
puede añadirse mientras SAP HANA se está ejecutando en ambos nodos.
-
Para cada instancia de HANA, instale el script de gancho que proporciona el paquete resource-agents-sap-hana en el directorio
/hana/shared/myHooks
y establezca la propiedad necesaria.En ambos nodos, ejecute los siguientes comandos.
cp /usr/share/SAPHanaSR/srHook/ChkSrv.py /hana/shared/myHooks
chown ${sid}adm:sapsys /hana/shared/myHooks/ChkSrv.py
-
Actualice el archivo
global.ini
en cada nodo SAP HANA para habilitar el script hook.En ambos nodos, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- <<EOT python \$DIR_INSTANCE/exe/python_support/setParameter.py \ -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/provider=ChkSrv \ -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/path=/hana/shared/myHooks \ -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/execution_order=2 \ -set SYSTEM/global.ini/ha_dr_provider_ChkSrv/action_on_lost=stop \ -set SYSTEM/global.ini/trace/ha_dr_chksrv=info EOT
El parámetro
action_on_lost
en este ejemplo se establece enstop
, el ajuste por defecto esignore
. Puede configurar opcionalmente los parámetrosstop_timeout
(por defecto:20
segundos) ykill_signal
(por defecto:9
). -
Activar el gancho
ChkSrv.py
En ambos nodos, ejecute el siguiente comando para recargar los proveedores HA-DR.
sudo -i -u ${sid}adm -- hdbnsutil -reloadHADRProviders
-
Compruebe que el gancho ha registrado algunos mensajes en los archivos de rastreo.
En ambos nodos, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- sh -c 'grep "ha_dr_ChkSrv" $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_* | cut -d" " -f2,3,6-'
Registro automático de una instancia secundaria
Debe ajustar el parámetro AUTOMATED_REGISTER
en función de sus necesidades operativas. Si desea mantener la capacidad de volver al estado de la instancia primaria anterior SAP HANA, entonces AUTOMATED_REGISTER=false
evita un registro automático del primario anterior como nuevo secundario.
Si experimenta un problema con los datos después de una toma de control desencadenada por el clúster, puede revertirlo manualmente si AUTOMATED_REGISTER
está configurado en false
.
Si AUTOMATED_REGISTER
se establece en true
, la instancia primaria anterior SAP HANA se registra automáticamente como secundaria, y no puede activarse en su historial anterior. La ventaja de AUTOMATED_REGISTER=true
es que la capacidad de alta disponibilidad se restablece automáticamente tras la reaparición del nodo averiado en el clúster.
Por ahora, se recomienda mantener AUTOMATED_REGISTER
en el valor predeterminado false
hasta que el clúster esté completamente probado y se verifique que los escenarios de conmutación por error funcionan como se espera.
El comando pcs resource update
se utiliza para modificar los atributos de los recursos y pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true
establece el atributo en true
.
Pruebas del clúster de replicación del sistema SAP HANA
Es fundamental probar a fondo la configuración del clúster para asegurarse de que funciona correctamente. La siguiente información proporciona algunos ejemplos de escenarios de prueba de conmutación por error, pero no es una lista completa de escenarios de prueba.
Por ejemplo, la descripción de cada caso de prueba incluye la siguiente información.
- Componente que se está probando
- Descripción de la prueba
- Requisitos previos y estado del clúster antes de iniciar la prueba de conmutación por error
- Procedimiento de ensayo
- Comportamiento y resultados esperados
- Procedimiento de recuperación
Prueba 1 - Prueba de un fallo de la instancia primaria de la base de datos
Utilice la siguiente información para probar el fallo de la instancia de base de datos primaria.
Prueba 1 - Descripción
Simule una caída de la instancia primaria de la base de datos HANA que se ejecuta en NODE1.
Prueba 1 - Requisitos previos
- Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
- Ambos nodos del clúster están activos.
- Cluster que se inicia en NODE1 y NODE2.
- Cluster Resource
SAPHana_${SID}_${INSTNO}
que está configurado conAUTOMATED_REGISTER=false
. - Compruebe el estado de la replicación del sistema SAP HANA:
- La base de datos primaria SAP HANA se ejecuta en NODE1
- La base de datos secundaria SAP HANA se ejecuta en NODE2
- La replicación del sistema HANA está activada y sincronizada
Prueba 1 - Procedimiento de prueba
Crash SAP HANA primaria mediante el envío de una señal SIGKILL como el usuario ${sid}adm
.
En NODE1, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- HDB kill-9
Prueba 1 - Comportamiento esperado
- SAP HANA la instancia primaria en NODE1 se bloquea.
- El clúster detecta la base de datos HANA primaria detenida y marca el recurso como
failed
. - El clúster promueve la base de datos HANA secundaria en NODE2 para que asuma el papel de la nueva primaria.
- El clúster libera la dirección IP virtual en NODE1, y la adquiere en el nuevo primario en NODE2.
- Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.
Prueba 1 - Procedimiento de recuperación
Como el recurso de cluster SAPHana_${SID}_${INSTNO}
está configurado con AUTOMATED_REGISTER=false
, el cluster no reinicia la base de datos HANA fallida, y no la registra contra el nuevo primario. Lo que significa
que el estado en el nuevo primario ( NODE2 ) también muestra el secundario en estado 'CONNECTION TIMEOUT'.
Para volver a registrar el primario anterior como nuevo secundario utilice los siguientes comandos.
En NODE1, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- <<EOT
hdbnsutil -sr_register \
--name=${DC1} \
--remoteHost=${NODE2} \
--remoteInstance=00 \
--replicationMode=sync \
--operationMode=logreplay \
--online
EOT
Verificar el estado de replicación del sistema:
sudo -i -u ${sid}adm -- <<EOT
hdbnsutil -sr_state
HDBSettings.sh systemReplicationStatus.py
EOT
Tras el registro manual y la actualización de recursos, la nueva instancia secundaria se reinicia y aparece en estado sincronizado (SOK
).
En NODE1, ejecute el siguiente comando.
pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full
Prueba 2 - Prueba de un fallo del nodo que ejecuta la base de datos primaria
Utilice la siguiente información para probar el fallo del nodo que está ejecutando la base de datos primaria.
Prueba 2 - Descripción
Simule una caída del nodo que ejecuta la base de datos HANA primaria.
Prueba 2 - Preparación
Asegúrese de que el recurso de clúster SAPHana_${SID}_${INSTNO}
está configurado con AUTOMATED_REGISTER=true
.
En NODE1, ejecute el siguiente comando.
pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true
pcs resource config SAPHana_${SID}_${INSTNO}
Prueba 2 - Requisitos previos
- Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
- Ambos nodos están activos.
- El clúster se inicia en NODE1 y NODE2.
- Compruebe el estado de la replicación del sistema SAP HANA.
- La base de datos primaria SAP HANA se ejecuta en NODE2
- La base de datos secundaria SAP HANA se ejecuta en NODE1
- La replicación del sistema HANA está activada y sincronizada
Prueba 2 - Procedimiento de prueba
Bloquea el sistema primario en NODE2 enviando una petición de bloqueo del sistema.
En NODE2, ejecute el siguiente comando.
sync; echo c > /proc/sysrq-trigger
Prueba 2 - Comportamiento esperado
- NODE2 se apaga.
- El clúster detecta el nodo que ha fallado y establece su estado en
OFFLINE
. - El clúster promueve la base de datos HANA secundaria en NODE1 para que asuma el papel de la nueva primaria.
- El clúster adquiere la dirección IP virtual en NODE1 en el nuevo primario.
- Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.
Prueba 2 - Procedimiento de recuperación
Acceda a la consola IBM Cloud® e inicie la instancia NODE2. Espere hasta que NODE2 vuelva a estar disponible y, a continuación, reinicie el marco del clúster.
En NODE2, ejecute el siguiente comando.
pcs cluster start
pcs status --full
Como el recurso de clúster SAPHana_${SID}_${INSTNO}
está configurado con AUTOMATED_REGISTER=true
, SAP HANA se reinicia cuando NODE2 se reincorpora al clúster y el antiguo primario se vuelve a registrar como secundario.
Prueba 3 - Prueba de un fallo de la instancia secundaria de la base de datos
Utilice la siguiente información para probar el fallo de la instancia de base de datos secundaria.
Prueba 3 - Descripción
Simular una caída de la base de datos secundaria HANA.
Prueba 3 - Requisitos previos
- Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
- Ambos nodos están activos.
- El clúster se inicia en NODE1 y NODE2.
- Cluster Resource
SAPHana_${SID}_${INSTNO}
se configura conAUTOMATED_REGISTER=true
. - Compruebe el estado de la replicación del sistema SAP HANA:
- La base de datos primaria SAP HANA se ejecuta en NODE1
- La base de datos secundaria SAP HANA se ejecuta en NODE2
- La replicación del sistema HANA está activada y sincronizada
Prueba 3 - Procedimiento de prueba
Crash SAP HANA secundaria mediante el envío de una señal SIGKILL como el usuario ${sid}adm
.
En NODE2, ejecute el siguiente comando.
sudo -i -u ${sid}adm -- HDB kill-9
Prueba 3 - Comportamiento esperado
- SAP HANA secundaria en NODE2 accidentes.
- El clúster detecta la base de datos HANA secundaria detenida y marca el recurso como
failed
. - El clúster reinicia la base de datos HANA secundaria.
- El clúster detecta que la replicación del sistema vuelve a estar sincronizada.
Prueba 3 - Procedimiento de recuperación
Espere hasta que la instancia secundaria de HANA se inicie y sincronice de nuevo (SOK
), luego limpie las acciones de recursos fallidas como se muestra en pcs status
.
En NODE2, ejecute el siguiente comando.
pcs resource refresh SAPHana_${SID}_${INSTNO}
pcs status --full
Prueba 4 - Prueba de traslado manual de un recurso SAPHana a otro nodo
Utilice la siguiente información para probar el traslado manual de un recurso SAPHana a otro nodo.
Prueba 4 - Descripción
Utilice los comandos de clúster para mover la instancia primaria al otro nodo con fines de mantenimiento.
Prueba 4 - Requisitos previos
- Un clúster funcional RHEL HA Add-On de dos nodos para la replicación de sistemas HANA.
- Ambos nodos están activos.
- El clúster se inicia en NODE1 y NODE2.
- Cluster Resource
SAPHana_${SID}_${INSTNO}
se configura conAUTOMATED_REGISTER=true
. - Compruebe el estado de la replicación del sistema SAP HANA:
- La base de datos primaria SAP HANA se ejecuta en NODE1
- La base de datos secundaria SAP HANA se ejecuta en NODE2
- La replicación del sistema HANA está activada y sincronizada
Prueba 4 - Procedimiento de prueba
Mueva el SAP HANA primario a otro nodo utilizando el comando pcs resource move
.
En NODE1, ejecute el siguiente comando.
pcs resource move SAPHana_${SID}_${INSTNO}-clone
Prueba 4 - Comportamiento esperado
- El clúster crea restricciones de ubicación para mover el recurso.
- El clúster activa una transferencia a la base de datos HANA secundaria.
- Si una aplicación, como SAP NetWeaver, se conecta a una base de datos tenant de SAP HANA, la aplicación se reconecta automáticamente al nuevo primario.
Prueba 4 - Procedimiento de recuperación
Las restricciones de ubicación creadas automáticamente deben eliminarse para permitir la conmutación por error automática en el futuro.
Espere hasta que la instancia primaria de HANA esté activa y elimine las restricciones.
El clúster registra e inicia la base de datos HANA como una nueva instancia secundaria.
En NODE1, ejecute el siguiente comando.
pcs constraint
pcs resource clear SAPHana_${SID}_${INSTNO}-clone
pcs constraint
pcs status --full