Guía de configuración de clústeres de alta disponibilidad para SAP NetWeaver en SLES

En esta guía, se muestra cómo implementar y configurar clústeres de alta disponibilidad (HA) de SUSE Linux Enterprise Server (SLES) optimizado para un sistema SAP NetWeaver.

En esta guía, se incluyen los siguientes pasos:

  • Configurar el Balanceo de cargas TCP/UDP interno para redirigir el tráfico en caso de falla
  • Configurar un clúster de Pacemaker en SLES para administrar los sistemas SAP y otros recursos durante una conmutación por error

En esta guía, también se incluyen pasos a fin de configurar el sistema SAP NetWeaver para HA, pero consulta la documentación de SAP a fin de obtener las instrucciones definitivas.

Si deseas obtener información sobre la implementación de VM de Compute Engine para SAP NetWeaver que no es específica de la alta disponibilidad, consulta la guía de implementación de SAP NetWeaver que es específica de tu sistema operativo.

Esta guía está destinada a usuarios avanzados de SAP NetWeaver que estén familiarizados con la configuración de alta disponibilidad de Linux para SAP NetWeaver.

El sistema que se implementa en esta guía

Con esta guía, podrás implementar dos instancias de SAP NetWeaver y configurar un clúster de HA en SLES. Implementarás cada instancia de SAP NetWeaver en una VM de Compute Engine en una zona diferente dentro de la misma región. En esta guía, no se aborda la instalación de alta disponibilidad de la base de datos subyacente.

Descripción general de un clúster de Linux de alta disponibilidad para un sistema SAP NetWeaver de un solo nodo

El clúster implementado incluye las siguientes funciones y características:

  • Dos VM de host, una con un SAP Central Services activo y otra con un Standalone Enqueue Server activo
  • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
  • Un mecanismo de defensa STONITH
  • Reinicio automático de la instancia con errores como la instancia secundaria nueva

En esta guía, se usan las plantillas de Cloud Deployment Manager que proporciona Google Cloud para implementar las máquinas virtuales (VM) de Compute Engine, lo que garantiza que las VM cumplan con los requisitos de compatibilidad de SAP y con las prácticas recomendadas actuales.

Requisitos previos

Antes de crear el clúster de alta disponibilidad de SAP NetWeaver, asegúrate de que se cumplan los siguientes requisitos:

  • Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP NetWeaver. Si deseas obtener información sobre cómo crear cuentas y proyectos de Google Cloud, consulta Crea un proyecto en la Guía de implementación de SAP NetWeaver para Linux.
  • Si usas un DNS interno de VPC, el valor de la variable VmDnsSetting en los metadatos del proyecto debe ser GlobalOnly o ZonalPreferred para habilitar la resolución de los nombres del nodo entre zonas. La configuración predeterminada de VmDnsSetting es ZonalOnly. Para obtener más información, consulta:

  • Si el Acceso al SO está habilitado en los metadatos del proyecto, debes inhabilitar el Acceso al SO de forma temporal hasta que se complete la implementación. Para fines de implementación, este procedimiento configura las claves SSH en metadatos de instancia. Cuando el Acceso al SO está habilitado, la configuración de las claves SSH basada en metadatos se inhabilita y esta implementación falla. Una vez completada la implementación, puedes volver a habilitar el Acceso al SO.

    Para obtener más información, consulte:

Excepto cuando sea necesario para el entorno de Google Cloud, la información de esta guía es coherente con las siguientes guías relacionadas de SUSE:

Crea una red

Por razones de seguridad, crea una red nueva. Puedes controlar quién tiene acceso con reglas de firewall o mediante otro método de control de acceso.

Si tu proyecto tiene una red de VPC predeterminada, no la uses. En su lugar, crea tu propia red de VPC para que las únicas reglas de firewall vigentes sean aquellas que crees explícitamente.

Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de supervisión de Google. Si usas una de las imágenes de Linux certificadas por SAP disponibles en Google Cloud, la instancia de VM también requerirá acceso a Internet para registrar la licencia y acceder a repositorios de proveedores de SO. Una configuración con una puerta de enlace NAT y con rótulos identificadores de red de VM admite este acceso, incluso si las VM de destino no tienen IP externas.

Para configurar la red, sigue estos pasos:

  1. Ve a Cloud Shell.

    Ir a Cloud Shell

  2. Para crear una red nueva en el modo de subredes personalizadas, ejecuta el siguiente comando:

    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    Reemplaza NETWORK_NAME por el nombre de la red nueva. El nombre de la red solo puede contener caracteres en minúsculas, dígitos y el carácter de guion (-).

    Especifica --subnet-mode custom para evitar el uso del modo automático predeterminado, que crea de forma automática una subred en cada región de Compute Engine. Para obtener más información, consulta Modo de creación de subredes.

  3. Crea una subred y especifica la región y el rango de IP mediante el siguiente comando:

    gcloud compute networks subnets create SUBNETWORK_NAME \
            --network NETWORK_NAME --region REGION --range RANGE

    Reemplaza lo siguiente:

    • SUBNETWORK_NAME: el nombre de la subred nueva
    • NETWORK_NAME: el nombre de la zona que creaste en el paso anterior
    • REGION: la región en la que deseas que esté la subred
    • RANGE: el rango de direcciones IP especificado en formato CIDR, como 10.1.0.0/24 Si planeas agregar más de una subred, asigna rangos de IP de CIDR no superpuestos para cada subred de la red. Ten en cuenta que cada subred y sus rangos de IP interna se asignan a una sola región.
  4. Opcionalmente, repite el paso anterior y agrega subredes adicionales.

Configura una puerta de enlace NAT

Si necesitas crear una o más VM sin direcciones IP públicas, debes usar la traducción de direcciones de red (NAT) para permitir que las VM accedan a Internet. Usa Cloud NAT, un servicio administrado distribuido y definido por Google Cloud que permite que las VM envíen paquetes salientes a Internet y reciban cualquier paquete de respuesta entrante establecido. Como alternativa, puedes configurar una VM independiente como una puerta de enlace NAT.

A fin de crear una instancia de Cloud NAT para tu proyecto, consulta Usa Cloud NAT.

Después de configurar Cloud NAT para tu proyecto, tus instancias de VM pueden acceder a Internet de forma segura sin una dirección IP pública.

Agrega reglas de firewall

De forma predeterminada, las conexiones entrantes que no pertenecen a tu red de Google Cloud se bloquean. A fin de permitir conexiones entrantes, establece una regla de firewall para tu VM. Las reglas de firewall solo regulan las conexiones entrantes nuevas a una VM. Después de establecer una conexión con una VM, se permite el tráfico en ambas direcciones a través de esa conexión.

Puedes crear una regla de firewall a fin de permitir el acceso a puertos específicos o para permitir el acceso entre las VM de la misma subred.

Tendrás que crear reglas de firewall que permitan el acceso, por ejemplo, para lo siguiente:

  • Los puertos predeterminados que utiliza SAP NetWeaver, como se documenta en Puertos TCP/IP de todos los productos SAP
  • Conexiones desde tu computadora o tu entorno de red empresarial a tu instancia de VM de Compute Engine; Si no estás seguro de qué dirección IP usar, comunícate con el administrador de red de tu empresa
  • Comunicación entre las VM en una configuración de alta disponibilidad, de escalamiento horizontal o de 3 niveles. Por ejemplo, si estás implementando un sistema de 3 niveles, tendrás al menos 2 VM en tu subred: la VM de SAP NetWeaver y otra VM para el servidor de base de datos. Para habilitar la comunicación entre las dos VM, debes crear una regla de firewall que permita el tráfico proveniente de la subred
  • Verificaciones de estado de Cloud Load Balancing. Si deseas obtener más información, consulta Crea una regla de firewall para las verificaciones de estado.

Para crear una regla de firewall, sigue estos pasos:

  1. En Cloud Console, ve a la página Reglas de firewall.

    Abrir la página Reglas de firewall

  2. En la parte superior de la página, haz clic en Crear regla de firewall.

    • En el campo Red, selecciona la red en la que se ubica tu VM.
    • En el campo Objetivos, selecciona Todas las instancias de la red.
    • En el campo Filtro de fuente, selecciona una de las siguientes opciones:
      • Rangos de IP, para permitir el tráfico entrante de direcciones IP específicas. Especifica el rango de direcciones IP en el campo Rangos de IP de origen.
      • Subredes, para permitir el tráfico entrante desde una subred específica. Especifica el nombre de la subred en el siguiente campo Subredes. Puedes usar esta opción para permitir el acceso entre las VM en una configuración de escalamiento horizontal o de 3 niveles.
    • En la sección Protocolos y puertos, selecciona Protocolos y puertos especificados y especifica tcp:[PORT_NUMBER];.
  3. Haz clic en Crear para crear tu regla de firewall.

Implementa las VM para SAP NetWeaver

Antes de comenzar a configurar el clúster de HA, debes definir y, luego, implementar las instancias de VM que funcionarán como los nodos principales y secundarios en tu clúster de HA.

A fin de definir e implementar las VM, usa la misma plantilla de Cloud Deployment Manager que usas a fin de implementar una VM para un sistema SAP NetWeaver en la Implementación automatizada de VM para SAP NetWeaver en Linux.

Sin embargo, a fin de implementar dos VM en lugar de una debes agregar la definición de la segunda VM al archivo de configuración. Para ello, copia y pega la definición de la primera VM. Después de crear la segunda definición, debes cambiar los nombres de los recursos y las instancias en la segunda definición. Para evitar una falla zonal, especifica una zona diferente en la misma región. Todos los demás valores de propiedad en las dos definiciones permanecen iguales.

Una vez que las VM se implementen de forma correcta, debes instalar SAP NetWeaver, y definir y configurar el clúster de HA.

Las siguientes instrucciones se usan con Cloud Shell, pero se pueden aplicar al SDK de Cloud en términos generales.

  1. Abra Cloud Shell.

    Ir a Cloud Shell

  2. Descarga la plantilla de archivo de configuración YAML, template.yaml, en el directorio de trabajo:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml

  3. De manera opcional, cambia el nombre del archivo template.yaml para identificar la configuración que define. Por ejemplo, nw-ha-sles15sp1.yaml

  4. Para abrir el archivo de configuración YAML en el editor de código de Cloud Shell, haz clic en el ícono de lápiz () en la esquina superior derecha de la ventana de la terminal de Cloud Shell.

  5. Define la primera instancia de VM en la plantilla del archivo de configuración YAML. Debes definir la segunda instancia de VM en el paso posterior a la siguiente tabla.

    Reemplaza los corchetes y su contenido por los valores de la instalación a fin de especificar los siguientes valores de propiedad. Las propiedades se describen en la siguiente tabla. Para ver un ejemplo de un archivo de configuración completo, consulta Ejemplo de un archivo de configuración YAML completo.

    Propiedad Tipo de datos Descripción
    nombre String Un nombre arbitrario que identifica el recurso de implementación que define el siguiente conjunto de propiedades.
    tipo String

    Especifica la ubicación, el tipo y la versión de la plantilla de Deployment Manager que se usará durante la implementación.

    El archivo YAML incluye dos especificaciones type, y una de ellas se marca como comentario. La especificación type que está activa de forma predeterminada especifica la versión de la plantilla como latest. La especificación type que se marca como comentario especifica una versión específica de la plantilla con una marca de tiempo.

    Si necesitas que todas tus implementaciones usen la misma versión de plantilla, usa la especificación type, que incluye la marca de tiempo.

    instanceName String El nombre de la instancia de VM que estás definiendo. Especifica nombres diferentes en las definiciones de la VM principal y la secundaria. Te recomendamos usar nombres que identifiquen las instancias como pertenecientes al mismo clúster de alta disponibilidad.

    Los nombres de las instancias deben tener 13 caracteres o menos y especificarse en letras minúsculas, números o guiones. Usa un nombre que sea único dentro de tu proyecto.

    instanceType String El tipo de VM de Compute Engine que necesitas. Especifica el mismo tipo de instancia para la VM principal y la secundaria.

    Si necesitas un tipo de VM personalizado, especifica un tipo de VM pequeño predefinido y, una vez finalizada la implementación, personaliza la VM según sea necesario.

    zone String La zona de Google Cloud en la que se implementará la instancia de VM que estás definiendo. Especifica diferentes zonas en la misma región para las definiciones de la VM principal y secundaria. Las zonas deben estar en la misma región que seleccionaste para tu subred.
    subnetwork String El nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por ejemplo, myproject/network1.
    linuxImage String El nombre de la imagen del sistema operativo Linux o la familia de imágenes que usas con SAP NetWeaver. Para especificar una familia de imágenes, agrega el prefijo family/ al nombre de la familia. Por ejemplo: family/sles-15-sp1-sap. Si deseas ver la lista de las familias de imágenes disponibles, consulta la página Imágenes en Cloud Console.
    linuxImageProject String El proyecto de Google Cloud que contiene la imagen que usarás. Este proyecto puede ser uno propio o el proyecto de imagen de Google Cloud suse-sap-cloud. Para ver una lista de proyectos de imágenes de Google Cloud, consulta la página Imágenes en la documentación de Compute Engine.
    usrsapSize Número entero El tamaño del disco “/usr/sap”. El tamaño mínimo es de 8 GB.
    sapmntSize Número entero El tamaño del disco “/sapmnt”. El tamaño mínimo es de 8 GB.
    swapSize Número entero El tamaño del volumen de intercambio. El tamaño mínimo es de 1 GB.
    networkTag String

    Opcional. Una o más etiquetas de red separadas por comas que representan tu instancia de VM para firewall o enrutamiento.

    En las configuraciones de alta disponibilidad, especifica una etiqueta de red que se usará en una regla de firewall que permita la comunicación entre los nodos del clúster y una etiqueta de red que se usará en una regla de firewall que permita las verificaciones de estado de Cloud Load Balancing para acceder a los nodos del clúster

    Si especificas “publicIP: No”, pero no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.

    serviceAccount String

    Opcional. Especifica una cuenta de servicio personalizada que se usará para la VM implementada. La cuenta de servicio debe incluir los permisos necesarios durante la implementación para configurar la VM de SAP.

    Si no se especifica serviceAccount, se usa la cuenta de servicio de Compute Engine predeterminada.

    Especifica la dirección completa de la cuenta de servicio. Por ejemplo, sap-ha-example@example-project-123456.iam.gserviceaccount.com

    publicIP Booleano Opcional. Determina si se agrega una dirección IP pública a tu instancia de VM. El valor predeterminado es Yes.
    sap_deployment_debug Booleano Opcional. Si este valor se establece en Yes, la implementación genera registros de implementación con verbosidad. No actives esta configuración, a menos que un ingeniero de Atención al cliente de Google te solicite que habilites la depuración.
  6. En el archivo de configuración YAML, crea la definición de la segunda VM. Para ello, copia la definición de la primera VM y pégala después de la primera definición. Para ver un ejemplo, consulta Ejemplo de un archivo de configuración YAML completo.

  7. En la definición de la segunda VM, especifica valores diferentes para las siguientes propiedades que especificaste en la primera definición:

    • name
    • instanceName
    • zone
  8. Crea las instancias de VM:

    gcloud deployment-manager deployments create [DEPLOYMENT_NAME] --config [TEMPLATE_NAME].yaml

    Donde:

    • [DEPLOYMENT_NAME] representa el nombre de la implementación.
    • [TEMPLATE_NAME] representa el nombre del archivo de configuración YAML.

    El comando anterior invoca a Deployment Manager, que implementa las VM de acuerdo con las especificaciones del archivo de configuración YAML.

    El procesamiento de la implementación consta de dos etapas. En la primera, Deployment Manager escribe su estado en la consola. En la segunda, las secuencias de comandos de implementación escriben su estado en Cloud Logging.

Ejemplo de un archivo de configuración YAML completo

En el siguiente ejemplo, se muestra un archivo de configuración YAML completo que implementa dos instancias de VM para una configuración de HA de SAP NetWeaver mediante la última versión de las plantillas de Deployment Manager. En el ejemplo, se omiten los comentarios que contiene la plantilla cuando la descargas por primera vez.

El archivo contiene las definiciones de dos recursos para implementar: sap_nw_node_1 y sap_nw_node_2. Cada definición de recurso contiene las definiciones de una VM.

La definición del recurso sap_nw_node_2 se creó cuando se copió y se pegó la primera definición y, luego, se modificaron los valores de las propiedades name, instanceName y zone. Todos los demás valores de propiedad en las dos definiciones de recursos son iguales.

Las propiedades networkTag y serviceAccount pertenecen a la sección Opciones avanzadas de la plantilla del archivo de configuración.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

Crea reglas de firewall que permitan el acceso a las VM host

Si aún no lo hiciste, crea reglas de firewall que permitan el acceso a cada VM del host desde las siguientes fuentes:

  • Para fines de configuración, tu estación de trabajo local, un host de bastión o un servidor de salto
  • Para el acceso entre los nodos del clúster, las otras VM del host en el clúster de HA
  • Las verificaciones de estado que usa Cloud Load Balancing, como se describe en el paso posterior, Crea una regla de firewall para las verificaciones de estado

Cuando creas reglas de firewall de VPC, especificas las etiquetas de red que definiste en el archivo de configuración template.yaml para designar tus VM del host como destino de la regla.

