Esta página foi traduzida pela API Cloud Translation.

Guia de configuração de cluster de alta disponibilidade para SAP MaxDB no RHEL

Neste guia, mostramos como implantar um sistema SAP MaxDB em um cluster de alta disponibilidade do Red Hat Enterprise Linux (RHEL) no Google Cloud, com configuração de cluster ativo/passivo.

Para implantar um sistema SAP MaxDB de nó único no Linux, use o Guia de implantação do SAP MaxDB.

Este guia é destinado a usuários avançados do SAP MaxDB que conhecem as configurações de HA do Linux para sistemas SAP.

O sistema que este guia implanta

Este guia inclui as etapas de:

Como configurar um balanceador de carga de rede de passagem interno para redirecionar o tráfego em caso de falha
Como configurar um cluster do Pacemaker no RHEL para gerenciar os sistemas SAP e outros recursos durante um failover

O cluster implantado inclui as seguintes funções e recursos:

Duas VMs do Compute Engine em zonas diferentes, capazes de executar uma instância do SAP MaxDB
Um disco permanente regional para a instalação do SAP MaxDB.
O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
Um mecanismo de cercas STONITH.

Uma instalação de alta disponibilidade do SAP NetWeaver não é abordada neste guia.

Pré-requisitos

Antes de criar o cluster de alta disponibilidade do SAP MaxDB, verifique se os seguintes pré-requisitos são atendidos:

Você leu o Guia de planejamento do SAP MaxDB.
Você tem uma assinatura do Red Hat.
Você ou sua organização têm uma conta do Google Cloud e criaram um projeto para a implantação do SAP MaxDB.
Se você precisar que a carga de trabalho da SAP seja executada em conformidade com residência de dados, controle de acesso, equipes de suporte ou requisitos regulatórios, crie a pasta do Assured Workloads necessária. Para mais informações, consulte Controles soberanos e de conformidade para a SAP no Google Cloud.
Se o login do SO estiver ativado nos metadados do projeto, você precisará desativar o login do SO temporariamente até que a implantação seja concluída. Para fins de implantação, este procedimento configura chaves SSH em metadados de instâncias. Quando o login do SO é ativado, as configurações de chave SSH baseadas em metadados são desativadas e a implantação falha. Após a conclusão da implantação, ative o login do SO novamente.

Veja mais informações em:
- Como ativar ou desativar o Login do SO
- Adicionar chaves SSH a VMs que usam chaves SSH baseadas em metadados

Criar uma rede

Por motivos de segurança, crie uma nova rede. Para controlar quem tem acesso a ela, adicione regras de firewall ou use outro método de controle de acesso.

Caso o projeto tenha uma rede VPC padrão, não a use. Em vez disso, crie sua própria rede VPC para que as únicas regras de firewall aplicadas sejam aquelas criadas explicitamente por você.

Durante a implantação, as instâncias de VM geralmente exigem acesso à Internet para fazer o download do agente do Google Cloudpara SAP. Se você estiver usando uma das imagens Linux certificadas pela SAP disponíveis no Google Cloud, a instância da VM também exigirá acesso à Internet para registrar a licença e acessar repositórios de fornecedor do sistema operacional. Uma configuração com um gateway NAT e tags de rede da VM é compatível com esse acesso, mesmo se as VMs de destino não tiverem IPs externos.

Para configurar a rede:

Console

No console do Google Cloud , acesse a página Redes VPC.
Acessar redes VPC
Clique em Criar rede VPC.
Digite um Nome para a rede.
O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.
Em Modo de criação da sub-rede, escolha Custom.
Na seção Nova sub-rede, especifique os parâmetros de configuração a seguir para uma sub-rede:
1. Insira um Nome para a sub-rede.
2. Em Região, selecione a região do Compute Engine em que você quer criar a sub-rede.
3. Em Tipo de pilha de IP, selecione IPv4 (pilha única) e insira um intervalo de endereços IP no formato CIDR. , como 10.1.0.0/24.
  Esse é o intervalo principal de IPv4 da sub-rede. Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.
