Esta página foi traduzida pela API Cloud Translation.

Terraform: guia de configuração de clusters de alta disponibilidade para SAP NetWeaver no RHEL

Neste guia, mostramos como automatizar a implantação de um cluster de alta disponibilidade (HA, na sigla em inglês) do Red Hat Enterprise Linux (RHEL) otimizado para desempenho para o SAP NetWeaver.

O guia usa o Terraform para implantar duas máquinas virtuais (VMs) do Compute Engine, um endereço IP virtual (VIP) com a implementação de um balanceador de carga de rede de passagem interna e um cluster de HA baseado em SO, de acordo com as práticas recomendadas do Google Cloud, SAP e do fornecedor do SO.

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

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

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

O sistema que este guia implanta

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

Visão geral de um cluster de alta disponibilidade do Linux para um sistema SAP NetWeaver de nó único

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

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

Informações relacionadas do RHEL

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

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 criar uma rede VPC para o projeto, siga estas etapas:

Crie uma rede de modo personalizado. Para mais informações, consulte Como criar uma rede de modo personalizado.
Crie uma sub-rede e especifique a região e o intervalo de IP. Para mais informações, consulte Como adicionar 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.

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 criar as regras de firewall para seu projeto, consulte Como criar regras de firewall.

Como criar um cluster Linux de alta disponibilidade para SAP NetWeaver

As instruções a seguir usam um arquivo de configuração do Terraform para criar um cluster de alta disponibilidade do RHEL para SAP NetWeaver com duas VMs do Compute Engine. As VMs do Compute Engine são criadas em duas zonas de destino em uma configuração de failover automático para serviços centrais do SAP e enfileiram replicação.

Defina as opções de configuração do cluster de alta disponibilidade do SAP NetWeaver em um arquivo de configuração do Terraform.

Abra o Cloud Shell.

Acessar o Cloud Shell
Faça o download do arquivo de configuração sap_nw_ha.tf para o cluster de alta disponibilidade do SAP NetWeaver para o diretório de trabalho:
```
$ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/terraform/sap_nw_ha.tf
```
Observação: verifique se há apenas um arquivo de configuração do Terraform no seu diretório de trabalho.
Abra o arquivo sap_nw_ha.tf no editor de código do Cloud Shell.

Para abrir o editor de código, clique no ícone de lápis, no canto superior direito da janela do terminal do Cloud Shell.

No arquivo sap_nw_ha.tf, atualize os valores do argumento substituindo o conteúdo dentro das aspas duplas pelos valores da sua instalação. Os argumentos são descritos na tabela a seguir.

