Compartir vía


Alta disponibilidad del escalado vertical de SAP HANA con Azure NetApp Files en RHEL

En este artículo se describe cómo configurar la replicación del sistema de SAP HANA en una implementación de escalado vertical, cuando los sistemas de archivos de HANA se montan mediante NFS con Azure NetApp Files. En las configuraciones de ejemplo y los comandos de instalación, se utiliza el número de instancia 03 y el identificador del sistema de HANA HN1. La replicación del sistema de SAP HANA consta de un nodo principal y al menos un nodo secundario.

Si los pasos de este documento se marcan con los siguientes prefijos, el significado es el siguiente:

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

Requisitos previos

Lea primero las notas y los documentos de SAP siguientes:

Información general

Tradicionalmente, en un entorno de escalado vertical, todos los sistemas de archivos para SAP HANA se montan desde el almacenamiento local. La configuración de alta disponibilidad (HA) de replicación del sistema de SAP HANA en Red Hat Enterprise Linux se publica en Configuración de la replicación del sistema de SAP HANA en RHEL.

Para lograr la alta disponibilidad de SAP HANA de un sistema de escalado vertical en recursos compartidos de NFS de Azure NetApp Files, necesitamos una configuración de recursos adicional en el clúster, para que los recursos de HANA se recuperen, cuando un nodo pierde el acceso a los recursos compartidos de NFS en Azure NetApp Files. El clúster administra los montajes NFS, lo que le permite supervisar el estado de los recursos. Se aplican las dependencias entre los montajes del sistema de archivos y los recursos de SAP HANA.

Diagrama que muestra el escalado vertical de alta disponibilidad de SAP HANA en Azure NetApp Files.

Los sistemas de archivos de SAP HANA se montan en recursos compartidos de NFS mediante Azure NetApp Files en cada nodo. Los sistemas de archivos /hana/data, /hana/log y /hana/shared son únicos para cada nodo.

Montado en el nodo 1 (hanadb1):

  • 10.32.2.4:/hanadb1-data-mnt00001 en /hana/data
  • 10.32.2.4:/hanadb1-log-mnt00001 en /hana/log
  • 10.32.2.4:/hanadb1-shared-mnt00001 en /hana/shared

Montado en el nodo 2 (hanadb2):

  • 10.32.2.4:/hanadb2-data-mnt00001 en /hana/data
  • 10.32.2.4:/hanadb2-log-mnt00001 en /hana/log
  • 10.32.2.4:/hanadb2-shared-mnt00001 en /hana/shared

Nota:

Los sistemas de archivos /hana/shared, /hana/data y /hana/log no se comparten entre los dos nodos. Cada nodo del clúster tiene sus propios sistemas de archivos independientes.

En la configuración de la replicación del sistema de SAP HANA se usa un nombre de host virtual dedicado y direcciones IP virtuales. En Azure, se requiere un equilibrador de carga para usar una dirección IP virtual. La configuración que se muestra aquí tiene un equilibrador de carga con:

  • Dirección IP de front-end: 10.32.0.10 para hn1-db
  • Puerto de sondeo: 62503

Configuración de la infraestructura de Azure NetApp Files

Antes de continuar con la configuración de la infraestructura de Azure NetApp Files, familiarícese con la documentación correspondiente.

Azure NetApp Files está disponible en varias regiones de Azure. Compruebe si la región de Azure seleccionada ofrece Azure NetApp Files.

Para obtener información sobre la disponibilidad de Azure NetApp Files según la región de Azure, consulte Disponibilidad de Azure NetApp Files por región de Azure.

Consideraciones importantes

A medida que va a crear volúmenes de Azure NetApp Files para sistemas de escalado vertical de SAP HANA, tenga en cuenta las consideraciones importantes documentadas en Volúmenes de NFS v4.1 en Azure NetApp Files para SAP HANA.

Dimensionamiento de la base de datos HANA en Azure NetApp Files

El rendimiento de un volumen de Azure NetApp Files es una función del tamaño del volumen y del nivel de servicio, como se documenta en Nivel de servicio para Azure NetApp Files.

Al diseñar la infraestructura para SAP HANA en Azure con Azure NetApp Files, tenga en cuenta las recomendaciones de Volúmenes de NFS v4.1 en Azure NetApp Files para SAP HANA.