4. Clique em Concluído.
Para adicionar mais sub-redes, clique em Adicionar sub-rede e repita as etapas anteriores. É possível adicionar mais sub-redes à rede depois de criá-la.
Clique em Criar.

gcloud

Acesse o Cloud Shell.
Acesse o Cloud Shell
Para criar uma nova rede no modo de sub-redes personalizadas, execute:
```
gcloud compute networks create NETWORK_NAME --subnet-mode custom
```
Substitua NETWORK_NAME pelo nome da nova rede. O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.

Especifique --subnet-mode custom para evitar o uso do modo automático padrão, que cria automaticamente uma sub-rede em cada região do Compute Engine. Para mais informações, consulte Modo de criação da sub-rede.
Crie uma sub-rede e especifique a região e o intervalo de IP:
```
gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE
```
Substitua:
- SUBNETWORK_NAME: o nome da nova sub-rede.
- NETWORK_NAME: o nome da rede que você criou na etapa anterior;
- REGION: a região em que você quer a sub-rede;
- RANGE: o intervalo de endereços IP, especificado no formato CIDR. Por exemplo, 10.1.0.0/24
  Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.
Se quiser, repita o passo anterior e adicione mais sub-redes.

Como configurar um gateway NAT

Se você precisar criar uma ou mais VMs sem endereços IP públicos, será necessário usar a conversão de endereços de rede (NAT) para permitir que as VMs acessem a Internet. Use o Cloud NAT, um serviço gerenciado distribuído e definido por software do Google Cloud que permite que as VMs enviem pacotes de saída para a Internet e recebam todos os pacotes de resposta de entrada estabelecidos. Se preferir, é possível configurar uma VM separada como um gateway NAT.

Para criar uma instância do Cloud NAT para seu projeto, consulte Como usar o Cloud NAT.

Depois de configurar o Cloud NAT para seu projeto, as instâncias de VM poderão acessar a Internet com segurança sem um endereço IP público.

Como adicionar regras de firewall

Por padrão, uma regra de firewall implícita bloqueia conexões de entrada de fora da rede de nuvem privada virtual (VPC). Para permitir conexões de entrada, configure uma regra de firewall para sua VM. Depois que uma conexão de entrada for estabelecida com uma VM, será permitido o tráfego nas duas direções nessa conexão.

Também é possível criar uma regra de firewall para permitir o acesso externo a portas especificadas ou para restringir o acesso entre as VMs na mesma rede. Se o tipo de rede VPC default for usado, algumas regras padrão complementares também serão aplicadas, como a regra default-allow-internal, que permite a conectividade entre VMs na mesma rede em todas as portas.

Dependendo da política de TI que for aplicada ao ambiente, pode ser necessário isolar ou então restringir a conectividade com o host do banco de dados, o que pode ser feito criando regras de firewall.

Dependendo do seu cenário, é possível criar regras de firewall para permitir o acesso para estes itens:

Portas padrão do SAP listadas no TCP/IP de Todos os Produtos SAP.
Conexões do seu computador ou do ambiente de rede corporativa para a instância de VM do Compute Engine. Se você não tiver certeza do endereço IP a ser usado, fale com o administrador de redes da sua empresa.

Para criar uma regra de firewall:

Console

No console do Google Cloud , acesse a página Firewall do Compute Engine.

Acessar o Firewall
Na parte superior da página, clique em Criar regra de firewall.
- No campo Rede, selecione a rede em que a VM está localizada.
- No campo Destinos, especifique os recursos no Google Cloud a que essa regra se aplica. Por exemplo, especifique Todas as instâncias na rede. Ou, para limitar a regra a instâncias específicas no Google Cloud, insira tags em Tags de destino especificadas.
- No campo Filtro de origem, selecione uma das opções a seguir:
  - Intervalos de IP para permitir tráfego de entrada de endereços IP específicos. Especifique o intervalo de endereços IP no campo Intervalos de IPs de origem.
  - Sub-redes para permitir tráfego de entrada de uma determinada sub-rede. Especifique o nome da sub-rede no campo Sub-redes a seguir. É possível usar esta opção para permitir acesso entre as VMs na configuração em três níveis ou de escalonamento horizontal.
