Guía de configuración de clústeres con escalamiento horizontal de alta disponibilidad para SAP HANA en SLES

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

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

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

En esta guía, también se incluyen pasos para configurar la replicación del sistema SAP HANA, pero consulta la documentación de SAP para obtener las instrucciones definitivas.

Para implementar un sistema de SAP HANA sin un clúster de alta disponibilidad de Linux o un host de nodo en espera, usa la Guía de implementación de SAP HANA.

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

El sistema que se implementa en esta guía

Con esta guía, implementarás un sistema SAP HANA de alta disponibilidad de varios nodos configurado para una redundancia total de zona con una instancia adicional que actúa como un creador de mayoría, también conocida como tie-breaker nodo, que garantiza que el quórum del clúster se mantenga en caso de pérdida de una zona.

La implementación final consta de los siguientes recursos:

• Un sitio principal y secundario en el que cada instancia tiene una contraparte zonal.
• Dos sitios configurados para la replicación síncrona.
• Una sola instancia de procesamiento para que actúe como creador de mayorías.
• Un administrador de recursos de clústeres de alta disponibilidad de Pacemaker con un mecanismo de protección.
• Discos persistentes para los datos de SAP HANA y los volúmenes de registro conectados a cada instancia de SAP HANA.

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

En esta guía, se usa SAP HANA Studio para probar la replicación del sistema SAP HANA. Si lo prefieres, puedes usar SAP HANA Cockpit. Para obtener información sobre la instalación de SAP HANA Studio, consulta la siguiente página:

• Instala SAP HANA Studio en una VM de Windows de Compute Engine
• SAP HANA Studio Installation and Update Guide (Guía de instalación y actualización de SAP HANA Studio)

Requisitos

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

• Leíste la Guía de planificación de SAP HANA y la Guía de planificación de alta disponibilidad de SAP HANA.
• Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP HANA. Para obtener información sobre cómo crear cuentas y proyectos de Google Cloud, consulta Configura la Cuenta de Google en la guía de implementación de SAP HANA.
• 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. Para obtener más información, consulta Cumplimiento y controles soberanos para SAP en Google Cloud.

• El medio de instalación de SAP HANA se almacena en un bucket de Cloud Storage que está disponible en tu proyecto y región de implementación. Para obtener información sobre cómo subir medios de instalación de SAP HANA a un bucket de Cloud Storage, consulta Descarga SAP HANA en la Guía de implementación de SAP HANA.

• 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

• Si usas un DNS interno de VPC, el valor de la variable vmDnsSetting en los metadatos del proyecto debe ser GlobalOnly o ZonalPreferred para habilitar la resolución de los nombres del nodo entre zonas. La configuración predeterminada de vmDnsSetting es ZonalOnly. Para obtener más información, consulta:

  • Configura nombres DNS para tu proyecto o instancias
  • Consulta metadatos personalizados
  • Establece metadatos personalizados para todo el proyecto

• Debes tener una solución NFS, como la solución administrada de Filestore, para compartir los volúmenes /hana/shared y /hanabackup de SAP HANA entre los hosts en el sistema de escalamiento horizontal de SAP HANA. Para implementar servidores NFS de Filestore, consulta Crea instancias.

  • Ten en cuenta que los sitios principal y secundario deben tener acceso a sus propias rutas de NFS dedicadas para evitar reemplazar datos. Para usar una sola instancia de Filestore, debes configurar la implementación para usar subdirectorios distintos como la ruta de activación.

Para evitar la exposición accidental de la instancia de VM en Internet, sigue estas recomendaciones:

• Usa una puerta de enlace NAT.
• Crea reglas de firewall que bloqueen todos los accesos externos que no necesites.
• Cuando crees tus VMs, sigue estos pasos:
  • Especifica una etiqueta de red para cada VM a fin de usarlas en las reglas de enrutamiento y firewall. Si usas la plantilla de Deployment Manager que proporciona Google Cloud, especifica una etiqueta con networkTag: [TAG].
  • Crea las VM sin una IP externa. Si usas las plantillas de Deployment Manager que proporciona Google Cloud, especifica publicIP: No.

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 configurar la red, sigue estos pasos:

Consola

1. En la consola de Google Cloud, ve a la página Redes de VPC.

   Ir a las redes de VPC

2. Haga clic en Crear red de VPC.
3. Ingresa un Nombre para la red.

   El nombre debe cumplir con la convención de nombres. Las redes de VPC usan la convención de nombres de Compute Engine.

4. En Modo de creación de subredes, selecciona Custom.
5. En la sección Subred nueva, especifica los siguientes parámetros de configuración para una subred:
   1. Ingresa un Nombre para la subred.
   2. En Región, selecciona la región de Compute Engine en la que deseas crear la subred.
   3. En Tipo de pila IP, selecciona IPv4 (pila única) y, luego, ingresa un rango de direcciones IP en el formato CIDR. , como 10.1.0.0/24.

      Este es el rango de IPv4 principal de la subred. Si planeas agregar más de una subred, asigna rangos de IP de CIDR no superpuestos para cada subred de la red. Ten en cuenta que cada subred y sus rangos de IP interna se asignan a una sola región.

   4. Haga clic en Listo.
6. Para agregar más subredes, haz clic en Agregar subred y repite los pasos anteriores. Puedes agregar más subredes a la red después de haberla creado.
7. Haga clic en Crear.

gcloud

1. Ve a Cloud Shell.

   Ir a Cloud Shell

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

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

   Reemplaza NETWORK_NAME por el nombre de la red nueva. El nombre debe cumplir con la convención de nombres. Las redes de VPC usan la convención de nombres de Compute Engine.

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

3. Crea una subred y especifica la región y el rango de IP a través del siguiente comando:

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

   Reemplaza lo siguiente:

   • SUBNETWORK_NAME: el nombre de la subred nueva
   • NETWORK_NAME: el nombre de la zona que creaste en el paso anterior
   • REGION: la región en la que deseas que esté la subred
   • RANGE: el rango de direcciones IP especificado en formato CIDR, como 10.1.0.0/24

     Si planeas agregar más de una subred, asigna rangos de IP de CIDR no superpuestos para cada subred de la red. Ten en cuenta que cada subred y sus rangos de IP interna se asignan a una sola región.

4. Si quieres, puedes repetir el paso anterior y agregar más 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.

Punto clave: Cuando configuras Cloud NAT, especifica al menos 160 como la cantidad mínima de puertos por VM. Ciertas actualizaciones del sistema operativo ejecutan procesos simultáneos que pueden exceder el Cloud NAT predeterminado para la cantidad de puertos, lo que puede provocar errores de activación o descarga.

Cuando crees una instancia de Cloud NAT, especifica la cantidad de puertos en el campo de Puertos mínimos por VM en Configuraciones avanzadas en la página Crea una puerta de enlace NAT en la consola de Google Cloud.

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, una regla de firewall implícita bloquea las conexiones entrantes desde fuera de tu red de nube privada virtual (VPC). Para permitir conexiones entrantes, establece una regla de firewall para la VM. Después de establecer una conexión entrante con una VM, se permite el tráfico en ambas direcciones a través de esa conexión.

También puedes crear una regla de firewall para permitir el acceso externo a puertos especificados o restringir el acceso entre las VM en la misma red. Si se usa el tipo de red de VPC default, también se aplican algunas reglas predeterminadas adicionales, como la regla default-allow-internal, que permite la conectividad entre VM en la misma red en todos los puertos.

En función de la política de TI que se aplique a tu entorno, es posible que debas aislar o restringir la conectividad a tu host de base de datos, lo que puedes hacer a través de la creación de reglas de firewall.

Según la situación en la que te encuentres, puedes crear reglas de firewall para permitir los siguientes accesos:

• Los puertos SAP predeterminados que se enumeran en TCP/IP de todos los productos SAP.
• Conexiones desde tu computadora o tu entorno de red corporativa 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.

Nota: El siguiente procedimiento es una versión simplificada de las instrucciones para crear reglas de firewall. Para obtener instrucciones más detalladas, consulta la sección sobre cómo crear reglas de firewall.

Para crear una regla de firewall, sigue estos pasos:

Consola

