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

Neste guia, mostramos como implantar e configurar um cluster de alta disponibilidade (HA, na sigla em inglês) do Red Hat Enterprise Linux (RHEL) otimizado para desempenho para o sistema SAP NetWeaver.

Exceto para os procedimentos específicos do servidor 2 da fila independente (ENSA2, na sigla em inglês), que está disponível apenas no ABAP, este guia se aplica às pilhas ABAP e Java SAP SAP.s

A menos que uma exceção seja indicada no guia, os exemplos que usam "ASCS" são válidos para os serviços centrais do SAP (ABCS) e o SAP Central para Java (SCS).

Se você estiver usando uma pilha Java, antes de usar os exemplos deste guia, substitua todas as instâncias de "ASCS" por "SCS".

Este guia inclui as etapas de:

• Como configurar um balanceador de carga de rede de passagem interna 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.

Este guia também inclui etapas para configurar o sistema SAP NetWeaver para alta disponibilidade, mas consulte a documentação do SAP para ver as instruções definitivas.

Para informações sobre como implantar VMs do Compute Engine para SAP NetWeaver não específicas para alta disponibilidade, consulte o Guia de implantação do SAP NetWeaver específico do seu sistema operacional.

Para configurar um cluster de alta disponibilidade para SAP OpenGL no SUSE Linux Enterprise Server (SLES), consulte o guia de configuração manual do cluster de alta disponibilidade para SAP OpenGL no SLES.

Este guia é destinado a usuários avançados do SAP NetWeaver familiarizados com as configurações de alta disponibilidade do Linux para SAP HANA.

O sistema que este guia implanta

Seguindo este guia, você implantará duas instâncias do SAP HANA e configurará um cluster de alta disponibilidade no RHEL. Implante cada instância do SAP NetWeaver em uma VM do Compute Engine em uma zona diferente na mesma região. Uma instalação de alta disponibilidade do banco de dados subjacente não é abordada neste guia.

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

• Duas VMs de host, uma para a instância ASCS ativa e outra para a instância ativa do ENSA2 Enqueue Replicator ou o ENSA1 Enen Replication Server (ENSA1). As instâncias ENSA2 e ENSA1 são chamadas de ERS.
• O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
• Um mecanismo de cercas STONITH.
• Reinicialização automática da instância com falha como nova instância secundária

Neste guia, você usa os modelos do Cloud Deployment Manager fornecidos pelo Google Cloud para implantar as máquinas virtuais (VMs) do Compute Engine, garantindo que elas atendam aos requisitos de suporte do SAP e estejam em conformidade com os melhores requisitos atuais.

Para usar o Terraform a fim de automatizar a implantação de sistemas de alta disponibilidade do SAP NetWeaver, consulte o artigo Terraform: guia de configuração de cluster de HA para SAP NetWeaver no RHEL.

Pré-requisitos

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

• Você leu o Guia de planejamento do SAP NetWeaver e o Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud.
• Você ou sua organização tem uma conta do Google Cloud e criou um projeto para a implantação do SAP NetWeaver. Para informações sobre como criar contas e projetos do Google Cloud, consulte Como criar um projeto no Guia de implantação do SAP NetWeaver para Linux.
• 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 você estiver usando o DNS interno da VPC, o valor da variável vmDnsSetting nos metadados do projeto precisará ser GlobalOnly ou ZonalPreferred para ativar a resolução dos nomes de nó nas zonas. A configuração padrão de vmDnsSetting é ZonalOnly. Para mais informações, consulte estes tópicos:

  • Como configurar nomes DNS para projetos ou instâncias
  • Como consultar metadados personalizados
  • Como definir metadados personalizados de projeto

• Você configurou um compartilhamento de arquivos usando uma solução de armazenamento de arquivos compartilhados NFS, como o Filestore Enterprise.

• 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

Para evitar a exposição não intencional da instância de VM à Internet, siga estas recomendações:

• Use um gateway NAT.
• Crie regras de firewall que impeçam todo o acesso externo não solicitado.
• Ao criar as VMs:
  • Especifique uma tag de rede para cada uma delas, que seja usada em regras de roteamento e de firewall. Se você usar os modelos do Deployment Manager fornecidos pelo Google Cloud, especifique uma tag com networkTag: [TAG].
  • Crie as VMs sem um IP externo. Se você usar os modelos do Deployment Manager fornecidos pelo Google Cloud, especifique publicIP: No.

Informações relacionadas do RHEL

Exceto quando necessário para o ambiente do Google Cloud, as informações deste guia são consistentes com os seguintes guias relacionados da Red Hat e da SAP:

• Configurar o SAP OpenGL ASCS/ERS ENSA1 com recursos autônomos no RHEL 7.5+ e RHEL 8
• Configurar o SAP S/4HANA ASCS/ERS com o servidor de fila independente 2 (ENSA2) no Pacemaker
• Nota SAP 2002167 - Red Hat Enterprise Linux 7.x: instalação e upgrade (em inglês)
• Nota SAP 2772999 - Red Hat Enterprise Linux 8.x: instalação e configuração (em inglês)
• Nota SAP 2772999 - Red Hat Enterprise Linux 8.x: instalação e configuração
• Nota SAP 2641322: instalação do ENSA2 e atualização do ENSA1 para o ENSA2 ao usar as soluções de HA do Red Hat para SAP (em inglês)

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 normalmente exigem acesso à Internet para fazer o download do agente do Google Cloud para SAP. Se você estiver usando uma das imagens Linux certificadas pelo 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

1. No Console do Google Cloud, acesse a página Redes VPC.

   Acessar redes VPC

2. Clique em Criar rede VPC.
3. 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.

4. Em Modo de criação da sub-rede, escolha Custom.
5. 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.
6. 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.
7. Clique em Criar.

gcloud

1. Acesse o Cloud Shell.

   Acesse o Cloud Shell

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

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

4. 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 pelo 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.

Ponto-chave: ao configurar o Cloud NAT, especifique pelo menos 160 como o número mínimo de portas por VM. Algumas atualizações de sistema operacional executam processos simultâneos que podem exceder o padrão do Cloud NAT para o número de portas, o que pode resultar em erros de ativação ou download.

Ao criar uma instância do Cloud NAT, especifique o número de portas no campo Mínimo de portas por VM em Configurações avançadas na página "Criar um gateway NAT" no console do Google Cloud.

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, as conexões recebidas de fora da rede do Google Cloud são bloqueadas. Para permiti-las, configure uma regra de firewall na sua VM. As regras de firewall regulam apenas novas conexões de entrada para uma VM. Depois que uma conexão é estabelecida com uma VM, o tráfego é permitido em ambas as direções nessa conexão.

É possível criar uma regra de firewall para permitir acesso a portas especificadas ou entre VMs na mesma sub-rede.

Crie regras de firewall para permitir acesso, por exemplo:

• às portas padrão usadas pelo SAP NetWeaver, conforme documentado em Portas TCP/IP de todos os produtos SAP (em inglês);
• das conexões do seu computador ou ambiente de rede corporativa com a instância de VM do Compute Engine. Se você não tiver certeza de qual endereço IP usar, fale com o administrador da rede da empresa;
• à comunicação entre VMs em uma configuração de três níveis, de escalonamento horizontal ou de alta disponibilidade. Por exemplo, se você estiver implantando um sistema em três níveis, terá, pelo menos, duas VMs na sub-rede: uma para o SAP NetWeaver e outra para o servidor de banco de dados. Para ativar a comunicação entre as duas VMs, crie uma regra de firewall para permitir o tráfego da sub-rede.
• Verificações de integridade do Cloud Load Balancing. Para mais informações, consulte Criar uma regra de firewall para verificações de integridade.

Observação: o procedimento a seguir é uma versão simplificada das instruções de criação de regras de firewall. Para instruções mais detalhadas, consulte a documentação da nuvem privada virtual.

Para criar uma regra de firewall:

1. No console do Google Cloud, acesse a página Firewall da rede VPC.

   Acessar o Firewall

2. 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, selecione Todas as instâncias na rede.
   • No campo Filtro de origem, selecione uma das opções a seguir:
     • Intervalos de IPs, 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 sub-rede específica. Especifique o nome da sub-rede no campo Sub-redes a seguir. É possível usar essa 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 especifique tcp:PORT_NUMBER;.

3. Clique em Criar para criar a regra de firewall.

Como implantar as VMs para SAP NetWeaver

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

Para definir e implantar as VMs, use o mesmo modelo do Cloud Deployment Manager usado na implantação de uma VM em um sistema SAP NetWeaver na implantação automatizada da VM para SAP NetWeaver no Linux.

No entanto, para implantar duas VMs em vez de uma, é necessário adicionar a definição da segunda VM ao arquivo de configuração copiando e colando a definição da primeira VM. Depois de criar a segunda definição, você precisa alterar os nomes dos recursos e das instâncias na segunda definição. Para se proteger contra uma falha zonal, especifique uma zona diferente na mesma região. Todos os outros valores de propriedade nas duas definições permanecem os mesmos.

Depois que as VMs forem implantadas, você instalará o SAP NetWeaver e definirá e configurará o cluster de alta disponibilidade.

As instruções a seguir usam o Cloud Shell, mas geralmente são aplicáveis à Google Cloud CLI.

1. Abra o Cloud Shell.

   Acessar o Cloud Shell

2. Faça o download do modelo do arquivo de configuração YAML, template.yaml, para o diretório de trabalho:

   wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml

3. Você tem a opção de renomear o arquivo template.yaml para identificar a configuração que ele define. Por exemplo, nw-ha-rhel-8-4.yaml.

4. Abra o arquivo de configuração YAML no editor de código do Cloud Shell clicando no ícone de lápis () no canto superior à direita da janela do terminal do Cloud Shell para iniciar o editor.

5. No modelo do arquivo de configuração YAML, defina a primeira instância de VM. Você definirá a segunda instância de VM na próxima etapa após a tabela a seguir.

   Especifique os valores da propriedade substituindo os colchetes e o conteúdo pelos valores da instalação. As propriedades estão descritas na tabela a seguir. Para um exemplo de um arquivo de configuração concluído, consulte Exemplo de um arquivo de configuração YAML completo.

   Propriedade	Tipo de dados	Descrição
   name	String	Um nome arbitrário que identifica o recurso de implantação que o seguinte conjunto de propriedades define.
   type	String	Especifica o local, o tipo e a versão do modelo do Deployment Manager a ser usado durante a implantação. O arquivo YAML inclui duas especificações type, uma delas comentada. A especificação type que está ativa por padrão especifica a versão do modelo como latest. A especificação type comentada especifica uma versão de modelo específica com carimbo de data/hora. Se você precisar que todas as suas implantações usem a mesma versão de modelo, use a especificação type que inclui o carimbo de data/hora.
   instanceName	String	O nome da instância de VM que você está definindo. Especifique nomes diferentes nas definições das VMs principal e secundária. Avalie o uso de nomes que identificam as instâncias como pertencentes ao mesmo cluster de alta disponibilidade. Os nomes das instâncias precisam ter até 13 caracteres e ser especificados em letras minúsculas, números ou hifens. Use um nome exclusivo no projeto.
   instanceType	String	O tipo de VM do Compute Engine necessário. Especifique o mesmo tipo de instância para as VMs principal e secundária. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido pequeno e, após o término da implantação, personalize a VM conforme necessário.
   zone	String	A zona do Google Cloud em que a instância da VM que você está definindo será implantada. Especifique zonas diferentes na mesma região para as definições de VM principal e secundária. As zonas precisam estar na mesma região selecionada para a sub-rede.
   subnetwork	String	O nome da sub-rede criada em uma etapa anterior. Se estiver implantando em uma VPC compartilhada, especifique esse valor como SHAREDVPC_PROJECT/SUBNETWORK. Por exemplo, myproject/network1.
   linuxImage	String	O nome da família de imagens ou da imagem do sistema operacional Linux que está sendo usada com o SAP NetWeaver. Para especificar uma família de imagens, adicione o prefixo family/ ao nome da família. Por exemplo, family/rhel-8-4-sap-ha: Para ver a lista de famílias de imagens disponíveis, consulte a página Imagens no console do Google Cloud.
   linuxImageProject	String	O projeto do Google Cloud que contém a imagem que você usará. Ele pode ser seu próprio projeto ou o projeto de imagem do Google Cloud rhel-sap-cloud. Para uma lista de projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.
   usrsapSize	Número inteiro	O tamanho do disco /usr/sap. O tamanho mínimo é 8 GB.
   sapmntSize	Número inteiro	O tamanho do disco /sapmnt. O tamanho mínimo é 8 GB.
   swapSize	Número inteiro	O tamanho do volume de troca. O tamanho mínimo é de 1 GB.
   networkTag	String	Opcional. Uma ou mais tags de rede separadas por vírgula que representam a instância da VM para fins de roteamento ou firewall. Para configurações de alta disponibilidade, especifique uma tag de rede a ser usada em uma regra de firewall que permita a comunicação entre os nós do cluster, e uma tag de rede a ser usada em uma regra de firewall que permita que as verificações de integridade do Cloud Load Balancing acessem os nós do cluster. Se você especificar publicIP: No e não inserir uma tag de rede, forneça outro meio de acesso à Internet.
   serviceAccount	String	Opcional. Especifica uma conta de serviço personalizada a ser usada para a VM implantada. A conta de serviço precisa incluir as permissões necessárias durante a implantação para configurar a VM para SAP. Se serviceAccount não for especificado, a conta de serviço padrão do Compute Engine será usada. Especifique o endereço completo da conta de serviço. Por exemplo: [e-mail]
   publicIP	Booleano	Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes. Observação: não especifique No a menos que você tenha um gateway NAT configurado com uma tag de rede definida para a VM ou que tenha fornecido à VM outra rota para a Internet. Se não houver rota para a Internet, a instalação falhará.
   sap_deployment_debug	Booleano	Opcional. Se esse valor estiver definido como Yes, serão gerados registros detalhados da implantação. Não ative essa configuração a menos que um engenheiro de suporte do Google peça para habilitar a depuração.

6. No arquivo de configuração YAML, crie a definição da segunda VM. Basta copiar a definição da primeira VM e colar a cópia após a primeira. Para um exemplo, consulte Exemplo de um arquivo de configuração YAML completo.

7. Na definição da segunda VM, especifique valores diferentes para as seguintes propriedades do que você especificou na primeira definição:

   • name
   • instanceName
   • zone

8. Crie as instâncias de VM:

   gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

   em que:

   • DEPLOYMENT_NAME representa o nome da sua implantação.
   • TEMPLATE_NAME representa o nome do arquivo de configuração YAML.

   O comando anterior invoca o Deployment Manager, que implanta as VMs de acordo com as especificações no arquivo de configuração YAML.

   O processamento da implantação consiste em dois estágios. Na primeira etapa, o Deployment Manager grava o status no console. Na segunda etapa, os scripts de implantação gravam o status no Cloud Logging.

Exemplo de um arquivo de configuração YAML completo

O exemplo a seguir mostra um arquivo de configuração YAML concluído que implanta duas instâncias de VM para uma configuração de alta disponibilidade do SAP NetWeaver usando a versão mais recente dos modelos do Deployment Manager. O exemplo omite os comentários que o modelo contém quando você faz o download dele pela primeira vez.

O arquivo contém as definições de dois recursos a serem implantados: sap_nw_node_1 e sap_nw_node_2. Cada definição de recurso contém as definições de uma VM.

A definição do recurso sap_nw_node_2 foi criada copiando e colando a primeira definição e, em seguida, modificando os valores das propriedades name, instanceName e zone. Todos os outros valores de propriedade nas duas definições de recursos são iguais.

As propriedades networkTag e serviceAccount são da seção "Opções avançadas" do modelo de arquivo de configuração.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]

Criar regras de firewall que permitam acesso às VMs do host

Se ainda não tiver feito isso, crie regras de firewall que permitam acesso a cada VM do host das seguintes origens:

• Para fins de configuração, sua estação de trabalho local, um Bastion Host ou um servidor do Jump
• Para acesso entre os nós do cluster, as outras VMs de host no cluster de alta disponibilidade
• As verificações de integridade usadas pelo Cloud Load Balancing, conforme descrito na etapa posterior Criar uma regra de firewall para as verificações de integridade.

Ao criar regras de firewall da VPC, especifique as tags de rede definidas no arquivo de configuração template.yaml para designar as VMs do host como destino da regra.

Para verificar a implantação, defina uma regra para permitir conexões SSH na porta 22 de um Bastion Host ou da estação de trabalho local.

Para acesso entre os nós do cluster, adicione uma regra de firewall que permita todos os tipos de conexão em qualquer porta de outras VMs na mesma sub-rede.

Certifique-se de que as regras de firewall para verificar a implantação e a comunicação dentro do cluster sejam criadas antes de prosseguir para a próxima seção. Para instruções, consulte Como adicionar regras de firewall.

Como verificar a implantação das VMs

Antes de instalar o SAP NetWeaver ou começar a configurar o cluster de alta disponibilidade, verifique se as VMs foram implantadas corretamente verificando os registros e o mapeamento de armazenamento do SO.

Verificar os registros

1. No console do Google Cloud, abra o Cloud Logging para monitorar o progresso da instalação e verificar se há erros.

   Observação: podem ser incorridos custos ao concluir esta etapa no Cloud Logging. Para mais informações, consulte os preços do Cloud Logging.

   Acesse o Cloud Logging

2. Filtre os registros:

   Explorador de registros

   1. Na página Explorador de registros, acesse o painel Consulta.

   2. No menu suspenso Recurso, selecione Global e clique em Adicionar.

      Se a opção Global não for exibida, insira a seguinte consulta no editor de consultas:

      resource.type="global"
      "Deployment"
      

   3. Clique em Run query.

   Visualizador de registros legado

   • Na página Visualizador de registros legado, no menu de seleção básico, selecione Global como o recurso de registros.

3. Analise os registros filtrados:

   • Se "--- Finished" for exibido, o processamento do Deployment Manager estará concluído e será possível prosseguir para a próxima etapa.

   • Se você vir um erro de cota:

     1. Na página Cotas do IAM e Admin, aumente as cotas que não atendem aos requisitos do SAP NetWeaver listados no Guia de planejamento do SAP NetWeaver.

     2. Na página Implantações do Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.

     3. Execute a implantação novamente.

Verificar a configuração das VMs

1. Depois que as instâncias de VM forem implantadas, conecte-se às VMs usando ssh.

   1. Se você ainda não tiver feito isso, crie uma regra de firewall para permitir uma conexão SSH na porta 22.

   2. Acesse a página Instâncias de VM.

      Acessar instâncias de VM

   3. Para se conectar a cada instância de VM, clique no botão SSH na entrada de cada instância de VM ou use o método SSH que preferir.

      