- Na seção Protocolos e portas, selecione Portas e protocolos especificados e insira tcp:PORT_NUMBER.
Clique em Criar para criar a regra de firewall.

gcloud

Crie uma regra de firewall usando o seguinte comando:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Implantar as VMs e instalar o MaxDB

Antes de começar a configurar o cluster de alta disponibilidade, defina e implante as instâncias de VM e os sistemas SAP MaxDB que servem como nós primário e secundário no cluster de alta disponibilidade.

Criar uma VM para implantação do MaxDB

Como parte da implantação de HA, é necessário criar duas VMs do Google Cloud Compute Engine. Consulte o guia Criar e iniciar uma instância do Compute Engine.

O disco permanente regional oferece suporte apenas aos tipos de máquina E2, N1, N2 e N2D. Confira mais detalhes no guia do disco permanente regional.

Consulte a Nota SAP 2456432: aplicativos SAP no Google Cloud: produtos compatíveis e Google Cloud tipos de máquina para selecionar o tipo de máquina certo com base no dimensionamento.

Crie as duas VMs em zonas separadas para alcançar a resiliência zonal, com os seguintes requisitos mínimos:

Detalhes da VM:
- Instance Name
- Zone: sua zona preferencial
- Machine Type: com base no dimensionamento
- Subnet: nome da sub-rede criada para essa região
Conta de serviço com pelo menos o escopo de acesso às seguintes APIs:
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/devstorage.read_write
Disco adicional em cada VM com no mínimo 20 GB para uso em /usr/sap

Criar um único disco regional para o SAP MaxDB

Para essa implantação, um disco regional será usado para armazenar os arquivos do MaxDB no diretório /sapdb.

Crie o disco, verificando se as zonas de replicação do disco regional correspondem às zonas em que você criou as duas VMs.

Anexe o disco regional a uma das VMs em que você vai realizar a instalação do MaxDB e as tarefas de configuração.

Preparar o RHEL OS para a instalação do SAP

O produto SAP exige a instalação de configurações e pacotes específicos do sistema operacional. Siga as diretrizes da Nota SAP 2772999: Red Hat Enterprise Linux 8.x: instalação e configuração (em inglês).

Essa tarefa precisa ser realizada nos dois nós.

Criar sistemas de arquivos

Conecte-se às duas instâncias usando SSH e crie os pontos de montagem /usr/sap/SID e /sapdb.
```
# sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb
```
Crie os sistemas de arquivos nos dois discos adicionais anexados às VMs usando mkfs.

Neste momento, o disco regional só será anexado a uma das VMs. Portanto, a criação do sistema de arquivos /sapdb será feita apenas uma vez.
Edite o arquivo /etc/fstab para montar sempre /usr/sap/SID na reinicialização nos dois nós.
Monte manualmente o sistema de arquivos /sapdb no nó em que você vai realizar a instalação do MaxDB.

Para mais referências sobre a criação e a montagem dos sistemas de arquivos, consulte o guia Formatar e ativar um disco que não é de inicialização em uma VM do Linux.

Modificar a configuração do LVM

É necessário modificar a configuração de gerenciamento de volume lógico (LVM) para que o grupo de volume compartilhado (VG, na sigla em inglês) seja sempre anexado e acessível por apenas um nó.

Para fazer isso, siga as etapas a seguir nos dois nós:

Como root, edite o arquivo /etc/lvm/lvm.conf e modifique o valor system_id_source para uname em none.

Verifique os resultados:

# grep -i system_id_source /etc/lvm/lvm.conf

O resultado será semelhante a este:

# Configuration option global/system_id_source.
        system_id_source = "uname"

Além disso, para impedir que as VMs ativem VGs gerenciadas pelo cluster quando um nó é reinicializado, mantenha o seguinte parâmetro no arquivo de configuração /etc/lvm/lvm.conf com nomes de VG completos separados por vírgulas que não são gerenciados pelo cluster.

Observação: por padrão, não há nenhum valor mantido neste arquivo. Portanto, é necessário navegar até a seção que descreve o uso do parâmetro auto_activation_volume_list e adicioná-lo manualmente.