Para verificar la implementación, define una regla que permita conexiones SSH en el puerto 22 desde un host de bastión o tu estación de trabajo local.

Para el acceso entre los nodos del clúster, agrega una regla de firewall que permita todos los tipos de conexiones en cualquier puerto de otras VM en la misma subred.

Asegúrate de que se creen las reglas de firewall para verificar la implementación y la comunicación dentro del clúster antes de continuar con la siguiente sección. Para obtener instrucciones, consulta Agrega reglas de firewall.

Verifica la implementación de las VM

Antes de instalar SAP NetWeaver o comenzar a configurar el clúster de HA, verifica que las VM se hayan implementado de forma correcta mediante la verificación de los registros y la asignación de almacenamiento del SO.

Verifica los registros

En los siguientes pasos, se usa Cloud Logging, que puede generar gastos. Para obtener más información, consulta los precios de Cloud Logging.

  1. Abre Cloud Logging para verificar errores y supervisar el progreso de la instalación.

    Ir a Logging

  2. En la pestaña Recursos, selecciona Global como tu recurso de registro. Si una VM muestra INSTANCE DEPLOYMENT COMPLETE, el procesamiento de Deployment Manager está completo para la VM.

    Pantalla de Logging

Verifica la configuración de las VM

  1. Después de que se implementan las instancias de VM, conéctate a las VM mediante ssh.

    1. Si aún no lo hiciste, crea una regla de firewall para permitir una conexión SSH en el puerto 22.
    2. Ve a la página Instancias de VM.

      Ir a la página Instancias de VM

    3. Conéctate a cada instancia de VM; para ello, haz clic en el botón SSH en la entrada de cada instancia de VM o usa tu método SSH preferido.

      Botón SSH de la página Instancias de VM de Compute Engine

  2. Muestra el sistema de archivos:

    ~> df -h

    Verifica que el resultado sea similar al siguiente:

    Filesystem                 Size  Used Avail Use% Mounted on
    devtmpfs                    32G  8.0K   32G   1% /dev
    tmpfs                       48G     0   48G   0% /dev/shm
    tmpfs                       32G  402M   32G   2% /run
    tmpfs                       32G     0   32G   0% /sys/fs/cgroup
    /dev/sda3                   30G  3.4G   27G  12% /
    /dev/sda2                   20M  3.7M   17M  19% /boot/efi
    /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
    /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
    tmpfs                      6.3G     0  6.3G   0% /run/user/1002
    tmpfs                      6.3G     0  6.3G   0% /run/user/0
  3. Confirma que se creó el espacio de intercambio:

    ~> cat /proc/meminfo | grep Swap

    Deberías ver resultados similares al siguiente ejemplo:

    SwapCached:            0 kB
    SwapTotal:      25161724 kB
    SwapFree:       25161724 kB

Si alguno de los pasos de la validación muestra que la instalación falló, haz lo siguiente:

  1. Corrige el error.
  2. En la página Implementaciones, borra la implementación para limpiar las VM y los discos persistentes de la instalación con errores.
  3. Vuelve a ejecutar tu implementación.

Actualiza el SDK de Cloud

La plantilla de Deployment Manager instaló el SDK de Cloud en las VM durante la implementación. Actualiza el SDK de Cloud para asegurarte de que incluya todas las actualizaciones más recientes.

  1. Establece una conexión SSH a la VM principal.

  2. Actualiza el SDK de Cloud:

    ~>  sudo gcloud components update
  3. Sigue las indicaciones.

  4. Repite los pasos en la VM secundaria.

Habilita la comunicación de backend del balanceador de cargas entre las VM

Después de confirmar que las VM se implementaron de forma correcta, habilita la comunicación de backend entre las VM que funcionarán como los nodos en tu clúster de HA.

  1. En cada VM del clúster de alta disponibilidad, habilita el enrutamiento local.

    1. Establece una conexión SSH en cada VM de tu clúster planificado.
    2. Cambia al usuario raíz.
    3. En cada máquina, habilita el enrutamiento local en la interfaz principal mediante la ejecución del siguiente comando. Si usas una interfaz diferente a eth0, especifica esa interfaz en el comando, en lugar de eth0.

      echo net.ipv4.conf.eth0.accept_local=1 >> /etc/sysctl.conf
      sysctl -p

      Con el comando anterior, se escribe el parámetro de configuración en el archivo de configuración.

  2. En cada VM, crea una secuencia de comandos de inicio para habilitar la comunicación de backend a backend:

    Cloud Console

    1. Ve a la página Instancias de VM en Cloud Console.

      Ir a la página Instancias de VM

    2. Haz clic en el nombre de la VM principal.

    3. En la página Detalles de instancia de VM, haz clic en el botón EDITAR.

    4. En la sección Metadatos personalizados, haz clic en Agregar elemento.

    5. En el campo Clave, especifica startup-script.

    6. En el campo Valor, pega la siguiente secuencia de comandos Bash:

      #! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule del from all lookup local
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi
    7. Al final de la página, haz clic en Guardar.

    8. Reinicia el servidor para que la secuencia de comandos de inicio tenga efecto.

      Cuando termines, tus metadatos personalizados deberían ser similares al siguiente ejemplo:

      La captura de pantalla muestra "startup-script" con otras entradas en la sección Metadatos personalizados de la página de detalles de la VM en Cloud Console.

    9. Repite los pasos anteriores para el servidor secundario.

    gcloud

    1. En Cloud Shell o en donde tengas el SDK de Cloud instalado, usa el siguiente comando gcloud con la secuencia de comandos de inicio incluida para agregar una a los metadatos de la instancia de cada VM. Reemplaza las variables con el nombre y la zona de la VM antes de ingresar el comando.

      gcloud compute instances add-metadata primary-vm-name \
      --zone=primary-vm-zone --metadata=startup-script='#! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip rule del from all lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi'
    2. Reinicia el servidor para que la secuencia de comandos de inicio tenga efecto.

    3. Para confirmar que la secuencia de comandos de inicio se almacena en los metadatos de la instancia, ejecuta el siguiente comando:

      gcloud compute instances describe primary-vm-name \
      --zone=primary-vm-zone

      La secuencia de comandos de inicio aparece en el resultado en metadata, como se muestra en el siguiente ejemplo truncado:

      metadata:
      fingerprint: Tbuij9k-knk=
      items:
      - key: post_deployment_script
      value: ''
      - key: sap_deployment_debug
      value: 'False'
      - key: status
      value: completed
      - key: startup-script
      value: |-
        #! /bin/bash
        # VM startup script
        ...
        [example truncated]
    4. Para la VM secundaria, repite los pasos anteriores después de reemplazar los valores de las variables por los valores de la instancia de VM secundaria.

Para obtener más información sobre cómo crear secuencias de comandos de inicio para VM de Compute Engine, consulta Ejecuta secuencias de comandos de inicio.

Configura claves SSH en las VM principales y secundarias

Para permitir que se copien archivos entre los hosts del clúster de HA, los pasos de esta sección crean conexiones SSH raíz entre los dos hosts.

Las plantillas de Deployment Manager que proporciona Google Cloud generan una clave por ti, pero puedes reemplazarla por una clave que generes si es necesario.

Es probable que tu organización tenga lineamientos que rijan las comunicaciones de red internas. Si es necesario, después de completar la implementación, puedes quitar los metadatos de las VM y las claves del directorio authorized_keys.

Si configurar conexiones SSH directas no cumple con los lineamientos de tu organización, puedes transferir archivos mediante otros métodos, como los que se mencionan a continuación:

Para habilitar las conexiones SSH entre la instancia principal y la secundaria, haz lo que se indica a continuación. En los pasos, se supone que usas la clave SSH que generan las plantillas de Deployment Manager para SAP.

  1. En la VM host principal, sigue estos pasos:

    1. Conéctate a la VM a través de SSH.

    2. Cambiar a la raíz:

      $ sudo su -
    3. Confirma que la clave SSH existe:

      # ls -l /root/.ssh/

      Deberías ver los archivos de claves id_rsa como en el siguiente ejemplo:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Actualiza los metadatos de la VM principal con información sobre la clave SSH para la VM secundaria.

      # gcloud compute instances add-metadata secondary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-vm-zone
    5. Para confirmar que las claves SSH estén configuradas de forma correcta, abre una conexión SSH desde el sistema principal al secundario.

      # ssh secondary-vm-name
  2. En la VM secundaria del host, sigue estos pasos:

    1. Conéctate a la VM mediante SSH.

    2. Cambiar a la raíz:

      $ sudo su -
    3. Confirma que la clave SSH existe:

      # ls -l /root/.ssh/

      Deberías ver los archivos de claves id_rsa como en el siguiente ejemplo:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Actualiza los metadatos de la VM secundaria con información sobre la clave SSH para la VM principal.

      # gcloud compute instances add-metadata primary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone
      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. Para confirmar que las claves SSH estén configuradas correctamente, abre una conexión SSH desde el sistema secundario al principal.

      # ssh primary-vm-name

