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.

Para configurar um cluster de alta disponibilidade para o SAP HANA no Red Hat Enterprise Linux (RHEL), consulte o Guia de configuração 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

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:

Console

  1. No console, acesse a página Redes VPC.

    Acessar redes VPC

  2. Clique em Criar rede VPC.
  3. Digite um Nome para a rede.

    O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.

  4. Em Modo de criação da sub-rede, escolha Custom.
  5. Na seção Nova sub-rede, especifique os parâmetros de configuração a seguir para uma sub-rede:
    1. Insira um Nome para a sub-rede.
    2. Em Região, selecione a região do Compute Engine em que você quer criar a sub-rede.
    3. Em Tipo de pilha de IP, selecione IPv4 (pilha única) e insira um intervalo de endereços IP no formato CIDR. , como 10.1.0.0/24.

      Esse é o intervalo principal de IPv4 da sub-rede. Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.

    4. Clique em Concluído.
  6. Para adicionar mais sub-redes, clique em Adicionar sub-rede e repita as etapas anteriores. É possível adicionar mais sub-redes à rede depois de criá-la.
  7. Clique em Criar.

gcloud

  1. Acesse o Cloud Shell.

    Acesse o Cloud Shell

  2. Para criar uma nova rede no modo de sub-redes personalizadas, execute:
    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    Substitua NETWORK_NAME pelo nome da nova rede. O nome precisa seguir a convenção de nomenclatura. As redes VPC usam a convenção de nomenclatura do Compute Engine.

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

  3. Crie uma sub-rede e especifique a região e o intervalo de IP:
    gcloud compute networks subnets create SUBNETWORK_NAME \
        --network NETWORK_NAME --region REGION --range RANGE

    Substitua:

    • SUBNETWORK_NAME: o nome da nova sub-rede.
    • NETWORK_NAME: o nome da rede que você criou na etapa anterior;
    • REGION: a região em que você quer a sub-rede;
    • RANGE: o intervalo de endereços IP, especificado no formato CIDR. Por exemplo, 10.1.0.0/24

      Se você planeja adicionar mais de uma sub-rede, atribua intervalos IP CIDR não sobrepostos para cada sub-rede na rede. Observe que cada sub-rede e os respectivos intervalos IP internos são mapeados para uma única região.

  4. Se quiser, repita o passo anterior e adicione mais sub-redes.

Como configurar um gateway NAT

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

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, 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 usam o Cloud Shell, mas geralmente são aplicáveis à Google Cloud CLI.

  1. Abra o Cloud Shell.

    Acessar o Cloud Shell

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Se você especificar publicIP: No e não inserir uma tag de rede, forneça outro meio de acesso à Internet.

    serviceAccount String

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

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

    Especifique o endereço completo da conta de serviço. Por exemplo: 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-sp3-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-sp3-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.

Verificar os registros

  1. No console, 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. Na página Implantaçõesdo Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.

      3. Execute novamente o Deployment Manager.

Verificar a configuração das VMs

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

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

      Acessar instâncias de VM

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

      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 a CLI do Google Cloud

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

  1. Conecte-se por SSH à VM principal.

  2. Atualizar a CLI gcloud:

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

  4. Repita as etapas na VM secundária.

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

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

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

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

  1. Interrompa o agente:

    sudo service google-guest-agent stop
  2. Abra ou crie o arquivo /etc/default/instance_configs.cfg para edição. Exemplo:

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

    [IpForwarding]
    ethernet_proto_id = 66
    ip_aliases = true
    target_instance_ips = false
    
    [NetworkInterfaces]
    dhclient_script = /sbin/google-dhclient-script
    dhcp_command =
    ip_forwarding = false
    setup = true
    
  4. Inicie o serviço de agente convidado:

    sudo service google-guest-agent start

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

Configurar chaves SSH nas VMs principais e secundárias

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

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

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

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

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

  1. Na VM do host principal:

    1. Conecte-se à VM via SSH.

    2. Mudar para raiz:

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

      # ls -l /root/.ssh/

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

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

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

      # ssh SECONDARY_VM_NAME
  2. Na VM do host secundário:

    1. Conecte-se por SSH à VM.

    2. Mudar para raiz:

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

      # ls -l /root/.ssh/

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

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

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

      # ssh PRIMARY_VM_NAME

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

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

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

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

