Migrar um VIP em um cluster de alta disponibilidade do RHEL para um balanceador de carga interno

No Google Cloud, a maneira recomendada de implementar um endereço IP virtual (VIP, na sigla em inglês) em um cluster de alta disponibilidade (HA, na sigla em inglês) para SAP baseado em SO é usar o suporte a failover de um balanceador de carga TCP/UDP interno.

Se você tiver um cluster de alta disponibilidade para SAP do Red Hat Enterprise Linux (RHEL) no Google Cloud que usa um VIP implementado com um IP de alias, poderá migrar o VIP para usar um balanceador de carga interno.

Se você tiver usado o modelo sap_hana_ha do Deployment Manager, que não é mais compatível, para implantar um sistema de escalonamento vertical do SAP HANA em um cluster de alta disponibilidade no RHEL, o VIP será implementado com um IP de alias

Estas instruções mostram como migrar um VIP em um cluster de alta disponibilidade no RHEL.

Pré-requisitos

Para seguir as instruções, é necessário ter um cluster de alta disponibilidade configurado corretamente no Google Cloud que usa um IP de alias para a implementação do VIP.

Visão geral das etapas

  • Configure e teste um balanceador de carga usando uma regra de encaminhamento e um endereço IP temporários em vez do VIP.
  • Configure o cluster para o modo de manutenção e, se possível, interrompa as instâncias do servidor de aplicativos SAP para evitar um comportamento inesperado.
  • Desaloque o endereço IP de alias do host principal. Esse endereço se tornará o VIP no balanceador de carga.
  • Na configuração do cluster do Pacemaker, siga estas instruções:
    • Altere a classe do recurso VIP existente.
    • Substitua os parâmetros atuais do IP de alias pelos parâmetros do serviço de verificação de integridade.

Confirmar o endereço VIP existente

Como raiz, na instância de VM principal, exiba a configuração de cluster com base no IP de alias:

$ pcs configure show

Na definição do recurso, o intervalo de endereços VIP aparece nos recursos alias e IPaddr2. Se você precisar alterar o endereço VIP, será necessário atualizar os dois recursos. Veja o exemplo a seguir:

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)

No Console do Google Cloud, confirme se o endereço IP que está sendo usado com o IP do alias está reservado. Ele pode ser o endereço IP usado para o alias de alias ou ser um novo endereço IP.

$ gcloud compute addresses list --filter="region:( cluster-region )"

Se o endereço IP estiver reservado e alocado para a instância de VM principal, seu status será exibido como IN_USE. Ao realocar o IP para o balanceador de carga, primeiro você o desaloca da instância principal ativa. Nesse momento, o status dele mudará para RESERVED.

Se o endereço não estiver incluído nos endereços IP retornados pelo comando de listagem, reserve o endereço agora para evitar conflitos de endereço no futuro:

$ gcloud compute addresses create vip-name \
  --region cluster-region --subnet cluster-subnet \
  --addresses vip-address

Liste seus endereços novamente para confirmar que o endereço IP aparece como RESERVED.

Configurar o suporte a failover do Cloud Load Balancing

O serviço de balanceador de carga de rede interno de passagem com suporte a failover direciona o tráfego para o host ativo em um cluster do SAP HANA com base em um serviço de verificação de integridade.

Para evitar conflitos e permitir testes antes da conclusão da migração, crie uma regra de encaminhamento temporária com um endereço IP de marcador da mesma sub-rede que o endereço VIP. Quando tudo estiver pronto para mudar a implementação do VIP, você criará uma nova regra de encaminhamento final com o endereço VIP.

Reservar um endereço IP temporário para o IP virtual

O endereço VIP segue o sistema ativo do SAP HANA. O balanceador de carga encaminha o tráfego enviado ao VIP para a VM que está hospedando o sistema ativo do SAP HANA.

  1. Abra o Cloud Shell:

    Acessar o Cloud Shell

  2. Reserve um endereço IP temporário na mesma sub-rede que o IP de alias para fins de teste. Se você omitir a sinalização --addresses, um endereço IP será escolhido para você na sub-rede especificada:

    $ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS

    Para mais informações sobre como reservar um IP estático, consulte Como reservar um endereço IP interno estático.

  3. Confirmar reserva de endereço IP:

    $ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

    O resultado será semelhante a:

    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

Criar grupos de instâncias para suas VMs de host

  1. No Cloud Shell, crie dois grupos de instâncias não gerenciadas e atribua a VM do host mestre principal a um e a VM do host mestre secundário à outra:

    $ 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. Confirme a criação dos grupos de instâncias:

    $ gcloud compute instance-groups unmanaged list

    O resultado será semelhante a:

    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