Configura el almacenamiento de archivos compartidos y los directorios compartidos

Debes configurar una solución de archivos compartidos NFS que proporcione almacenamiento de archivos compartidos con alta disponibilidad a los que ambos nodos del clúster con alta disponibilidad puedan acceder. Luego, crearás directorios en ambos nodos que se asignan al almacenamiento de archivos compartidos. El software del clúster garantiza que los directorios adecuados se activen solo en las instancias correctas.

En esta guía, no se aborda la configuración de una solución de uso compartido de archivos. A fin de obtener instrucciones para configurar el sistema de uso compartido de archivos, consulta las instrucciones que proporciona el proveedor de la solución que seleccionaste.

Para obtener información sobre soluciones de uso compartido de archivos que están disponibles en Google Cloud, consulta Opciones de almacenamiento compartido para sistemas SAP de alta disponibilidad en Google Cloud.

Para configurar los directorios compartidos, sigue estos pasos:

  1. Si aún no configuraste una solución de almacenamiento de archivos compartidos NFS con alta disponibilidad, hazlo ahora.

  2. Activa el almacenamiento compartido de NFS en ambos servidores para la configuración inicial.

    ~> sudo mkdir /mnt/nfs
    ~> sudo mount -t nfs nfs-path /mnt/nfs
  3. Desde cualquiera de los servidores, crea directorios para sapmnt, el directorio de transporte central, el directorio del sistema y el directorio específico de la instancia. Si usas una pila de Java, reemplaza “ASCS” por “SCS” antes de usar los siguientes y otros comandos de ejemplo:

    ~> sudo mkdir /mnt/nfs/sapmntSID
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDSYS,SIDASCSscs-instance-number,SIDERSers-instance-number}
  4. En ambos servidores, crea los puntos de activación necesarios:

    ~> sudo mkdir -p /sapmnt/SID
    ~> sudo mkdir -p /usr/sap/trans
    ~> sudo mkdir -p /usr/sap/SID/SYS
    ~> sudo mkdir -p /usr/sap/SID/ASCSscs-instance-number
    ~> sudo mkdir -p /usr/sap/SID/ERSers-instance-number
  5. Configura autofs para activar los directorios de archivos compartidos comunes cuando se accede a los directorios por primera vez. El software del clúster, que configuras en un paso posterior, administra la activación de los directorios ASCSscs-instance-number y ERSers-instance-number.

    Ajusta las opciones de NFS en los comandos según sea necesario para tu solución de uso compartido de archivos.

    En ambos servidores, configura autofs:

    ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
    ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
    ~> echo "/sapmnt/SID ${NFS_OPTS} nfs-path/sapmntSID" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/trans ${NFS_OPTS} nfs-path/usrsaptrans" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/SID/SYS ${NFS_OPTS} nfs-path/usrsapSIDSYS" | sudo tee -a /etc/auto.sap

    Para obtener más información sobre autofs, consulta autofs: cómo funciona.

  6. En ambos servidores, inicia el servicio de autofs:

    ~> sudo systemctl enable autofs
    ~> sudo systemctl restart autofs
    ~> sudo automount -v
  7. Para activar autofs a fin de activar los directorios compartidos, accede a cada directorio con el comando cd. Por ejemplo:

    ~> cd /sapmnt/SID
    ~> cd /usr/sap/trans
    ~> cd /usr/sap/SID/SYS
    
  8. Después de acceder a todos los directorios, ejecuta el comando df -Th para confirmar que los directorios están activados.

    ~> df -Th | grep file_share_name

    Deberías ver puntos de activación y directorios similares a los siguientes:

    10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
    10.49.153.26:/nfs_share_nw_ha/usrsapAHASYS nfs      1007G   76M  956G   1% /usr/sap/AHA/SYS
    10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
    10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

Configura la compatibilidad con la conmutación por error de Cloud Load Balancing

El servicio de balanceo de cargas de TCP/UDP interno compatible con la conmutación por error enruta el tráfico de SCS y ERS a las instancias activas de cada uno en un clúster de SAP NetWeaver. El balanceo de cargas de TCP/UDP interno usa direcciones IP virtuales (VIP), servicios de backend, grupos de instancias y verificaciones de estado para enrutar el tráfico de manera adecuada.

Reserva direcciones IP para las IP virtuales

Para un clúster de alta disponibilidad de SAP NetWeaver, creas dos VIP, que a veces se conocen como direcciones IP flotantes. Una VIP sigue la instancia activa de SAP Central Services (SCS) y la otra sigue la instancia de Enqueue Replication Server (ERS). El balanceador de cargas enruta el tráfico que se envía a cada VIP a la VM que aloja la instancia activa del componente SCS o ERS de la VIP.

  1. Abre Cloud Shell:

    Ir a Cloud Shell

  2. Reserva una dirección IP para la IP virtual del SCS y la VIP del ERS. En el caso de SCS, la dirección IP es la que usan las aplicaciones para acceder a SAP NetWeaver. En el caso de ERS, la dirección IP es la que se usa para la replicación del servidor de cola. Si omites la marca --addresses, se elige una dirección IP en la subred especificada:

    ~ gcloud compute addresses create scs-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses scs-vip-address
    
    ~ gcloud compute addresses create ers-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses ers-vip-address

    Para obtener más información sobre cómo reservar una IP estática, consulta Reserva una dirección IP interna estática.

  3. Confirma la reserva de la dirección IP:

    ~ gcloud compute addresses describe vip-name \
      --region cluster-region

    Deberías ver un resultado similar al siguiente:

    address: 10.1.0.85
    addressType: INTERNAL
    creationTimestamp: '2021-05-12T13:30:29.991-07:00'
    description: ''
    id: '1740813556077659146'
    kind: compute#address
    name: scs-aha-vip-name
    networkTier: PREMIUM
    purpose: GCE_ENDPOINT
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/scs-aha-vip-name
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

Define los nombres de host de la dirección VIP en /etc/hosts

Define un nombre de host para cada dirección VIP y, luego, agrega las direcciones IP y los nombres de host de las VM y las VIP al archivo /etc/hosts en cada VM.

Los nombres de host VIP no se conocen fuera de las VM, a menos que también los agregues a tu servicio DNS. Agregar estas entradas al archivo /etc/hosts local protege tu clúster de las interrupciones del servicio de DNS.

Las actualizaciones del archivo /etc/hosts deben ser similares al siguiente ejemplo:

#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost
10.1.0.89       nw-ha-vm-1
10.1.0.88       nw-ha-vm-2
10.1.0.90       vh-scs-aha
10.1.0.91       vh-ers-aha

Crea las verificaciones de estado de Cloud Load Balancing

Crea verificaciones de estado: una para la instancia de SCS activa y otra para el ERS activo.

  1. En Cloud Shell, crea las verificaciones de estado. A fin de evitar conflictos con otros servicios, designa los números de puerto para las instancias de SCS y ERS en el rango privado 49152-65535. Los valores de intervalo de verificación y tiempo de espera de los siguientes comandos son un poco más largos que los valores predeterminados con el fin de aumentar la tolerancia a la conmutación por error durante los eventos de migración en vivo de Compute Engine. Puedes ajustar los valores si es necesario:

    1. ~ gcloud compute health-checks create tcp scs-health-check-name \
      --port=scs-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ers-health-check-name \
      --port=ers-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
  2. Confirma la creación de cada verificación de estado:

    ~ gcloud compute health-checks describe health-check-name

    Deberías ver un resultado similar al siguiente:

    checkIntervalSec: 10
    creationTimestamp: '2021-05-12T15:12:21.892-07:00'
    healthyThreshold: 2
    id: '1981070199800065066'
    kind: compute#healthCheck
    name: scs-aha-health-check-name
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    tcpHealthCheck:
      port: 60000
      portSpecification: USE_FIXED_PORT
      proxyHeader: NONE
    timeoutSec: 10
    type: TCP
    unhealthyThreshold: 2

Crea una regla de firewall para las verificaciones de estado

Si aún no lo has hecho, define una regla de firewall para un puerto en el rango privado que permita el acceso a las VM de tu host desde los rangos de IP que usan las verificaciones de estado de Cloud Load Balancing, 35.191.0.0/16 y 130.211.0.0/22. Si deseas obtener más información sobre las reglas de firewall para los balanceadores de cargas, consulta Crea reglas de firewall para verificaciones de estado.

  1. Si aún no tienes una, agrega una etiqueta de red a las VM del host. La regla de firewall usa esta etiqueta de red para las verificaciones de estado.

  2. Crea una regla de firewall que use la etiqueta de red para permitir las verificaciones de estado:

    ~ gcloud compute firewall-rules create  rule-name \
      --network=network-name \
      --action=ALLOW \
      --direction=INGRESS \
      --source-ranges=35.191.0.0/16,130.211.0.0/22 \
      --target-tags=network-tags \
      --rules=tcp:scs-healthcheck-port-num,tcp:ers-healthcheck-port-num

    Por ejemplo:

    gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
    --network=example-network \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-health-check \
    --rules=tcp:60000,tcp:60010

