Se usó la API de Cloud Translation para traducir esta página.

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. La configuración de Simple Mount también se proporciona para SLES 15 para SAP y versiones posteriores.

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:

Leíste la Guía de planificación de SAP NetWeaver y la Guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud.
Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP NetWeaver. Si deseas obtener información sobre cómo crear cuentas y proyectos de Google Cloud, consulta Crea un proyecto en la Guía de implementación de SAP NetWeaver para Linux.
Si necesitas que tu carga de trabajo de SAP se ejecute de acuerdo con los requisitos de residencia de datos, control de acceso, personal de asistencia o reglamentario, debes crear la carpeta de cargas de trabajo de Assured Workloads requerida. A fin de obtener más información, consulta Cumplimiento y controles soberanos para SAP en Google Cloud.
Si usas un DNS interno de VPC, entonces el valor de la variable vmDnsSetting en los metadatos del proyecto debe ser GlobalOnly o ZonalPreferred para habilitar la resolución de los nombres del nodo entre zonas. La configuración predeterminada de vmDnsSetting es ZonalOnly. Para obtener más información, consulta:
Configuraste un recurso compartido de archivos con una solución de almacenamiento de archivos compartidos de NFS, como Filestore Enterprise.
Si el Acceso al SO está habilitado en los metadatos del proyecto, debes inhabilitar el Acceso al SO de forma temporal hasta que se complete la implementación. Para fines de implementación, este procedimiento configura las claves SSH en metadatos de instancia. Cuando el acceso al SO está habilitado, la configuración de las claves SSH basada en metadatos se inhabilita y esta implementación falla. Una vez terminada la implementación, puedes volver a habilitar el acceso al SO.

Para obtener más información, consulte:
- Cómo habilitar o inhabilitar el acceso al SO
- Agrega claves SSH a las VM que usan claves SSH basadas en metadatos

Información relacionada de SUSE

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:

Crea una red de modo personalizado. Para obtener más información, consulta Cómo crear una red de modo personalizado.
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.

Abre Cloud Shell.