Por exemplo, quando usrsap é um nome de VG que não é gerenciado pelo cluster:
```
auto_activation_volume_list = [ usrsap ]
```
Quando não há VGs que não são gerenciados pelo cluster, por exemplo, esse parâmetro precisa ser adicionado com valores vazios:
```
auto_activation_volume_list = [  ]
```

Como instalar o banco de dados e o agente de host da SAP

Agora que o sistema operacional está configurado, instale o banco de dados SAP MaxDB e o SAP Host Agent. O MaxDB normalmente é instalado com o produto SAP a que ele está integrado.

A instalação só será realizada uma vez, na instância em que você anexou o disco permanente regional.

Para instalar o SAP MaxDB na VM, faça o seguinte:

Estabeleça uma conexão SSH com a VM baseada em Linux.
Faça o download do SAP Software Provisioning Manager (SWPM), da mídia de instalação do produto SAP e da mídia de instalação do MaxDB, de acordo com os guias de instalação da SAP.
Instale o produto SAP e o banco de dados do SAP MaxDB de acordo com os guias de instalação da SAP para seu produto. Para receber mais orientações, consulte a documentação do SAP MaxDB (em inglês).

A SAP fornece mais informações sobre instalação na Nota SAP 1020175 - Perguntas frequentes: instalação, upgrade ou aplicação de um patch no SAP MaxDB.

Quando a instalação for concluída, execute as seguintes validações:

Como usuário do sidadm, verifique o status do MaxDB.

# dbmcli -d  SID -u control,password db_state

O resultado será semelhante a:

>dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE

Verifique também o status de x_server:

# x_server

O resultado será semelhante a:

>x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

Verifique se o SAP Host Agent está em execução:

# ps -ef | grep -i hostctrl

O resultado será semelhante a:

>ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

Depois que a instalação for verificada, interrompa a instância do MaxDB e o x_server.
```
# dbmcli -d SID -u control, and password db_offline
# x_server stop
```

Como realizar tarefas pós-instalação

Antes de usar sua instância do SAP MaxDB, é recomendável que você execute as seguintes etapas de pós-implantação:

Atualize seu software SAP MaxDB com os patches mais recentes, se disponíveis.
Instale quaisquer outros componentes.
Configure e faça o backup do seu novo banco de dados SAP MaxDB.

Para mais informações, consulte Administração do banco de dados do SAP MaxDB (em inglês).

Depois que os sistemas SAP MaxDB forem implantados, você definirá e configurará o cluster de alta disponibilidade.

Configurar o suporte a failover do Cloud Load Balancing

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

Reservar um endereço IP para o IP virtual

O endereço IP virtual (VIP), às vezes chamado de endereço IP flutuante, segue o sistema SAP MaxDB ativo. O balanceador de carga encaminha o tráfego enviado ao VIP para a VM que hospeda o sistema SAP MaxDB ativo.

Abra o Cloud Shell:

Acessar o Cloud Shell
Reserve um endereço IP para o IP virtual. Esse é o endereço IP que os aplicativos usam para acessar o SAP MaxDB. 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: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-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-maxdb-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 principal a um e a VM do host 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
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-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: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-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

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

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. No caso do endereço IP, especifique aquele que você reservou para o VIP. Se você precisar acessar o sistema SAP MaxDB de fora da região especificada abaixo, inclua a flag --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 MaxDB, 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/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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 de porta original.

Configurar o Pacemaker

O procedimento a seguir configura a implementação do Red Hat de um cluster do Pacemaker em VMs do Compute Engine para SAP MaxDB.

O procedimento é baseado na documentação do Red Hat para configurar clusters de alta disponibilidade, incluindo:

Como instalar e configurar um cluster de alta disponibilidade do Red Hat Enterprise Linux 7.6 (ou posterior) no Google Cloud

Instalar os agentes do cluster nos dois nós

Conclua as etapas a seguir nos dois nós.