Crea grupos de instancias de Compute Engine

Debes crear un grupo de instancias en cada zona que contenga una VM de nodo de clúster y agregar la VM en esa zona al grupo de instancias.

  1. En Cloud Shell, crea el grupo de instancias principal y agrégale la VM principal:

    1. ~ gcloud compute instance-groups unmanaged create primary-ig-name \
      --zone=primary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-vm-zone \
      --instances=primary-vm-name
  2. En Cloud Shell, crea el grupo de instancias secundario y agrégale la VM secundaria:

    1. ~ gcloud compute instance-groups unmanaged create secondary-ig-name \
      --zone=secondary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-vm-zone \
      --instances=secondary-vm-name
  3. Confirma la creación de los grupos de instancias:

    ~ gcloud compute instance-groups unmanaged list

    Deberías ver un resultado similar al siguiente:

    NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
    sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
    sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
    

Configura los servicios de backend

Crea dos servicios de backend, uno para SCS y otro para ERS. Agrega ambos grupos de instancias a cada servicio de backend y designa el grupo opuesto como el grupo de instancias de conmutación por error en cada servicio de backend. Por último, crea reglas de reenvío desde las VIP hacia los servicios de backend.

  1. En Cloud Shell, crea el servicio de backend y el grupo de conmutación por error para SCS:

    1. Crea el servicio de backend para SCS:

      ~ gcloud compute backend-services create scs-backend-service-name \
         --load-balancing-scheme internal \
         --health-checks scs-health-check-name \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region cluster-region \
         --global-health-checks
    2. Agrega el grupo de instancias principal al servicio de backend de SCS:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --region cluster-region
    3. Agrega el grupo de instancias secundario como el grupo de instancias de conmutación por error para el servicio de backend de SCS:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --failover \
        --region cluster-region
  2. En Cloud Shell, crea el servicio de backend y el grupo de conmutación por error para ERS:

    1. Crea el servicio de backend para ERS:

      ~ gcloud compute backend-services create ers-backend-service-name \
      --load-balancing-scheme internal \
      --health-checks ers-health-check-name \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region cluster-region \
      --global-health-checks
    2. Agrega el grupo de instancias secundario al servicio de backend de ERS:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --region cluster-region
    3. Agrega el grupo de instancias principal como el grupo de instancias de conmutación por error para el servicio de backend de ERS:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --failover \
        --region cluster-region
  3. De manera opcional, confirma que los servicios de backend contengan los grupos de instancias como se espera:

    ~ gcloud compute backend-services describe backend-service-name \
     --region=cluster-region

    Deberías ver un resultado similar al siguiente ejemplo para el servicio de backend de SCS. En el caso de ERS, failover: true aparecerá en el grupo de instancias principal:

    backends:
    - balancingMode: CONNECTION
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    - balancingMode: CONNECTION
      failover: true
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    connectionDraining:
      drainingTimeoutSec: 0
    creationTimestamp: '2021-05-25T08:30:58.424-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: n44gVc1VVQE=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    id: '4940777952116778717'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: scs-aha-backend-service-name
    protocol: TCP
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/backendServices/scs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. En Cloud Shell, crea reglas de reenvío para los servicios de backend de SCS y ERS:

    1. Crea la regla de reenvío de la VIP de SCS al servicio de backend de SCS:

      ~ gcloud compute forwarding-rules create scs-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address scs-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service scs-backend-service-name \
      --ports ALL
    2. Crea la regla de reenvío desde la VIP de ERS al servicio de backend de ERS:

      ~ gcloud compute forwarding-rules create ers-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address ers-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service ers-backend-service-name \
      --ports ALL

Prueba la configuración del balanceador de cargas

Aunque los grupos de instancias de backend no se registren como en buen estado, puedes probar la configuración del balanceador de cargas mediante la configuración de un objeto de escucha que responda a las verificaciones de estado. Después de configurar un objeto de escucha, si el balanceador de cargas está configurado de forma correcta, el estado de los grupos de instancias de backend cambia a en buen estado.

En las siguientes secciones, se presentan diferentes métodos que puedes usar para probar la configuración.

Prueba el balanceador de cargas con la utilidad socat

Puedes usar la utilidad socat para escuchar de forma temporal en un puerto de verificación de estado. Debes instalar la utilidad socat de todos modos, ya que la usarás más adelante cuando configures los recursos del clúster.

  1. En ambas VM host como raíz, instala la utilidad socat:

    # zypper install -y socat

  2. En la VM principal, inicia un proceso socat para escuchar durante 60 segundos en el puerto de verificación de estado de SCS:

    # timeout 60s socat - TCP-LISTEN:scs-healthcheck-port-num,fork

  3. En Cloud Shell, después de esperar algunos segundos para que la verificación de estado detecte el objeto de escucha, verifica el estado de tus grupos de instancias de backend de SCS:

    ~ gcloud compute backend-services get-health scs-backend-service-name \
      --region cluster-region
  4. Repite los pasos de ERS y reemplaza los valores de variables de SCS por los valores de ERS.

    Deberías ver un resultado similar al siguiente ejemplo para SCS:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.89
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: UNHEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.88
        port: 80
      kind: compute#backendServiceGroupHealth

Prueba el balanceador de cargas mediante el puerto 22

Si el puerto 22 está abierto para conexiones SSH en las VM del host, puedes editar de manera temporal el verificador de estado a fin de usar el puerto 22, que tiene un objeto de escucha que puede responder al verificador de estado.

Para usar de forma temporal el puerto 22, sigue estos pasos:

  1. Haz clic en la verificación de estado en la consola:

    Ir a la página Verificaciones de estado

  2. Haz clic en Editar.

  3. En el campo Puerto, cambia el número de puerto a 22.

  4. Haz clic en Guardar y espera uno o dos minutos.

  5. En Cloud Shell, después de esperar algunos segundos para que la verificación de estado detecte el objeto de escucha, verifica el estado de tus grupos de instancias de backend:

    ~ gcloud compute backend-services get-health backend-service-name \
      --region cluster-region

    Debería ver un resultado similar al siguiente:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.79
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.78
        port: 80
      kind: compute#backendServiceGroupHealth
  6. Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.

Configura Pacemaker

El siguiente procedimiento configura la implementación de SUSE de un clúster de Pacemaker en las VM de Compute Engine para SAP NetWeaver.

Para obtener más información sobre la configuración de clústeres de alta disponibilidad en SLES, consulta la documentación de la extensión de alta disponibilidad de SUSE Linux Enterprise para tu versión de SLES.

Instala los paquetes de clúster requeridos

  1. Como raíz en los hosts principal y secundario, descarga los siguientes paquetes de clústeres obligatorios:

    • El patrón ha_sles:

      # zypper install -t pattern ha_sles
    • El paquete sap-suse-cluster-connector:

      # zypper install -y sap-suse-cluster-connector
    • Si aún no lo has instalado, la utilidad socat realiza lo siguiente:

      # zypper install -y socat

  2. Confirma que se hayan cargado los últimos agentes de alta disponibilidad:

    # zypper se -t patch SUSE-SLE-HA

Inicializa, configura e inicia el clúster en la VM principal

Inicializa el clúster mediante la secuencia de comandos SUSE ha-cluster-init. Luego, debes editar el archivo de configuración de Corosync y sincronizarlo con el nodo secundario. Después de iniciar el clúster, configura propiedades adicionales y valores predeterminados mediante comandos crm.

Inicializa el clúster

Para inicializar el clúster, sigue estos pasos:

  1. En el host principal como raíz, inicializa el clúster mediante la secuencia de comandos ha-cluster-init de SUSE. Los siguientes comandos nombran al clúster y crean el archivo de configuración corosync.conf: configura este archivo y también la sincronización entre los nodos del clúster.

    # ha-cluster-init --name cluster-name --yes --interface eth0 csync2
    # ha-cluster-init --name cluster-name --yes --interface eth0 corosync

Actualiza los archivos de configuración de Corosync

  1. Abre el archivo corosync.conf para editarlo:

    # vi /etc/corosync/corosync.conf
  2. En la sección totem del archivo corosync.conf, configura los parámetros del siguiente ejemplo extraído para los valores que se muestran. Es posible que algunos parámetros ya estén configurados en los valores correctos:

    totem {
            ...
            token: 20000
            token_retransmits_before_loss_const: 10
            join: 60
            max_messages: 20
            ...
    }
  3. Inicia el clúster:

    # ha-cluster-init --name cluster-name cluster