2. Exibir o sistema de arquivos:

   ~> df -h

   Você precisa ver uma saída semelhante a esta:

   Filesystem                 Size  Used Avail Use% Mounted on
   devtmpfs                    32G  8.0K   32G   1% /dev
   tmpfs                       48G     0   48G   0% /dev/shm
   tmpfs                       32G  402M   32G   2% /run
   tmpfs                       32G     0   32G   0% /sys/fs/cgroup
   /dev/sda3                   30G  3.4G   27G  12% /
   /dev/sda2                   20M  3.7M   17M  19% /boot/efi
   /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
   /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
   tmpfs                      6.3G     0  6.3G   0% /run/user/1002
   tmpfs                      6.3G     0  6.3G   0% /run/user/0

3. Confirme se o diretório de troca foi criado:

   ~> cat /proc/meminfo | grep Swap

   Você verá resultados parecidos com os deste exemplo:

   SwapCached:            0 kB
   SwapTotal:      25161724 kB
   SwapFree:       25161724 kB

Se qualquer um dos passos de validação mostrar que a instalação falhou, faça o seguinte:

1. Corrija o erro.
2. Na página Implantações, exclua a implantação para limpar as VMs e os discos permanentes da instalação com falha.
3. Execute a implantação novamente.

Ativar a comunicação de back-end do balanceador de carga entre as VMs

Depois de confirmar que as VMs foram implantadas com sucesso, ative a comunicação de back-end entre as VMs que servirão como os nós no cluster de alta disponibilidade.

Para ativar a comunicação de back-end entre as VMs, modifique a configuração do google-guest-agent, incluída no ambiente convidado do Linux para todas as imagens públicas do Linux fornecidas pelo Google Cloud.

Para ativar as comunicações de back-end do balanceador de carga, execute as seguintes etapas em cada VM que faz parte do cluster:

1. Interrompa o agente:

   sudo service google-guest-agent stop

2. Abra ou crie o arquivo /etc/default/instance_configs.cfg para edição. Exemplo:

   sudo vi /etc/default/instance_configs.cfg

3. No arquivo /etc/default/instance_configs.cfg, especifique as seguintes propriedades de configuração, conforme mostrado. Se as seções não existirem, crie-as. Em particular, verifique se as propriedades target_instance_ips e ip_forwarding estão definidas como false:

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Inicie o serviço de agente convidado:

   sudo service google-guest-agent start

A configuração da verificação de integridade do balanceador de carga requer uma porta de destino de detecção para a verificação de integridade e uma atribuição do IP virtual para uma interface. Para mais informações, consulte Testar a configuração do balanceador de carga.

Configurar chaves SSH nas VMs principais e secundárias

Para permitir que os arquivos sejam copiados entre os hosts no cluster de alta disponibilidade, as etapas nesta seção criam conexões SSH raiz entre os dois hosts.

Os modelos do Deployment Manager fornecidos pelo Google Cloud geram uma chave, mas é possível substituí-la por uma chave gerada por você, se necessário.

Sua organização provavelmente terá diretrizes que regem as comunicações internas da rede. Se necessário, após a implantação, remova os metadados das VMs e as chaves do diretório authorized_keys.

Se a configuração de conexões SSH diretas não estiver em conformidade com as diretrizes da sua organização, transfira os arquivos usando outros métodos, como os seguintes:

• Transfira arquivos menores por meio da estação de trabalho local usando as opções de menu Fazer upload de arquivos e Fazer o download de arquivos do Cloud Shell. Consulte Como gerenciar arquivos com o Cloud Shell.
• Troque arquivos usando um bucket do Cloud Storage. Consulte Uploads e downloads.
• Use uma solução de armazenamento de arquivos, como Filestore ou NetApp Cloud Volumes Service, para criar uma pasta compartilhada. Consulte Soluções de compartilhamento de arquivos.

Para ativar as conexões SSH entre as instâncias principal e secundária, siga estas etapas. As etapas pressupõem que você esteja usando a chave SSH gerada pelos modelos do Deployment Manager para SAP.

1. Na VM do host principal:

   1. Conecte-se à VM via SSH.

   2. Mudar para raiz:

      $ sudo su -

   3. Confirmar a existência da chave SSH:

      # ls -l /root/.ssh/

      Você verá os arquivos de chave id_rsa como no exemplo a seguir:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Atualize os metadados da VM principal com informações sobre a chave SSH da VM secundária.

      # gcloud compute instances add-metadata SECONDARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone SECONDARY_VM_ZONE

   5. Confirme se as chaves SSH estão configuradas corretamente abrindo uma conexão SSH do sistema principal para o sistema secundário.

      # ssh SECONDARY_VM_NAME

2. Na VM do host secundário:

   1. Conecte-se por SSH à VM.

   2. Mudar para raiz:

      $ sudo su -

   3. Confirmar a existência da chave SSH:

      # ls -l /root/.ssh/

      Você verá os arquivos de chave id_rsa como no exemplo a seguir:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Atualize os metadados da VM secundária com informações sobre a chave SSH da VM principal.

      # gcloud compute instances add-metadata PRIMARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone PRIMARY_VM_ZONE

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

   5. Confirme se as chaves SSH estão configuradas corretamente abrindo uma conexão SSH do sistema secundário para o sistema principal.

      # ssh PRIMARY_VM_NAME

Configurar o armazenamento de arquivos compartilhados e configurar os diretórios compartilhados

É necessário configurar uma solução de compartilhamento de arquivos NFS que forneça armazenamento altamente disponível de arquivos compartilhados acessível pelos dois nós do cluster de alta disponibilidade. Em seguida, crie diretórios nos dois nós que mapeiam para o armazenamento de arquivos compartilhado. O software do cluster garante que os diretórios apropriados sejam montados apenas nas instâncias corretas.

A configuração de uma solução de compartilhamento de arquivos não é abordada neste guia. Para instruções sobre como configurar o sistema de compartilhamento de arquivos, consulte as instruções do fornecedor da solução selecionada. Se você usar o Filestore para sua solução de compartilhamento de arquivos, recomendamos o uso do nível empresarial do Filestore. Para saber como criar uma instância do Filestore, consulte Como criar instâncias.

Para informações sobre soluções de compartilhamento de arquivos disponíveis no Google Cloud, consulte Opções de armazenamento compartilhado para sistemas SAP de alta disponibilidade no Google Cloud.

Para configurar os diretórios compartilhados:

1. Se você ainda não configurou uma solução NFS de armazenamento de arquivos compartilhados altamente disponível, faça isso agora.

2. Ative o armazenamento compartilhado NFS nos dois servidores para a configuração inicial.

   ~> sudo mkdir /mnt/nfs
   ~> sudo mount -t nfs NFS_PATH /mnt/nfs

   Substitua NFS_PATH pelo caminho da solução de compartilhamento de arquivos NFS. Por exemplo, 10.49.153.26:/nfs_share_nw_ha.

3. A partir de qualquer servidor, crie diretórios para sapmnt, o diretório de transporte central e o diretório específico da instância. Se você estiver usando uma pilha Java, substitua "ASCS" por "SCS" antes de usar os seguintes comandos e exemplos:

   ~> sudo mkdir /mnt/nfs/sapmntSID
   ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}

   Se você estiver usando uma configuração de Simple Mount, execute os seguintes comandos:

   ~> sudo mkdir /mnt/nfs/sapmntSID
   ~> sudo mkdir /mnt/nfs/usrsap{trans,SID}

   Substitua:

   • SID: o ID do sistema SAP (SID). Todas as letras devem ser maiúsculas. Por exemplo, AHA.
   • ASCS_INSTANCE_NUMBER: o número da instância do sistema ASCS. Por exemplo, 00.
   • ERS_INSTANCE_NUMBER: o número da instância do sistema ERS. Por exemplo, 10.

4. Nos dois servidores, crie os pontos de montagem necessários:

   ~> sudo mkdir -p /sapmnt/SID
   ~> sudo mkdir -p /usr/sap/trans
   ~> sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER
   ~> sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBER

   Se você estiver usando uma configuração de Simple Mount, execute os comandos a seguir:

   ~> sudo mkdir -p /sapmnt/SID
   ~> sudo mkdir -p /usr/sap/trans
   ~> sudo mkdir -p /usr/sap/SID

5. Configure autofs para montar os diretórios de arquivos compartilhados comuns quando os diretórios de arquivos forem acessados pela primeira vez. A montagem dos diretórios ASCSASCS_INSTANCE_NUMBER e ERSERS_INSTANCE_NUMBER é gerenciada pelo software do cluster, que você configurará em uma etapa posterior.

   Ajuste as opções NFS nos comandos conforme necessário para sua solução de compartilhamento de arquivos.

   Nos dois servidores, configure autofs:

   ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
   ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
   ~> echo "/sapmnt/SID ${NFS_OPTS} NFS_PATH/sapmntSID" | sudo tee -a /etc/auto.sap
   ~> echo "/usr/sap/trans ${NFS_OPTS} NFS_PATH/usrsaptrans" | sudo tee -a /etc/auto.sap

   Para mais informações sobre autofs, consulte autofs: como funciona.

   Se você estiver usando uma configuração de Simple Mount, execute os comandos a seguir:

   ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
   ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
   ~> echo "/sapmnt/SID ${NFS_OPTS}/sapmnt" | sudo tee -a /etc/auto.sap
   ~> echo "/usr/sap/trans ${NFS_OPTS}/usrsaptrans" | sudo tee -a /etc/auto.sap
   ~> echo "/usr/sap/SID  ${NFS_OPTS}/usrsapSID" | sudo tee -a /etc/auto.sap