1. En la consola de Google Cloud, ve a la página Firewall de Compute Engine.

   Ir a Firewall

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

   • En el campo Red, selecciona la red donde se ubica tu VM.
   • En el campo Destinos, especifica los recursos de Google Cloud a los que se aplica esta regla. Por ejemplo, especifica Todas las instancias de la red. O bien, para limitar la regla a instancias específicas en Google Cloud, ingresa etiquetas en Etiquetas de destino especificadas.
   • En el campo Filtro de fuente, selecciona una de las siguientes opciones:
     • Rangos de IP para permitir el tráfico entrante de direcciones IP específicas. Especifica el rango de direcciones IP en el campo Rangos de IP de origen.
     • Subredes para permitir el tráfico entrante desde una subred específica. Especifica el nombre de la subred en el siguiente campo Subredes. Puedes usar esta opción para permitir el acceso entre las VM en una configuración de escalamiento horizontal o de 3 niveles.
   • En la sección Protocolos y puertos, selecciona Protocolos y puertos especificados y luego ingresa tcp:PORT_NUMBER.

3. Haz clic en Crear para crear tu regla de firewall.

gcloud

Crea una regla de firewall mediante el siguiente comando:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Implementa las VM y SAP HANA

A fin de implementar un sistema SAP HANA con alta disponibilidad de varios nodos configurado para la redundancia de zona completa, usa la plantilla de Cloud Deployment Manager para SAP HANA como base para la configuración, así como una plantilla adicional para implementar una instancia como creador de mayorías.

La implementación consiste en lo siguiente:

• Dos sistemas SAP HANA coincidentes, cada uno con dos o más nodos trabajadores.
• Una sola instancia de creador de mayoría, también conocida como nodo tie-breaker, que garantiza que el quórum del clúster se mantenga en caso de la pérdida de una zona.

Agrega definición para todos los sistemas al mismo archivo YAML de modo que Deployment Manager implemente todos los recursos bajo una implementación. Una vez que los sistemas SAP HANA y la instancia del creador de mayoría de recursos se implementen de forma correcta, debes definir y configurar el clúster de alta disponibilidad.

En las siguientes instrucciones, se usa Cloud Shell, pero, en términos generales, se pueden aplicar a Google Cloud CLI.

1. Confirma que las cuotas actuales de los recursos como discos persistentes y CPU sean suficientes para los sistemas SAP HANA que estás a punto de instalar. Si las cuotas no son suficientes, la implementación fallará. Si quieres ver los requisitos de cuota de SAP HANA, consulta las consideraciones de precios y cuotas para SAP HANA.

   Ir a la página Cuotas

2. Abre Cloud Shell o, si instalaste la CLI de gcloud en tu estación de trabajo local, abre una terminal.

   Ir a Cloud Shell

3. Ingresa el siguiente comando en Cloud Shell o en la CLI de gcloud a fin de descargar la plantilla del archivo de configuración template.yaml para el clúster de alta disponibilidad de SAP HANA en el directorio de trabajo:

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

4. De manera opcional, cambia el nombre del archivo template.yaml para identificar la configuración que define.

5. Abre el archivo template.yaml en el editor de código de Cloud Shell o, si usas la CLI de gcloud, el editor de texto que elijas.

   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.

6. En el archivo template.yaml, completa la definición del sistema SAP HANA principal. Reemplaza los corchetes y su contenido por los valores de la instalación a fin de especificar los siguientes valores de propiedad. Las propiedades se describen en la siguiente tabla.

   Para crear las instancias de VM sin instalar SAP HANA, borra todas las líneas que comiencen con sap_hana_ o conviértelas en comentarios.

   Propiedad	Tipo de datos	Descripción
   tipo	String	Especifica la ubicación, el tipo y la versión de la plantilla de Deployment Manager que se usará durante la implementación. El archivo YAML incluye dos especificaciones type, y una de ellas se marca como comentario. La especificación type que está activa de forma predeterminada especifica la versión de la plantilla como latest. La especificación type que se marca como comentario especifica una versión específica de la plantilla con una marca de tiempo. Si necesitas que todas tus implementaciones usen la misma versión de plantilla, usa la especificación type, que incluye la marca de tiempo.
   instanceName	String	El nombre de la instancia de VM que se define en este momento. Especifica nombres diferentes en las definiciones de la VM principal y secundaria. Los nombres se deben especificar con letras minúsculas, números o guiones.
   instanceType	String	El tipo de máquina virtual de Compute Engine en el que quieres ejecutar SAP HANA. 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. Cuando finalice la implementación, modifica la cantidad de CPU virtuales y de memoria. El mínimo recomendado instanceType para la instancia de creador de mayorías es n1-standard-2 o el equivalente de al menos 2 núcleos de CPU y 2 GB de memoria.
   zone	String	La zona de Google Cloud en la que se implementará la instancia de VM que estás definiendo. Especifica diferentes zonas en la misma región para las definiciones de las instancias principal y secundaria de HANA, y la instancia de creador de mayorías. Las zonas deben estar en la misma región que seleccionaste para tu subred.
   subnetwork	String	El nombre de la subred que creaste en un paso anterior. Si realizas la implementación en una VPC compartida, especifica este valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por ejemplo, myproject/network1.
   linuxImage	String	El nombre de la imagen del sistema operativo Linux o de la familia de imágenes que usas con SAP HANA. Para especificar una familia de imágenes, agrega el prefijo family/ al nombre de la familia. Por ejemplo, family/sles-15-sp1-sap. Para indicar una imagen específica, proporciona solo el nombre de la imagen. Para ver la lista de imágenes y familias disponibles, consulta la página Imágenes en la consola de Google Cloud.
   linuxImageProject	String	El proyecto de Google Cloud que contiene la imagen que usarás. Este proyecto puede ser uno propio o un proyecto de imágenes de Google Cloud, como suse-sap-cloud. Para obtener más información sobre los proyectos de imagen de Google Cloud, consulta la página Imágenes en la documentación de Compute Engine.
   sap_hana_deployment_bucket	String	El nombre del bucket de almacenamiento de Google Cloud en el proyecto que contiene los archivos de instalación y revisión de SAP HANA que subiste en un paso anterior. Todos los archivos de revisión de actualización en el bucket se aplican a SAP HANA durante el proceso de implementación.
   sap_hana_sid	String	El ID del sistema SAP HANA (SID). Debe constar de tres caracteres alfanuméricos y comenzar con una letra. Todas las letras deben estar en mayúsculas.
   sap_hana_instance_number	Entero	El número de instancia, de 0 a 99, del sistema SAP HANA. El valor predeterminado es 0.
   sap_hana_sidadm_password	String	La contraseña del administrador del sistema operativo (SO). Las contraseñas deben tener como mínimo ocho caracteres y deben incluir al menos una letra mayúscula, una letra minúscula y un número. Precaución: Cambia la contraseña después de que se complete la instalación.
   sap_hana_system_password	String	La contraseña para el superusuario de la base de datos. Las contraseñas deben tener al menos ocho caracteres y, a su vez, incluir al menos una letra mayúscula, una letra minúscula y un número. Precaución: Cambia la contraseña después de que se complete la instalación.
   sap_hana_sidadm_uid	Integer	El valor predeterminado para el ID de usuario SID_LCadmes 900 a fin de evitar que los grupos creados por el usuario entren en conflicto con SAP HANA. Puedes cambiar este valor a uno diferente si es necesario.
   sap_hana_sapsys_gid	Entero	El ID de grupo predeterminado para sapsys es 79. Si especificas un valor superior, puedes anular este valor según tus requisitos.
   sap_hana_scaleout_nodes	Integer	Especifica 1 o un valor superior.
   sap_hana_shared_nfs	String	El punto de activación de NFS para el volumen /hana/shared. Por ejemplo, 10.151.91.122:/hana_shared_nfs Nota: El punto de activación de NFS para el volumen /hana/shared debe estar vacío y ninguna otra implementación lo debe usar antes de ejecutar Deployment Manager.
   sap_hana_backup_nfs	String	El punto de activación de NFS para el volumen /hanabackup. Por ejemplo, 10.216.41.122:/hana_backup_nfs.
   networkTag	String	Una etiqueta de red que representa tu instancia de VM para el firewall o el enrutamiento. Si especificas publicIP: No y no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.
   nic_type	String	Opcional, pero recomendado si está disponible para la máquina de destino y la versión del SO. Especifica la interfaz de red que se usará con la instancia de VM. Puedes especificar el valor GVNIC o VIRTIO_NET. Para usar una NIC virtual de Google (gVNIC), debes especificar una imagen de SO que admita gVNIC como valor de la propiedad linuxImage. Para obtener la lista de imágenes del SO, consulta Detalles de los sistemas operativos. Si no especificas un valor para esta propiedad, la interfaz de red se selecciona de manera automática según el tipo de máquina que especifiques para la propiedad instanceType. Este argumento está disponible en las versiones 202302060649 de la plantilla de Deployment Manager o posteriores.
   publicIP	Booleano	Opcional. Determina si se agrega una dirección IP pública a tu instancia de VM. El valor predeterminado es Yes. Nota: No especifiques No a menos que tengas una puerta de enlace NAT configurada con una etiqueta de red definida para la VM o hayas proporcionado a la VM otra ruta a Internet. Si no hay una ruta a Internet, la instalación falla.
   serviceAccount	String	Opcional. Especifica una cuenta de servicio que usarán las VM del host y los programas que se ejecutan en las VM del host. Especifica la dirección de correo electrónico de la cuenta de servicio. Por ejemplo, [e-mail]. De forma predeterminada, se usa la cuenta de servicio predeterminada de Compute Engine. A fin de obtener más información, consulta Administración de identidades y accesos para programas SAP en Google Cloud.