Configura las propiedades adicionales del clúster

  1. Configura las propiedades generales del clúster:

    # crm configure property stonith-timeout="300s"
    # crm configure property stonith-enabled="true"
    # crm configure rsc_defaults resource-stickiness="1"
    # crm configure rsc_defaults migration-threshold="3"
    # crm configure op_defaults timeout="600"

    Cuando defines los recursos del clúster individuales, los valores que estableces para resource-stickiness y migration-threshold anulan los valores predeterminados que estableces aquí.

    Puedes ver los valores predeterminados de los recursos, así como los valores de los recursos definidos, si ingresas crm config show.

  2. Inicia Pacemaker en el host principal:

    # systemctl enable pacemaker
    # systemctl start pacemaker

Une la VM secundaria al clúster

Desde la terminal abierta en la VM principal, une y, luego, inicia el clúster en la VM secundaria a través de SSH.

  1. Desde la VM principal, ejecuta las siguientes opciones de secuencias de comandos ha-cluster-join en la VM secundaria a través de SSH. Si configuraste tu clúster de HA como se describe en estas instrucciones, puedes ignorar las advertencias sobre el perro guardián.

    1. Ejecuta la opción --interface eth0 csync2:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes --interface eth0 csync2'
    2. Ejecuta la opción ssh_merge:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes ssh_merge'
    3. Ejecuta la opción cluster:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes cluster'
  2. Inicia Pacemaker en el host secundario:

    1. Habilita Pacemaker:

      # ssh secondary-vm-name systemctl enable pacemaker
    2. Inicia Pacemaker:

      # ssh secondary-vm-name systemctl start pacemaker
  3. En cualquiera de los hosts como raíz, confirma que el clúster muestre ambos nodos:

    # crm_mon -s

    Debería ver un resultado similar al siguiente:

    CLUSTER OK: 2 nodes online, 0 resource instances configured

Configura los recursos del clúster para la infraestructura

Debes definir los recursos que Pacemaker administra en un clúster de alta disponibilidad. Debes definir los recursos para los siguientes componentes del clúster:

  • El dispositivo de protección, que evita situaciones de cerebro dividido
  • Los directorios SCS y ERS en el sistema de archivos compartidos
  • Las verificaciones de estado
  • Las VIP
  • Los componentes de SCS y ERS

Defines los recursos para los componentes de SCS y ERS más adelante que el resto de los recursos, ya que primero debes instalar SAP NetWeaver.

Habilita el modo de mantenimiento

  1. En cualquier host como raíz, coloca el clúster en modo de mantenimiento:

    # crm configure property maintenance-mode="true"
  2. Confirma el modo de mantenimiento:

    # crm status

    El resultado debería indicar que la administración de recursos está inhabilitada, como se muestra en el siguiente ejemplo:

    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    * Last updated: Fri May 14 15:26:08 2021
    * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
    * 2 nodes configured
    * 0 resource instances configured
    
                *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
    * No resources

Configura la protección

Puedes configurar la protección mediante la definición de un recurso de clúster con el agente fence_gce para cada VM del host.

A fin de garantizar la secuencia correcta de eventos después de una acción de protección, también debes configurar el sistema operativo para que retrase el reinicio de Corosync después de que se protege una VM. También debes ajustar el tiempo de espera de Pacemaker para los reinicios a fin de responder ante la demora.

Crea los recursos del dispositivo de protección

Por cada VM en el clúster, debes crear un recurso de clúster para el dispositivo de protección que puede reiniciar esa VM. El dispositivo de protección para una VM debe ejecutarse en una VM diferente, por lo que configuras la ubicación del recurso de clúster que se ejecutará en cualquier VM, excepto la VM que puede reiniciar.

  1. En el host principal como raíz, crea un recurso de clúster para un dispositivo de protección de la VM principal:

    # crm configure primitive fencing-rsc-name-primary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" \
      op start interval="0" timeout="60s" \
      params port="primary-vm-name" zone="primary-vm-zone" \
      project="cluster-project-id" \
      pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
  2. Configura la ubicación del dispositivo de protección de la VM principal a fin de que esté activa solo en la VM secundaria:

    # crm configure location fencing-location-name-primary-vm \
      fencing-rsc-name-primary-vm -inf: "primary-vm-name"
  3. En el host principal como raíz, crea un recurso de clúster para un dispositivo de protección de la VM secundaria:

    # crm configure primitive fencing-rsc-name-secondary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" \
      op start interval="0" timeout="60s" \
      params port="secondary-vm-name" zone="secondary-vm-zone" \
      project="cluster-project-id" \
      pcmk_reboot_timeout=300 pcmk_monitor_retries=4
  4. Configura la ubicación del dispositivo de protección para la VM secundaria a fin de que esté activa solo en la VM principal:

    # crm configure location fencing-location-name-secondary-vm \
      fencing-rsc-name-secondary-vm -inf: "secondary-vm-name"

Establece una demora para el reinicio de Corosync

  1. En ambos hosts como raíz, crea un archivo directo systemd que retrase el inicio de Corosync para garantizar la secuencia adecuada de eventos después de reiniciar una VM protegida:

    systemctl edit corosync.service
  2. Agrega las siguientes líneas al archivo:

    [Service]
    ExecStartPre=/bin/sleep 60
  3. Guarda el archivo y sal del editor.

  4. Vuelve a cargar la configuración del administrador del sistema.

    systemctl daemon-reload
  5. Confirma que se creó el archivo directo:

    service corosync status

    Deberías ver una línea para el archivo directo, como se muestra en el siguiente ejemplo:

    ● corosync.service - Corosync Cluster Engine
       Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/corosync.service.d
               └─override.conf
       Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Crea los recursos del sistema de archivos

Ahora que creaste los directorios del sistema de archivos compartidos, puedes definir los recursos del clúster.

  1. Configura los recursos del sistema de archivos para los directorios específicos de la instancia.

    # crm configure primitive scs-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDASCSscs-instance-number" \
    directory="/usr/sap/SID/ASCSscs-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s
    # crm configure primitive ers-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDERSers-instance-number" \
    directory="/usr/sap/SID/ERSers-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

Crea los recursos de verificación de estado

  1. Configura los recursos del clúster para las verificaciones de estado de SCS y ERS:
# crm configure primitive scs-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:scs-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0
# crm configure primitive ers-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ers-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0

Crea los recursos VIP

Define los recursos del clúster para las direcciones VIP.

  1. Si necesitas buscar la dirección VIP numérica, puedes usar el siguiente comando:

    • gcloud compute addresses describe scs-vip-name
      --region=cluster-region --format="value(address)"
    • gcloud compute addresses describe ers-vip-name
      --region=cluster-region --format="value(address)"
  2. Crea los recursos del clúster para las VIP de SCS y ERS.

    # crm configure primitive scs-vip-rsc-name IPaddr2 \
     params ip=scs-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=3600s timeout=60s
    # crm configure primitive ers-vip-rsc-name IPaddr2 \
     params ip=ers-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=3600s timeout=60s

Visualiza los recursos definidos

  1. Para ver todos los recursos que definiste hasta ahora, ingresa el siguiente comando:

    # crm status

    Deberías ver un resultado similar al siguiente:

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Wed May 26 19:10:10 2021
    Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
    
    2 nodes configured
    8 resource instances configured
    
                  *** Resource management is DISABLED ***
      The cluster will not attempt to start, stop or recover services
    
    Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Stopped (unmanaged)
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

Instala SCS y ERS

En la siguiente sección, solo se abordan los requisitos y las recomendaciones específicos para instalar SAP NetWeaver en Google Cloud.

Para obtener instrucciones de instalación completas, consulta la documentación de SAP NetWeaver.

Prepararse para la instalación

Para garantizar la coherencia en el clúster y simplificar la instalación, antes de instalar los componentes de SCS y ERS de SAP NetWeaver, define los usuarios, grupos y permisos, y coloca el servidor secundario en modo de espera.

  1. Quita el clúster del modo de mantenimiento:

    # crm configure property maintenance-mode="false"
  2. En ambos servidores como raíz, ingresa los siguientes comandos y especifica los ID de usuario y grupo que sean adecuados para tu entorno:

    # groupadd -g gid-sapinst sapinst
    # groupadd -g gid-sapsys sapsys
    # useradd -u uid-sidadm sid-loweradm -g sapsys
    # usermod -a -G sapinst sid-loweradm
    # useradd -u uid-sapadm sapadm -g sapinst
    
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS
    # chown sid-loweradm:sapsys /sapmnt/SID -R
    # chown sid-loweradm:sapsys /usr/sap/trans -R
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS -R
    # chown sid-loweradm:sapsys /usr/sap/SID -R