6. Em ambos os servidores, inicie o serviço autofs:

   ~> sudo systemctl enable autofs
   ~> sudo systemctl restart autofs
   ~> sudo automount -v

7. Acione autofs para montar diretórios compartilhados acessando cada diretório usando o comando cd. Exemplo:

   ~> cd /sapmnt/SID
   ~> cd /usr/sap/trans
   

   Se você estiver usando uma configuração de Simple Mount, execute o seguinte comando:

   ~> cd /sapmnt/SID
   ~> cd /usr/sap/trans
   ~> cd /usr/sap/SID

8. Depois de acessar todos os diretórios, emita o comando df -Th para confirmar se os diretórios estão ativados.

   ~> df -Th | grep FILE_SHARE_NAME

   Substitua FILE_SHARE_NAME pelo nome da sua solução de compartilhamento de arquivos NFS. Por exemplo, nfs_share_nw_ha.

   Você verá pontos de montagem e diretórios semelhantes ao exemplo a seguir:

   10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
   10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
   10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

   Se você estiver usando uma configuração de montagem simples, você verá pontos de montagem e diretórios semelhantes ao exemplo abaixo:

   10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
   10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
   10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA
   10.49.153.26:/nfs_share_nw_ha/usrsapAHA   nfs      1007G   76M  956G   1% /usr/sap/AHA

Configurar o suporte a failover do Cloud Load Balancing

O serviço de balanceador de carga de rede de passagem interno compatível com failover direciona o tráfego ASCS e ERS para as instâncias ativas de cada um em um cluster do SAP NetWeaver. Os balanceadores de carga de rede de passagem internos usam endereços IP virtuais (VIP, na sigla em inglês), serviços de back-end, grupos de instâncias e verificações de integridade para rotear o tráfego adequadamente.

Reservar endereços IP para os IPs virtuais

Para um cluster de alta disponibilidade do SAP NetWeaver, crie dois VIPs, que às vezes são chamados de endereços IP flutuantes. Um VIP segue a instância ativa do SAP Central Services (SCS), e o outro segue a instância do Enqueue Replication Server (ERS). O balanceador de carga roteia o tráfego enviado a cada VIP para a VM que está hospedando a instância ativa do componente SCS ou ERS do VIP.

1. Abra o Cloud Shell:

   Acessar o Cloud Shell

2. Reserve um endereço IP para o IP virtual do ASCS e para o VIP do ERS. Para o ASCS, o endereço IP é aquele que os aplicativos usam para acessar o SAP NetWeaver. Para o ERS, o endereço IP é aquele usado para a replicação do Enqueue Server. Se você omitir a sinalização --addresses, será escolhido para você um endereço IP na sub-rede especificada:

   ~ gcloud compute addresses create ASCS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ASCS_VIP_ADDRESS
   
   ~ gcloud compute addresses create ERS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ERS_VIP_ADDRESS

   Substitua:

   • ASCS_VIP_NAME: especifica um nome para o endereço IP virtual da instância do ASCS. Exemplo, ascs-aha-vip
   • CLUSTER_REGION: especifique a região do Google Cloud em que o cluster está localizado.s Por exemplo, us-central1
   • CLUSTER_SUBNET: especifica a sub-rede que você está usando com o cluster. Exemplo, example-sub-network-sap
   • ASCS_VIP_ADDRESS: como opção, especifique um endereço IP para o IP virtual do ASCS na notação CIDR. Exemplo, 10.1.0.2
   • ERS_VIP_NAME: especifique um nome para o endereço IP virtual da instância do ERS. Exemplo, ers-aha-vip
   • ERS_VIP_ADDRESS: como opção, especifique um endereço IP para o IP virtual do ERS na notação CIDR. Exemplo, 10.1.0.4

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

3. Confirmar reserva de endereço IP:

   ~ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   O resultado será semelhante a:

   address: 10.1.0.2
   addressType: INTERNAL
   creationTimestamp: '2022-04-04T15:04:25.872-07:00'
   description: ''
   id: '555067171183973766'
   kind: compute#address
   name: ascs-aha-vip
   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/ascs-aha-vip
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

Definir nomes de host para o endereço VIP em /etc/hosts

Defina um nome de host para cada endereço VIP e adicione os endereços IP e os nomes do host das VMs e dos VIPs ao arquivo /etc/hosts em cada VM.

Os nomes de host VIP não são conhecidos fora das VMs, a menos que você também os adicione ao serviço de DNS. A adição dessas entradas no arquivo /etc/hosts local protege o cluster contra interrupções no serviço DNS.

As atualizações para o arquivo /etc/hosts precisam ser semelhantes ao seguinte exemplo:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2
10.1.0.2   ascs-aha-vip
10.1.0.4   ers-aha-vip
10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1  # Added by Google
169.254.169.254 metadata.google.internal  # Added by Google

Criar as verificações de integridade do Cloud Load Balancing

Crie verificações de integridade: uma para a instância ativa do SCS e outra para o ERS ativo.

1. No Cloud Shell, crie as verificações de integridade. Para evitar conflitos com outros serviços, designe números de portas para as instâncias do ASCS e do ERS no intervalo particular 49152-65535. Os valores de intervalo de verificação e tempo limite nos comandos a seguir são um pouco mais longos do que os padrões a fim de 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:

   1. ~ gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \
      --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2

   2. ~ gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \
      --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2

2. Confirmar a criação da verificação de integridade:

   ~ gcloud compute health-checks describe HEALTH_CHECK_NAME

   O resultado será semelhante a:

   checkIntervalSec: 10
   creationTimestamp: '2021-05-12T15:12:21.892-07:00'
   healthyThreshold: 2
   id: '1981070199800065066'
   kind: compute#healthCheck
   name: ascs-aha-health-check-name
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
   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

Se você ainda não tiver feito isso, defina uma regra de firewall para uma porta no intervalo particular que permita acesso às VMs do host a partir dos intervalos de IP usados pelas verificações de integridade do Cloud Load Balancing: 35.191.0.0/16 e 130.211.0.0/22. Para mais informações sobre regras de firewall para balanceadores de carga, consulte Como criar regras de firewall para verificações de integridade.

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

   • ~ gcloud compute instances add-tags  PRIMARY_VM_NAME \
     --zone=PRIMARY_ZONE \
     --tags NETWORK_TAGS

   • ~ gcloud compute instances add-tags  SECONDARY_VM_NAME \
     --zone=SECONDARY_ZONE \
     --tags NETWORK_TAGS

2. Criar uma regra de firewall que use a tag de rede 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:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUM

   Exemplo:

   gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
   --network=example-network \
   --action=ALLOW \
   --direction=INGRESS \
   --source-ranges=35.191.0.0/16,130.211.0.0/22 \
   --target-tags=allow-health-check \
   --rules=tcp:60000,tcp:60010

Criar grupos de instâncias do Compute Engine

É necessário criar um grupo de instâncias em cada zona que contenha uma VM de nó do cluster e adicionar a VM nessa zona ao grupo de instâncias.

1. No Cloud Shell, crie o grupo de instâncias principais e adicione a VM principal a ele:

   1. ~ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE \
      --instances=PRIMARY_VM_NAME

2. No Cloud Shell, crie o grupo de instâncias secundárias e adicione a VM secundária a ele:

   1. ~ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE \
      --instances=SECONDARY_VM_NAME

3. 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
   sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
   sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
   

Configurar os serviços de back-end

Crie dois serviços de back-end, um para ASCS e outro para ERS. Adicione os dois grupos de instâncias a cada serviço de back-end, designando o grupo de instâncias oposto como o grupo de instâncias de failover em cada serviço de back-end. Por fim, crie regras de encaminhamento dos VIPs aos serviços de back-end.

1. No Cloud Shell, crie o serviço de back-end e o grupo de failover para o ASCS:

   1. Crie o serviço de back-end para ASCS:

      ~ gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \
         --load-balancing-scheme internal \
         --health-checks ASCS_HEALTH_CHECK_NAME \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region CLUSTER_REGION \
         --global-health-checks

   2. Adicione o grupo de instâncias principal ao serviço de back-end do ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION

   3. Adicionar o grupo de instâncias secundárias como o grupo de instâncias de failover para o serviço de back-end do ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION

2. No Cloud Shell, crie o serviço de back-end e o grupo de failover para o ERS:

   1. Criar o serviço de back-end para ERS:

      ~ gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \
      --load-balancing-scheme internal \
      --health-checks ERS_HEALTH_CHECK_NAME \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region CLUSTER_REGION \
      --global-health-checks

   2. Adicionar o grupo de instâncias secundárias ao serviço de back-end de ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --region CLUSTER_REGION

   3. Adicionar o grupo de instâncias principais como o grupo de instâncias de failover para o serviço de back-end de ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --failover \
        --region CLUSTER_REGION

