En esta guía, se muestra cómo implementar y configurar un clúster de alta disponibilidad (HA) optimizado para mejorar el rendimiento de Red Hat Enterprise Linux (RHEL) para el sistema SAP NetWeaver.
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 a fin de configurar el sistema SAP NetWeaver para HA, pero consulta la documentación de SAP a fin de obtener las instrucciones definitivas.
Si deseas obtener información sobre la implementación de VM de Compute Engine para SAP NetWeaver que no es específica de la alta disponibilidad, consulta la guía de implementación de SAP NetWeaver que es específica de tu sistema operativo.
Si deseas configurar un clúster de alta disponibilidad para SAP NetWeaver en SUSE Linux Enterprise Server (SLES), consulta la guía de configuración manual de clústeres de alta disponibilidad para SAP NetWeaver en SLES.
Esta guía está destinada a usuarios avanzados de SAP NetWeaver que estén familiarizados con la configuración de alta disponibilidad de Linux para SAP NetWeaver.
El sistema que se implementa en esta guía
Si sigues las instrucciones de esta guía, implementarás dos instancias de SAP NetWeaver y configurarás un clúster de alta disponibilidad en RHEL. Implementarás cada instancia de SAP NetWeaver en una VM de Compute Engine en una zona diferente dentro de la misma región. En esta guía, no se aborda la instalación de alta disponibilidad de la base de datos subyacente.
El clúster implementado incluye las siguientes funciones y características:
- Dos VM de host, una para la instancia activa de ASCS y otra para la instancia activa de ENSA2 Enqueue Replicator o ENSA1 Enqueue Replication Server (ENSA1). Las instancias de ENSA2 y ENSA1 se denominan ERS.
- El administrador de recursos del clúster de alta disponibilidad de Pacemaker
- Un mecanismo de defensa STONITH
- Reinicio automático de la instancia con errores como la instancia secundaria nueva
Si deseas usar Terraform para automatizar la implementación de un sistema SAP NetWeaver de HA, consulta Terraform: Guía de configuración de clústeres de HA para SAP NetWeaver en RHEL.
Requisitos previos
Antes de crear el clúster de alta disponibilidad de SAP NetWeaver, asegúrate de que se cumplan los siguientes requisitos:
- Leíste la Guía de planificación de SAP NetWeaver y la Guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud.
- Tú o tu organización deben tener una cuenta de Google Cloud y haber creado un proyecto para la implementación de SAP NetWeaver. Si deseas obtener información sobre cómo crear cuentas y proyectos de Google Cloud, consulta Crea un proyecto en la Guía de implementación de SAP NetWeaver para Linux.
- Si necesitas que tu carga de trabajo de SAP se ejecute de acuerdo con los requisitos de residencia de datos, control de acceso, personal de asistencia o reglamentario, debes crear la carpeta de cargas de trabajo de Assured Workloads requerida. A fin de obtener más información, consulta Cumplimiento y controles soberanos para SAP en Google Cloud.
Si usas un DNS interno de VPC, entonces el valor de la variable
vmDnsSetting
en los metadatos del proyecto debe 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:Configuraste un recurso compartido de archivos con una solución de almacenamiento de archivos compartidos de NFS, como Filestore Enterprise.
Si el Acceso al SO está habilitado en los metadatos del proyecto, debes inhabilitar el Acceso al SO de forma temporal hasta que se complete la implementación. Para fines de implementación, este procedimiento configura las claves SSH en metadatos de instancia. Cuando el acceso al SO está habilitado, la configuración de las claves SSH basada en metadatos se inhabilita y esta implementación falla. Una vez terminada la implementación, puedes volver a habilitar el acceso al SO.
Para obtener más información, consulte:
Información relacionada de RHEL
Excepto cuando sea necesario para el entorno de Google Cloud, la información de esta guía es coherente con las siguientes guías relacionadas de Red Hat y SAP:
- Configura SAP NetWeaver ASCS/ERS ENSA1 con Standalone Resources en RHEL 7.5+ y RHEL 8
- Configura SAP S/4HANA ASCS/ERS con Standalone Enqueue Server 2 (ENSA2) en Pacemaker
- Nota de SAP 2002167 - Red Hat Enterprise Linux 7.x: Instalación y actualización
- Nota de SAP 2772999 - Red Hat Enterprise Linux 8.x: Instalación y configuración
- Nota de SAP 3108316 - Red Hat Enterprise Linux 9.x: Instalación y configuración
- Nota de SAP 2641322: Instalación de ENSA2 y actualización de ENSA1 a ENSA2 cuando se usan las soluciones de alta disponibilidad de Red Hat para SAP
Crea una red
Por razones de seguridad, crea una red nueva. Puedes controlar quién tiene acceso con reglas de firewall o a través de otro método de control de acceso.
Si tu proyecto tiene una red de VPC predeterminada, no la uses. En su lugar, crea tu propia red de VPC para que las únicas reglas de firewall vigentes sean aquellas que crees de forma explícita.
Durante la implementación, las instancias de VM suelen requerir acceso a Internet para descargar el agente de Google Cloud para SAP. Si usas una de las imágenes de Linux certificadas por SAP disponibles en Google Cloud, la instancia de VM también requerirá acceso a Internet para registrar la licencia y acceder a repositorios de proveedores de SO. Una configuración con una puerta de enlace NAT y con rótulos identificadores de red de VM admite este acceso, incluso si las VM de destino no tienen IP externas.
Para 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, las conexiones entrantes que no pertenecen a tu red de Google Cloud se bloquean. A fin de permitir conexiones entrantes, establece una regla de firewall para tu VM. Las reglas de firewall solo regulan las conexiones entrantes nuevas a una VM. Después de establecer una conexión con una VM, se permite el tráfico en ambas direcciones a través de esa conexión.
Puedes crear una regla de firewall a fin de permitir el acceso a puertos específicos o para permitir el acceso entre las VM de la misma subred.
Tendrás que crear reglas de firewall que permitan el acceso, por ejemplo, para lo siguiente:
- Los puertos predeterminados que utiliza SAP NetWeaver, como se documenta en Puertos TCP/IP de todos los productos SAP
- Conexiones desde tu computadora o tu entorno de red empresarial a tu instancia de VM de Compute Engine; Si no estás seguro de qué dirección IP usar, comunícate con el administrador de red de tu empresa
- Comunicación entre las VM en una configuración de alta disponibilidad, de escalamiento horizontal o de 3 niveles. Por ejemplo, si estás implementando un sistema de 3 niveles, tendrás al menos 2 VM en tu subred: la VM de SAP NetWeaver y otra VM para el servidor de base de datos. Para habilitar la comunicación entre las dos VM, debes crear una regla de firewall que permita el tráfico proveniente de la subred
- Verificaciones de estado de Cloud Load Balancing. Si deseas obtener más información, consulta Crea una regla de firewall para las verificaciones de estado.
Para crear una regla de firewall, sigue estos pasos:
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 en la que se ubica tu VM.
- En el campo Objetivos, selecciona Todas las instancias de la red.
- 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 especifica
tcp:PORT_NUMBER;
.
Haz clic en Crear para crear tu regla de firewall.
Implementa las VM para SAP NetWeaver
Antes de comenzar a configurar el clúster de HA, debes definir y, luego, implementar las instancias de VM que funcionarán como los nodos principales y secundarios en tu clúster de HA.
A fin de definir e implementar las VM, usa la misma plantilla de Cloud Deployment Manager que usas a fin de implementar una VM para un sistema SAP NetWeaver en la Implementación automatizada de VM para SAP NetWeaver en Linux.
Sin embargo, a fin de implementar dos VM en lugar de una debes agregar la definición de la segunda VM al archivo de configuración. Para ello, copia y pega la definición de la primera VM. 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 las VM se implementen de forma correcta, debes instalar SAP NetWeaver, y 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.
Abra Cloud Shell.
Descarga la plantilla de archivo de configuración YAML,
template.yaml
, en el directorio de trabajo:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml
De manera opcional, cambia el nombre del archivo
template.yaml
para identificar la configuración que define. Por ejemplo,nw-ha-rhel-8-4.yaml
Para abrir el archivo de configuración YAML en el editor de código de Cloud Shell, haz clic en el ícono de lápiz (edit) en la esquina superior derecha de la ventana de la terminal de Cloud Shell.
Define la primera instancia de VM en la plantilla del archivo de configuración YAML. Debes definir la segunda instancia de VM en el paso posterior a la siguiente tabla.
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 ver un ejemplo de un archivo de configuración completo, consulta Ejemplo de un archivo de configuración YAML completo.
Propiedad Tipo de datos Descripción name
String Un nombre arbitrario que identifica el recurso de implementación que define el siguiente conjunto de propiedades. type
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 estás definiendo. Especifica nombres diferentes en las definiciones de la VM principal y la secundaria. Te recomendamos usar nombres que identifiquen las instancias como pertenecientes al mismo clúster de alta disponibilidad. Los nombres de las instancias deben tener 13 caracteres o menos y especificarse en letras minúsculas, números o guiones. Usa un nombre que sea único dentro de tu proyecto.
instanceType
String El tipo de VM de Compute Engine que necesitas. Especifica el mismo tipo de instancia para la VM principal y la secundaria. Si necesitas un tipo de VM personalizado, especifica un tipo de VM pequeño predefinido y, una vez finalizada la implementación, personaliza la VM según sea necesario.
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 la VM principal y secundaria. 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 la familia de imágenes que usas con SAP NetWeaver. Para especificar una familia de imágenes, agrega el prefijo family/
al nombre de la familia. Por ejemplo:family/rhel-8-4-sap-ha
. Si deseas ver la lista de las familias de imágenes 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 el proyecto de imagen de Google Cloud rhel-sap-cloud
. Para ver una lista de proyectos de imágenes de Google Cloud, consulta la página Imágenes en la documentación de Compute Engine.usrsapSize
Entero El tamaño del disco /usr/sap
. El tamaño mínimo es de 8 GB.sapmntSize
Entero El tamaño del disco /sapmnt
. El tamaño mínimo es de 8 GB.swapSize
Entero El tamaño del volumen de intercambio. El tamaño mínimo es de 1 GB. networkTag
String Opcional. Una o más etiquetas de red separadas por comas que representan tu instancia de VM para firewall o enrutamiento.
En las configuraciones de alta disponibilidad, especifica una etiqueta de red que se usará en una regla de firewall que permita la comunicación entre los nodos del clúster y una etiqueta de red que se usará en una regla de firewall que permita las verificaciones de estado de Cloud Load Balancing para acceder a los nodos del clúster
Si especificas
publicIP: No
y no especificas una etiqueta de red, asegúrate de proporcionar otro medio de acceso a Internet.serviceAccount
String Opcional. Especifica una cuenta de servicio personalizada que se usará para la VM implementada. La cuenta de servicio debe incluir los permisos necesarios durante la implementación para configurar la VM de SAP.
Si no se especifica
serviceAccount
, se usa la cuenta de servicio de Compute Engine predeterminada.Especifica la dirección completa de la cuenta de servicio. Por ejemplo,
sap-ha-example@example-project-123456.iam.gserviceaccount.com
publicIP
Booleano Opcional. Determina si se agrega una dirección IP pública a tu instancia de VM. El valor predeterminado es Yes
.sap_deployment_debug
Booleano Opcional. Si este valor se establece en Yes
, la implementación genera registros de implementación con verbosidad. No actives esta configuración, a menos que un ingeniero de Atención al cliente de Google te solicite que habilites la depuración.En el archivo de configuración YAML, crea la definición de la segunda VM. Para ello, copia la definición de la primera VM y pégala después de la primera definición. Para ver un ejemplo, consulta Ejemplo de un archivo de configuración YAML completo.
En la definición de la segunda VM, especifica valores diferentes para las siguientes propiedades que especificaste en la primera definición:
name
instanceName
zone
Crea las instancias de VM:
gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml
Donde:
DEPLOYMENT_NAME
representa el nombre de la implementación.TEMPLATE_NAME
representa el nombre del archivo de configuración YAML.
El comando anterior invoca a Deployment Manager, que implementa las VM de acuerdo con las especificaciones del archivo de configuración 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 YAML completo
En el siguiente ejemplo, se muestra un archivo de configuración YAML completo que implementa dos instancias de VM para una configuración de HA de SAP NetWeaver mediante la última versión de las plantillas de Deployment Manager. En el ejemplo, se omiten los comentarios que contiene la plantilla cuando la descargas por primera vez.
El archivo contiene las definiciones de dos recursos para implementar: sap_nw_node_1
y sap_nw_node_2
. Cada definición de recurso contiene las definiciones de una VM.
La definición del recurso sap_nw_node_2
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
y serviceAccount
pertenecen a la sección Opciones avanzadas de la plantilla del archivo de configuración.
resources: - name: sap_nw_node_1 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-1 instanceType: n2-standard-4 zone: us-central1-b subnetwork: example-sub-network-sap linuxImage: family/rhel-8-4-sap-ha linuxImageProject: rhel-sap-cloud usrsapSize: 15 sapmntSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com - name: sap_nw_node_2 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-2 instanceType: n2-standard-4 zone: us-central1-c subnetwork: example-sub-network-sap linuxImage: family/rhel-8-4-sap-ha linuxImageProject: rhel-sap-cloud usrsapSize: 15 sapmntSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
Crea reglas de firewall que permitan el acceso a las VM 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
- Las verificaciones de estado que usa Cloud Load Balancing, como se describe en el paso posterior, Crea una regla de firewall para las verificaciones de estado
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 VM
Antes de instalar SAP NetWeaver o comenzar a configurar el clúster de HA, verifica que las VM se hayan implementado de forma correcta mediante la verificación de los registros y la asignación de almacenamiento del SO.
Verifica los registros
En la consola de Google Cloud, abre Cloud Logging para supervisar el progreso de la instalación y verificar si hay errores.
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 NetWeaver que se enumeran en la Guía de planificación de SAP NetWeaver.
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
Después de que se implementan las instancias de VM, conéctate a las VM mediante
ssh
.- Si aún no lo hiciste, crea una regla de firewall para permitir una conexión SSH en el puerto
22
. Ve a la página Instancias de VM.
Conéctate a cada instancia de VM; para ello, haz clic en el botón SSH en la entrada de cada instancia de VM o usa tu método SSH preferido.
- Si aún no lo hiciste, crea una regla de firewall para permitir una conexión SSH en el puerto
Muestra el sistema de archivos:
~>
df -hVerifica que el resultado sea similar al siguiente:
Filesystem Size Used Avail Use% Mounted on devtmpfs 32G 8.0K 32G 1% /dev tmpfs 48G 0 48G 0% /dev/shm tmpfs 32G 402M 32G 2% /run tmpfs 32G 0 32G 0% /sys/fs/cgroup /dev/sda3 30G 3.4G 27G 12% / /dev/sda2 20M 3.7M 17M 19% /boot/efi /dev/mapper/vg_usrsap-vol 15G 48M 15G 1% /usr/sap /dev/mapper/vg_sapmnt-vol 15G 48M 15G 1% /sapmnt tmpfs 6.3G 0 6.3G 0% /run/user/1002 tmpfs 6.3G 0 6.3G 0% /run/user/0
Confirma que se creó el espacio de intercambio:
~>
cat /proc/meminfo | grep SwapDeberías ver resultados similares al siguiente ejemplo:
SwapCached: 0 kB SwapTotal: 25161724 kB SwapFree: 25161724 kB
Si alguno de los pasos de la validación muestra que la instalación falló, haz lo siguiente:
- Corrige el error.
- En la página Implementaciones, borra la implementación para limpiar las VM y los discos persistentes de la instalación con errores.
- Vuelve a ejecutar tu implementación.
Habilita la comunicación de backend del balanceador de cargas entre las VM
Después de confirmar que las VM se implementaron de forma correcta, habilita la comunicación de backend entre las VM que funcionarán como los nodos en tu clúster de HA.
Para habilitar la comunicación de backend entre las VM, modifica la configuración de google-guest-agent
, que se incluye en el entorno de invitado de Linux, para todas las imágenes públicas de Linux que proporciona Google Cloud.
Para habilitar las comunicaciones de backend del balanceador de cargas, realiza los siguientes pasos en cada VM que forma parte de tu clúster:
Detén el agente:
sudo service google-guest-agent stop
Abre o crea el archivo
/etc/default/instance_configs.cfg
para editarlo. Por ejemplo:sudo vi /etc/default/instance_configs.cfg
En el archivo
/etc/default/instance_configs.cfg
, especifica las propiedades de configuración que se muestran a continuación. Si las secciones no existen, créalas. En especial, asegúrate de que las propiedadestarget_instance_ips
yip_forwarding
estén configuradas comofalse
:[IpForwarding] ethernet_proto_id = 66 ip_aliases = true target_instance_ips = false [NetworkInterfaces] dhclient_script = /sbin/google-dhclient-script dhcp_command = ip_forwarding = false setup = true
Inicia el servicio del agente invitado:
sudo service google-guest-agent start
La configuración de verificación de estado del balanceador de cargas requiere un puerto de destino de escucha para la verificación de estado y una asignación de la IP virtual a una interfaz. Para obtener más información, consulta Prueba la configuración del balanceador de cargas.
Configura claves SSH en las VM principales y secundarias
Para permitir que se copien archivos entre los hosts del clúster de HA, los pasos de esta sección crean conexiones SSH raíz entre los dos hosts.
Las plantillas de Deployment Manager que proporciona Google Cloud generan una clave por ti, pero puedes reemplazarla por una clave que generes si es necesario.
Es probable que tu organización tenga lineamientos que rijan las comunicaciones de red 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 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 con un bucket de Cloud Storage. Consulta Cargas y descargas.
- Usa una solución de almacenamiento de archivos como Filestore o NetApp Cloud Volumes Service para crear una carpeta compartida. Consulta Soluciones de uso compartido de archivos.
Para habilitar las conexiones SSH entre la instancia principal y la secundaria, haz lo que se indica a continuación. En los pasos, se supone que usas la clave SSH que generan las plantillas de Deployment Manager para SAP.
En la VM host principal, sigue estos pasos:
Conéctate a la VM a través de SSH.
Cambiar a la raíz:
$
sudo su -Confirma que la clave SSH existe:
#
ls -l /root/.ssh/Deberías ver los archivos de claves id_rsa como en el siguiente ejemplo:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
Actualiza los metadatos de la VM principal con información sobre la clave SSH para la VM secundaria.
#
gcloud compute instances add-metadata SECONDARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone SECONDARY_VM_ZONEPara confirmar que las claves SSH estén configuradas de forma correcta, abre una conexión SSH desde el sistema principal al secundario:
#
ssh SECONDARY_VM_NAME
En la VM secundaria del host, sigue estos pasos:
Conéctate a la VM mediante SSH.
Cambiar a la raíz:
$
sudo su -Confirma que la clave SSH existe:
#
ls -l /root/.ssh/Deberías ver los archivos de claves id_rsa como en el siguiente ejemplo:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
Actualiza los metadatos de la VM secundaria con información sobre la clave SSH para la VM principal.
#
gcloud compute instances add-metadata PRIMARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone PRIMARY_VM_ZONE#
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysPara confirmar que las claves SSH estén configuradas correctamente, abre una conexión SSH desde el sistema secundario al principal.
#
ssh PRIMARY_VM_NAME
Configura el almacenamiento de archivos compartidos y los directorios compartidos
Debes configurar una solución de archivos compartidos NFS que proporcione almacenamiento de archivos compartidos con alta disponibilidad a los que ambos nodos del clúster con alta disponibilidad puedan acceder. Luego, crearás directorios en ambos nodos que se asignan al almacenamiento de archivos compartidos. El software del clúster garantiza que los directorios adecuados se activen solo en las instancias correctas.
En esta guía, no se aborda la configuración de una solución de uso compartido de archivos. A fin de obtener instrucciones para configurar el sistema de uso compartido de archivos, consulta las instrucciones que proporciona el proveedor de la solución que seleccionaste. Si eliges usar Filestore para tu solución de uso compartido de archivos, te recomendamos usar el nivel empresarial de Filestore. Para aprender a crear una instancia de Filestore, consulte Crear instancias.
Para obtener información sobre soluciones de uso compartido de archivos que están disponibles en Google Cloud, consulta Opciones de almacenamiento compartido para sistemas SAP de alta disponibilidad en Google Cloud.
Para configurar los directorios compartidos, sigue estos pasos:
Si aún no configuraste una solución de almacenamiento de archivos compartidos NFS con alta disponibilidad, hazlo ahora.
Activa el almacenamiento compartido de NFS en ambos servidores para la configuración inicial.
~>
sudo mkdir /mnt/nfs~>
sudo mount -t nfs NFS_PATH /mnt/nfsReemplaza
NFS_PATH
por la ruta a tu solución de archivos compartidos NFS. Por ejemplo,10.49.153.26:/nfs_share_nw_ha
Desde cualquiera de los servidores, crea directorios para
sapmnt
, el directorio central de transporte y el directorio específico de la instancia. Si usas una pila de Java, reemplaza “ASCS” por “SCS” antes de usar los siguientes y otros comandos de ejemplo:~>
sudo mkdir /mnt/nfs/sapmntSID~>
sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}Reemplaza lo siguiente:
SID
: El ID del sistema SAP (SID). Usa mayúsculas para las letras. Por ejemplo,AHA
.ASCS_INSTANCE_NUMBER
: el número de instancia del sistema ASCS. Por ejemplo,00
ERS_INSTANCE_NUMBER
: el número de instancia del sistema ERS. Por ejemplo,10
En ambos servidores, crea los puntos de activación necesarios:
~>
sudo mkdir -p /sapmnt/SID~>
sudo mkdir -p /usr/sap/trans~>
sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER~>
sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBERConfigura
autofs
para activar los directorios de archivos compartidos comunes cuando se accede a los directorios por primera vez. El software del clúster, que configuras en un paso posterior, administra la activación de los directoriosASCSASCS_INSTANCE_NUMBER
yERSERS_INSTANCE_NUMBER
.Ajusta las opciones de NFS en los comandos según sea necesario para la solución de uso compartido de archivos.
En ambos servidores, configura
autofs
:~>
echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master~>
NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"~>
echo "/sapmnt/SID ${NFS_OPTS} NFS_PATH/sapmntSID" | sudo tee -a /etc/auto.sap~>
echo "/usr/sap/trans ${NFS_OPTS} NFS_PATH/usrsaptrans" | sudo tee -a /etc/auto.sapPara obtener más información sobre
autofs
, consulta autofs: cómo funciona.En ambos servidores, inicia el servicio de
autofs
:~>
sudo systemctl enable autofs~>
sudo systemctl restart autofs~>
sudo automount -vPara activar
autofs
a fin de activar los directorios compartidos, accede a cada directorio con el comandocd
. Por ejemplo:~>
cd /sapmnt/SID~>
cd /usr/sap/transDespués de acceder a todos los directorios, ejecuta el comando
df -Th
para confirmar que los directorios están activados.~>
df -Th | grep FILE_SHARE_NAMEReemplaza
FILE_SHARE_NAME
por el nombre de tu solución de archivos compartidos NFS. Por ejemplo,nfs_share_nw_ha
Deberías ver puntos de activación y directorios similares a los siguientes:
10.49.153.26:/nfs_share_nw_ha nfs 1007G 76M 956G 1% /mnt/nfs 10.49.153.26:/nfs_share_nw_ha/usrsaptrans nfs 1007G 76M 956G 1% /usr/sap/trans 10.49.153.26:/nfs_share_nw_ha/sapmntAHA nfs 1007G 76M 956G 1% /sapmnt/AHA
Configura la compatibilidad con la conmutación por error de Cloud Load Balancing
El servicio de balanceador de cargas de red de transferencia interno compatible con la conmutación por error enruta el tráfico de ASCS y ERS a las instancias activas de cada uno en un clúster de SAP NetWeaver. El balanceador de cargas de red de transferencia interno usa direcciones IP virtuales (VIP), servicios de backend, grupos de instancias y verificaciones de estado para enrutar el tráfico de manera adecuada.
Reserva direcciones IP para las IP virtuales
Para un clúster de alta disponibilidad de SAP NetWeaver, creas dos VIP, que a veces se conocen como direcciones IP flotantes. Una VIP sigue la instancia activa de SAP Central Services (SCS) y la otra sigue la instancia de Enqueue Replication Server (ERS). El balanceador de cargas enruta el tráfico que se envía a cada VIP a la VM que aloja la instancia activa del componente ASCS o ERS de la VIP.
Abre Cloud Shell:
Reserva una dirección IP para la IP virtual del ASCS y la VIP del ERS. En el caso de ASCS, la dirección IP es la que usan las aplicaciones para acceder a SAP NetWeaver. En el caso de ERS, la dirección IP es la que se usa para la replicación del servidor de cola. Si omites la marca
--addresses
, se elige una dirección IP en la subred especificada:~
gcloud compute addresses create ASCS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ASCS_VIP_ADDRESS~
gcloud compute addresses create ERS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ERS_VIP_ADDRESSReemplaza lo siguiente:
ASCS_VIP_NAME
: Especifica un nombre para la dirección IP virtual de la instancia de ASCS. Por ejemplo,ascs-aha-vip
.CLUSTER_REGION
: Especifica la región de Google Cloud en la que se encuentra el clúster. Por ejemplo,us-central1
CLUSTER_SUBNET
: Especifica la subred que usas con tu clúster. Por ejemplo,example-sub-network-sap
.ASCS_VIP_ADDRESS
: De forma opcional, especifica una dirección IP para la IP virtual de ASCS en notación CIDR. Por ejemplo,10.1.0.2
.ERS_VIP_NAME
: Especifica un nombre para la dirección IP virtual de la instancia de ERS. Por ejemplo,ers-aha-vip
.ERS_VIP_ADDRESS
: De forma opcional, especifica una dirección IP para la IP virtual de ERS en notación CIDR. Por ejemplo,10.1.0.4
.
Para 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.1.0.2 addressType: INTERNAL creationTimestamp: '2022-04-04T15:04:25.872-07:00' description: '' id: '555067171183973766' kind: compute#address name: ascs-aha-vip 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/ascs-aha-vip status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap
Define los nombres de host de la dirección VIP en /etc/hosts
Define un nombre de host para cada dirección VIP y, luego, agrega las direcciones IP y los nombres de host de las VM y las VIP al archivo /etc/hosts
en cada VM.
Los nombres de host VIP no se conocen fuera de las VM, a menos que también los agregues a tu servicio DNS. Agregar estas entradas al archivo /etc/hosts
local protege tu clúster de las interrupciones del servicio de DNS.
Las actualizaciones del archivo /etc/hosts
deben ser similares al siguiente ejemplo:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2 10.1.0.2 ascs-aha-vip 10.1.0.4 ers-aha-vip 10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1 # Added by Google 169.254.169.254 metadata.google.internal # Added by Google
Crea las verificaciones de estado de Cloud Load Balancing
Crea verificaciones de estado: una para la instancia de ASCS activa y otra para el ERS activo.
En Cloud Shell, crea las verificaciones de estado. A fin de evitar conflictos con otros servicios, designa los números de puerto para las instancias de ASCS y ERS en el rango privado 49152-65535. Los valores de intervalo de verificación y tiempo de espera de los siguientes comandos 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 ASCS_HEALTH_CHECK_NAME \ --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \ --unhealthy-threshold=2 --healthy-threshold=2~
gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \ --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \ --unhealthy-threshold=2 --healthy-threshold=2
Confirma la creación de cada verificación de estado:
~
gcloud compute health-checks describe HEALTH_CHECK_NAMEDeberías ver un resultado similar al siguiente:
checkIntervalSec: 10 creationTimestamp: '2021-05-12T15:12:21.892-07:00' healthyThreshold: 2 id: '1981070199800065066' kind: compute#healthCheck name: ascs-aha-health-check-name selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name 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
Si aún no lo has hecho, 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 Cloud Load Balancing, 35.191.0.0/16
y 130.211.0.0/22
. Si deseas obtener más información sobre las reglas de firewall para los balanceadores de cargas, consulta Crea reglas de firewall para 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_VM_NAME \ --zone=PRIMARY_ZONE \ --tags NETWORK_TAGS~
gcloud compute instances add-tags SECONDARY_VM_NAME \ --zone=SECONDARY_ZONE \ --tags NETWORK_TAGS
Crea una regla de firewall que use la etiqueta de red 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:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUMPor ejemplo:
gcloud compute firewall-rules create nw-ha-cluster-health-checks \ --network=example-network \ --action=ALLOW \ --direction=INGRESS \ --source-ranges=35.191.0.0/16,130.211.0.0/22 \ --target-tags=allow-health-check \ --rules=tcp:60000,tcp:60010
Crea grupos de instancias de Compute Engine
Debes crear un grupo de instancias en cada zona que contenga una VM de nodo de clúster y agregar la VM en esa zona al grupo de instancias.
En Cloud Shell, crea el grupo de instancias principal y agrégale la VM principal:
~
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_VM_NAME
En Cloud Shell, crea el grupo de instancias secundario y agrégale la VM secundaria:
~
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_VM_NAME
Confirma 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 sap-aha-primary-instance-group us-central1-b example-network-sap example-project-123456 No 1 sap-aha-secondary-instance-group us-central1-c example-network-sap example-project-123456 No 1
Configura los servicios de backend
Crea dos servicios de backend, uno para ASCS y otro para ERS. Agrega ambos grupos de instancias a cada servicio de backend y designa el grupo opuesto como el grupo de instancias de conmutación por error en cada servicio de backend. Por último, crea reglas de reenvío desde las VIP hacia los servicios de backend.
En Cloud Shell, crea el servicio de backend y el grupo de conmutación por error para ASCS:
Crea el servicio de backend para ASCS:
~
gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ASCS_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 de ASCS:
~
gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONAgrega el grupo de instancias secundario como el grupo de instancias de conmutación por error para el servicio de backend de ASCS:
~
gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGION
En Cloud Shell, crea el servicio de backend y el grupo de conmutación por error para ERS:
Crea el servicio de backend para ERS:
~
gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ERS_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 secundario al servicio de backend de ERS:
~
gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --region CLUSTER_REGIONAgrega el grupo de instancias principal como el grupo de instancias de conmutación por error para el servicio de backend de ERS:
~
gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --failover \ --region CLUSTER_REGION
De manera opcional, confirma que los servicios de backend contengan los grupos de instancias como se espera:
~
gcloud compute backend-services describe BACKEND_SERVICE_NAME \ --region=CLUSTER_REGIONDeberías ver un resultado similar al siguiente ejemplo para el servicio de backend de ASCS. En el caso de ERS,
failover: true
aparecerá en el grupo de instancias principal:backends: - balancingMode: CONNECTION group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group - balancingMode: CONNECTION failover: true group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group connectionDraining: drainingTimeoutSec: 0 creationTimestamp: '2022-04-06T10:58:37.744-07:00' description: '' failoverPolicy: disableConnectionDrainOnFailover: true dropTrafficIfUnhealthy: true failoverRatio: 1.0 fingerprint: s4qMEAyhrV0= healthChecks: - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name id: '6695034709671438882' kind: compute#backendService loadBalancingScheme: INTERNAL name: ascs-aha-backend-service-name protocol: TCP 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/backendServices/ascs-aha-backend-service-name sessionAffinity: NONE timeoutSec: 30
En Cloud Shell, crea reglas de reenvío para los servicios de backend de ASCS y ERS:
Crea la regla de reenvío de ASCS VIP al servicio de backend de ASCS:
~
gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ASCS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ASCS_BACKEND_SERVICE_NAME \ --ports ALLCrea la regla de reenvío desde la VIP de ERS al servicio de backend de ERS:
~
gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ERS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ERS_BACKEND_SERVICE_NAME \ --ports ALL
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 un puerto de verificación de estado.
En ambas VM del host, instala la utilidad
socat
:$
sudo yum install socatEn la VM principal, asigna temporalmente la VIP a la tarjeta de red de eth0:
ip addr add VIP_ADDRESS dev eth0
En la VM principal, inicia un proceso
socat
para escuchar durante 60 segundos en el puerto de verificación de estado de ASCS:$
timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_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 de ASCS:
~
gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDeberías ver un resultado similar al siguiente ejemplo para ASCS:
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.90 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1 ipAddress: 10.1.0.89 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.90 healthState: UNHEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2 ipAddress: 10.1.0.88 port: 80 kind: compute#backendServiceGroupHealth
Quita la VIP de la interfaz de eth0:
ip addr del VIP_ADDRESS dev eth0
Repite los pasos de ERS y reemplaza los valores de variables de ASCS por los valores de ERS.
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:
En la consola de Google Cloud, ve a la página Verificaciones de estado de Compute Engine:
Haz clic en el nombre de la verificación de estado.
Haz clic en Edit.
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, 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-b/instanceGroups/sap-aha-primary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.85 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1 ipAddress: 10.1.0.79 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.85 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2 ipAddress: 10.1.0.78 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.
Instala objetos de escucha para las verificaciones de estado
Para configurar un recurso de verificación de estado, primero debes instalar los objetos 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.
En cada host del clúster, instala un objeto de escucha mediante los siguientes pasos:
Como raíz, instala un objeto de escucha de TCP simple. En estas instrucciones, se instala y usa HAProxy como objeto de escucha.
#
yum install haproxyCopia y cambia el nombre del archivo de configuración
haproxy.cfg
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@.serviceEdita las secciones
[Unit]
y[Service]
del archivohaproxy@.service
para incluir el parámetro de instancia%i
, como se muestra en el siguiente ejemplo:[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 la instancia de ASCS. Por ejemplo:#
vi /etc/haproxy/haproxy-SIDscs.cfgReemplaza
SID
por el ID del sistema SAP (SID). Usa mayúsculas para las letras. Por ejemplo,AHA
En el archivo de configuración de ASCS
haproxy-SIDscs.cfg
, inserta la siguiente configuración y reemplazaASCS_HEALTHCHECK_PORT_NUM
por el número de puerto que especificaste cuando creaste la verificación de estado de Compute Engine para ASCS antes: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 *:ASCS_HEALTHCHECK_PORT_NUM
Crea un archivo de configuración
haproxy.cfg
para la instancia de ERS. Por ejemplo:#
vi /etc/haproxy/haproxy-SIDers.cfgEn el archivo de configuración ERS
haproxy-SIDers.cfg
, inserta la siguiente configuración y reemplazaERS_HEALTHCHECK_PORT_NUM
por el número de puerto que especificaste cuando creaste la verificación de estado de Compute Engine para ERS antes: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 *:ERS_HEALTHCHECK_PORT_NUM
Vuelve a cargar los servicios de
systemd
:#
systemctl daemon-reloadConfirma que el servicio haproxy esté configurado de forma correcta:
#
systemctl start haproxy#
systemctl status haproxy#
systemctl | grep haproxyEn el estado que se muestra debe aparecer
haproxy.service
comoactive (running)
.● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago Main PID: 1079 (haproxy) Tasks: 2 (limit: 100996) Memory: 5.1M CGroup: /system.slice/haproxy.service ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer... Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.
Repite los pasos anteriores en cada host del clúster.
Configura Pacemaker
El siguiente procedimiento configura la implementación de RHEL de un clúster de Pacemaker en las VM de Compute Engine para SAP NetWeaver.
El procedimiento se basa en la documentación de Red Hat para configurar clústeres de alta disponibilidad, que incluyen las siguientes publicaciones (se requiere una suscripción a Red Hat):
- Configura SAP NetWeaver ASCS/ERS ENSA1 con Standalone Resources en RHEL 7.5+ y RHEL 8
- Configura SAP S/4HANA ASCS/ERS con Standalone Enqueue Server 2 (ENSA2) en Pacemaker
Para obtener información de SAP sobre la instalación y configuración de RHEL, consulta los siguientes vínculos:
- Nota de SAP 3108316 - Red Hat Enterprise Linux 9.x: Instalación y configuración
- Nota de SAP 2772999 - Red Hat Enterprise Linux 8.x: Instalación y configuración
- Nota de SAP 2002167 - Red Hat Enterprise Linux 7.x: Instalación y actualización
Configura los paquetes de clústeres obligatorios y el firewall del SO en ambos hosts
Como raíz en los hosts principales y secundarios, instala y actualiza los paquetes de clúster necesarios, configura hacluster
y configura el servicio de firewall del SO.
Instala los siguientes paquetes de clúster obligatorios:
#
yum install pcs pacemaker#
yum install fence-agents-gce#
yum install resource-agents-gcp#
yum install resource-agents-sap#
yum install sap-cluster-connectorActualiza los paquetes instalados:
#
yum update -yConfigura 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ía 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.
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_VM_NAME SECONDARY_VM_NAMERHEL 7
#
pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_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_VM_NAME SECONDARY_VM_NAMERHEL 7
#
pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME
Actualiza los archivos de configuración de Corosync
En los siguientes pasos, se establecen valores de clúster recomendados para Corosync.
Si el archivo de configuración de Corosync, /etc/corosync/corosync.conf
, aún no existe o está vacío, puedes usar el archivo de muestra en el directorio /etc/corosync/
como base para tu configuración.
Abre el archivo
corosync.conf
para editarlo:#
vi /etc/corosync/corosync.confEn la sección
totem
del archivocorosync.conf
, configura los parámetros del siguiente ejemplo extraído para los valores que se muestran. Es posible que algunos parámetros ya estén configurados en los valores correctos:RHEL 8
totem { ... transport: knet token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }
RHEL 7
totem { ... transport: udpu token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }
Sincroniza la configuración con el segundo servidor:
RHEL 8 y versiones posteriores
#
pcs cluster sync corosyncRHEL 7
#
pcs cluster syncDesde la VM principal, habilita y, luego, inicia el clúster.
#
pcs cluster enable --all#
pcs cluster start --allConfirma que la nueva configuración de corosync esté activa en el clúster mediante la utilidad corosync-cmapctl:
#
corosync-cmapctlVerifica el estado del clúster:
#
pcs statusDeberías ver un resultado similar al siguiente:
Cluster name: nwha WARNINGS: No stonith devices and stonith-enabled is not false Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 0 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Configura los recursos del clúster para la infraestructura
Debes definir los recursos de Pacemaker para la siguiente infraestructura de clúster:
- El dispositivo de protección, que evita situaciones de cerebro dividido
- Los directorios ASCS y ERS en el sistema de archivos compartidos
- Las verificaciones de estado
- Las VIP
- Los componentes de ASCS y ERS
Primero, debes definir los recursos para el dispositivo de protección, el sistema de archivos compartidos, las verificaciones de estado y las VIP. Luego, instala SAP NetWeaver. Después de instalar SAP NetWeaver, debes definir los recursos del clúster para los componentes de ASCS y ERS.
Configura la protección
Puedes configurar la protección mediante la definición de un recurso de clúster con el agente fence_gce
para cada VM del host.
A fin de garantizar la secuencia correcta de eventos después de una acción de protección, también debes configurar el sistema operativo para que retrase el reinicio de Corosync después de que se protege una VM. También debes ajustar el tiempo de espera de Pacemaker para los reinicios a fin de responder ante la demora.
Crea los recursos del dispositivo de protección
En cada VM del clúster, crea un recurso de clúster para el dispositivo de protección a fin de que el clúster pueda reiniciar la VM. El dispositivo de protección para una VM debe ejecutarse en una VM diferente, por lo que configuras la ubicación del recurso de clúster que se ejecutará en cualquier VM, excepto la VM que puede reiniciar.
En el host principal como raíz, crea un recurso de clúster para un dispositivo de protección de la VM principal:
#
pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \ port="PRIMARY_VM_NAME" \ zone="PRIMARY_ZONE" \ project="CLUSTER_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"Configura la ubicación del dispositivo de protección de la VM principal a fin de que esté activa solo en la VM secundaria:
#
pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAMEEn el host principal como raíz, crea un recurso de clúster para un dispositivo de protección de la VM secundaria:
#
pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \ port="SECONDARY_VM_NAME" \ zone="SECONDARY_ZONE" \ project="CLUSTER_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"Configura la ubicación del dispositivo de protección para la VM secundaria a fin de que esté activa solo en la VM principal:
#
pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME
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
Crea los recursos del sistema de archivos
Define los recursos del clúster para los directorios ASCS y ERS en el sistema de archivos compartidos.
Configura un recurso del sistema de archivos para el directorio ASCS.
#
pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ASCS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40Reemplaza lo siguiente:
ASCS_FILE_SYSTEM_RESOURCE
: Especifica un nombre para el recurso del clúster del sistema de archivos ASCS.NFS_PATH
: especifica la ruta del directorio al sistema de archivos NFS.SID
: Especifica el ID del sistema (SID). Usa mayúsculas para las letras.ASCS_INSTANCE_NUMBER
: Especifica el número de instancia de ASCS.ASCS_RESOURCE_GROUP
: Especifica un nombre de grupo único para los recursos del clúster de ASCS. Puedes garantizar la exclusividad con una convención como “SID_ASCSinstance_number_group”. Por ejemplo,nw8_ASCS00_group
.Debido a que un grupo aún no existe, Pacemaker lo crea ahora. A medida que creas otros recursos de ASCS, los agregas a este grupo.
Configura un recurso del sistema de archivos para el directorio ERS.
#
pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ERS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40Reemplaza lo siguiente:
ERS_FILE_SYSTEM_RESOURCE
: Especifica un nombre para el recurso del sistema de archivos.NFS_PATH
: especifica la ruta del directorio al sistema de archivos NFS.SID
: Especifica el ID del sistema (SID). Usa mayúsculas para las letras.ERS_INSTANCE_NUMBER
: Especifica el número de instancia de ERS.ERS_RESOURCE_GROUP
: Especifica un nombre de grupo único para los recursos del clúster de ERS. Puedes garantizar la exclusividad con una convención como “SID_ERSinstance_number_group”. Por ejemplo,nw8_ERS10_group
.Debido a que un grupo aún no existe, Pacemaker lo crea ahora. A medida que creas otros recursos de ERS, los agregas a este grupo.
Crea un recurso de dirección IP virtual
Define los recursos del clúster para las direcciones VIP.
Si necesitas buscar la dirección VIP, puedes usar el siguiente comando:
gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
Crea los recursos del clúster para las VIP de ASCS y ERS.
#
pcs resource create ASCS_VIP_RESOURCE IPaddr2 \ ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ASCS_RESOURCE_GROUP#
pcs resource create ERS_VIP_RESOURCE IPaddr2 \ ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ERS_RESOURCE_GROUP
Crea los recursos de verificación de estado
Configura el recurso del clúster para la verificación de estado de ASCS:
#
pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \ op monitor interval=10s timeout=20s \ --group ASCS_RESOURCE_GROUPConfigura el recurso del clúster para la verificación de estado de ERS:
#
pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \ op monitor interval=10s timeout=20s \ --group ERS_RESOURCE_GROUP
Establece valores predeterminados adicionales del clúster
Configura las propiedades adicionales del clúster:
#
pcs resource defaults resource-stickiness=1#
pcs resource defaults migration-threshold=3
Visualiza los recursos definidos
Muestra los recursos del clúster que definiste hasta ahora para asegurarte de que sean correctos.
Muestra el estado del clúster:
#
pcs statusDeberías ver un resultado similar al siguiente:
Cluster name: nwha Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 8 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * Resource Group: nw8_ascs00_group: * nw8_vip_ascs00 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_scs (service:haproxy@nw8scs): Started nw-ha-vm-1 * nw8_fs_ascs00 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * Resource Group: nw8_ers10_group: * nw8_vip_ers10 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * nw8_healthcheck_ers (service:haproxy@nw8ers): Started nw-ha-vm-2 * nw8_fs_ers10 (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Instala ASCS y ERS
En la siguiente sección, solo se abordan los requisitos y las recomendaciones específicos para instalar SAP NetWeaver en Google Cloud.
Para obtener instrucciones de instalación completas, consulta la documentación de SAP NetWeaver.
Prepararse para la instalación
Para garantizar la coherencia en el clúster y simplificar la instalación, antes de instalar los componentes de ASCS y ERS de SAP NetWeaver, define los usuarios, grupos y permisos, y coloca el servidor secundario en modo de espera.
Quita el clúster del modo de mantenimiento:
#
sudo pcs property set maintenance-mode="false"En ambos servidores como raíz, ingresa los siguientes comandos y especifica los ID de usuario y grupo que sean adecuados para tu entorno:
#
groupadd -g GID_SAPINST sapinst#
groupadd -g GID_SAPSYS sapsys#
useradd -u UID_SIDADM SID_LCadm -g sapsys#
usermod -a -G sapinst SID_LCadm#
useradd -u UID_SAPADM sapadm -g sapinst#
chown SID_LCadm:sapsys /usr/sap/SID/SYS#
chown SID_LCadm:sapsys /sapmnt/SID -R#
chown SID_LCadm:sapsys /usr/sap/trans -R#
chown SID_LCadm:sapsys /usr/sap/SID/SYS -R#
chown SID_LCadm:sapsys /usr/sap/SID -RReemplaza lo siguiente:
GID_SAPINST
: Especifica el ID de grupo de Linux para la herramienta de aprovisionamiento de SAP.GID_SAPSYS
: Especifica el ID de grupo de Linux para el usuario SAPSYS.UID_SIDADM
: Especifica el ID de usuario de Linux para el administrador del sistema SAP (SID).SID_LC
: Especifica el ID del sistema (SID). Usa minúsculas para las letras.UID_SAPADM
: Especifica el ID de usuario para SAP Host Agent.SID
: Especifica el ID del sistema (SID). Usa mayúsculas para las letras.
Por ejemplo, a continuación se muestra un esquema práctico de numeración de GID y UID:
Group sapinst 1001 Group sapsys 1002 Group dbhshm 1003 User en2adm 2001 User sapadm 2002 User dbhadm 2003
Instala el componente ASCS
En el servidor secundario, ingresa el siguiente comando para poner el servidor secundario en modo de espera:
#
pcs node standbyCuando se pone el servidor secundario en modo de espera, se consolidan todos los recursos del clúster en el servidor principal, lo que simplifica la instalación.
Confirma que el servidor secundario esté en modo de espera:
#
pcs statusDeberías ver un resultado similar al siguiente:
Cluster name: nwha Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 8 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * fence-nw-ha-vm-1 (stonith:fence_gce): Stopped * Resource Group: nw8_ascs00_group: * nw8_vip_ascs00 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_scs (service:haproxy@nw8scs): Started nw-ha-vm-1 * nw8_fs_ascs00 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * Resource Group: nw8_ers10_group: * nw8_vip_ers10 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_ers (service:haproxy@nw8ers): Started nw-ha-vm-1 * nw8_fs_ers10 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 Daemon Status: corosync: active/enabled
En el servidor principal como usuario raíz, cambia tu directorio a un directorio de instalación temporal, como
/tmp
, para instalar la instancia de ASCS. Para ello, ejecuta SAP Software Provisioning Manager (SWPM).A fin de acceder a la interfaz web de SWPM, necesitas la contraseña para el usuario
root
. Si tu política de TI no permite que el administrador de SAP tenga acceso a la contraseña raíz, puedes usarSAPINST_REMOTE_ACCESS_USER
.Cuando inicies SWPM, usa el parámetro
SAPINST_USE_HOSTNAME
a fin de especificar el nombre de host virtual que definiste para la dirección VIP de ASCS en el archivo/etc/hosts
.Por ejemplo:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
En la página de confirmación final de SWPM, asegúrate de que el nombre del host virtual sea correcto.
Una vez completada la configuración, quita la VM secundaria del modo en espera:
#
pcs node unstandby
Instala el componente ERS
En el servidor principal como raíz o
SID_LCadm
, detén el servicio de ASCS.#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"En el servidor principal, ingresa el siguiente comando para poner el servidor principal en modo de espera:
#
pcs node standbyCuando se coloca el servidor principal en modo de espera, se consolidan todos los recursos del clúster en el servidor secundario, lo que simplifica la instalación.
Confirma que el servidor principal esté en modo de espera:
#
pcs statusEn el servidor secundario como usuario raíz, cambia tu directorio a uno de instalación temporal, como
/tmp
, para instalar la instancia de ERS, mediante la ejecución del SAP Software Provisioning Manager (SWPM).Usa el mismo usuario y contraseña para acceder a SWPM que usaste cuando instalaste el componente ASCS.
Cuando inicies SWPM, usa el parámetro
SAPINST_USE_HOSTNAME
a fin de especificar el nombre de host virtual que definiste para la dirección VIP de ERS en el archivo/etc/hosts
.Por ejemplo:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
En la página de confirmación final de SWPM, asegúrate de que el nombre del host virtual sea correcto.
Quita la VM principal del modo de espera para que esté activa:
#
pcs node unstandby
Configura los servicios de SAP
Debes confirmar que los servicios estén configurados de forma correcta, verificar la configuración en los perfiles de ASCS y ERS, y agregar el usuario SID_LCadm
al grupo de usuarios haclient
.
Confirma las entradas de servicio de SAP
En ambos servidores, confirma que el archivo
/usr/sap/sapservices
contenga entradas para los servicios ASCS y ERS. Para hacerlo, puedes usar la integraciónsystemV
osystemd
.Puedes agregar cualquier entrada faltante a través del comando
sapstartsrv
con las opcionespf=PROFILE_OF_THE_SAP_INSTANCE
y-reg
.Para obtener más información sobre estas integraciones, consulta las siguientes Notas de SAP:
- 3139184: Linux: integración de
systemd
parasapstartsrv
y SAP Host Agent 3115048:
sapstartsrv
con compatibilidad nativa consystemd
en Linux
systemV
El siguiente es un ejemplo de cómo apaecen las entradas para los servicios de ASCS y ERS en el archivo
/usr/sap/sapservices
cuando usas la integraciónsystemV
:#
LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH /usr/sap/hostctrl/exe/sapstartsrv \ pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ -D -u SID_LCadm /usr/sap/hostctrl/exe/sapstartsrv \ pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ -D -u SID_LCadmsystemd
Verifica que tu archivo
/usr/sap/sapservices
contenga entradas para los servicios de ASCS y ERS. El siguiente es un ejemplo de cómo aparecen estas entradas en el archivo/usr/sap/sapservices
cuando usas la integraciónsystemd
:systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
Inhabilita la integración
systemd
en las instancias de ASCS y ERS:#
systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ERS_INSTANCE_NUMBER.serviceVerifica que la integración
systemd
esté inhabilitada:#
systemctl list-unit-files | grep sapUn resultado similar al siguiente ejemplo significa que la integración
systemd
está inhabilitada. Ten en cuenta que algunos servicios, comosaphostagent
ysaptune
, están habilitados y otros no lo están.SAPSID_ASCS_INSTANCE_NUMBER.service disabled SAPSID_ERS_INSTANCE_NUMBER.service disabled saphostagent.service enabled sapinit.service generated saprouter.service disabled saptune.service enabled
- 3139184: Linux: integración de
Detén los servicios de SAP
En el servidor secundario, detén el servicio de ERS:
#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"En cada servidor, verifica que todos los servicios estén detenidos:
#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"Deberías ver un resultado similar al siguiente:
GetSystemInstanceList FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()
Inhabilita el reinicio automático de servicios en SAP
Debido a que el software del clúster administra el reinicio de los servicios de SAP durante una conmutación por error, para evitar conflictos, inhabilita la capacidad del software de SAP para reiniciar los servicios de forma automática.
En ambos nodos, edita el archivo
/usr/sap/sapservices
para inhabilitar el reinicio automático en el software de SAP mediante la adición de un carácter de comentario,#
, al comienzo del comandosapstartsrv
para componentes de ASCS y ERS.Por ejemplo:
#!/bin/sh #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
Edita los perfiles de ASCS y ERS
En cualquiera de los servidores, cambia al directorio de perfil mediante uno de los siguientes comandos:
#
cd /usr/sap/SID/SYS/profile#
cd /sapmnt/SID/profileSi es necesario, puedes encontrar los nombres de los archivos de tus perfiles de ASCS y ERS si enumeras los archivos en el directorio de perfil o usas los siguientes formatos:
SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
Si usas ENSA1, habilita la función keepalive con solo configurar lo siguiente en el perfil de ASCS:
enque/encni/set_so_keepalive = true
Para obtener más información, consulta la Nota de SAP 1410736 - TCP/IP: Cómo configurar el intervalo keepalive.
Si es necesario, edita los perfiles de ASCS y ERS para cambiar el comportamiento de inicio del Enqueue Server y del Enqueue Replication Server.
ENSA1
En la sección “Iniciar SAP Enqueue Server” del perfil de ASCS, si ves
Restart_Program_NN
, cambia “Restart
” a “Start
”, como se muestra en el siguiente ejemplo.Start_Program_01 = local $(_EN) pf=$(_PF)
En la sección “Inicia el Enqueue Replication Server” del perfil de ERS, si ves
Restart_Program_NN
, cambia “Restart
” por “Start
”, como se muestra en el siguiente ejemplo.Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)
ENSA2
En la sección “Iniciar SAP Enqueue Server” del perfil de ASCS, si ves
Restart_Program_NN
, cambia “Restart
” a “Start
”, como se muestra en el siguiente ejemplo.Start_Program_01 = local $(_ENQ) pf=$(_PF)
En la sección “Iniciar Enqueue Replicator” del perfil de ERS, si ves
Restart_Program_NN
, cambia “Restart
” por “Start
”, como se muestra en el siguiente ejemplo.Start_Program_00 = local $(_ENQR) pf=$(_PF) ...
Configura los recursos del clúster para ASCS y ERS
Como raíz de cualquiera de los servidores, coloca el clúster en modo de mantenimiento:
#
pcs property set maintenance-mode="true"Confirma que el clúster esté en modo de mantenimiento:
#
pcs statusCrea los recursos del clúster para los servicios de ASCS y ERS:
ENSA1
Crea el recurso de clúster para la instancia de ASCS. El valor de
InstanceName
es el nombre del perfil de la instancia que generó SWPM cuando instalaste ASCS.#
pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \ failure-timeout=60 --group ASCS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600#
pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000Crea el recurso de clúster para la instancia de ERS. El valor de
InstanceName
es el nombre del perfil de la instancia que generó SWPM cuando instalaste ERS. El parámetroIS_ERS=true
le indica a Pacemaker que establezca la marcarunsersSID
en1
en el nodo en el que está activo ERS.#
pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600
ENSA2
Crea el recurso de clúster para la instancia de ASCS. El valor de
InstanceName
es el nombre del perfil de la instancia que generó SWPM cuando instalaste ASCS.#
pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \ --group ASCS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600#
pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000Crea el recurso de clúster para la instancia de ERS. El valor de
InstanceName
es el nombre del perfil de la instancia que generó SWPM cuando instalaste ERS.#
pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600
Configura las limitaciones de ubicación y orden
Crea restricciones para definir qué servicios deben iniciarse primero y qué servicios deben ejecutarse juntos en el mismo host. Por ejemplo, la dirección IP debe estar en el mismo host que la instancia principal de SAP Central Services.
- Define la restricción del orden de inicio:
ENSA1
Crea una restricción de colocación que evite que los recursos de ASCS se ejecuten en el mismo servidor que los recursos de ERS:
#
pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000Configura ASCS para conmutar por error al servidor en el que se ejecuta ERS, según lo determinado por la marca
runsersSID
que es igual a1
:#
pcs constraint location ASCS_INSTANCE \ rule score=2000 runs_ers_SID eq 1Configura ASCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:
#
pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
ENSA2
Crea una restricción de colocación que evite que los recursos de ASCS se ejecuten en el mismo servidor que los recursos de ERS:
#
pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000Configura ASCS para que se inicie antes de que ERS se traslade al otro servidor después de una conmutación por error:
#
pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
Comprueba las restricciones:
#
pcs constraintDebería ver un resultado similar al siguiente:
Location Constraints: Resource: ascs-aha-instance Constraint: location-ascs-instance Rule: score=2000 Expression: runs_ers_HKN eq 1 Resource: fence-nw-ha-vm-1 Disabled on: nw-ha-vm-1 (score:-INFINITY) Resource: fence-nw-ha-vm-2 Disabled on: nw-ha-vm-2 (score:-INFINITY) Ordering Constraints: start ascs-group then stop ers-group (kind:Optional) (non-symmetrical) Colocation Constraints: ascs-group with ers-group (score:-5000) Ticket Constraints:
Como raíz desde cualquiera de los servidores, inhabilita el modo de mantenimiento del clúster:
#
pcs property set maintenance-mode="false"
Configura el conector de clústeres de Red Hat para SAP
En cada host del clúster, configura SAP Start Service sapstartsrv
para que se comunique con el software del clúster de Pacemaker a través de la interfaz de alta disponibilidad.
Agrega el usuario administrativo de SAP al grupo
haclient
:usermod -a -G haclient SID_LCadm
Edita los perfiles de instancia de SAP y agrega las siguientes líneas al final de cada perfil. Los perfiles se pueden encontrar en el directorio
/sapmnt/SID/profiles
.service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_cluster_connector
Si los recursos de instancia de ASCS y ERS se están ejecutando actualmente en el clúster, inhabilítalos:
pcs resource disable ERS_INSTANCE_RESOURCE pcs resource disable ASCS_INSTANCE_RESOURCE
Detén los servicios en el host de ASCS:
sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService
Detén los servicios en el host de ERS:
sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService
Habilita los recursos:
pcs resource enable ERS_INSTANCE_RESOURCE pcs resource enable ASCS_INSTANCE_RESOURCE
Repite los pasos anteriores en cada host del clúster.
Si deseas obtener más información de Red Hat, consulta Cómo configurar SAP halib
para los recursos SAPInstance
en RHEL 7 y 8.
Instala la base de datos y los servidores de aplicaciones en hosts fuera del clúster
En la configuración de alta disponibilidad, te recomendamos que instales los servidores de aplicaciones y la base de datos en hosts diferentes de los hosts de ASCS y ERS en el clúster.
Mediante el uso de hosts independientes para cada servidor, se reduce la complejidad y el riesgo de una falla que afecte a varios servidores, y se puede adaptar el tamaño de cada Compute Engine a cada tipo de servidor.
Esto te permite elegir el tamaño de máquina certificada más adecuado, evitar fallas y reducir la complejidad.
La instalación de la base de datos y los servidores de aplicaciones no se trata en esta guía.
Para obtener información sobre cómo instalar los servidores de bases de datos, consulta los siguientes vínculos:
- SAP HANA en Google Cloud
- SAP ASE en Google Cloud
- SAP MaxDB en Google Cloud
- IBM Db2 para SAP en Google Cloud
Valida y prueba el clúster
En esta sección, se muestra cómo ejecutar las siguientes pruebas:
- Comprueba si hay errores de configuración
- Confirma que los recursos de ASCS y ERS cambien de servidor correctamente durante las conmutaciones por error
- Confirma que los bloqueos estén retenidos
- Simula un evento de mantenimiento de Compute Engine para asegurarte de que la migración en vivo no active una conmutación por error
Verifica la configuración del clúster
Como raíz en cualquiera de los servidores, verifica en qué nodos se están ejecutando los recursos:
#
pcs statusEn el siguiente ejemplo, los recursos de ASCS se ejecutan en el servidor
nw-ha-vm-2
y los recursos de ERS se ejecutan en el servidornw-ha-vm-1
.Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Wed Apr 13 05:21:21 2022 Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2 2 nodes configured 10 resource instances configured Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 Resource Group: ascs-group ascs-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 ascs-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 ascs-healthcheck (service:haproxy@AHAascs): Started nw-ha-vm-2 ascs-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 Resource Group: ers-group ers-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 ers-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 ers-healthcheck (service:haproxy@AHAers): Started nw-ha-vm-1 ers-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 Migration Summary: * Node nw-ha-vm-1: * Node nw-ha-vm-2:
Cambia al usuario
SID_LCadm
.#
su - SID_LCadmVerifica la configuración del clúster. Para
INSTANCE_NUMBER
, especifica el número de la instancia de ASCS o ERS que está activa en el servidor en el que ingresas el comando:>
sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfigHAActive
debe serTRUE
, como se muestra en el siguiente ejemplo:HAGetFailoverConfig 14.04.2022 17:25:45 HAGetFailoverConfig OK HAActive: TRUE HAProductVersion: Pacemaker HASAPInterfaceVersion: sap_cluster_connector HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector HAActiveNode: HANodes:
Como
SID_LCadm
, verifica si hay errores en la configuración:>
sapcontrol -nr INSTANCE_NUMBER -function HACheckConfigDeberías ver un resultado similar al siguiente:
14.04.2022 21:43:39 HACheckConfig OK state, category, description, comment SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server SUCCESS, SAP STATE, SCS instance running, SCS instance status ok SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch
En el servidor en el que ASCS está activo, como
SID_LCadm
, simula una conmutación por error:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""Como raíz, si sigues la conmutación por error mediante
crm_mon
, deberías ver que ASCS se mueve al otro servidor, y que ERS se detiene en ese servidor y que se traslada al servidor en el que se solía ejecutar ASCS.
Simula una conmutación por error
Simula una falla en el host principal para probar el clúster. Usa un sistema de prueba o ejecuta la prueba en tu sistema de producción antes de lanzar el sistema para su uso.
Puedes simular una falla de varias maneras, incluidas las siguientes:
shutdown -r
(en el nodo activo)ip link set eth0 down
echo c > /proc/sysrq-trigger
En estas instrucciones, se usa ip link set eth0 down
para desconectar la interfaz de red, ya que valida la conmutación por error y la protección.
Realiza una copia de seguridad de tu sistema.
Como raíz en el host con la instancia de SCS activa, desconecta la interfaz de red:
$
ip link set eth0 downVuelve a conectarte a cualquier host mediante 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.Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Wed Apr 13 05:21:21 2022 Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2 2 nodes configured 10 resource instances configured Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 Resource Group: ascs-group ascs-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 ascs-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 ascs-healthcheck (service:haproxy@AHAascs): Started nw-ha-vm-1 ascs-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 Resource Group: ers-group ers-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 ers-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 ers-healthcheck (service:haproxy@AHAers): Started nw-ha-vm-2 ers-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 Migration Summary: * Node nw-ha-vm-1: * Node nw-ha-vm-2:
Confirma que se conserven las entradas de bloqueo
Para confirmar que las entradas de bloqueo se conservan en una conmutación por error, primero selecciona la pestaña de tu versión de Enqueue Server y sigue el procedimiento para generar entradas de bloqueo, simula una conmutación por error y confirma que las entradas de bloqueo se retienen después de que ASCS se vuelve a activar.
ENSA1
Como
SID_LCadm
, en el servidor en el que ERS está activo, genera entradas de bloqueo mediante el programaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKSComo
SID_LCadm
, en el servidor en el que ASCS está activo, verifica que se registren las entradas de bloqueo:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSi creaste 10 bloqueos, deberías ver un resultado similar al siguiente:
locks_now: 10
Como
SID_LCadm
, en el servidor en el que ERS está activo, inicia la función de supervisión,OpCode=20
, del programaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999Por ejemplo:
>
enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999Cuando ASCS esté activo, reinicia el servidor.
En el servidor de supervisión, para cuando Pacemaker detenga el ERS a fin de moverlo al otro servidor, deberías ver un resultado similar al siguiente.
Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10
Cuando se detenga el monitor
enqt
, ingresaCtrl + c
para salir de él.De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:
#
crm_monComo
SID_LCadm
, después de confirmar que los bloqueos se retuvieron, debes liberarlos:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKSComo
SID_LCadm
, en el servidor en el que está activo ASCS, verifica que se quiten las entradas de bloqueo:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now
ENSA2
Como
SID_LCadm
, en el servidor en el que ASCS está activo, genera entradas de bloqueo mediante el programaenq_adm
:>
enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAMEComo
SID_LCadm
, en el servidor en el que ASCS está activo, verifica que se registren las entradas de bloqueo:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSi creaste 10 bloqueos, deberías ver un resultado similar al siguiente:
locks_now: 10
Cuando ERS esté activo, confirma que las entradas de bloqueo se hayan replicado:
>
sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowLa cantidad de bloqueos que se muestran debe ser la misma que la de la instancia de ASCS.
Cuando ASCS esté activo, reinicia el servidor.
De manera opcional, como raíz en cualquiera de los servidores, supervisa la conmutación por error del clúster:
#
crm_monComo
SID_LCadm
, en el servidor en el que se reinició ASCS, verifica que se hayan retenido las entradas de bloqueo:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowComo
SID_LCadm
en el servidor en el que ERS está activo, después de confirmar que se retuvieron los bloqueos, libera los bloqueos:>
enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAMEComo
SID_LCadm
, en el servidor en el que está activo ASCS, verifica que se quiten las entradas de bloqueo:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowDeberías ver un resultado similar al siguiente:
locks_now: 0
Simula un evento de mantenimiento de Compute Engine
Simula un evento de mantenimiento de Compute Engine para asegurarte de que la migración en vivo no active una conmutación por error.
Los valores de tiempo de espera y de intervalo que se usan en estas instrucciones se tienen en cuenta para la duración de las migraciones en vivo. Si usas valores más cortos en la configuración de tu clúster, el riesgo de que la migración en vivo active una conmutación por error es mayor.
Para probar la tolerancia del clúster en la migración en vivo, haz lo siguiente:
En el nodo principal, activa un evento de mantenimiento simulado mediante el siguiente comando de la CLI de gcloud:
$
gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAMEConfirma que el nodo principal no cambie:
$
pcs status
Evalúa la carga de trabajo de SAP NetWeaver
Para automatizar las verificaciones de validación continua de las cargas de trabajo de alta disponibilidad de SAP NetWeaver que se ejecutan en Google Cloud, puedes usar Workload Manager.
Workload Manager te permite analizar y evaluar de forma automática las cargas de trabajo de alta disponibilidad de SAP NetWeaver con las prácticas recomendadas de SAP, Google Cloud y los proveedores del SO. Esto ayuda a mejorar la calidad, el rendimiento y la confiabilidad de tus cargas de trabajo.
Si deseas obtener información sobre las prácticas recomendadas que admite el administrador de cargas de trabajo para evaluar las cargas de trabajo de alta disponibilidad de SAP NetWeaver que se ejecutan en Google Cloud, consulta Prácticas recomendadas de administrador de cargas de trabajo para SAP. Para obtener información sobre cómo crear y ejecutar una evaluación mediante Workload Manager, consulta Crea y ejecuta una evaluación.
Soluciona problemas
A fin de solucionar problemas de configuraciones de alta disponibilidad para SAP NetWeaver, consulta Solución de problemas de configuraciones de alta disponibilidad para SAP.
Recopila información de diagnóstico para los clústeres de alta disponibilidad de SAP NetWeaver
Si necesitas ayuda para resolver un problema con los clústeres de alta disponibilidad para SAP NetWeaver, recopila la información de diagnóstico requerida y comunícate con el servicio de Atención al cliente de Cloud.
Para recopilar información de diagnóstico, consulta Clústeres de alta disponibilidad en la información de diagnóstico de RHEL.Asistencia
Si tienes problemas con la infraestructura o los servicios de Google Cloud, comunícate con el servicio de Atención al cliente. Puedes encontrar la información de contacto en la página Descripción general de la asistencia en la consola de Google Cloud. Si el servicio de Atención al cliente determina que existe un problema en tus sistemas de SAP, te referiremos al servicio de asistencia de SAP.
Por problemas relacionados con el producto SAP, registra una solicitud de asistencia en Asistencia de SAP.
SAP evalúa el ticket de asistencia y, si parece ser un problema de infraestructura de Google Cloud, SAP transfiere ese ticket al componente de Google Cloud adecuado en su sistema: BC-OP-LNX-GOOGLE
o BC-OP-NT-GOOGLE
.
Requisitos de asistencia
Antes de recibir asistencia para los sistemas SAP y la infraestructura y los servicios de Google Cloud que usan, debes cumplir con los requisitos mínimos del plan de asistencia.
Para obtener más información sobre los requisitos mínimos de asistencia para SAP en Google Cloud, consulta lo siguiente:
- Obtén asistencia para SAP en Google Cloud
- Nota de SAP 2456406: SAP en Google Cloud Platform: requisitos previos de compatibilidad (se requiere una cuenta de usuario de SAP)
Realiza tareas posteriores a la implementación
Antes de usar el sistema SAP NetWeaver, te recomendamos que crees una copia de seguridad del nuevo sistema SAP NetWeaver de HA.
Para obtener más información, consulta la Guía de operaciones de SAP NetWeaver.
¿Qué sigue?
Para obtener más información sobre la alta disponibilidad, SAP NetWeaver y Google Cloud, consulta los siguientes recursos:
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]
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 para SAP NetWeaver en Google Cloud
Para obtener más información sobre la administración y la supervisión de VM, consulta la Guía de operaciones de SAP NetWeaver.