7. Para crear la definición del sistema SAP HANA secundario, copia la definición del sistema SAP HANA principal y pégala después de la definición del sistema SAP HANA principal. SIgue estos pasos para consultar el ejemplo.

8. En la definición del sistema SAP HANA secundario, especifica valores diferentes para las siguientes propiedades que los que especificaste en la definición del sistema SAP HANA principal:

   • name
   • instanceName
   • zone

9. Descarga el archivo de configuración de la instancia del creador de mayoría sap_majoritymaker.yaml:

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

10. Copia y pega la especificación YAML del archivo sap_majoritymaker.yaml, a partir de la línea 6 y debajo, hasta la parte inferior del archivo template.yaml de SAP HANA.

11. Completa la definición de la instancia del creador de mayorías:

    • Especifica un zone que sea diferente de los dos sistemas SAP HANA.
    • El mínimo recomendado de instanceType es n1-standard-2 o el equivalente de al menos 2 núcleos de CPU y 2 GB de memoria.

    Ahora deberías tener tres recursos en tu archivo YAML, dos clústeres de SAP HANA y una instancia de creador de mayorías, junto con sus propiedades configurables.

12. Crea las instancias:

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

    Mediante el comando anterior, se invoca a Deployment Manager, que implementa las VMs, descarga el software de SAP HANA del bucket de almacenamiento e instala SAP HANA, todo según las especificaciones del archivo template.yaml.

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

Ejemplo de un archivo de configuración template.yaml completo

En el siguiente ejemplo, se muestra un archivo de configuración template.yaml completo que implementa dos clústeres de escalamiento horizontal con un sistema SAP HANA instalado y una sola instancia de VM que actúa como creador de mayorías.

El archivo contiene las definiciones de dos recursos para implementar: sap_hana_primary y sap_hana_secondary. Cada definición de recurso contiene las definiciones de una VM y una instancia de SAP HANA.

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

Las propiedades networkTag, serviceAccount, sap_hana_sidadm_uid y sap_hana_sapsys_gid pertenecen a la sección Opciones avanzadas de la plantilla del archivo de configuración. Las propiedades sap_hana_sidadm_uid y sap_hana_sapsys_gid se incluyen para mostrar sus valores predeterminados, que se usan porque las propiedades se convertieron en comentarios.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.151.91.123:/hana_shared_nfs
    sap_hana_backup_nfs: 10.216.41.123:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.141.91.124:/hana_shared_nfs
    sap_hana_backup_nfs: 10.106.41.124:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_majoritymaker
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202208181245/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  properties:
    instanceName: sap-majoritymaker
    instanceType: n1-standard-2
    zone: us-central1-b
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    publicIP: No
    

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

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

• Para fines de configuración, tu estación de trabajo local, un host de bastión o un servidor de salto
• Para el acceso entre los nodos del clúster, las otras VM del host en el clúster de HA

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

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

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

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

Verifica la implementación de las VMs y SAP HANA

Para verificar la implementación, revisa los registros de implementación en Cloud Logging y los discos y servicios en las VMs de los hosts principales y secundarios.

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

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 HANA que se enumeran en la Guía de planificación de SAP HANA.

     2. En la página Implementaciones de Deployment Manager, borra la implementación para limpiar las VM y los discos persistentes de la instalación con errores.

     3. Vuelve a ejecutar tu implementación.

Verifica el estado de implementación del mayor compilador

Puedes verificar el estado de implementación del mayor compilador mediante el siguiente comando.

gcloud compute instances describe MAJORITY_MAKER_HOSTNAME --zone MAJORITY_MAKER_ZONE --format="table[box,title='Deployment Status'](name:label=Instance_Name,metadata.items.status:label=Status)"

Si se muestra el estado Complete, el procesamiento de implementación se realizó de forma correcta para la instancia del creador de la mayoría de los creadores. Para una implementación en curso, se muestra el estado <blank>.

Verifica la configuración de las VM y SAP HANA

1. Después de que el sistema SAP HANA se implemente sin errores, conéctate a cada VM mediante una conexión 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. En cada VM, asegúrate de ver los directorios /hana, como /hana/data.

   Filesystem                        Size  Used Avail Use% Mounted on
   /dev/sda2                          30G  4.0G   26G  14% /
   devtmpfs                          126G     0  126G   0% /dev
   tmpfs                             126G     0  126G   0% /dev/shm
   tmpfs                             126G   17M  126G   1% /run
   tmpfs                             126G     0  126G   0% /sys/fs/cgroup
   /dev/sda1                         200M  9.7M  191M   5% /boot/efi
   /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
   /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
   /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
   /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
   /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
   tmpfs                              26G     0   26G   0% /run/user/900
   tmpfs                              26G     0   26G   0% /run/user/899
   tmpfs                              26G     0   26G   0% /run/user/1000

4. En el siguiente comando, reemplaza SID_LC con el ID del sistema que especificaste en la plantilla del archivo de configuración para cambiar al usuario administrador de SAP. Usa minúsculas para las letras.

   # su - SID_LCadm

5. Ejecuta el siguiente comando para asegurarte de que los servicios de SAP HANA, como hdbnameserver, hdbindexserver y otros, se ejecuten en la instancia:

   > HDB info

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

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

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

Configura la supervisión para SAP HANA

De manera opcional, puedes supervisar tus instancias de SAP HANA con el agente para SAP de Google Cloud. Desde la versión 2.0, puedes configurar el agente para recopilar las métricas de supervisión de SAP HANA y enviarlas a Cloud Monitoring. Cloud Monitoring te permite crear paneles para visualizar estas métricas, configurar alertas basadas en límites de métricas y mucho más.

Si deseas obtener más información sobre la recopilación de métricas de supervisión de SAP HANA mediante el agente de para SAP de Google Cloud, consulta Recopilación de métricas de supervisión de SAP HANA.

Crea una lista de instancias para la automatización de secuencias de comandos (opcional)

Para automatizar parcialmente algunas de las tareas repetitivas durante la configuración del sistema SAP HANA y del clúster de Pacemaker, puedes usar secuencias de comandos de Bash. En esta guía, se usan esas secuencias de comandos de Bash para acelerar la configuración de tu sistema SAP HANA y del clúster de Pacemaker. Estas secuencias de comandos requieren una lista de todas las instancias VM implementadas y sus zonas correspondientes como entrada.

Para habilitar esta automatización, crea un archivo llamado nodes.txt y, luego, incluye los detalles de todas las instancias de VM implementadas en el siguiente formato: nombre de la zona, espacio en blanco y, luego, el nombre de la instancia de VM. El siguiente archivo de muestra se usa en esta guía:

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2
 

Configura el acceso SSH sin contraseña

Para configurar el clúster de Pacemaker y sincronizar las claves del almacén seguro (SSFS) de SAP HANA, se requiere un acceso SSH sin contraseña entre todos los nodos, incluida la instancia del creador de mayoría. Para el acceso SSH sin contraseña, debes agregar las claves públicas SSH a los metadatos de la instancia de todas las instancias implementadas.

El formato de los metadatos es USERNAME: PUBLIC-KEY-VALUE.

Para obtener más información sobre cómo agregar claves SSH a las VMs, consulta Agrega claves SSH a las VMs que usan claves SSH basadas en metadatos.

Pasos manuales

1. Para cada instancia en los sistemas principales y secundarios, así como en la instancia del creador de mayorías, recopila la clave pública para el usuario root.

   gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub

2. Agrega la clave con la string root: y escribe la clave como una línea nueva en el archivo llamado public-ssh-keys.txt, por ejemplo:

   root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME

3. Después de recopilar todas las claves públicas SSH, sube las claves como metadatos a todas las instancias:

   gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME

Pasos automatizados

Como alternativa, a fin de automatizar el proceso de configuración del acceso SSH sin contraseña para todas las instancias que se enumeran en nodes.txt, realiza los siguientes pasos desde la consola de Google Cloud:

1. Crea una lista de claves públicas de todas las instancias implementadas:

   while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

2. Asigna las claves públicas SSH como entradas de metadatos a todas las instancias:

   while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt 

Inhabilita el inicio automático de SAP HANA

Pasos manuales

Asegúrate de que el inicio automático de SAP HANA esté inhabilitado para cada instancia de SAP HANA en el clúster. Para las conmutaciones por error, Pacemaker administra el inicio y la detención de las instancias de SAP HANA en un clúster.

1. En cada host como SID_LCadm, detén SAP HANA:

   > HDB stop

2. En cada host, abre el perfil de SAP HANA con un editor, como "vi":

   vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

3. Establece la propiedad Autostart en 0:

   Autostart=0

4. Guarda el perfil.

5. En cada host como SID_LCadm, inicia SAP HANA:

   > HDB start

Pasos automatizados

Como alternativa, para inhabilitar el inicio automático de SAP HANA para todas las instancias que se enumeran en nodes.txt, ejecuta la siguiente secuencia de comandos desde la consola de Google Cloud:

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt
 

Nota: Ignora el error “No existe el archivo o el directorio” que se muestra cuando la secuencia de comandos de automatización accede a la instancia de creador de mayorías. Este error se muestra porque la instancia de creador de mayorías no tiene SAP HANA instalado.

Habilita SAP HANA Fast Restart

Google Cloud recomienda enfáticamente habilitar SAP HANA Fast Restart para cada instancia de SAP HANA, en especial para instancias más grandes. SAP HANA Fast Restart reduce los tiempos de reinicio en caso de que SAP HANA finalice, pero el sistema operativo permanezca en ejecución.

Nota: Si implementas SAP HANA mediante el módulo de Terraform de Google Cloud sap_hana o sap_hana_ha, versión 202309280828 o posterior, entonces el reinicio rápido se habilita automáticamente.

Como se establece en las secuencias de comandos de automatización que proporciona Google Cloud, la configuración del kernel y el sistema operativo ya son compatibles con el reinicio rápido de SAP HANA. Debes definir el sistema de archivos tmpfs y configurar SAP HANA.

Para definir el sistema de archivos tmpfs y configurar SAP HANA, puedes seguir los pasos manuales o usar la secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA. Para obtener más información, consulta los siguientes vínculos:

• Pasos manuales: Habilita el reinicio rápido de SAP HANA
• Pasos manuales: Habilita el reinicio rápido de SAP HANA

Para obtener instrucciones autorizadas completas sobre Fast Restart SAP HANA, consulta la documentación de la opción Fast Restart SAP HANA.

Pasos manuales

Configura el sistema de archivos tmpfs

Después de que las VM del host y los sistemas base de SAP HANA se implementan de forma correcta, debes crear y activar directorios para los nodos de NUMA en el sistema de archivos tmpfs.

Muestra la topología de NUMA de tu VM

Para poder asignar el sistema de archivos tmpfs requerido, debes saber cuántos nodos de NUMA tiene tu VM. Si deseas mostrar los nodos de NUMA disponibles en una VM de Compute Engine, ingresa el siguiente comando:

lscpu | grep NUMA

Por ejemplo, un tipo de VM m2-ultramem-208 tiene cuatro nodos de NUMA, numerados del 0 al 3, como se muestra en el siguiente ejemplo:

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

Crea los directorios de nodos de NUMA

Crea un directorio para cada nodo de NUMA en tu VM y configura los permisos.

Por ejemplo, para cuatro nodos de NUMA que están numerados del 0 al 3:

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

Activa los directorios de nodos de NUMA en tmpfs

Activa los directorios del sistema de archivos tmpfs y especifica una preferencia de nodo de NUMA para cada uno con mpol=prefer:

SID especifica el SID con letras mayúsculas.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

Nota: si cambias los tipos de máquina y los nodos de NUMA aumentan o disminuyen, debes modificar el sistema de archivos tmpfs y la sección [persistence] del archivo INI de SAP HANA, que se muestra en la siguiente sección, para que coincida con la cantidad nueva de nodos de NUMA.

Actualiza /etc/fstab

Para asegurarte de que los puntos de activación estén disponibles después de reiniciar el sistema operativo, agrega entradas a la tabla del sistema de archivos, /etc/fstab:

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Opcional: Establece límites para el uso de memoria

El sistema de archivos tmpfs puede aumentar o reducirse de forma dinámica.

A fin de limitar la memoria que usa el sistema de archivos tmpfs, puedes establecer un límite de tamaño para un volumen de nodo NUMA con la opción size. Por ejemplo:

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

También puedes limitar el uso de memoria tmpfs general de todos los nodos de NUMA para una instancia determinada de SAP HANA y un nodo del servidor determinado si configuras el parámetro persistent_memory_global_allocation_limit en la sección [memorymanager] del archivo global.ini.

Configuración de SAP HANA para Fast Restart

A fin de configurar SAP HANA para Fast Restart, actualiza el archivo global.ini y especifica las tablas que se almacenarán en la memoria persistente.

Actualiza la sección [persistence] en el archivo global.ini

Configura la sección [persistence] en el archivo global.ini de SAP HANA para hacer referencia a las ubicaciones de tmpfs. Separa cada ubicación de tmpfs con un punto y coma:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

En el ejemplo anterior, se especifican cuatro volúmenes de memoria para cuatro nodos de NUMA, que corresponden a m2-ultramem-208. Si ejecutas en el m2-ultramem-416, debes configurar ocho volúmenes de memoria (0..7).

Reinicia SAP HANA después de modificar el archivo global.ini.

SAP HANA ahora puede usar la ubicación de tmpfs como espacio de memoria persistente.

Especifica las tablas que se almacenarán en la memoria persistente

Especifica particiones o tablas de columnas específicas para almacenarlas en la memoria persistente.

Por ejemplo, para activar la memoria persistente en una tabla existente, ejecuta la consulta de SQL:

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Para cambiar el valor predeterminado de las tablas nuevas, agrega el parámetro table_default en el archivo indexserver.ini. Por ejemplo:

[persistent_memory]
table_default = ON

Para obtener más información sobre cómo controlar las columnas, las tablas y qué vistas de supervisión proporcionan información detallada, consulta Memoria persistente de SAP HANA.

Pasos automatizados

La secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA realiza cambios en los directorios /hana/tmpfs*, el archivo /etc/fstab y la configuración de SAP HANA. Cuando ejecutas la secuencia de comandos, es posible que debas realizar pasos adicionales en función de si esta es la implementación inicial de tu sistema SAP HANA o de cambiar el tamaño de la máquina a un tamaño de NUMA diferente.

Para la implementación inicial de tu sistema SAP HANA o cambio del tamaño de la máquina a fin de aumentar la cantidad de nodos de NUMA, asegúrate de que SAP HANA se ejecute durante la ejecución de la secuencia de comandos de automatización que Google Cloud proporciona para habilitar el reinicio rápido de SAP HANA.

Cuando cambies el tamaño de tu máquina a fin de disminuir la cantidad de nodos de NUMA, asegúrate de que SAP HANA se detenga durante la ejecución de la secuencia de comandos de automatización que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA. Después de ejecutar la secuencia de comandos, debes actualizar de forma manual la configuración de SAP HANA para completar la configuración de reinicio rápido de SAP HANA. Para obtener más información, consulta Configuración de SAP HANA para un reinicio rápido.

Nota: Recomendamos que ejecutes la secuencia de comandos que proporciona Google Cloud para habilitar el reinicio rápido de SAP HANA en un entorno que no sea de producción y verificar los resultados de forma exhaustiva antes de ejecutar la secuencia de comandos en entornos de producción. Asumes la responsabilidad de habilitar de forma correcta el reinicio rápido de SAP HANA.

Para habilitar el reinicio rápido de SAP HANA, sigue estos pasos:

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

2. Cambiar a la raíz:

   sudo su -

3. Descarga la secuencia de comandos sap_lib_hdbfr.sh:

   wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

4. Haz que el archivo sea ejecutable:

   chmod +x sap_lib_hdbfr.sh

5. Verifica que la configuración no tenga errores:

   vi sap_lib_hdbfr.sh
   ./sap_lib_hdbfr.sh -help

   Si el comando muestra un error, comunícate con el servicio de Atención al cliente de Cloud. Si deseas obtener más información para comunicarte con el equipo de Atención al cliente de Cloud, consulta Obtén asistencia para SAP en Google Cloud.

6. Ejecuta la secuencia de comandos después de reemplazar el ID del sistema SAP HANA (SID) y la contraseña para el usuario SYSTEM de la base de datos SAP HANA. Para proporcionar la contraseña de forma segura, te recomendamos que uses un secreto en Secret Manager.

   Ejecuta la secuencia de comandos con el nombre de un secreto en Secret Manager. Este secreto debe existir en el proyecto de Google Cloud que contiene tu instancia de VM del host.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 

   Reemplaza lo siguiente:

   • SID: Especifica el SID con letras mayúsculas. Por ejemplo, AHA.
   • SECRET_NAME: Especifica el nombre del secreto que corresponde a la contraseña del usuario del sistema de la base de datos de SAP HANA. Este secreto debe existir en el proyecto de Google Cloud que contiene tu instancia de VM del host.

   Como alternativa, puedes ejecutar la secuencia de comandos con una contraseña de texto sin formato. Después de habilitar el reinicio rápido de SAP HANA, asegúrate de cambiar la contraseña. No se recomienda usar una contraseña con texto sin formato, ya que tu contraseña se registraría en el historial de línea de comandos de tu VM.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

   Reemplaza lo siguiente:

   • SID: Especifica el SID con letras mayúsculas. Por ejemplo, AHA.
   • PASSWORD: Especifica la contraseña para el usuario del sistema de la base de datos de SAP HANA.

Para obtener una ejecución inicial exitosa, deberías ver un resultado similar al siguiente:

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Descarga paquetes de SUSE

Desinstala los agentes de recursos que se usan para las implementaciones de escalamiento vertical y reemplázalos por los agentes de recursos que se usaron para el escalamiento horizontal.

Pasos manuales

Realiza los siguientes pasos en todos los hosts, incluida la instancia de creador de mayorías:

1. Desinstala los agentes de recursos de escalamiento vertical de HANA:

   zypper remove SAPHanaSR SAPHanaSR-doc

2. Instala los agentes de recursos de escalamiento horizontal de HANA:

   zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

3. Instala socat:

   zypper install socat

4. Instala los últimos parches del sistema operativo:

   zypper patch

Pasos automatizados

Como alternativa, ejecuta el siguiente comando desde la consola de Google Cloud a fin de automatizar este proceso para todas las instancias que se enumeran en nodes.txt:

while read -u10 HOST ;  do gcloud compute ssh --zone $HOST -- "sudo zypper remove -y SAPHanaSR SAPHanaSR-doc; sudo zypper in -y SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc socat; sudo zypper patch -y"; done 10< nodes.txt

Crea una copia de seguridad de las bases de datos

Crea copias de seguridad de tus bases de datos a fin de iniciar el registro de la base de datos para la replicación del sistema SAP HANA y crear un punto de recuperación.

Si tienes varias bases de datos de usuarios en una configuración de MDC, crea una copia de seguridad de cada una de ellas.

La plantilla de Deployment Manager usa /hanabackup/data/SID como directorio de copia de seguridad predeterminado.

Sigue estos pasos para crear copias de seguridad de bases de datos nuevas de SAP HANA:

1. En el host principal, cambia a SID_LCadm. El comando puede ser diferente según la imagen de SO.

   sudo -i -u SID_LCadm

2. Crea copias de seguridad de las bases de datos:

   • Para un sistema de contenedor de base de datos único de SAP HANA, ejecuta este comando:

     > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     En el siguiente ejemplo, se muestra una respuesta exitosa de un sistema SAP HANA nuevo:

     0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

   • Para un sistema de contenedores de varias bases de datos (MDC) de SAP HANA, crea una copia de seguridad de la base de datos del sistema y de todas las bases de datos de usuarios:

     > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

   En el siguiente ejemplo, se muestra una respuesta exitosa de un sistema SAP HANA nuevo:

   0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

3. Confirma que el modo de registro esté configurado en normal:

   > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
     "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

   Deberías ver lo siguiente:

   VALUE
   "normal"

Habilita la replicación del sistema SAP HANA

Como parte de la habilitación de la replicación del sistema SAP HANA, debes copiar los datos y los archivos de claves de los almacenes seguros de SAP HANA en el sistema de archivos (SSFS) del host principal al secundario. El método que usa este procedimiento para copiar los archivos es solo uno de los métodos que se pueden usar.

1. En el host principal como SID_LCadm, habilita la replicación del sistema:

   > hdbnsutil -sr_enable --name=PRIMARY_HOST_NAME

2. En el host secundario:

   1. Como SID_LCadm, detén SAP HANA:

      > sapcontrol -nr INST_NUM -function StopSystem

   2. Como raíz, archiva los datos de SSFS y los archivos de claves existentes:

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

   3. Copia el archivo de datos del host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

   4. Copia el archivo de claves del host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   5. Actualiza la propiedad de los archivos:

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   6. Actualiza los permisos de los archivos:

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   7. Como SID_LC, registra el sistema SAP HANA secundario con la replicación del sistema SAP HANA:

      > hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \
      --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAME

   8. Como SID_LCadm, inicia SAP HANA:

      > sapcontrol -nr INST_NUM -function StartSystem

Valida la replicación del sistema

En el host principal como SID_LCadm, confirma que la replicación del sistema SAP HANA esté activa mediante la ejecución de la siguiente secuencia de comandos de Python:

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Si la replicación está configurada de forma correcta, entre otros indicadores, se muestran los siguientes valores para los servicios xsengine, nameserver y indexserver:

• El Secondary Active Status es YES.
• El Replication Status es ACTIVE.

Además, el overall system replication status muestra ACTIVE.

Habilita los hooks del proveedor de HA/DR de SAP HANA

SUSE recomienda que habilites el hook del proveedor de HA/DR de SAP HANA, que permite que SAP HANA envíe notificaciones para ciertos eventos y mejora la detección de fallas. Los hooks del proveedor de HA/DR de SAP HANA requieren la versión de SAP HANA 2.0 SPS 03 o una posterior.

Nota: Si deseas implementar los hooks del proveedor HA/DR en un sistema SAP HANA preexistente con un tiempo de inactividad casi nulo, consulta el Guía de operaciones de SAP HANA.

En el sitio principal y secundario, completa los siguientes pasos:

1. Como SID_LCadm, detén SAP HANA:

   > sapcontrol -nr 00 -function StopSystem

1. Como raíz o SID_LCadm, abre el archivo global.ini para editarlo:

   > vi /hana/shared/SID/global/hdb/custom/config/global.ini

2. Agrega las siguientes definiciones al archivo global.ini:

   [ha_dr_provider_saphanasrmultitarget]
   provider = SAPHanaSrMultiTarget
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [ha_dr_provider_sustkover]
   provider = susTkOver
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 2
   sustkover_timeout = 30
   
   [ha_dr_provider_suschksrv]
   provider = susChkSrv
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 3
   action_on_lost = stop
   
   [trace]
   ha_dr_saphanasrmultitarget = info
   ha_dr_sustkover = info

3. Como raíz, crea un archivo de configuración personalizado en el directorio /etc/sudoers.d mediante la ejecución del siguiente comando. Este archivo de configuración nuevo permite que el usuario SID_LCadm acceda a los atributos del nodo del clúster cuando se llama al método de hook srConnectionChanged().

   > sudo visudo -f /etc/sudoers.d/SAPHanaSR

4. En el archivo /etc/sudoers.d/SAPHanaSR, agrega el siguiente texto:

   Reemplaza SID_LC por el SID en letras minúsculas.

   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_*
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_gsh *
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=SID_LC *