Para configurar os diretórios compartilhados:

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

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

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

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

  3. 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_UC
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SID_UCSYS,SID_UCASCSASCS_INSTANCE_NUMBER,SID_UCERSERS_INSTANCE_NUMBER}

    Substitua:

    • SID_UC: o ID do sistema SAP (SID) com letras maiúsculas. Por exemplo, AHA.
    • ASCS_INSTANCE_NUMBER: o número da instância do sistema ASCS. Por exemplo, 00.
    • ERS_INSTANCE_NUMBER: o número da instância do sistema ERS. Por exemplo, 10.
  4. Nos dois servidores, crie os pontos de montagem necessários:

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

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

    Nos dois servidores, configure autofs:

    ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
    ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
    ~> echo "/sapmnt/SID_UC ${NFS_OPTS} NFS_PATH/sapmntSID_UC" | 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_UC/SYS ${NFS_OPTS} NFS_PATH/usrsapSID_UCSYS" | 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_UC
    ~> cd /usr/sap/trans
    ~> cd /usr/sap/SID_UC/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

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

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

    10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
    10.49.153.26:/nfs_share_nw_ha/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 ASCS 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 ASCS e para o VIP do ERS. Para o ASCS, o endereço IP é aquele que os aplicativos usam para acessar o SAP NetWeaver. Para o ERS, o endereço IP é aquele usado para a replicação do Enqueue Server. Se você omitir a sinalização --addresses, será escolhido para você um endereço IP na sub-rede especificada:

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

    Substitua:

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

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

  3. Confirmar reserva de endereço IP:

    ~ gcloud compute addresses describe VIP_NAME \
      --region CLUSTER_REGION

    O resultado será semelhante a:

    address: 10.1.0.2
    addressType: INTERNAL
    creationTimestamp: '2022-04-04T15:04:25.872-07:00'
    description: ''
    id: '555067171183973766'
    kind: compute#address
    name: ascs-aha-vip
    networkTier: PREMIUM
    purpose: GCE_ENDPOINT
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/ascs-aha-vip
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

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

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

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

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

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

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

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

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

    1. ~ gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \
      --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \
      --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
  2. Confirmar a criação da verificação de integridade:

    ~ gcloud compute health-checks describe HEALTH_CHECK_NAME

    O resultado será semelhante a:

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

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

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

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

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

    ~ gcloud compute firewall-rules create  RULE_NAME \
      --network=NETWORK_NAME \
      --action=ALLOW \
      --direction=INGRESS \
      --source-ranges=35.191.0.0/16,130.211.0.0/22 \
      --target-tags=NETWORK_TAGS \
      --rules=tcp:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUM

    Exemplo:

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

Criar grupos de instâncias do Compute Engine

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

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

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

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

    ~ gcloud compute instance-groups unmanaged list

    O resultado será semelhante a:

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

Configurar os serviços de back-end

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

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

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

      ~ gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \
         --load-balancing-scheme internal \
         --health-checks ASCS_HEALTH_CHECK_NAME \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region CLUSTER_REGION \
         --global-health-checks
    2. Adicione o grupo de instâncias principal ao serviço de back-end do ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION
    3. Adicionar o grupo de instâncias secundárias como o grupo de instâncias de failover para o serviço de back-end do ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION
  2. No Cloud Shell, crie o serviço de back-end e o grupo de failover para o ERS:

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

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

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --region CLUSTER_REGION
    3. Adicionar o grupo de instâncias principais como o grupo de instâncias de failover para o serviço de back-end de ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --failover \
        --region CLUSTER_REGION
  3. Se quiser, confirme se os serviços de back-end contêm os grupos de instâncias conforme o esperado:

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

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

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

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

      ~ gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ASCS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ASCS_BACKEND_SERVICE_NAME \
      --ports ALL
    2. Criar a regra de encaminhamento do VIP do ERS para o serviço de back-end ERS:

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