Instala el componente de SCS

  1. En el servidor secundario, ingresa el siguiente comando para poner el servidor secundario en modo de espera:

    # crm_standby -v on -N ${HOSTNAME};

    Cuando se pone el servidor secundario en modo de espera, se consolidan todos los recursos del clúster en el servidor principal, lo que simplifica la instalación.

  2. Confirma que el servidor secundario esté en modo de espera:

    # crm status

    Deberías ver un resultado similar al siguiente:

    Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
    
    2 nodes configured
    8 resource instances configured
    
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
  3. En el servidor principal como usuario raíz, cambia tu directorio a un directorio de instalación temporal, como /tmp, para instalar la instancia de SCS. Para ello, ejecuta SAP Software Provisioning Manager (SWPM).

    • A fin de acceder a la interfaz web de SWPM, necesitas la contraseña para el usuario root. Si tu política de TI no permite que el administrador de SAP tenga acceso a la contraseña raíz, puedes usar SAPINST_REMOTE_ACCESS_USER.

    • Cuando inicies SWPM, usa el parámetro SAPINST_USE_HOSTNAME a fin de especificar el nombre de host virtual que definiste para la dirección VIP de SCS en el archivo /etc/hosts.

      Por ejemplo:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
    • En la página de confirmación final de SWPM, asegúrate de que el nombre del host virtual sea correcto.

  4. Una vez completada la configuración, quita la VM secundaria del modo en espera:

    # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

Instala el componente ERS

  1. En el servidor principal como raíz o sidadm, detén el servicio de SCS.

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function StopService"
  2. En el servidor principal, ingresa el siguiente comando para poner el servidor principal en modo de espera:

    # crm_standby -v on -N ${HOSTNAME};

    Cuando se coloca el servidor principal en modo de espera, se consolidan todos los recursos del clúster en el servidor secundario, lo que simplifica la instalación.

  3. Confirma que el servidor principal esté en modo de espera:

    # crm status
  4. En el servidor secundario como usuario raíz, cambia tu directorio a uno de instalación temporal, como /tmp, para instalar la instancia de ERS, mediante la ejecución del SAP Software Provisioning Manager (SWPM).

    • Usa el mismo usuario y contraseña para acceder a SWPM que usaste cuando instalaste el componente SCS.

    • Cuando inicies SWPM, usa el parámetro SAPINST_USE_HOSTNAME a fin de especificar el nombre de host virtual que definiste para la dirección VIP de ERS en el archivo /etc/hosts.

      Por ejemplo:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
    • En la página de confirmación final de SWPM, asegúrate de que el nombre del host virtual sea correcto.

  5. Quita la VM principal del modo de espera para que esté activa:

    # crm_standby -v off -N ${HOSTNAME};

Configura los servicios de SAP

Debes confirmar que los servicios estén configurados de forma correcta, verificar la configuración en los perfiles de ASCS y ERS, y agregar el usuario sidadm al grupo de usuarios haclient.

Confirma las entradas de servicio de SAP

  1. En ambos servidores, confirma que /usr/sap/sapservices contenga entradas para los servicios SCS y ERS. Puedes agregar cualquier entrada faltante mediante sapstartsrv command con las opciones pf=profile-of-the-sap-instance y -reg. Por ejemplo:

    # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ERSers-instance-number_ers-virtual-host-name \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ASCSscs-instance-number_scs-virtual-host-name \
     -reg

Detén los servicios de SAP

  1. En el servidor secundario, detén el servicio de ERS:

    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function StopService"
  2. En cada servidor, verifica que todos los servicios estén detenidos:

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function GetSystemInstanceList"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function GetSystemInstanceList"

    Deberías ver un resultado similar al siguiente:

    18.05.2021 17:39:18
    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Edita los perfiles de SCS y ERS

  1. En cualquiera de los servidores, cambia al directorio de perfil mediante uno de los siguientes comandos:

    # cd /usr/sap/SID/SYS/profile
    # cd /sapmnt/SID/profile
  2. Si es necesario, puedes encontrar los nombres de los archivos de tus perfiles de ASCS y ERS si enumeras los archivos en el directorio de perfil o usas los siguientes formatos:

    SID_ASCSscs-instance-number_scs-virtual-host-name
    SID_ERSers-instance-number_ers-virtual-host-name
  3. Para habilitar el paquete sap-suse-cluster-connector, agrega las siguientes líneas a los perfiles de instancia de ASCS y ERS:

    #-----------------------------------------------------------------------
    # SUSE HA library
    #-----------------------------------------------------------------------
    service/halib = $(DIR_CT_RUN)/saphascriptco.so
    service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
  4. Si usas ENSA1, habilita la función keepalive con solo configurar lo siguiente en el perfil de ASCS:

    enque/encni/set_so_keepalive = true

    Para obtener más información, consulta la Nota de SAP 1410736 - TCP/IP: Cómo configurar el intervalo keepalive.

  5. Si es necesario, edita los perfiles de ASCS y ERS para cambiar el comportamiento de inicio del Enqueue Server y del Enqueue Replication Server.

    ENSA1

    En la sección “Iniciar SAP Enqueue Server” del perfil de ASCS, si ves Restart_Program_nn, cambia “Restart” a “Start”, como se muestra en el siguiente ejemplo.

    Start_Program_01 = local $(_EN) pf=$(_PF)

    En la sección “Inicia el Enqueue Replication Server” del perfil de ERS, si ves Restart_Program_nn, cambia “Restart” por “Start”, como se muestra en el siguiente ejemplo.

    Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

    ENSA2

    En la sección “Iniciar SAP Enqueue Server” del perfil de ASCS, si ves Restart_Program_nn, cambia “Restart” a “Start”, como se muestra en el siguiente ejemplo.

    Start_Program_01 = local $(_ENQ) pf=$(_PF)

    En la sección “Iniciar Enqueue Replicator” del perfil de ERS, si ves Restart_Program_nn, cambia “Restart” por “Start”, como se muestra en el siguiente ejemplo.

    Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

Agrega el usuario sidadm al grupo de usuarios haclient

Cuando instalaste sap-suse-cluster-connector, la instalación creó un grupo de usuarios haclient. Para permitir que el usuario sidadm trabaje con el clúster, agrégalo al grupo de usuarios haclient.

  1. En ambos servidores, agrega el usuario sidadm al grupo de usuarios haclient:

    # usermod -aG haclient sid-loweradm

Configura los recursos del clúster para SCS y ERS

  1. Como raíz de cualquiera de los servidores, coloca el clúster en modo de mantenimiento:

    # crm configure property maintenance-mode="true"
  2. Confirma que el clúster esté en modo de mantenimiento:

    # crm status

    Si el clúster está en modo de mantenimiento, el estado incluye las siguientes líneas:

                  *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
  3. Crea los recursos del clúster para los servicios de SCS y ERS:

    ENSA1

    • Crea el recurso del clúster para la instancia de SCS. El valor de InstanceName es el nombre del perfil de la instancia que generó SWPM cuando instalaste SCS.

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10
    • Crea el recurso de clúster para la instancia de ERS. El valor de InstanceName es el nombre del perfil de la instancia que generó SWPM cuando instalaste ERS. El parámetro IS_ERS=true le indica a Pacemaker que establezca la marca runsersSID en 1 en el nodo en el que está activo ERS.

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

    ENSA2

    • Crea el recurso del clúster para la instancia de SCS. El valor de InstanceName es el nombre del perfil de la instancia que generó SWPM cuando instalaste SCS.

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60
    • Crea el recurso de clúster para la instancia de ERS. El valor de InstanceName es el nombre del perfil de la instancia que generó SWPM cuando instalaste ERS.

      # crm configure primitive ers-instance-rsc-name SAPInstance \
        operations \$id=ers-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSers-instance-number_ers-virtual-host-name  \
           START_PROFILE="/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name" \
           AUTOMATIC_RECOVER=false IS_ERS=true