5. En el archivo /etc/sudoers, asegúrate de que se incluya el siguiente texto.

   • Para SLES para SAP 15 SP3 y versiones posteriores:

     @includedir /etc/sudoers.d

   • Para versiones hasta SLES para SAP 15 SP2:

     #includedir /etc/sudoers.d

     Ten en cuenta que el # de este texto es parte de la sintaxis y no significa que la línea sea un comentario.

   Nota: Si bien SUSE recomienda el procedimiento de esta sección, puedes usar un enfoque alternativo. En lugar de crear un archivo de configuración directo, puedes agregar el acceso requerido directamente al archivo /etc/sudoers.

6. Como SID_LCadm, inicia SAP HANA:

   > sapcontrol -nr 00 -function StartSystem

7. Después de completar la configuración del clúster para SAP HANA, puedes verificar que el hook funcione de forma correcta durante una prueba de conmutación por error, como se describe en Soluciona problemas del hook de Python de SAPHanaSR y Apropiación del clúster de HA tarda demasiado en la falla del servidor de índices de HANA.

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

El servicio de balanceador de cargas de red de transferencia interno con compatibilidad con la conmutación por error enruta el tráfico al host activo en un clúster de SAP HANA basado en un servicio de verificación de estado.

Reserva una dirección IP para la IP virtual

La dirección IP virtual (VIP), que a veces se conoce como dirección IP flotante, sigue el sistema SAP HANA activo. El balanceador de cargas enruta el tráfico que se envía a la VIP hacia la VM que aloja el sistema SAP HANA activo.

1. Abre Cloud Shell:

   Ir a Cloud Shell

2. Reserva una dirección IP para la IP virtual. Esta es la dirección IP que usan las aplicaciones para acceder a SAP HANA. Si omites la marca --addresses, se elige una dirección IP en la subred especificada:

   $ gcloud compute addresses create VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses VIP_ADDRESS

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

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

   $ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   Deberías ver un resultado similar al siguiente:

   address: 10.0.0.19
   addressType: INTERNAL
   creationTimestamp: '2020-05-20T14:19:03.109-07:00'
   description: ''
   id: '8961491304398200872'
   kind: compute#address
   name: vip-for-hana-ha
   networkTier: PREMIUM
   purpose: GCE_ENDPOINT
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Crea grupos de instancias para tus VM host

1. En Cloud Shell, crea dos grupos de instancias no administrados y asigna el VM host de instancia principal a uno y el VM host de instancia principal del secundario a la otra:

   $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE \
     --instances=PRIMARY_HOST_NAME
   $ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE \
     --instances=SECONDARY_HOST_NAME
   

2. Confirma la creación de los grupos de instancias:

   $ gcloud compute instance-groups unmanaged list

   Deberías ver un resultado similar al siguiente:

   NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
   hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
   hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Crea una verificación de estado de Compute Engine

1. En Cloud Shell, crea la verificación de estado. Para el puerto que usa la verificación de estado, elige un puerto que esté en el rango privado, 49152-65535, a fin de evitar conflictos con otros servicios. Los valores de intervalo de verificación y tiempo de espera son un poco más largos que los valores predeterminados con el fin de aumentar la tolerancia a la conmutación por error durante los eventos de migración en vivo de Compute Engine. Puedes ajustar los valores si es necesario:

   $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

2. Confirma la creación de la verificación de estado:

   $ gcloud compute health-checks describe HEALTH_CHECK_NAME

   Deberías ver un resultado similar al siguiente:

   checkIntervalSec: 10
   creationTimestamp: '2020-05-20T21:03:06.924-07:00'
   healthyThreshold: 2
   id: '4963070308818371477'
   kind: compute#healthCheck
   name: hana-health-check
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
   tcpHealthCheck:
    port: 60000
    portSpecification: USE_FIXED_PORT
    proxyHeader: NONE
   timeoutSec: 10
   type: TCP
   unhealthyThreshold: 2

Crea una regla de firewall para las verificaciones de estado

Define una regla de firewall para un puerto en el rango privado que permita el acceso a las VM de tu host desde los rangos de IP que usan las verificaciones de estado de Compute Engine, 35.191.0.0/16 y 130.211.0.0/22. Si deseas obtener más información, consulta Crea reglas de firewall para las verificaciones de estado.

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

   $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone PRIMARY_ZONE
   $ gcloud compute instances add-tags SECONDARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone SECONDARY_ZONE
   

2. Si aún no tienes una, crea una regla de firewall para permitir las verificaciones de estado:

   $ gcloud compute firewall-rules create RULE_NAME \
     --network NETWORK_NAME \
     --action ALLOW \
     --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --target-tags NETWORK_TAGS \
     --rules tcp:HLTH_CHK_PORT_NUM

   Por ejemplo:

   gcloud compute firewall-rules create  fw-allow-health-checks \
   --network example-network \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
   --target-tags cluster-ntwk-tag \
   --rules tcp:60000

Configura el balanceador de cargas y el grupo de conmutación por error

1. Crea el servicio de backend del balanceador de cargas:

   $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme internal \
     --health-checks HEALTH_CHECK_NAME \
     --no-connection-drain-on-failover \
     --drop-traffic-if-unhealthy \
     --failover-ratio 1.0 \
     --region CLUSTER_REGION \
     --global-health-checks

2. Agrega el grupo de instancias principal al servicio de backend:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group PRIMARY_IG_NAME \
     --instance-group-zone PRIMARY_ZONE \
     --region CLUSTER_REGION

3. Agrega el grupo de instancias de conmutación por error secundario al servicio de backend:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group SECONDARY_IG_NAME \
     --instance-group-zone SECONDARY_ZONE \
     --failover \
     --region CLUSTER_REGION

4. Crea una regla de reenvío. En la dirección IP, especifica la dirección IP que reservaste para la VIP. Si necesitas acceder al sistema SAP HANA desde fuera de la región que se especifica a continuación, incluye la marca --allow-global-access en la definición:

   $ gcloud compute forwarding-rules create RULE_NAME \
     --load-balancing-scheme internal \
     --address VIP_ADDRESS \
     --subnet CLUSTER_SUBNET \
     --region CLUSTER_REGION \
     --backend-service BACKEND_SERVICE_NAME \
     --ports ALL

   Para obtener más información sobre el acceso entre regiones al sistema de alta disponibilidad de SAP HANA, consulta Balanceo de cargas de TCP/UDP interno.

Nota: Tus grupos de instancias de backend no se registrarán como en buen estado hasta que completes la configuración del clúster de Pacemaker.

Prueba la configuración del balanceador de cargas

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

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

Prueba el balanceador de cargas con la utilidad socat

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

1. En la VM principal y la secundaria del host principal como raíz, instala la utilidad socat:

   # zypper install -y socat

2. Inicia un proceso socat para escuchar durante 60 segundos en el puerto de verificación de estado:

   # timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

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

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Debería ver un resultado similar al siguiente:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

Prueba el balanceador de cargas mediante el puerto 22

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

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

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

   Ir a la página Verificaciones de estado

2. Haz clic en Editar.

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

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

5. En Cloud Shell, verifica el estado de tus grupos de instancias de backend:

   $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Debería ver un resultado similar al siguiente:

   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

6. Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.

Configura Pacemaker

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

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

Descarga las secuencias de comandos del agente de recursos

Pasos manuales

Como raíz en todos los hosts principales y secundarios, y en el creador de mayorías, descarga las secuencias de comandos del agente de recursos necesarias:

# mkdir -p /usr/lib64/stonith/plugins/external
# curl https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith
# chmod +x /usr/lib64/stonith/plugins/external/gcpstonith

Pasos automatizados

Como alternativa, ejecuta el siguiente comando desde la consola de Google Cloud a fin de descargar las secuencias de comandos de agentes de recursos necesarias para todas las instancias enumeradas en nodes.txt:

while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "echo 'CLOUDSDK_PYTHON=/usr/bin/python' | sudo tee -a /etc/sysconfig/pacemaker; sudo curl --silent https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith; sudo chmod +x /usr/lib64/stonith/plugins/external/gcpstonith"; done 10< nodes.txt

Inicializa el clúster

En el host principal como raíz, inicializa el clúster:

SLES 15

crm cluster init -y

SLES 12

ha-cluster-init -y

Ignora las advertencias relacionadas con el SBD y la contraseña predeterminada. El SBD y la contraseña predeterminada no se usan en esta implementación.

