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

Neste guia, você verá como automatizar a implantação de um cluster de alta disponibilidade (HA, na sigla em inglês) do SUSE Linux Enterprise Server (SLES) otimizado para desempenho para 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 interno de passagem, e um Cluster de alta disponibilidade 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 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.

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:

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

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:

  1. Crie uma rede de modo personalizado. Para mais informações, consulte Como criar uma rede de modo personalizado.

  2. 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 do SLES com dois sistemas SAP NetWeaver, um sistema SAP NetWeaver Host de único host principal em uma instância de VM e um sistema SAP NetWeaver em espera em outra instância de VM na mesma região do Compute Engine.

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

  1. Abra o Cloud Shell.

    Acessar o Cloud Shell

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

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

  4. 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, sles-15-sp5-sap. 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 suse-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.
    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 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 Inteiro Opcional. Especifique o tamanho do disco /sapmnt em GB. O tamanho mínimo é 8 GB. O valor padrão é 8.
    swap_size 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.
    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.

    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 interna para gerenciar o VIP.

    O Terraform implanta os recursos do Google Cloud definidos no arquivo de configuração, e os scripts 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 = "sles-15-sp3-sap"
   linux_image_project = "suse-sap-cloud"

   sap_primary_instance = "example-nw1"
   sap_primary_zone = "us-central1-a"

   sap_secondary_instance = "example-nw2"
   sap_secondary_zone = "us-central1-c"

   nfs_path = "10.223.55.130:/pr1_nw"

   sap_sid = "PR1"
   # ...
}

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

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

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

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

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

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

  2. Mude para o usuário raiz.

    sudo su -

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

    example-nw1:~ # df -h
  Filesystem                             Size  Used Avail Use% Mounted on
  ...
  /dev/mapper/vg_usrsap-vol              8.0G   41M  8.0G   1% /usr/sap
  /dev/mapper/vg_sapmnt-vol              8.0G   41M  8.0G   1% /sapmnt
  10.233.55.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
  10.223.55.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
  10.223.55.130:/pr1_nw/usrsapPR1ASCS00 1007G     0  956G   0% /usr/sap/PR1/ASCS00
  ...
    O autofs é configurado automaticamente durante a implantação para ativar 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 de cluster, que também é configurado durante a implantação.

  4. Verifique o status do novo cluster inserindo o comando de status: crm status

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

    example-nw1:~ # crm status
Cluster Summary:
  * Stack: corosync
  * Current DC: example-nw1 (version 2.0.4+20200616.2deceaa3a-3.6.1-2.0.4+20200616.2deceaa3a) - partition with quorum
  * Last updated: Fri Jun 18 05:47:48 2021
  * Last change:  Fri Jun 18 05:41:32 2021 by root via cibadmin on example-nw1
  * 2 nodes configured
  * 8 resource instances configured
Node List:
  * Online: [ example-nw1 example-nw2 ]
Full List of Resources:
  * fence-PR1-example-nw1     (stonith:fence_gce):           Started example-nw2
  * fence-PR1-example-nw2     (stonith:fence_gce):           Started example-nw1
  * file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):      Started example-nw1
  * file-system-PR1-ERS10     (ocf::heartbeat:Filesystem):      Started example-nw2
  * health-check-PR1-ASCS00   (ocf::heartbeat:anything):        Started example-nw1
  * health-check-PR1-ERS10    (ocf::heartbeat:anything):        Started example-nw2
  * vip-PR1-ASCS00      (ocf::heartbeat:IPaddr2):             Started example-nw1
  * vip-PR1-ERS10       (ocf::heartbeat:IPaddr2):             Started example-nw2

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

    1. 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)" &

    2. 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 algum dos passos de validação mostrar que a instalação falhou:

  1. Resolva os erros.

  2. Abra o Cloud Shell.

    Acessar o Cloud Shell

  3. Acesse o diretório que contém o arquivo de configuração do Terraform.

  4. Exclua a implantação:

    terraform destroy

    Quando for solicitada a aprovação da ação, digite yes.

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

  1. Estabeleça uma conexão SSH com a instância da VM do host.

  2. Execute este comando: 

    systemctl status google-cloud-sap-agent

    Se o agente estiver funcionando corretamente, a saída conterá active (running). 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:

  1. No sistema SAP, insira a transação ST06.

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

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

    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:

      # 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 administrador SID_LC trabalhe com o cluster, adicione-o ao grupo de usuários haclient.

  1. Nos dois servidores, adicione o usuário administrador SID_LC 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

    • 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_RSC_NAME 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

    • 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_RSC_NAME 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

    • 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_RSC_NAME 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

    • 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_RSC_NAME 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_RSC_GROUP_NAME ASCS_FILE_SYSTEM_RSC_NAME \
  ASCS_HEALTH_CHECK_RSC_NAME ASCS_VIP_RSC_NAME \
  ASCS_INSTANCE_RSC_NAME \
  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_RSC_GROUP_NAME ERS_FILE_SYSTEM_RSC_NAME \
  ERS_HEALTH_CHECK_RSC_NAME ERS_VIP_RSC_NAME \
  ERS_INSTANCE_RSC_NAME

    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. 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_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME

    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_ASCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RSC_NAME \
rule 2000: runs_ers_SID eq 1

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

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
 Optional: ASCS_INSTANCE_RSC_NAME:start \
 ERS_INSTANCE_RSC_NAME:stop symmetrical=false

    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_ASCS_ERS_COLOC -5000: ERS_RSC_GROUP_NAME ASCS_RSC_GROUP_NAME

    2. Configure o ASCS 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_RSC_NAME:start \
 ERS_INSTANCE_RSC_NAME:stop symmetrical=false

  3. Desative o modo de manutenção.

    # crm configure property maintenance-mode="false"

  4. Verifique a configuração dos grupos, as restrições de posicionamento e a ordem:

    # crm config show

    A saída precisa incluir linhas semelhantes às do exemplo a seguir:

    ENSA1 

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
        meta resource-stickiness=3000
colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name
location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
location loc-sap-AHA-failover-to-ers scs-aha-instance-rsc-name \
        rule 2000: runs_ers_AHA eq 1

    ENSA2 

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
        meta resource-stickiness=3000
location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
order ord-sap-AHA-first-start-ascs Optional: scs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name

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