La configuración de este artículo se presenta con volúmenes sencillos de Azure NetApp Files.

Importante

En el caso de los sistemas de producción, donde el rendimiento es una clave, se recomienda evaluar y considerar el uso de un Grupo de volúmenes de aplicación de Azure NetApp Files para SAP HANA.

Implementación de recursos de Azure NetApp Files

En las siguientes instrucciones se supone que ya ha implementado la red virtual de Azure. Los recursos de Azure NetApp Files y las VM en las que esos recursos se montarán se deben implementar en la misma red virtual de Azure o en redes virtuales de Azure emparejadas.

  1. Cree una cuenta de NetApp en la región de Azure seleccionada. Para ello, siga las instrucciones en Creación de una cuenta de NetApp.

  2. Configure el grupo de capacidad de Azure NetApp Files según disponibles en Configuración en un grupo de capacidad de Azure NetApp Files.

    La arquitectura de HANA que se muestra en este artículo utiliza un único grupo de capacidad de Azure NetApp Files, el nivel de servicio Ultra. Para las cargas de trabajo HANA en Azure, se recomienda usar el nivel de servicio Ultra o Premium de Azure NetApp Files.

  3. Delegue una subred en Azure NetApp Files tal como se describe en las instrucciones de Delegación de una subred en Azure NetApp Files.

  4. Implemente los volúmenes de Azure NetApp Files según las instrucciones de Creación de un volumen de NFS para Azure NetApp Files.

    Cuando vaya a implementar los volúmenes, asegúrese de seleccionar la versión NFSv 4.1. Implemente los volúmenes en la subred de Azure NetApp Files designada. Las direcciones IP de los volúmenes de Azure NetApp se asignan automáticamente.

    Tenga en cuenta que los recursos de Azure NetApp Files y las VM de Azure deben estar en la misma red virtual de Azure o en redes virtuales de Azure emparejadas. Por ejemplo, hanadb1-data-mnt00001 y hanadb1-log-mnt00001 son los nombres de volumen y nfs://10.32.2.4/hanadb1-data-mnt00001 y nfs://10.32.2.4/hanadb1-log-mnt00001 son las rutas de acceso de archivo para los volúmenes de Azure NetApp Files.

    En hanadb1:

    • Volumen hanadb1-data-mnt00001 (nfs://10.32.2.4:/hanadb1-data-mnt00001)
    • Volumen hanadb1-log-mnt00001 (nfs://10.32.2.4:/hanadb1-log-mnt00001)
    • Volumen hanadb1-shared-mnt00001 (nfs://10.32.2.4:/hanadb1-shared-mnt00001)

    En hanadb2:

    • Volumen hanadb2-data-mnt00001 (nfs://10.32.2.4:/hanadb2-data-mnt00001)
    • Volumen hanadb2-log-mnt00001 (nfs://10.32.2.4:/hanadb2-log-mnt00001)
    • Volumen hanadb2-shared-mnt00001 (nfs://10.32.2.4:/hanadb2-shared-mnt00001)

Nota:

Todos los comandos que se van a montar /hana/shared en este artículo se presentan para volúmenes de NFSv4.1 /hana/shared. Si ha implementado los volúmenes de /hana/shared como volúmenes de NFSv3, no olvide ajustar los comandos de montaje para /hana/shared para NFSv3.

Preparación de la infraestructura

Azure Marketplace contiene imágenes calificadas para SAP HANA con el complemento de alta disponibilidad, que puede usar para implementar nuevas máquinas virtuales mediante varias versiones de Red Hat.

Implementación manual de VM de Linux mediante Azure Portal

En este documento se supone que ya ha implementado un grupo de recursos, una red virtual de Azure y una subred.

Implemente máquinas virtuales para SAP HANA. Elija una imagen de RHEL adecuada que sea compatible con el sistema HANA. Puede implementar una máquina virtual en cualquiera de las opciones de disponibilidad: conjunto de escalado de máquinas virtuales, zona de disponibilidad o conjunto de disponibilidad.

Importante

Asegúrese de que el sistema operativo que selecciona está certificado por SAP para SAP HANA en los tipos específicos de máquinas virtuales que tiene previsto usar en su implementación. Puede buscar los tipos de máquina virtual certificados por SAP HANA y sus versiones del sistema operativo en Plataformas IaaS certificadas para SAP HANA. Asegúrese de consultar los detalles del tipo de máquina virtual para obtener la lista completa de versiones de SO compatibles con SAP HANA para el tipo de máquina virtual específico.

Configurar Azure Load Balancer

Durante la configuración de la máquina virtual, tiene una opción para crear o seleccionar salir del equilibrador de carga en la sección de redes. Siga estos pasos para configurar el equilibrador de carga estándar para la configuración de alta disponibilidad de la base de datos de HANA.

Siga los pasos descritos en Creación de un equilibrador de carga para configurar un equilibrador de carga estándar para un sistema SAP de alta disponibilidad mediante Azure Portal. Durante la configuración del equilibrador de carga, tenga en cuenta los siguientes puntos:

  1. Configuración de IP de front-end: cree una dirección IP de front-end. Seleccione el mismo nombre de red virtual y subred que las máquinas virtuales de la base de datos.
  2. Grupo de back-end: cree un grupo de back-end y agregue máquinas virtuales de base de datos.
  3. Reglas de entrada: cree una regla de equilibrio de carga. Siga los mismos pasos para ambas reglas de equilibrio de carga.
    • Dirección IP de front-end: seleccione una dirección IP de front-end.
    • Grupo de back-end: seleccione un grupo de back-end.
    • Puertos de alta disponibilidad: seleccione esta opción.
    • Protocolo: seleccione TCP.
    • Sondeo de estado: cree un sondeo de estado con los detalles siguientes:
      • Protocolo: seleccione TCP.
      • Puerto: por ejemplo, 625<instance-no.>.
      • Intervalo: escriba 5.
      • Umbral de sondeo: escriba 2.
    • Tiempo de espera de inactividad (minutos): Escriba 30.
    • Habilitar IP flotante: seleccione esta opción.

Nota:

No se respeta la propiedad de configuración del sondeo de estado numberOfProbes, también conocida como Umbral incorrecto en el portal. Para controlar el número de sondeos consecutivos correctos o erróneos, establezca la propiedad probeThreshold en 2. Actualmente, no es posible establecer esta propiedad mediante Azure Portal, por lo que debe usar la CLI de Azure o el comando de PowerShell.

Para obtener más información sobre los puertos necesarios para SAP HANA, lea el capítulo Connections to Tenant Databases (Conexiones a las bases de datos de inquilino) de la guía SAP HANA Tenant Databases (Bases de datos de inquilino de SAP HANA) o la nota de SAP 2388694.

Nota:

Cuando las máquinas virtuales sin direcciones IP públicas se colocan en el grupo de back-end de una instancia interna (sin dirección IP pública) de Azure Load Balancer Estándar, no hay conectividad saliente a Internet, a menos que se realice una configuración adicional para permitir el enrutamiento a puntos de conexión públicos. Para más información sobre cómo lograr la conectividad saliente, consulte Conectividad de punto de conexión público para máquinas virtuales mediante Azure Load Balancer Estándar en escenarios de alta disponibilidad de SAP.

Importante

No habilite las marcas de tiempo TCP en VM de Azure que se encuentren detrás de Azure Load Balancer. La habilitación de las marcas de tiempo de TCP podría provocar un error en los sondeos de estado. Establezca el parámetro net.ipv4.tcp_timestamps a 0. Para obtener más información, consulte Sondeos de estado de Load Balancer y Nota de SAP 2382421.

Montaje de los volúmenes de Azure NetApp Files

  1. [A] Cree puntos de montaje para los volúmenes de bases de datos HANA.

    sudo mkdir -p /hana/data
    sudo mkdir -p /hana/log
    sudo mkdir -p /hana/shared
    
  2. [A] Compruebe la configuración del dominio NFS. Asegúrese de que el dominio esté configurado como dominio predeterminado de Azure NetApp Files, es decir, defaultv4iddomain.com, y de que la asignación se haya establecido en nobody.

    sudo cat /etc/idmapd.conf
    

    Ejemplo:

    [General]
    Domain = defaultv4iddomain.com
    [Mapping]
    Nobody-User = nobody
    Nobody-Group = nobody
    

    Importante

    Asegúrese de establecer el dominio de NFS en /etc/idmapd.conf en la máquina virtual para que coincida con la configuración de dominio predeterminada en Azure NetApp Files: defaultv4iddomain.com. Si hay un error de coincidencia entre la configuración de dominio en el cliente NFS (es decir, la máquina virtual) y el servidor NFS (es decir, la configuración de Azure NetApp Files), los permisos para los archivos de los volúmenes de Azure NetApp Files que se montan en las máquinas virtuales se muestran como nobody.

  3. [1] Monte los volúmenes específicos del nodo en node1 (hanadb1).

    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
    
  4. [2] Monte los volúmenes específicos del nodo en node2 (hanadb2).

    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
    
  5. [A] Compruebe que todos los volúmenes de HANA están montados con la versión del protocolo NFS NFSv4.

    sudo nfsstat -m
    

    Compruebe que la marca vers está establecida en 4.1. Ejemplo de hanadb1:

    /hana/log from 10.32.2.4:/hanadb1-log-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
    /hana/data from 10.32.2.4:/hanadb1-data-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
    /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
    
  6. [A] Compruebe nfs4_disable_idmapping. Debe establecerse en S. Para crear la estructura de directorios donde se encuentra nfs4_disable_idmapping, ejecute el comando mount. No se puede crear manualmente el directorio en /sys/modules porque el acceso está reservado para el kernel y los controladores.

    Compruebe nfs4_disable_idmapping.

    sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
    

    Si necesita establecer nfs4_disable_idmapping en:

    sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
    

    Haga que la configuración sea permanente.

    sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    

    Para obtener más información sobre cómo cambiar el parámetro nfs_disable_idmapping, consulte Base de conocimiento de Red Hat.

Instalación de SAP HANA

  1. [A] Configurar la resolución de nombres de host para todos los hosts.

    Puede usar un servidor DNS o modificar el archivo /etc/hosts en todos los nodos. En este ejemplo se muestra cómo usar el archivo /etc/hosts. Reemplace la dirección IP y el nombre de host en los siguientes comandos:

    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.

    10.32.0.4   hanadb1
    10.32.0.5   hanadb2
    
  2. [A] Prepare el sistema operativo para ejecutar SAP HANA en Azure NetApp con NFS, tal como se describe en la Nota de SAP 3024346: Configuración del kernel de Linux para NetApp NFS. Cree el archivo de configuración /etc/sysctl.d/91-NetApp-HANA.conf para las opciones de configuración de NetApp.

    sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
    

    Agregue las siguientes entradas en el archivo de configuración.

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.ipv4.tcp_rmem = 4096 131072 16777216
    net.ipv4.tcp_wmem = 4096 16384 16777216
    net.core.netdev_max_backlog = 300000 
    net.ipv4.tcp_slow_start_after_idle=0 
    net.ipv4.tcp_no_metrics_save = 1
    net.ipv4.tcp_moderate_rcvbuf = 1
    net.ipv4.tcp_window_scaling = 1    
    net.ipv4.tcp_sack = 1
    
  3. [A] Cree el archivo de configuración /etc/sysctl.d/ms-az.conf con más opciones de optimización.

    sudo vi /etc/sysctl.d/ms-az.conf
    

    Agregue las siguientes entradas en el archivo de configuración.

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv4.tcp_max_syn_backlog = 16348
    net.ipv4.conf.all.rp_filter = 0
    sunrpc.tcp_slot_table_entries = 128
    vm.swappiness=10
    

    Sugerencia

    Evite establecer net.ipv4.ip_local_port_range y net.ipv4.ip_local_reserved_ports explícitamente en los archivos de configuración sysctl para permitir que el agente de host de SAP administre los intervalos de puertos. Para más información, consulte la Nota de SAP 2382421.

  4. [A] Ajuste la configuración de sunrpc, como se recomienda en la Nota de SAP 3024346 - Configuración del kernel de Linux para NetApp NFS.

    sudo vi /etc/modprobe.d/sunrpc.conf
    

    Inserte la línea siguiente:

    options sunrpc tcp_max_slot_table_entries=128
    
  5. [A] Realice la configuración del sistema operativo RHEL para HANA.

    Configure el sistema operativo como se describe en las notas de SAP siguientes en función de la versión de RHEL:

  6. [A] Instale SAP HANA.

    A partir de HANA 2.0 SPS 01, MDC es la opción predeterminada. Al instalar el sistema HANA, SYSTEMDB y un inquilino con el mismo SID se crean juntos. En algunos casos, no se recomienda el inquilino predeterminado. Si no desea crear un inquilino inicial junto con la instalación, puede seguir la Nota de SAP 2629711.

    Ejecute el programa hdblcm del DVD de HANA. Escriba los siguientes valores en el símbolo del sistema:

    1. Elegir instalación: escriba 1 (para instalar).
    2. Seleccione más componentes para la instalación: escriba 1.
    3. Escriba Ruta de instalación [/hana/shared]: seleccione Entrar para aceptar el valor predeterminado.
    4. Escriba Nombre de host local [..]: seleccione Entrar para aceptar el valor predeterminado. ¿Desea agregar hosts adicionales al sistema? (y/n) [n]: n.
    5. Escriba Id. de sistema de SAP HANA: escriba HN1.
    6. Escriba Número de instancia [00]: escriba 03.
    7. Seleccione Modo de base de datos / Escribir índice [1]: seleccione Entrar para aceptar el valor predeterminado.
    8. Seleccione Uso del sistema / Escribir índice [4]: Escriba 4 (para personalizar).
    9. Escriba Ubicación de volúmenes de datos [/hana/data]: seleccione Entrar para aceptar el valor predeterminado.
    10. Escriba Ubicación de volúmenes de registro [/hana/log]: seleccione Entrar para aceptar el valor predeterminado.
    11. ¿Restringir la asignación de memoria máxima? [n]: Seleccione Entrar para aceptar el valor predeterminado.
    12. Escriba Nombre de host del certificado para el host "..." [...]: seleccione Entrar para aceptar el valor predeterminado.
    13. Escriba Contraseña de usuario del agente de host de SAP (sapadm): escriba la contraseña de usuario del agente de host.
    14. Confirme la Contraseña de usuario del agente de host de SAP (sapadm): vuelva a escribir la contraseña de usuario del agente de host para confirmar.
    15. Escriba Contraseña del administrador del sistema (hn1adm): escriba la contraseña de administrador del sistema.
    16. Confirme la Contraseña de administrador del sistema (hn1adm): escriba la contraseña de administrador del sistema de nuevo para confirmar.
    17. Escriba Directorio principal del administrador del sistema [/usr/sap/HN1/home]: seleccione Entrar para aceptar el valor predeterminado.
    18. Escriba Shell de inicio de sesión del administrador del sistema [/bin/sh]: seleccione Entrar para aceptar el valor predeterminado.
    19. Escriba Id. de usuario del administrador del sistema [1001]: seleccione Entrar para aceptar el valor predeterminado.
    20. Escriba Identificador del grupo de usuarios (sapsys) [79]: seleccione Entrar para aceptar el valor predeterminado.
    21. Escriba Contraseña de usuario de base de datos (SYSTEM): escriba la contraseña de usuario de la base de datos.
    22. Confirme la Contraseña de usuario de base de datos (SYSTEM): vuelva a escribir la contraseña de usuario de la base de datos para confirmar.
    23. ¿Reiniciar el sistema tras el reinicio de la máquina? [n]: Seleccione Entrar para aceptar el valor predeterminado.
    24. ¿Desea continuar? (y/n): valide el resumen. Escriba s para continuar.
  7. [A] Actualización del agente de host de SAP.

    Descargue el archivo más reciente del agente de host de SAP desde SAP Software Center y ejecute el siguiente comando para actualizar el agente. Reemplace la ruta de acceso al archivo para que apunte al archivo que descargó:

    sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
    
  8. [A] Configurar un firewall.

    Cree la regla de firewall para el puerto de sondeo de Azure Load Balancer.

    sudo firewall-cmd --zone=public --add-port=62503/tcp
    sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
    

Configuración de la replicación del sistema de SAP HANA

Siga los pasos descritos en Configuración de la Replicación del sistema de SAP HANA 2.0 para configurar la replicación del sistema de SAP HANA.

Configuración del clúster

En esta sección se describen los pasos necesarios para que un clúster funcione sin problemas cuando SAP HANA está instalado en recursos compartidos de NFS mediante Azure NetApp Files.

Creación de un clúster de Pacemaker

Siga los pasos descritos en Configuración de Pacemaker en Red Hat Enterprise Linux en Azure para crear un clúster básico de Pacemaker para este servidor HANA.

Importante

Con el marco de inicio de SAP basado en sistema, las instancias de SAP HANA ahora se pueden administrar mediante systemd. La versión mínima necesaria de Red Hat Enterprise Linux (RHEL) es RHEL 8 para SAP. Como se describe en la Nota de SAP 3189534, las nuevas instalaciones de la revisión 70 o posteriores de SAP HANA SPS07, o las actualizaciones de los sistemas HANA a HANA 2.0 SPS07 revisión 70 o posterior, el marco de inicio de SAP se registrará automáticamente con systemd.

Al usar soluciones de alta disponibilidad para administrar la replicación del sistema de SAP HANA en combinación con las instancias de SAP HANA habilitadas para el sistema (consulte la Nota de SAP 3189534), se necesitan pasos adicionales para asegurarse de que el clúster de alta disponibilidad pueda administrar la instancia de SAP sin interferencias del sistema. Por lo tanto, para el sistema de SAP HANA integrado con systemd, deben seguirse pasos adicionales descritos en Red Hat KBA 7029705 en todos los nodos del clúster.

Implementación del enlace de replicación del sistema Python SAPHanaSR

Este paso es importante para optimizar la integración con el clúster y mejorar la detección cuando se necesita una conmutación por error de clúster. Se recomienda encarecidamente configurar el enlace de Python de SAPHanaSR. Siga los pasos descritos en Implementación del enlace de replicación del sistema Python SAPHanaSR.

Configuración de recursos del sistema de archivos

En este ejemplo, cada nodo de clúster tiene sus propios sistemas de archivos NFS de HANA /hana/shared, /hana/data y /hana/log.

  1. [1] Ponga el clúster en modo de mantenimiento.

    sudo pcs property set maintenance-mode=true
    
  2. [1] Cree los recursos del sistema de archivos para los montajes de hanadb1.

    sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
    sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
    sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
    
  3. [2] Cree los recursos del sistema de archivos para los montajes de hanadb2.

    sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
    sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
    sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
    

    El atributo OCF_CHECK_LEVEL=20 se agrega a la operación de supervisión para que cada monitor realice una prueba de lectura o escritura en el sistema de archivos. Sin este atributo, la operación de supervisión solo comprueba que el sistema de archivos esté montado. Esto puede ser un problema porque cuando se pierde la conectividad, es posible que el sistema de archivos permanezca montado a pesar de ser inaccesible.

    El atributo on-fail=fence también se agrega a la operación de supervisión. Con esta opción, si se produce un error en la operación de supervisión en un nodo, ese nodo se delimita inmediatamente. Sin esta opción, el comportamiento predeterminado es detener todos los recursos que dependen del recurso con errores, reiniciar el recurso con errores y, a continuación, iniciar todos los recursos que dependen del recurso con errores.

    Este comportamiento no solo puede tardar mucho tiempo cuando un recurso de SAP Hana depende del recurso con errores, pero también se puede producir un error general. El recurso SAPHana no se puede detener correctamente si el servidor de NFS que contiene los ejecutables de HANA no es accesible.

    Los valores de tiempo de espera sugeridos permiten que los recursos del clúster resistan la pausa específica del protocolo, relacionadas con las renovaciones de concesión NFSv4.1. Para obtener más información, consulte Procedimiento recomendado de NFS en NetApp. Es posible que los tiempos de espera de la configuración anterior deban adaptarse a la configuración de SAP específica.

    En el caso de las cargas de trabajo que requieren un mayor rendimiento, considere la posibilidad de usar la opción de montaje nconnect, como se describe en Volúmenes de NFS v4.1 en Azure NetApp Files para SAP HANA. Compruebe si nconnect es compatible con Azure NetApp Files en la versión de Linux.

  4. [1] Configure restricciones de ubicación.

    Configure restricciones de ubicación para asegurarse de que los recursos que administran montajes únicos de hanadb1 nunca se puedan ejecutar en hanadb2 y viceversa.

    sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
    sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
    

    Se establece la opción resource-discovery=never porque los montajes únicos de cada nodo comparten el mismo punto de montaje. Por ejemplo, hana_data1 usa el punto de montaje /hana/data y hana_data2 también usa /hana/data como punto de montaje. Compartir el mismo punto de montaje puede provocar un falso positivo para una operación de sondeo, cuando el estado del recurso se comprueba en el inicio del clúster y, a su vez, puede provocar un comportamiento de recuperación innecesario. Para evitar este escenario, establezca resource-discovery=never.

  5. [1] Configure recursos de atributo.

    Configure los recursos de atributo. Estos atributos se establecen en true si se montan todos los montajes de NFS de un nodo (/hana/data, /hana/log y /hana/data). De lo contrario, se establecen en false.

    sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
    sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
    
  6. [1] Configure restricciones de ubicación.

    Configure restricciones de ubicación para asegurarse de que el recurso de atributo de hanadb1 nunca se ejecute en hanadb2 y viceversa.

    sudo pcs constraint location hana_nfs1_active avoids hanadb2
    sudo pcs constraint location hana_nfs2_active avoids hanadb1
    
  7. [1] Cree restricciones de ordenación.

    Configure restricciones de ordenación para que los recursos de atributo de un nodo se inicien solo después de montar todos los montajes NFS del nodo.

    sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
    sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
    

    Sugerencia

    Si la configuración incluye sistemas de archivos, fuera del grupo hanadb1_nfs o hanadb2_nfs, incluya la opción sequential=false para que no haya dependencias de ordenación entre los sistemas de archivos. Todos los sistemas de archivos deben iniciarse antes de hana_nfs1_active, pero no necesitan iniciarse en ningún orden en relación con los demás. Para más información, consulte Cómo configurar la replicación del sistema de SAP HANA en el escalado vertical de un clúster de Pacemaker cuando los sistemas de archivos de HANA están en recursos compartidos de NFS

Configuración de recursos de clúster de SAP HANA

  1. Siga los pasos descritos en Creación de recursos de clúster de SAP HANA para crear los recursos de SAP HANA en el clúster. Una vez creados los recursos de SAP HANA, debe crear una restricción de regla de ubicación entre los recursos de SAP HANA y los sistemas de archivos (montajes de NFS).

  2. [1] Configure restricciones entre los recursos de SAP HANA y los montajes de NFS.

    Las restricciones de regla de ubicación se establecen para que los recursos de SAP HANA se puedan ejecutar en un nodo solo si se montan todos los montajes de NFS del nodo.

    sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
    

    En RHEL 7.x:

    sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
    

    En RHEL 8.x/9.x:

    sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
    
  3. [1] Configure las restricciones de ordenación para que los recursos de SAP de un nodo se detengan antes de que se detenga cualquiera de los montajes NFS.

    pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs
    pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
    

    En RHEL 7.x:

    pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs
    pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
    

    En RHEL 8.x/9.x:

    pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs
    pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
    

    Saque el clúster del modo de mantenimiento.

    sudo pcs property set maintenance-mode=false
    

    Compruebe el estado del clúster y todos los recursos.

    Nota:

    Este artículo contiene referencias a un término que Microsoft ya no utiliza. Cuando se elimine el término del software, se eliminará también de este artículo.

    sudo pcs status
    

    Ejemplo:

    Online: [ hanadb1 hanadb2 ]
    
    Full list of resources:
    
    rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1
    
    Resource Group: hanadb1_nfs
    hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
    hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
    hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1
    
    Resource Group: hanadb2_nfs
    hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
    hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
    hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2
    
    hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
    hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2
    
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hanadb1 hanadb2 ]
    
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hanadb1 ]
    Slaves: [ hanadb2 ]
    
    Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1
    

Configuración de la replicación del sistema activa/habilitada para lectura de HANA en el clúster de Pacemaker

A partir de SAP HANA 2.0 SPS 01, SAP permite el uso de configuraciones activas/habilitadas para lectura para la replicación del sistema de SAP HANA, donde los sistemas secundarios de la replicación del sistema de SAP HANA se pueden usar activamente para cargas de trabajo de lectura intensiva. Para admitir esta configuración en un clúster, se requiere una segunda dirección IP virtual, lo que permite a los clientes acceder a la base de datos de SAP HANA habilitada para lectura secundaria.

Para garantizar que se puede acceder al sitio de replicación secundario tras una adquisición, el clúster debe mover la dirección IP virtual con la base de datos secundaria del recurso SAPHana.

La configuración adicional, que es necesaria para administrar la replicación del sistema activa/habilitada para lectura de HANA en un clúster de alta disponibilidad de Red Hat con una segunda dirección IP virtual, se describe en Configuración de la replicación del sistema activa/habilitada para lectura de HANA en el clúster de Pacemaker.

Antes de continuar, asegúrese de que ha configurado completamente el clúster de alta disponibilidad de Red Hat que administra la base de datos de SAP HANA, tal como se describe en las secciones anteriores de la documentación.

Prueba de la configuración del clúster

En esta sección se describe cómo se puede probar la configuración.

  1. Antes de iniciar una prueba, asegúrese de que Pacemaker no tiene ninguna acción con error (a través del estado de pcs), no hay restricciones de ubicación inesperadas (por ejemplo, restos de una prueba de migración) y que la replicación del sistema de HANA está en estado de sincronización, por ejemplo, con systemReplicationStatus:

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
  2. Compruebe la configuración del clúster para un escenario de error, cuando un nodo pierde el acceso al recurso compartido de NFS (/hana/shared).

    Los agentes de recursos de SAP HANA dependen de los archivos binarios almacenados en /hana/shared para realizar operaciones durante la conmutación por error. El sistema de archivos /hana/shared se monta en NFS en el escenario presentado.

    Es difícil simular un error en el que uno de los servidores pierde el acceso al recurso compartido de NFS. Como prueba, puede volver a montar el sistema de archivos como de solo lectura. Este enfoque valida que el clúster pueda realizar la conmutación por error, si se pierde el acceso a /hana/shared en el nodo activo.

    Resultado esperado: al hacer que /hana/shared sea un sistema de archivos de solo lectura, se produce un error en el atributo OCF_CHECK_LEVEL del recurso hana_shared1, que realiza operaciones de lectura y escritura en sistemas de archivos. No puede escribir nada en el sistema de archivos y se realiza la conmutación por error de recursos de HANA. Se espera el mismo resultado cuando el nodo de HANA pierde el acceso a los recursos compartidos de NFS.

    Estado del recurso antes de iniciar la prueba:

    sudo pcs status
    

    Ejemplo:

    Full list of resources:
     rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1
    
     Resource Group: hanadb1_nfs
         hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
         hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
         hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1
    
    Resource Group: hanadb2_nfs
         hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
         hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
         hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
    
     hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
     hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
    
     Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
         Started: [ hanadb1 hanadb2 ]
    
     Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
         Masters: [ hanadb1 ]
         Slaves: [ hanadb2 ]
    
     Resource Group: g_ip_HN1_03
         nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
         vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1
    

    Puede colocar /hana/shared en modo de solo lectura en el nodo de clúster activo mediante este comando:

    sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
    

    hanadb se reiniciará o apagará en función de la acción establecida en stonith (pcs property show stonith-action). Una vez que el servidor (hanadb1) está inactivo, el recurso de HANA se mueve a hanadb2. Puede comprobar el estado del clúster desde hanadb2.

    sudo pcs status
    

    Ejemplo:

    Full list of resources:
    
     rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2
    
     Resource Group: hanadb1_nfs
         hana_data1 (ocf::heartbeat:Filesystem):    Stopped
         hana_log1  (ocf::heartbeat:Filesystem):    Stopped
         hana_shared1       (ocf::heartbeat:Filesystem):    Stopped
    
     Resource Group: hanadb2_nfs
         hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
         hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
         hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
    
     hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
     hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
    
     Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
         Started: [ hanadb2 ]
         Stopped: [ hanadb1 ]
    
     Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
         Masters: [ hanadb2 ]
         Stopped: [ hanadb1 ]
    
     Resource Group: g_ip_HN1_03
         nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
         vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2
    

    Se recomienda probar exhaustivamente la configuración del clúster de SAP HANA mediante la realización de las pruebas descritas en Configuración de la replicación del sistema de SAP HANA en RHEL.

Pasos siguientes