Configura grupos de recursos y restricciones de ubicación

  1. Agrupa los recursos SCS y ERS. Puedes mostrar los nombres de todos los recursos definidos con anterioridad si ingresas el comando crm resource status:

    # crm configure group scs-rsc-group-name scs-file-system-rsc-name \
      scs-health-check-rsc-name scs-vip-rsc-name \
      scs-instance-rsc-name \
      meta resource-stickiness=3000
    # crm configure group ers-rsc-group-name ers-file-system-rsc-name \
      ers-health-check-rsc-name ers-vip-rsc-name \
      ers-instance-rsc-name
  2. Crea las restricciones de colocación:

    ENSA1

    1. Crea una restricción de colocación que evite que los recursos de SCS se ejecuten en el mismo servidor que los recursos ERS:

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configura SCS para conmutar por error al servidor en el que se ejecuta ERS, según lo determinado por la marca runsersSID que es igual a 1:

      # crm configure location loc-scs-SID-failover-to-ers scs-instance-rsc-name \
      rule 2000: runs_ers_SID eq 1
    3. Configura SCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false

    ENSA2

    1. Crea una restricción de colocación que evite que los recursos de SCS se ejecuten en el mismo servidor que los recursos ERS:

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configura SCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false
  3. Inhabilita el modo de mantenimiento.

    # crm configure property maintenance-mode="false"
  4. Verifica la configuración de los grupos, las restricciones de colocación y el orden:

    # crm config show

    El resultado debe incluir líneas similares a las del siguiente ejemplo:

    ENSA1

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name
    location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    location loc-sap-AHA-failover-to-ers scs-aha-instance-rsc-name \
            rule 2000: runs_ers_AHA eq 1

    ENSA2

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    order ord-sap-AHA-first-start-ascs Optional: scs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name

Prueba tu clúster

En esta sección, se muestra cómo ejecutar las siguientes pruebas:

  • Comprueba si hay errores de configuración
  • Confirma que los recursos de SCS y ERS cambien de servidor de forma correcta durante las conmutaciones por error
  • Confirma que los bloqueos estén retenidos
  • Confirma en Compute Engine que los eventos de mantenimiento no activen una conmutación por error

Verifica la configuración del clúster desde SAP

  1. Como raíz en cualquiera de los servidores, consulta qué instancias están activas en el servidor:

    # crm status
  2. Cambiar al usuario de sidadm

    # su - sid-loweradm
  3. Verifica la configuración del clúster. Para el número de instancia, especifica el número de la instancia de SCS o ERS que está activo en el servidor en el que ingresas el comando:

    > sapcontrol -nr instance-number -function HAGetFailoverConfig

    HAActive debe ser TRUE, como se muestra en el siguiente ejemplo:

    20.05.2021 01:33:25
    HAGetFailoverConfig
    OK
    HAActive: TRUE
    HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
    HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
    HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
    HAActiveNode: nw-ha-vm-1
    HANodes: nw-ha-vm-1, nw-ha-vm-2
  4. Como sidadm, verifica si hay errores en la configuración:

    > sapcontrol -nr instance-number -function HACheckConfig

    Deberías ver un resultado similar al siguiente:

    20.05.2021 01:37:19
    HACheckConfig
    OK
    state, category, description, comment
    SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
    SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java instances detected
    SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
    SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
    SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vh-scs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-scs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-scs-aha_AHA_00), Enqueue replication active
  5. Como raíz en cualquiera de los servidores, verifica en qué nodos se están ejecutando los recursos:

    # crm status

    En el siguiente ejemplo, los recursos de SCS se ejecutan en el servidor nw-ha-vm-1 y los recursos de ERS se ejecutan en el servidor nw-ha-vm-2.

    # Cluster Summary:
      * Stack: corosync
      * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Thu May 20 16:58:46 2021
      * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
      * 2 nodes configured
      * 10 resource instances configured
    
    Node List:
      * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Active Resources:
      * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
      * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
      * Resource Group: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
      * Resource Group: ers-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
        * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
        * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
        * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
  6. Como sidadm en el servidor en el que SCS está activo, simula una conmutación por error:

    > sapcontrol -nr scs-instance-number -function HAFailoverToNode ""
  7. Como raíz, si sigues la conmutación por error mediante crm_mon, deberías ver que SCS se mueve al otro servidor, que ERS se detiene en ese servidor y que se traslada al servidor en el que se solía ejecutar SCS.

Confirma que se conserven las entradas de bloqueo

Para confirmar que las entradas de bloqueo se conservan en una conmutación por error, primero selecciona la pestaña de tu versión del Enqueue Server y sigue el procedimiento para generar entradas de bloqueo, simula una conmutación por error y confirma que las entradas de bloqueo se retienen después de que SCS se vuelve a activar.

ENSA1

  1. Como sidadm, en el servidor en el que ERS está activo, genera entradas de bloqueo mediante el programa enqt:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 11 number-of-locks
  2. Como sid, en el servidor en el que SCS está activo, verifica que se registren las entradas de bloqueo:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Si creaste 10 bloqueos, deberías ver un resultado similar al siguiente:

    locks_now: 10
  3. Como sid, en el servidor en el que ERS está activo, inicia la función de supervisión, OpCode=20, del programa enqt:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 20 1 1 9999

    Por ejemplo:

    > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999
  4. Cuando SCS esté activo, reinicia el servidor.

    En el servidor de supervisión, para cuando Pacemaker detenga el ERS a fin de moverlo al otro servidor, deberías ver un resultado similar al siguiente.

    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
  5. Cuando se detenga el monitor enqt, ingresa Ctrl + c para salir de él.

  6. De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:

    # crm_mon
  7. Como sidadm, después de confirmar que los bloqueos se retuvieron, debes liberarlos:

    > enqt pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name 12 number-of-locks
  8. Como sid, en el servidor en el que está activo SCS, verifica que se quiten las entradas de bloqueo:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

ENSA2

  1. Como sidadm, en el servidor en el que ERS está activo, genera entradas de bloqueo mediante el programa enq_adm:

    > enq_admin --set_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  2. Como sid, en el servidor en el que SCS está activo, verifica que se registren las entradas de bloqueo:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Si creaste 10 bloqueos, deberías ver un resultado similar al siguiente:

    locks_now: 10
  3. Cuando SCS esté activo, reinicia el servidor.

  4. De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:

    # crm_mon
  5. Como sidadm, en el servidor en el que se reinició SCS, verifica que se hayan retenido las entradas de bloqueo:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now
  6. Como sidadm en el servidor en el que ERS está activo, después de confirmar que se retuvieron los bloqueos, libera los bloqueos:

    > enq_admin --release_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  7. Como sid, en el servidor en el que está activo SCS, verifica que se quiten las entradas de bloqueo:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

    Deberías ver un resultado similar al siguiente:

    locks_now: 0

Simula un evento de mantenimiento de Compute Engine

Simula un evento de mantenimiento de Compute Engine para asegurarte de que la migración en vivo no active una conmutación por error.

Los valores de tiempo de espera y de intervalo que se usan en estas instrucciones contribuyen a la duración de las migraciones en vivo. Si usas valores más cortos, el riesgo de que la migración en vivo active una conmutación por error es mayor.

Para probar la tolerancia del clúster en la migración en vivo, haz lo siguiente:

  1. En el nodo principal, activa un evento de mantenimiento simulado mediante el siguiente comando del SDK de Cloud:

    # gcloud compute instances simulate-maintenance-event primary-instance-name
  2. Confirma que el nodo principal no cambie:

    # crm status

Soluciona problemas

A fin de solucionar problemas de opciones de configuración de alta disponibilidad para SAP NetWeaver en SLES, consulta Solución de problemas de opciones de configuración de alta disponibilidad para SAP.

Obtén asistencia para SAP NetWeaver en SLES

Si necesitas ayuda para resolver un problema con los clústeres de alta disponibilidad para SAP NetWeaver en SLES, recopila la información de diagnóstico requerida y comunícate con el servicio de atención al cliente de Cloud. Para obtener más información, consulta Clústeres de alta disponibilidad en la información de diagnóstico de RHEL.

Asistencia

Si tienes problemas con la infraestructura o los servicios de Google Cloud, comunícate con el servicio de Atención al cliente. Puedes encontrar la información de contacto en la página Descripción general de la asistencia en Google Cloud Console. Si el servicio de Atención al cliente determina que existe un problema en tus sistemas de SAP, te referiremos al servicio de asistencia de SAP.

Por problemas relacionados con el producto SAP, registra una solicitud de asistencia en Asistencia de SAP. SAP evalúa el ticket de asistencia y, si parece ser un problema de infraestructura de Google Cloud, transfiere el ticket al componente BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE de Google Cloud.

Requisitos de asistencia

Antes de recibir asistencia para los sistemas SAP y la infraestructura y los servicios de Google Cloud que usan, debes cumplir con los requisitos mínimos del plan de asistencia.

A fin de obtener más información sobre los requisitos mínimos de asistencia para SAP en Google Cloud, consulta lo siguiente:

Realiza tareas posteriores a la implementación

Antes de usar el sistema SAP NetWeaver, te recomendamos que crees una copia de seguridad del nuevo sistema SAP NetWeaver de HA.

Para obtener más información, sigue estas sugerencias:

¿Qué sigue?

Consulta los siguientes recursos para obtener más información:

+ Guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud + SAP en Google Cloud: informe sobre alta disponibilidad + Para obtener más información sobre la administración de VM y supervisión, consulta la Guía de operaciones de SAP NetWeaver