Configura el clúster

Realiza los siguientes pasos en el host principal como raíz.

Habilita el modo de mantenimiento

Coloca el clúster de Pacemaker en modo de mantenimiento:

crm configure property maintenance-mode="true"

Configura las propiedades generales del clúster

Configura las siguientes propiedades generales del clúster:

crm configure property stonith-timeout="300s"
crm configure property stonith-action="reboot"
crm configure property stonith-enabled="true"
crm configure property cluster-infrastructure="corosync"
crm configure property cluster-name="hacluster"
crm configure property placement-strategy="balanced"
crm configure property no-quorum-policy="freeze"
crm configure property concurrent-fencing="true"

crm configure rsc_defaults migration-threshold="50"
crm configure rsc_defaults resource-stickiness="1000"

crm configure op_defaults timeout="600"

Edita la configuración predeterminada de corosync.conf

1. Abre el archivo /etc/corosync/corosync.conf con el editor que prefieras.

2. Quita el parámetro consensus.

3. Modifica los parámetros restantes según las recomendaciones de Google Cloud.

   En la siguiente tabla, se muestran los parámetros totem para los que Google Cloud recomienda valores, junto con el impacto de cambiarlos. Para conocer los valores predeterminados de estos parámetros, que pueden diferir entre distribuciones de Linux, consulta la documentación de tu distribución de Linux.

   Parámetro	Valor recomendado	Impacto del cambio de valor
   secauth	off	Inhabilita la autenticación y encriptación de todos los mensajes totem
   join	60 (ms)	Aumenta el tiempo de espera del nodo para recibir mensajes join en el protocolo de membresía.
   max_messages	20	Aumenta la cantidad máxima de mensajes que puede enviar el nodo después de recibir el token.
   token	20000 (ms)	Aumenta el tiempo de espera del nodo para obtener un token de protocolo totem antes de que el nodo declare la pérdida del token, suponga una falla de nodo y comience a tomar medidas. Aumentar el valor del parámetro token hace que el clúster sea más tolerante a los eventos momentáneos de la infraestructura, como una migración en vivo. Sin embargo, también puede hacer que el clúster tarde más tiempo en detectar las fallas de nodos y en recuperarse de ellas. El valor del parámetro token también determina el valor predeterminado del parámetro consensus, que controla cuánto tiempo espera un nodo para permitir que se logre el consenso antes de intentar restablecer la membresía de configuración.
   consensus	No disponible	Especifica en milisegundos cuánto tiempo se debe esperar para que se logre el consenso antes de comenzar una nueva ronda de configuración de membresía. Te recomendamos omitir este parámetro. Cuando no se especifica el parámetro consensus, Corosync establece su valor en 1.2 veces el valor del parámetro token. Si usas el valor recomendado 20000 del parámetro token, el parámetro consesus se establece con el valor 24000. Si especificas de forma explícita un valor para consensus, asegúrate de que el valor sea 24000 o 1.2*token, lo que sea mayor.
   token_retransmits_before_loss_const	10	Aumenta la cantidad de retransmisiones del token que intenta realizar el nodo antes de suponer que ocurrió una falla en el nodo receptor y comenzar a tomar medidas.
   transport	Para SLES: udpu Para RHEL 8 o versiones posteriores: knet Para RHEL 7: udpu	Especifica el mecanismo de transporte que usa corosync.

Une todos los hosts al clúster de Pacemaker

Une todos los demás hosts, incluido el creador de mayorías, al clúster de Pacemaker en el host principal:

Pasos manuales

SLES 15

crm cluster join -y -c PRIMARY_HOST_NAME

SLES 12

ha-cluster-join -y -c PRIMARY_HOST_NAME

Pasos automatizados

Como alternativa, ejecuta el siguiente comando desde la consola de Google Cloud a fin de automatizar este proceso para todas las instancias que se enumeran en nodes.txt:

while read -u10 HOST ;  do echo "Joining $HOST to Pacemaker cluster";
gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- sudo ha-cluster-join -y -c PRIMARY_HOST_NAME;
done 10< nodes.txt

Ignora el mensaje de error ERROR: cluster.join: Abort: Cluster is currently active que se activa cuando se une al nodo principal.

Desde cualquier host como raíz, confirma que el clúster muestre todos los nodos:

# crm_mon -s

Debería ver un resultado similar al siguiente:

CLUSTER OK: 5 nodes online, 0 resources configured

Configura la protección

Para configurar la protección, debes definir un recurso de clúster con un agente de protección para cada VM del host.

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

Crea los recursos del dispositivo de protección

Pasos manuales

En el host principal, como raíz, crea los recursos de protección para todos los nodos del clúster principal y el secundario:

1. Ejecuta el siguiente comando después de reemplazar PRIMARY_HOST_NAME por el nombre de host de un nodo en el clúster principal:

   # crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="PRIMARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

2. Repite el paso anterior para todos los demás nodos del clúster principal.

3. Ejecuta el siguiente comando después de reemplazar SECONDARY_HOST_NAME por el nombre de host de un nodo en el clúster secundario.

   # crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="SECONDARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

4. Repite el paso anterior para todos los demás nodos del clúster secundario.

5. Ejecuta el siguiente comando después de reemplazar MAJORITY_MAKER_HOSTNAME por el nombre de host de la instancia del creador de mayoría:

   # crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="MAJORITY_MAKER_HOSTNAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

6. Establece la ubicación del dispositivo de protección:

   # crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \
       STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"

7. Repite los dos pasos anteriores para todos los demás hosts en los clústeres principal y secundario, incluido el host creador de mayorías.

Pasos automatizados

Como alternativa, ejecuta la siguiente secuencia de comandos desde la consola de Google Cloud para configurar la protección de todas las instancias que se enumeran en nodes.txt:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   -- "sudo crm configure primitive STONITH-\$HOSTNAME stonith:external/gcpstonith op monitor interval=\"300s\" timeout=\"60s\" on-fail=\"restart\" op start interval=\"0\" timeout=\"60s\" onfail=\"restart\" params instance_name=\$HOSTNAME gcloud_path=\"/usr/bin/gcloud\" logging=\"yes\" pcmk_reboot_timeout=300 pcmk_monitor_retries=4; sudo crm configure location LOC_STONITH_\$HOSTNAME STONITH-\$HOSTNAME -inf: \$HOSTNAME"; done 10< nodes.txt

Establece una demora para el reinicio de Corosync

Pasos manuales

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

   systemctl edit corosync.service

2. Agrega las siguientes líneas al archivo:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Guarda el archivo y sal del editor.

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

   systemctl daemon-reload

5. Confirma que se creó el archivo directo:

   service corosync status

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

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

Pasos automatizados

Como alternativa, ejecuta el siguiente comando desde la consola de Google Cloud a fin de automatizar este proceso para todas las instancias que se enumeran en nodes.txt:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

Crea un recurso de IP de clúster local para la dirección VIP

Para configurar la dirección VIP en el sistema operativo, crea un recurso de IP de clúster local para la dirección VIP que reservaste antes:

# crm configure primitive rsc_vip_int-primary IPaddr2 \
     params ip=VIP_ADDRESS cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s

Configura el servicio de verificación de estado auxiliar

El balanceador de cargas usa un objeto de escucha en el puerto de verificación de estado de cada host para determinar dónde se ejecuta la instancia principal del clúster de SAP HANA.

A fin de administrar los objetos de escucha en el clúster, debes crear un recurso para el objeto de escucha.

Estas instrucciones usan la utilidad socat como objeto de escucha.

1. En ambos hosts como raíz, instala socat utility:

   # zypper in -y socat

2. En el host principal, crea un recurso para el servicio de verificación de estado auxiliar:

   crm configure primitive rsc_healthcheck-primary anything \
   params binfile="/usr/bin/socat" \
   cmdline_options="-U TCP-LISTEN:HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
   op monitor timeout=20s interval=10s \
   op_params depth=0

3. Agrupa los recursos VIP y auxiliares del servicio de verificación de estado:

   # crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary meta resource-stickiness="0"

Crea el recurso básico de SAPHanaTopology

Debes definir el recurso básico SAPHanaTopology en un archivo de configuración temporal, que luego subirás a Corosync.

En el host principal como raíz:

1. Crea un archivo de configuración temporal para los parámetros de configuración de SAPHanaTopology:

   # vi /tmp/cluster.tmp