Testar a configuração do balanceador de carga

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

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

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

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

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

    # zypper install socat

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

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

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

  4. No Cloud Shell, depois de esperar alguns segundos pela verificação de integridade para detectar o listener, verifique a integridade dos grupos de instâncias de back-end:

    ~ gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \
      --region CLUSTER_REGION

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

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

    ip addr del VIP_ADDRESS dev eth0
  6. Repita as etapas para o ERS, substituindo os valores da variável ASCS pelos valores do ERS.

Como testar o balanceador de carga usando a porta 22

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

Para usar temporariamente a porta 22, siga estas etapas:

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

    Acessar "Verificações de integridade"

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

  3. Clique em Editar.

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

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

  6. No Cloud Shell, depois de esperar alguns segundos pela verificação de integridade para detectar o listener, verifique a integridade dos grupos de instâncias de back-end:

    ~ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
      --region CLUSTER_REGION

    A resposta será semelhante a esta:

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

Configurar o Pacemaker

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

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

Instalar os pacotes de cluster necessários

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

    • O padrão ha_sles:

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

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

      # zypper install -y socat

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

    # zypper se -t patch SUSE-SLE-HA

Inicializar, configurar e iniciar o cluster na VM principal

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

Criar os arquivos de configuração do Corosync

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

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

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

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

    Substitua:

    • STATIC_IP_OF_THIS_HOST: especifique o endereço IP interno primário dessa VM, conforme mostrado em Interfaces de rede no console ou conforme exibido por gcloud compute instances describe VM_NAME.
    • THIS_HOST_NAME: especifica o nome do host dessa VM.
    • OTHER_HOST_NAME: especifica o nome do host da outra VM no cluster.
  2. Crie um arquivo de configuração do Corosync no host secundário repetindo as mesmas etapas usadas para o host principal. Os valores de propriedade do arquivo de configuração são os mesmos para cada host, exceto para o IP estático do HDB na propriedade Bindnetaddr e para a ordem dos nomes de host em nodelist.

Inicializar o cluster

Para inicializar o cluster:

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

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

Definir as outras propriedades do cluster

  1. Defina as propriedades gerais do cluster:

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

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

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

  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 ASCS e ERS

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

Ativar o modo de manutenção

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

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

    # crm status

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

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

Configurar o isolamento

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

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

Criar os recursos do dispositivo de isolamento

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

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

    # crm configure primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \
      op monitor interval="300s" timeout="120s" \
      op start interval="0" timeout="60s" \
      params port="PRIMARY_VM_NAME" zone="PRIMARY_ZONE" \
      project="CLUSTER_PROJECT_ID" \
      pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
  2. Configure a localização do dispositivo de isolamento da VM principal para que ela fique ativa somente na VM secundária:

    # crm configure location FENCING_LOCATION_NAME_PRIMARY_VM \
      FENCING_RESOURCE_PRIMARY_VM -inf: "PRIMARY_VM_NAME"
  3. No host principal como raiz, crie um recurso de cluster para um dispositivo de isolamento para a VM secundária:

    # crm configure primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
      op monitor interval="300s" timeout="120s" \
      op start interval="0" timeout="60s" \
      params port="SECONDARY_VM_NAME" zone="SECONDARY_VM_ZONE" \
      project="CLUSTER_PROJECT_ID" \
      pcmk_reboot_timeout=300 pcmk_monitor_retries=4
  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_RESOURCE_SECONDARY_VM -inf: "SECONDARY_VM_NAME"

Definir um atraso para a reinicialização do Corosync

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

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

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

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

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

    service corosync status

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

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

Criar os recursos do sistema de arquivos

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

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

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

    Substitua:

    • ASCS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso do cluster para o sistema de arquivos ASCS.
    • NFS_PATH: especifica o caminho para o sistema de arquivos NFS do ASCS.
    • SID_UC: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.
    • ASCS_INSTANCE_NUMBER: especifica o número da instância do ASCS.
    # crm configure primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
    device="NFS_PATH/usrsapSID_UCERSERS_INSTANCE_NUMBER" \
    directory="/usr/sap/SID_UC/ERSERS_INSTANCE_NUMBER" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

    Substitua:

    • ERS_FILE_SYSTEM_RESOURCE: especifica um nome para o recurso de cluster para o sistema de arquivos ERS.
    • NFS_PATH: especifica o caminho para o sistema de arquivos NFS do ERS.
    • SID_UC: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.
    • ERS_INSTANCE_NUMBER: especifica o número da instância do ASCS.