Criar uma verificação de integridade do Compute Engine

  1. No Cloud Shell, crie a verificação de integridade. Para a porta usada pela verificação de integridade, escolha uma porta que esteja no intervalo privado 49152-65535 para evitar conflitos com outros serviços. Os valores de intervalo de verificação e tempo limite são um pouco mais longos do que os padrões para aumentar a tolerância de failover durante os eventos de migração em tempo real do Compute Engine. É possível ajustar os valores, se necessário:

    $ 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. Confirme a criação da verificação de integridade:

    $ gcloud compute health-checks describe HEALTH_CHECK_NAME

    O resultado será semelhante a:

    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

Criar uma regra de firewall para as verificações de integridade

Defina uma regra de firewall para uma porta no intervalo particular que permita o acesso às VMs do host a partir dos intervalos de IP usados pelas verificações de integridade do Compute Engine, 35.191.0.0/16 e 130.211.0.0/22. Para mais informações, consulte Como criar regras de firewall para verificações de integridade.

  1. Se você ainda não tiver uma tag de rede, adicione uma às suas VMs de host. Essa tag de rede é usada pela regra de firewall para verificações de integridade.

    $ 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. Se você ainda não tiver uma, crie uma regra de firewall para permitir as verificações de integridade:

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

    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

Configurar o balanceador de carga e o grupo de failover

  1. Crie o serviço de back-end do balanceador de carga:

    $ 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. Adicione o grupo de instâncias principal ao serviço de back-end:

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

  3. Adicione o grupo de instâncias de failover secundário ao serviço de back-end:

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

  4. Crie uma regra de encaminhamento temporária. Para o endereço IP, especifique o endereço IP temporário que você reservou para testes. Se você precisar acessar o sistema SAP HANA de fora da região especificada abaixo, inclua a sinalização --allow-global-access na definição:

    $ 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 mais informações sobre o acesso entre regiões ao sistema de alta disponibilidade do SAP HANA, consulte Balanceamento de carga TCP/UDP interno.

Testar a configuração do balanceador de carga

Mesmo que os grupos de instâncias de back-end não sejam registrados como íntegros até mais tarde, teste a configuração do balanceador de carga configurando um listener para responder às verificações de integridade. Depois de configurar um listener, se o balanceador de carga estiver configurado corretamente, o status dos grupos de instâncias de back-end será alterado para íntegro.

As seções a seguir apresentam métodos diferentes que podem ser usados para testar a configuração.

Como testar o balanceador de carga com o utilitário socat

É possível usar o utilitário socat para detectar temporariamente a porta de verificação de integridade.

  1. Nas duas VMs do host, instale o utilitário socat:

    $ sudo yum install -y socat

  2. Inicie um processo socat para detectar por 60 segundos na porta de verificação de integridade:

    $ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

  3. No Cloud Shell, depois de esperar alguns segundos pela verificação de integridade para detectar o listener, verifique a integridade dos grupos de instâncias de back-end:

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

    A resposta será semelhante a esta:

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

Como testar o balanceador de carga usando a porta 22

Se a porta 22 estiver aberta para conexões SSH nas VMs do host, será possível editar temporariamente o verificador de integridade para usar a porta 22, que tem um listener que pode responder ao verificador de integridade.

Para usar temporariamente a porta 22, siga estas etapas:

  1. Clique na verificação de integridade no console:

    Acessar a página "Verificações de integridade"

  2. Clique em Editar.

  3. No campo Porta, altere o número da porta para 22.

  4. Clique em Salvar e aguarde um ou dois minutos.

  5. No Cloud Shell, verifique a integridade dos grupos de instâncias de back-end:

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

    A resposta será semelhante a esta:

    ---
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. Quando terminar, altere o número da porta de verificação de integridade para o número original.

Migrar a implementação do VIP para usar o balanceador de carga

As etapas a seguir editam a configuração do cluster do Pacemaker e a regra de encaminhamento do balanceador de carga para concluir a migração do VIP.

Preparar o sistema para edição

  1. Se possível, pare a conexão do aplicativo SAP com o banco de dados SAP HANA, porque você interromperá a conexão rapidamente para trocar os endereços IP. Os processos de trabalho do NetWeaver podem se reconectar ao banco de dados, mas é possível que aconteçam falhas ou situações pendentes que a interrupção da conexão pode evitar. Verifique se o IP está registrado em um intervalo interno que faz parte da VPC na região de destino.

  2. Como raiz na instância principal ativa, coloque o cluster no modo de manutenção:

    $ pcs property set maintenance-mode="true"

  3. Faça backup da configuração do cluster:

    $ pcs config show > clusterconfig.backup