Como raiz, instale os componentes do Pacemaker:
```
# yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y
```
Caso use uma imagem RHEL para SAP fornecida pelo Google, esses pacotes já estão instalados, mas algumas atualizações podem ser necessárias.
Defina a senha do usuário hacluster, que é instalado como parte dos pacotes:
```
# passwd hacluster
```
Especifique uma senha para hacluster nas solicitações.
Nas imagens do RHEL fornecidas pelo Google Cloud, o serviço de firewall do SO está ativo por padrão. Configure o serviço de firewall para permitir tráfego de alta disponibilidade:
```
# firewall-cmd --permanent --add-service=high-availability
```
```
# firewall-cmd --reload
```
Inicie o serviço de PCs e configure-o para iniciar no momento da inicialização:
```
# systemctl start pcsd.service
# systemctl enable pcsd.service
```

Verifique o status do serviço de PCs:

# systemctl status pcsd.service

A resposta será semelhante a esta:

● pcsd.service - PCS GUI and remote configuration interface
  Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
  Active: active (running) since Sat 2023-10-23 21:17:05 UTC; 25s ago
    Docs: man:pcsd(8)
          man:pcs(8)
Main PID: 31627 (pcsd)
  CGroup: /system.slice/pcsd.service
          └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
Oct 23 21:17:03 maxdb-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
Oct 23 21:17:05 maxdb-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Verifique se todos os serviços de HA necessários estão ativados e funcionando nos dois nós.
```
# systemctl enable pcsd.service pacemaker.service corosync.service
```

No arquivo /etc/hosts, adicione o nome de host completo e os endereços IP internos dos dois hosts no cluster. Exemplo:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.40 maxdb-ha-vm-1.us-central1-a.c.example-project-123456.internal maxdb-ha-vm-1  # Added by Google
10.0.0.41 maxdb-ha-vm-2.us-central1-c.c.example-project-123456.internal maxdb-ha-vm-2
169.254.169.254 metadata.google.internal  # Added by Google

Para mais informações do Red Hat sobre como configurar o arquivo /etc/hosts nos nós do cluster RHEL, consulte https://access.redhat.com/solutions/81123.

Crie o cluster

Como raiz em um dos nós, autorize o usuário hacluster. Clique na guia da versão do RHEL para ver o comando:
RHEL 8 e versões mais recentes
```
# pcs host auth primary-host-name secondary-host-name
```
RHEL 7
```
# pcs cluster auth primary-host-name secondary-host-name
```
Nas solicitações, digite o nome de usuário hacluster e a senha que você definiu para o usuário hacluster.

Crie o cluster:

RHEL 8 e versões mais recentes

# pcs cluster setup cluster-name primary-host-name secondary-host-name

RHEL 7

# pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Editar as configurações padrão corosync.conf

Edite o arquivo /etc/corosync/corosync.conf no host principal para definir um ponto de partida mais apropriado para testar a tolerância a falhas do cluster de alta disponibilidade no Google Cloud.

Nos dois hosts, use o editor de texto que preferir para abrir o arquivo /etc/corosync/corosync.conf para edição:
```
# /etc/corosync/corosync.conf
```
Se /etc/corosync/corosync.conf for um novo arquivo ou estiver em branco, será possível verificar o diretório /etc/corosync/ para ver um arquivo de exemplo a ser usado como base para o arquivo rosync.
Na seção totem do arquivo corosync.conf, adicione as seguintes propriedades com os valores sugeridos, como mostrado na versão do RHEL:
RHEL 8 e versões mais recentes
- transport: knet
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Exemplo:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
RHEL 7
- transport: udpu
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Exemplo:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
No host com o arquivo corosync.conf editado, sincronize a configuração do corosync em todo o cluster:
RHEL 8 e versões mais recentes
```
# pcs cluster sync corosync
```
RHEL 7
```
# pcs cluster sync
```

Configure o cluster a ser iniciado automaticamente:

# pcs cluster enable --all

# pcs cluster start --all

Confirme se as novas configurações do corosync estão ativas no cluster por meio do utilitário corosync-cmapctl:
```
# corosync-cmapctl
```

Configurar o isolamento

