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

En esta guía, se muestra cómo automatizar la implementación de un clúster de alta disponibilidad (HA) de Red Hat Enterprise Linux (RHEL) optimizado para el rendimiento para SAPNetWeaver.

En la guía, se usa Terraform para implementar dos máquinas virtuales (VMs) de Compute Engine, una dirección IP virtual (VIP) con una implementación de balanceador de cargas de red de transferencia interno y un clúster de HA basado en SO, según las prácticas recomendadas de Google Cloud, SAP y el proveedor del SO.

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.

Si deseas configurar un clúster de alta disponibilidad para SAP NetWeaver en SUSE Linux Enterprise Server (SLES), consulta la guía de configuración manual de clústeres de alta disponibilidad para SAP NetWeaver en SLES.

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

Si sigues las instrucciones de esta guía, implementarás dos instancias de SAP NetWeaver y configurarás un clúster de alta disponibilidad en RHEL. 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 para la instancia activa de ASCS y otra para la instancia activa de ENSA2 Enqueue Replicator o ENSA1 Enqueue Replication Server (ENSA1). Las instancias de ENSA2 y ENSA1 se denominan ERS.
  • 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

Requisitos previos

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

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 Red Hat y SAP:

Crea una red

Por razones de seguridad, crea una red nueva. Puedes controlar quién tiene acceso con reglas de firewall o a través de 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 de forma explícita.

Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de Google Cloud para SAP. 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 crear una red de VPC para tu proyecto, completa los siguientes pasos:

  1. Crea una red de modo personalizado. Para obtener más información, consulta Cómo crear una red de modo personalizado.

  2. Crea una subred y especifica la región y el rango de IP a través de el siguiente comando. Para obtener más información, consulta Cómo agregar subredes.

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 software 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.

Para 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.

Cómo agregar 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.

A fin de crear las reglas de firewall para tu proyecto, consulta Crea reglas de firewall.

Crea un clúster de Linux de alta disponibilidad para SAP NetWeaver

En las siguientes instrucciones, se usa un archivo de configuración de Terraform a fin de crear un clúster de alta disponibilidad de RHEL para SAP NetWeaver con dos VMs de Compute Engine. Las VMs de Compute Engine se crean en dos zonas de destino en una configuración de conmutación por error automática para los servicios centrales de SAP y la replicación en cola.

