Migra una VIP en un clúster con alta disponibilidad de RHEL 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 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.

  1. Abre Cloud Shell:

    Ir a Cloud Shell

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

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

    $ gcloud compute addresses describe VIP_NAME \
      --region CLUSTER_REGION

    Deberías ver un resultado similar al siguiente:

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

Crea grupos de instancias para tus VM host

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

    $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE
    $ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE \
      --instances=PRIMARY_HOST_NAME
    $ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE
    $ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE \
      --instances=SECONDARY_HOST_NAME
    
  2. Confirma la creación de los grupos de instancias:

    $ gcloud compute instance-groups unmanaged list

    Deberías ver un resultado similar al siguiente:

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

Crea una verificación de estado de Compute Engine

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

    $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
      --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
      --healthy-threshold=2
  2. Confirma la creación de la verificación de estado:

    $ gcloud compute health-checks describe HEALTH_CHECK_NAME

    Deberías ver un resultado similar al siguiente:

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

Crea una regla de firewall para las verificaciones de estado

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

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

    $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
      --tags NETWORK_TAGS \
      --zone PRIMARY_ZONE
    $ gcloud compute instances add-tags SECONDARY_HOST_NAME \
      --tags NETWORK_TAGS \
      --zone SECONDARY_ZONE
    
  2. Si aún no tienes una, crea una regla de firewall para permitir las verificaciones de estado:

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

    Por ejemplo:

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

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

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

    $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
      --load-balancing-scheme internal \
      --health-checks HEALTH_CHECK_NAME \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region CLUSTER_REGION \
      --global-health-checks
  2. Agrega el grupo de instancias principal al servicio de backend:

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --instance-group PRIMARY_IG_NAME \
      --instance-group-zone PRIMARY_ZONE \
      --region CLUSTER_REGION
  3. Agrega el grupo de instancias de conmutación por error secundario al servicio de backend:

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --instance-group SECONDARY_IG_NAME \
      --instance-group-zone SECONDARY_ZONE \
      --failover \
      --region CLUSTER_REGION
  4. Crea una regla de reenvío 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 de forma temporal en el puerto de verificación de estado.

  1. En ambas VMs del host, instala la utilidad socat:

    $ sudo yum install -y socat

  2. Inicia 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,fork

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

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

    Debería ver un resultado similar al siguiente:

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

Prueba el balanceador de cargas mediante el puerto 22

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

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

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

    Ir a la página Verificaciones de estado

  2. Haz clic en Editar.

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

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

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

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

    Debería ver un resultado similar al siguiente:

    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
    status:
     healthStatus:
     ‐ healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
       ipAddress: 10.0.0.35
       port: 80
     kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
    status:
     healthStatus:
     ‐ healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
       ipAddress: 10.0.0.34
       port: 80
     kind: compute#backendServiceGroupHealth
  6. Cuando termines, vuelve a cambiar el número de puerto de verificación de estado al número de puerto original.

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

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

  2. Como raíz en la instancia principal activa, coloca el clúster en modo de mantenimiento:

    $ pcs property set maintenance-mode="true"

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

  1. 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)"
  2. 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

  1. 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
  2. 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
  3. Borra la regla de reenvío temporal:

    $ gcloud compute forwarding-rules delete rule-name --region=cluster-region
  4. Libera 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

  1. Abre el archivo de configuración haproxy.cfg para editarlo:

    # vi /etc/haproxy/haproxy.cfg
    1. En la sección valores predeterminados de haproxy.cfg, cambia mode a tcp.

    2. 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
  2. En cada host como raíz, inicia el servicio para confirmar que esté configurado de forma correcta:

    # systemctl start haproxy.service
  3. En la página del balanceador de cargas en la consola de Google Cloud, haz clic en la entrada del balanceador de cargas:

    Página Balanceo 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.

    Captura de pantalla que muestra “1/1” en la columna En buen estado de ambos grupos de instancias, lo que indica que ambos están en buen estado.

  4. En cada host, detén el servicio HAProxy:

    # systemctl stop haproxy.service

    Despué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.

    La captura de pantalla muestra “0/1” en la columna En buen estado de cada grupo de instancias, lo que indica que no hay un objeto de escucha activo.

    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

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

  1. 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_name
  2. Crea 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_name

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

  3. Verifica el nombre del grupo de recursos nuevo en la configuración del clúster:

    # pcs config show

    Deberí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)
     
  4. Borra el recurso de alias:

    # pcs resource delete alias_resource_name
  5. Verifica el estado del clúster:

    # pcs status

    Deberí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
    

  6. 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 -d
  • Como cualquier usuario:

    telnet VIP HANA SQL port

    o

    nc -zv VIP HANA SQL port