Guia de configuração de clusters de alta disponibilidade para SAP NetWeaver no SLES

Neste guia, você verá como implantar e configurar um cluster de alta disponibilidade (HA, na sigla em inglês) do SUSE Linux Enterprise Server (SLES) para o sistema SAP NetWeaver.

Este guia inclui as etapas de:

  • Como configurar o balanceamento de carga TCP/UDP interno para redirecionar o tráfego em caso de falha
  • Como configurar um cluster do Pacemaker no SLES para gerenciar os sistemas SAP e outros recursos durante um failover

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

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

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 com um SAP Central Services ativo e outra com um Standalone Enqueue Server ativo
  • O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
  • Um mecanismo de cercas STONITH.
  • Reinicialização automática da instância com falha como nova instância secundária

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

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

Para configurar a rede:

  1. Acesse o Cloud Shell.

    Acesse o Cloud Shell

  2. Para criar uma nova rede no modo de sub-redes personalizadas, execute:

    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    Substitua NETWORK_NAME pelo nome da nova rede. Esse nome pode conter apenas letras minúsculas, dígitos e o caractere traço (-).

    Especifique --subnet-mode custom para evitar o uso do modo automático padrão, que cria automaticamente uma sub-rede em cada região do Compute Engine. Para mais informações, consulte Modo de criação da sub-rede.

  3. Crie uma sub-rede e especifique a região e o intervalo de IP:

    gcloud compute networks subnets create SUBNETWORK_NAME \
            --network NETWORK_NAME --region REGION --range RANGE

    Substitua:

    • SUBNETWORK_NAME: o nome da nova sub-rede.
    • NETWORK_NAME: o nome da zona que você criou na etapa anterior;
    • REGION: a região em que você quer a sub-rede;
    • RANGE: o intervalo de endereços IP, especificado no formato CIDR. Por exemplo, 10.1.0.0/24. Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.
  4. Se quiser, repita o passo anterior e adicione mais sub-redes.

Como configurar um gateway NAT

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

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

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

Como adicionar regras de firewall

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

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

Crie regras de firewall para permitir acesso, por exemplo:

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

Para criar uma regra de firewall:

  1. No Console do Cloud, acesse a página Regras de firewall:

    Abrir a página "Regras de firewall"

  2. Na parte superior da página, clique em Criar regra de firewall.

    • No campo Rede, selecione a rede em que a VM está localizada.
    • No campo Destinos, selecione Todas as instâncias na rede.
    • No campo Filtro de origem, selecione uma das opções a seguir:
      • Intervalos de IPs, para permitir tráfego de entrada de endereços IP específicos. Especifique o intervalo de endereços IP no campo Intervalos de IPs de origem.
      • Sub-redes, para permitir tráfego de entrada de uma sub-rede específica. Especifique o nome da sub-rede no campo Sub-redes a seguir. É possível usar essa opção para permitir acesso entre as VMs na configuração em três níveis ou de escalonamento horizontal.
    • Na seção Protocolos e portas, selecione Portas e protocolos especificados e especifique tcp:[PORT_NUMBER];.
  3. Clique em Criar para criar a regra de firewall.

Como implantar as VMs para SAP NetWeaver

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

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

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

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

As instruções a seguir são para o Cloud Shell, mas, no geral, podem ser aplicadas ao SDK do Cloud.

  1. Abra o Cloud Shell.

    Acessar o Cloud Shell

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

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

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

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

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

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

    Propriedade Tipo de dados Descrição
    Nome String Um nome arbitrário que identifica o recurso de implantação que o seguinte conjunto de propriedades define.
    tipo String

    Especifica o local, o tipo e a versão do modelo do Deployment Manager a ser usado durante a implantação.

    O arquivo YAML inclui duas especificações type, uma delas comentada. A especificação type que está ativa por padrão especifica a versão do modelo como latest. A especificação type comentada especifica uma versão de modelo específica com carimbo de data/hora.

    Se você precisar que todas as suas implantações usem a mesma versão de modelo, use a especificação type que inclui o carimbo de data/hora.

    instanceName String O nome da instância de VM que você está definindo. Especifique nomes diferentes nas definições das VMs principal e secundária. Avalie o uso de nomes que identificam as instâncias como pertencentes ao mesmo cluster de alta disponibilidade.

    Os nomes das instâncias precisam ter até 13 caracteres e ser especificados em letras minúsculas, números ou hifens. Use um nome exclusivo no projeto.

    instanceType String O tipo de VM do Compute Engine necessário. Especifique o mesmo tipo de instância para as VMs principal e secundária.

    Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido pequeno e, após o término da implantação, personalize a VM conforme necessário.

    zone String A zona do Google Cloud em que a instância da VM que você está definindo será implantada. Especifique zonas diferentes na mesma região para as definições de VM principal e secundária. As zonas precisam estar na mesma região selecionada para a sub-rede.
    subnetwork String O nome da sub-rede criada em uma etapa anterior. Se estiver implantando em uma VPC compartilhada, especifique esse valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por exemplo, myproject/network1.
    linuxImage String O nome da família de imagens ou da imagem do sistema operacional Linux que está sendo usada com o SAP NetWeaver. Para especificar uma família de imagens, adicione o prefixo family/ ao nome da família. Por exemplo, family/sles-15-sp1-sap: Para ver a lista de famílias de imagens disponíveis, consulte a página Imagens no Console do Cloud.
    linuxImageProject String O projeto do Google Cloud que contém a imagem que você usará. Ele pode ser seu próprio projeto ou o projeto de imagem do Google Cloud suse-sap-cloud. Para uma lista de projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.
    usrsapSize Inteiro O tamanho do disco "/usr/sap". O tamanho mínimo é 8 GB.
    sapmntSize Inteiro O tamanho do disco "/sapmnt". O tamanho mínimo é 8 GB.
    swapSize Inteiro O tamanho do volume de troca. O tamanho mínimo é de 1 GB.
    networkTag String

    Opcional. Uma ou mais tags de rede separadas por vírgula que representam a instância da VM para fins de roteamento ou firewall.

    Para configurações de alta disponibilidade, especifique uma tag de rede a ser usada em uma regra de firewall que permita a comunicação entre os nós do cluster, e uma tag de rede a ser usada em uma regra de firewall que permita que as verificações de integridade do Cloud Load Balancing acessem os nós do cluster.

    Se você especificar "publicIP: No" e não especificar uma tag de rede, certifique-se de fornecer outro meio de acesso à Internet.

    serviceAccount String

    Opcional. Especifica uma conta de serviço personalizada a ser usada para a VM implantada. A conta de serviço precisa incluir as permissões necessárias durante a implantação para configurar a VM para SAP.

    Se serviceAccount não for especificado, a conta de serviço padrão do Compute Engine será usada.

    Especifique o endereço completo da conta de serviço. Por exemplo: sap-ha-example@example-project-123456.iam.gserviceaccount.com

    publicIP Booleano Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes.
    sap_deployment_debug Booleano Opcional. Se esse valor estiver definido como Yes, serão gerados registros detalhados da implantação. Não ative essa configuração a menos que um engenheiro de suporte do Google peça para habilitar a depuração.
  6. No arquivo de configuração YAML, crie a definição da segunda VM. Basta copiar a definição da primeira VM e colar a cópia após a primeira. Para um exemplo, consulte Exemplo de um arquivo de configuração YAML completo.

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

    • name
    • instanceName
    • zone
  8. Crie as instâncias de VM:

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

    onde:

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

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

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

Exemplo de um arquivo de configuração YAML completo

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

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

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

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

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

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

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

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

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

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

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

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

Como verificar a implantação das VMs

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

Como verificar os registros

As etapas a seguir usam o Cloud Logging, o que pode gerar cobranças. Para mais informações, consulte os preços do Cloud Logging.

  1. Abra o Cloud Logging para verificar se há erros e monitorar o progresso da instalação.

    Acessar o Logging

  2. Na guia Recursos, selecione Global como o recurso de geração de registros. Se INSTANCE DEPLOYMENT COMPLETE for exibido para uma VM, o processamento do Deployment Manager será concluído para ela.

    Exibição do Logging

Como verificar a configuração das VMs

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

    1. Se você ainda não tiver feito isso, crie uma regra de firewall para permitir uma conexão SSH na porta 22.
    2. Acesse a página Instâncias de VM.

      Acessar a página Instâncias de VM

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

      Botão SSH na página "Instâncias de VM" do Compute Engine.

  2. Exibir o sistema de arquivos:

    ~> df -h

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

    Filesystem                 Size  Used Avail Use% Mounted on
    devtmpfs                    32G  8.0K   32G   1% /dev
    tmpfs                       48G     0   48G   0% /dev/shm
    tmpfs                       32G  402M   32G   2% /run
    tmpfs                       32G     0   32G   0% /sys/fs/cgroup
    /dev/sda3                   30G  3.4G   27G  12% /
    /dev/sda2                   20M  3.7M   17M  19% /boot/efi
    /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
    /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
    tmpfs                      6.3G     0  6.3G   0% /run/user/1002
    tmpfs                      6.3G     0  6.3G   0% /run/user/0
  3. Confirme se o diretório de troca foi criado:

    ~> cat /proc/meminfo | grep Swap

    Você verá resultados parecidos com os deste exemplo:

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

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

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