Define opciones de configuración para el clúster de alta disponibilidad de SAP NetWeaver en un archivo de configuración de Terraform.

  1. Abre Cloud Shell.

    Ir a Cloud Shell

  2. Descarga el archivo de configuración sap_nw_ha.tf para el clúster de alta disponibilidad de SAP NetWeaver en tu directorio de trabajo:

    $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/terraform/sap_nw_ha.tf

  3. Abre el archivo sap_nw_ha.tf en el editor de código de Cloud Shell.

    Para abrir 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.

  4. En el archivo sap_nw_ha.tf, reemplaza los contenidos dentro de las comillas dobles por los valores de la instalación para actualizar los siguientes valores de argumento. Los argumentos se describen en la siguiente tabla.

    Argument Tipo de dato Descripción
    source Cadena

    Especifica la ubicación y la versión del módulo de Terraform que se usará durante la implementación.

    El archivo de configuración DEPLOYMENT_TYPE.tf incluye dos instancias del argumento source: una que está activa y otra que se incluye como un comentario. El argumento source que está activo de forma predeterminada especifica latest como la versión del módulo. La segunda instancia del argumento source, que de forma predeterminada se desactiva a través de un carácter # inicial, especifica una marca de tiempo que identifica una versión del módulo.

    Si necesitas que todas tus implementaciones usen la misma versión del módulo, quita el carácter # inicial del argumento source que especifica la marca de tiempo de la versión y agrégala al argumento source que especifica latest.

    project_id Cadena Especifica el ID del proyecto de Google Cloud en el que implementarás este sistema. Por ejemplo, my-project-x.
    machine_type String Especifica el tipo de máquina virtual (VM) de Compute Engine en el que quieres ejecutar el sistema SAP. Si necesitas un tipo de VM personalizada, especifica un tipo de VM predefinido con una cantidad de CPU virtuales más cercana al número que necesitas sin dejar de ser más grande. Una vez completada la implementación, modifica la cantidad de CPU virtuales y la cantidad de memoria.

    Por ejemplo, n1-highmem-32.
    network String Especifica el nombre de la red en la que necesitas crear el balanceador de cargas que administra la VIP.

    Si usas una red de VPC compartida, debes agregar el ID del proyecto host como directorio superior del nombre de la red. Por ejemplo, HOST_PROJECT_ID/NETWORK_NAME.

    subnetwork Cadena Especifica el nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como SHARED_VPC_PROJECT_ID/SUBNETWORK. Por ejemplo: myproject/network1
    linux_image Cadena Especifica el nombre de la imagen del sistema operativo Linux en la que deseas implementar tu sistema SAP. Por ejemplo, rhel-9-2-sap-ha. Para obtener la lista de imágenes de sistema operativo disponibles, consulta la página Imágenes en la consola de Google Cloud.
    linux_image_project Cadena Especifica el proyecto de Google Cloud que contiene la imagen que especificaste para el argumento linux_image. Este proyecto puede ser uno propio o un proyecto de imagen de Google Cloud. Para una imagen de Compute Engine, especifica rhel-sap-cloud. A fin de encontrar el proyecto de imagen de tu sistema operativo, consulta Detalles de los sistemas operativos.
    sap_primary_instance String Especifica un nombre para la instancia de VM del sistema SAP NetWeaver principal. Esta es tu ubicación inicial de ASCS. El nombre puede contener letras en minúscula, números o guiones, y no debe superar los 13 caracteres.
    sap_primary_zone String Especifica una zona en la que se implemente el sistema SAP NetWeaver principal. Las zonas principal y secundaria deben estar en la misma región. Por ejemplo, us-east1-b.
    sap_secondary_instance String Especifica un nombre para la instancia de VM del sistema secundario de SAP NetWeaver. Esta es tu ubicación inicial de ERS. El nombre puede contener letras en minúscula, números o guiones, y no debe superar los 13 caracteres.
    sap_secondary_zone String Especifica una zona en la que se implemente el sistema SAP NetWeaver secundario. Las zonas principal y secundaria deben estar en la misma región. Por ejemplo, us-east1-c.
    nfs_path String Especifica el punto de activación de NFS para el sistema de archivos compartidos. Por ejemplo, 10.163.58.114:/ssd_nfs.
    sap_sid String Especifica un ID del sistema SAP. Debe constar de tres caracteres alfanuméricos y comenzar con una letra. Todas las letras deben estar en mayúsculas. Por ejemplo, ED1.
    hc_firewall_rule_name String Opcional. Especifica un nombre para la regla de firewall de verificación de estado. El valor predeterminado es SAP_SID-hc-allow.
    hc_network_tag Cadena Opcional. Especifica una o más etiquetas de red separadas por comas que desees asociar con tus instancias de VM para la regla de firewall de verificación de estado. El valor predeterminado es SAP_SID-hc-allow-tag.
    scs_inst_group_name Cadena Opcional. Especifica un nombre para el grupo de instancias de ASCS. El valor predeterminado es SAP_SID-scs-ig.
    scs_hc_name Cadena Opcional. Especifica un nombre para la verificación de estado de ASCS. El valor predeterminado es SAP_SID-scs-hc.
    scs_hc_port Cadena Opcional. Especifica un puerto para la verificación de estado de ASCS. A fin de evitar conflictos con otros servicios, designa el número de puerto para la verificación de estado de ASCS en el rango privado 49152-65535. El valor predeterminado es 60000.
    scs_vip_address Cadena Opcional. Especifica una dirección IP sin usar dentro de la subred especificada en subnetwork antes a fin de usarla como la dirección IP virtual para la instancia de ASCS. Si no se especifica nada, las secuencias de comandos de implementación seleccionan automáticamente una dirección IP sin usar de la subred especificada.
    scs_vip_name String Opcional. Especifica un nombre para la IP virtual de ASCS. El valor predeterminado es SAP_SID-scs-vip.
    scs_backend_svc_name Cadena Opcional. Especifica un nombre para el servicio de backend de ASCS. El valor predeterminado es SAP_SID-scs-backend-svc.
    scs_forw_rule_name Cadena Opcional. Especifica un nombre para la regla de reenvío de ASCS. El valor predeterminado es SAP_SID-scs-fwd-rule.
    ers_inst_group_name Cadena Opcional. Especifica un nombre para el grupo de instancias de ERS. El valor predeterminado es SAP_SID-ers-ig.
    ers_hc_name Cadena Opcional. Especifica un nombre para la verificación de estado de ERS. El valor predeterminado es SAP_SID-ers-hc.
    ers_hc_port Cadena Opcional. Especifica un puerto para la verificación de estado de ERS. A fin de evitar conflictos con otros servicios, designa el número de puerto para la verificación de estado de ERS en el rango privado 49152-65535. El valor predeterminado es 60010.
    ers_vip_address Cadena Opcional. Especifica una dirección IP sin usar dentro de la subred especificada en subnetwork antes a fin de usarla como la dirección IP virtual para la instancia de ERS. Si no se especifica nada, las secuencias de comandos de implementación seleccionan automáticamente una dirección IP sin usar de la subred especificada.
    ers_vip_name String Opcional. Especifica un nombre para la IP virtual de ERS. El valor predeterminado es SAP_SID-ers-vip.
    ers_backend_svc_name Cadena Opcional. Especifica un nombre para el servicio de backend de ERS. El valor predeterminado es SAP_SID-ers-backend-svc.
    ers_forw_rule_name Cadena Opcional. Especifica un nombre para la regla de reenvío de ERS. El valor predeterminado es SAP_SID-ers-fwd-rule.
    usr_sap_size Número entero Opcional. Especifica el tamaño del disco /usr/sap en GB. El tamaño mínimo es de 8 GB. El valor predeterminado es 8.
    sap_mnt_size Número entero Opcional. Especifica el tamaño del disco /sapmnt en GB. El tamaño mínimo es de 8 GB. El valor predeterminado es 8.
    swap_size Número entero Opcional. Especifica el tamaño del volumen de intercambio en GB. El tamaño mínimo es de 8 GB. El valor predeterminado es 8.
    sap_scs_instance_number Cadena Opcional. Especifica el número de instancia de ASCS. El valor de sap_scs_instance_number debe ser un número de dos dígitos. Si necesitas especificar un solo número de dígitos, agrega un 0 delante del número. Por ejemplo, 07. El valor predeterminado es 00.
    sap_ers_instance_number Cadena Opcional. Especifica el número de instancia de ERS. El valor de sap_ers_instance_number debe ser un número de dos dígitos. Si necesitas especificar un solo número de dígitos, agrega un 0 delante del número. Por ejemplo, 07. El valor predeterminado es 10.
    sap_nw_abap Booleano Opcional. Especifica si implementas una pila de ABAP o una de Java de SAP NetWeaver. Para una pila de Java de SAP NetWeaver, especifica false. El valor predeterminado es true.
    pacemaker_cluster_name Cadena Opcional. Especifica un nombre para el clúster de pacemaker. El valor predeterminado es SAP_SID-cluster.
    public_ip Booleano Opcional. Si quieres crear una dirección IP pública efímera para las instancias de VM, configura public_ip como true. El valor predeterminado es false.
    service_account Cadena Opcional. Especifica la dirección de correo electrónico de una cuenta de servicio administrada por el usuario que usarán las VM del host y los programas que se ejecutan en las VM del host. Por ejemplo: svc-acct-name@project-id.iam.gserviceaccount.com.

    Si especificas este argumento sin un valor o lo omites, la secuencia de comandos de instalación usará la cuenta de servicio predeterminada de Compute Engine. A fin de obtener más información, consulta la sección sobre administración de identidades y accesos para programas SAP en Google Cloud.

    network_tags String Opcional. Especifica una o más etiquetas de red separadas por comas que desees asociar con tus instancias de VM para un firewall o enrutamiento.

    Una etiqueta de red para los componentes del ILB se agrega automáticamente a las etiquetas de red de la VM.

    Si public_ip = false y no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.

    sap_deployment_debug Booleano Opcional. Solo cuando Atención al cliente de Cloud te solicite habilitar la depuración para tu implementación, especifica true, lo que hace que la implementación genere registros de implementación con verbosidad. El valor predeterminado es false.
    primary_reservation_name Cadena Opcional. Especifica el nombre de la reserva para usar una reserva de VM de Compute Engine específica para aprovisionar la instancia de VM que aloja la instancia principal de SAP HANA de tu clúster de alta disponibilidad. De forma predeterminada, la secuencia de comandos de instalación selecciona cualquier reserva de Compute Engine disponible según las siguientes condiciones.

    Para que una reserva se pueda usar, sin importar si especificas un nombre o si la secuencia de comandos de instalación lo selecciona automáticamente, la reserva debe configurarse con lo siguiente:

    • La opción specificReservationRequired se configura como true o, en la consola de Google Cloud, la opción Seleccionar reserva específica está seleccionada.
    • Algunos tipos de máquinas de Compute Engine son compatibles con las plataformas de CPU que no están cubiertas por la certificación de SAP del tipo de máquina. Si la reserva de destino es para cualquiera de los siguientes tipos de máquina, la reserva debe especificar las plataformas de CPU mínimas como se indica:
      • n1-highmem-32: Broadwell de Intel
      • n1-highmem-64: Broadwell de Intel
      • n1-highmem-96: Intel Skylake
      • m1-megamem-96: Intel Skylake
      • Las plataformas de CPU mínimas para todos los demás tipos de máquinas certificados por SAP para su uso en Google Cloud cumplen con el requisito mínimo de CPU de SAP.
    secondary_reservation_name Cadena Opcional. Especifica el nombre de la reserva para usar una reserva de VM de Compute Engine específica para aprovisionar la instancia de VM que aloja la instancia secundaria de SAP HANA de tu clúster de alta disponibilidad. De forma predeterminada, la secuencia de comandos de instalación selecciona cualquier reserva de Compute Engine disponible según las siguientes condiciones.

    Para que una reserva se pueda usar, sin importar si especificas un nombre o si la secuencia de comandos de instalación lo selecciona automáticamente, la reserva debe configurarse con lo siguiente:

    • La opción specificReservationRequired se configura como true o, en la consola de Google Cloud, la opción Seleccionar reserva específica está seleccionada.
    • Algunos tipos de máquinas de Compute Engine son compatibles con las plataformas de CPU que no están cubiertas por la certificación de SAP del tipo de máquina. Si la reserva de destino es para cualquiera de los siguientes tipos de máquina, la reserva debe especificar las plataformas de CPU mínimas como se indica:
      • n1-highmem-32: Broadwell de Intel
      • n1-highmem-64: Broadwell de Intel
      • n1-highmem-96: Intel Skylake
      • m1-megamem-96: Intel Skylake
      • Las plataformas de CPU mínimas para todos los demás tipos de máquinas certificados por SAP para su uso en Google Cloud cumplen con el requisito mínimo de CPU de SAP.

    En el ejemplo siguiente, se muestra un archivo de configuración completo que define un clúster de alta disponibilidad para SAP NetWeaver. El clúster usa un balanceador de cargas de red de transferencia interno para administrar la VIP.

    Terraform implementa los recursos de Google Cloud que se definen en el archivo de configuración y, luego, las secuencias de comandos de inicio toman el control para configurar el sistema operativo y el clúster de HA de Linux.

    Para mayor claridad, los comentarios del archivo de configuración se omiten en el ejemplo.

       # ...
     module "sap_nw_ha" {
     source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # By default, this source file uses the latest release of the terraform module
   # for SAP on Google Cloud.  To fix your deployments to a specific release
   # of the module, comment out the source argument above and uncomment the source argument below.
   #
   # source = "https://storage.googleapis.com/cloudsapdeploy/terraform/202201240926/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # ...
   #
   project_id = "example-project-123456"
   machine_type = "n2-highmem-32"
   network = "example-network"
   subnetwork = "example-subnet-us-central1"
   linux_image = "rhel-8-4-sap-ha"
   linux_image_project = "rhel-sap-cloud"

   sap_primary_instance = "nw-ha-vm-1"
   sap_primary_zone = "us-central1-a"

   sap_secondary_instance = "nw-ha-vm-2"
   sap_secondary_zone = "us-central1-c"

   nfs_path = "10.223.55.130:/pr1_nw"

   sap_sid = "PR1"
   # ...
}

  5. Inicializa tu directorio de trabajo actual y descarga los archivos del módulo y el complemento del proveedor de Terraform para Google Cloud:

    terraform init

    El comando terraform init prepara tu directorio de trabajo para otros comandos de Terraform.

    Para forzar una actualización del complemento de proveedor y los archivos de configuración en tu directorio de trabajo, especifica la marca --upgrade. Si se omite la marca --upgrade y no realizas ningún cambio en tu directorio de trabajo, Terraform usa las copias almacenadas en caché de forma local, incluso si latest se especifica en la URL source.

    terraform init --upgrade

  6. De manera opcional, crea el plan de ejecución de Terraform:

    terraform plan

    El comando terraform plan muestra los cambios que requiere tu configuración actual. Si omites este paso, el comando terraform apply crea de forma automática un plan nuevo y te solicita que lo apruebes.

  7. Aplica el plan de ejecución:

    terraform apply

    Cuando se te solicite aprobar las acciones, ingresa yes.

    El comando terraform apply configura la infraestructura de Google Cloud y, luego, entrega el control a una secuencia de comandos que configura el clúster de HA de acuerdo con los argumentos definidos en el archivo de configuración de Terraform.

    Mientras Terraform tiene control, los mensajes de estado se escriben en Cloud Shell. Una vez que se invocan las secuencias de comandos, los mensajes de estado se escriben en Logging y se pueden ver en la consola de Google Cloud, como se describe en Verifica los registros de Logging.

    El tiempo de finalización puede variar, pero todo el proceso suele tardar menos de 30 minutos.