Argumento	Tipo de dado	Descrição
`source`	String	Especifica o local e a versão do módulo do Terraform a serem usados durante a implantação. O arquivo de configuração `sap_nw_ha.tf` inclui duas instâncias do argumento `source`: uma que está ativa e outra incluída como um comentário. O argumento `source`, que é ativo por padrão, especifica `latest` como a versão do módulo. A segunda instância do argumento `source`, que, por padrão, é desativada por um caractere `#` inicial, especifica um carimbo de data/hora que identifica uma versão do módulo. Se você precisar que todas as implantações usem a mesma versão do módulo, remova o caractere `#` líder do argumento `source` que especifica o carimbo de data/hora da versão e o adiciona aos `source` que especifica `latest`.
`project_id`	String	Especifique o ID do projeto do Google Cloud em que você está implantando esse sistema. Por exemplo, `my-project-x`.
`machine_type`	String	Especifique o tipo de máquina virtual (VM) do Compute Engine em que você precisa executar o sistema SAP. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido com um número de vCPUs o mais próximo possível do necessário, mesmo que maior. Após a conclusão da implantação, modifique o número de vCPUs e a quantidade de memória. Por exemplo, `n1-highmem-32`.
`network`	String	Especifique o nome da rede em que você precisa criar o balanceador de carga que gerencia o VIP. Se você estiver usando uma rede VPC compartilhada, será preciso adicionar o ID do projeto host como um diretório pai do nome da rede. Por exemplo, `HOST_PROJECT_ID/NETWORK_NAME`.
`subnetwork`	String	O nome da sub-rede criada em um passo anterior. Se você estiver implantando em uma VPC compartilhada, especifique esse valor como `SHARED_VPC_PROJECT_ID/SUBNETWORK`. Por exemplo, `myproject/network1`.
`linux_image`	String	Especifique o nome da imagem do sistema operacional Linux em que você quer implantar o sistema SAP. Por exemplo, `rhel-9-2-sap-ha`. Para ver a lista de imagens do sistema operacional disponíveis, consulte a página Imagens no console do Google Cloud.
`linux_image_project`	String	Especifique o projeto do Google Cloud que contém a imagem que você especificou para o argumento `linux_image`. Talvez seja seu próprio projeto ou um projeto de imagem do Google Cloud. Para uma imagem do Compute Engine, especifique `rhel-sap-cloud`. Para encontrar o projeto de imagem do sistema operacional, consulte Detalhes do sistema operacional.
`sap_primary_instance`	String	Especifique um nome para a instância de VM para o sistema SAP NetWeaver principal. Este é seu local ASCS inicial. O nome pode conter letras minúsculas, números ou hífens e não pode exceder 13 caracteres.
`sap_primary_zone`	String	Especifique uma zona em que o sistema SAP NetWeaver principal está implantado. As zonas principal e secundária precisam estar na mesma região. Por exemplo, `us-east1-b`
`sap_secondary_instance`	String	Especifique um nome para a instância de VM para o sistema SAP NetWeaver secundário. Este é seu local inicial do ERS. O nome pode conter letras minúsculas, números ou hífens e não pode exceder 13 caracteres.
`sap_secondary_zone`	String	Especifique uma zona em que o sistema secundário do SAP NetWeaver está implantado. As zonas principal e secundária precisam estar na mesma região. Por exemplo, `us-east1-c`
`nfs_path`	String	Especifique o ponto de montagem do NFS para o sistema de arquivos compartilhados. Por exemplo, `10.163.58.114:/ssd_nfs`. Observação: o ponto de montagem do NFS para o sistema de arquivos compartilhados precisa estar vazio antes de aplicar a configuração do Terraform.
`sap_sid`	String	Especifique um ID do sistema SAP. O ID precisa ter três caracteres alfanuméricos e começar com uma letra. Todas as letras precisam estar em maiúsculas. Por exemplo, `ED1`.
`hc_firewall_rule_name`	String	Opcional. Especifique um nome para a regra de firewall de verificação de integridade. O valor padrão é `SAP_SID-hc-allow`.
`hc_network_tag`	String	Opcional. Especifique uma ou mais tags de rede separadas por vírgula que você quer associar às instâncias de VM para a regra de firewall de verificação de integridade. O valor padrão é `SAP_SID-hc-allow-tag`.
`scs_inst_group_name`	String	Opcional. Especifique um nome para o grupo de instâncias do ASCS. O valor padrão é `SAP_SID-scs-ig`.
`scs_hc_name`	String	Opcional. Especifique um nome para a verificação de integridade do ASCS. O valor padrão é `SAP_SID-scs-hc`.
`scs_hc_port`	String	Opcional. Especifique uma porta para a verificação de integridade do ASCS. Para evitar conflitos com outros serviços, designe o número da porta da verificação de integridade do ASCS no intervalo particular 49152-65535. O valor padrão é `60000`.
`scs_vip_address`	String	Opcional. Especifique um endereço IP não utilizado na sub-rede especificada anteriormente em `subnetwork` para usar como endereço IP virtual para a instância do ASCS. Se nada for especificado, os scripts de implantação selecionarão automaticamente um endereço IP não utilizado da sub-rede especificada.
`scs_vip_name`	String	Opcional. Especifique um nome para o IP virtual do ASCS. O valor padrão é `SAP_SID-scs-vip`.
`scs_backend_svc_name`	String	Opcional. Especifique um nome para o serviço de back-end do ASCS. O valor padrão é `SAP_SID-scs-backend-svc`.
`scs_forw_rule_name`	String	Opcional. Especifique um nome para a regra de encaminhamento do ASCS. O valor padrão é `SAP_SID-scs-fwd-rule`.
`ers_inst_group_name`	String	Opcional. Especifique um nome para o grupo de instâncias do ERS. O valor padrão é `SAP_SID-ers-ig`.
`ers_hc_name`	String	Opcional. Especifique um nome para a verificação de integridade do ERS. O valor padrão é `SAP_SID-ers-hc`.
`ers_hc_port`	String	Opcional. Especifique uma porta para a verificação de integridade do ERS. Para evitar conflitos com outros serviços, designe o número da porta para a verificação de integridade do ERS no intervalo particular, 49152-65535. O valor padrão é `60010`.
`ers_vip_address`	String	Opcional. Especifique um endereço IP não utilizado na sub-rede especificada anteriormente em `subnetwork` para usar como endereço IP virtual para a instância do ERS. Se nada for especificado, os scripts de implantação selecionarão automaticamente um endereço IP não utilizado da sub-rede especificada.
`ers_vip_name`	String	Opcional. Especifique um nome para o IP virtual do ERS. O valor padrão é `SAP_SID-ers-vip`.
`ers_backend_svc_name`	String	Opcional. Especifique um nome para o serviço de back-end do ERS. O valor padrão é `SAP_SID-ers-backend-svc`.
`ers_forw_rule_name`	String	Opcional. Especifique um nome para a regra de encaminhamento do ERS. O valor padrão é `SAP_SID-ers-fwd-rule`.
`usr_sap_size`	Número inteiro	Opcional. Especifique o tamanho do disco `/usr/sap` em GB. O tamanho mínimo é 8 GB. O valor padrão é `8`.
`sap_mnt_size`	Número inteiro	Opcional. Especifique o tamanho do disco `/sapmnt` em GB. O tamanho mínimo é 8 GB. O valor padrão é `8`.
`swap_size`	Número inteiro	Opcional. Especifique o tamanho do volume de troca em GB. O tamanho mínimo é 8 GB. O valor padrão é `8`.
`sap_scs_instance_number`	String	Opcional. Especifique o número da instância do ASCS. O `sap_scs_instance_number` precisa ser um número de dois dígitos. Se você precisar especificar um número de dígito único, adicione um `0` na frente do número. Por exemplo, `07`. O valor padrão é `00`.
`sap_ers_instance_number`	String	Opcional. Especifique o número da instância do ERS. O `sap_ers_instance_number` precisa ser um número de dois dígitos. Se você precisar especificar um número de dígito único, adicione um `0` na frente do número. Por exemplo, `07`. O valor padrão é `10`.
`sap_nw_abap`	Booleano	Opcional. Especifique se você está implantando uma pilha ABAP ou Java do SAP NetWeaver. Para uma pilha Java do SAP NetWeaver, especifique `false`. O valor padrão é `true`.
`pacemaker_cluster_name`	String	Opcional. Especifique um nome para o cluster do marca-passo. O valor padrão é `SAP_SID-cluster`.
`public_ip`	Booleano	Opcional. Para criar um endereço IP público temporário para as instâncias de VM, defina `public_ip` como `true`. O valor padrão é `false`. Cuidado: quando `public_ip` for `false`, verifique se você tem um gateway NAT configurado com uma tag de rede definida para a VM ou você forneceu à VM outra rota para a Internet. Se não houver rota para a Internet, a instalação falhará.
`service_account`	String	Opcional. Especifique o endereço de e-mail de uma conta de serviço gerenciada pelo usuário que será usada pelas VMs do host e pelos programas executados nas VMs do host. Por exemplo, `svc-acct-name@project-id.iam.gserviceaccount.com`. Se você especificar esse argumento sem um valor ou omiti-lo, o script de instalação usará a conta de serviço padrão do Compute Engine. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.
`network_tags`	String	Opcional. Especifique uma ou mais tags de rede separadas por vírgula que você quer associar às suas instâncias de VM para fins de firewall ou roteamento. Uma tag de rede para os componentes do ILB é adicionada automaticamente às Tags de rede da VM. Se `public_ip = false` e você não especificar uma tag de rede, forneça outro meio de acesso à Internet.
`sap_deployment_debug`	Booleano	Opcional. Somente quando o Cloud Customer Care solicitar que você ative a depuração da sua implantação, especifique `true`, o que faz com que a implantação gere registros de implantação detalhados. O valor padrão é `false`.
`primary_reservation_name`	String	Opcional. Para usar uma reserva de VM do Compute Engine específica para provisionar a instância da VM que hospeda a instância principal do SAP HANA do cluster de alta disponibilidade, especifique o nome da reserva. Por padrão, o script de instalação seleciona qualquer reserva disponível do Compute Engine com base nas condições a seguir. Para que uma reserva seja utilizável, independentemente de você especificar um nome ou o script de instalação a selecionar automaticamente, a reserva precisa ser definida com o seguinte: A opção `specificReservationRequired` está definida como `true` ou, no console do Google Cloud, a opção Selecionar uma reserva específica está selecionada. Alguns tipos de máquina do Compute Engine são compatíveis com plataformas de CPU que não são cobertas pela certificação SAP do tipo de máquina. Se a reserva de destino for de qualquer um dos seguintes tipos de máquina, a reserva precisará especificar as plataformas mínimas de CPU, conforme indicado: `n1-highmem-32`: Intel Broadwell `n1-highmem-64`: Intel Broadwell `n1-highmem-96`: Intel Skylake `m1-megamem-96`: Intel Skylake As plataformas de CPU mínimas para todos os outros tipos de máquina que são certificadas pela SAP para uso no Google Cloud estão em conformidade com o requisito de CPU mínimo da SAP.
`secondary_reservation_name`	String	Opcional. Para usar uma reserva de VM específica do Compute Engine para provisionar a instância da VM que hospeda a instância secundária do SAP HANA do cluster de alta disponibilidade, especifique o nome da reserva. Por padrão, o script de instalação seleciona qualquer reserva disponível do Compute Engine com base nas condições a seguir. Para que uma reserva seja utilizável, independentemente de você especificar um nome ou o script de instalação a selecionar automaticamente, a reserva precisa ser definida com o seguinte: A opção `specificReservationRequired` está definida como `true` ou, no console do Google Cloud, a opção Selecionar uma reserva específica está selecionada. Alguns tipos de máquina do Compute Engine são compatíveis com plataformas de CPU que não são cobertas pela certificação SAP do tipo de máquina. Se a reserva de destino for de qualquer um dos seguintes tipos de máquina, a reserva precisará especificar as plataformas mínimas de CPU, conforme indicado: `n1-highmem-32`: Intel Broadwell `n1-highmem-64`: Intel Broadwell `n1-highmem-96`: Intel Skylake `m1-megamem-96`: Intel Skylake As plataformas de CPU mínimas para todos os outros tipos de máquina que são certificadas pela SAP para uso no Google Cloud estão em conformidade com o requisito de CPU mínimo da SAP.
`can_ip_forward`	Booleano	Especifique se o envio e o recebimento de pacotes com IPs de origem ou de destino não correspondentes é permitido, o que permite que uma VM funcione como um roteador. O valor padrão é `true`. Se você pretende usar apenas os balanceadores de carga internos do Google para gerenciar endereços IP virtuais para as VMs implantadas, defina o valor como `false`. Um balanceador de carga interno é implantado automaticamente como parte dos modelos de alta disponibilidade.

Veja no exemplo a seguir um arquivo de configuração concluído que define um cluster de alta disponibilidade para SAP NetWeaver. O cluster usa um balanceador de carga de rede de passagem interno para gerenciar o VIP.

O Terraform implanta os recursos do Google Cloud definidos no arquivo de configuração, e os scripts de inicialização assumem a configuração do sistema operacional e do cluster de alta disponibilidade do Linux.

Para deixar claro, os comentários no arquivo de configuração são omitidos no exemplo.

   # ...
     module "sap_nw_ha" {
     source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # By default, this source file uses the latest release of the terraform module
   # for SAP on Google Cloud.  To fix your deployments to a specific release
   # of the module, comment out the source argument above and uncomment the source argument below.
   #
   # source = "https://storage.googleapis.com/cloudsapdeploy/terraform/202201240926/terraform/sap_nw_ha/sap_nw_ha_module.zip"
   #
   # ...
   #
   project_id = "example-project-123456"
   machine_type = "n2-highmem-32"
   network = "example-network"
   subnetwork = "example-subnet-us-central1"
   linux_image = "rhel-8-4-sap-ha"
   linux_image_project = "rhel-sap-cloud"

   sap_primary_instance = "nw-ha-vm-1"
   sap_primary_zone = "us-central1-a"

   sap_secondary_instance = "nw-ha-vm-2"
   sap_secondary_zone = "us-central1-c"

   nfs_path = "10.223.55.130:/pr1_nw"

   sap_sid = "PR1"
   # ...
}

Para inicializar seu diretório de trabalho atual e fazer o download do plug-in do provedor do Terraform e dos arquivos de módulo para o Google Cloud:
```
terraform init
```
O comando terraform init prepara seu diretório de trabalho para outros comandos do Terraform.

Para forçar uma atualização do plug-in do provedor e dos arquivos de configuração no diretório de trabalho, especifique a sinalização --upgrade. Se a sinalização --upgrade for omitida e você não fizer nenhuma alteração no seu diretório de trabalho, o Terraform usará as cópias armazenadas em cache local, mesmo se latest for especificado na source URL
```
terraform init --upgrade 
```
Como opção, crie o plano de execução do Terraform:
```
terraform plan
```
O comando terraform plan mostra as alt erações exigidas pela configuração atual. Se você pular essa etapa, o comando terraform apply criará automaticamente um novo plano e solicitará que você o aprove.
Aplique o plano de execução:
```
terraform apply
```
Quando for solicitada a aprovação das ações, digite yes.

O comando terraform apply configura a infraestrutura do Google Cloud e, em seguida, controla manualmente um script que configura o cluster de alta disponibilidade de acordo com os argumentos definidos no arquivo de configuração do Terraform.

Embora o Terraform tenha controle, as mensagens de status são gravadas no Cloud Shell. Depois que o script é invocado, as mensagens de status são gravadas no Logging e podem ser visualizadas no console do Google Cloud, conforme descrito em Verificar os registros do Logging.

O tempo até a conclusão pode variar, mas o processo todo geralmente leva menos de 30 minutos.

Como verificar a implantação do sistema de alta disponibilidade do SAP NetWeaver

A verificação de um cluster de alta disponibilidade do SAP NetWeaver envolve vários procedimentos diferentes:

Verificar os registros
Verificar a configuração da VM

Verificar os registros

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
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.
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. Abra o Cloud Shell.
    
    Acessar o Cloud Shell
  3. Acesse seu diretório de trabalho e exclua a implantação para limpar as VMs e os discos permanentes da instalação com falha:
```
terraform destroy
```
    Quando for solicitada a aprovação da ação, digite yes.
  4. Execute a implantação novamente.

Verificar a configuração da VM

Depois de implantar as instâncias de VM sem erros, conecte-se a cada VM usando SSH. Na página Instâncias de VM do Compute Engine, clique no botão "SSH" para cada instância de VM ou use seu método de SSH preferido.
Mude para o usuário raiz.
```
sudo su -
```

No prompt de comando, insira df -h. Verifique se você vê uma saída que inclui os diretórios /usr/sap, como /usr/sap/trans.

nw-ha-vm-1:~ # df -h
Filesystem                             Size  Used Avail Use% Mounted on
...
/dev/mapper/vg_usrsap-vol              8.0G  242M  7.8G   3% /usr/sap
/dev/mapper/vg_sapmnt-vol              8.0G   90M  7.9G   2% /sapmnt
10.95.255.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
10.95.255.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
10.95.255.130:/pr1_nw/usrsapPR1ASCS00 1007G     0  956G   0% /usr/sap/PR1/ASCS00
...

O autofs é configurado automaticamente durante a implantação para montar os diretórios de arquivos compartilhados comuns quando eles são acessados pela primeira vez. A montagem dos diretórios ASCSASCS_INSTANCE_NUMBER e ERSERS_INSTANCE_NUMBER é gerenciada pelo software do cluster, que também é configurado durante a implantação.

Verifique o status do novo cluster inserindo o comando de status: pcs status

Você verá resultados semelhantes ao exemplo a seguir, em que ambas as instâncias da VM são iniciadas e nw-ha-vm-1 é a instância primária ativa:

nw-ha-vm-1:~ # pcs status
Cluster name: pr1-cluster
Cluster Summary:
* Stack: corosync
* Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.5-ba59be7122) - partition with quorum
* Last updated: Mon Aug 29 18:03:22 2022
* Last change:  Mon Aug 29 17:58:21 2022 by root via cibadmin on nw-ha-vm-1
* 2 nodes configured
* 8 resource instances configured
Node List:
* Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
Full List of Resources:
* fence-PR1-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
* fence-PR1-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
* file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
* file-system-PR1-ERS10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
* health-check-PR1-ASCS00    (service:haproxy@PR1ASCS):     Started nw-ha-vm-1
* health-check-PR1-ERS10    (service:haproxy@PR1ERS):     Started nw-ha-vm-2
* vip-PR1-ASCS00    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-1
* vip-PR1-ERS10    (ocf::heartbeat:IPaddr2):     Started nw-ha-vm-2
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Teste a configuração do balanceador de carga ASCS e ERS usando o utilitário socat:

Em cada instância de VM, inicie temporariamente um processo socat que retorne o próprio nome de host:

socat TCP-LISTEN:80,bind=0.0.0.0,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; echo $(hostname)" &

Em cada nó, use curl e tente alcançar os seguintes endereços IP e nomes de host. Os endereços IP e nomes de host podem ser encontrados em /etc/hosts.
- 127.0.0.1
- localhost
- ASCS_VIRTUAL_HOST_NAME
- ASCS_IP_ADDRESS
- ERS_VIRTUAL_HOST_NAME
- ERS_IP_ADDRESS
- Nome VIP do SCS, especificado para o parâmetro scs_vip_name
- Endereço IP do SCS, especificado para o parâmetro scs_vip_address
- Nome VIP do ERS, especificado para o parâmetro ers_vip_name
- Endereço IP do ERS VIP, especificado para o parâmetro ers_vip_address

Veja a seguir um exemplo de saída desse teste:

