En Google Cloud se recomienda usar la compatibilidad con la conmutación por error de un balanceador de cargas TCP/UDP interno para implementar una dirección IP virtual (VIP) en un clúster de alta disponibilidad (HA) basado en SO para SAP.
Si tienes un clúster de HA de Red Hat Enterprise Linux (RHEL) para SAP en Google Cloud que usa una VIP que se implementó con una IP de alias, puedes migrar la VIP a fin de usar un balanceador de cargas interno.
Si usaste la plantilla sap_hana_ha
de Deployment Manager, que ya no es compatible, para implementar un sistema de escalamiento vertical de SAP HANA en un clúster de HA en RHEL, tu VIP se implementa con una IP de alias.
En las siguientes instrucciones, se explica cómo migrar una VIP en un clúster de HA de RHEL.
Requisitos previos
En estas instrucciones se supone que ya tienes un clúster de HA configurado correctamente en Google Cloud y que este usa una IP de alias para implementar la VIP.
Descripción general de los pasos
- Configura y prueba un balanceador de cargas con una regla de reenvío y una dirección IP temporales en lugar de la VIP.
- Configura tu clúster en el modo de mantenimiento y, si puedes, detén las instancias del servidor de aplicaciones de SAP para evitar cualquier comportamiento inesperado.
- Desasigna la dirección IP de alias del host principal. Esta dirección se convertirá en la VIP con el balanceador de cargas.
- Realiza estas acciones en la configuración del clúster de Pacemaker:
- Cambia la clase del recurso de VIP existente.
- Reemplaza los parámetros existentes de la IP de alias por los parámetros del servicio de verificación de estado.
Confirma la dirección VIP existente
Como raíz, en la instancia de VM principal, muestra tu configuración de clúster basada en IP de alias:
$
pcs configure show
En la definición del recurso, el rango de direcciones VIP aparece en los recursos alias
y IPaddr2
. Si necesitas cambiar la dirección VIP, debes actualizar ambos recursos. Consulta el siguiente ejemplo:
Resource rsc_alias (class=ocf provider=heartbeat type=gcp-vpc-move-vip) \ Attributes: alias_ip=10.10.0.90/32 Operations: monitor interval=60s timeout=60s (vip_hkn_00-monitor-interval-60s) start interval=0s timeout=600s stop interval=0s timeout=20s Resource rsc_vip(class=ocf provider=heartbeat type=IPaddr2) \ Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0 Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s) start interval=0s timeout=20s (vip_hkn_00-start-interval-0s) stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s)
En la consola de Google Cloud, confirma que esté reservada la dirección IP que se usa con la IP de alias. La dirección IP puede ser la que se usó para la IP de alias o puede ser una dirección IP nueva.
$
gcloud compute addresses list --filter="region:( cluster-region )"
Si la dirección IP está reservada y se asigna a la instancia de VM principal, su estado se muestra como IN_USE
. Cuando vuelvas a asignar la IP en el balanceador de cargas, primero deberás desasignarla de la instancia principal activa. En ese momento su estado cambiará a RESERVED
.
Si la dirección no se incluye en las direcciones IP que muestra el comando de lista, configúrala ahora para evitar conflictos de IP en el futuro:
$
gcloud compute addresses create vip-name \
--region cluster-region --subnet cluster-subnet \
--addresses vip-address
Vuelve a enumerar tus direcciones para confirmar que la dirección IP aparezca como RESERVED
.
Configura la compatibilidad con la conmutación por error de Cloud Load Balancing
El servicio de balanceador de cargas de red de transferencia interno con compatibilidad con la conmutación por error enruta el tráfico al host activo en un clúster de SAP HANA basado en un servicio de verificación de estado.
Para evitar conflictos y poder realizar pruebas antes de que se complete la migración, con estas instrucciones podrás crear una regla de reenvío temporal con una dirección IP de marcador de posición de la misma subred que la dirección VIP. Cuando estés listo para implementar la VIP, deberás crear una nueva regla de reenvío final con la dirección VIP.
Reserva una dirección IP temporal para la IP virtual
La dirección VIP sigue el sistema SAP HANA activo. El balanceador de cargas enruta el tráfico que se envía a la VIP hacia la VM que aloja el sistema SAP HANA activo.
Abre Cloud Shell:
Reserva una dirección IP temporal en la misma subred que la IP de alias a fin de realizar pruebas. Si omites la marca
--addresses
, se elige una dirección IP en la subred especificada:$
gcloud compute addresses create VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses VIP_ADDRESSPara obtener más información sobre cómo reservar una IP estática, consulta Reserva una dirección IP interna estática.
Confirma la reserva de la dirección IP:
$
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONDeberías ver un resultado similar al siguiente:
address: 10.0.0.19 addressType: INTERNAL creationTimestamp: '2020-05-20T14:19:03.109-07:00' description: '' id: '8961491304398200872' kind: compute#address name: vip-for-hana-ha networkTier: PREMIUM purpose: GCE_ENDPOINT region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1
Crea grupos de instancias para tus VM host
En Cloud Shell, crea dos grupos de instancias no administrados y asigna el VM host de instancia principal a uno y el VM host de instancia principal del secundario a la otra:
$
gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE$
gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_HOST_NAME$
gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE$
gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_HOST_NAMEConfirma la creación de los grupos de instancias:
$
gcloud compute instance-groups unmanaged listDeberías ver un resultado similar al siguiente:
NAME ZONE NETWORK NETWORK_PROJECT MANAGED INSTANCES hana-ha-ig-1 us-central1-a example-network example-project-123456 No 1 hana-ha-ig-2 us-central1-c example-network example-project-123456 No 1
Crea una verificación de estado de Compute Engine
En Cloud Shell, crea la verificación de estado. Para el puerto que usa la verificación de estado, elige un puerto que esté en el rango privado, 49152-65535, a fin de evitar conflictos con otros servicios. Los valores de intervalo de verificación y tiempo de espera son un poco más largos que los valores predeterminados con el fin de aumentar la tolerancia a la conmutación por error durante los eventos de migración en vivo de Compute Engine. Puedes ajustar los valores si es necesario:
$
gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \ --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Confirma la creación de la verificación de estado:
$
gcloud compute health-checks describe HEALTH_CHECK_NAMEDeberías ver un resultado similar al siguiente:
checkIntervalSec: 10 creationTimestamp: '2020-05-20T21:03:06.924-07:00' healthyThreshold: 2 id: '4963070308818371477' kind: compute#healthCheck name: hana-health-check selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check tcpHealthCheck: port: 60000 portSpecification: USE_FIXED_PORT proxyHeader: NONE timeoutSec: 10 type: TCP unhealthyThreshold: 2
Crea una regla de firewall para las verificaciones de estado
Define una regla de firewall para un puerto en el rango privado que permita el acceso a las VM de tu host desde los rangos de IP que usan las verificaciones de estado de Compute Engine, 35.191.0.0/16
y 130.211.0.0/22
. Si deseas obtener más información, consulta Crea reglas de firewall para las verificaciones de estado.
Si aún no tienes una, agrega una etiqueta de red a las VM del host. La regla de firewall usa esta etiqueta de red para las verificaciones de estado.
$
gcloud compute instances add-tags PRIMARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone PRIMARY_ZONE$
gcloud compute instances add-tags SECONDARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone SECONDARY_ZONESi aún no tienes una, crea una regla de firewall para permitir las verificaciones de estado:
$
gcloud compute firewall-rules create RULE_NAME \ --network NETWORK_NAME \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags NETWORK_TAGS \ --rules tcp:HLTH_CHK_PORT_NUMPor ejemplo:
gcloud compute firewall-rules create fw-allow-health-checks \ --network example-network \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags cluster-ntwk-tag \ --rules tcp:60000
Configura el balanceador de cargas y el grupo de conmutación por error
Crea el servicio de backend del balanceador de cargas:
$
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAgrega el grupo de instancias principal al servicio de backend:
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONAgrega el grupo de instancias de conmutación por error secundario al servicio de backend:
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGIONCrea una regla de reenvío temporal. En la dirección IP, especifica la dirección IP temporal que reservaste para realizar la prueba: Si necesitas acceder al sistema SAP HANA desde fuera de la región que se especifica a continuación, incluye la marca
--allow-global-access
en la definición:$
gcloud compute forwarding-rules create RULE_NAME \ --load-balancing-scheme internal \ --address VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service BACKEND_SERVICE_NAME \ --ports ALLPara obtener más información sobre el acceso entre regiones al sistema de alta disponibilidad de SAP HANA, consulta Balanceo de cargas de TCP/UDP interno.
Prueba la configuración del balanceador de cargas
Aunque los grupos de instancias de backend no se registren como en buen estado, puedes probar la configuración del balanceador de cargas mediante la configuración de un objeto de escucha que responda a las verificaciones de estado. Después de configurar un objeto de escucha, si el balanceador de cargas está configurado de forma correcta, el estado de los grupos de instancias de backend cambia a en buen estado.
En las siguientes secciones, se presentan diferentes métodos que puedes usar para probar la configuración.
Prueba el balanceador de cargas con la utilidad socat
Puedes usar la utilidad socat
para escuchar de forma temporal en el puerto de verificación de estado.
En ambas VMs del host, instala la utilidad
socat
:$
sudo yum install -y socatInicia un proceso
socat
para escuchar durante 60 segundos en el puerto de verificación de estado:$
sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkEn Cloud Shell, después de esperar algunos segundos para que la verificación de estado detecte el objeto de escucha, verifica el estado de tus grupos de instancias de backend:
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDebería ver un resultado similar al siguiente:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Prueba el balanceador de cargas mediante el puerto 22
Si el puerto 22 está abierto para conexiones SSH en las VM del host, puedes editar de manera temporal el verificador de estado a fin de usar el puerto 22, que tiene un objeto de escucha que puede responder al verificador de estado.
Para usar de forma temporal el puerto 22, sigue estos pasos:
Haz clic en la verificación de estado en la consola:
Haz clic en Editar.
En el campo Puerto, cambia el número de puerto a 22.
Haz clic en Guardar y espera uno o dos minutos.
En Cloud Shell, verifica el estado de tus grupos de instancias de backend:
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDebería ver un resultado similar al siguiente:
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.
Migra la implementación de la VIP para usar el balanceador de cargas
En los pasos siguientes, se editan la configuración del clúster de Pacemaker y la regla de reenvío del balanceador de cargas para completar la migración de la VIP.
Prepara el sistema para la edición
Si puedes, evita que la aplicación de SAP se conecte a la base de datos de SAP HANA, ya que interrumpirás la conexión brevemente para intercambiar las direcciones IP. Los procesos de NetWeaver pueden volver a conectarse a la base de datos, pero es posible que experimentes fallas o esperas. Puedes evitar estas situaciones si interrumpes la conexión. Asegúrate de que tu IP esté registrada en un rango interno que sea parte de la VPC en la región de destino.
Como raíz en la instancia principal activa, coloca el clúster en modo de mantenimiento:
$
pcs property set maintenance-mode="true"Realiza una copia de seguridad de la configuración del clúster:
$
pcs config show > clusterconfig.backup
Cancela la asignación de la IP de alias
En Cloud Shell, confirma los rangos de IP de alias que están asignados a la instancia principal de SAP HANA:
$
gcloud compute instances describe \ primary-host-name \ --zone primary-zone \ --format="flattened(name,networkInterfaces[].aliasIpRanges)"Actualiza la interfaz de red en la consola de Google Cloud . Si no necesitas retener ninguna IP de alias, especifica
--aliases ""
:$
gcloud compute instances network-interfaces update primary-host-name \ --zone primary-zone \ --aliases "ip-ranges-to-retain"
Crea la regla de reenvío de VIP y realiza una limpieza
En la consola de Google Cloud, crea una nueva regla de reenvío de frontend para el balanceador de cargas y especifica la dirección IP que se utilizó en la IP de alias como la dirección IP. Esta es tu VIP.
$
gcloud compute forwarding-rules create rule-name \ --load-balancing-scheme internal \ --address vip-address \ --subnet cluster-subnet \ --region cluster-region \ --backend-service backend-service-name \ --ports ALLConfirma la creación de la regla de reenvío y toma nota del nombre de la regla de reenvío temporal para borrarla:
$
gcloud compute forwarding-rules listBorra la regla de reenvío temporal:
$
gcloud compute forwarding-rules delete rule-name --region=cluster-regionLibera la dirección IP temporal que reservaste:
$
gcloud compute addresses delete temp-ip-name --region=cluster-region
Instala objetos de escucha y crea un recurso de verificación de estado
Para configurar un recurso de verificación de estado, primero debes instalar los objetos de escucha.
Instala un objeto de escucha
El balanceador de cargas usa un objeto de escucha en el puerto de verificación de estado de cada host para determinar dónde se ejecuta la instancia principal del clúster de SAP HANA. 1. Como raíz en la instancia principal en los sistemas principal y secundario, instala un objeto de escucha de TCP. En estas instrucciones, se instala y usa HAProxy como objeto de escucha.
#
yum install haproxy
Abre el archivo de configuración
haproxy.cfg
para editarlo:#
vi /etc/haproxy/haproxy.cfgEn la sección valores predeterminados de
haproxy.cfg
, cambiamode
atcp
.Después de la sección valores predeterminados, agrega lo siguiente para crear una sección nueva:
#--------------------------------------------------------------------- # Health check listener port for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:healthcheck-port-num
El puerto de vinculación es el mismo que usaste cuando creaste la verificación de estado.
Cuando termines, tus actualizaciones deberían ser similares al siguiente ejemplo:
#--------------------------------------------------------------------- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode tcp log global option tcplog option dontlognull option http-server-close # option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 #--------------------------------------------------------------------- # Set up health check listener for SAP HANA HA cluster #--------------------------------------------------------------------- listen healthcheck bind *:60000
En cada host como raíz, inicia el servicio para confirmar que esté configurado de forma correcta:
#
systemctl start haproxy.serviceEn la página del balanceador de cargas en la consola de Google Cloud, haz clic en la entrada del balanceador de cargas:
En la sección Backend de la página Detalles del balanceador de cargas, si el servicio HAProxy está activo en ambos hosts, verás
1/1
en la columna En buen estado (Healthy) de cada entrada del grupo de instancias.En cada host, detén el servicio HAProxy:
#
systemctl stop haproxy.serviceDespués de detener el servicio HAProxy en cada host, se muestra
0/1
en la columna En buen estado (Healthy) de cada grupo de instancias.Más tarde, cuando se configura la verificación de estado, el clúster reinicia el objeto de escucha en el nodo principal.
Crea el recurso de verificación de estado
En cualquier host como raíz, crea un recurso de verificación de estado para el servicio HAProxy:
#
pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s
Edita la configuración del clúster para usar el recurso de verificación de estado y quita el recurso de alias
Quita
Colocation Constraints
para el grupo existente que contiene el recurso de IP de alias asignado a la instancia principal de SAP HANA:#
pcs constraint remove colocation-alias-vip-group-sap_hana_resource_nameCrea un nuevo grupo de recursos que agrupe los recursos VIP y de verificación de estado:
#
pcs resource group add rsc-group-namehealthcheck_resource_namevip_resource_nameEste comando reemplaza el nombre del grupo anterior de alias de IP y recursos VIP con el nuevo nombre del grupo de recursos en la configuración del clúster.
Verifica el nombre del grupo de recursos nuevo en la configuración del clúster:
#
pcs config showDeberías ver un resultado similar al siguiente:
Group: ilb-vip-group Resource: vip_hkn_00 (class=ocf provider=heartbeat type=IPaddr2) Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0 Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s) start interval=0s timeout=20s (vip_hkn_00-start-interval-0s) stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s) Resource: ilb-health-check (class=service type=haproxy) Operations: monitor interval=60 timeout=100 (ilb-health-check-monitor-interval-60) start interval=0s timeout=100 (ilb-health-check-start-interval-0s) stop interval=0s timeout=100 (ilb-health-check-stop-interval-0s)
Borra el recurso de alias:
#
pcs resource delete alias_resource_nameVerifica el estado del clúster:
#
pcs statusDeberías ver la sección Grupo de recursos en el resultado, que se parece al siguiente ejemplo:
STONITH-hana-ha-vm-1 (stonith:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22] Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Resource Group: g-primary rsc_healthcheck_HA1 (service:haproxy): Started hana-ha-vm-1 rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1
Quita el clúster del modo de mantenimiento:
#
pcs property set maintenance-mode=false
Prueba el clúster de HA actualizado
En la instancia de tu aplicación, confirma que puedes llegar a la base de datos mediante cualquiera de los siguientes comandos:
Como usuario
sidadm
:>
R3trans -dComo cualquier usuario:
telnet VIP HANA SQL port
o
nc -zv VIP HANA SQL port