Verifica la implementación de tu sistema SAP NetWeaver de HA

La verificación de un clúster de alta disponibilidad de SAP NetWeaver implica varios procedimientos diferentes:

  • Verifica los registros
  • Verifica la configuración de la VM

Verifica los registros

  1. En la consola de Google Cloud, abre Cloud Logging para supervisar el progreso de la instalación y verificar si hay errores.

    Ir a Cloud Logging

  2. Filtra los registros:

    Explorador de registros

    1. En la página Explorador de registros, ve al panel Consulta.

    2. En el menú desplegable Recurso, selecciona Global y, luego, haz clic en Agregar.

      Si no ves la opción Global, ingresa la siguiente consulta en el editor de consultas:

      resource.type="global"
"Deployment"

    3. Haz clic en Ejecutar consulta.

    Visor de registros heredado

    • En la página Visor de registros heredado, en el menú del selector básico, selecciona Global como tu recurso de registro.

  3. Analiza los registros filtrados:

    • Si se muestra "--- Finished", el proceso de implementación está completo y puedes continuar con el siguiente paso.

    • Si ves un error de cuota, sigue estos pasos:

      1. En la página Cuotas de IAM y administración, aumenta cualquiera de las cuotas que no cumplan con los requisitos de SAP NetWeaver que se enumeran en la Guía de planificación de SAP NetWeaver.

      2. Abra Cloud Shell.

        Ir a Cloud Shell

      3. Ve al directorio de trabajo y borra la implementación para limpiar las VM y los discos persistentes de la instalación fallida:

        terraform destroy

        Cuando se te solicite aprobar la acción, ingresa yes.

      4. Vuelve a ejecutar tu implementación.

