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 proporciona Google Cloud 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

La dirección VIP es la dirección especificada en el parámetro alias_ip=, como se muestra en el siguiente ejemplo:

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.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=10s

En Cloud Console confirma que esté reservada la dirección IP que se usa con la IP de alias:

$ 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 balanceo de cargas de TCP/UDP interno compatible 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. Esto ofrece protección en una configuración activa/pasiva y se puede extender para admitir una configuración activa/activa (secundaria con lectura habilitada).

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 las VM de tu host

  1. En Cloud Shell, crea dos grupos de instancias no administrados y asigna la VM del host principal a uno y la VM del host secundaria al otro:

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

    $ 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

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.

  1. En ambas VM host como raíz, instala la utilidad socat:

    # zypper install -y socat

  2. Inicia un proceso de socat para escuchar durante 60 segundos en el puerto de verificación de estado:

    # 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ías 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ías 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:

    $ crm configure property maintenance-mode="true"
  3. 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

  1. En Cloud Shell, confirma los rangos de IP de alias que están asignados a la instancia principal de SAP:

    $ gcloud compute instances describe \
        primary-host-name \
        --zone primary-zone \
        --format="flattened(name,networkInterfaces[].aliasIpRanges)"
  2. Actualiza la interfaz de red en Cloud Console. 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 Cloud Console, 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

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

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

  2. 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
    • 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 \
        op start interval=0 timeout=180s \
        op stop interval=0 timeout=180s \
        params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
        meta priority=10

    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.

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