Ir a Cloud Shell
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
```
Nota: Asegúrate de tener solo un archivo de configuración de Terraform en tu directorio de trabajo.
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.

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.

Argumento	Tipo de datos	Descripción
`source`	String	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`	String	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`	String	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`	String	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`	String	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`. Nota: El punto de activación de NFS para el sistema de archivos compartidos debe estar vacío antes de aplicar la configuración de Terraform.
`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`	String	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`	String	Opcional. Especifica un nombre para el grupo de instancias de ASCS. El valor predeterminado es `SAP_SID-scs-ig`.
`scs_hc_name`	String	Opcional. Especifica un nombre para la verificación de estado de ASCS. El valor predeterminado es `SAP_SID-scs-hc`.
`scs_hc_port`	String	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`	String	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`	String	Opcional. Especifica un nombre para el servicio de backend de ASCS. El valor predeterminado es `SAP_SID-scs-backend-svc`.
`scs_forw_rule_name`	String	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`	String	Opcional. Especifica un nombre para el grupo de instancias de ERS. El valor predeterminado es `SAP_SID-ers-ig`.
`ers_hc_name`	String	Opcional. Especifica un nombre para la verificación de estado de ERS. El valor predeterminado es `SAP_SID-ers-hc`.
`ers_hc_port`	String	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`	String	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`	String	Opcional. Especifica un nombre para el servicio de backend de ERS. El valor predeterminado es `SAP_SID-ers-backend-svc`.
`ers_forw_rule_name`	String	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`.
`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`	String	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`	String	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`	String	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`. Precaución: Cuando `public_ip` sea `false`, asegúrate de tener una puerta de enlace NAT configurada con una etiqueta de red definida para la VM o de que proporcionaste a la VM otra ruta a Internet. Si no hay una ruta a Internet, la instalación falla.
`service_account`	String	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`	String	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`	String	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.
`can_ip_forward`	Booleano	Especifica si se permite el envío y la recepción de paquetes con IP de origen o destino que no coincidan, lo que permite que una VM actúe como un router. El valor predeterminado es `true`. Si solo deseas usar los balanceadores de cargas internos de Google para administrar las IP virtuales de las VMs implementadas, establece el valor en `false`. Un balanceador de cargas interno se implementa automáticamente como parte de las plantillas de alta disponibilidad.

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

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 
```
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.
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 alta disponibilidad

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

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

Nota: Es posible que generes costos cuando completes este paso en Cloud Logging. Para obtener más información, consulta Precios de Cloud Logging.

Ir a Cloud Logging
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.
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

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.
Cambia al usuario raíz.
```
sudo su -
```

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/usrsapPR1       1007G     0  956G   0% /usr/sap/PR1
  ...

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.

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

Si usas una configuración de activación simple, verás un resultado similar al siguiente ejemplo:

Stack: corosync
Current DC: example-nw1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
Last updated: Wed Sep 26 19:10:10 2024
Last change: Tue Sep 25 23:48:35 2024 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
  * 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

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

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)" &

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:

Resuelve los errores.
Abra Cloud Shell.

Ir a Cloud Shell
Ve al directorio que contiene el archivo de configuración de Terraform.
Borra la implementación:
```
terraform destroy
```
Cuando se te solicite aprobar la acción, ingresa yes.
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:

Establece una conexión SSH con tu instancia de Compute Engine.

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:

En el sistema SAP, ingresa la transacción ST06.
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.

Quita el clúster del modo de mantenimiento:

# crm configure property maintenance-mode="false"

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

Si usas una configuración de activación simple, ejecuta los siguientes comandos en ambos servidores como root. Especifica los IDs 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
# chown SID_LCadm:sapsys /sapmnt/SID -R
# chown SID_LCadm:sapsys /usr/sap/trans -R
# chown SID_LCadm:sapsys /usr/sap/SID -R
# chown SID_LCadm:sapsys /usr/sap/SID/SYS

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

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.

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

# crm status

El resultado es similar al siguiente ejemplo.

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

Si usas una configuración de activación simple, el resultado es similar al siguiente:

Stack: corosync
 Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
 Last updated: Wed Sep 26 19:30:10 2024
 Last change: Tue Sep 25 23:58:35 2024 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
  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

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

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"

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.
Confirma que el servidor principal esté en modo de espera:
```
# crm status
```
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.
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

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:
- 3139184: Linux: integración de systemd para sapstartsrv y SAP Host Agent
- 3115048: sapstartsrv con compatibilidad nativa con systemd en Linux
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:
  
  Precaución: Inhabilitar la integración systemd también detiene las instancias de SAP.
  # 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

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"

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()

Habilita `sapping` y `sappong`

Debido a que Pacemaker administra los procedimientos de inicio y detención en el clúster, debes asegurarte de que sapstartsrv no se inicie automáticamente durante el inicio del sistema. Durante el inicio del sistema, sapping se ejecuta antes de sapinit, que oculta los archivos sapservices. Cuando se completa sapinit, sappong muestra los archivos sapservices.

Para activar este flujo, debes habilitar los servicios systemd sapping y sappong con los siguientes comandos:

# systemctl enable sapping sappong
# systemctl status sapping sappong

Edita los perfiles de ASCS y ERS

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
```
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
```

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

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

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

Como raíz de cualquiera de los servidores, coloca el clúster en modo de mantenimiento:
```
# crm configure property maintenance-mode="true"
```

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

Si usas una configuración de activación simple, crea los recursos del clúster sapstartsrv para los servicios de ASCS y ERS. Si no usas una configuración de activación simple, omite este paso.
1. Para ASCS, crea un archivo de configuración llamado sapstartsrv_scs.txt con el siguiente contenido:
```
primitive rsc_SAPStartSrv_SID_ASCSINSTANCENUMBER ocf:suse:SAPStartSrv \
params InstanceName=SID_ASCSINSTANCE_NUMBER_ASCS_VIRTUAL_HOSTNAME
```
2. Para cargar la configuración de ASCS, ejecuta el siguiente comando:
```
# crm configure load update sapstartsrv_scs.txt
```
3. Para ERS, crea un archivo de configuración llamado sapstartsrv_ers.txt con el siguiente contenido:
```
primitive rsc_SAPStartSrv_SID_ERSINSTANCENUMBER ocf:suse:SAPStartSrv \
params InstanceName=SID_ERSINSTANCE_NUMBER_ERS_VIRTUAL_HOSTNAME
```
4. Para cargar la configuración de ERS, ejecuta el siguiente comando:
```
# crm configure load update sapstartsrv_ers.txt
```

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_RESOURCE 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

Si usas una configuración de activación simple, ejecuta el siguiente comando:

# crm configure primitive ASCS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true \
  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_RESOURCE 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

Si usas una configuración de activación simple, ejecuta el siguiente comando:

# crm configure primitive ERS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true IS_ERS=true \
  meta priority=1000

Confirma la configuración recién creada:

# crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

El resultado es similar al siguiente ejemplo:

primitive ASCS_INSTANCE_RESOURCE 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


primitive ERS_INSTANCE_RESOURCE 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

Si usas una configuración de activación simple, el resultado es similar al siguiente ejemplo:

primitive ASCS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true \
meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10


primitive ERS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true 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_RESOURCE 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

Si usas una configuración de activación simple, ejecuta el siguiente comando en su lugar:

# crm configure primitive ASCS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true \
  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_RESOURCE 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

Si usas una configuración de activación simple, ejecuta el siguiente comando en su lugar:

# crm configure primitive ERS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true \
     meta priority=1000

Confirma la configuración recién creada:

# crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

El resultado es similar al siguiente ejemplo:

primitive ASCS_INSTANCE_RESOURCE 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


primitive ERS_INSTANCE_RESOURCE 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 \

Si usas una configuración de activación simple, el resultado es similar al siguiente:

primitive ASCS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true \
meta resource-stickiness=5000 failure-timeout=60 \
migration-threshold=1 priority=10


primitive ERS_INSTANCE_RESOURCE 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 MINIMAL_PROBE=true IS_ERS=true \
meta priority=1000

Configura grupos de recursos y restricciones de ubicación

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_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \
  ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
  ASCS_INSTANCE_RESOURCE \
  meta resource-stickiness=3000
```
  Si usas una configuración de activación simple, ejecuta el siguiente comando:
```
# crm configure group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE \
  ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
  ASCS_INSTANCE_RESOURCE \
  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_LC_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. Esta variable de marcador de posición no se aplica cuando usas una configuración de activación simple.
  - ASCS_SAPSTARTSRV_RESOURCE: Especifica el nombre de recurso del clúster que definiste para el "sapstartsrv" de ASCS antes. Esta variable de marcador de posición solo se aplica cuando usas una configuración de activación simple.
  - 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_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
  ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
  ERS_INSTANCE_RESOURCE
```
  Si usas una configuración de activación simple, ejecuta el siguiente comando:
```
# crm configure group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE \
  ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
  ERS_INSTANCE_RESOURCE
```
  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_SAPSTARTSRV_RESOURCE: Especifica el nombre de recurso del clúster que definiste para el "sapstartsrv" de ERS antes. Esta variable de marcador de posición solo se aplica cuando usas una configuración de activación simple.
  - ERS_FILE_SYSTEM_RESOURCE: Especifica el nombre de recurso del clúster que definiste para el sistema de archivos ERS antes. Esta variable de marcador de posición no se aplica cuando usas una configuración de activación simple.
  - 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.

Confirma la configuración recién creada:

# crm configure show type:group

El resultado es similar al siguiente ejemplo:

group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE \
        meta resource-stickiness=3000

Si usas una configuración de activación simple, el resultado es similar al siguiente ejemplo:

group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE

Crea las restricciones de colocación:

ENSA1

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_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
```
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_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
rule 2000: runs_ers_SID eq 1
```

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_RESOURCE:start \
 ERS_INSTANCE_RESOURCE:stop symmetrical=false