Verifica la configuración de la VM

  1. Después de que las instancias de VM se implementen sin errores, conéctate a cada una mediante SSH. En la página Instancias de VM de Compute Engine, puedes hacer clic en el botón SSH para cada instancia de VM o usar tu método SSH preferido.

  2. Cambia al usuario raíz.

    sudo su -

  3. En el símbolo del sistema, ingresa df -h. Asegúrate de ver un resultado que incluya los directorios /usr/sap, como /usr/sap/trans. 

    nw-ha-vm-1:~ # df -h
Filesystem                             Size  Used Avail Use% Mounted on
...
/dev/mapper/vg_usrsap-vol              8.0G  242M  7.8G   3% /usr/sap
/dev/mapper/vg_sapmnt-vol              8.0G   90M  7.9G   2% /sapmnt
10.95.255.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
10.95.255.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
10.95.255.130:/pr1_nw/usrsapPR1ASCS00 1007G     0  956G   0% /usr/sap/PR1/ASCS00
...
    autofs se configura de forma automática durante la implementación para activar los directorios de archivos compartidos comunes cuando se accede a ellos por primera vez. El software del clúster, que también se configura durante la implementación, administra la activación de los directorios ASCSASCS_INSTANCE_NUMBER y ERSERS_INSTANCE_NUMBER.

  4. Para verificar el estado del clúster nuevo, ingresa el comando de estado: pcs status

    Deberías ver resultados similares al siguiente ejemplo, en el que se inician ambas instancias de VM y nw-ha-vm-1 es la instancia principal activa: 

    nw-ha-vm-1:~ # pcs status