As imagens RHEL fornecidas pelo Google Cloud incluem um agente de isolamento fence_gce específico para Google Cloud. Use fence_gce para criar dispositivos de isolamento para cada VM de host.

Para garantir a sequência correta de eventos após uma ação de isolamento, configure também o sistema operacional para atrasar a reinicialização do Corosync depois que uma VM for isolada. Ajuste também o tempo limite do Pacemaker para reinicializações para considerar o atraso.

Para ver todas as opções disponíveis com o agente de isolamento fence_gce, emita fence_gce -h.

Criar os recursos do dispositivo de isolamento

No host principal como raiz:

Crie um dispositivo de isolamento para cada VM do host:

# pcs stonith create primary-fence-name fence_gce \
  port=primary-host-name \
  zone=primary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

Restrinja cada dispositivo de isolamento à outra VM do host:

# pcs constraint location primary-fence-name avoids primary-host-name
# pcs constraint location secondary-fence-name avoids secondary-host-name

No host principal como raiz, teste o dispositivo de isolamento secundário:
1. Encerre a VM do host secundário:
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  Se o comando for bem-sucedido, você perderá a conectividade com a VM do host secundário e ela aparecerá interrompida na página Instâncias de VM no console do Google Cloud . Talvez seja necessário atualizar a página.
2. Reinicie a VM do host secundário:
```
# fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
```
No host secundário como raiz, teste o dispositivo de isolamento primário repetindo as etapas anteriores e usando os valores do host principal nos comandos.

Em qualquer host como raiz, verifique o status do cluster:

# pcs status

Os recursos de isolamento aparecem na seção de recursos do status do cluster, semelhante ao exemplo a seguir:

[root@maxdb-ha-vm-2 ~]# pcs status
Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Mon Jun 15 17:19:07 2020
Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on maxdb-ha-vm-1

2 nodes configured
2 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

 STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
 STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Definir um atraso para a reinicialização do Corosync

Em ambos os hosts como raiz, crie um arquivo drop-in systemd que atrase a inicialização do Corosync para garantir a sequência adequada de eventos após a reinicialização de uma VM isolada:
```
systemctl edit corosync.service
```
Adicione as seguintes linhas ao arquivo:
```
[Service]
ExecStartPre=/bin/sleep 60
```
Salve o arquivo e saia do editor.
Atualize a configuração do gerenciador systemd.
```
systemctl daemon-reload
```

Confirme se o arquivo drop-in foi criado:

service corosync status

Você verá uma linha para o arquivo drop-in, conforme mostrado no exemplo abaixo:

● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/corosync.service.d
           └─override.conf
   Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

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 do MaxDB está sendo executada.

Como raiz nos dois hosts, 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 tcplog.

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

#---------------------------------------------------------------------
# Health check listener port for SAP MaxDB 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 MaxDB 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 , 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ó ativo.

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 —-group SAPMaxDB_Group

Confirme se o serviço de verificação de integridade está ativo no mesmo host que a instância do SAP MaxDB:
```
# pcs status
```
Se o recurso de verificação de integridade não estiver no mesmo host que o MaxDB, mova-o com o seguinte comando:
```
# pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name
```
O comando pcs resource clear deixa o recurso no novo local, mas remove a restrição de local indesejada que o comando pcs resource move criou.

No status, a seção de recursos deve ser semelhante ao exemplo a seguir:
```
Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1
```

Definir os padrões do cluster

Configure os limites de migração e a permanência para determinar o número de failovers a serem tentados antes da falha e configure o sistema para tentar reiniciar no host atual primeiro. Isso só precisa ser definido em um nó para aplicar ao cluster.

Como raiz em qualquer um dos hosts, defina os padrões do recurso:
```
# pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000
```
A propriedade resource-stickiness controla a probabilidade de um serviço permanecer em execução onde ele está. Valores mais altos tornam o serviço mais fixo. Um valor de 1000 significa que o serviço é muito fixo.

A propriedade migration-threshold especifica o número de falhas que precisam ocorrer antes da falha de um serviço para outro host. Um valor de 5.000 é alto o suficiente para evitar o failover em situações de erro de curta duração.