Criar os recursos da verificação de integridade

  1. Configure os recursos do cluster para as verificações de integridade do ASCS e ERS:
# crm configure primitive ASCS_HEALTH_CHECK_RESOURCE anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0
# crm configure primitive ERS_HEALTH_CHECK_RESOURCE anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0

Criar os recursos do VIP

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

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

    • gcloud compute addresses describe ASCS_VIP_NAME
      --region=CLUSTER_REGION --format="value(address)"
    • gcloud compute addresses describe ERS_VIP_NAME
      --region=CLUSTER_REGION --format="value(address)"
  2. Crie os recursos de cluster dos VIPs do ASCS e do ERS.

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

Ver os recursos definidos

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

    # crm status

    O resultado será semelhante a:

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

Instalar ASCS e ERS

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

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

Preparar para a instalação

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

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

    # crm configure property maintenance-mode="false"

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

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

    Substitua:

    • GID_SAPINST: especifica o ID do grupo do Linux para a ferramenta de provisionamento da SAP.
    • GID_SAPSYS: especifica o caminho para o sistema de arquivos NFS.
    • UID_SIDADM: especifica o número da instância do ASCS.
    • 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_UC: especifica o ID do sistema (SID). Use letras maiúsculas para qualquer letra.

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

    # 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. Em ambos os servidores, confirme se /usr/sap/sapservices contém entradas para os serviços ASCS 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_UC/SYS/profile/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID_UC/SYS/profile/SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
     -reg

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_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
    SID_UC_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_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_UC_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_UC como 1 no nó em que o ERS está ativo.

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_UC_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_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_UC_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_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true

Configurar grupos de recursos e restrições de local

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

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

    Substitua:

    • ASCS_RESOURCE_GROUP: especifica um nome de grupo exclusivo para os recursos do cluster do ASCS. É possível garantir a exclusividade usando uma convenção como "SID_ASCSinstance number_group". Por exemplo, `nw1_ASCS00_group`.
    • ASCS_FILE_SYSTEM_RESOURCE: especifica o nome do recurso do cluster que você definiu para o sistema de arquivos ASCS anteriormente.
    • ASCS_HEALTH_CHECK_RESOURCE: especifica o nome do recurso do cluster que você definiu para a verificação de integridade do ASCS anteriormente.
    • ASCS_VIP_RESOURCE: especifique o nome do recurso do cluster que você definiu para o VIP do ASCS antes.
    • ASCS_INSTANCE_RESOURCE: especifica anteriormente o nome do recurso do cluster que você definiu para a instância do ASCS.
    # crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
      ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
      ERS_INSTANCE_RESOURCE

    Substitua:

    • ERS_RESOURCE_GROUP: especifica um nome de grupo exclusivo para os recursos do cluster de ERS. É possível garantir a exclusividade usando uma convenção como "SID_ERS instance_group". Por 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_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
    2. Configure o ASCS para fazer failover ao servidor em que o ERS está sendo executado, o que é determinado pela sinalização runsersSID_UC ser igual a 1:

      # crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID_UC 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_UC_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE: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_RESOURCE_GROUP ASCS_RESOURCE_GROUP
    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_RESOURCE:start \
       ERS_INSTANCE_RESOURCE: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 ascs-aha-rsc-group-name filesystem-rsc-nw-aha-ascs health-check-rsc-nw-ha-ascs vip-rsc-nw-aha-ascs ascs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    colocation prevent-aha-ascs-ers-coloc -5000: ers-aha-rsc-group-name ascs-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 ascs-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 ascs-aha-rsc-group-name filesystem-rsc-nw-aha-ascs health-check-rsc-nw-ha-ascs vip-rsc-nw-aha-ascs ascs-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: ascs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
    colocation prevent-aha-ascs-ers-coloc -5000: ers-aha-rsc-group-name ascs-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

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

      > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""
    2. 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_UC_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_UC_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_UC_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_UC_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_UC_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

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

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