Cluster name: pr1-cluster
Cluster Summary:
* Stack: corosync
* Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
* Last updated: Mon Aug 29 18:03:22 2022
* Last change:  Mon Aug 29 17:58:21 2022 by root via cibadmin on nw-ha-vm-1
* 2 nodes configured
* 8 resource instances configured
Node List:
* Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
Full List of Resources:
* fence-PR1-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
* fence-PR1-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
* file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
* file-system-PR1-ERS10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
* health-check-PR1-ASCS00    (service:haproxy@PR1ASCS):     Started nw-ha-vm-1
* health-check-PR1-ERS10    (service:haproxy@PR1ERS):     Started nw-ha-vm-2
* vip-PR1-ASCS00    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-1
* vip-PR1-ERS10    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-2
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

  5. Prueba la configuración del balanceador de cargas de ASCS y ERS con la utilidad socat:

    1. En cada instancia de VM, inicia de forma temporal un proceso socat que muestre su propio nombre de host:

      socat TCP-LISTEN:80,bind=0.0.0.0,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; echo $(hostname)" &

    2. En cada nodo, usa curl y, luego, intenta acceder a las siguientes direcciones IP y nombres de host. Las direcciones IP y los nombres de host se pueden encontrar en /etc/hosts.

      • 127.0.0.1
      • localhost
      • ASCS_VIRTUAL_HOST_NAME
      • ASCS_IP_ADDRESS
      • ERS_VIRTUAL_HOST_NAME
      • ERS_IP_ADDRESS
      • Nombre VIP de SCS, que se especifica para el parámetro scs_vip_name
      • Dirección IP de VIP de SCS, que se especifica para el parámetro scs_vip_address
      • Nombre de VIP de ERS, que se especifica para el parámetro ers_vip_name
      • Dirección IP de ERS VIP, que se especifica para el parámetro ers_vip_address

    El siguiente es un resultado de ejemplo de esa prueba:

    example-nw1:~ # cat /etc/hosts
...
10.128.1.182 example-nw1.c.myproject.internal example-nw1
10.128.1.169 example-nw2.c.myproject.internal example-nw2
10.128.1.46 pr1-scs-vip.c.myproject.internal pr1-scs-vip
10.128.0.75 pr1-ers-vip.c.myproject.internal pr1-ers-vip
example-nw1:~ # curl 127.0.0.1
example-nw1
example-nw1:~ # curl localhost
example-nw1
example-nw1:~ # curl example-nw1
example-nw1
example-nw1:~ # curl 10.128.1.182
example-nw1
example-nw1:~ # curl example-nw2
example-nw2
example-nw1:~ # curl 10.128.1.169
example-nw2
example-nw1:~ # curl pr1-scs-vip
example-nw1
example-nw1:~ # curl 10.128.1.46
example-nw1
example-nw1:~ # curl pr1-ers-vip
example-nw2
example-nw1:~ # curl 10.128.0.75
example-nw2

  6. Si usas RHEL para SAP 9.0 o una versión posterior, asegúrate de que los paquetes chkconfig y compat-openssl11 estén instalados en la instancia de VM.

    Para obtener más información de SAP, consulta la Nota 3108316 de SAP: Red Hat Enterprise Linux 9.x: Instalación y configuración.

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

  1. Resuelve los errores.

  2. Abra Cloud Shell.

    Ir a Cloud Shell

  3. Ve al directorio que contiene el archivo de configuración de Terraform.

  4. Borra la implementación:

    terraform destroy

    Cuando se te solicite aprobar la acción, ingresa yes.

  5. Vuelve a ejecutar tu implementación.