Para verificar os padrões do recurso, digite pcs resource defaults.
Defina os padrões de tempo limite da operação de recursos:
```
# pcs resource op defaults timeout=600s
```
Para verificar os padrões do recurso, digite pcs resource op defaults.
Defina as seguintes propriedades do cluster:
```
# pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"
```
É possível verificar as configurações da propriedade com pcs property list.

Criar recursos do MaxDB no cluster

Antes de realizar essas etapas, verifique se o MaxDB e o x_server estão interrompidos e se o sistema de arquivos /sapdb está desconectado.

Criar o recurso gcp-pd-move

O recurso gcp-pd-move é um agente de recurso usado para mover o disco permanente de um nó para outro durante um failover de cluster.

Crie o recurso usando o seguinte comando como raiz em qualquer nó:

# pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

Criar recurso LVM

Um agente de recurso ativado por LVM é usado para ativar o LVM depois que o disco é movido para o outro nó.

Crie o recurso LVM usando o seguinte comando como raiz em qualquer nó:

# pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

Exemplo:

# pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

Criar o recurso do sistema de arquivos

O recurso do sistema de arquivos é usado no cluster para desmontar /sapdb e montar em outro nó durante a operação de failover.

Crie o recurso do sistema de arquivos usando o seguinte comando como raiz em qualquer nó:

# pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

Exemplo:

# pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

Preparações para o grupo de recursos do MaxDB

Para ativar o grupo de recursos do MaxDB, siga estas etapas.

Sincronize usuários e grupos do nó em que você realizou a instalação do MaxDB com o outro nó.
1. Os usuários do SAP MaxDB precisam ser sincronizados entre os nós copiando as entradas em /etc/passwd, por exemplo:
```
 sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh
```
2. Da mesma forma, os grupos do SAP também precisam ser sincronizados, copiando as entradas em /etc/group de um nó para o outro, por exemplo:
```
 dba:x:1003:mdbadm
 sapsys:x:1005:
```

Sincronize arquivos específicos do MaxDB que são armazenados nos diretórios do sistema operacional. Como usuário raiz, execute os seguintes comandos:

# rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/

# MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

Para os usuários do SO SAP no segundo nó, renomeie os seguintes arquivos de ambiente para usar o respectivo nome de host nos diretórios iniciais, por exemplo:

mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

O agente de recursos SAPDatabase não usa comandos específicos do banco de dados para interromper ou iniciar o banco de dados, mas depende de comandos saphostctrl para fazer isso. O SAP Host Agent exige que as entradas xuser sejam criadas para monitoramento e controle bem-sucedidos do MAXDB usando saphostctrl. Consulte a Nota SAP 2435938: SAP Host Agent SAP MaxDB: DBCredentials for DB connect para mais informações.

Como raiz, execute o comando a seguir para SetDatabaseProperty no nó ativo:

/usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Teste as entradas usando o comando a seguir, mesmo que o banco de dados esteja interrompido. O comando poderá recuperar o status:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

O comando do agente saphostctrl usa o programa xuser da instalação do MaxDB e, portanto, para preparar o segundo nó agora, você move o SAPMaxDB_group para maxdb-node-b.

Em qualquer nó, execute o seguinte comando como root:
```
pcs resource move SAPMaxDB_group
```

Os quatro recursos criados, verificação de integridade, gcp-pd-move, LVM e sistema de arquivos foram migrados e iniciados no segundo nó.

É possível usar o seguinte comando em qualquer nó para observar as ações realizadas:
```
watch pcs status
```

Depois que os quatro recursos forem iniciados no segundo nó, execute o comando saphostctrl.

Como raiz, execute o comando a seguir para SetDatabaseProperty no nó ativo:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

No nó b, inicie manualmente o MaxDB e o x_server para verificar se eles podem ser iniciados corretamente:
```
# dbmcli -d SID -u control, and password db_online
# x_server start
```

Siga para a próxima etapa de criação de um recurso para o banco de dados SAP. Se houver algum erro nesse ponto, não crie o recurso de banco de dados.

Criar recurso para o SAP MaxDB

