Migra una VIP en un clúster de HA de SLES a un balanceador de cargas interno

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 SUSE Linux Enterprise Server (SLES) 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 SLES, tu VIP se implementará con una IP de alias.

En las siguientes instrucciones, se explica cómo migrar una VIP en un clúster de HA de SLES.

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:

$ crm 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:

primitive rsc_vip_gcp-primary ocf:gcp:alias \
        op monitor interval=60s timeout=60s \
        op start interval=0 timeout=600s \
        op stop interval=0 timeout=180s \
        params alias_ip="10.128.1.200/32" hostlist="ha1 ha2" gcloud_path="/usr/local/google-cloud-sdk/bin/gcloud" logging=yes \
        meta priority=10
primitive rsc_vip_int-primary IPaddr2 \
        params ip=10.128.1.200 cidr_netmask=32 nic=eth0 \
        op monitor interval=3600s timeout=60s

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:

Ir a 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_ADDRESS
```
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_REGION

Deberías ver un resultado similar al siguiente:

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

Crea grupos de instancias para tus VM host

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

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

Confirma la creación de los grupos de instancias:

$ gcloud compute instance-groups unmanaged list

Deberías ver un resultado similar al siguiente:

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

Crea una verificación de estado de Compute Engine

En Cloud Shell, crea la verificación de estado. Para el puerto que usa la verificación de estado, elige un puerto que esté en el rango privado, 49152-65535, a fin de evitar conflictos con otros servicios. Los valores de intervalo de verificación y tiempo de espera son un poco más largos que los valores predeterminados con el fin de aumentar la tolerancia a la conmutación por error durante los eventos de migración en vivo de Compute Engine. Puedes ajustar los valores si es necesario:
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

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

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

Deberías ver un resultado similar al siguiente:

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

Crea una regla de firewall para las verificaciones de estado

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

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

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

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

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

Por ejemplo:

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

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

Crea el servicio de backend del balanceador de cargas:

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

Agrega el grupo de instancias principal al servicio de backend:

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

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

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

Crea 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 ALL
```
Para obtener más información sobre el acceso entre regiones al sistema de alta disponibilidad de SAP HANA, consulta Balanceo de cargas de TCP/UDP interno.

Prueba la configuración del balanceador de cargas

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

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

Prueba el balanceador de cargas con la utilidad `socat`

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

En ambas VMs host como raíz, instala la utilidad socat:
```
# zypper install -y socat
```
Inicia un proceso socat para escuchar durante 60 segundos en el puerto de verificación de estado:
```
# timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

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

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

Debería ver un resultado similar al siguiente:

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

Prueba el balanceador de cargas mediante el puerto 22

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

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

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

Ir a la página Verificaciones de estado
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_REGION

Debería ver un resultado similar al siguiente:

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

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:
```
$ crm configure property maintenance-mode="true"
```
Realiza una copia de seguridad de la configuración del clúster:
```
$ crm configure 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)"
```
Nota: Actualizarás la interfaz de red de la instancia principal para quitar la IP de alias. Si hay varias IP de alias y necesitas conservar algunas, debes especificarlas en el comando que actualiza la interfaz de red. Se desasignará cualquier IP de alias que no se especifique en el comando de actualización.

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 ALL

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

Borra la regla de reenvío temporal:

$ gcloud compute forwarding-rules delete rule-name --region=cluster-region

Libera la dirección IP temporal que reservaste:

$ gcloud compute addresses delete temp-ip-name --region=cluster-region

Edita el recurso primitivo de la VIP en la configuración del clúster

En la instancia principal como raíz, edita la definición de recurso primitivo de VIP. Si el clúster se creó con las plantillas de Deployment Manager que proporciona Google Cloud, el nombre del recurso primitivo de VIP es rsc_vip_gcp-primary:
```
$ crm configure edit rsc_name
```
La definición de recursos se abre en un editor de texto, como vi.
Realiza los siguientes cambios en el recurso VIP en la configuración del clúster de HA de Pacemaker:
- Reemplaza la clase de recurso ocf:gcp:alias por anything
- Cambia el intervalo op monitor a interval=10s
- Cambia el tiempo de espera de op monitor a timeout=20s
- Quita las definiciones de las operaciones op start y op stop
- Quita meta priority=10
- Reemplaza los parámetros de IP de alias:
```
alias_ip="10.0.0.10/32" hostlist="example-ha-vm1 example-ha-vm2" gcloud_path="/usr/bin/gcloud" logging=yes
```
  por parámetros del servicio de verificación de estado:
```
binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null"
```
Por ejemplo, reemplaza las entradas en negrita en el siguiente ejemplo de IP de alias:
```
primitive rsc_vip_gcp-primary ocf:gcp:alias \
    op monitor interval=60s timeout=60s \
    op start interval=0 timeout=180s \
    op stop interval=0 timeout=180s \
    params alias_ip="10.0.0.10/32" hostlist="example-ha-vm1 example-ha-vm2" gcloud_path="/usr/bin/gcloud" logging=yes \
    meta priority=10
```
Cuando termines de editar, la definición de recurso del servicio de verificación de estado debería parecerse al siguiente ejemplo:
```
primitive rsc_vip_gcp-primary anything \
    op monitor interval=10s timeout=20s \
    params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null"
```
En el ejemplo anterior, HC port es el puerto de verificación de estado que especificaste cuando creaste la verificación de estado y configuraste la utilidad socat.

Quita el clúster del modo de mantenimiento:

$ crm configure property 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 -d
```

Como cualquier usuario:

telnet VIP HANA SQL port

nc -zv VIP HANA SQL port

Migra una VIP en un clúster de HA de SLES a un balanceador de cargas interno

Requisitos previos

Descripción general de los pasos

Confirma la dirección VIP existente

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

Reserva una dirección IP temporal para la IP virtual

Crea grupos de instancias para tus VM host

Crea una verificación de estado de Compute Engine

Crea una regla de firewall para las verificaciones de estado

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

Prueba la configuración del balanceador de cargas

Prueba el balanceador de cargas con la utilidad socat

Prueba el balanceador de cargas mediante el puerto 22

Migra la implementación de la VIP para usar el balanceador de cargas

Prepara el sistema para la edición

Cancela la asignación de la IP de alias

Crea la regla de reenvío de VIP y realiza una limpieza

Edita el recurso primitivo de la VIP en la configuración del clúster

Prueba el clúster de HA actualizado

Prueba el balanceador de cargas con la utilidad `socat`