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

En esta guía, se muestra cómo automatizar la implementación de un clúster de alta disponibilidad (HA) de SUSE Linux Enterprise Server (SLES) optimizado para SAP NetWeaver.

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 HANA en Red Hat Enterprise Linux (RHEL), consulta la guía de configuración manual de clústeres de alta disponibilidad para SAP NetWeaver en RHEL.

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

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 para crear un clúster de SLES con dos sistemas SAP NetWeaver: un sistema SAP NetWeaver principal de host único en una instancia de VM y un sistema SAP NetWeaver en espera en otra instancia de VM en la misma región de Compute Engine.

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 sap_nw_ha.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, sles-15-sp5-sap. 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 suse-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 toman el control del sistema operativo y del 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 = "sles-15-sp3-sap"
       linux_image_project = "suse-sap-cloud"
    
       sap_primary_instance = "example-nw1"
       sap_primary_zone = "us-central1-a"
    
       sap_secondary_instance = "example-nw2"
       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.

    example-nw1:~ # df -h
      Filesystem                             Size  Used Avail Use% Mounted on
      ...
      /dev/mapper/vg_usrsap-vol              8.0G   41M  8.0G   1% /usr/sap
      /dev/mapper/vg_sapmnt-vol              8.0G   41M  8.0G   1% /sapmnt
      10.233.55.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
      10.223.55.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
      10.223.55.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: crm status

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

    example-nw1:~ # crm status
    Cluster Summary:
      * Stack: corosync
      * Current DC: example-nw1 (version 2.0.4+20200616.2deceaa3a-3.6.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Fri Jun 18 05:47:48 2021
      * Last change:  Fri Jun 18 05:41:32 2021 by root via cibadmin on example-nw1
      * 2 nodes configured
      * 8 resource instances configured
    Node List:
      * Online: [ example-nw1 example-nw2 ]
    Full List of Resources:
      * fence-PR1-example-nw1     (stonith:fence_gce):           Started example-nw2
      * fence-PR1-example-nw2     (stonith:fence_gce):           Started example-nw1
      * file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):      Started example-nw1
      * file-system-PR1-ERS10     (ocf::heartbeat:Filesystem):      Started example-nw2
      * health-check-PR1-ASCS00   (ocf::heartbeat:anything):        Started example-nw1
      * health-check-PR1-ERS10    (ocf::heartbeat:anything):        Started example-nw2
      * vip-PR1-ASCS00      (ocf::heartbeat:IPaddr2):             Started example-nw1
      * vip-PR1-ERS10       (ocf::heartbeat:IPaddr2):             Started example-nw2

  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

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:

    # 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_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:

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

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

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:

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

    # 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 SID_LCadm al grupo de usuarios haclient.

Confirma las entradas de servicio de SAP

  1. En ambos servidores, confirma que el archivo /usr/sap/sapservices contenga entradas para los servicios ASCS y ERS. Para hacerlo, puedes usar la integración systemV o systemd.

    Puedes agregar cualquier entrada faltante a través del comando sapstartsrv con las opciones pf=PROFILE_OF_THE_SAP_INSTANCE y -reg.

    Para obtener más información sobre estas integraciones, consulta las siguientes Notas de SAP:

    systemV

    El siguiente es un ejemplo de cómo apaecen las entradas para los servicios de ASCS y ERS en el archivo /usr/sap/sapservices cuando usas la integración systemV:

    # 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 \
    -D -u SID_LCadm
    /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    -D -u SID_LCadm

    systemd

    1. Verifica que tu archivo /usr/sap/sapservices contenga entradas para los servicios de ASCS y ERS. El siguiente es un ejemplo de cómo aparecen estas entradas en el archivo /usr/sap/sapservices cuando usas la integración systemd:

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
    2. Inhabilita la integración systemd en las instancias de ASCS y ERS:

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
      
    3. Verifica que la integración systemd esté inhabilitada:

      # systemctl list-unit-files | grep sap

      Un resultado similar al siguiente ejemplo significa que la integración systemd está inhabilitada. Ten en cuenta que algunos servicios, como saphostagent y saptune, están habilitados y otros no lo están.

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

      Para obtener más información, consulta el documento de SUSE Inhabilita los servicios systemd de las instancias de SAP 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()

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. 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 SID_LCadm trabaje con el clúster, agrégalo al grupo de usuarios haclient.

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

    # usermod -aG haclient SID_LCadm

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:

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

      # crm configure primitive ASCS_INSTANCE_RSC_NAME SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_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 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.

      # crm configure primitive ASCS_INSTANCE_RSC_NAME SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_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 de ASCS y ERS. Puedes mostrar los nombres de todos los recursos definidos con anterioridad si ingresas el comando crm resource status:

    # crm configure group ASCS_RSC_GROUP_NAME ASCS_FILE_SYSTEM_RSC_NAME \
      ASCS_HEALTH_CHECK_RSC_NAME ASCS_VIP_RSC_NAME \
      ASCS_INSTANCE_RSC_NAME \
      meta resource-stickiness=3000

    Reemplaza lo siguiente:

    • ASCS_RESOURCE_GROUP: Especifica un nombre de grupo único para los recursos del clúster de ASCS. Puedes garantizar la exclusividad con una convención como “SID_ASCSinstance number_group”. Por ejemplo, nw1_ASCS00_group.
    • ASCS_FILE_SYSTEM_RESOURCE: Especifica el nombre de recurso del clúster que definiste para el sistema de archivos ASCS antes.
    • ASCS_HEALTH_CHECK_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la verificación de estado de ASCS antes.
    • ASCS_VIP_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la VIP de ASCS antes.
    • ASCS_INSTANCE_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la instancia de ASCS antes.
    # 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

    Reemplaza lo siguiente:

    • ERS_RESOURCE_GROUP: Especifica un nombre de grupo único para los recursos del clúster de ERS. Puedes garantizar la exclusividad con una convención como “SID_ERSinstance number_group”. Por ejemplo, nw1_ERS10_group.
    • ERS_FILE_SYSTEM_RESOURCE: Especifica el nombre de recurso del clúster que definiste para el sistema de archivos ERS antes.
    • ERS_HEALTH_CHECK_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la verificación de estado de ERS antes.
    • ERS_VIP_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la VIP de ERS antes.
    • ERS_INSTANCE_RESOURCE: Especifica el nombre de recurso del clúster que definiste para la instancia de ERS antes.
  2. Crea las restricciones de colocación:

    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:

      # crm configure colocation PREVENT_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME
    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:

      # crm configure location LOC_ASCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RSC_NAME \
      rule 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:

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_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 ASCS se ejecuten en el mismo servidor que los recursos de ERS:

      # crm configure colocation PREVENT_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME
    2. Configura ASCS 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: ASCS_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

Valida y 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 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:

    # crm status

    En el siguiente ejemplo, los recursos de ASCS 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: ascs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-ascs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-ascs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * ascs-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
  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:

    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 SID_LCadm, 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-ascs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active

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

    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: Fri May 21 22:31:32 2021
    * Last change:  Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1
    * 2 nodes configured
    * 10 resource instances configured
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of 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-2
      * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
      * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
      * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
    * Resource Group: ers-aha-rsc-group-name:
      * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
      * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
      * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
      * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1

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:

    # crm 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 SLES.

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: