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

Neste guia, você verá como implantar e configurar um cluster de alta disponibilidade (HA, na sigla em inglês) do SUSE Linux Enterprise Server (SLES) 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 interno para redirecionar o tráfego em caso de falha
• Como configurar um cluster do Pacemaker no SLES 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 o SAP HANA no Red Hat Enterprise Linux (RHEL), consulte o Guia de configuração manual de clusters de alta disponibilidade para SAP NetWeaver no RHEL.

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 NetWeaver e configurará um cluster de alta disponibilidade no SLES. 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 SLES.

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 bloqueiem todo o acesso externo não solicitado.
• Ao criar suas VMs:
  • Especifique uma tag de rede para cada VM 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 SUSE

Exceto onde exigido para o ambiente do Google Cloud, as informações neste guia são consistentes com os seguintes guias do SUSE:

• Cluster de alta disponibilidade do SAP NetWeaver Enqueue Replication 1: guia de configuração do SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server para aplicativos SAP 12 (em inglês)
• Cluster de alta disponibilidade do SAP NetWeaver Enqueue Replication: guia de configuração do SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server para aplicativos SAP 15 (em inglês)
• SAP S/4 HANA: cluster de alta disponibilidade do Enqueue Replication 2 - Guia de configuração | SUSE Linux Enterprise Server para aplicativos SAP 12 (em inglês)
• SAP S/4 HANA: cluster de alta disponibilidade do Enqueue Replication 2 - Guia de configuração | SUSE Linux Enterprise Server para aplicativos SAP 15 (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-sles15sp3.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/sles-15-sp3-sap: 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 suse-sap-cloud. Para uma lista de projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.
   usrsapSize	Inteiro	O tamanho do disco /usr/sap. O tamanho mínimo é 8 GB.
   sapmntSize	Inteiro	O tamanho do disco /sapmnt. O tamanho mínimo é 8 GB.
   swapSize	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

   onde:

   • 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/sles-15-sp3-sap
    linuxImageProject: suse-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/sles-15-sp3-sap
    linuxImageProject: suse-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 os 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 que falhou.
3. Execute a implantação novamente.

Atualizar a CLI do Google Cloud

O modelo do Deployment Manager instalou a Google Cloud CLI nas VMs durante a implantação. Atualize a CLI gcloud para garantir que ela inclua todas as atualizações mais recentes.

1. Conecte-se por SSH à VM principal.

2. Atualizar a CLI gcloud:

   ~>  sudo gcloud components update

3. Siga as instruções.

4. Repita as etapas na VM secundária.

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. do 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}

   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

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 (em inglês).

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
   

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 aos seguintes:

   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

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

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

   # zypper 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 de porta original.

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.

Para mais informações sobre a configuração de clusters de alta disponibilidade no SLES, consulte a documentação Extensão de alta disponibilidade do SUSE Linux Enterprise (em inglês) para sua versão do SLES.

Instalar os pacotes de cluster necessários

1. Como raiz nos hosts principal e secundário, faça o download dos seguintes pacotes de cluster necessários:

   • O padrão ha_sles:

     # zypper install -t pattern ha_sles

   • O pacote sap-suse-cluster-connector:

     # zypper install -y sap-suse-cluster-connector

   • Se você ainda não o instalou, o utilitário socat:

     # zypper install -y socat

2. Confirme se os agentes de alta disponibilidade mais recentes foram carregados:

   # zypper se -t patch SUSE-SLE-HA

Inicializar, configurar e iniciar o cluster na VM principal

Inicialize o cluster usando o script SUSE ha-cluster-init. Em seguida, edite o arquivo de configuração do Corosync e sincronize-o com o nó secundário. Depois de iniciar o cluster, defina outras propriedades e padrões do cluster usando os comandos crm.

Talvez você veja os seguintes avisos ao inicializar ou mesclar o cluster:

• Nenhum firewall detectado: este aviso indica que o processo de inicialização do cluster não encontrou ou atualizou o firewall do sistema operacional. Se você estiver usando um firewall do sistema operacional, é necessário permitir o acesso a essas portas. Também é necessário criar uma regra de firewall VPC que permita o acesso a essas portas, bem como às portas usadas pelo aplicativo SAP.
• Nenhum dispositivo guardião encontrado: esta opção pode ser ignorada. Essas instruções não usam o SBD.
• Altere a senha de "hacluster": altere a senha depois de concluir estas instruções.

Criar os arquivos de configuração do Corosync

1. Crie um arquivo de configuração do Corosync no host principal:

   1. Usando o editor de texto que preferir, crie o seguinte arquivo:

      /etc/corosync/corosync.conf

   2. No arquivo corosync.conf no host principal, adicione a seguinte configuração substituindo o texto da variável em itálico pelos valores:

      totem {
       version: 2
       secauth: off
       crypto_hash: sha1
       crypto_cipher: aes256
       cluster_name: hacluster
       clear_node_high_bit: yes
       token: 20000
       token_retransmits_before_loss_const: 10
       join: 60
       max_messages:  20
       transport: udpu
       interface {
         ringnumber: 0
         Bindnetaddr: STATIC_IP_OF_THIS_HOST
         mcastport: 5405
         ttl: 1
       }
      }
      logging {
       fileline:  off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
      }
      nodelist {
       node {
         ring0_addr: THIS_HOST_NAME
         nodeid: 1
       }
       node {
         ring0_addr: OTHER_HOST_NAME
         nodeid: 2
       }
      }
      quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
      }

   Substitua:

   • STATIC_IP_OF_THIS_HOST: especifique o endereço IP interno primário dessa VM, conforme mostrado em Interfaces de rede no console do Google Cloud ou conforme exibido por gcloud compute instances describe VM_NAME.
   • THIS_HOST_NAME: especifica o nome do host dessa VM.
   • OTHER_HOST_NAME: especifica o nome do host da outra VM no cluster.

2. Crie um arquivo de configuração do Corosync no host secundário repetindo as mesmas etapas usadas para o host principal. Os valores de propriedade do arquivo de configuração são os mesmos para cada host, exceto para o IP estático do HDB na propriedade Bindnetaddr e para a ordem dos nomes de host em nodelist.

Inicializar o cluster

Para inicializar o cluster:

1. No host principal como raiz, inicialize o cluster usando o script SUSE ha-cluster-init. Os comandos a seguir nomeiam o cluster e criam o arquivo de configuração corosync.conf: configure-o e defina a sincronização entre os nós do cluster.

   # ha-cluster-init --name CLUSTER_NAME --yes --interface eth0 csync2
   # ha-cluster-init --name CLUSTER_NAME --yes --interface eth0 corosync

2. Inicie o Pacemaker no host principal:

   # systemctl enable pacemaker
   # systemctl start pacemaker

Definir as outras propriedades do cluster

1. Defina as propriedades gerais do cluster:

   # crm configure property stonith-timeout="300s"
   # crm configure property stonith-enabled="true"
   # crm configure rsc_defaults resource-stickiness="1"
   # crm configure rsc_defaults migration-threshold="3"
   # crm configure op_defaults timeout="600"

   Ao definir os recursos individuais do cluster, os valores definidos para resource-stickiness e migration-threshold modificam os valores padrão definidos aqui.

   É possível ver os padrões de recursos, bem como os valores de quaisquer recursos definidos, inserindo crm config show.

Mesclar a VM secundária ao cluster

No terminal aberto na VM principal, mescle e inicie o cluster na VM secundária via SSH.

1. Na VM principal, execute as seguintes opções de script ha-cluster-join na VM secundária via SSH. Se você tiver configurado o cluster de alta disponibilidade conforme descrito nestas instruções, desconsidere os avisos sobre o dispositivo guardião.

   1. Execute a opção --interface eth0 csync2:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes --interface eth0 csync2'

   2. Execute a opção ssh_merge:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes ssh_merge'

   3. Execute a opção cluster:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes cluster'

2. Inicie o Pacemaker no host secundário:

   1. Ative o Pacemaker:

      # ssh SECONDARY_VM_NAME systemctl enable pacemaker

   2. Inicie o Pacemaker:

      # ssh SECONDARY_VM_NAME systemctl start pacemaker

3. Em ambos os hosts como raiz, confirme se o cluster mostra os dois nós:

   # crm_mon -s

   A resposta será semelhante a esta:

   CLUSTER OK: 2 nodes online, 0 resource instances configured

Configurar os recursos de cluster para a infraestrutura

Os recursos que o Pacemaker gerencia são definidos em um cluster de alta disponibilidade. É preciso definir recursos dos seguintes componentes do 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

Os recursos dos componentes SCS e ERS são definidos depois que o restante dos recursos, porque é necessário instalar o SAP NetWeaver primeiro.

Ativar o modo de manutenção

1. Em ambos os hosts como raiz, coloque o cluster no modo de manutenção:

   # crm configure property maintenance-mode="true"

2. Confirme o modo de manutenção:

   # crm status

   A saída precisa indicar que o gerenciamento de recursos está desativado, conforme mostrado no exemplo a seguir:

   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
   * Last updated: Fri May 14 15:26:08 2021
   * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
   * 2 nodes configured
   * 0 resource instances configured
   
               *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * No resources

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.

Criar os recursos do dispositivo de isolamento

Para cada VM no cluster, crie um recurso de cluster para o dispositivo de isolamento que pode reiniciá-la. 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:

   # crm configure primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \
     op monitor interval="300s" timeout="120s" \
     op start interval="0" timeout="60s" \
     params port="PRIMARY_VM_NAME" zone="PRIMARY_ZONE" \
     project="CLUSTER_PROJECT_ID" \
     pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

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

   # crm configure location FENCING_LOCATION_NAME_PRIMARY_VM \
     FENCING_RESOURCE_PRIMARY_VM -inf: "PRIMARY_VM_NAME"

3. Confirme a configuração recém-criada:

   # crm config show related:FENCING_RESOURCE_PRIMARY_VM

   O resultado será semelhante a:

   primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \
           op monitor interval=300s timeout=120s \
           op start interval=0 timeout=60s \
           params PRIMARY_VM_NAME zone=PRIMARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
   location FENCING_RESOURCE_PRIMARY_VM FENCING_RESOURCE_PRIMARY_VM -inf: PRIMARY_VM_NAME

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

   # crm configure primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
     op monitor interval="300s" timeout="120s" \
     op start interval="0" timeout="60s" \
     params port="SECONDARY_VM_NAME" zone="SECONDARY_VM_ZONE" \
     project="CLUSTER_PROJECT_ID" \
     pcmk_reboot_timeout=300 pcmk_monitor_retries=4

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

   # crm configure location FENCING_LOCATION_NAME_SECONDARY_VM \
     FENCING_RESOURCE_SECONDARY_VM -inf: "SECONDARY_VM_NAME"

6. Confirme a configuração recém-criada:

   # crm config show related:FENCING_RESOURCE_SECONDARY_VM

   O resultado será semelhante a:

   primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
           op monitor interval=300s timeout=120s \
           op start interval=0 timeout=60s \
           params SECONDARY_VM_NAME zone=SECONDARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
   location FENCING_RESOURCE_SECONDARY_VM FENCING_RESOURCE_SECONDARY_VM -inf: 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

Agora que você criou os diretórios do sistema de arquivos compartilhados, defina os recursos do cluster.

1. Configure os recursos do sistema de arquivos dos diretórios específicos da instância.

   # crm configure primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   Substitua:

   • ASCS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso do cluster para o sistema de arquivos ASCS.
   • NFS_PATH: especifica o caminho para o sistema de arquivos NFS do ASCS.
   • 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.

   # crm configure primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   Substitua:

   • ERS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso de cluster para o sistema de arquivos ERS.
   • NFS_PATH: especifica o caminho para o sistema de arquivos NFS do ERS.
   • 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 número ASCS.

2. Confirme a configuração recém-criada:

   # crm configure show ASCS_FILE_SYSTEM_RESOURCE ERS_FILE_SYSTEM_RESOURCE

   O resultado será semelhante a:

   primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \
       params device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype=nfs \
       op start timeout=60s interval=0 \
       op stop timeout=60s interval=0 \
       op monitor interval=20s timeout=40s
   primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
       params device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype=nfs \
       op start timeout=60s interval=0 \
       op stop timeout=60s interval=0 \
       op monitor interval=20s timeout=40s

Criar os recursos da verificação de integridade

1. Configure os recursos do cluster para as verificações de integridade do ASCS e ERS:

   # crm configure primitive ASCS_HEALTH_CHECK_RESOURCE anything \
     params binfile="/usr/bin/socat" \
     cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
     op monitor timeout=20s interval=10s \
     op_params depth=0

   # crm configure primitive ERS_HEALTH_CHECK_RESOURCE anything \
     params binfile="/usr/bin/socat" \
     cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
     op monitor timeout=20s interval=10s \
     op_params depth=0

2. Confirme a configuração recém-criada:

   # crm configure show ERS_HEALTH_CHECK_RESOURCE ASCS_HEALTH_CHECK_RESOURCE

   O resultado será semelhante a:

   primitive ERS_HEALTH_CHECK_RESOURCE anything \
           params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
           op monitor timeout=20s interval=10s \
           op_params depth=0
       primitive ASCS_HEALTH_CHECK_RESOURCE anything \
           params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
           op monitor timeout=20s interval=10s \
           op_params depth=0

Criar os recursos do VIP

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.

   # crm configure primitive ASCS_VIP_RESOURCE IPaddr2 \
    params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

   # crm configure primitive ERS_VIP_RESOURCE IPaddr2 \
    params ip=ERS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

3. Confirme a configuração recém-criada:

   # crm configure show ASCS_VIP_RESOURCE ERS_VIP_RESOURCE

   O resultado será semelhante a:

       primitive ASCS_VIP_RESOURCE IPaddr2 \
           params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
           op monitor interval=3600s timeout=60s
       primitive ERS_VIP_RESOURCE IPaddr2 \
           params ip=ERS_VIP_RESOURCE cidr_netmask=32 nic=eth0 \
           op monitor interval=3600s timeout=60s

Ver os recursos definidos

1. Para ver todos os recursos que você definiu até o momento, digite o seguinte comando:

   # crm status

   O resultado será semelhante a:

   Stack: corosync
   Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
   Last updated: Wed May 26 19:10:10 2021
   Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
   
   2 nodes configured
   8 resource instances configured
   
                 *** Resource management is DISABLED ***
     The cluster will not attempt to start, stop or recover services
   
   Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full list of resources:
   
    fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
    fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
    filesystem-rsc-nw-aha-ascs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
    filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
    health-check-rsc-nw-ha-ascs     (ocf::heartbeat:anything):      Stopped (unmanaged)
    health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
    vip-rsc-nw-aha-ascs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
    vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

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:

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

   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:

   # crm_standby -v on -N ${HOSTNAME};

   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:

   # crm status

   O resultado será semelhante a:

   Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
   
    2 nodes configured
    8 resource instances configured
   
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
   
    Full list of resources:
   
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
   

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:

   # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

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:

   # crm_standby -v on -N ${HOSTNAME};

   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:

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

   # crm_standby -v off -N ${HOSTNAME};

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

      Para mais informações, consulte o documento do SUSE Como desativar serviços systemd das instâncias do ASCS e do ERS SAP (em inglês).

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

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. Ative o pacote sap-suse-cluster-connector adicionando as seguintes linhas aos perfis de instâncias de ASCS e ERS:

   #-----------------------------------------------------------------------
   # SUSE HA library
   #-----------------------------------------------------------------------
   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
   

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

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

Adicionar o usuário sidadm ao grupo de usuários haclient

Quando você instalou sap-suse-cluster-connector, a instalação criou um grupo de usuários haclient. Para permitir que o usuário SID_LCadm trabalhe com o cluster, adicione-o ao grupo de usuários haclient.

1. Nos dois servidores, adicione o usuário SID_LCadm ao grupo de usuários haclient:

   # usermod -aG haclient SID_LCadm

Configurar os recursos do cluster para ASCS e ERS

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

   # crm configure property maintenance-mode="true"

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

   # crm status

   Se o cluster estiver no modo de manutenção, o status incluirá as seguintes linhas:

                 *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services

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

   ENSA1

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

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10

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

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

   3. Confirme a configuração recém-criada:

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      O resultado será semelhante a:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      meta priority=1000
      

   ENSA2

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

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60

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

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true

   3. Confirme a configuração recém-criada:

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      O resultado será semelhante a:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      

Configurar grupos de recursos e restrições de local

1. Agrupe os recursos ASAS e ERS. Para exibir os nomes de todos os recursos definidos anteriormente, insira o comando crm resource status:

   # crm configure group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \
     ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
     ASCS_INSTANCE_RESOURCE \
     meta resource-stickiness=3000

   Substitua:

   • 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, nw1_ASCS00_group
   • ASCS_FILE_SYSTEM_RESOURCE: especifica o nome do recurso do cluster que você definiu para o sistema de arquivos ASCS anteriormente.
   • ASCS_HEALTH_CHECK_RESOURCE: especifica o nome do recurso do cluster que você definiu para a verificação de integridade do ASCS anteriormente.
   • ASCS_VIP_RESOURCE: especifique o nome do recurso do cluster que você definiu para o VIP do ASCS antes.
   • ASCS_INSTANCE_RESOURCE: especifica anteriormente o nome do recurso do cluster que você definiu para a instância do ASCS.

   # crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
     ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
     ERS_INSTANCE_RESOURCE

   Substitua:

   • 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_ERS instance_group". Exemplo, nw1_ERS10_group
   • ERS_FILE_SYSTEM_RESOURCE: especifica anteriormente o nome do recurso do cluster que você definiu para o sistema de arquivos ERS.
   • ERS_HEALTH_CHECK_RESOURCE: especifique o nome do recurso do cluster que você definiu para a verificação de integridade do ERS anteriormente.
   • ERS_VIP_RESOURCE: especifique o nome do recurso do cluster que você definiu para o VIP do ERS antes.
   • ERS_INSTANCE_RESOURCE: especifique o nome do recurso de cluster que você definiu para a instância do ERS antes.

2. Confirme a configuração recém-criada:

   # crm configure show type:group

   O resultado será semelhante a:

   group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
   group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE \
           meta resource-stickiness=3000

3. Crie as restrições de colocation:

   ENSA1

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

   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:

      # crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID eq 1

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

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   4. Confirme a configuração recém-criada:

      # crm configure show type:colocation type:location type:order

      O resultado será semelhante a:

      order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false
      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID eq 1

   ENSA2

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

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

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   3. Confirme a configuração recém-criada:

      # crm configure show type:colocation type:order

      O resultado será semelhante a:

      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      order ORD_SAP_SID_FIRST_START_ASCS  Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false

4. Desative o modo de manutenção.

   # crm configure property maintenance-mode="false"

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:

   # crm status

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

   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
     * Last updated: Thu May 20 16:58:46 2021
     * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
     * 2 nodes configured
     * 10 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Active Resources:
     * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
     * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
     * Resource Group: ascs-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
       * health-check-rsc-nw-ha-ascs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
       * vip-rsc-nw-aha-ascs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
       * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
     * Resource Group: ers-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
       * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
       * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
       * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started 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:

   20.05.2021 01:33:25
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
   HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
   HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
   HAActiveNode: nw-ha-vm-1
   HANodes: nw-ha-vm-1, nw-ha-vm-2

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

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   O resultado será semelhante a:

   20.05.2021 01:37:19
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
   SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java 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 (vh-ascs-aha_AHA_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active

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

   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
   * Last updated: Fri May 21 22:31:32 2021
   * Last change:  Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1
   * 2 nodes configured
   * 10 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
   * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
   * Resource Group: scs-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
     * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
     * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
     * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
   * Resource Group: ers-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
     * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
     * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1

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:

   # crm 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 em informações de diagnóstico do SLES.

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 for um problema de infraestrutura do Google Cloud, transfere o tíquete para o componente BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE do Google Cloud.

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:

• Práticas recomendadas do SUSE

• 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