2. Copia y pega las definiciones de recursos de SAPHanaTopology en el archivo /tmp/cluster.tmp:

   primitive rsc_SAPHanaTopology_SID_HDBINST_NUM ocf:suse:SAPHanaTopology \
    operations \$id="rsc_sap2_SID_HDBINST_NUM-operations" \
    op monitor interval="10" timeout="600" \
    op start interval="0" timeout="600" \
    op stop interval="0" timeout="300" \
    params SID="SID" InstanceNumber="INST_NUM"
   
   clone cln_SAPHanaTopology_SID_HDBINST_NUM rsc_SAPHanaTopology_SID_HDBINST_NUM \
    meta clone-node-max="1" target-role="Started" interleave="true"
   location SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

3. Edita el archivo /tmp/cluster.tmp para reemplazar el texto de la variable con el SID y el número de instancia de tu sistema SAP HANA.

4. En la instancia principal como raíz, carga el contenido del archivo /tmp/cluster.tmp en Corosync:

   crm configure load update /tmp/cluster.tmp

Crea el recurso básico de SAPHana

Debes definir el recurso básico de SAPHana con el mismo método que usaste para el recurso SAPHanaTopology: en un archivo de configuración temporal, que luego subirás a Corosync.

1. Reemplaza el archivo de configuración temporal:

   # rm /tmp/cluster.tmp
   # vi /tmp/cluster.tmp

2. Copia y pega las definiciones de recursos de SAPHana en el archivo /tmp/cluster.tmp:

   primitive rsc_SAPHana_SID_HDBINST_NUM ocf:suse:SAPHanaController \
    operations \$id="rsc_sap_SID_HDBINST_NUM-operations" \
    op start interval="0" timeout="3600" \
    op stop interval="0" timeout="3600" \
    op promote interval="0" timeout="3600" \
    op demote interval="0" timeout="3600" \
    op monitor interval="60" role="Master" timeout="700" \
    op monitor interval="61" role="Slave" timeout="700" \
    params SID="SID" InstanceNumber="INST_NUM" PREFER_SITE_TAKEOVER="true" \
    DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"
   
   ms msl_SAPHana_SID_HDBINST_NUM rsc_SAPHana_SID_HDBINST_NUM \
    meta master-node-max="1" master-max="1" clone-node-max="1" \
    target-role="Started" interleave="true"
   
   colocation col_saphana_ip_SID_HDBINST_NUM 4000: g-primary:Started \
    msl_SAPHana_SID_HDBINST_NUM:Master
   order ord_SAPHana_SID_HDBINST_NUM Optional: cln_SAPHanaTopology_SID_HDBINST_NUM \
    msl_SAPHana_SID_HDBINST_NUM
   location SAPHanaCon_not_on_majority_maker  msl_SAPHana_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

   Para un clúster de SAP HANA con alta disponibilidad de varios niveles, si usas una versión anterior a SAP HANA 2.0 SP03, configura AUTOMATED_REGISTER como false. Esto evita que una instancia recuperada intente registrarse para la replicación en un sistema HANA que ya tiene un destino de replicación configurado. Para SAP HANA 2.0 SP03 o versiones posteriores, puedes establecer AUTOMATED_REGISTER como true para las configuraciones de SAP HANA que usan la replicación de sistemas de varios niveles. Para obtener información adicional, consulta:

   • Escalamiento vertical de la replicación del sistema de SAP HANA
   • Alta disponibilidad de escalamiento vertical de HANA con replicación del sistema y conmutación por error automatizada

3. En la instancia principal como raíz, carga el contenido del archivo /tmp/cluster.tmp en Corosync:

   crm configure load update /tmp/cluster.tmp

Confirma que la replicación del sistema SAP HANA esté activa

En el host principal como SID_LCadm, verifica el estado de replicación:

# python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Activa el clúster

1. En el host principal como raíz, quita el clúster del modo de mantenimiento:

   # crm configure property maintenance-mode="false"

   Si recibes un mensaje que te pide que quites el “mantenimiento”, ingresa y.

2. Espera 15 segundos y, luego, en el host principal como raíz, verifica el estado del clúster:

   # crm status

   En los siguientes ejemplos, se muestra el estado de un clúster activo y configurado correctamente:

7 nodes configured
21 resources configured
Online: [   hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 sap-majoritymaker ]


Full list of resources:


 STONITH-hana-ha-vm-1   (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith):  Started hana-ha-vm-1
 STONITH-hana-ha-vm-1w2 (stonith:external/gcpstonith):  Started hana-ha-vm-2
 STONITH-sap-majoritymaker      (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-2w1
 STONITH-hana-ha-vm-2w1 (stonith:external/gcpstonith):  Started hana-ha-vm-2w2
 STONITH-hana-ha-vm-2w2 (stonith:external/gcpstonith):  Started sap-majoritymaker
 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
     Started: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]
 Resource Group: g-primary
     rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
     rsc_healthcheck-primary    (ocf::heartbeat:anything):      Started hana-ha-vm-1
 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
     Masters: [ hana-ha-vm-1 ]
     Slaves: [ hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]

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

Realiza una copia de seguridad del sistema antes de la prueba.

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

• HDB stop
• HDB kill
• reboot (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. En el host activo, como raíz, desconecta la interfaz de red:

   # ip link set eth0 down

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

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

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
   Last updated: Fri Jun 12 16:46:07 2020
   Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:external/gcpstonith):  Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:external/gcpstonith):    Started hana-ha-vm-1w1
   Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]
   Resource Group: g-primary
       rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
       rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
   Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]

Evalúa la carga de trabajo de SAP HANA

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

Workload Manager te permite analizar y evaluar automáticamente las cargas de trabajo de alta disponibilidad de SAP HANA 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 HANA 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 opciones de configuración de alta disponibilidad para SAP HANA en SLES, consulta Solución de problemas de opciones de configuración de alta disponibilidad para SAP.

Obtén asistencia para SAP HANA en SLES

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

Asistencia

Si tienes problemas con la infraestructura o los servicios de Google Cloud, comunícate con el servicio de Atención al cliente. Puedes encontrar la información de contacto en la página Descripción general de la asistencia en 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:

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

Conéctate a SAP HANA

Si las VM del host no tienen una dirección IP externa para SAP HANA, solo puedes conectarte a las instancias de SAP HANA a través de la instancia de bastión mediante SSH o a través del servidor de Windows de SAP HANA Studio.

• Para conectarte a SAP HANA a través de la instancia de bastión, conéctate al host de bastión y, luego, a las instancias de SAP HANA mediante el cliente SSH que prefieras.

• Para conectarte a la base de datos de SAP HANA a través de SAP HANA Studio, usa un cliente de escritorio remoto para conectarte a la instancia de Windows Server. Después de la conexión, instala SAP HANA Studio de forma manual y accede a la base de datos de SAP HANA.

Tareas posteriores a la implementación

Después de completar la implementación, finaliza los siguientes pasos:

1. Cambia las contraseñas temporales para el administrador del sistema de SAP HANA y el superusuario de la base de datos. Por ejemplo:

   sudo passwd SID_LCadm

   Para obtener información de SAP sobre cómo cambiar la contraseña, consulta Restablece la contraseña del usuario del sistema de la base de datos del sistema.

2. Antes de usar la instancia de SAP HANA, configura la base de datos de SAP HANA nueva y crea una copia de seguridad.

3. Si tu sistema SAP HANA se implementa en una interfaz de red de VirtIO, te recomendamos que te asegures de que el valor del parámetro de TCP /proc/sys/net/ipv4/tcp_limit_output_bytes esté configurado como 1048576. Esta modificación ayuda a mejorar la capacidad de procesamiento general de la red en la interfaz de red de VirtIO sin afectar la latencia de la red.

Para obtener más información, consulte:

• Guía de operaciones de SAP HANA.
• SAP HANA Installation and Update Guide (Guía de instalación y actualización de SAP HANA).

Próximos pasos

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

Automated SAP HANA System Replication in Scale-Up in pacemaker cluster (Replicación automatizada del sistema SAP HANA en escalamiento vertical en clústeres de Pacemaker)

Guía de planificación de alta disponibilidad de SAP HANA

Guía de planificación de recuperación ante desastres de SAP HANA

Para obtener más información sobre la administración y la supervisión de VM, consulta la Guía de operaciones de SAP HANA.