example-nw1:~ # cat /etc/hosts
...
10.128.1.182 example-nw1.c.myproject.internal example-nw1
10.128.1.169 example-nw2.c.myproject.internal example-nw2
10.128.1.46 pr1-scs-vip.c.myproject.internal pr1-scs-vip
10.128.0.75 pr1-ers-vip.c.myproject.internal pr1-ers-vip
example-nw1:~ # curl 127.0.0.1
example-nw1
example-nw1:~ # curl localhost
example-nw1
example-nw1:~ # curl example-nw1
example-nw1
example-nw1:~ # curl 10.128.1.182
example-nw1
example-nw1:~ # curl example-nw2
example-nw2
example-nw1:~ # curl 10.128.1.169
example-nw2
example-nw1:~ # curl pr1-scs-vip
example-nw1
example-nw1:~ # curl 10.128.1.46
example-nw1
example-nw1:~ # curl pr1-ers-vip
example-nw2
example-nw1:~ # curl 10.128.0.75
example-nw2

Se você estiver usando o RHEL for SAP 9.0 ou posterior, verifique se os pacotes chkconfig e compat-openssl11 estão instalados na instância de VM.

Para mais informações da SAP, consulte a Nota SAP 3108316 – Red Hat Enterprise Linux 9.x: instalação e configuração .

Se algum dos passos de validação mostrar que a instalação falhou:

Resolva os erros.
Abra o Cloud Shell.

Acessar o Cloud Shell
Acesse o diretório que contém o arquivo de configuração do Terraform.
Exclua a implantação:
```
terraform destroy
```
Quando for solicitada a aprovação da ação, digite yes.
Execute a implantação novamente.

Validar a instalação do agente do Google Cloud para SAP

Depois de implantar uma VM e instalar o sistema SAP, confirme se o agente do Google Cloud para SAP está funcionando corretamente.

Verificar se o agente do Google Cloud para SAP está em execução

Para verificar se o agente está em execução, siga estas etapas:

Estabeleça uma conexão SSH com a instância do Compute Engine.

Execute este comando:

systemctl status google-cloud-sap-agent

Se o agente estiver funcionando corretamente, a saída conterá active (running). Por exemplo:

google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

Se o agente não estiver em execução, reinicie-o.

Verificar se o SAP Host Agent está recebendo métricas

Para verificar se as métricas de infraestrutura são coletadas pelo agente do Google Cloud para SAP e enviadas corretamente ao agente de host da SAP, siga estas etapas:

No sistema SAP, insira a transação ST06.
No painel de visão geral, verifique a disponibilidade e o conteúdo dos seguintes campos para a configuração completa da infraestrutura de monitoramento da SAP e do Google:
- Provedor de nuvem: Google Cloud Platform
- Acesso ao monitoramento avançado: TRUE
- Detalhes do monitoramento avançado: ACTIVE

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.

Remova o cluster do modo de manutenção:

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

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

# groupadd -g GID_SAPINST sapinst
# groupadd -g GID_SAPSYS sapsys
# useradd -u UID_SIDADM SID_LCadm -g sapsys
# usermod -a -G sapinst SID_LCadm
# useradd -u UID_SAPADM sapadm -g sapinst

# chown SID_LCadm:sapsys /usr/sap/SID/SYS
# chown SID_LCadm:sapsys /sapmnt/SID -R
# chown SID_LCadm:sapsys /usr/sap/trans -R
# chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
# chown SID_LCadm:sapsys /usr/sap/SID -R

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

# groupadd -g GID_SAPINST sapinst
# groupadd -g GID_SAPSYS sapsys
# useradd -u UID_SIDADM SID_LCadm -g sapsys
# usermod -a -G sapinst SID_LCadm
# useradd -u UID_SAPADM sapadm -g sapinst

# chown SID_LCadm:sapsys /usr/sap/SID
# chown SID_LCadm:sapsys /sapmnt/SID -R
# chown SID_LCadm:sapsys /usr/sap/trans -R
# chown SID_LCadm:sapsys /usr/sap/SID -R
# chown SID_LCadm:sapsys /usr/sap/SID/SYS

Substitua:

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

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

Group sapinst      1001
Group sapsys       1002
Group dbhshm       1003

User  en2adm       2001
User  sapadm       2002
User  dbhadm       2003

Instalar o componente ASCS

No servidor secundário, digite o seguinte comando para colocar o servidor secundário no modo de espera:
```
# pcs node standby
```
Colocar o servidor secundário no modo de espera consolida todos os recursos do cluster no servidor principal, o que simplifica a instalação.

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

# pcs status

A resposta será semelhante a:

Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured

   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]

   Full List of Resources:
     * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
       * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1

   Daemon Status:
     corosync: active/enabled

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.
Após a conclusão da configuração, remova a VM secundária do modo de espera:
```
# pcs node unstandby
```

Instalar o componente ERS

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"

No servidor principal, digite o seguinte comando para colocar o servidor principal no modo de espera:
```
# pcs node standby
```
Colocar o servidor principal no modo de espera consolida todos os recursos do cluster no servidor secundário, o que simplifica a instalação.
Confirme se o servidor principal está no modo de espera:
```
# pcs status
```
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.
Deixe a VM principal em espera para ativar as duas:
```
# pcs node unstandby
```

Configurar os serviços do SAP

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

Confirmar as entradas de serviço do SAP

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

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

Para mais informações sobre essas integrações, consulte as seguintes notas SAP:
- 3139184 - Linux: integração do systemd para sapstartsrv e SAP Host Agent
- 3115048 - sapstartsrv com suporte nativo a systemd do Linux
systemV
Este é um exemplo de como as entradas para os serviços ASCS e ERS no arquivo /usr/sap/sapservices quando você usa a integração systemV:
```
# LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
/usr/sap/hostctrl/exe/sapstartsrv \
pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
-D -u SID_LCadm
/usr/sap/hostctrl/exe/sapstartsrv \
pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
-D -u SID_LCadm
```
systemd
1. Verifique se o arquivo /usr/sap/sapservices contém entradas para os serviços ASCS e ERS. Confira abaixo um exemplo de como essas entradas aparecem no arquivo /usr/sap/sapservices quando você usa a integração systemd:
  systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
2. Desative a integração systemd nas instâncias do ASCS e do ERS:
  
  Cuidado: desativar a integração systemd também interrompe as instâncias do SAP.
  # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
3. Verifique se a integração com systemd está desativada:
  # systemctl list-unit-files | grep sap
  Uma saída semelhante ao exemplo a seguir significa que a integração com systemd está desativada. Alguns serviços, como saphostagent e saptune, estão ativados e outros desativados.
  SAPSID_ASCS_INSTANCE_NUMBER.service disabled SAPSID_ERS_INSTANCE_NUMBER.service disabled saphostagent.service enabled sapinit.service generated saprouter.service disabled saptune.service enabled

Interromper os serviços do SAP

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"

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

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

O resultado será semelhante a:

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

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

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

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

Exemplo:

#!/bin/sh

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

Editar os perfis do ASCS e do ERS

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
```
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
```
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).
Se necessário, edite os perfis ASCS e ERS para alterar o comportamento de inicialização do Enqueue Server e do Enqueue Replication Server.
ENSA1
Na seção Iniciar servidor de enfileiramento SAP do perfil do ASCS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.
```
Start_Program_01 = local $(_EN) pf=$(_PF)
```
Na seção Iniciar servidor de replicação de enfileiramento do perfil do ERS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.
```
Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)
```
ENSA2
Na seção Iniciar servidor de enfileiramento SAP do perfil do ASCS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.
```
Start_Program_01 = local $(_ENQ) pf=$(_PF)
```
Na seção Iniciar replicador de enfileiramento do perfil do ERS, se você vir Restart_Program_NN, altere "Restart" para "Start". conforme mostrado no exemplo a seguir.
```
Start_Program_00 = local $(_ENQR) pf=$(_PF) ...
```

Configurar os recursos do cluster para ASCS e ERS

Como raiz em um dos servidores, coloque o cluster no modo de manutenção:
```
# pcs property set maintenance-mode="true"
```
Confirme se o cluster está no modo de manutenção:
```
# pcs status
```

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

ENSA1

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

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

# pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

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

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

ENSA2

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

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

# pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000

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

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

Configurar as restrições de local e ordem

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

Defina a restrição do pedido inicial:

ENSA1

Crie uma restrição de posicionamento para impedir que os recursos ASCS sejam executados no mesmo servidor que os recursos do ERS:
```
# pcs constraint colocation add ERS_RESOURCE_GROUP with \
    ASCS_RESOURCE_GROUP -5000
```
Configure o ASCS para fazer failover ao servidor em que o ERS está sendo executado, o que é determinado pela sinalização runsersSID ser igual a 1:
```
# pcs constraint location ASCS_INSTANCE \
    rule score=2000 runs_ers_SID eq 1
```

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

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

ENSA2

Crie uma restrição de posicionamento para impedir que os recursos SCS sejam executados no mesmo servidor que os recursos do ERS:
```
# pcs constraint colocation add ERS_RESOURCE_GROUP  with \
    ASCS_RESOURCE_GROUP -5000
```

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

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

Verifique as restrições:

# pcs constraint

A resposta será semelhante a esta:

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

Como raiz de qualquer um dos servidores, desative o modo de manutenção do cluster:
```
# pcs property set maintenance-mode="false"
```

Configurar o conector de cluster do Red Hat para SAP

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

Adicione o usuário administrativo da SAP ao grupo haclient:
```
usermod -a -G haclient SID_LCadm
```
Edite os perfis de instância da SAP adicionando as seguintes linhas ao final de cada perfil: Os perfis podem ser encontrados no diretório /sapmnt/SID/profiles.
```
service/halib = $(DIR_CT_RUN)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_cluster_connector
```
Se os recursos da instância do ASCS e do ERS estiverem em execução no cluster, desative-os:
```
pcs resource disable ERS_INSTANCE_RESOURCE
pcs resource disable ASCS_INSTANCE_RESOURCE
```

Interrompa os serviços no host ASCS:

sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

Interrompa os serviços no host do ERS:

sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

Ative os recursos:

pcs resource enable ERS_INSTANCE_RESOURCE
pcs resource enable ASCS_INSTANCE_RESOURCE

Repita as etapas anteriores em cada host do cluster.

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

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

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

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

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

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

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

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

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

# pcs status

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

Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

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

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

Mude para o usuário SID_LCadm.
```
# su - SID_LCadm
```

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

> sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

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

HAGetFailoverConfig

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

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

> sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

O resultado será semelhante a:

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

No servidor em que o ASCS está ativo, como SID_LCadm, simule um failover:
```
> sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""
```
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.

Faça backup do seu sistema.
Como raiz no host com a instância SCS ativa, torne a interface de rede off-line:
```
$ ip link set eth0 down
```
Reconecte-se ao host usando o SSH e mude para o usuário raiz

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

 Stack: corosync
  Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Apr 13 05:21:21 2022
  Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2

  2 nodes configured
  10 resource instances configured

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

  Full list of resources:

  fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
  fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
   Resource Group: ascs-group
       ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
       ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
       ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
       ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   Resource Group: ers-group
       ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
       ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
       ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
       ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2

  Migration Summary:
  * Node nw-ha-vm-1:
  * Node nw-ha-vm-2:

Confirmar que as entradas de bloqueio foram mantidas

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

ENSA1

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

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

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
```
Quando o monitor enqt parar, saia dele digitando Ctrl + c.
Se preferir, como raiz em um dos servidores, monitore o failover do cluster:
```
# crm_mon
```

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

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

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

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
```
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.
Quando o ASCS estiver ativo, reinicialize o servidor.
Se preferir, como raiz em um dos servidores, monitore o failover do cluster:
```
# crm_mon
```
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
```

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

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:

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
```
Confirme que o nó principal não foi alterado:
```
$ pcs status
```

Avalie sua carga de trabalho do SAP NetWeaver

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

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

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

Solução de problemas

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

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

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

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

Suporte

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

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

Requisitos de suporte

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

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

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

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

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

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

A seguir

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

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

Terraform: guia de configuração de clusters de alta disponibilidade para SAP NetWeaver no RHEL

O sistema que este guia implanta

Pré-requisitos

Informações relacionadas do RHEL

Criar uma rede

Como configurar um gateway NAT

Como adicionar regras de firewall

Como criar um cluster Linux de alta disponibilidade para SAP NetWeaver

Como verificar a implantação do sistema de alta disponibilidade do SAP NetWeaver

Verificar os registros

Explorador de registros

Visualizador de registros legado

Verificar a configuração da VM

Validar a instalação do agente do Google Cloud para SAP

Verificar se o agente do Google Cloud para SAP está em execução

Verificar se o SAP Host Agent está recebendo métricas

Instalar ASCS e ERS

Preparar para a instalação

Instalar o componente ASCS

Instalar o componente ERS

Configurar os serviços do SAP

Confirmar as entradas de serviço do SAP

systemV

systemd

Interromper os serviços do SAP

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

Editar os perfis do ASCS e do ERS

ENSA1

ENSA2

Configurar os recursos do cluster para ASCS e ERS

ENSA1

ENSA2

Configurar as restrições de local e ordem

ENSA1

ENSA2

Configurar o conector de cluster do Red Hat para SAP

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

Validar e testar o cluster

Verifique a configuração do cluster

Simule um failover

Confirmar que as entradas de bloqueio foram mantidas

ENSA1

ENSA2

Simular um evento de manutenção do Compute Engine

Avalie sua carga de trabalho do SAP NetWeaver

Solução de problemas

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

Suporte

Requisitos de suporte

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

A seguir

`systemV`

`systemd`