Como migrar um VIP em um cluster de alta disponibilidade no SLES 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 SUSE Linux Enterprise Server (SLES) 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 SLES, o VIP será implementado com um IP de alias

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

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:

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

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

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. Você precisa instalar o utilitário socat mesmo assim, porque ele será usado mais tarde quando você configurar os recursos do cluster.

Nas duas VMs do host como raiz, instale o utilitário socat:
```
# zypper install -y socat
```
Inicie um processo socat para detectar por 60 segundos na porta de verificação de integridade:
```
# 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:
```
$ crm configure property maintenance-mode="true"
```

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

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

Editar o recurso VIP primitivo na configuração do cluster

Na instância principal como raiz, edite a definição do recurso VIP primitivo. Se o cluster foi criado pelos modelos do Deployment Manager fornecidos pelo Google Cloud, o nome do recurso VIP primitivo será rsc_vip_gcp-primary:
```
$ crm configure edit rsc_name
```
A definição do recurso é aberta em um editor de texto, como o "vi".
Faça as seguintes alterações no recurso VIP na configuração do cluster de alta disponibilidade do Pacemaker:
- Substitua a classe de recurso ocf:gcp:alias por anything.
- Altere o intervalo op monitor para interval=10s.
- Altere o tempo limite de op monitor para timeout=20s.
- Remover a definição da operação op start e op stop
- Remover meta priority=10
- Substitua os parâmetros do IP de alias:
```
alias_ip="10.0.0.10/32" hostlist="example-ha-vm1 example-ha-vm2" gcloud_path="/usr/bin/gcloud" logging=yes
```
  com parâmetros do serviço de verificação de integridade:
```
binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null"
```
Por exemplo, substitua as entradas em negrito no seguinte exemplo 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
```
Quando você terminar de editar, a definição de recurso do serviço de verificação de integridade será semelhante ao exemplo a seguir:
```
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"
```
No exemplo anterior, HC port é a porta de verificação de integridade que você especificou ao configurar o utilitário socat e criar a verificação de integridade.

Remova o cluster do modo de manutenção:

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

Como migrar um VIP em um cluster de alta disponibilidade no SLES 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

Editar o recurso VIP primitivo na configuração do cluster

Testar o cluster de alta disponibilidade atualizado

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