Valida la instalación del agente de Google Cloud para SAP

Después de que hayas implementado una VM y le hayas instalado SAP NetWeaver, valida que el Agente de Google Cloud para SAP funcione de forma correcta.

Verifica que el Agente de Google Cloud para SAP esté en ejecución

Para verificar que el agente esté en ejecución, sigue estos pasos:

  1. Establece una conexión SSH con la instancia de VM del host.

  2. Ejecuta el siguiente comando: 

    systemctl status google-cloud-sap-agent

    Si el agente funciona de forma correcta, el resultado contendrá active (running). Por ejemplo: 

    google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

Si el agente no está en ejecución, reinicia el agente.

Verifica que el agente de host SAP reciba métricas

Para verificar que el Agente de Google Cloud para SAP recopile las métricas de infraestructura y que se envíen de forma correcta al agente de host SAP, sigue estos pasos:

  1. En el sistema SAP, ingresa la transacción ST06.

  2. En el panel de descripción general, revisa la disponibilidad y el contenido de los siguientes campos para verificar la configuración completa y correcta de la infraestructura de supervisión de SAP y Google:

    • Proveedor de servicios en la nube: Google Cloud Platform
    • Acceso de supervisión mejorada: TRUE
    • Detalles de supervisión mejorada: ACTIVE

Instala ASCS 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 ASCS 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:

    # sudo pcs property set 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_LCadm -g sapsys
# usermod -a -G sapinst SID_LCadm
# useradd -u UID_SAPADM sapadm -g sapinst

# chown SID_LCadm:sapsys /usr/sap/SID/SYS
# chown SID_LCadm:sapsys /sapmnt/SID -R
# chown SID_LCadm:sapsys /usr/sap/trans -R
# chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
# chown SID_LCadm:sapsys /usr/sap/SID -R

    Reemplaza lo siguiente:

    • GID_SAPINST: Especifica el ID de grupo de Linux para la herramienta de aprovisionamiento de SAP.
    • GID_SAPSYS: Especifica el ID de grupo de Linux para el usuario SAPSYS.
    • UID_SIDADM: Especifica el ID de usuario de Linux para el administrador del sistema SAP (SID).
    • SID_LC: Especifica el ID del sistema (SID). Usa minúsculas para las letras.
    • UID_SAPADM: Especifica el ID de usuario para SAP Host Agent.
    • SID: Especifica el ID del sistema (SID). Usa mayúsculas para las letras.

    Por ejemplo, a continuación se muestra un esquema práctico de numeración de GID y UID:

    Group sapinst      1001
Group sapsys       1002
Group dbhshm       1003

User  en2adm       2001
User  sapadm       2002
User  dbhadm       2003

Instala el componente ASCS

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

    # pcs node standby

    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:

    # pcs status

    Deberías ver un resultado similar al siguiente: 

    Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured

   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

   Full List of Resources:
     * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
       * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1

   Daemon Status:
     corosync: active/enabled

  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 ASCS. 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 ASCS 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:

    # pcs node unstandby

Instala el componente ERS

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

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
# su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"

  2. En el servidor principal, ingresa el siguiente comando para poner el servidor principal en modo de espera:

    # pcs node standby

    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:

    # pcs 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 ASCS.

    • 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:

    # pcs node unstandby

Configura los servicios de SAP

Debes confirmar que los servicios estén configurados correctamente y verificar la configuración en los perfiles de ASCS y ERS.

Detén los servicios de SAP

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

    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
# su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"

  2. En cada servidor, verifica que todos los servicios estén detenidos:

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
# su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

    Deberías ver un resultado similar al siguiente:

    GetSystemInstanceList
FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Inhabilita el reinicio automático de servicios en SAP

Debido a que el software del clúster administra el reinicio de los servicios de SAP durante una conmutación por error, para evitar conflictos, inhabilita la capacidad del software de SAP para reiniciar los servicios de forma automática.

  1. En ambos nodos, edita el archivo /usr/sap/sapservices para inhabilitar el reinicio automático en el software de SAP mediante la adición de un carácter de comentario, #, al comienzo del comando sapstartsrv para componentes de ASCS y ERS.

    Por ejemplo:

    #!/bin/sh

 #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
 #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm

Edita los perfiles de ASCS 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_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
     
    SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

  3. 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.

  4. 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) ...

Configura los recursos del clúster para ASCS y ERS

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

    # pcs property set maintenance-mode="true"

  2. Confirma que el clúster esté en modo de mantenimiento:

    # pcs status

  3. Crea los recursos del clúster para los servicios de ASCS y ERS:

    ENSA1

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

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
    InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
    failure-timeout=60  --group ASCS_RESOURCE_GROUP \
    op monitor interval=20 on-fail=restart timeout=60 \
    op start interval=0 timeout=600 \
    op stop interval=0 timeout=600

      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

    • 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.

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
    InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
    op monitor interval=20 on-fail=restart timeout=60 \
    op start interval=0 timeout=600 \
    op stop interval=0 timeout=600

    ENSA2

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

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
    InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
    --group ASCS_RESOURCE_GROUP \
    op monitor interval=20 on-fail=restart timeout=60 \
    op start interval=0 timeout=600 \
    op stop interval=0 timeout=600

      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

    • 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.

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
    InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
    op monitor interval=20 on-fail=restart timeout=60 \
    op start interval=0 timeout=600 \
    op stop interval=0 timeout=600