3. Se quiser, confirme se os serviços de back-end contêm os grupos de instâncias conforme o esperado:

   ~ gcloud compute backend-services describe BACKEND_SERVICE_NAME \
    --region=CLUSTER_REGION

   O resultado será semelhante ao exemplo a seguir do serviço de back-end do ASCS. Para ERS, failover: true apareceria no grupo de instâncias principais:

   backends:
   - balancingMode: CONNECTION
     group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   - balancingMode: CONNECTION
     failover: true
     group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   connectionDraining:
     drainingTimeoutSec: 0
   creationTimestamp: '2022-04-06T10:58:37.744-07:00'
   description: ''
   failoverPolicy:
     disableConnectionDrainOnFailover: true
     dropTrafficIfUnhealthy: true
     failoverRatio: 1.0
   fingerprint: s4qMEAyhrV0=
   healthChecks:
   - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name
   id: '6695034709671438882'
   kind: compute#backendService
   loadBalancingScheme: INTERNAL
   name: ascs-aha-backend-service-name
   protocol: TCP
   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/backendServices/ascs-aha-backend-service-name
   sessionAffinity: NONE
   timeoutSec: 30

4. No Cloud Shell, crie regras de encaminhamento para os serviços de back-end do ASCS e ERS:

   1. Crie a regra de encaminhamento do ASCS VIP para o serviço de back-end ASCS:

      ~ gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ASCS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ASCS_BACKEND_SERVICE_NAME \
      --ports ALL

   2. Criar a regra de encaminhamento do VIP do ERS para o serviço de back-end ERS:

      ~ gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ERS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ERS_BACKEND_SERVICE_NAME \
      --ports ALL

Observação: os grupos de instâncias de back-end não serão registrados como íntegros até que você conclua a configuração do cluster do Pacemaker.

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

Use o utilitário socat para detectar temporariamente uma porta de verificação de integridade.

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

   $ sudo yum install socat

2. Na VM principal, atribua temporariamente o VIP ao cartão de rede eth0:

   ip addr add VIP_ADDRESS dev eth0

3. Na VM principal, inicie um processo socat para detectar por 60 segundos na porta de verificação de integridade do ASCS:

   $ timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,fork

4. 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 ASCS_BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Você verá uma saída semelhante ao seguinte exemplo do ASCS:

   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.90
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
       ipAddress: 10.1.0.89
       port: 80
     kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.90
       healthState: UNHEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
       ipAddress: 10.1.0.88
       port: 80
     kind: compute#backendServiceGroupHealth

5. Remova o VIP da interface eth0:

   ip addr del VIP_ADDRESS dev eth0

6. Repita as etapas para o ERS, substituindo os valores da variável ASCS pelos valores do ERS.

Como testar o balanceador de carga usando a porta 22

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

Para usar temporariamente a porta 22, siga estas etapas:

1. No console do Google Cloud, acesse a página Verificações de integridade do Compute Engine:

   Acessar "Verificações de integridade"

2. Clique no nome da verificação de integridade.

3. Clique em Editar.

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

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

6. 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-b/instanceGroups/sap-aha-primary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
       ipAddress: 10.1.0.79
       port: 80
     kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
       ipAddress: 10.1.0.78
       port: 80
     kind: compute#backendServiceGroupHealth

7. Quando terminar, altere o número da porta de verificação de integridade para o número original.

Instalar listeners para as verificações de integridade

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

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.

Em cada host do cluster, instale um listener seguindo estas etapas:

1. Como raiz, instale um listener TCP simples. Estas instruções instalam e usam o HAProxy como listener.

   # yum install haproxy

2. Copie e renomeie o arquivo de configuração haproxy.cfg padrão para torná-lo um modelo de várias instâncias haproxy:

   # cp /usr/lib/systemd/system/haproxy.service \
       /etc/systemd/system/haproxy@.service
   

3. Edite as seções [Unit] e [Service] do arquivo haproxy@.service para incluir o parâmetro de instância %i, conforme mostrado no exemplo a seguir:

   [Unit]
   Description=HAProxy Load Balancer %i
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
   ...
   

   Para ver mais informações da Red Hat sobre modelos de unidades de systemd, consulte Como trabalhar com unidades instanciadas.

4. Crie um arquivo de configuração haproxy.cfg para a instância do ASCS. Exemplo:

   # vi /etc/haproxy/haproxy-SIDscs.cfg

   Substitua SID pelo ID do sistema SAP (SID). Use letras maiúsculas para todas as letras. Por exemplo, AHA.

5. No arquivo de configuração ASCS haproxy-SIDscs.cfg, insira a configuração a seguir e substitua ASCS_HEALTHCHECK_PORT_NUM pelo número da porta que você especificou ao criar a verificação de integridade do Compute Engine para ASCS:

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ASCS_HEALTHCHECK_PORT_NUM

6. Crie um arquivo de configuração haproxy.cfg para a instância do ERS. Exemplo:

   # vi /etc/haproxy/haproxy-SIDers.cfg

7. No arquivo de configuração do ERS do haproxy-SIDers.cfg, insira a configuração abaixo e substitua ERS_HEALTHCHECK_PORT_NUM pelo número que você especificou ao criar a verificação de integridade do Compute Engine para o ERS:

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ERS_HEALTHCHECK_PORT_NUM

8. Atualize os serviços de systemd:

   # systemctl daemon-reload

9. Confirme se o serviço haproxy está configurado corretamente:

    # systemctl start haproxy
    # systemctl status haproxy
    # systemctl | grep haproxy

   O status retornado mostrará o haproxy.service como active (running).

   ● haproxy.service - HAProxy Load Balancer
      Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
      Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago
    Main PID: 1079 (haproxy)
       Tasks: 2 (limit: 100996)
      Memory: 5.1M
      CGroup: /system.slice/haproxy.service
              ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
              └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
   
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer...
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.

10. Repita as etapas anteriores em cada host do cluster.

Configurar o Pacemaker

O procedimento a seguir configura a implementação do SUSE de um cluster do Pacemaker nas VMs do Compute Engine para SAP NetWeaver.

O procedimento é baseado na documentação da Red Hat para configurar clusters de alta disponibilidade, incluindo as seguintes publicações (uma assinatura da Red Hat é necessária):

• Como configurar o SAP OpenGL ASCS/ERS ENSA1 com recursos autônomos no RHEL 7.5+ e no RHEL 8
• Como configurar SAP S/4HANA ASCS/ERS com servidor de fila independente 2 (ENSA2) no Pacemaker

Para informações da SAP sobre a instalação e configuração do RHEL, consulte:

• Nota SAP 2772999 - Red Hat Enterprise Linux 8.x: instalação e configuração
• Nota SAP 2772999 - Red Hat Enterprise Linux 8.x: instalação e configuração (em inglês)
• Nota SAP 2002167 - Red Hat Enterprise Linux 7.x: instalação e upgrade (em inglês)

Configurar os pacotes de cluster e o firewall do SO necessários nos dois hosts

Como raiz nos hosts principais e secundários, instale e atualize os pacotes de clusters necessários, configure hacluster e defina o serviço de firewall do SO.

1. Instale os seguintes pacotes de cluster necessários:

   # yum install pcs pacemaker
   # yum install fence-agents-gce
   # yum install resource-agents-gcp
   # yum install resource-agents-sap
   # yum install sap-cluster-connector

2. Atualize os pacotes instalados:

   # yum update -y

3. Defina a senha do usuário hacluster, que é instalado como parte dos pacotes:

   # passwd hacluster

4. Especifique uma senha para hacluster nas solicitações.

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

6. Inicie o serviço de PCs e configure-o para iniciar no momento da inicialização:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

7. 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 2020-06-13 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
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Crie o cluster

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

   RHEL 7

   # pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAME

2. Nas solicitações, digite o nome de usuário hacluster e a senha que você definiu para o usuário hacluster.

3. Crie o cluster:

   RHEL 8 e versões mais recentes

   # pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

Atualizar os arquivos de configuração do Corosync

As etapas a seguir definem valores de cluster recomendados para o Corosync. Se o arquivo de configuração do Corosync, /etc/corosync/corosync.conf, ainda não existir ou estiver vazio, será possível usar o arquivo de amostra no diretório /etc/corosync/ como a base para sua configuração.

1. Abra o arquivo corosync.conf para edição:

   # vi /etc/corosync/corosync.conf

2. Na seção totem do arquivo corosync.conf, defina os parâmetros no exemplo a seguir para os valores mostrados. Alguns parâmetros talvez já estejam definidos com os valores corretos:

   RHEL 8

   totem {
   ...
     transport: knet
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

   RHEL 7

   totem {
   ...
     transport: udpu
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

3. Sincronize a configuração com seu segundo servidor:

   RHEL 8 e versões mais recentes

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

4. Na VM principal, ative e inicie o cluster

   # pcs cluster enable --all
   # pcs cluster start --all

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

   # corosync-cmapctl

6. Verifique o status do cluster:

   # pcs status

   O resultado será semelhante a:

   Cluster name: nwha
   
   WARNINGS:
   No stonith devices and stonith-enabled is not false
   
   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
   * 2 nodes configured
   * 0 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * No resources
   
   Daemon Status:
   corosync: active/enabled
   pacemaker: active/enabled
   pcsd: active/enabled

Configurar os recursos de cluster para a infraestrutura

É preciso definir recursos do Pacemaker para a seguinte infraestrutura de cluster:

• O dispositivo de isolamento, que evita cenários de divisão cerebral
• Os diretórios SCS e ERS no sistema de arquivos compartilhado
• As verificações de integridade
• Os VIPs
• Os componentes ASCS e ERS

Primeiro, você define os recursos do dispositivo de esgrima, o sistema de arquivos compartilhado, as verificações de integridade e os VIPs. Em seguida, instale o SAP OpenGL. Depois que o SAP OpenGL for instalado, você definirá os recursos do cluster para os componentes ASCS e ERS.

Configurar o isolamento

Para configurar o isolamento, defina um recurso de cluster com o agente fence_gce para cada VM do 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.

Observação: o parâmetro pcmk_delay_max=30 precisa ser configurado apenas em um recurso de dispositivo de proteção.

Criar os recursos do dispositivo de isolamento

Para cada VM no cluster, crie um recurso de cluster para o dispositivo de isolamento de modo que o cluster possa reiniciar a VM. O dispositivo de isolamento de uma VM precisa ser executado em outra VM. Portanto, configure o local do recurso de cluster para ser executado em qualquer VM, exceto na VM que ele puder reiniciar.

1. No host principal como raiz, crie um recurso de cluster para um dispositivo de isolamento para a VM principal:

   # pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \
       port="PRIMARY_VM_NAME" \
       zone="PRIMARY_ZONE" \
       project="CLUSTER_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"

2. Configure a localização do dispositivo de isolamento da VM principal para que ela fique ativa somente na VM secundária:

   # pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAME

3. No host secundário como raiz, crie um recurso de cluster para um dispositivo de isolamento para a VM secundária:

   # pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \
       port="SECONDARY_VM_NAME" \
       zone="SECONDARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

4. Configure a localização do dispositivo de isolamento da VM secundária para que ela fique ativa somente na VM principal:

   # pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME

Definir um atraso para a reinicialização do Corosync

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

2. Adicione as seguintes linhas ao arquivo:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Salve o arquivo e saia do editor.

4. Atualize a configuração do gerenciador systemd.

   systemctl daemon-reload

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

Criar os recursos do sistema de arquivos

Defina os recursos do cluster para os diretórios ASCS e ERS no sistema de arquivos compartilhado.

1. Configure um recurso do sistema de arquivos para o diretório ASCS.

   # pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ASCS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Substitua:

   • ASCS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso do cluster para o sistema de arquivos ASCS.
   • NFS_PATH: especifica o caminho do diretório para o sistema de arquivos NFS.
   • SID: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.
   • ASCS_INSTANCE_NUMBER: especifica o número da instância do ASCS.
   • ASCS_RESOURCE_GROUP: especifica um nome de grupo exclusivo para os recursos do cluster do ASCS. É possível garantir a exclusividade usando uma convenção como "SID_ASCSinstance_number_group". Exemplo, nw8_ASCS00_group

     Como um grupo ainda não existe, o Pacemaker cria o grupo agora. Conforme você cria outros recursos do ASCS, eles são adicionados a este grupo.

2. Configure um recurso do sistema de arquivos para o diretório ERS.

   # pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ERS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Substitua:

   • ERS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso do sistema de arquivos.
   • NFS_PATH: especifica o caminho do diretório para o sistema de arquivos NFS.
   • SID: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.
   • ERS_INSTANCE_NUMBER: especifica o número da instância do ERS.
   • ERS_RESOURCE_GROUP: especifica um nome de grupo exclusivo para os recursos do cluster de ERS. É possível garantir a exclusividade usando uma convenção como "SID_ERSinstance_number_group". Exemplo, nw8_ERS10_group

     Como um grupo ainda não existe, o Pacemaker cria o grupo agora. Ao criar outros recursos de ERS, você os adiciona a este grupo.

Criar um recurso de endereço IP virtual

Defina os recursos de cluster para os endereços VIP.

1. Se você precisar procurar o endereço VIP numérico, use:

   • gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
   • gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"

2. Crie os recursos de cluster dos VIPs do SCS e do ERS.

   # pcs resource create ASCS_VIP_RESOURCE IPaddr2 \
       ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ASCS_RESOURCE_GROUP

   # pcs resource create ERS_VIP_RESOURCE IPaddr2 \
       ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ERS_RESOURCE_GROUP

Criar os recursos da verificação de integridade

1. Configure o recurso de cluster para a verificação de integridade do ASCS:

   # pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \
      op monitor interval=10s timeout=20s \
      --group ASCS_RESOURCE_GROUP

2. Configure o recurso de cluster para a verificação de integridade do ERS:

   # pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \
      op monitor interval=10s timeout=20s \
      --group ERS_RESOURCE_GROUP

Definir padrões de cluster adicionais

1. Defina outras propriedades do cluster:

   # pcs resource defaults resource-stickiness=1
   # pcs resource defaults migration-threshold=3

Ver os recursos definidos

Exiba os recursos de cluster que você definiu até agora para garantir que eles estejam corretos.

1. Exiba o status do cluster:

   # pcs status

   O resultado será semelhante a:

   Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
     * fence-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00    (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs   (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00 (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10 (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-2
       * nw8_healthcheck_ers   (service:haproxy@nw8ers):    Started nw-ha-vm-2
       * nw8_fs_ers10  (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
   
   Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled
   

Instalar ASCS e ERS

A seção a seguir abrange apenas os requisitos e as recomendações específicas da instalação do SAP NetWeaver no Google Cloud.

Para instruções completas de instalação, consulte a documentação do SAP NetWeaver.

Preparar para a instalação

Para garantir a consistência no cluster e simplificar a instalação, antes de instalar os componentes SCS e ERS do SAP NetWeaver, defina os usuários, grupos e permissões e coloque o servidor secundário no modo de espera.

1. Remova o cluster do modo de manutenção:

   # sudo pcs property set maintenance-mode="false"

2. Nos dois servidores como raiz, digite os seguintes comandos, especificando os IDs de usuário e de grupo adequados ao ambiente:

   # groupadd -g GID_SAPINST sapinst
   # groupadd -g GID_SAPSYS sapsys
   # useradd -u UID_SIDADM SID_LCadm -g sapsys
   # usermod -a -G sapinst SID_LCadm
   # useradd -u UID_SAPADM sapadm -g sapinst
   
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS
   # chown SID_LCadm:sapsys /sapmnt/SID -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
   # chown SID_LCadm:sapsys /usr/sap/SID -R

   Se você estiver usando uma configuração de montagem simples (link em inglês), execute os comandos abaixo em ambos os servidores como raiz. Especifique os IDs de usuário e de grupo adequados para seu ambiente.

   # groupadd -g GID_SAPINST sapinst
   # groupadd -g GID_SAPSYS sapsys
   # useradd -u UID_SIDADM SID_LCadm -g sapsys
   # usermod -a -G sapinst SID_LCadm
   # useradd -u UID_SAPADM sapadm -g sapinst
   
   # chown SID_LCadm:sapsys /usr/sap/SID
   # chown SID_LCadm:sapsys /sapmnt/SID -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID -R
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS

   Substitua:

   • GID_SAPINST: especifica o ID do grupo do Linux para a ferramenta de provisionamento da SAP.
   • GID_SAPSYS: especifica o ID do grupo do Linux para o usuário do SAPSYS.
   • UID_SIDADM: especifique o ID do usuário do Linux para o administrador do sistema SAP (SID).
   • SID_LC: especifica o ID do sistema (SID). Use letras minúsculas para letras.
   • UID_SAPADM: especifica o ID do usuário para o agente de host da SAP.
   • SID: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.

   Por exemplo, veja a seguir um esquema prático de numeração de GID e UID:

   Group sapinst      1001
   Group sapsys       1002
   Group dbhshm       1003
   
   User  en2adm       2001
   User  sapadm       2002
   User  dbhadm       2003

Instalar o componente ASCS

1. No servidor secundário, digite o seguinte comando para colocar o servidor secundário no modo de espera:

   # pcs node standby

   Colocar o servidor secundário no modo de espera consolida todos os recursos do cluster no servidor principal, o que simplifica a instalação.

2. Confirme se o servidor secundário está em modo de espera:

   # pcs status

   A resposta será semelhante a:

   Cluster name: nwha
      Cluster Summary:
        * Stack: corosync
        * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
        * 2 nodes configured
        * 8 resource instances configured
   
      Node List:
        * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
      Full List of Resources:
        * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
        * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
        * Resource Group: nw8_ascs00_group:
          * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
          * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * Resource Group: nw8_ers10_group:
          * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
          * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
   
      Daemon Status:
        corosync: active/enabled
   

3. No servidor principal, como usuário raiz, altere o diretório para um diretório de instalação temporário, como /tmp, para instalar a instância do SCS executando o SAP Software Provisioning Manager (SWPM).

   • Para acessar a interface da Web do SWPM, é necessário ter a senha do usuário root. Se a política de TI não permitir que o administrador do SAP tenha acesso à senha raiz, use o SAPINST_REMOTE_ACCESS_USER.

   • Ao iniciar o SWPM, use o parâmetro SAPINST_USE_HOSTNAME para especificar o nome do host virtual definido para o endereço VIP do SCS no arquivo /etc/hosts.

     Exemplo:

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs

   • Na página final de confirmação do SWPM, verifique se o nome do host virtual está correto.

4. Após a conclusão da configuração, remova a VM secundária do modo de espera:

   # pcs node unstandby

Instalar o componente ERS

1. No servidor principal como raiz ou SID_LCadm, pare o serviço ASCS.

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"

2. No servidor principal, digite o seguinte comando para colocar o servidor principal no modo de espera:

   # pcs node standby

   Colocar o servidor principal no modo de espera consolida todos os recursos do cluster no servidor secundário, o que simplifica a instalação.

3. Confirme se o servidor principal está no modo de espera:

   # pcs status

4. No servidor secundário, como usuário raiz, altere o diretório para um diretório de instalação temporário, como /tmp, para instalar a instância ERS executando o SAP Software Provisioning Manager (SWPM).

   • Use o mesmo usuário e senha para acessar o SWPM usados quando você instalou o componente SCS.

   • Ao iniciar o SWPM, use o parâmetro SAPINST_USE_HOSTNAME para especificar o nome do host virtual que você definiu para o endereço VIP do ERS no arquivo /etc/hosts.

     Exemplo:

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers

   • Na página final de confirmação do SWPM, verifique se o nome do host virtual está correto.

5. Deixe a VM principal em espera para ativar as duas:

   # pcs node unstandby

Configurar os serviços do SAP

Confirme se os serviços estão definidos corretamente, confira as configurações nos perfis ASCS e ERS e adicione o usuário SID_LCadm ao grupo de usuários haclient.

Confirmar as entradas de serviço do SAP

1. Nos dois servidores, confirme se o arquivo /usr/sap/sapservices contém entradas para os serviços ASCS e ERS. Para isso, você pode usar a integração systemV ou systemd.

   Adicione as entradas ausentes usando o comando sapstartsrv com as opções pf=PROFILE_OF_THE_SAP_INSTANCE e -reg.

   Para mais informações sobre essas integrações, consulte as seguintes notas SAP:

   • 3139184 - Linux: integração do systemd para sapstartsrv e SAP Host Agent

   • 3115048 - sapstartsrv com suporte nativo a systemd do Linux

   systemV

   Este é um exemplo de como as entradas para os serviços ASCS e ERS no arquivo /usr/sap/sapservices quando você usa a integração systemV:

   # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
   /usr/sap/hostctrl/exe/sapstartsrv \
   pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
   -D -u SID_LCadm
   /usr/sap/hostctrl/exe/sapstartsrv \
   pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
   -D -u SID_LCadm

   systemd

   1. Verifique se o arquivo /usr/sap/sapservices contém entradas para os serviços ASCS e ERS. Confira abaixo um exemplo de como essas entradas aparecem no arquivo /usr/sap/sapservices quando você usa a integração systemd:

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers

   2. Desative a integração systemd nas instâncias do ASCS e do ERS:

      Cuidado: desativar a integração systemd também interrompe as instâncias do SAP.

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service

   3. Verifique se a integração com systemd está desativada:

      # systemctl list-unit-files | grep sap

      Uma saída semelhante ao exemplo a seguir significa que a integração com systemd está desativada. Alguns serviços, como saphostagent e saptune, estão ativados e outros desativados.

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

Interromper os serviços do SAP

1. No servidor secundário, interrompa o serviço ERS:

   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"

2. Em cada servidor, valide se todos os serviços foram interrompidos:

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

   O resultado será semelhante a:

   GetSystemInstanceList
   FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Desativar a reinicialização automática de serviço em SAP

Importante: essa seção é obrigatória APENAS para systemV.

Como o software do cluster gerencia a reinicialização dos serviços da SAP durante um failover, desative o recurso de reinicialização automática dos serviços para evitar conflitos.

1. Em ambos os nós, edite o arquivo /usr/sap/sapservices para desativar a reinicialização automática no software SAP adicionando um caractere de comentário, #, no início do comando sapstartsrv para os dois. os componentes ASCS e ERS.

   Exemplo:

   #!/bin/sh
   
    #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    

Editar os perfis do ASCS e do ERS

1. Nos dois servidores, alterne para o diretório de perfil usando um dos seguintes comandos:

   # cd /usr/sap/SID/SYS/profile

   # cd /sapmnt/SID/profile

2. Se necessário, encontre os nomes dos arquivos dos perfis ASCS e ERS listando os arquivos no diretório do perfil ou use os seguintes formatos:

   SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

3. Se você estiver usando o ENSA1, ative a função de sinal de atividade definindo o seguinte no perfil do ASCS:

   enque/encni/set_so_keepalive = true

   Para mais informações, consulte a Nota SAP 1410736: TCP/IP: como configurar um intervalo de sinal de atividade (em inglês).

4. Se necessário, edite os perfis ASCS e ERS para alterar o comportamento de inicialização do Enqueue Server e do Enqueue Replication Server.

   ENSA1

   Na seção Iniciar servidor de enfileiramento SAP do perfil do ASCS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.

   Start_Program_01 = local $(_EN) pf=$(_PF)

   Na seção Iniciar servidor de replicação de enfileiramento do perfil do ERS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.

   Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

   ENSA2

   Na seção Iniciar servidor de enfileiramento SAP do perfil do ASCS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.

   Start_Program_01 = local $(_ENQ) pf=$(_PF)

   Na seção Iniciar replicador de enfileiramento do perfil do ERS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.

   Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

Configurar os recursos do cluster para ASCS e ERS

1. Como raiz em um dos servidores, coloque o cluster no modo de manutenção:

   # pcs property set maintenance-mode="true"

2. Confirme se o cluster está no modo de manutenção:

   # pcs status

3. Crie os recursos de cluster para os serviços ASCS e ERS:

   ENSA1

   • Crie o recurso de cluster para a instância do ASCS. O valor de InstanceName é o nome do perfil da instância gerado pelo SWPM quando você instalou o ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
         failure-timeout=60  --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Crie o recurso de cluster para a instância do ERS. O valor de InstanceName é o nome do perfil da instância gerado pelo SWPM quando você instalou o ERS. O parâmetro IS_ERS=true instrui o Pacemaker a definir a sinalização runsersSID como 1 no nó em que o ERS está ativo.

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

   ENSA2

   • Crie o recurso de cluster para a instância do ASCS. O valor de InstanceName é o nome do perfil da instância gerado pelo SWPM quando você instalou o ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
         --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Crie o recurso de cluster para a instância do ERS. O valor de InstanceName é o nome do perfil da instância gerado pelo SWPM quando você instalou o ERS.

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

Configurar as restrições de local e ordem

Você cria restrições para definir quais serviços precisam ser iniciados primeiro e quais precisam ser executados juntos no mesmo host. Por exemplo, o endereço IP precisa estar no mesmo host da instância principal do SAP Central Services.

1. Defina a restrição do pedido inicial:

ENSA1

1. Crie uma restrição de posicionamento para impedir que os recursos ASCS sejam executados no mesmo servidor que os recursos do ERS:

   # pcs constraint colocation add ERS_RESOURCE_GROUP with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configure o ASCS para fazer failover ao servidor em que o ERS está sendo executado, o que é determinado pela sinalização runsersSID ser igual a 1:

   # pcs constraint location ASCS_INSTANCE_RESOURCE \
       rule score=2000 runs_ers_SID eq 1

3. Configure o ASCS para iniciar antes que o ERS seja movido para o outro servidor após um failover:

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

ENSA2

1. Crie uma restrição de posicionamento para impedir que os recursos SCS sejam executados no mesmo servidor que os recursos do ERS:

   # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configure o SCS para iniciar antes que o ERS seja movido para o outro servidor após um failover:

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

1. Verifique as restrições:

   # pcs constraint

   A resposta será semelhante a esta:

   Location Constraints:
     Resource: ascs-aha-instance
       Constraint: location-ascs-instance
         Rule: score=2000
           Expression: runs_ers_HKN eq 1
     Resource: fence-nw-ha-vm-1
       Disabled on: nw-ha-vm-1 (score:-INFINITY)
     Resource: fence-nw-ha-vm-2
       Disabled on: nw-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
     start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
   Colocation Constraints:
     ascs-group with ers-group (score:-5000)
   Ticket Constraints:

2. Como raiz de qualquer um dos servidores, desative o modo de manutenção do cluster:

   # pcs property set maintenance-mode="false"

Configurar o conector de cluster do Red Hat para SAP

Em cada host no cluster, configure o sapstartsrv Start Service da SAP para se comunicar com o software de cluster do builder por meio da interface de alta disponibilidade.

1. Adicione o usuário administrativo da SAP ao grupo haclient:

   usermod -a -G haclient SID_LCadm

2. Edite os perfis de instância da SAP adicionando as seguintes linhas ao final de cada perfil: Os perfis podem ser encontrados no diretório /sapmnt/SID/profiles.

   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_cluster_connector

3. Se os recursos da instância do ASCS e do ERS estiverem em execução no cluster, desative-os:

   pcs resource disable ERS_INSTANCE_RESOURCE
   pcs resource disable ASCS_INSTANCE_RESOURCE

4. Interrompa os serviços no host ASCS:

   sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

5. Interrompa os serviços no host do ERS:

   sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

6. Ative os recursos:

   pcs resource enable ERS_INSTANCE_RESOURCE
   pcs resource enable ASCS_INSTANCE_RESOURCE

7. Repita as etapas anteriores em cada host do cluster.

Para mais informações do Red Hat, consulte Como configurar o SAP halib para recursos do SAPInstance no RHEL 7 e 8 (em inglês).

Instalar o banco de dados e os servidores de aplicativos em hosts fora do cluster

Na configuração de alta disponibilidade, recomendamos instalar os bancos de dados e servidores de aplicativos em hosts diferentes do que os hosts ASCS e ERS no cluster.

Ao usar hosts separados para cada servidor, você reduz a complexidade, o risco de uma falha afetar vários servidores e pode personalizar o tamanho de cada Compute Engine para cada tipo de servidor.

Isso permite que você escolha o tamanho de máquina certificado mais adequado, evite falhas e reduza a complexidade.

A instalação dos bancos de dados e servidores de aplicativos não é abordada neste guia.

Para informações sobre como instalar os servidores de banco de dados, consulte:

• SAP HANA no Google Cloud
• SAP ASE no Google Cloud
• SAP MaxDB no Google Cloud
• IBM Db2 para SAP no Google Cloud

Validar e testar o cluster

Esta seção mostra como executar os seguintes testes:

• Verificar se há erros de configuração
• Confirmar se os recursos ASCS e ERS alternam de servidor corretamente durante os failovers
• Confirmar se os bloqueios foram retidos
• Simular um evento de manutenção do Compute Engine para garantir que a migração em tempo real não acione um failover

Verifique a configuração do cluster

1. Como raiz em um dos servidores, verifique em quais nós os recursos estão sendo executados:

   # pcs status

   No exemplo a seguir, os recursos do SCS estão sendo executados no servidor nw-ha-vm-2 e os recursos do ERS são executados no servidor nw-ha-vm-1.

   Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

2. Mude para o usuário SID_LCadm.

   # su - SID_LCadm

3. Verifique a configuração do cluster. Para INSTANCE_NUMBER, especifique o número da instância do ASCS ou do ERS que está ativa no servidor em que você está inserindo o comando:

   > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

   HAActive precisa ser TRUE, conforme mostrado no exemplo a seguir:

   HAGetFailoverConfig
   
   14.04.2022 17:25:45
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: Pacemaker
   HASAPInterfaceVersion: sap_cluster_connector
   HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
   HAActiveNode:
   HANodes:

4. Como SID_LCadm, verifique se há erros na configuração:

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   O resultado será semelhante a:

   14.04.2022 21:43:39
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
   SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
   SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
   SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

5. No servidor em que o ASCS está ativo, como SID_LCadm, simule um failover:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

6. Como raiz, se você seguir o failover usando crm_mon, verá o ASCS mover para o outro servidor, o ERS ser interrompido nesse servidor e, em seguida, o ERS ser movido para o servidor em que o SCS estava sendo executado.

Simule um failover

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

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

• shutdown -r (no nó ativo)
• ip link set eth0 down
• echo c > /proc/sysrq-trigger

Estas instruções usam ip link set eth0 down para colocar a interface de rede off-line porque ela valida o failover e o isolamento.

1. Faça backup do seu sistema.

2. Como raiz no host com a instância SCS ativa, torne a interface de rede off-line:

   $ ip link set eth0 down

3. Reconecte-se ao host usando o SSH e mude para o usuário raiz

4. Digite pcs status para confirmar que o host principal está ativo na VM que costumava conter o host secundário. A reinicialização automática está habilitada no cluster. Portanto, o host parado será reiniciado e passará à função de host secundário, conforme mostrado no exemplo a seguir.

    Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

Confirmar que as entradas de bloqueio foram mantidas

Para confirmar se as entradas de bloqueio são preservadas em um failover, primeiro selecione a guia da versão do Enqueue Server e siga o procedimento para gerar entradas de bloqueio, simule um failover e confirme se as entradas de bloqueio são retidos depois que o ASCS é ativado novamente.

ENSA1

1. Como SID_LCadm, no servidor em que o ERS está ativo, gere entradas de bloqueio usando o programa enqt:

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS

2. Como SID_LCadm, no servidor em que ASCS está ativo, verifique se as entradas de bloqueio estão registradas:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Se você criou 10 bloqueios, o resultado será semelhante ao seguinte exemplo:

   locks_now: 10

3. Como SID_LCadm, no servidor em que o ERS está ativo, inicie a função de monitoramento, OpCode=20, do programa enqt:

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999

   Exemplo:

   > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999

4. Quando o ASCS estiver ativo, reinicialize o servidor.

   No servidor de monitoramento, no momento em que o Pacemaker interrompe o ERS para movê-lo para o outro servidor, você verá uma saída semelhante à seguinte.

   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10

5. Quando o monitor enqt parar, saia dele digitando Ctrl + c.

6. Se preferir, como raiz em um dos servidores, monitore o failover do cluster:

   # crm_mon

7. Como SID_LCadm, depois de confirmar que os bloqueios foram mantidos, libere os bloqueios:

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS

8. Como SID_LCadm, no servidor em que o ASCS está ativo, verifique se as entradas de bloqueio foram removidas:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

1. Como SID_LCadm, no servidor em que o ASCS está ativo, gere entradas de bloqueio usando o programa enq_adm:

   > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

2. Como SID_LCadm, no servidor em que ASCS está ativo, verifique se as entradas de bloqueio estão registradas:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Se você criou 10 bloqueios, o resultado será semelhante ao seguinte exemplo:

   locks_now: 10

3. Quando o ERS estiver ativo, confirme se as entradas de bloqueio foram replicadas:

   > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   O número de bloqueios retornados deve ser o mesmo da instância do ASCS.

4. Quando o ASCS estiver ativo, reinicialize o servidor.

5. Se preferir, como raiz em um dos servidores, monitore o failover do cluster:

   # crm_mon

6. Como SID_LCadm, no servidor em que ASCS foi reiniciado, verifique se as entradas de bloqueio foram retidas:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

7. Como SID_LCadm, no servidor em que o ERS está ativo, depois de confirmar que os bloqueios foram retidos, libere os bloqueios:

   > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

8. Como SID_LCadm, no servidor em que o ASCS está ativo, verifique se as entradas de bloqueio foram removidas:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Você verá uma saída semelhante ao seguinte exemplo:

   locks_now: 0

Simular um evento de manutenção do Compute Engine

Simule um evento de manutenção do Compute Engine para garantir que a migração em tempo real não acione um failover.

Os valores de tempo limite e intervalo usados nessas instruções consideram a duração das migrações em tempo real. Se você usar valores mais curtos na configuração do cluster, o risco de que a migração em tempo real possa acionar um failover é maior.

Para testar a tolerância do cluster na migração em tempo real:

1. No nó principal, acione um evento de manutenção simulado usando o seguinte comando da CLI gcloud:

   $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

2. Confirme que o nó principal não foi alterado:

   $ pcs status

Avalie sua carga de trabalho do SAP NetWeaver

Para automatizar verificações de validação contínua para suas cargas de trabalho de alta disponibilidade do SAP NetWeaver em execução no Google Cloud, use o Gerenciador de carga de trabalho.

O Gerenciador de carga de trabalho permite verificar e avaliar automaticamente suas cargas de trabalho de alta disponibilidade do SAP NetWeaver em relação às práticas recomendadas de fornecedores da SAP, do Google Cloud e do SO. Isso ajuda a melhorar a qualidade, o desempenho e a confiabilidade das cargas de trabalho.

Para mais informações sobre as práticas recomendadas compatíveis com o Gerenciador de cargas de trabalho para avaliar as cargas de trabalho de alta disponibilidade do SAP NetWeaver em execução no Google Cloud, consulte Práticas recomendadas do Gerenciador de cargas de trabalho para SAP. Para informações sobre como criar e executar uma avaliação usando o Gerenciador de cargas de trabalho, consulte Criar e executar uma avaliação.

Solução de problemas

Para resolver problemas com configurações de alta disponibilidade para o SAP NetWeaver, consulte Como resolver problemas de configurações de alta disponibilidade para SAP (em inglês).

Coletar informações de diagnóstico para clusters de alta disponibilidade do SAP OpenGL

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

Para coletar informações de diagnóstico, consulte Clusters de alta disponibilidade no RHEL.

Suporte

Em caso de problemas com a infraestrutura ou os serviços do Google Cloud, entre em contato com o Customer Care. É possível ver os dados de contato na página Visão geral do suporte no Console do Google Cloud. Se o Customer Care determinar que há um problema nos seus sistemas SAP, você será encaminhado ao Suporte da SAP.

Para problemas relacionados a produtos SAP, registre sua solicitação de suporte no site da SAP. A SAP avalia o tíquete de suporte e, se ele parecer ser um problema de infraestrutura do Google Cloud, a SAP transfere esse tíquete para o componente adequado do Google Cloud em seu sistema: BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE.

Requisitos de suporte

Antes de receber suporte para sistemas SAP e a infraestrutura e os serviços do Google Cloud que eles usam, você precisa atender aos requisitos mínimos do plano de suporte.

Saiba mais sobre os requisitos mínimos de suporte para SAP no Google Cloud em:

• Como receber suporte para o SAP no Google Cloud
• Nota SAP 2456406 - SAP no Google Cloud Platform: pré-requisitos de suporte (é necessário ter uma conta de usuário SAP)

Como realizar tarefas de pós-implantação

Antes de usar o sistema SAP NetWeaver, recomendamos que você faça backup do novo sistema de alta disponibilidade do SAP NetWeaver.

Para mais informações, consulte o guia de operações do SAP NetWeaver.

A seguir

Para mais informações sobre alta disponibilidade, SAP OpenGL e Google Cloud, consulte os seguintes recursos:

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

• Políticas de suporte para clusters de alta disponibilidade do RHEL - requisitos gerais para isolamento/STONITH

• Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud

• Para mais informações sobre administração e monitoramento de VMs, consulte o Guia de operações do SAP HANA