Confirma la configuración recién creada:

# crm configure show type:colocation type:location type:order

Deberías ver un resultado similar al siguiente:

order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false
colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
rule 2000: runs_ers_SID eq 1

ENSA2

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_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
```

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_RESOURCE:start \
 ERS_INSTANCE_RESOURCE:stop symmetrical=false

Confirma la configuración recién creada:

# crm configure show type:colocation type:order

Deberías ver un resultado similar al siguiente:

colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
order ORD_SAP_SID_FIRST_START_ASCS  Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false

Inhabilita el modo de mantenimiento.

# crm configure property maintenance-mode="false"

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

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

Si usas una configuración de activación simple, el resultado es similar al 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: Thu Sep 20 19:44:26 2024
  * Last change:  Thu Sep 20 19:53:41 2024 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:
    * SAPStartSrv-rsc-nw-aha-ascs (ocf::heartbeat:SAPStartSrv):     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:
    * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv):     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

Cambia al usuario SID_LCadm.
```
# su - SID_LCadm
```

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

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

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 ""
```
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.

Realiza una copia de seguridad de tu sistema.
Como raíz en el host con la instancia de SCS activa, desconecta la interfaz de red:
```
# ip link set eth0 down
```
Vuelve a conectarte a cualquier host mediante SSH y cambia al usuario raíz.

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

Si usas una configuración de activación simple, verás un resultado similar al siguiente:

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: Wed Sep 26 19:10:10 2024
 * Last change:  Tue Sep 25 23:48:35 2024 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:
   * SAPStartSrv-rsc-nw-aha-scs (ocf::heartbeat:SAPStartSrv):     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:
   * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv):     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

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
```
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
```

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

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
```
Cuando se detenga el monitor enqt, ingresa Ctrl + c para salir de él.
De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:
```
# crm_mon
```

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

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

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

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
```
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.
Cuando ASCS esté activo, reinicia el servidor.
De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:
```
# crm_mon
```
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
```
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
```
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:

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
```
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, SAP transfiere ese ticket al componente de Google Cloud adecuado en su sistema: BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE.

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:

Obtén asistencia para SAP en Google Cloud
Nota de SAP 2456406: SAP en Google Cloud Platform: requisitos previos de compatibilidad (se requiere una cuenta de usuario de SAP)

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:

Prácticas recomendadas de SUSE

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

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

El sistema que se implementa en esta guía

Requisitos previos

Información relacionada de SUSE

Crea una red

Configura una puerta de enlace NAT

Cómo agregar reglas de firewall

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

Verifica la implementación de tu sistema SAP NetWeaver de alta disponibilidad

Verifica los registros

Explorador de registros

Visor de registros heredado

Verifica la configuración de la VM

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

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

Verifica que el agente de host SAP reciba métricas

Instala ASCS y ERS

Prepararse para la instalación

Instala el componente ASCS

Instala el componente ERS

Configura los servicios de SAP

Confirma las entradas de servicio de SAP

systemV

systemd

Detén los servicios de SAP

Habilita sapping y sappong

Edita los perfiles de ASCS y ERS

ENSA1

ENSA2

Agrega el usuario sidadm al grupo de usuarios haclient

Configura los recursos del clúster para ASCS y ERS

ENSA1

ENSA2

Configura grupos de recursos y restricciones de ubicación

ENSA1

ENSA2

Valida y prueba tu clúster

Verifica la configuración del clúster

Simula una conmutación por error

Confirma que se conserven las entradas de bloqueo

ENSA1

ENSA2

Simula un evento de mantenimiento de Compute Engine

Evalúa la carga de trabajo de SAP NetWeaver

Soluciona problemas

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

Asistencia

Requisitos de asistencia

Realiza tareas posteriores a la implementación

¿Qué sigue?

`systemV`

`systemd`

Habilita `sapping` y `sappong`

Agrega el usuario `sidadm` al grupo de usuarios `haclient`