Configura las limitaciones de ubicación y orden

Crea restricciones para definir qué servicios deben iniciarse primero y qué servicios deben ejecutarse juntos en el mismo host. Por ejemplo, la dirección IP debe estar en el mismo host que la instancia principal de SAP Central Services.

  1. Define la restricción del orden de inicio:

ENSA1

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

    # pcs constraint colocation add ERS_RESOURCE_GROUP with \
    ASCS_RESOURCE_GROUP -5000

  2. Configura ASCS 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:

    # pcs constraint location ASCS_INSTANCE \
    rule score=2000 runs_ers_SID eq 1

  3. Configura ASCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
    stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional

ENSA2

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

    # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
    ASCS_RESOURCE_GROUP -5000

  2. Configura ASCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
    stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional

  1. Comprueba las restricciones:

    # pcs constraint

    Debería ver un resultado similar al siguiente:

    Location Constraints:
  Resource: ascs-aha-instance
    Constraint: location-ascs-instance
      Rule: score=2000
        Expression: runs_ers_HKN eq 1
  Resource: fence-nw-ha-vm-1
    Disabled on: nw-ha-vm-1 (score:-INFINITY)
  Resource: fence-nw-ha-vm-2
    Disabled on: nw-ha-vm-2 (score:-INFINITY)
Ordering Constraints:
  start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
Colocation Constraints:
  ascs-group with ers-group (score:-5000)
Ticket Constraints:

  2. Como raíz desde cualquiera de los servidores, inhabilita el modo de mantenimiento del clúster:

    # pcs property set maintenance-mode="false"

Configura el conector de clústeres de Red Hat para SAP

En cada host del clúster, configura SAP Start Service sapstartsrv para que se comunique con el software del clúster de Pacemaker a través de la interfaz de alta disponibilidad.

  1. Agrega el usuario administrativo de SAP al grupo haclient:

    usermod -a -G haclient SID_LCadm

  2. Edita los perfiles de instancia de SAP y agrega las siguientes líneas al final de cada perfil. Los perfiles se pueden encontrar en el directorio /sapmnt/SID/profiles.

    service/halib = $(DIR_CT_RUN)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_cluster_connector

  3. Si los recursos de instancia de ASCS y ERS se están ejecutando actualmente en el clúster, inhabilítalos:

    pcs resource disable ERS_INSTANCE_RESOURCE
pcs resource disable ASCS_INSTANCE_RESOURCE

  4. Detén los servicios en el host de ASCS:

    sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

  5. Detén los servicios en el host de ERS:

    sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

  6. Habilita los recursos:

    pcs resource enable ERS_INSTANCE_RESOURCE
pcs resource enable ASCS_INSTANCE_RESOURCE

  7. Repite los pasos anteriores en cada host del clúster.

Si deseas obtener más información de Red Hat, consulta Cómo configurar SAP halib para los recursos SAPInstance en RHEL 7 y 8.

Instala la base de datos y los servidores de aplicaciones en hosts fuera del clúster

En la configuración de alta disponibilidad, te recomendamos que instales los servidores de aplicaciones y la base de datos en hosts diferentes de los hosts de ASCS y ERS en el clúster.

Mediante el uso de hosts independientes para cada servidor, se reduce la complejidad y el riesgo de una falla que afecte a varios servidores, y se puede adaptar el tamaño de cada Compute Engine a cada tipo de servidor.

Esto te permite elegir el tamaño de máquina certificada más adecuado, evitar fallas y reducir la complejidad.

La instalación de la base de datos y los servidores de aplicaciones no se trata en esta guía.

Para obtener información sobre cómo instalar los servidores de bases de datos, consulta los siguientes vínculos:

Valida y prueba el 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 ASCS y ERS cambien de servidor correctamente durante las conmutaciones por error
  • Confirma que los bloqueos estén retenidos
  • Simula un evento de mantenimiento de Compute Engine para asegurarte de que la migración en vivo no active una conmutación por error

Verifica la configuración del clúster

  1. Como raíz en cualquiera de los servidores, verifica en qué nodos se están ejecutando los recursos:

    # pcs status

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

    Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

  Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

  2. Cambia al usuario SID_LCadm.

    # su - SID_LCadm

  3. Verifica la configuración del clúster. Para INSTANCE_NUMBER, especifica el número de la instancia de ASCS o ERS que está activa 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:

    HAGetFailoverConfig