O Pacemaker do RHEL usa o agente de recursos do banco de dados SAP para monitorar e controlar o banco de dados SAP.

Crie o recurso de banco de dados no nó em que o SAPMaxDB_group está ativo usando o seguinte comando:

# pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

Os recursos finais do cluster podem ser vistos usando pcs status, e o resultado esperado é o seguinte:

# pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

  Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

  Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Testar o failover

Para testar seu cluster, simule uma falha no host ativo. Use um sistema de teste ou execute o teste no sistema de produção antes de liberar o sistema para uso.

Faça backup do sistema antes do teste.

É possível simular uma falha de várias maneiras, incluindo:

Interromper manualmente o MaxDB ou o x_server
Encerrar o processo MaxDB ou x_server
reboot (no nó ativo)
ip link set eth0 down para instâncias com uma única interface de rede
iptables ... DROP para instâncias com várias interfaces de rede
echo c > /proc/sysrq-trigger

Nestas instruções, ip link set eth0 down ou iptables são usados para simular uma interrupção de rede entre os dois hosts no cluster. Use o comando ip link em uma instância com uma única interface de rede e iptables em instâncias com uma ou mais interfaces de rede. O teste valida o failover e o isolamento. Quando as instâncias têm várias interfaces de rede definidas, use o comando iptables no host secundário para descartar o tráfego de entrada e de saída com base no IP usado pelo host principal para o cluster de comunicação, simulando uma perda de conexão de rede com a instância principal.

No host ativo, como raiz, coloque a interface de rede off-line:
```
# ip link set eth0 down
```
Reconecte-se ao host usando o SSH e mude para o usuário raiz

Digite pcs status para confirmar que o host anteriormente passivo agora tem o disco persistente regional anexado e está executando os serviços do MaxDB. A reinicialização automática está ativada no cluster. Portanto, o host parado será reiniciado e assumirá a função de host passivo, conforme mostrado no exemplo a seguir:

Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Resolver problemas

Para resolver problemas com as configurações de alta disponibilidade para sistemas SAP no RHEL, consulte Como resolver problemas de configurações de alta disponibilidade para SAP.

Receber suporte para o SAP HANA no RHEL

Se você precisar de ajuda para resolver um problema com clusters de alta disponibilidade do SAP HANA no RHEL, colete as informações de diagnóstico necessárias e entre em contato com o Cloud Customer Care. Para mais informações, consulte Clusters de alta disponibilidade em informações de diagnóstico do RHEL.

Guia de configuração de cluster de alta disponibilidade para SAP MaxDB no RHEL

O sistema que este guia implanta

Pré-requisitos

Criar uma rede

Console

gcloud

Como configurar um gateway NAT

Como adicionar regras de firewall

Console

gcloud

Implantar as VMs e instalar o MaxDB

Criar uma VM para implantação do MaxDB

Criar um único disco regional para o SAP MaxDB

Preparar o RHEL OS para a instalação do SAP

Criar sistemas de arquivos

Modificar a configuração do LVM

Como instalar o banco de dados e o agente de host da SAP

Como realizar tarefas pós-instalação

Configurar o suporte a failover do Cloud Load Balancing

Reservar um endereço IP 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

Configurar o Pacemaker

Instalar os agentes do cluster nos dois nós

Crie o cluster

RHEL 8 e versões mais recentes

RHEL 7

RHEL 8 e versões mais recentes

RHEL 7

Editar as configurações padrão corosync.conf

RHEL 8 e versões mais recentes

RHEL 7

RHEL 8 e versões mais recentes

RHEL 7

Configurar o isolamento

Criar os recursos do dispositivo de isolamento

Definir um atraso para a reinicialização do Corosync

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

Instalar um listener

Criar o recurso de verificação de integridade

Definir os padrões do cluster

Criar recursos do MaxDB no cluster

Criar o recurso gcp-pd-move

Criar recurso LVM

Criar o recurso do sistema de arquivos

Preparações para o grupo de recursos do MaxDB

Criar recurso para o SAP MaxDB

Testar o failover

Resolver problemas

Receber suporte para o SAP HANA no RHEL

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