En esta guía, se muestra cómo implementar y configurar un clúster de alta disponibilidad (HA) de Red Hat Enterprise Linux (RHEL) para un sistema de escalamiento vertical de SAP HANA 1.0 SPS 12 o posterior 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 RHEL 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.
Si deseas configurar un clúster de HA para SAP HANA en SUSE Linux Enterprise Server (SLES), consulta la guía de configuración de clústeres de HA para 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
Al seguir las instrucciones de esta guía, podrás implementar dos instancias de SAP HANA y configurar un clúster de HA en RHEL. Implementas cada instancia de SAP HANA en una VM de Compute Engine en una zona diferente dentro de la misma región. En esta guía, no se aborda la instalación de alta disponibilidad de SAP NetWeaver.
El clúster implementado incluye las siguientes funciones y características:
- Dos VM de host, cada una con una instancia de SAP HANA
- Replicación síncrona del sistema SAP HANA.
- El administrador de recursos del clúster de alta disponibilidad de Pacemaker
- Un mecanismo de defensa STONITH
- Reinicio automático de la instancia con errores como la instancia secundaria nueva
En esta guía, se usan las plantillas de Cloud Deployment Manager que proporciona Google Cloud para implementar las máquinas virtuales (VM) de Compute Engine 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:
Si usas un DNS interno de VPC, el valor de la variable
vmDnsSetting
en los metadatos del proyecto debe serGlobalOnly
oZonalPreferred
para habilitar la resolución de los nombres del nodo entre zonas. La configuración predeterminada devmDnsSetting
esZonalOnly
. Para obtener más información, consulta:
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
- En la consola de Google Cloud, ve a la página Redes de VPC.
- Haga clic en Crear red de VPC.
- 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.
- En Modo de creación de subredes, selecciona Custom.
- En la sección Subred nueva, especifica los siguientes parámetros de configuración para una subred:
- Ingresa un Nombre para la subred.
- En Región, selecciona la región de Compute Engine en la que deseas crear la subred.
- 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.
- Haga clic en Listo.
- 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.
- Haga clic en Crear.
gcloud
- Ve a Cloud Shell.
- 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. - 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 nuevaNETWORK_NAME
: el nombre de la zona que creaste en el paso anteriorREGION
: la región en la que deseas que esté la subredRANGE
: el rango de direcciones IP especificado en formato CIDR, como10.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.
- 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.
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.
- Comunicación entre las VM de la subred de SAP HANA, incluida la comunicación entre los nodos en un sistema de escalamiento horizontal de SAP HANA o la comunicación entre el servidor de base de datos y los servidores de aplicaciones en una arquitectura de 3 niveles. Puedes habilitar la comunicación entre las VM si creas una regla de firewall para permitir el tráfico que se origina desde la subred.
Para crear una regla de firewall, sigue estos pasos:
Consola
En la consola de Google Cloud, ve a la página Firewall de la red de VPC.
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
.
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
Antes de comenzar a configurar el clúster de HA, debes definir e implementar las instancias de VM y los sistemas SAP HANA que funcionan como los nodos principales y secundarios en tu clúster de HA.
A fin de definir e implementar los sistemas, usa la misma plantilla de Cloud Deployment Manager que usas para implementar un sistema SAP HANA en la guía de implementación de SAP HANA.
Sin embargo, a fin de implementar dos sistemas en lugar de uno, debes agregar la definición del segundo sistema al archivo de configuración. Para ello, copia y pega la definición del primer sistema. Después de crear la segunda definición, debes cambiar los nombres de los recursos y las instancias en la segunda definición. Para evitar una falla zonal, especifica una zona diferente en la misma región. Todos los demás valores de propiedad en las dos definiciones permanecen iguales.
Una vez que los sistemas SAP HANA se implementen de forma correcta, debes definir y configurar el clúster de HA.
En las siguientes instrucciones, se usa Cloud Shell, pero, en términos generales, se pueden aplicar a Google Cloud CLI.
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.
Abre Cloud Shell o, si instalaste la CLI de gcloud en tu estación de trabajo local, abre una terminal.
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
De manera opcional, cambia el nombre del archivo
template.yaml
para identificar la configuración que define.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.
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óntype
que está activa de forma predeterminada especifica la versión de la plantilla comolatest
. La especificacióntype
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. Una vez completada la implementación, modifica la cantidad de CPU virtuales y la cantidad 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 HANA principales y secundarias. 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/rhel-7-6-sap-ha
. 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 rhel-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. 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. sap_hana_sidadm_uid
Integer El valor predeterminado para el ID de usuario SID_LCadm
es900
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
Entero Especifica 0
. Estas instrucciones son solo para sistemas SAP HANA de escalamiento vertical.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
oVIRTIO_NET
. Para usar una NIC virtual de Google (gVNIC), debes especificar una imagen de SO que admita gVNIC como valor de la propiedadlinuxImage
. 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
Este argumento está disponible en las versionesinstanceType
.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
.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, svc-acct-name@project-id.iam.gserviceaccount.com. 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. 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.
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
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 instancias de VMs con un sistema SAP HANA instalado.
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/rhel-8-1-sap-ha linuxImageProject: rhel-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: 0 networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # 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/rhel-8-1-sap-ha linuxImageProject: rhel-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: 0 networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # sap_hana_sidadm_uid: 900 # sap_hana_sapsys_gid: 79
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.
En la consola de Google Cloud, abre Cloud Logging para supervisar el progreso de la instalación y verificar si hay errores.
Filtra los registros:
Explorador de registros
En la página Explorador de registros, ve al panel Consulta.
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"
Haz clic en Ejecutar consulta.
Visor de registros heredado
- En la página Visor de registros heredado, en el menú del selector básico, selecciona Global como tu recurso de registro.
Analiza los registros filtrados:
- Si se muestra
"--- Finished"
, el proceso de implementación está completo y puedes continuar con el siguiente paso. Si ves un error de cuota, sigue estos pasos:
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.
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.
Vuelve a ejecutar tu implementación.
- Si se muestra
Verifica la configuración de las VM y SAP HANA
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.
Cambia al usuario raíz.
$
sudo su -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
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_LCadmEjecuta el siguiente comando para asegurarte de que los servicios de SAP HANA, como
hdbnameserver
,hdbindexserver
y otros, se ejecuten en la instancia:>
HDB infoSi usas RHEL para SAP 9.0 o una versión posterior, asegúrate de que los paquetes
chkconfig
ycompat-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:
Establece una conexión SSH con la instancia de VM del host.
Ejecuta el siguiente comando:
systemctl status google-cloud-sap-agent
Si el agente funciona de forma correcta, el resultado contendrá
active (running)
. Por ejemplo:google-cloud-sap-agent.service - Google Cloud Agent for SAP Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2022-12-02 07:21:42 UTC; 4 days ago Main PID: 1337673 (google-cloud-sa) Tasks: 9 (limit: 100427) Memory: 22.4 M (max: 1.0G limit: 1.0G) CGroup: /system.slice/google-cloud-sap-agent.service └─1337673 /usr/bin/google-cloud-sap-agent
Si el agente no está en ejecución, reinicia el agente.
Verifica que el agente de host SAP reciba métricas
Para verificar que el Agente de Google Cloud para SAP recopile las métricas de infraestructura y que se envíen de forma correcta al agente de host SAP, sigue estos pasos:
- En el sistema SAP, ingresa la transacción
ST06
. En el panel de descripción general, revisa la disponibilidad y el contenido de los siguientes campos para verificar la configuración completa y correcta de la infraestructura de supervisión de SAP y Google:
- Proveedor de servicios en la nube:
Google Cloud Platform
- Acceso de supervisión mejorada:
TRUE
- Detalles de supervisión mejorada:
ACTIVE
- Proveedor de servicios en la nube:
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.
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.
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
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.
Para habilitar el reinicio rápido de SAP HANA, sigue estos pasos:
Establece una conexión SSH con la VM del host.
Cambiar a la raíz:
sudo su -
Descarga la secuencia de comandos
sap_lib_hdbfr.sh
:wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh
Haz que el archivo sea ejecutable:
chmod +x sap_lib_hdbfr.sh
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.
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)
Opcional: Configura claves SSH en las VM principales y secundarias
Las claves del almacenamiento seguro (SSFS) de SAP HANA deben sincronizarse entre los hosts en el clúster de HA. En estas instrucciones, para simplificar la sincronización y permitir que se copien archivos (como las copias de seguridad) entre los hosts en el clúster de HA, se autorizan las conexiones SSH directas entre los dos hosts.
Es probable que tu organización tenga lineamientos que rijan las comunicaciones de redes internas. Si es necesario, después de completar la implementación, puedes quitar los metadatos de las VM y las claves del directorio authorized_keys
.
Si configurar conexiones SSH directas no cumple con los lineamientos de tu organización, puedes sincronizar las claves SSFS y transferir archivos mediante otros métodos, como los que se mencionan a continuación:
- Transfiere archivos más pequeños a través de tu estación de trabajo local mediante las opciones del menú Subir archivo y Descargar archivo de Cloud Shell. Consulta Administra archivos con Cloud Shell.
- Intercambia archivos mediante un bucket de Google Cloud Storage. Consulta Trabaja con objetos en la documentación de Cloud Storage.
- Usa el agente de Backint de Cloud Storage para SAP HANA a fin de crear una copia de seguridad y restablecer las bases de datos de HANA. Consulta Agente de Backint de Cloud Storage para SAP HANA.
- Usa una solución de almacenamiento de archivos como Filestore o NetApp Cloud Volumes Service para crear una carpeta compartida. Consulta Opciones del servidor de archivos.
Para habilitar las conexiones SSH entre la instancia principal y la secundaria, haz lo que se indica a continuación.
En la VM host principal, sigue estos pasos:
Conéctate a la VM mediante SSH.
Genera una clave SSH para el usuario que necesita la conexión SSH de host a host. El usuario sueles ser tú.
$
ssh-keygenEn los mensajes, presiona Intro para aceptar los valores predeterminados.
Actualiza los metadatos de la VM principal con información sobre la clave SSH para la VM secundaria.
$
gcloud compute instances add-metadata secondary-host-name \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone secondary-zoneAutoriza la VM principal a sí misma
$
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
En la VM secundaria del host, sigue estos pasos:
Conéctate a la VM mediante SSH.
Genera una clave SSH para el usuario que necesita la conexión SSH de host a host.
$
ssh-keygenActualiza los metadatos de la VM secundaria con información sobre la clave SSH para la VM principal.
$
gcloud compute instances add-metadata primary-host-name \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone primary-zoneAutoriza la VM secundaria a sí misma
$
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysPara confirmar que las claves SSH estén configuradas de forma correcta, abre una conexión SSH desde el sistema secundario al principal.
$
ssh primary-host-name
En la VM principal del host, abre una conexión SSH a la VM secundaria del host para confirmar la conexión:
$
ssh secondary-host-name
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:
En el host principal, cambia a
SID_LCadm
. El comando puede ser diferente según la imagen de SO.sudo -i -u SID_LCadm
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)
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.
En el host principal como
SID_LCadm
, habilita la replicación del sistema:>
hdbnsutil -sr_enable --name=primary-host-nameEn el host secundario como
SID_LCadm
, detén SAP HANA:>
HDB stopEn el host principal, mediante la misma cuenta de usuario que usaste para configurar la conexión SSH entre las VM del host, copia los archivos de claves en el host secundario. A fin de lograr mayor comodidad, con los siguientes comandos, también se define una variable de entorno para tu ID de cuenta de usuario:
$
sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r$
myid=$(whoami)$
sudo chown ${myid} -R /home/"${myid}"/rsecssfs$
scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs$
rm -r /home/"${myid}"/rsecssfsEn el host secundario, con el mismo usuario que en el paso anterior, sigue estos pasos:
Reemplaza los archivos de claves existentes en los directorios rsecssfs por los archivos del host principal y establece los permisos del archivo para limitar el acceso:
$
SAPSID=SID$
sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT$
sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY$
myid=$(whoami)$
sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT$
sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY$
sudo chown "${SAPSID,,}"adm:sapsys \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT$
sudo chown "${SAPSID,,}"adm:sapsys \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY$
sudo chmod 644 \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT$
sudo chmod 640 \ /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEYLimpia los archivos del directorio principal.
$
rm -r /home/"${myid}"/rsecssfsComo
SID_LCadm
, 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-nameComo
SID_LCadm
, inicia SAP HANA:>
HDB start
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
esYES
. - El
Replication Status
esACTIVE
.
Además, el overall system replication status
muestra ACTIVE
.
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.
Abre Cloud Shell:
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_ADDRESSPara obtener más información sobre cómo reservar una IP estática, consulta Reserva una dirección IP interna estática.
Confirma la reserva de la dirección IP:
$
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONDeberí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
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_NAMEConfirma la creación de los grupos de instancias:
$
gcloud compute instance-groups unmanaged listDeberí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
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=2Confirma la creación de la verificación de estado:
$
gcloud compute health-checks describe HEALTH_CHECK_NAMEDeberí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.
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_ZONESi 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_NUMPor 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
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-checksAgrega 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_REGIONAgrega 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_REGIONCrea 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 ALLPara 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.
Prueba la configuración del balanceador de cargas
Aunque los grupos de instancias de backend no se registren como en buen estado, puedes probar la configuración del balanceador de cargas mediante la configuración de un objeto de escucha que responda a las verificaciones de estado. Después de configurar un objeto de escucha, si el balanceador de cargas está configurado de forma correcta, el estado de los grupos de instancias de backend cambia a en buen estado.
En las siguientes secciones, se presentan diferentes métodos que puedes usar para probar la configuración.
Prueba el balanceador de cargas con la utilidad socat
Puedes usar la utilidad socat
para escuchar de forma temporal en el puerto de verificación de estado.
En ambas VMs del host, instala la utilidad
socat
:$
sudo yum install -y socatInicia un proceso
socat
para escuchar durante 60 segundos en el puerto de verificación de estado:$
sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkEn 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_REGIONDeberí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:
Haz clic en la verificación de estado en la consola:
Haz clic en Editar.
En el campo Puerto, cambia el número de puerto a 22.
Haz clic en Guardar y espera uno o dos minutos.
En Cloud Shell, verifica el estado de tus grupos de instancias de backend:
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDeberí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
Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.
Configura Pacemaker
Con el siguiente procedimiento, se configura la implementación de Red Hat de un clúster de Pacemaker en las VM de Compute Engine para SAP HANA.
El procedimiento se basa en la documentación de Red Hat para configurar clústeres de alta disponibilidad, que incluyen lo siguiente (se requiere una suscripción a Red Hat):
- Instalación y configuración de un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Cloud
- Replicación automatizada del sistema SAP HANA en el escalamiento vertical en el clúster de Pacemaker
Instala los agentes del clúster en ambos nodos
Completa los siguientes pasos en ambos nodos.
Como raíz, instala los componentes de Pacemaker:
#
yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana#
yum update -ySi usas una imagen de RHEL para SAP proporcionada por Google, estos paquetes ya están instalados, pero es posible que se requieran algunas actualizaciones.
Configura la contraseña para el usuario
hacluster
, que se instala como parte de los paquetes:#
passwd haclusterEspecifica una contraseña para
hacluster
en los mensajes.En las imágenes de RHEL que proporciona Google Cloud, el servicio de firewall del SO está activo de forma predeterminada. Configura el servicio de firewall para permitir el tráfico de alta disponibilidad:
#
firewall-cmd --permanent --add-service=high-availability#
firewall-cmd --reloadInicia el servicio pcs y configúralo para que se inicie en el momento del inicio:
#
systemctl start pcsd.service#
systemctl enable pcsd.serviceComprueba el estado del servicio pcs:
#
systemctl status pcsd.serviceDeberías ver un resultado similar al siguiente:
● pcsd.service - PCS GUI and remote configuration interface Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago Docs: man:pcsd(8) man:pcs(8) Main PID: 31627 (pcsd) CGroup: /system.slice/pcsd.service └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface... Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
En el archivo
/etc/hosts
, agrega el nombre completo del host y las direcciones IP internas de ambos hosts en el clúster. Por ejemplo:127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1 # Added by Google 10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2 169.254.169.254 metadata.google.internal # Added by Google
Para obtener más información de Red Hat sobre la configuración del archivo
/etc/hosts
en los nodos del clúster de RHEL, consulta https://access.redhat.com/solutions/81123.
Cree el clúster
Como raíz en cualquiera de los nodos, autoriza al usuario
hacluster
. Haz clic en la pestaña de tu versión de RHEL para ver el comando:RHEL 8 y versiones posteriores
#
pcs host auth primary-host-name secondary-host-nameRHEL 7
#
pcs cluster auth primary-host-name secondary-host-nameEn los mensajes, ingresa el nombre de usuario
hacluster
y la contraseña que configuraste para el usuariohacluster
.Crea el clúster:
RHEL 8 y versiones posteriores
#
pcs cluster setup cluster-name primary-host-name secondary-host-nameRHEL 7
#
pcs cluster setup --name cluster-name primary-host-name secondary-host-name
Edita la configuración predeterminada de corosync.conf
Edita el archivo /etc/corosync/corosync.conf
en el host principal a fin de establecer un punto de partida más apropiado para probar la tolerancia a errores del clúster de HA en Google Cloud.
En cualquier host, usa tu editor de texto preferido a fin de abrir el archivo
/etc/corosync/corosync.conf
para editarlo:#
/etc/corosync/corosync.confSi
/etc/corosync/corosync.conf
es un archivo nuevo o vacío, puedes verificar el directorio/etc/corosync/
para ver un archivo de ejemplo que usarás como base para el archivo de Corosync.En la sección
totem
del archivo corosync.conf, agrega las siguientes propiedades con los valores sugeridos como se muestra para tu versión de RHEL:RHEL 8 y versiones posteriores
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
Por ejemplo:
totem { version: 2 cluster_name: hacluster secauth: off transport: knet token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 } ...
RHEL 7
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
Por ejemplo:
totem { version: 2 cluster_name: hacluster secauth: off transport: udpu token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 } ...
Desde el host que contiene el archivo
corosync.conf
editado, sincroniza la configuración de corosync en el clúster:RHEL 8 y versiones posteriores
#
pcs cluster sync corosyncRHEL 7
#
pcs cluster syncConfigura el clúster para que se inicie de manera automática:
#
pcs cluster enable --all#
pcs cluster start --all
Confirma que la nueva configuración de corosync esté activa en el clúster mediante la utilidad corosync-cmapctl:
#
corosync-cmapctl
Configura la protección
Las imágenes de RHEL que proporciona Google Cloud incluyen un agente de protección fence_gce
que es específico de Google Cloud. Usa fence_gce
a fin de crear dispositivos 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, 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.
Para ver todas las opciones disponibles con el agente de protección fence_gce
, emite fence_gce -h
.
Crea los recursos del dispositivo de protección
En el host principal como raíz:
Crea un dispositivo de protección para cada VM del host:
#
pcs stonith create primary-fence-name fence_gce \ port=primary-host-name \ zone=primary-host-zone \ project=project-id \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"#
pcs stonith create secondary-fence-name fence_gce \ port=secondary-host-name \ zone=secondary-host-zone \ project=project-id \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"Restringe cada dispositivo de protección a la otra VM del host:
#
pcs constraint location primary-fence-name avoids primary-host-name#
pcs constraint location secondary-fence-name avoids secondary-host-name
En el host principal como raíz, prueba el dispositivo de protección secundario:
Apaga la VM del host secundaria:
#
fence_gce -o off -n secondary-host-name --zone=secondary-host-zoneSi el comando se ejecuta de forma correcta, perderás conectividad con la VM secundaria del host y aparecerá detenida en la página Instancias de VM en la consola de Google Cloud. Es posible que debas actualizar la página.
Reinicia la VM del host secundaria:
#
fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
En el host secundario como raíz, repite los pasos anteriores mediante los valores del host principal en los comandos para probar la protección principal.
En cualquiera de los hosts como raíz, verifica el estado del clúster:
#
pcs statusLos recursos de protección aparecen en la sección de recursos del estado del clúster, de manera similar al siguiente ejemplo:
[root@hana-ha-vm-2 ~]# pcs status Cluster name: hana-ha-cluster Stack: corosync Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum Last updated: Mon Jun 15 17:19:07 2020 Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1 2 nodes configured 2 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Establece una demora para el reinicio de Corosync
En ambos hosts como raíz, crea un archivo directo
systemd
que retrase el inicio de Corosync para garantizar la secuencia adecuada de eventos después de reiniciar una VM protegida:systemctl edit corosync.service
Agrega las siguientes líneas al archivo:
[Service] ExecStartPre=/bin/sleep 60
Guarda el archivo y sal del editor.
Vuelve a cargar la configuración del administrador del sistema.
systemctl daemon-reload
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
Habilita los hooks del proveedor de HA/DR de SAP HANA
Red Hat 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.
En el sitio principal y secundario, completa los siguientes pasos:
Como
SID_LCadm
, detén SAP HANA:>
HDB stop
Como raíz o
SID_LCadm
, abre el archivoglobal.ini
para editarlo:>
vi /hana/shared/SID/global/hdb/custom/config/global.iniAgrega las siguientes definiciones al archivo
global.ini
:[ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR/srHook execution_order = 1 [trace] ha_dr_saphanasr = info
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 usuarioSID_LCadm
acceda a los atributos del nodo del clúster cuando se llama al método de hooksrConnectionChanged()
.>
sudo visudo -f /etc/sudoers.d/20-saphanaEn el archivo
/etc/sudoers.d/20-saphana
, agrega el siguiente texto:Reemplaza lo siguiente:
SITE_A
: Es el nombre del sitio del servidor principal de SAP HANA.SITE_B
: Es el nombre del sitio del servidor secundario de SAP HANASID_LC
: El SID se debe especificar en letras minúsculas.
crm_mon -A1 | grep site
, como usuario raíz, en el servidor principal de SAP HANA o en el servidor secundario.Cmnd_Alias SITEA_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SITEA_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias SITEB_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SITEB_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR SID_LCadm ALL=(ALL) NOPASSWD: SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL Defaults!SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL !requiretty
En el archivo
/etc/sudoers
, asegúrate de que se incluya el siguiente texto.#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.Como
SID_LCadm
, inicia SAP HANA:>
HDB startEn el host principal como
SID_LCadm
, prueba el estado que informó la secuencia de comandos del hook:>
cdtrace>
awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
Establece la configuración predeterminada del clúster
Configura los límites de migración y permanencia para determinar la cantidad de veces que se debe intentar la conmutación por error antes de fallar y a fin de configurar el sistema con el fin de que se reinicie primero en el host actual. Esto solo se debe configurar en un nodo para aplicarlo al clúster.
Como raíz en cualquiera de los hosts, inicia el clúster:
#
pcs cluster start --all #start the clusterEstablece los valores predeterminados del recurso:
#
pcs resource defaults resource-stickiness=1000#
pcs resource defaults migration-threshold=5000La propiedad
resource-stickiness
controla la probabilidad de que un servicio continúe ejecutándose donde está. Los valores más altos proporcionan mayor permanencia del servicio. Un valor de1000
significa que el servicio es muy persistente.La propiedad
migration-threshold
especifica la cantidad de fallas que deben ocurrir antes de que un servicio se transfiera a otro host. Un valor de 5,000 es lo bastante alto como para evitar la conmutación por error en situaciones de error de corta duración.Para verificar los valores predeterminados del recurso, ingresa
pcs resource defaults
.Establece los valores predeterminados del tiempo de espera de la operación del recurso:
#
pcs resource op defaults timeout=600sPara verificar los valores predeterminados de la operación del recurso, ingresa
pcs resource op defaults
.Establece las siguientes propiedades del clúster:
#
pcs property set stonith-enabled="true"#
pcs property set stonith-timeout="300s"Puedes verificar la configuración de la propiedad con
pcs property list
.
Crea el recurso SAPHanaTopology
El recurso SAPHanaTopology
obtiene el estado y la configuración de la replicación del sistema HANA en los nodos. También verifica SAP Host Agent.
Como raíz en cualquiera de los hosts, crea el recurso
SAPHanaTopology
:#
pcs resource create topology_resource_name SAPHanaTopology SID=SID \ InstanceNumber=inst_num \ op start timeout=600 \ op stop timeout=300 \ op monitor interval=10 timeout=600 \ clone clone-max=2 clone-node-max=1 interleave=trueDespués de crear el recurso, verifica la configuración. Agrega
-clone
al nombre del recurso para incluir la información del conjunto de clones en la respuesta:RHEL 8 y versiones posteriores
#
pcs resource config topology_resource_name-cloneRHEL 7
#
pcs resource show topology_resource_name-cloneDebería ver un resultado similar al siguiente:
Clone: SAPHanaTopology_HA1_22-clone Meta Attrs: clone-max=2 clone-node-max=1 interleave=true Resource: SAPHanaTopology_HA1_22 (class=ocf provider=heartbeat type=SAPHanaTopology) Attributes: InstanceNumber=22 SID=HA1 Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_22-methods-interval-0s) monitor interval=10 timeout=600 (SAPHanaTopology_HA1_22-monitor-interval-10) reload interval=0s timeout=5 (SAPHanaTopology_HA1_22-reload-interval-0s) start interval=0s timeout=600 (SAPHanaTopology_HA1_22-start-interval-0s) stop interval=0s timeout=300 (SAPHanaTopology_HA1_22-stop-interval-0s)
También puedes verificar los atributos del clúster mediante el comando crm_mon -A1
.
Crea el recurso SAPHana
El agente de recursos de SAPHana administra las bases de datos configuradas para la replicación del sistema SAP HANA.
Los siguientes parámetros en la definición de recursos de SAPHana son opcionales:
AUTOMATED_REGISTER
: Cuando se configura comotrue
, registra de forma automática la principal anterior como secundaria cuando vence el DUPLICATE_PRIMARY_TIMEOUT después de una apropiación. El valor predeterminado esfalse
.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
comofalse
. 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 establecerAUTOMATED_REGISTER
comotrue
para las configuraciones de SAP HANA que usan la replicación de sistemas de varios niveles.DUPLICATE_PRIMARY_TIMEOUT
: Establece la diferencia de tiempo en segundos entre dos marcas de tiempo principales si se produce una situación de principales duplicadas. El valor predeterminado7200
.PREFER_SITE_TAKEOVER
: Determina si los reinicios locales se prueban antes de iniciar la conmutación por error. El predeterminado esfalse
.
Para obtener información adicional sobre estos parámetros, consulta Installing and Configuring a Red Hat Enterprise Linux 7.6 (and later) High-Availability Cluster on Google Cloud [Instala y configura un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Cloud]. Se requiere una suscripción a Red Hat.
Como raíz en cualquiera de los hosts, crea el recurso SAP HANA:
RHEL 8 y versiones posteriores
#
pcs resource create sap_hana_resource_name SAPHana SID=SID \ InstanceNumber=inst_num \ PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \ op start timeout=3600 \ op stop timeout=3600 \ op monitor interval=61 role="Slave" timeout=700 \ op monitor interval=59 role="Master" timeout=700 \ op promote timeout=3600 \ op demote timeout=3600 \ promotable meta notify=true clone-max=2 clone-node-max=1 interleave=trueRHEL 7
#
pcs resource create sap_hana_resource_name SAPHana SID=SID \ InstanceNumber=inst_num \ PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \ op start timeout=3600 \ op stop timeout=3600 \ op monitor interval=61 role="Slave" timeout=700 \ op monitor interval=59 role="Master" timeout=700 \ op promote timeout=3600 \ op demote timeout=3600 \ master meta notify=true clone-max=2 clone-node-max=1 interleave=trueVerifica los atributos de los recursos resultantes:
RHEL 8 y versiones posteriores
#
pcs resource config sap_hana_resource_nameRHEL 7
#
pcs resource show sap_hana_resource_nameDeberías ver un resultado similar al siguiente:
Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana) Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1 Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s) methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s) monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61) monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59) promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s) reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s) start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s) stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)
Después de iniciar el recurso, verifica los atributos del nodo para ver el estado actual de las bases de datos de SAP HANA en los nodos:
#
crm_mon -A1Deberías ver un resultado similar al siguiente:
Stack: corosync Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum Last updated: Tue Jun 16 20:07:51 2020 Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1 2 nodes configured 6 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Active resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Node Attributes: * Node hana-ha-vm-1: + hana_ha1_clone_state : PROMOTED + hana_ha1_op_mode : logreplay + hana_ha1_remoteHost : hana-ha-vm-2 + hana_ha1_roles : 4:P:master1:master:worker:master + hana_ha1_site : hana-ha-vm-1 + hana_ha1_srmode : syncmem + hana_ha1_sync_state : PRIM + hana_ha1_version : 1.00.122.27.1568902538 + hana_ha1_vhost : hana-ha-vm-1 + lpa_ha1_lpt : 1592338046 + master-SAPHana_HA1_22 : 150 * Node hana-ha-vm-2: + hana_ha1_clone_state : DEMOTED + hana_ha1_op_mode : logreplay + hana_ha1_remoteHost : hana-ha-vm-1 + hana_ha1_roles : 4:S:master1:master:worker:master + hana_ha1_site : hana-ha-vm-2 + hana_ha1_srmode : syncmem + hana_ha1_sync_state : SOK + hana_ha1_version : 1.00.122.27.1568902538 + hana_ha1_vhost : hana-ha-vm-2 + lpa_ha1_lpt : 30 + master-SAPHana_HA1_22 : 100
Crea un recurso de dirección IP virtual
Debes crear un recurso de clúster para la VIP. El recurso VIP está localizado para el sistema operativo principal y otros hosts no lo pueden enrutar. El balanceador de cargas enruta el tráfico que se envía a la VIP al host de backend según la verificación de estado.
Como raíz en cualquiera de los hosts, ejecuta el siguiente comando:
#
pcs resource create resource_name \
IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
op monitor interval=3600s timeout=60s
El valor vip-address
es la misma dirección IP que reservaste antes y que especificaste en la regla de reenvío para el frontend de tu balanceador de cargas. Cambia la interfaz de red según corresponda para tu configuración.
Crea las restricciones
Crea restricciones para definir qué servicios deben iniciarse primero y qué servicios deben ejecutarse juntos en el mismo host. Por ejemplo, la dirección IP debe estar en el mismo host que la instancia principal de HANA.
Define la restricción del orden de inicio:
RHEL 8 y versiones posteriores
#
pcs constraint order topology_resource_name-clone \ then sap_hana_resource_name-clone symmetrical=falseRHEL 7
#
pcs constraint order topology_resource_name-clone \ then sap_hana_resource_name-master symmetrical=falseLa especificación de
symmetrical=false
significa que la restricción se aplica solo al inicio y no al apagado.Sin embargo, debido a que configuraste
interleave=true
para estos recursos en un paso anterior, los procesos pueden comenzar en paralelo. En otras palabras, puedes iniciar SAPHana en cualquier nodo tan pronto como se ejecute SAPHanaTopology.Comprueba las restricciones:
#
pcs constraintDebería ver un resultado similar al siguiente:
Location Constraints: Resource: STONITH-hana-ha-vm-1 Disabled on: Node: hana-ha-vm-1 (score:-INFINITY) Resource: STONITH-hana-ha-vm-2 Disabled on: Node: hana-ha-vm-2 (score:-INFINITY) Ordering Constraints: start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical) Colocation Constraints: Ticket Constraints:
Instala objetos de escucha y crea un recurso de verificación de estado
Para configurar un recurso de verificación de estado, primero debes instalar los objetos de escucha.
Instala un objeto de escucha
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. 1. Como raíz en la instancia principal en los sistemas principal y secundario, instala un objeto de escucha de TCP. En estas instrucciones, se instala y usa HAProxy como objeto de escucha.
#
yum install haproxy
Abre el archivo de configuración
haproxy.cfg
para editarlo:#
vi /etc/haproxy/haproxy.cfgEn la sección valores predeterminados de
haproxy.cfg
, cambiamode
atcp
.Después de la sección valores predeterminados, agrega lo siguiente para crear una sección nueva:
#--------------------------------------------------------------------- # Health check listener port for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:healthcheck-port-num
El puerto de vinculación es el mismo que usaste cuando creaste la verificación de estado.
Cuando termines, tus actualizaciones deberían ser similares al siguiente ejemplo:
#--------------------------------------------------------------------- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode tcp log global option tcplog option dontlognull option http-server-close # option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 #--------------------------------------------------------------------- # Set up health check listener for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:60000
En cada host como raíz, inicia el servicio para confirmar que esté configurado de forma correcta:
#
systemctl start haproxy.serviceEn la página del balanceador de cargas en la consola de Google Cloud, haz clic en la entrada del balanceador de cargas:
En la sección Backend de la página Detalles del balanceador de cargas, si el servicio HAProxy está activo en ambos hosts, verás
1/1
en la columna En buen estado (Healthy) de cada entrada del grupo de instancias.En cada host, detén el servicio HAProxy:
#
systemctl stop haproxy.serviceDespués de detener el servicio HAProxy en cada host, se muestra
0/1
en la columna En buen estado (Healthy) de cada grupo de instancias.Más tarde, cuando se configura la verificación de estado, el clúster reinicia el objeto de escucha en el nodo principal.
Crea el recurso de verificación de estado
En cualquier host como raíz, crea un recurso de verificación de estado para el servicio HAProxy:
#
pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20sConfirma que el servicio de verificación de estado esté activo en el mismo host que tu instancia principal de SAP HANA y el recurso VIP:
#
pcs statusSi el recurso de verificación de estado no está en el host principal, muévelo con el siguiente comando:
#
pcs resource move healthcheck_resource_name target_host_name#
pcs resource clear healthcheck_resource_nameEl comando
pcs resource clear
deja el recurso en su ubicación nueva, pero quita la restricción de ubicación no deseada que creó el comandopcs resource move
.En el estado, la sección de recursos debería ser similar al siguiente ejemplo:
Full list of resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1 rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-2
Agrupa los recursos de la VIP y la verificación de estado:
#
pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_nameEn el estado del clúster, la sección de recursos debería ser similar al siguiente ejemplo:
Full list of resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Resource Group: g-primary rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-1 rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1
Crea una restricción que ubica el grupo nuevo en el mismo nodo que la instancia principal de SAP HANA.
RHEL 8 y versiones posteriores
#
pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-clone 4000RHEL 7
#
pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000Las restricciones finales deberían ser similares al siguiente ejemplo:
# pcs constraint Location Constraints: Resource: STONITH-hana-ha-vm-1 Disabled on: Node: hana-ha-vm-1 (score:-INFINITY) Resource: STONITH-hana-ha-vm-2 Disabled on: Node: hana-ha-vm-2 (score:-INFINITY) Ordering Constraints: start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical) Colocation Constraints: g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master) Ticket Constraints:
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
para instancias con una sola interfaz de rediptables ... DROP
para instancias con varias interfaces de redecho c > /proc/sysrq-trigger
En estas instrucciones, se usa ip link set eth0 down
o iptables
para
simular una interrupción de red entre los dos hosts en el clúster. Usa el comando ip link
en una instancia con una sola interfaz de red y el comando iptables
en instancias con una o más interfaces de red. La prueba valida
tanto la conmutación por error como la protección. En el caso de que tus instancias tengan varias interfaces
de red definidas, usa el comando iptables
en el host
secundario para descartar el tráfico entrante y saliente en función de la IP que usa el host
principal para la comunicación del clúster, lo que simula una pérdida de conexión de red a la
instancia principal.
En el host activo, como raíz, desconecta la interfaz de red:
#
ip link set eth0 downO bien, si varias interfaces de red están activas, usa
iptables
en el host secundario:#
iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROPVuelve a conectarte a cualquier host a través de SSH y cambia al usuario raíz.
Ingresa
pcs status
para confirmar que el host principal ahora está activo en la VM que contenía el host secundario. El reinicio automático está habilitado en el clúster, por lo que el host detenido se reiniciará y asumirá la función de host secundario, como se muestra en el siguiente ejemplo.Cluster name: hana-ha-cluster Stack: corosync Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum Last updated: Wed Jun 17 01:04:36 2020 Last change: Wed Jun 17 01:03:58 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 ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-2 ] Slaves: [ hana-ha-vm-1 ] Resource Group: g-primary rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-2 rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Configurar HANA activo/activo (lectura habilitada)
A partir de SAP HANA 2.0 SPS1, puedes configurar HANA Active/Active (Read Enabled) en un clúster de Pacemaker. Esto es opcional.
Para configurar HANA activo/activo (lectura habilitada) en un clúster de Pacemaker, completa los siguientes pasos.
Configura la compatibilidad con la conmutación por error de Cloud Load Balancing para el host secundario
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 secundario en un clúster de SAP HANA basado en un servicio de verificación de estado.
Para configurar la asistencia de conmutación por error del host secundario, sigue estos pasos:
Abre Cloud Shell:
Reserva una dirección IP para la IP virtual mediante la ejecución del siguiente comando.
La dirección IP virtual (VIP) sigue el sistema SAP HANA secundario. Esta es la dirección IP que usan las aplicaciones para acceder a tu sistema SAP HANA secundario. El balanceador de cargas enruta el tráfico que se envía a la VIP hacia la instancia de VM que aloja el sistema secundario en la actualidad.
Si omites la marca
--addresses
en el siguiente comando, se elige una dirección IP en la subred especificada. Para obtener más información sobre cómo reservar una IP estática, consulta Reserva una dirección IP interna estática.$
gcloud compute addresses create secondary-vip-name \ --region cluster-region --subnet cluster-subnet \ --addresses secondary-vip-addressCrea una verificación de estado de Compute Engine mediante la ejecución del siguiente comando.
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. El puerto debe ser diferente del que se configuró para la verificación de estado que se usa en el acceso del sistema principal de HANA. 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 secondary-health-check-name \ --port=secondary-healthcheck-port-num \ --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Configura el balanceador de cargas y el grupo de conmutación por error mediante la ejecución de los siguientes comandos.
Aquí crearás un servicio de backend adicional y usarás los mismos grupos de instancias que creaste antes para el servicio de backend detrás del balanceador de cargas TCP/UDP interno para tu sistema principal de SAP HANA.
Crea el servicio de backend del balanceador de cargas:
$
gcloud compute backend-services create secondary-backend-service-name \ --load-balancing-scheme internal \ --health-checks secondary-health-check-name \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region cluster-region \ --global-health-checksAgrega el grupo de instancias principal al servicio de backend:
$
gcloud compute backend-services add-backend secondary-backend-service-name \ --instance-group primary-ig-name \ --instance-group-zone primary-zone \ --region cluster-regionAgrega el grupo de instancias de conmutación por error secundario al servicio de backend:
$
gcloud compute backend-services add-backend secondary-backend-service-name \ --instance-group secondary-ig-name \ --instance-group-zone secondary-zone \ --failover \ --region cluster-regionCree 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 secundario de HANA fuera de la región que especificas en el siguiente comando, incluye la marca
--allow-global-access
en la definición de la regla de reenvío.$
gcloud compute forwarding-rules create secondary-rule-name \ --load-balancing-scheme internal \ --address secondary-vip-name \ --subnet cluster-subnet \ --region cluster-region \ --backend-service secondary-backend-service-name \ --ports ALLPara 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.
Habilitar HANA activo/activo (lectura habilitada)
En tu host secundario, habilita Activa/Activa (lectura habilitada) para la replicación del sistema SAP HANA mediante los siguientes pasos:
Como raíz, coloca el clúster en modo de mantenimiento:
$
pcs property set maintenance-mode=trueComo
SID_LCadm
, detén SAP HANA:>
HDB stopComo
SID_LCadm
, vuelve a registrar el sistema secundario de HANA con la replicación del sistema SAP HANA mediante el modo de operaciónlogreplay_readaccess
:>
hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \ --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-nameComo
SID_LCadm
, inicia SAP HANA:>
HDB startComo
SID_LCadm
, confirma que el estado de sincronización de HANA seaACTIVE
:>
cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_statusDeberías ver un resultado similar al siguiente:
overall_replication_status=ACTIVE
Configura Pacemaker
Configura tu clúster de HA de Pacemaker para activo/activo (lectura habilitada) mediante la ejecución de los siguientes comandos como raíz:
Configura los objetos de escucha para las verificaciones de estado:
Copia y cambia el nombre del archivo de configuración
haproxy.service
predeterminado a fin de que sea un archivo de plantilla para las varias instancias de haproxy:# cp /usr/lib/systemd/system/haproxy.service \ /etc/systemd/system/haproxy@.service
Edita el[Unidad] y[Servicio] secciones de lahaproxy@.service que incluya el%i Parámetro de instancia, como se muestra en el siguiente ejemplo:
RHEL 7
[Unit] Description=HAProxy Load Balancer %i After=network-online.target
[Service] EnvironmentFile=/etc/sysconfig/haproxy ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-%i.cfg -p /run/haproxy-%i.pid $OPTIONS ...
RHEL 8
[Unit] Description=HAProxy Load Balancer %i After=network-online.target Wants=network-online.target
[Service] Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid" ...
Para obtener más información de Red Hat sobre las plantillas de unidades
systemd
, consulta Trabaja con unidades con instancias.Crea un archivo de configuración
haproxy.cfg
para tu sistema principal de SAP HANA. Por ejemplo:#
vi /etc/haproxy/haproxy-primary.cfgEn el archivo de configuración
haproxy-primary.cfg
para tu sistema principal de SAP HANA, inserta la siguiente configuración y reemplazahealthcheck-port-num
por el número de puerto que especificaste cuando creaste la instancia de Compute Engine. La verificación de estado del sistema principal de HANA anterior:global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:healthcheck-port-num
Crea un archivo de configuración
haproxy.cfg
para el sistema secundario de SAP HANA. Por ejemplo:#
vi /etc/haproxy/haproxy-secondary.cfgEn el archivo de configuración
haproxy-secondary.cfg
para tu sistema secundario de SAP HANA, inserta la siguiente configuración y reemplazasecondary-healthcheck-port-num
por el número de puerto que especificaste cuando creaste la instancia de Compute Engine. Una verificación de estado anterior del sistema secundario de HANA:global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:secondary-healthcheck-port-num
Quita la configuración del objeto de escucha existente de
/etc/haproxy/haproxy.cfg
:#--------------------------------------------------------------------- # Health check listener port for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:healthcheck-port-num
Vuelve a cargar los servicios de
systemd
para cargar los cambios:#
systemctl daemon-reloadConfirma que los dos servicios de haproxy estén configurados de forma correcta:
#
systemctl start haproxy@primary#
systemctl start haproxy@secondary#
systemctl status haproxy@primary#
systemctl status haproxy@secondaryEl estado que se muestra debe mostrar
haproxy@primary.service
yhaproxy@secondary.service
comoactive (running)
. El siguiente es un resultado de ejemplo parahaproxy@primary.service
:● haproxy@primary.service - Cluster Controlled haproxy@primary Loaded: loaded (/etc/systemd/system/haproxy@.service; disabled; vendor preset: disabled) Drop-In: /run/systemd/system/haproxy@primary.service.d └─50-pacemaker.conf Active: active (running) since Fri 2022-10-07 23:36:09 UTC; 1h 13min ago Main PID: 21064 (haproxy-systemd) CGroup: /system.slice/system-haproxy.slice/haproxy@primary.service ├─21064 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-primary.cfg -p /run/hapro... ├─21066 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -... └─21067 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -... Oct 07 23:36:09 hana-ha-vm-1 systemd[1]: Started Cluster Controlled haproxy@primary.
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 en los servicios de backend principal y secundario:
$
gcloud compute backend-services get-health backend-service-name \ --region cluster-region$
gcloud compute backend-services get-health secondary-backend-service-name \ --region cluster-regionDeberías ver un resultado similar al siguiente que muestra la VM en la que estás trabajando en este momento, el
healthState
esHEALTHY
:--- 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
Detén ambos servicios para permitir que Pacemaker administre los servicios:
#
systemctl stop haproxy@primary#
systemctl stop haproxy@secondaryRepite los pasos anteriores en cada host del clúster.
Crea un recurso de IP de clúster local para la dirección VIP que reservaste para el sistema secundario:
#
pcs resource create secondary_vip_resource_name \ IPaddr2 ip="secondary-vip-address" nic=eth0 cidr_netmask=32 \ op monitor interval=3600s timeout=60sPara configurar el servicio de verificación de estado auxiliar, ejecuta los siguientes comandos.
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:
Borra el recurso del servicio de verificación de estado para el sistema principal de HANA:
#
pcs resource delete healthcheck_resource_name --forceAgrega un recurso nuevo para el servicio de verificación de estado del sistema principal de HANA:
#
pcs resource create primary_healthcheck_resource_name \ service:haproxy@primary op monitor interval=10s timeout=20sAgrega un recurso nuevo para el servicio de verificación de estado del sistema secundario de HANA:
#
pcs resource create secondary_healthcheck_resource_name \ service:haproxy@secondary op monitor interval=10s timeout=20s
Agrupa los recursos VIP y auxiliares del servicio de verificación de estado
Agrega el nuevo recurso de verificación de estado al grupo de recursos existente para los recursos VIP principales:
#
pcs resource group add rsc-group-name primary_healthcheck_resource_name \ --before vip_resource_nameAgrega un grupo de recursos nuevo a fin de agrupar los recursos de servicio de verificación de estado VIP y auxiliar para el sistema secundario de HANA:
#
pcs resource group add secondary-rsc-group-name \ secondary_healthcheck_resource_name secondary_vip_resource_name
Ejecuta los siguientes comandos para crear dos restricciones de ubicación:
Estas restricciones garantizan que el grupo de recursos VIP secundarios se coloque en el nodo correcto del clúster:
#
pcs constraint location secondary-rsc-group-name rule score=INFINITY \ hana_sid_sync_state eq SOK and hana_sid_roles eq 4:S:master1:master:worker:master#
pcs constraint location secondary-rsc-group-name rule score=2000 \ hana_sid_sync_state eq PRIM and hana_sid_roles eq 4:P:master1:master:worker:masterSal del modo de mantenimiento del clúster:
#
pcs property set maintenance-mode=falseVerifica el estado del clúster:
#
pcs statusEn los siguientes ejemplos, se muestra el estado de un clúster activo y configurado correctamente para la replicación del sistema SAP HANA con activo/activo (lectura habilitada). Deberías ver un grupo de recursos adicional para los recursos VIP del sistema secundario. En el siguiente ejemplo, el nombre de ese grupo de recursos es
g-secondary
.Cluster name: hacluster Stack: corosync Current DC: hana-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Sat Oct 8 00:37:08 2022 Last change: Sat Oct 8 00:36:57 2022 by root via crm_attribute on hana-test-2 2 nodes configured 10 resource instances configured Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Resource Group: g-primary rsc_healthcheck_HA1-primary (service:haproxy@primary): Started hana-ha-vm-1 rsc_vip_HA1_00 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_00-master [SAPHana_HA1_00] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable): Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Resource Group: g-secondary rsc_healthcheck_HA1-secondary (service:haproxy@secondary): Started hana-ha-vm-2 rsc_vip_HA1_00-secondary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2
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 configuraciones de alta disponibilidad para SAP HANA en RHEL, consulta Solución de problemas de configuraciones de alta disponibilidad para SAP.
Obtén asistencia para SAP HANA en RHEL
Si necesitas ayuda para resolver un problema con los clústeres con alta disponibilidad para SAP HANA en RHEL, 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:
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.
Antes de usar la instancia de SAP HANA, configura la base de datos de SAP HANA nueva y crea una copia de seguridad.
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 como1048576
. 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:
- Installing and Configuring a Red Hat Enterprise Linux 7.6 (and later) High-Availability Cluster on Google Compute Cloud [Instala y configura un clúster de alta disponibilidad de Red Hat Enterprise Linux 7.6 (y versiones posteriores) en Google Compute Cloud]
- 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)
- Support Policies for RHEL High Availability Clusters - General Requirements for Fencing/STONITH (Políticas de compatibilidad para clústeres de alta disponibilidad de RHEL: Requisitos generales para protección/STONITH)
- 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.