Atualizar o SDK do Cloud

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

  1. Conecte-se por SSH à VM principal.

  2. Atualize o Cloud SDK.

    ~>  sudo gcloud components update
  3. Siga as instruções.

  4. Repita as etapas na VM secundária.

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

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

  1. Em cada VM no cluster de alta disponibilidade, ative o roteamento local.

    1. Conecte-se por SSH a cada VM no cluster planejado.
    2. Mude para o usuário raiz.
    3. Em cada máquina, ative o roteamento local na interface principal emitindo o comando a seguir. Se você estiver usando uma interface diferente de eth0, especifique-a no comando em vez de eth0.

      echo net.ipv4.conf.eth0.accept_local=1 >> /etc/sysctl.conf
      sysctl -p

      O comando anterior grava a configuração no arquivo de configuração.

  2. Em cada VM, crie um script de inicialização para ativar a comunicação entre back-ends:

    Console do Cloud

    1. Acesse a página "Instâncias de VMs" no Console do Cloud.

      Acessar a página Instâncias de VM

    2. Clique no nome da VM principal.

    3. Na página Detalhes da instância de VM, clique no botão EDITAR.

    4. Na seção Metadados personalizados, clique em Adicionar item.

    5. No campo Chave, especifique startup-script.

    6. No campo Value, cole o script bash a seguir:

      #! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule del from all lookup local
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi
    7. Na parte inferior da página, clique em Salvar.

    8. Reinicie o servidor para que o script de inicialização entre em vigor.

      Quando terminar, os metadados personalizados serão semelhantes ao exemplo a seguir:

      A captura de tela mostra "startup-script" com outras entradas na
seção de metadados personalizados na página de detalhes da VM no
Console do Cloud

    9. Repita as etapas anteriores para o servidor secundário.

    gcloud

    1. No Cloud Shell, ou em outro lugar que você tenha o SDK do Cloud instalado, use o seguinte comando gcloud com o script de inicialização incluído para adicionar um script de inicialização aos metadados de instância de cada VM. Substitua as variáveis pelo nome e zona da VM antes de inserir o comando.

      gcloud compute instances add-metadata primary-vm-name \
      --zone=primary-vm-zone --metadata=startup-script='#! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip rule del from all lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi'
    2. Reinicie o servidor para que o script de inicialização entre em vigor.

    3. Para confirmar que o script de inicialização está armazenado nos metadados da instância, emita o seguinte comando:

      gcloud compute instances describe primary-vm-name \
      --zone=primary-vm-zone

      O script de inicialização aparece na saída em metadata, conforme mostrado no exemplo truncado a seguir:

      metadata:
      fingerprint: Tbuij9k-knk=
      items:
      - key: post_deployment_script
      value: ''
      - key: sap_deployment_debug
      value: 'False'
      - key: status
      value: completed
      - key: startup-script
      value: |-
        #! /bin/bash
        # VM startup script
        ...
        [example truncated]
    4. Para a VM secundária, repita as etapas anteriores após substituir os valores da variável pelos valores da instância da VM secundária.

Para mais informações sobre como criar scripts de inicialização para VMs do Compute Engine, consulte Como executar scripts de inicialização.

Configurar chaves SSH nas VMs principais e secundárias

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

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

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

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

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

  1. Na VM do host principal:

    1. Conecte-se à VM via SSH.

    2. Mudar para raiz:

      $ sudo su -
    3. Confirmar a existência da chave SSH:

      # ls -l /root/.ssh/

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

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Atualize os metadados da VM principal com informações sobre a chave SSH da VM secundária.

      # gcloud compute instances add-metadata secondary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-vm-zone
    5. Confirme se as chaves SSH estão configuradas corretamente abrindo uma conexão SSH do sistema secundário para o sistema principal.

      # ssh secondary-vm-name
  2. Na VM do host secundário:

    1. Conecte-se por SSH à VM.

    2. Mudar para raiz:

      $ sudo su -
    3. Confirmar a existência da chave SSH:

      # ls -l /root/.ssh/

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

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Atualize os metadados da VM secundária com informações sobre a chave SSH da VM principal.

      # gcloud compute instances add-metadata primary-vm-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone
      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. Confirme se as chaves SSH estão configuradas corretamente abrindo uma conexão SSH do sistema secundário para o sistema principal.

      # ssh primary-vm-name

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

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

A configuração de uma solução de compartilhamento de arquivos não é abordada neste guia. Para instruções sobre como configurar o sistema de compartilhamento de arquivos, consulte as instruções do fornecedor da solução selecionada.

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

Para configurar os diretórios compartilhados:

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

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

    ~> sudo mkdir /mnt/nfs
    ~> sudo mount -t nfs nfs-path /mnt/nfs
  3. Em qualquer servidor, crie diretórios para sapmnt, o diretório de transporte central, o diretório do sistema e o diretório específico da instância. Se você estiver usando uma pilha Java, substitua "ASCS" por "SCS" antes de usar os seguintes comandos e exemplos:

    ~> sudo mkdir /mnt/nfs/sapmntSID
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDSYS,SIDASCSscs-instance-number,SIDERSers-instance-number}
  4. Nos dois servidores, crie os pontos de montagem necessários:

    ~> sudo mkdir -p /sapmnt/SID
    ~> sudo mkdir -p /usr/sap/trans
    ~> sudo mkdir -p /usr/sap/SID/SYS
    ~> sudo mkdir -p /usr/sap/SID/ASCSscs-instance-number
    ~> sudo mkdir -p /usr/sap/SID/ERSers-instance-number
  5. Configure autofs para montar os diretórios de arquivos compartilhados comuns quando os diretórios de arquivos forem acessados pela primeira vez. A montagem dos diretórios ASCSscs-instance-number e ERSers-instance-number é gerenciada pelo software do cluster, que você configurará em uma etapa posterior.

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

    Nos dois servidores, configure autofs:

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

    Para mais informações sobre autofs, consulte autofs: como funciona (em inglês).

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

    ~> sudo systemctl enable autofs
    ~> sudo systemctl restart autofs
    ~> sudo automount -v
  7. Acione autofs para montar diretórios compartilhados acessando cada diretório usando o comando cd. Exemplo:

    ~> cd /sapmnt/SID
    ~> cd /usr/sap/trans
    ~> cd /usr/sap/SID/SYS
    
  8. Depois de acessar todos os diretórios, emita o comando df -Th para confirmar se os diretórios estão ativados.

    ~> df -Th | grep file_share_name

    Você verá pontos de montagem e diretórios semelhantes aos seguintes:

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

Configurar o suporte a failover do Cloud Load Balancing

O serviço de balanceamento de carga TCP/UDP interno compatível com failover direciona o tráfego SCS e ERS para as instâncias ativas de cada um em um cluster do SAP NetWeaver. O balanceamento de carga TCP/UDP interno usa endereços IP virtuais (VIP, na sigla em inglês), serviços de back-end, grupos de instâncias e verificações de integridade para rotear o tráfego adequadamente.

Reservar endereços IP para os IPs virtuais

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

  1. Abra o Cloud Shell:

    Acessar o Cloud Shell

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

    ~ gcloud compute addresses create scs-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses scs-vip-address
    
    ~ gcloud compute addresses create ers-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses ers-vip-address

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

  3. Confirmar reserva de endereço IP:

    ~ gcloud compute addresses describe vip-name \
      --region cluster-region

    O resultado será semelhante a:

    address: 10.1.0.85
    addressType: INTERNAL
    creationTimestamp: '2021-05-12T13:30:29.991-07:00'
    description: ''
    id: '1740813556077659146'
    kind: compute#address
    name: scs-aha-vip-name
    networkTier: PREMIUM
    purpose: GCE_ENDPOINT
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/scs-aha-vip-name
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

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

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

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

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

#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost
10.1.0.89       nw-ha-vm-1
10.1.0.88       nw-ha-vm-2
10.1.0.90       vh-scs-aha
10.1.0.91       vh-ers-aha

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

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

  1. No Cloud Shell, crie as verificações de integridade. Para evitar conflitos com outros serviços, designe números de portas para as instâncias do SCS e do ERS no intervalo particular 49152-65535. Os valores de intervalo de verificação e tempo limite nos comandos a seguir são um pouco mais longos do que os padrões a fim de aumentar a tolerância de failover durante os eventos de migração em tempo real do Compute Engine. É possível ajustar os valores, se necessário:

    1. ~ gcloud compute health-checks create tcp scs-health-check-name \
      --port=scs-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ers-health-check-name \
      --port=ers-healthcheck-port-num --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
  2. Confirmar a criação da verificação de integridade:

    ~ gcloud compute health-checks describe health-check-name

    O resultado será semelhante a:

    checkIntervalSec: 10
    creationTimestamp: '2021-05-12T15:12:21.892-07:00'
    healthyThreshold: 2
    id: '1981070199800065066'
    kind: compute#healthCheck
    name: scs-aha-health-check-name
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    tcpHealthCheck:
      port: 60000
      portSpecification: USE_FIXED_PORT
      proxyHeader: NONE
    timeoutSec: 10
    type: TCP
    unhealthyThreshold: 2

Criar uma regra de firewall para as verificações de integridade

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

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

  2. Criar uma regra de firewall que use a tag de rede para permitir as verificações de integridade:

    ~ gcloud compute firewall-rules create  rule-name \
      --network=network-name \
      --action=ALLOW \
      --direction=INGRESS \
      --source-ranges=35.191.0.0/16,130.211.0.0/22 \
      --target-tags=network-tags \
      --rules=tcp:scs-healthcheck-port-num,tcp:ers-healthcheck-port-num

    Exemplo:

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

Criar grupos de instâncias do Compute Engine

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

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

    1. ~ gcloud compute instance-groups unmanaged create primary-ig-name \
      --zone=primary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-vm-zone \
      --instances=primary-vm-name
  2. No Cloud Shell, crie o grupo de instâncias secundárias e adicione a VM secundária a ele:

    1. ~ gcloud compute instance-groups unmanaged create secondary-ig-name \
      --zone=secondary-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-vm-zone \
      --instances=secondary-vm-name
  3. Confirme a criação dos grupos de instâncias:

    ~ gcloud compute instance-groups unmanaged list

    O resultado será semelhante a:

    NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
    sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
    sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
    

Configurar os serviços de back-end

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

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

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

      ~ gcloud compute backend-services create scs-backend-service-name \
         --load-balancing-scheme internal \
         --health-checks scs-health-check-name \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region cluster-region \
         --global-health-checks
    2. Adicionar o grupo de instâncias principal ao serviço de back-end:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --region cluster-region
    3. Adicionar o grupo de instâncias secundárias como o grupo de instâncias de failover para o serviço de back-end do SCS:

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --failover \
        --region cluster-region
  2. No Cloud Shell, crie o serviço de back-end e o grupo de failover para o ERS:

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

      ~ gcloud compute backend-services create ers-backend-service-name \
      --load-balancing-scheme internal \
      --health-checks ers-health-check-name \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region cluster-region \
      --global-health-checks
    2. Adicionar o grupo de instâncias secundárias ao serviço de back-end de ERS:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-zone \
        --region cluster-region
    3. Adicionar o grupo de instâncias principais como o grupo de instâncias de failover para o serviço de back-end de ERS:

      ~ gcloud compute backend-services add-backend ers-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --failover \
        --region cluster-region
  3. Se quiser, confirme se os serviços de back-end contêm os grupos de instâncias conforme o esperado:

    ~ gcloud compute backend-services describe backend-service-name \
     --region=cluster-region

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

    backends:
    - balancingMode: CONNECTION
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    - balancingMode: CONNECTION
      failover: true
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    connectionDraining:
      drainingTimeoutSec: 0
    creationTimestamp: '2021-05-25T08:30:58.424-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: n44gVc1VVQE=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    id: '4940777952116778717'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: scs-aha-backend-service-name
    protocol: TCP
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/backendServices/scs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. No Cloud Shell, crie regras de encaminhamento para os serviços de back-end do SCS e ERS:

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

      ~ gcloud compute forwarding-rules create scs-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address scs-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service scs-backend-service-name \
      --ports ALL
    2. Criar a regra de encaminhamento do VIP do ERS para o serviço de back-end ERS:

      ~ gcloud compute forwarding-rules create ers-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address ers-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service ers-backend-service-name \
      --ports ALL

Testar a configuração do balanceador de carga

Mesmo que os grupos de instâncias de back-end não sejam registrados como íntegros até mais tarde, teste a configuração do balanceador de carga configurando um listener para responder às verificações de integridade. Depois de configurar um listener, se o balanceador de carga estiver configurado corretamente, o status dos grupos de instâncias de back-end será alterado para íntegro.

As seções a seguir apresentam métodos diferentes que podem ser usados para testar a configuração.

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

Use o utilitário socat para detectar temporariamente uma porta de verificação de integridade. Você precisa instalar o utilitário socat mesmo assim, porque ele será usado mais tarde quando você configurar os recursos do cluster.

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

    # zypper install -y socat

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

    # timeout 60s socat - TCP-LISTEN:scs-healthcheck-port-num,fork

  3. No Cloud Shell, depois de esperar alguns segundos pela verificação de integridade detectar o listener, verifique a integridade do grupo de instância de back-end:

    ~ gcloud compute backend-services get-health scs-backend-service-name \
      --region cluster-region
  4. Repita as etapas para o ERS, substituindo os valores da variável SCS pelos valores do ERS.

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

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

Como testar o balanceador de carga usando a porta 22

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

Para usar temporariamente a porta 22, siga estas etapas:

  1. Clique na verificação de integridade no console:

    Acessar a página "Verificações de integridade"

  2. Clique em Editar.

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

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

  5. No Cloud Shell, depois de esperar alguns segundos pela verificação de integridade detectar o listener, verifique a integridade do grupo de instância de back-end:

    ~ gcloud compute backend-services get-health backend-service-name \
      --region cluster-region

    A resposta será semelhante a esta:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.79
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.78
        port: 80
      kind: compute#backendServiceGroupHealth
  6. Quando terminar, altere o número da porta de verificação de integridade para o número de porta original.

Configurar o Pacemaker

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

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

Instalar os pacotes de cluster necessários

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

    • O padrão ha_sles:

      # zypper install -t pattern ha_sles
    • O pacote sap-suse-cluster-connector:

      # zypper install -y sap-suse-cluster-connector
    • Se você ainda não o instalou, o utilitário socat:

      # zypper install -y socat

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

    # zypper se -t patch SUSE-SLE-HA

Inicializar, configurar e iniciar o cluster na VM principal

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

Inicializar o cluster

Para inicializar o cluster:

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

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

Atualizar os arquivos de configuração do Corosync

  1. Abra o arquivo corosync.conf para editá-lo:

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

    totem {
            ...
            token: 20000
            token_retransmits_before_loss_const: 10
            join: 60
            consensus: 24000
            max_messages: 20
            ...
    }
  3. Inicie o cluster

    # ha-cluster-init --name cluster-name cluster

Definir as outras propriedades do cluster

  1. Defina as propriedades gerais do cluster:

    # crm configure property no-quorum-policy="stop"
    # crm configure property startup-fencing="true"
    # crm configure property stonith-timeout="300s"
    # crm configure property stonith-enabled="true"
    # crm configure rsc_defaults resource-stickiness="1"
    # crm configure rsc_defaults migration-threshold="3"
    # crm configure op_defaults timeout="600"

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

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

  2. Inicie o Pacemaker no host principal:

    # systemctl enable pacemaker
    # systemctl start pacemaker

Mesclar a VM secundária ao cluster

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

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

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

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes --interface eth0 csync2'
    2. Execute a opção ssh_merge:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes ssh_merge'
    3. Execute a opção cluster:

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes cluster'
  2. Inicie o Pacemaker no host secundário:

    1. Ative o Pacemaker:

      # ssh secondary-vm-name systemctl enable pacemaker
    2. Inicie o Pacemaker:

      # ssh secondary-vm-name systemctl start pacemaker
  3. Em ambos os hosts como raiz, confirme se o cluster mostra os dois nós:

    # crm_mon -s

    A resposta será semelhante a esta:

    CLUSTER OK: 2 nodes online, 0 resource instances configured

Configurar os recursos de cluster para a infraestrutura

Os recursos que o Pacemaker gerencia são definidos em um cluster de alta disponibilidade. É preciso definir recursos dos seguintes componentes do cluster:

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

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

Ativar o modo de manutenção

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

    # crm configure property maintenance-mode="true"
  2. Confirme o modo de manutenção:

    # crm status

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

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

Configurar o isolamento

Para configurar o isolamento, defina um recurso de cluster com o agente fence_gce para cada VM do host.

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

Criar os recursos do dispositivo de isolamento

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

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

    # crm configure primitive fencing-rsc-name-primary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="primary-vm-name" zone="primary-vm-zone" \
      project="cluster-project-id"
  2. Configure a localização do dispositivo de isolamento da VM principal para que ela fique ativa somente na VM secundária:

    # crm configure location fencing-location-name-primary-vm \
      fencing-rsc-name-primary-vm -inf: "primary-vm-name"
  3. No host principal como raiz, crie um recurso de cluster para um dispositivo de isolamento para a VM secundária:

    # crm configure primitive fencing-rsc-name-secondary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="secondary-vm-name" zone="secondary-vm-zone" \
      project="cluster-project-id"
  4. Configure a localização do dispositivo de isolamento da VM secundária para que ela fique ativa somente na VM principal:

    # crm configure location fencing-location-name-secondary-vm \
      fencing-rsc-name-secondary-vm -inf: "secondary-vm-name"

Definir um atraso para a reinicialização do Corosync

  1. Em ambos os hosts como raiz, crie um arquivo drop-in systemd que atrase a inicialização do Corosync para garantir a sequência adequada de eventos após a reinicialização de uma VM isolada:

    systemctl edit corosync.service
  2. Adicione as seguintes linhas ao arquivo:

    [Service]
    ExecStartPre=/bin/sleep 60
  3. Salve o arquivo e saia do editor.

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

    systemctl daemon-reload
  5. Confirme se o arquivo drop-in foi criado:

    service corosync status

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

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

Aumentar o valor de tempo limite do Pacemaker para reinicializações

  1. Em cada host como raiz, aumente o valor do tempo limite do Pacemaker para reinicializações para considerar o atraso da inicialização.

    crm_resource --resource STONITH-"host-name --set-parameter=pcmk_reboot_timeout --parameter-value=300

    O valor pcmk_reboot_timeout precisa ser maior que a soma do:

    • Tempo limite token do Corosync
    • Tempo limite consensus do Corosync
    • Tempo que uma operação de reinicialização leva para ser concluída, incluindo qualquer atributo de atraso.

    No Google Cloud, 300 segundos são suficientes para a maioria dos clusters.

  2. Confirme o novo valor pcmk_reboot_timeout:

    crm_resource --resource STONITH-host-name --get-parameter=pcmk_reboot_timeout

Criar os recursos do sistema de arquivos

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

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

    # crm configure primitive scs-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDASCSscs-instance-number" \
    directory="/usr/sap/SID/ASCSscs-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s
    # crm configure primitive ers-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDERSers-instance-number" \
    directory="/usr/sap/SID/ERSers-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

Criar os recursos da verificação de integridade

  1. Configure os recursos do cluster para as verificações de integridade do SCS e ERS:
# crm configure primitive scs-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:scs-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0
# crm configure primitive ers-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ers-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0

Criar os recursos do VIP

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

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

    • gcloud compute addresses describe scs-vip-name
      --region=cluster-region --format="value(address)"
    • gcloud compute addresses describe ers-vip-name
      --region=cluster-region --format="value(address)"
  2. Crie os recursos de cluster dos VIPs do SCS e do ERS.

    # crm configure primitive scs-vip-rsc-name IPaddr2 \
     params ip=scs-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s
    # crm configure primitive ers-vip-rsc-name IPaddr2 \
     params ip=ers-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s

Ver os recursos definidos

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

    # crm status

    O resultado será semelhante a:

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

Instalar o SCS e o 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-loweradm -g sapsys
    # usermod -a -G sapinst sid-loweradm
    # useradd -u uid-sapadm sapadm -g sapinst
    
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS
    # chown sid-loweradm:sapsys /sapmnt/SID -R
    # chown sid-loweradm:sapsys /usr/sap/trans -R
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS -R
    # chown sid-loweradm:sapsys /usr/sap/SID -R

Instalar o componente SCS

  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 administrador sid, pare o serviço SCS.

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr scs-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 ao grupo de usuários haclient.

Confirmar as entradas de serviço do SAP

  1. Em ambos os servidores, confirme se /usr/sap/sapservices contém entradas para os serviços SCS e ERS. É possível adicionar entradas ausentes usando sapstartsrv command com as opções pf=profile-of-the-sap-instance e -reg. Exemplo:

    # 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 \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ASCSscs-instance-number_scs-virtual-host-name \
     -reg

Interromper os serviços do SAP

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

    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function StopService"
  2. Em cada servidor, valide se todos os serviços foram interrompidos:

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function GetSystemInstanceList"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function GetSystemInstanceList"

    O resultado será semelhante a:

    18.05.2021 17:39:18
    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Editar os perfis do SCS e 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_ASCSscs-instance-number_scs-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 administrador sid 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 trabalhe com o cluster, adicione-o ao grupo de usuários haclient.

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

    # usermod -aG haclient sid-loweradm

Configurar os recursos do cluster para SCS 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 SCS e ERS:

    ENSA1

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

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-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 SCS. O valor de InstanceName é o nome do perfil da instância gerado pelo SWPM quando você instalou o SCS.

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-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 SCS e ERS. Para exibir os nomes de todos os recursos definidos anteriormente, insira o comando crm resource status:

    # crm configure group scs-rsc-group-name scs-file-system-rsc-name \
      scs-health-check-rsc-name scs-vip-rsc-name \
      scs-instance-rsc-name \
      meta resource-stickiness=3000
    # 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
  2. Crie as restrições de colocation:

    ENSA1

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

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configure o SCS para fazer failover ao servidor em que o ERS está sendo executado, o que é determinado pela sinalização runsersSID ser igual a 1:

      # crm configure location loc-scs-SID-failover-to-ers scs-instance-rsc-name \
      rule 2000: runs_ers_SID eq 1
    3. Configure o SCS para iniciar antes que o ERS seja movido para o outro servidor após um failover:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-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-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configure o SCS para iniciar antes que o ERS seja movido para o outro servidor após um failover:

      # crm configure order ord-sap-SID-first-start-ascs \
       Optional: scs-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

Testar o cluster

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

  • Verificar se há erros de configuração
  • Confirmar se os recursos SCS e ERS alternam de servidor corretamente durante os failovers
  • Confirmar se os bloqueios foram retidos
  • Confirmar noo Compute Engine que os eventos de manutenção não acionam um failover

Verificar a configuração do cluster no SAP

  1. Como raiz em um dos servidores, veja quais instâncias estão ativas no servidor:

    # crm status
  2. Alterne para o usuário administrador sid

    # su - sid-loweradm
  3. Verifique a configuração do cluster. No número da instância, especifique o número da instância SCS ou ERS ativa no servidor em que o comando será inserido:

    > 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 administrador sid, 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-scs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-scs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-scs-aha_AHA_00), Enqueue replication active
  5. 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 SCS 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: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * scs-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
  6. Como administrador sid no servidor em que o SCS está ativo, simule um failover:

    > sapcontrol -nr scs-instance-number -function HAFailoverToNode ""
  7. Como raiz, se você seguir o failover usando crm_mon, verá o SCS 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.

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 SCS é ativado novamente.

ENSA1

  1. Como administrador sid, 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 administrado sid, no servidor em que SCS está ativo, verifique se as entradas de bloqueio estão registradas:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

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

    locks_now: 10
  3. Como administrador sid, 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 SCS 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 administrador sid, 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 administrador sid, no servidor em que o SCS está ativo, verifique se as entradas de bloqueio foram removidas:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

ENSA2

  1. Como administrador sid, no servidor em que o ERS 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_ERSers-instance-number_ers-virtual-host-name
  2. Como administrado sid, no servidor em que SCS está ativo, verifique se as entradas de bloqueio estão registradas:

    > sapcontrol -nr scs-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 SCS estiver ativo, reinicialize o servidor.

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

    # crm_mon
  5. Como administrador sid, no servidor em que SCS foi reiniciado, verifique se as entradas de bloqueio foram retidas:

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now
  6. Como administrador sid 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
  7. Como administrador sid, no servidor em que o SCS está ativo, verifique se as entradas de bloqueio foram removidas:

    > sapcontrol -nr scs-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, o risco de que a migração em tempo real acionará um failover será 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 do SDK do Cloud:

    # gcloud compute instances simulate-maintenance-event primary-instance-name
  2. Confirme que o nó principal não foi alterado:

    # crm status

Solução de problemas

Para resolver problemas com configurações de alta disponibilidade do SAP NetWeaver no SLES, consulte este link.

Como receber suporte para o SAP NetWeaver no SLES

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 mais informações, 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 ele parecer ser um problema de infraestrutura do Google Cloud, transfere o tíquete para o componente do Google Cloud, 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 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:

A seguir

Consulte os tópicos aseguir para saber mais:

+ Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud + SAP no Google Cloud: artigo sobre alta disponibilidade + Para mais informações sobre a administração e monitoramento de VMs, consulte o Guia de operações do SAP NetWeaver