14.04.2022 17:25:45
HAGetFailoverConfig
OK
HAActive: TRUE
HAProductVersion: Pacemaker
HASAPInterfaceVersion: sap_cluster_connector
HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
HAActiveNode:
HANodes:

  4. Como SID_LCadm, verifica si hay errores en la configuración:

    > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

    Deberías ver un resultado similar al siguiente:

    14.04.2022 21:43:39
HACheckConfig
OK
state, category, description, comment
SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP 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 (vip-ascs_NWT_00), SAPInstance includes is-ers patch
SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

  5. En el servidor en el que ASCS está activo, como SID_LCadm, simula una conmutación por error:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

  6. Como raíz, si sigues la conmutación por error mediante crm_mon, deberías ver que ASCS se mueve al otro servidor, y que ERS se detiene en ese servidor y que se traslada al servidor en el que se solía ejecutar ASCS.

Simula una conmutación por error

Simula una falla en el host principal para probar el clúster. Usa un sistema de prueba o ejecuta la prueba en tu sistema de producción antes de lanzar el sistema para su uso.

Puedes simular una falla de varias maneras, incluidas las siguientes:

  • shutdown -r (en el nodo activo)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

En estas instrucciones, se usa ip link set eth0 down para desconectar la interfaz de red, ya que valida la conmutación por error y la protección.

  1. Realiza una copia de seguridad de tu sistema.

  2. Como raíz en el host con la instancia de SCS activa, desconecta la interfaz de red:

    $ ip link set eth0 down

  3. Vuelve a conectarte a cualquier host mediante SSH y cambia al usuario raíz.

  4. Ingresa pcs status para confirmar que el host principal ahora está activo en la VM que contenía el host secundario. El reinicio automático está habilitado en el clúster, por lo que el host detenido se reiniciará y asumirá la función de host secundario, como se muestra en el siguiente ejemplo.

     Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

  Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

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 de 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 ASCS se vuelve a activar.

ENSA1

  1. Como SID_LCadm, 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_LCadm, en el servidor en el que ASCS está activo, verifica que se registren las entradas de bloqueo:

    > sapcontrol -nr ASCS_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_LCadm, 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 ASCS 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 SID_LCadm, 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_LCadm, en el servidor en el que está activo ASCS, verifica que se quiten las entradas de bloqueo:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

  1. Como SID_LCadm, en el servidor en el que ASCS 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_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

  2. Como SID_LCadm, en el servidor en el que ASCS está activo, verifica que se registren las entradas de bloqueo:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

    locks_now: 10

  3. Cuando ERS esté activo, confirma que las entradas de bloqueo se hayan replicado:

    > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    La cantidad de bloqueos que se muestran debe ser la misma que la de la instancia de ASCS.

  4. Cuando ASCS esté activo, reinicia el servidor.

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

    # crm_mon

  6. Como SID_LCadm, en el servidor en el que se reinició ASCS, verifica que se hayan retenido las entradas de bloqueo:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

  7. Como SID_LCadm 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

  8. Como SID_LCadm, en el servidor en el que está activo ASCS, verifica que se quiten las entradas de bloqueo:

    > sapcontrol -nr ASCS_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 se tienen en cuenta para la duración de las migraciones en vivo. Si usas valores más cortos en la configuración de tu clúster, 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 de la CLI de gcloud:

    $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

  2. Confirma que el nodo principal no cambie:

    $ pcs status

Evalúa la carga de trabajo de SAP NetWeaver

Para automatizar las verificaciones de validación continua de las cargas de trabajo de alta disponibilidad de SAP NetWeaver que se ejecutan en Google Cloud, puedes usar Workload Manager.

Workload Manager te permite analizar y evaluar de forma automática las cargas de trabajo de alta disponibilidad de SAP NetWeaver con las prácticas recomendadas de SAP, Google Cloud y los proveedores del SO. Esto ayuda a mejorar la calidad, el rendimiento y la confiabilidad de tus cargas de trabajo.

Si deseas obtener información sobre las prácticas recomendadas que admite el administrador de cargas de trabajo para evaluar las cargas de trabajo de alta disponibilidad de SAP NetWeaver que se ejecutan en Google Cloud, consulta Prácticas recomendadas de administrador de cargas de trabajo para SAP. Para obtener información sobre cómo crear y ejecutar una evaluación mediante Workload Manager, consulta Crea y ejecuta una evaluación.

Soluciona problemas

A fin de solucionar problemas de configuraciones de alta disponibilidad para SAP NetWeaver, consulta Solución de problemas de configuraciones de alta disponibilidad para SAP.

Recopila información de diagnóstico para los clústeres de alta disponibilidad de SAP NetWeaver

Si necesitas ayuda para resolver un problema con los clústeres de alta disponibilidad para SAP NetWeaver, recopila la información de diagnóstico requerida y comunícate con el servicio de Atención al cliente de Cloud.

Para recopilar información de diagnóstico, 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 la consola de Google Cloud. 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.

Para 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, consulta la Guía de operaciones de SAP NetWeaver.

¿Qué sigue?

Para obtener más información sobre la alta disponibilidad, SAP NetWeaver y Google Cloud, consulta los siguientes recursos: