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.

Abra o Cloud Shell:

Acessar o Cloud Shell
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.

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

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

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

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

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.

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

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

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

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

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

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

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.

Nas duas VMs do host, instale o utilitário socat:
```
$ sudo yum install -y socat
```
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
```

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:

Clique na verificação de integridade no console:

Acessar a página "Verificações de integridade"
Clique em Editar.
No campo Porta, altere o número da porta para 22.
Clique em Salvar e aguarde um ou dois minutos.

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

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

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.
Como raiz na instância principal ativa, coloque o cluster no modo de manutenção:
```
$ pcs property set maintenance-mode="true"
```
Faça backup da configuração do cluster:
```
$ pcs config show > clusterconfig.backup
```

Desalocar o IP de alias

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)"
```
Observação: você atualizará a interface de rede da instância principal para remover o IP de alias. Se houver vários IPs de alias, e você precisar manter algum deles, será necessário especificar os IPs de alias que você precisa manter no comando que atualiza a interface de rede. Todos os IPs de alias que não estão especificados no comando de atualização estarão desalocados.
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

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

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

Exclua a regra de encaminhamento temporária:

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

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

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

# vi /etc/haproxy/haproxy.cfg

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

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

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

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

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

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

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)

Exclua o recurso de alias:

# pcs resource delete alias_resource_name

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

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

nc -zv VIP HANA SQL port

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

Pré-requisitos

Visão geral das etapas

Confirmar o endereço VIP existente

Configurar o suporte a failover do Cloud Load Balancing

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

Criar grupos de instâncias para suas VMs de host

Criar uma verificação de integridade do Compute Engine

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

Configurar o balanceador de carga e o grupo de failover

Testar a configuração do balanceador de carga

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

Como testar o balanceador de carga usando a porta 22

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

Preparar o sistema para edição

Desalocar o IP de alias

Criar a regra de encaminhamento de VIP e fazer a limpeza

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

Instalar um listener

Criar o recurso de verificação de integridade

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

Testar o cluster de alta disponibilidade atualizado

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