Desalocar o IP de alias

  1. No Cloud Shell, confirme os intervalos do IP de alias atribuídos à instância principal do SAP HANA:

    $ gcloud compute instances describe \
    primary-host-name \
    --zone primary-zone \
    --format="flattened(name,networkInterfaces[].aliasIpRanges)"

  2. No Console do Google Cloud, atualize a interface de rede. Se você não precisar manter nenhum IP de alias, especifique --aliases "":

    $ gcloud compute instances network-interfaces update primary-host-name \
--zone primary-zone \
--aliases "ip-ranges-to-retain"

Criar a regra de encaminhamento de VIP e fazer a limpeza

  1. No Console do Google Cloud, crie uma nova regra de encaminhamento de front-end para o balanceador de carga, especificando o endereço IP que foi usado anteriormente para o alias de IP como o endereço IP. Este é seu 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. Confirme a criação da regra de encaminhamento e anote o nome da regra de encaminhamento temporária para exclusão:

    $ gcloud compute forwarding-rules list

  3. Exclua a regra de encaminhamento temporária:

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

  4. Libere o endereço IP temporário que você reservou:

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

Instalar listeners e criar um recurso de verificação de integridade

Para configurar um recurso de verificação de integridade, é necessário instalar os listeners primeiro.

Instalar um listener

O balanceador de carga usa um listener na porta de verificação de integridade de cada host para determinar onde a instância principal do cluster do SAP HANA está sendo executada. 1. Como raiz na instância mestre nos sistemas primário e secundário, instale um listener TCP. Estas instruções instalam e usam o HAProxy como listener. 

# yum install haproxy

  1. Abra o arquivo de configuração haproxy.cfg para edição:

    # vi /etc/haproxy/haproxy.cfg

    1. Na seção padrões de haproxy.cfg, altere mode para tcp.

    2. Após a seção padrões, crie uma nova seção adicionando:

      #---------------------------------------------------------------------
# Health check listener port for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

      A porta de vinculação é a mesma que você usou quando criou a verificação de integridade.

      Quando terminar, suas atualizações serão semelhantes ao exemplo a seguir:

      #---------------------------------------------------------------------
# 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. Em cada host como raiz, inicie o serviço para confirmar se ele está configurado corretamente:

    # systemctl start haproxy.service

  3. Na página do balanceador de carga no Console do Google Cloud, clique na entrada do balanceador de carga:

    Página de balanceamento de carga

    Na seção Back-end da página Detalhes do balanceador de carga, se o serviço HAProxy estiver ativo nos dois hosts, você verá 1/1 na coluna Íntegra de cada entrada do grupo de instâncias.

    A captura de tela mostra "1/1" na coluna íntegra dos dois grupos de instâncias, indicando que ambos estão íntegros.

  4. Em cada host, interrompa o serviço HAProxy:

    # systemctl stop haproxy.service

    Depois que você interrompe o serviço HAProxy em cada host, o 0/1 é exibido na coluna íntegra de cada grupo de instâncias.

    A captura de tela mostra "0/1" na coluna íntegra de cada grupo de instâncias, indicando que não há listener ativo.

    Mais tarde, quando a verificação de integridade for configurada, o cluster reiniciará o listener no nó mestre.

Criar o recurso de verificação de integridade

  1. Em qualquer host como raiz, crie um recurso de verificação de integridade para o serviço HAProxy:

    # pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s

Edite a configuração do cluster para usar o recurso de verificação de integridade e remover o recurso de alias

  1. Remova o Colocation Constraints do grupo atual que contém o recurso de IP do alias mapeado para a instância principal do SAP HANA:

    # pcs constraint remove colocation-alias-vip-group-sap_hana_resource_name

  2. Crie um novo grupo de recursos que agrupe os recursos VIP e de verificação de integridade:

    # pcs resource group add rsc-group-namehealthcheck_resource_namevip_resource_name

    Este comando substitui o nome do grupo anterior dos recursos de IP e VIP do alias pelo novo nome do grupo de recursos na configuração do cluster.

  3. Verifique o novo nome do grupo de recursos na configuração do cluster:

    # pcs config show

    O resultado será semelhante a:

    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. Exclua o recurso de alias:

    # pcs resource delete alias_resource_name

  5. Verifique o status do cluster:

    # pcs status

    Você verá a seção "Grupo de recursos" na saída semelhante ao exemplo a seguir: 

    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. Remova o cluster do modo de manutenção:

    # pcs property set maintenance-mode=false

Testar o cluster de alta disponibilidade atualizado

A partir da instância do aplicativo, confirme se é possível acessar o banco de dados emitindo um dos seguintes comandos:

  • Como usuário do sidadm:

    > R3trans -d

  • Como qualquer usuário:

    telnet VIP HANA SQL port

    ou

    nc -zv VIP HANA SQL port