Guia de configuração de clusters de escalonamento vertical de alta disponibilidade para SAP HANA no RHEL

Neste guia, mostramos como implantar e configurar um cluster de alta disponibilidade (HA, na sigla em inglês) do Red Hat Enterprise Linux (RHEL) em um sistema SAP HANA 1.0 SPS 12 ou posterior de escalonamento vertical no Google Cloud.

Este guia inclui as etapas de:

• Como configurar um balanceador de carga de rede de passagem interno para redirecionar o tráfego em caso de falha
• Como configurar um cluster do Pacemaker no RHEL para gerenciar os sistemas SAP e outros recursos durante um failover

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

Para implantar um sistema SAP HANA sem um cluster de alta disponibilidade do Linux ou um host de nó em espera, use o guia de implantação do SAP HANA.

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

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

O sistema que este guia implanta

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

O cluster implantado inclui as seguintes funções e recursos:

• Duas VMs de host, cada uma com uma instância do SAP HANA
• Replicação síncrona do sistema SAP HANA.
• 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 e as instâncias do SAP HANA, garantindo que as VMs e os sistemas SAP HANA de base atendam aos requisitos de compatibilidade da SAP e as práticas recomendadas atuais.

O SAP HANA Studio é usado neste guia para testar a replicação do sistema SAP HANA. Se preferir, use o SAP HANA Cockpit. Para informações sobre como instalar o SAP HANA Studio, consulte:

• Como instalar o SAP HANA Studio em uma VM do Windows do Compute Engine
• Guia de instalação e atualização do SAP HANA Studio

Pré-requisitos

Antes de criar o cluster de alta disponibilidade do SAP HANA, verifique se os pré-requisitos a seguir são atendidos:

• Você leu o Guia de planejamento do SAP HANA e o Guia de planejamento de alta disponibilidade do SAP HANA.
• Você ou sua organização tem uma conta do Google Cloud e criou um projeto para a implantação do SAP HANA. Para informações sobre como criar contas e projetos do Google Cloud, consulte Como configurar sua Conta do Google no Guia de implantação do SAP HANA.
• Se você precisar que a carga de trabalho da SAP seja executada em conformidade com residência de dados, controle de acesso, equipes de suporte ou requisitos regulatórios, crie a pasta do Assured Workloads necessária. Para mais informações, consulte Controles soberanos e de conformidade para a SAP no Google Cloud.

• A mídia de instalação do SAP HANA está armazenada em um bucket do Cloud Storage disponível no projeto e na região de implantação. Para mais informações sobre como fazer upload da mídia de instalação do SAP HANA em um bucket do Cloud Storage, consulte Como fazer o download do SAP HANA no Guia de implantação do SAP HANA.

• Se o login do SO estiver ativado nos metadados do projeto, você precisará desativar o login do SO temporariamente até que a implantação seja concluída. Para fins de implantação, este procedimento configura chaves SSH em metadados de instâncias. Quando o login do SO é ativado, as configurações de chave SSH baseadas em metadados são desativadas e a implantação falha. Após a conclusão da implantação, ative o login do SO novamente.

  Veja mais informações em:

  • Como ativar ou desativar o Login do SO
  • Adicionar chaves SSH a VMs que usam chaves SSH baseadas em metadados

• Se você estiver usando o DNS interno da VPC, o valor da variável vmDnsSetting nos metadados do projeto precisará ser GlobalOnly ou ZonalPreferred para ativar a resolução dos nomes de nó nas zonas. A configuração padrão de vmDnsSetting é ZonalOnly. Para mais informações, consulte estes tópicos:

  • Como configurar nomes DNS para projetos ou instâncias
  • Como consultar metadados personalizados
  • Como definir metadados personalizados de projeto

Para evitar a exposição não intencional da instância de VM à Internet, siga estas recomendações:

• Use um gateway NAT.
• Crie regras de firewall que impeçam todo o acesso externo não solicitado.
• Ao criar as VMs:
  • Especifique uma tag de rede para cada uma delas, que seja usada em regras de roteamento e de firewall. Se você usar os modelos do Deployment Manager fornecidos pelo Google Cloud, especifique uma tag com networkTag: [TAG].
  • Crie as VMs sem um IP externo. Se você usar os modelos do Deployment Manager fornecidos pelo Google Cloud, especifique publicIP: No.

Como criar uma rede

Por motivos de segurança, crie uma nova rede. Para controlar quem tem acesso a ela, adicione regras de firewall ou use outro método de controle de acesso.

Caso o projeto tenha uma rede VPC padrão, não a use. Em vez disso, crie sua própria rede VPC para que as únicas regras de firewall aplicadas sejam aquelas criadas explicitamente por você.

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

Para configurar a rede:

Console

1. No Console do Google Cloud, acesse a página Redes VPC.

   Acessar redes VPC

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

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

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

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

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

gcloud

1. Acesse o Cloud Shell.

   Acesse o Cloud Shell

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

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

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

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

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

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

   Substitua:

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

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

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

Como configurar um gateway NAT

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

Ponto-chave: ao configurar o Cloud NAT, especifique pelo menos 160 como o número mínimo de portas por VM. Algumas atualizações de sistema operacional executam processos simultâneos que podem exceder o padrão do Cloud NAT para o número de portas, o que pode resultar em erros de ativação ou download.

Ao criar uma instância do Cloud NAT, especifique o número de portas no campo Mínimo de portas por VM em Configurações avançadas na página "Criar um gateway NAT" no console do Google Cloud.

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

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

Como adicionar regras de firewall

Por padrão, uma regra de firewall implícita bloqueia conexões de entrada de fora da rede de nuvem privada virtual (VPC). Para permitir conexões de entrada, configure uma regra de firewall para sua VM. Depois que uma conexão de entrada for estabelecida com uma VM, será permitido o tráfego nas duas direções nessa conexão.

Também é possível criar uma regra de firewall para permitir o acesso externo a portas especificadas ou para restringir o acesso entre as VMs na mesma rede. Se o tipo de rede VPC default for usado, algumas regras padrão complementares também serão aplicadas, como a regra default-allow-internal, que permite a conectividade entre VMs na mesma rede em todas as portas.

Dependendo da política de TI que for aplicada ao ambiente, pode ser necessário isolar ou então restringir a conectividade com o host do banco de dados, o que pode ser feito criando regras de firewall.

Dependendo do seu cenário, é possível criar regras de firewall para permitir o acesso para estes itens:

• Portas padrão do SAP listadas no TCP/IP de Todos os Produtos SAP.
• Conexões do seu computador ou do ambiente de rede corporativa para a instância de VM do Compute Engine. Se você não tiver certeza do endereço IP a ser usado, fale com o administrador de redes da sua empresa.
• A comunicação entre VMs na sub-rede do SAP HANA, incluindo a comunicação entre nós em um sistema de escalonamento horizontal do SAP HANA ou a comunicação entre o servidor de banco de dados e os servidores de aplicativos em uma arquitetura de três níveis. É possível ativar a comunicação entre as VMs criando uma regra de firewall para permitir o tráfego proveniente da sub-rede.

Observação: o procedimento a seguir é uma versão simplificada das instruções de criação de regras de firewall. Para instruções mais detalhadas, consulte Como criar regras de firewall.

Para criar uma regra de firewall:

Console

1. No console do Google Cloud, acesse a página Firewall da rede VPC.

   Acessar o Firewall

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

   • No campo Rede, selecione a rede em que a VM está localizada.
   • No campo Destinos, especifique os recursos no Google Cloud a que esta regra se aplica. Por exemplo, especifique Todas as instâncias na rede. Ou, para limitar a regra a instâncias específicas no Google Cloud, insira tags em Tags de destino especificado.
   • No campo Filtro de origem, selecione uma das opções a seguir:
     • Intervalos de IP 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 determinada sub-rede. Especifique o nome da sub-rede no campo Sub-redes a seguir. É possível usar esta 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 insira tcp:PORT_NUMBER.

3. Clique em Criar para criar a regra de firewall.

gcloud

Crie uma regra de firewall usando o seguinte comando:

$ gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS

Como implantar as VMs e o SAP HANA

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

Para definir e implantar os sistemas, use o mesmo modelo do Cloud Deployment Manager usado para implantar um sistema SAP HANA no guia de implantação do SAP HANA.

No entanto, para implantar dois sistemas em vez de um, você precisa adicionar a definição do segundo sistema ao arquivo de configuração copiando e colando a definição do primeiro sistema. 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 os sistemas SAP HANA forem implantados, você definirá e configurará o cluster de alta disponibilidade.

As instruções a seguir são para o Cloud Shell, mas, no geral, podem ser aplicadas à Google Cloud CLI.

1. Confirme se as cotas atuais para recursos, como discos permanentes e CPUs, são suficientes para os sistemas SAP HANA que você está prestes a instalar. Se as cotas não forem suficientes, a implantação falhará. Para saber os requisitos de cotas do SAP HANA, consulte Considerações sobre preços e cotas para SAP HANA.

   Acessar a página de cotas

2. Abra o Cloud Shell ou, se tiver instalado a CLI gcloud na estação de trabalho local, abra um terminal.

   Acessar o Cloud Shell

3. Faça o download do modelo do arquivo de configuração template.yaml do cluster de alta disponibilidade do SAP HANA para o diretório de trabalho usando o seguinte comando no Cloud Shell ou no CLI gcloud:

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

4. Você tem a opção de renomear o arquivo template.yaml para identificar a configuração que ele define.

5. Abra o arquivo template.yaml no editor de código do Cloud Shell ou, se estiver usando o gcloud, o editor de texto de sua escolha.

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

6. No arquivo template.yaml, conclua a definição do sistema SAP HANA principal. 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 criar as instâncias de VM sem instalar o SAP HANA, exclua ou comente todas as linhas que começam com sap_hana_.

   Propriedade	Tipo de dados	Descrição
   Tipo	String	Especifica o local, o tipo e a versão do modelo do Deployment Manager a ser usado durante a implantação. O arquivo YAML inclui duas especificações type, uma delas comentada. A especificação type que está ativa por padrão especifica a versão do modelo como latest. A especificação type comentada especifica uma versão de modelo específica com carimbo de data/hora. Se você precisar que todas as suas implantações usem a mesma versão de modelo, use a especificação type que inclui o carimbo de data/hora.
   instanceName	String	O nome da instância de VM que está sendo definida no momento. Especifique nomes diferentes nas definições de VM principal e secundária. Os nomes precisam ser especificados em letras minúsculas, números ou hífens.
   instanceType	String	O tipo de máquina virtual do Compute Engine em que é necessário executar o SAP HANA. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido com um número de vCPUs o mais próximo possível do necessário, mesmo que maior. Após a conclusão da implantação, modifique o número de vCPUs e a quantidade de memória. .
   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 primárias e secundárias do HANA. As zonas precisam estar na mesma região selecionada para a sub-rede.
   subnetwork	String	Nome da sub-rede criado em uma etapa anterior. Se estiver implantando em uma VPC compartilhada, especifique esse valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por exemplo, myproject/network1.
   linuxImage	String	Nome da imagem do sistema operacional Linux ou da família de imagens que você está usando com o SAP HANA. Para especificar uma família de imagens, adicione o prefixo family/ ao nome da família. Por exemplo, family/rhel-7-6-sap-ha. Para definir uma imagem específica, determine somente o nome da imagem. Para ver a lista de imagens e famílias disponíveis, consulte a página Imagens no Console do Google Cloud.
   linuxImageProject	String	O projeto do Google Cloud que contém a imagem que você usará. Ele pode ser o próprio projeto ou um projeto de imagem do Google Cloud, como rhel-sap-cloud. Para mais informações sobre projetos de imagem do Google Cloud, consulte a página Imagens na documentação do Compute Engine.
   sap_hana_deployment_bucket	String	Nome do bucket de armazenamento do Google Cloud no projeto que contém os arquivos de instalação e revisão do SAP HANA enviados em uma etapa anterior. Todos os arquivos de revisão de upgrade no bucket são aplicados ao SAP HANA durante o processo de implantação.
   sap_hana_sid	String	O ID do sistema (SID, na sigla em inglês) do SAP HANA. O ID precisa ter três caracteres alfanuméricos e começar com uma letra. Todas as letras precisam ser maiúsculas.
   sap_hana_instance_number	Inteiro	Número da instância, 0 a 99, do sistema SAP HANA. O padrão é 0.
   sap_hana_sidadm_password	String	A senha do administrador do sistema operacional (SO). As senhas precisam ter no mínimo oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. Cuidado: mude a senha depois que a instalação for concluída.
   sap_hana_system_password	String	A senha do superusuário do banco de dados. As senhas precisam ter pelo menos oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. Cuidado: mude a senha depois que a instalação for concluída.
   sap_hana_sidadm_uid	Inteiro	O valor padrão do ID do usuário SID_LCadm é 900 para evitar que grupos criados por usuários entrem em conflito com o SAP HANA. É possível alterar para um valor diferente, se necessário.
   sap_hana_sapsys_gid	Inteiro	O ID de grupo padrão do sapsys é 79. Ao especificar um valor acima, é possível substituir esse valor pelos seus requisitos.
   sap_hana_scaleout_nodes	Inteiro	Especifique 0. Estas instruções são apenas para sistemas SAP HANA de escalonamento vertical.
   networkTag	String	Uma tag de rede que representa a instância de VM para fins de firewall ou roteamento. Se você especificar publicIP: No e não inserir uma tag de rede, forneça outro meio de acesso à Internet.
   nic_type	String	Opcional, mas recomendado se disponível para a máquina de destino e a versão do SO. Especifica a interface de rede a ser usada com a instância de VM. É possível especificar o valor GVNIC ou VIRTIO_NET. Para usar uma NIC virtual do Google (gVNIC), especifique uma imagem do SO compatível com gVNIC como o valor da propriedade linuxImage. Confira a lista de imagens do SO em Detalhes do sistema operacional. Se você não especificar um valor para essa propriedade, a interface de rede será selecionada automaticamente com base no tipo de máquina especificado para a propriedade instanceType. Esse argumento está disponível nas versões 202302060649 ou posteriores do modelo do Deployment Manager.
   publicIP	Booleano	Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes. Observação: não especifique No a menos que você tenha um gateway NAT configurado com uma tag de rede definida para a VM ou que tenha fornecido à VM outra rota para a Internet. Se não houver rota para a Internet, a instalação falhará.
   serviceAccount	String	Opcional. Especifica uma conta de serviço a ser usada pelas VMs de host e pelos programas executados nas VMs de host. Especifique o endereço de e-mail da conta de serviço. Por exemplo, [e-mail]. Por padrão, a conta de serviço padrão do Compute Engine é usada. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.

7. Crie a definição do sistema SAP HANA secundário, copiando a definição do sistema SAP HANA principal e colando a cópia após a definição do sistema SAP HANA principal. Veja o exemplo seguindo estas etapas.

8. Na definição do sistema SAP HANA secundário, especifique valores para as propriedades a seguir diferentes daqueles definidos na definição do sistema SAP HANA principal:

   • name
   • instanceName
   • zone

9. Crie as instâncias:

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

   O comando acima invoca o Deployment Manager, que implanta as VMs, faz o download do software do SAP HANA do bucket de armazenamento e instala o SAP HANA de acordo com as especificações do arquivo template.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 template.yaml completo

O exemplo a seguir mostra um arquivo de configuração template.yaml completo que implanta duas instâncias de VM com um sistema SAP HANA instalado.

O arquivo contém as definições de dois recursos a serem implantados: sap_hana_primary e sap_hana_secondary. Cada definição de recurso contém as definições de uma VM e uma instância do SAP HANA.

A definição do recurso sap_hana_secondary 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, serviceAccount, sap_hana_sidadm_uid e sap_hana_sapsys_gid são da seção Opções avançadas do modelo de arquivo de configuração. As propriedades sap_hana_sidadm_uid e sap_hana_sapsys_gid são incluídas para mostrar os valores padrão, que são usados porque as propriedades são comentadas.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    

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

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 e do SAP HANA

Para verificar a implantação, verifique os registros de implantação no Cloud Logging e verifique os discos e serviços nas VMs dos hosts principal e secundário.

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

   Observação: podem ser incorridos custos ao concluir esta etapa no Cloud Logging. Para mais informações, consulte os preços do Cloud Logging.

   Acesse o Cloud Logging

2. Filtre os registros:

   Explorador de registros

   1. Na página Explorador de registros, acesse o painel Consulta.

   2. No menu suspenso Recurso, selecione Global e clique em Adicionar.

      Se a opção Global não for exibida, insira a seguinte consulta no editor de consultas:

      resource.type="global"
      "Deployment"
      

   3. Clique em Run query.

   Visualizador de registros legado

   • Na página Visualizador de registros legado, no menu de seleção básico, selecione Global como o recurso de registros.

3. Analise os registros filtrados:

   • Se "--- Finished" for exibido, o processamento do Deployment Manager estará concluído e será possível prosseguir para a próxima etapa.

   • Se você vir um erro de cota:

     1. Na página Cotas do IAM e Admin, aumente as cotas que não atendem aos requisitos do SAP HANA listados no Guia de planejamento do SAP HANA.

     2. Na página Implantações do Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.

     3. Execute a implantação novamente.

Verificar a configuração das VMs e do SAP HANA

1. Depois de implantar o sistema SAP HANA sem erros, conecte-se a cada VM usando SSH. Na página Instâncias de VM do Compute Engine, clique no botão "SSH" para cada instância de VM ou use seu método de SSH preferido.

   

2. Mude para o usuário raiz.

   $ sudo su -

3. No prompt de comando, insira df -h. Em cada VM, verifique se você vê os diretórios /hana, como /hana/data.

   Filesystem                        Size  Used Avail Use% Mounted on
   /dev/sda2                          30G  4.0G   26G  14% /
   devtmpfs                          126G     0  126G   0% /dev
   tmpfs                             126G     0  126G   0% /dev/shm
   tmpfs                             126G   17M  126G   1% /run
   tmpfs                             126G     0  126G   0% /sys/fs/cgroup
   /dev/sda1                         200M  9.7M  191M   5% /boot/efi
   /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
   /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
   /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
   /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
   /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
   tmpfs                              26G     0   26G   0% /run/user/900
   tmpfs                              26G     0   26G   0% /run/user/899
   tmpfs                              26G     0   26G   0% /run/user/1000

4. Altere para o usuário administrador do SAP substituindo SID_LC no comando a seguir pelo ID do sistema especificado no modelo do arquivo de configuração. Use letras minúsculas para letras.

   # su - SID_LCadm

5. Para verificar se os serviços do SAP HANA, como hdbnameserver, hdbindexserver e outros, estão sendo executados na instância, digite o seguinte comando:

   > HDB info

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

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

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

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

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

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

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

2. Execute este comando:

   systemctl status google-cloud-sap-agent

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

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

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

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

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

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

2. No painel de visão geral, verifique a disponibilidade e o conteúdo dos seguintes campos para a configuração completa da infraestrutura de monitoramento da SAP e do Google:

   • Provedor de nuvem: Google Cloud Platform
   • Acesso ao monitoramento avançado: TRUE
   • Detalhes do monitoramento avançado: ACTIVE

Configurar o monitoramento para o SAP HANA

Como opção, monitore as instâncias do SAP HANA usando o agente do Google Cloud para SAP. A partir da versão 2.0, é possível configurar o agente para coletar as métricas de monitoramento do SAP HANA e enviá-las para o Cloud Monitoring. O Cloud Monitoring permite criar painéis para visualizar essas métricas, configurar alertas com base em limites de métrica e muito mais.

Para mais informações sobre a coleta de métricas de monitoramento do SAP HANA usando o agente do Google Cloud para SAP, consulte Coleta de métricas de monitoramento do SAP HANA.

Ativar a reinicialização rápida do SAP HANA

O Google Cloud recomenda fortemente ativar a reinicialização rápida do SAP HANA para cada instância do SAP HANA, especialmente para instâncias maiores. A reinicialização rápida do SAP HANA reduz os tempos de reinicialização caso o SAP HANA seja encerrado, mas o sistema operacional continua em execução.

Observação: se você implantar o SAP HANA usando o módulo Terraform do Google Cloud sap_hana ou sap_hana_ha, versão 202309280828 ou posterior, então a reinicialização rápida será ativada automaticamente.

Conforme definido pelos scripts de automação que o Google Cloud fornece, as configurações do sistema operacional e do kernel já aceitam o Inicialização rápida do SAP HANA. Você precisa definir o sistema de arquivos tmpfs e configurar o SAP HANA.

Para definir o sistema de arquivos tmpfs e configurar o SAP HANA, siga as etapas manuais ou use o script de automação fornecido pelo Google Cloud para ativar a reinicialização rápida do SAP HANA. Para mais informações, veja:

• Etapas manuais: ativar a reinicialização rápida do SAP HANA
• Etapas automatizadas: ativar a reinicialização rápida do SAP HANA

Para receber instruções completas sobre a reinicialização rápida do SAP HANA, consulte a documentação da opção de reinicialização rápida do SAP HANA.

Etapas manuais

Configurar o sistema de arquivos tmpfs

Depois que as VMs do host e os sistemas SAP HANA de base forem implantados, você precisará criar e ativar diretórios para os nós NUMA no sistema de arquivos tmpfs.

Exibir a topologia de NUMA da sua VM

Antes de mapear o sistema de arquivos tmpfs necessário, você precisa saber quantos nós NUMA sua VM tem. Para exibir os nós NUMA disponíveis em uma VM do Compute Engine, digite o seguinte comando:

lscpu | grep NUMA

Por exemplo, um tipo de VM m2-ultramem-208 tem quatro nós NUMA, numerados de 0 a 3, conforme mostrado no exemplo a seguir:

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207

Criar os diretórios de nós NUMA

Crie um diretório para cada nó NUMA na sua VM e defina as permissões.

Por exemplo, para quatro nós NUMA numerados de 0 a 3:

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID

Montar os diretórios de nó NUMA em tmpfs

Monte os diretórios do sistema de arquivos tmpfs e especifique uma preferência de nó NUMA para cada um com mpol=prefer:

SID especifica o SID com letras maiúsculas.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID

Observação: se você alterar os tipos de máquina e os nós NUMA aumentarem ou diminuirem, será necessário modificar o sistema de arquivos tmpfs e a seção [persistence] do arquivo INI do SAP HANA, mostrado na próxima seção, para corresponder ao novo número de nós NUMA.

Atualizar /etc/fstab

Para garantir que os pontos de montagem estejam disponíveis após uma reinicialização do sistema operacional, adicione entradas à tabela do sistema de arquivos, /etc/fstab:

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Opcional: defina limites de uso de memória

O sistema de arquivos tmpfs pode aumentar e diminuir dinamicamente.

Para limitar a memória usada pelo sistema de arquivos tmpfs, defina um limite de tamanho para um volume de nó NUMA com a opção size. Por exemplo:

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

Também é possível limitar o uso geral da memória tmpfs para todos os nós NUMA de uma determinada instância do SAP HANA e de um determinado nó do servidor definindo o parâmetro persistent_memory_global_allocation_limit na seção [memorymanager] do arquivo global.ini.

Configuração do SAP HANA para reinicialização rápida

Para configurar o SAP HANA para reinicialização rápida, atualize o arquivo global.ini e especifique as tabelas a serem armazenadas na memória permanente.

Atualize a seção [persistence] no arquivo global.ini

Configure a seção [persistence] no arquivo global.ini do SAP HANA para fazer referência aos locais tmpfs. Separe cada local tmpfs com um ponto e vírgula:

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

O exemplo anterior especifica quatro volumes de memória para quatro nós NUMA, que correspondem a m2-ultramem-208. Se você estivesse executando no m2-ultramem-416, seria necessário configurar oito volumes de memória (0..7).

Reinicie o SAP HANA depois de modificar o arquivo global.ini.

O SAP HANA agora pode usar o local tmpfs como espaço de memória permanente.

Especificar as tabelas a serem armazenadas na memória permanente

Especifique tabelas ou partições específicas de coluna para armazenar na memória permanente.

Por exemplo, para ativar a memória permanente de uma tabela atual, execute a consulta SQL:

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Para alterar o padrão de novas tabelas, adicione o parâmetro table_default no arquivo indexserver.ini. Por exemplo:

[persistent_memory]
table_default = ON

Para mais informações sobre como controlar colunas, tabelas e quais visualizações de monitoramento fornecem informações detalhadas, consulte Memória permanente do SAP HANA.

Etapas automatizadas

O script de automação que o Google Cloud fornece para ativar a Inicialização rápida do SAP HANA faz mudanças nos diretórios /hana/tmpfs*, /etc/fstab e na configuração do SAP HANA. Ao executar o script, talvez seja necessário executar etapas adicionais, dependendo se essa é a implantação inicial do seu sistema SAP HANA ou se você está redimensionando sua máquina para um tamanho de NUMA diferente.

Para a implantação inicial do seu sistema SAP HANA ou redimensionar a máquina para aumentar o número de nós NUMA, verifique se o SAP HANA está em execução durante a execução do script de automação que o Google Cloud fornece para permitir a reinicialização rápida do SAP HANA.

Ao redimensionar a máquina para diminuir o número de nós NUMA, verifique se o SAP HANA é interrompido durante a execução do script de automação fornecido pelo Google Cloud para ativar a reinicialização rápida do SAP HANA. Depois que o script for executado, você precisará atualizar manualmente a configuração do SAP HANA para concluir a configuração de reinício rápido do SAP HANA. Para mais informações, consulte Configuração do SAP HANA para reinício rápido.

Observação: é altamente recomendável executar o script fornecido pelo Google Cloud para ativar o reinício rápido do SAP HANA em um ambiente de não produção e verificar os resultados completamente antes de executar o script em ambientes de produção. Você assume a responsabilidade de ativar corretamente a reinicialização rápida do SAP HANA.

Para ativar o reinício rápido do SAP HANA, siga estas etapas:

1. Estabeleça uma conexão SSH com sua VM do host.

2. Mudar para raiz:

   sudo su -

3. Faça o download do script sap_lib_hdbfr.sh:

   wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

4. Torne o arquivo executável:

   chmod +x sap_lib_hdbfr.sh

5. Verifique se o script não tem erros:

   vi sap_lib_hdbfr.sh
   ./sap_lib_hdbfr.sh -help

   Se o comando retornar um erro, entre em contato com o Cloud Customer Care. Para mais informações sobre como entrar em contato com o Customer Care, consulte Como receber suporte para a SAP no Google Cloud.

6. Execute o script depois de substituir o ID do sistema (SID) do SAP HANA e a senha do usuário SYSTEM do banco de dados do SAP HANA. Para fornecer a senha com segurança, recomendamos que você use uma chave secreta no Gerenciador de secrets.

   Execute o script usando o nome de um secret no Secret Manager. Esse secret precisa existir no projeto do Google Cloud que contém a instância de VM do host.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME 

   Substitua:

   • SID: especifique o SID com letras maiúsculas. Por exemplo, AHA.
   • SECRET_NAME: especifique o nome do secret que corresponde à senha do usuário do SYSTEM do banco de dados do SAP HANA. Esse secret precisa existir no projeto do Google Cloud que contém a instância de VM do host.

   Outra opção é executar o script com uma senha de texto simples. Depois que a reinicialização rápida do SAP HANA estiver ativada, altere sua senha. Não é recomendável usar uma senha de texto simples, porque ela seria registrada no histórico de linha de comando da VM.

   sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

   Substitua:

   • SID: especifique o SID com letras maiúsculas. Por exemplo, AHA.
   • PASSWORD: especifique a senha do usuário do SYSTEM do banco de dados SAP HANA.

Para uma execução inicial bem-sucedida, você verá uma saída semelhante a esta:

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Opcional: configurar chaves SSH nas VMs principais e secundárias

As chaves de armazenamento seguro (SSFS, na sigla em inglês) do SAP HANA precisam ser sincronizadas entre os hosts no cluster de alta disponibilidade. Para simplificar a sincronização e permitir que arquivos como backups sejam copiados entre os hosts no cluster de alta disponibilidade, estas instruções autorizam conexões SSH diretas entre os dois hosts.

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, será possível sincronizar as chaves SSFS e transferir arquivos usando outros métodos, como:

• Transfira arquivos menores por meio da estação de trabalho local usando as opções de menu Fazer upload de arquivos e Fazer o download de arquivos do Cloud Shell. Consulte Como gerenciar arquivos com o Cloud Shell.
• Trocar arquivos usando um bucket do Google Cloud Storage. Consulte Como trabalhar com objetos na documentação do Cloud Storage.
• Use o agente Backint do Cloud Storage para SAP HANA para fazer backup e restaurar bancos de dados HANA. Consulte Agente Backint do Cloud Storage para SAP HANA.
• Use uma solução de armazenamento de arquivos, como Filestore ou NetApp Cloud Volumes Service, para criar uma pasta compartilhada. Consulte Opções do servidor de arquivos.

Para ativar as conexões SSH entre as instâncias principal e secundária, siga estas etapas.

1. Na VM do host principal:

   1. Conecte-se por SSH à VM.

   2. Gere uma chave SSH para o usuário que precisa da conexão SSH de um host para outro. O usuário normalmente é você.

      $ ssh-keygen

   3. Nas solicitações, aceite os padrões pressionando a tecla Enter.

   4. Atualize os metadados da VM principal com informações sobre a chave SSH da VM secundária.

      $ gcloud compute instances add-metadata secondary-host-name \
           --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
           --zone secondary-zone

   5. Autorizar a VM principal para si mesma

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

2. Na VM do host secundário:

   1. Conecte-se por SSH à VM.

   2. Gere uma chave SSH para o usuário que precisa da conexão SSH de host para host.

      $ ssh-keygen

   3. Atualize os metadados da VM secundária com informações sobre a chave SSH da VM principal.

      $ gcloud compute instances add-metadata primary-host-name \
            --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
            --zone primary-zone

   4. Autorizar a VM secundária para si mesma

      $ 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-host-name

3. Na VM do host principal, confirme a conexão abrindo uma conexão SSH com a VM do host secundário:

   $ ssh secondary-host-name

Fazer backup dos bancos de dados

Crie backups dos seus bancos de dados para iniciar a geração de registros do banco de dados para a replicação do sistema SAP HANA e criar um ponto de recuperação.

Se você tiver bancos de dados multilocatário em uma configuração de MDC, faça backup de cada banco de dados de locatário.

O modelo do Deployment Manager usa /hanabackup/data/SID como o diretório de backup padrão.

Para criar backups de novos bancos de dados SAP HANA:

1. No host principal, mude para SID_LCadm. Dependendo da imagem do SO, o comando pode ser diferente.

   sudo -i -u SID_LCadm

2. Crie backups de banco de dados:

   • Para um sistema de contêiner de banco de dados único do SAP HANA:

     > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     O exemplo a seguir mostra uma resposta bem-sucedida de um novo sistema SAP HANA:

     0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

   • Para um sistema de contêiner de vários bancos de dados (MDC, na sigla em inglês) do SAP HANA, crie um backup do banco de dados do sistema e de quaisquer bancos de dados de locatário:

     > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

     > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
       "backup data using file ('full')"

   O exemplo a seguir mostra uma resposta bem-sucedida de um novo sistema SAP HANA:

   0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

3. Confirme se o modo de geração de registros está definido como normal:

   > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
     "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

   Você verá:

   VALUE
   "normal"

Ativar a replicação do sistema SAP HANA

Como parte da ativação da replicação do sistema SAP HANA, você precisa copiar os dados e os arquivos de chave para os armazenamentos seguros do SAP HANA no sistema de arquivos (SSFS) do host principal para o host secundário. O método usado para copiar os arquivos é apenas um método possível.

1. No host principal como SID_LCadm, ative a replicação do sistema:

   > hdbnsutil -sr_enable --name=primary-host-name

2. No host secundário como SID_LCadm, interrompa o SAP HANA:

   > HDB stop

3. No host principal, usando a mesma conta de usuário usada para configurar o SSH entre as VMs do host, copie os arquivos de chave para o host secundário. Por conveniência, os seguintes comandos também definem uma variável de ambiente para o ID da sua conta de usuário:

   $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
   $ myid=$(whoami)
   $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
   $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
   $ rm -r /home/"${myid}"/rsecssfs
   

4. No host secundário, como o mesmo usuário da etapa anterior:

   1. Substitua os arquivos de chave nos diretórios rsecssfs pelos arquivos do host principal e defina as permissões do arquivo para limitar o acesso:

      $ SAPSID=SID
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ myid=$(whoami)
      $ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chown "${SAPSID,,}"adm:sapsys \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
      $ sudo chmod 644 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
      $ sudo chmod 640 \
        /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY

   2. Limpe os arquivos no diretório principal.

      $ rm -r /home/"${myid}"/rsecssfs

   3. Como SID_LCadm, registre o sistema SAP HANA secundário com a replicação do sistema SAP HANA:

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
      --replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name

   4. Como SID_LCadm, inicie o SAP HANA:

      > HDB start

Como validar a replicação do sistema

No host principal como SID_LCadm, confirme se a replicação do sistema SAP HANA está ativa executando o seguinte script Python:

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Se a replicação estiver configurada corretamente, entre outros indicadores, os seguintes valores serão exibidos para os serviços xsengine, nameserver e indexserver:

• O Secondary Active Status é YES
• O Replication Status é ACTIVE

Além disso, o overall system replication status mostra ACTIVE.

Configurar o suporte a failover do Cloud Load Balancing

O serviço de balanceador de carga de rede de passagem interno com suporte a failover direciona o tráfego para o host ativo em um cluster do SAP HANA com base em um serviço de verificação de integridade.

Reservar um endereço IP para o IP virtual

O endereço IP virtual (VIP, na sigla em inglês), às vezes chamado de endereço IP flutuante, segue o sistema SAP HANA ativo. O balanceador de carga encaminha o tráfego enviado ao VIP para a VM que está hospedando o sistema ativo do SAP HANA.

1. Abra o Cloud Shell:

   Acessar o Cloud Shell

2. Reserve um endereço IP para o IP virtual. Esse é o endereço IP que os aplicativos usam para acessar o SAP HANA. Se você omitir a sinalização --addresses, um endereço IP será escolhido para você na sub-rede especificada:

   $ gcloud compute addresses create VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses VIP_ADDRESS

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

3. Confirmar reserva de endereço IP:

   $ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   O resultado será semelhante a:

   address: 10.0.0.19
   addressType: INTERNAL
   creationTimestamp: '2020-05-20T14:19:03.109-07:00'
   description: ''
   id: '8961491304398200872'
   kind: compute#address
   name: vip-for-hana-ha
   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/vip-for-hana-ha
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Criar grupos de instâncias para suas VMs de host

1. No Cloud Shell, crie dois grupos de instâncias não gerenciadas e atribua a VM do host mestre principal a um e a VM do host mestre secundário à outra:

   $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
     --zone=PRIMARY_ZONE \
     --instances=PRIMARY_HOST_NAME
   $ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE
   $ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
     --zone=SECONDARY_ZONE \
     --instances=SECONDARY_HOST_NAME
   

2. 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
   hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
   hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Criar uma verificação de integridade do Compute Engine

1. No Cloud Shell, crie a verificação de integridade. Para a porta usada pela verificação de integridade, escolha uma porta que esteja no intervalo privado 49152-65535 para evitar conflitos com outros serviços. Os valores de intervalo de verificação e tempo limite são um pouco mais longos do que os padrões para 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:

   $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

2. Confirme a criação da verificação de integridade:

   $ gcloud compute health-checks describe HEALTH_CHECK_NAME

   O resultado será semelhante a:

   checkIntervalSec: 10
   creationTimestamp: '2020-05-20T21:03:06.924-07:00'
   healthyThreshold: 2
   id: '4963070308818371477'
   kind: compute#healthCheck
   name: hana-health-check
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
   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

Defina uma regra de firewall para uma porta no intervalo particular que permita o acesso às VMs do host a partir dos intervalos de IP usados pelas verificações de integridade do Compute Engine, 35.191.0.0/16 e 130.211.0.0/22. Para mais informações, consulte Como criar regras de firewall para verificações de integridade.

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

   $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone PRIMARY_ZONE
   $ gcloud compute instances add-tags SECONDARY_HOST_NAME \
     --tags NETWORK_TAGS \
     --zone SECONDARY_ZONE
   

2. Se você ainda não tiver uma, crie uma regra de firewall 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:HLTH_CHK_PORT_NUM

   Por exemplo:

   gcloud compute firewall-rules create  fw-allow-health-checks \
   --network example-network \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
   --target-tags cluster-ntwk-tag \
   --rules tcp:60000

Configurar o balanceador de carga e o grupo de failover

1. Crie o serviço de back-end do balanceador de carga:

   $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
     --load-balancing-scheme internal \
     --health-checks 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:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group PRIMARY_IG_NAME \
     --instance-group-zone PRIMARY_ZONE \
     --region CLUSTER_REGION

3. Adicione o grupo de instâncias de failover secundário ao serviço de back-end:

   $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --instance-group SECONDARY_IG_NAME \
     --instance-group-zone SECONDARY_ZONE \
     --failover \
     --region CLUSTER_REGION

4. Crie uma regra de encaminhamento. No caso do endereço IP, especifique aquele que você reservou para o VIP. Se você precisar acessar o sistema SAP HANA de fora da região especificada abaixo, inclua a sinalização --allow-global-access na definição:

   $ gcloud compute forwarding-rules create RULE_NAME \
     --load-balancing-scheme internal \
     --address VIP_ADDRESS \
     --subnet CLUSTER_SUBNET \
     --region CLUSTER_REGION \
     --backend-service BACKEND_SERVICE_NAME \
     --ports ALL

   Para mais informações sobre o acesso entre regiões ao sistema de alta disponibilidade do SAP HANA, consulte Balanceamento de carga TCP/UDP interno.

Observação: os grupos de instâncias de back-end não serão registrados como íntegros até que você conclua a configuração do cluster do Pacemaker.

Testar a configuração do balanceador de carga

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

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

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

É possível usar o utilitário socat para detectar temporariamente a porta de verificação de integridade.

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

   $ sudo yum install -y socat

2. Inicie um processo socat para detectar por 60 segundos na porta de verificação de integridade:

   $ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

3. 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-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

Como testar o balanceador de carga usando a porta 22

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

Para usar temporariamente a porta 22, siga estas etapas:

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

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

2. Clique em Editar.

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

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

5. No Cloud Shell, 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-a/instanceGroups/hana-ha-ig-1
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
      ipAddress: 10.0.0.35
      port: 80
    kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
   status:
    healthStatus:
    ‐ healthState: HEALTHY
      instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
      ipAddress: 10.0.0.34
      port: 80
    kind: compute#backendServiceGroupHealth

6. Quando terminar, altere o número da porta de verificação de integridade para o número de porta original.

Configurar o Pacemaker

O procedimento a seguir configura a implementação do Red Hat de um cluster do Pacemaker em VMs do Compute Engine para SAP HANA.

O procedimento é baseado na documentação do Red Hat para configurar clusters de alta disponibilidade, incluindo (uma assinatura do Red Hat é necessária):

• Como instalar e configurar um cluster de alta disponibilidade do Red Hat Enterprise Linux 7.6 (ou posterior) no Google Cloud
• Replicação automatizada do sistema SAP HANA em escalonamento vertical no cluster do Pacemaker

Instalar os agentes do cluster nos dois nós

Conclua as etapas a seguir nos dois nós.

1. Como raiz, instale os componentes do Pacemaker:

   # yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
   # yum update -y

   Caso use uma imagem RHEL para SAP fornecida pelo Google, esses pacotes já estão instalados, mas algumas atualizações podem ser necessárias.

2. Defina a senha do usuário hacluster, que é instalado como parte dos pacotes:

   # passwd hacluster

3. Especifique uma senha para hacluster nas solicitações.

4. Nas imagens do RHEL fornecidas pelo Google Cloud, o serviço de firewall do SO está ativo por padrão. Configure o serviço de firewall para permitir tráfego de alta disponibilidade:

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

5. Inicie o serviço de PCs e configure-o para iniciar no momento da inicialização:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

6. Verifique o status do serviço de PCs:

   # systemctl status pcsd.service

   A resposta será assim:

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

7. No arquivo /etc/hosts, adicione o nome completo do host e os endereços IP internos dos dois hosts no cluster. Exemplo:

   127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
   ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
   10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
   10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2
   169.254.169.254 metadata.google.internal  # Added by Google

   Para mais informações do Red Hat sobre como configurar o arquivo /etc/hosts nos nós do cluster RHEL, consulte https://access.redhat.com/solutions/81123.

Crie o cluster

1. Como raiz em um dos nós, autorize o usuário hacluster. Clique na guia da versão do RHEL para ver o comando:

   RHEL 8 e versões mais recentes

   # pcs host auth primary-host-name secondary-host-name

   RHEL 7

   # pcs cluster auth primary-host-name secondary-host-name

2. Nas solicitações, digite o nome de usuário hacluster e a senha que você definiu para o usuário hacluster.

3. Crie o cluster:

   RHEL 8 e versões mais recentes

   # pcs cluster setup cluster-name primary-host-name secondary-host-name

   RHEL 7

   # pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Editar as configurações padrão corosync.conf

Edite o arquivo /etc/corosync/corosync.conf no host principal para definir um ponto de partida mais apropriado para testar a tolerância a falhas do cluster de alta disponibilidade no Google Cloud.

1. Nos dois hosts, use o editor de texto que preferir para abrir o arquivo /etc/corosync/corosync.conf para edição:

   # /etc/corosync/corosync.conf

2. Se /etc/corosync/corosync.conf for um novo arquivo ou estiver em branco, será possível verificar o diretório /etc/corosync/ para ver um arquivo de exemplo a ser usado como base para o arquivo rosync.

3. Na seção totem do arquivo corosync.conf, adicione as seguintes propriedades com os valores sugeridos, como mostrado na versão do RHEL:

   RHEL 8 e versões mais recentes

   • transport: knet
   • token: 20000
   • token_retransmits_before_loss_const: 10
   • join: 60
   • max_messages: 20

   Exemplo:

   totem {
   version: 2
   cluster_name: hacluster
   secauth: off
   transport: knet
   token: 20000
   token_retransmits_before_loss_const: 10
   join: 60
   max_messages: 20
   }
   ...

   RHEL 7

   • transport: udpu
   • token: 20000
   • token_retransmits_before_loss_const: 10
   • join: 60
   • max_messages: 20

   Exemplo:

   totem {
   version: 2
   cluster_name: hacluster
   secauth: off
   transport: udpu
   token: 20000
   token_retransmits_before_loss_const: 10
   join: 60
   max_messages: 20
   }
   ...

4. No host com o arquivo corosync.conf editado, sincronize a configuração do corosync em todo o cluster:

   RHEL 8 e versões mais recentes

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

5. Configure o cluster a ser iniciado automaticamente:

   1. # pcs cluster enable --all

   2. # pcs cluster start --all

6. Confirme se as novas configurações do corosync estão ativas no cluster por meio do utilitário corosync-cmapctl:

   # corosync-cmapctl

Configurar o isolamento

As imagens RHEL fornecidas pelo Google Cloud incluem um agente de isolamento fence_gce específico para o Google Cloud. Use fence_gce para criar dispositivos de isolamento para cada VM de 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.

Para ver todas as opções disponíveis com o agente de isolamento fence_gce, emita fence_gce -h.

Observação: se você alterou os nomes de host para que não sejam mais os mesmos nomes de instância de VM, consulte Como instalar e configurar um Cluster de alta disponibilidade do Red Hat Enterprise Linux 7.6 (e posterior) no Google Compute Cloud. As etapas a seguir exigem que os nomes de host e de instância de VM sejam os mesmos.

Criar os recursos do dispositivo de isolamento

1. No host principal como raiz:

   1. Crie um dispositivo de isolamento para cada VM do host:

      # pcs stonith create primary-fence-name fence_gce \
        port=primary-host-name \
        zone=primary-host-zone \
        project=project-id \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"
      # pcs stonith create secondary-fence-name fence_gce \
        port=secondary-host-name \
        zone=secondary-host-zone \
        project=project-id \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"

   2. Restrinja cada dispositivo de isolamento à outra VM do host:

      # pcs constraint location primary-fence-name avoids primary-host-name
      # pcs constraint location secondary-fence-name avoids secondary-host-name

2. No host principal como raiz, teste o dispositivo de isolamento secundário:

   1. Encerre a VM do host secundário:

      # fence_gce -o off -n secondary-host-name --zone=secondary-host-zone

      Se o comando for bem-sucedido, você perderá a conectividade com a VM do host secundário e ela aparecerá interrompida na página Instâncias de VM no console do Google Cloud. Talvez seja necessário atualizar a página.

   2. Reinicie a VM do host secundário:

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone

3. No host secundário como raiz, teste o dispositivo de isolamento primário repetindo as etapas anteriores e usando os valores do host principal nos comandos.

4. Em qualquer host como raiz, verifique o status do cluster:

   # pcs status

   Os recursos de isolamento aparecem na seção de recursos do status do cluster, semelhante ao exemplo a seguir:

   [root@hana-ha-vm-2 ~]# pcs status
   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Mon Jun 15 17:19:07 2020
   Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1
   
   2 nodes configured
   2 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   
   Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled

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

Ativar os ganchos de provedor HA/DR do SAP HANA

O Red Hat recomenda que você ative os ganchos de provedor HA/DR do SAP HANA, que permitem que o SAP HANA envie notificações para determinados eventos e melhoram a detecção de falhas. Os ganchos de provedor HA/DR do SAP HANA exigem o SAP HANA 2.0 SPS 03 ou uma versão posterior.

Observação:se você quiser implementar os hooks de provedor HA/DR em um sistema SAP HANA preexistente com tempo de inatividade quase zero, consulte o Guia de operações do SAP HANA.

Tanto no site principal quanto no secundário, siga estas etapas:

1. Como SID_LCadm, interrompa o SAP HANA:

   > HDB stop

1. Como raiz ou SID_LCadm, abra o arquivo global.ini para edição:

   > vi /hana/shared/SID/global/hdb/custom/config/global.ini

2. Adicione as seguintes definições ao arquivo global.ini:

   Observação:para implementar o hook chksrv.py, você precisa do RHEL 8 para SAP SP6 ou mais recente.

   [ha_dr_provider_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR/srHook
   execution_order = 1
   
   [ha_dr_provider_chksrv]
   provider = ChkSrv
   path = /usr/share/SAPHanaSR/srHook
   execution_order = 2
   action_on_lost = stop
   
   [trace]
   ha_dr_saphanasr = info
   ha_dr_chksrv = info

3. Como raiz, crie um arquivo de configuração personalizado no diretório /etc/sudoers.d executando o comando a seguir. Esse novo arquivo de configuração permite que o usuário SID_LCadm acesse os atributos do nó do cluster quando o método hook srConnectionChanged() for chamado.

   > sudo visudo -f /etc/sudoers.d/20-saphana

4. No arquivo /etc/sudoers.d/20-saphana, adicione o seguinte texto:

   Substitua:

   • SITE_A: o nome do site do servidor SAP HANA principal
   • SITE_B: o nome do site do servidor SAP HANA secundário
   • SID_LC: o SID precisa ser especificado em letras minúsculas.
   Para conferir os nomes dos sites, execute o comando crm_mon -A1 | grep site como usuário raiz no servidor principal ou secundário do SAP HANA.

   Cmnd_Alias SITEA_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEA_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEB_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITEB_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL
   Defaults!SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL !requiretty

5. No arquivo /etc/sudoers, verifique se o texto a seguir está incluído.

   #includedir /etc/sudoers.d

   Observe que # nesse texto faz parte da sintaxe e não significa que a linha seja um comentário.

Observação: embora o procedimento nesta seção seja recomendado pelo Red Hat, você pode usar uma abordagem alternativa. Em vez de criar um arquivo de configuração drop-in, é possível adicionar o acesso necessário diretamente ao arquivo /etc/sudoers.

6. Como SID_LCadm, inicie o SAP HANA:

   > HDB start

7. No host principal como SID_LCadm, teste o status informado pelo script do gancho:

   > cdtrace
   > awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

Definir os padrões do cluster

Configure os limites de migração e a permanência para determinar o número de failovers a serem tentados antes da falha e configure o sistema para tentar reiniciar no host atual primeiro. Isso só precisa ser definido em um nó para aplicar ao cluster.

1. Como raiz em um dos hosts, inicie o cluster:

   # pcs cluster start --all #start the cluster

2. Defina os padrões do recurso:

   # pcs resource defaults resource-stickiness=1000
   # pcs resource defaults migration-threshold=5000

   A propriedade resource-stickiness controla a probabilidade de um serviço permanecer em execução onde ele está. Valores mais altos tornam o serviço mais fixo. Um valor de 1000 significa que o serviço é muito fixo.

   A propriedade migration-threshold especifica o número de falhas que precisam ocorrer antes da falha de um serviço para outro host. Um valor de 5.000 é alto o suficiente para evitar o failover em situações de erro de curta duração.

   Para verificar os padrões do recurso, digite pcs resource defaults.

3. Defina os padrões de tempo limite da operação de recursos:

   # pcs resource op defaults timeout=600s

   Para verificar os padrões do recurso, digite pcs resource op defaults.

4. Defina abaixo as propriedades do cluster:

   # pcs property set stonith-enabled="true"
   # pcs property set stonith-timeout="300s"
   

   É possível verificar as configurações da propriedade com pcs property list.

Criar o recurso SAPHanaTopology

O recurso SAPHanaTopology recebe o status e a configuração da replicação do sistema HANA nos nós. Ele também verifica o agente de host do SAP.

1. Como raiz em qualquer um dos hosts, crie o recurso SAPHanaTopology:

   # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
      InstanceNumber=inst_num \
      op start timeout=600 \
      op stop timeout=300 \
      op monitor interval=10 timeout=600 \
      clone clone-max=2 clone-node-max=1 interleave=true

2. Depois que o recurso for criado, verifique a configuração. Anexe -clone ao nome do recurso para incluir as informações do conjunto de clones na resposta:

   RHEL 8 e versões mais recentes

   # pcs resource config topology_resource_name-clone

   RHEL 7

   # pcs resource show topology_resource_name-clone

   A resposta será semelhante a esta:

   Clone: SAPHanaTopology_HA1_22-clone
   Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
   Resource: SAPHanaTopology_HA1_22 (class=ocf provider=heartbeat type=SAPHanaTopology)
    Attributes: InstanceNumber=22 SID=HA1
    Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_22-methods-interval-0s)
                monitor interval=10 timeout=600 (SAPHanaTopology_HA1_22-monitor-interval-10)
                reload interval=0s timeout=5 (SAPHanaTopology_HA1_22-reload-interval-0s)
                start interval=0s timeout=600 (SAPHanaTopology_HA1_22-start-interval-0s)
                stop interval=0s timeout=300 (SAPHanaTopology_HA1_22-stop-interval-0s)

Também é possível verificar os atributos do cluster usando o comando crm_mon -A1.

Criar o recurso SAPHana

O agente de recursos SAPHana gerencia os bancos de dados configurados para replicação do sistema SAP HANA.

Os seguintes parâmetros na definição do recurso SAPHana são opcionais:

• AUTOMATED_REGISTER, que, quando definido como true, registra automaticamente o antigo primário como secundário quando o DUPLICATE_PRIMARY_TIMEOUT expira após um preenchimento total. O padrão é false.

  Para um cluster multinível de HA do SAP HANA, se você estiver usando uma versão anterior ao SAP HANA 2.0 SP03, defina AUTOMATED_REGISTER como false. Isso impede que uma instância recuperada tente fazer o registro automático para replicação em um sistema HANA que já tem um destino de replicação configurado. Para o SAP HANA 2.0 SP03 ou posterior, é possível definir AUTOMATED_REGISTER como true para configurações do SAP HANA que usam replicação do sistema de várias camadas.

• DUPLICATE_PRIMARY_TIMEOUT, que define a diferença de horário em segundos entre dois carimbos de data/hora primários, caso ocorra uma situação dupla. O padrão é 7200.

• PREFER_SITE_TAKEOVER, que determina se as reinicializações locais são tentadas antes do início do failover. O padrão é false.

Para mais informações sobre esses parâmetros, consulte Como instalar e configurar um cluster de alta disponibilidade do Red Hat Enterprise Linux 7.6 (ou posterior) no Google Cloud. É necessário ter uma assinatura do Red Hat.

1. Como raiz em um dos hosts, crie o recurso SAP HANA:

   RHEL 8 e versões mais recentes

   # pcs resource create sap_hana_resource_name SAPHana SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start timeout=3600 \
   op stop timeout=3600 \
   op monitor interval=61 role="Slave" timeout=700 \
   op monitor interval=59 role="Master" timeout=700 \
   op promote timeout=3600 \
   op demote timeout=3600 \
   promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

   RHEL 7

   # pcs resource create sap_hana_resource_name SAPHana SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start timeout=3600 \
   op stop timeout=3600 \
   op monitor interval=61 role="Slave" timeout=700 \
   op monitor interval=59 role="Master" timeout=700 \
   op promote timeout=3600 \
   op demote timeout=3600 \
   master meta notify=true clone-max=2 clone-node-max=1 interleave=true

2. Verifique os atributos de recursos resultantes:

   RHEL 8 e versões mais recentes

   # pcs resource config sap_hana_resource_name

   RHEL 7

   # pcs resource show sap_hana_resource_name

   O resultado será semelhante a:

    Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
     Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
     Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
     Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
                 methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                 monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                 monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                 promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                 reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                 start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                 stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)

3. Depois que o recurso for iniciado, verifique os atributos do nó para ver o estado atual dos bancos de dados do SAP HANA nos nós:

   # crm_mon -A1

   A resposta será assim:

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Tue Jun 16 20:07:51 2020
   Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1
   
   2 nodes configured
   6 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Active resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
   
   Node Attributes:
   * Node hana-ha-vm-1:
      + hana_ha1_clone_state              : PROMOTED
      + hana_ha1_op_mode                  : logreplay
      + hana_ha1_remoteHost               : hana-ha-vm-2
      + hana_ha1_roles                    : 4:P:master1:master:worker:master
      + hana_ha1_site                     : hana-ha-vm-1
      + hana_ha1_srmode                   : syncmem
      + hana_ha1_sync_state               : PRIM
      + hana_ha1_version                  : 1.00.122.27.1568902538
      + hana_ha1_vhost                    : hana-ha-vm-1
      + lpa_ha1_lpt                       : 1592338046
      + master-SAPHana_HA1_22             : 150
   * Node hana-ha-vm-2:
      + hana_ha1_clone_state              : DEMOTED
      + hana_ha1_op_mode                  : logreplay
      + hana_ha1_remoteHost               : hana-ha-vm-1
      + hana_ha1_roles                    : 4:S:master1:master:worker:master
      + hana_ha1_site                     : hana-ha-vm-2
      + hana_ha1_srmode                   : syncmem
      + hana_ha1_sync_state               : SOK
      + hana_ha1_version                  : 1.00.122.27.1568902538
      + hana_ha1_vhost                    : hana-ha-vm-2
      + lpa_ha1_lpt                       : 30
      + master-SAPHana_HA1_22             : 100

Criar um recurso de endereço IP virtual

Você precisa criar um recurso de cluster para o VIP. O recurso VIP é localizado no sistema operacional principal e não é roteável por outros hosts. O balanceador de carga encaminha o tráfego enviado ao VIP para o host de back-end com base na verificação de integridade.

Como raiz em um dos hosts:

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

O valor vip-address é o mesmo endereço IP reservado anteriormente e especificado na regra de encaminhamento para o front-end do balanceador de carga. Alterar a interface de rede conforme apropriado para sua configuração.

Criar as restrições

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

1. Defina a restrição do pedido inicial:

   RHEL 8 e versões mais recentes

   # pcs constraint order topology_resource_name-clone \
   then sap_hana_resource_name-clone symmetrical=false

   RHEL 7

   # pcs constraint order topology_resource_name-clone \
   then sap_hana_resource_name-master symmetrical=false

   A especificação de symmetrical=false significa que a restrição se aplica apenas à inicialização e não à desativação.

   No entanto, como você definiu interleave=true para esses recursos em uma etapa anterior, os processos podem ser iniciados em paralelo. Em outras palavras, é possível iniciar o SAPHana em qualquer nó assim que o SAPHanaTopology estiver em execução.

2. Verifique as restrições:

   # pcs constraint

   A resposta será assim:

   Location Constraints:
    Resource: STONITH-hana-ha-vm-1
      Disabled on:
        Node: hana-ha-vm-1 (score:-INFINITY)
    Resource: STONITH-hana-ha-vm-2
      Disabled on:
        Node: hana-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
    start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
   Colocation Constraints:
   Ticket Constraints:

Instalar listeners e criar um recurso de verificação de integridade

Para configurar um recurso de verificação de integridade, é necessário instalar os listeners primeiro.

Instalar um listener

O balanceador de carga usa um listener na porta de verificação de integridade de cada host para determinar onde a instância principal do cluster do SAP HANA está sendo executada. 1. Como raiz na instância mestre nos sistemas primário e secundário, instale um listener TCP. Estas instruções instalam e usam o HAProxy como listener.

# yum install haproxy

1. Abra o arquivo de configuração haproxy.cfg para edição:

   # vi /etc/haproxy/haproxy.cfg

   1. Na seção padrões de haproxy.cfg, altere mode para tcp.

   2. Após a seção padrões, crie uma nova seção adicionando:

      #---------------------------------------------------------------------
      # Health check listener port for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
        bind *:healthcheck-port-num

      A porta de vinculação é a mesma que você usou quando criou a verificação de integridade.

      Quando terminar, suas atualizações serão semelhantes ao exemplo a seguir:

      #---------------------------------------------------------------------
      # common defaults that all the 'listen' and 'backend' sections will
      # use if not designated in their block
      #---------------------------------------------------------------------
      defaults
        mode                    tcp
        log                     global
        option                  tcplog
        option                  dontlognull
        option http-server-close
        # option forwardfor       except 127.0.0.0/8
        option                  redispatch
        retries                 3
        timeout http-request    10s
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout http-keep-alive 10s
        timeout check           10s
        maxconn                 3000
      
      #---------------------------------------------------------------------
      # Set up health check listener for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
       bind *:60000

2. Em cada host como raiz, inicie o serviço para confirmar se ele está configurado corretamente:

   # systemctl start haproxy.service

3. Na página do balanceador de carga no Console do Google Cloud, clique na entrada do balanceador de carga:

   Página de balanceamento de carga

   Na seção Back-end da página Detalhes do balanceador de carga, se o serviço HAProxy estiver ativo nos dois hosts, você verá 1/1 na coluna Íntegra de cada entrada do grupo de instâncias.

   

4. Em cada host, interrompa o serviço HAProxy:

   # systemctl stop haproxy.service

   Depois que você interrompe o serviço HAProxy em cada host, o 0/1 é exibido na coluna íntegra de cada grupo de instâncias.

   

   Mais tarde, quando a verificação de integridade for configurada, o cluster reiniciará o listener no nó mestre.

Criar o recurso de verificação de integridade

1. Em qualquer host como raiz, crie um recurso de verificação de integridade para o serviço HAProxy:

   # pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s

2. Confirme se o serviço de verificação de integridade está ativo no mesmo host que a instância mestre do SAP HANA e o recurso VIP:

   # pcs status

   Se o recurso de verificação de integridade não estiver no host principal, mova-o com o seguinte comando:

   # pcs resource move healthcheck_resource_name target_host_name
   # pcs resource clear healthcheck_resource_name

   O comando pcs resource clear deixa o recurso no novo local, mas remove a restrição de local indesejada que o comando pcs resource move criou.

   No status, a seção de recursos deve ser semelhante ao exemplo a seguir:

   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
   rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
   rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2

3. Agrupe os recursos VIP e de verificação de integridade:

   # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

   No status do cluster, a seção de recursos deve ser semelhante ao exemplo a seguir:

   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
   Resource Group: g-primary
       rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
       rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1

4. Crie uma restrição que localize o novo grupo no mesmo nó que a instância mestre do SAP HANA.

   RHEL 8 e versões mais recentes

   # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-clone 4000

   RHEL 7

   # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

   Suas restrições finais devem ser semelhantes ao exemplo a seguir:

   # pcs constraint
   Location Constraints:
    Resource: STONITH-hana-ha-vm-1
      Disabled on:
        Node: hana-ha-vm-1 (score:-INFINITY)
    Resource: STONITH-hana-ha-vm-2
      Disabled on:
        Node: hana-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
    start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
   Colocation Constraints:
    g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

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

Faça backup do sistema antes do teste.

É possível simular uma falha de várias maneiras, incluindo:

• HDB stop
• HDB kill
• reboot (no nó ativo)
• ip link set eth0 down para instâncias com uma única interface de rede
• iptables ... DROP para instâncias com várias interfaces de rede
• echo c > /proc/sysrq-trigger

Nestas instruções, ip link set eth0 down ou iptables são usados para simular uma interrupção de rede entre os dois hosts no cluster. Use o comando ip link em uma instância com uma única interface de rede e iptables em instâncias com uma ou mais interfaces de rede. O teste valida o failover e o isolamento. Quando as instâncias têm várias interfaces de rede definidas, use o comando iptables no host secundário para descartar o tráfego de entrada e de saída com base no IP usado pelo host principal para o cluster de comunicação, simulando uma perda de conexão de rede com a instância principal.

1. No host ativo, como raiz, coloque a interface de rede off-line:

   # ip link set eth0 down

   Ou, se várias interfaces de rede estiverem ativas, usando iptables no host secundário:

   # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

2. Reconecte-se ao host usando o SSH e mude para o usuário raiz

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

   Cluster name: hana-ha-cluster
   Stack: corosync
   Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
   Last updated: Wed Jun 17 01:04:36 2020
   Last change: Wed Jun 17 01:03:58 2020 by root via crm_attribute on hana-ha-vm-2
   
   2 nodes configured
   8 resources configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
   
   STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
   
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2  ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1  ]
   Resource Group: g-primary
       rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
       rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   
   Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

Configurar o HANA ativo/ativo (ativado para leitura)

A partir do SAP HANA 2.0 SPS1, é possível configurar o HANA Active/Active (Read Enabled) em um cluster do Pacemaker. Isso é opcional.

Para configurar o HANA ativo/ativo (ativado para leitura) em um cluster do Pacemaker, conclua as etapas a seguir.

Configurar o suporte a failover do Cloud Load Balancing para o host secundário

O serviço de balanceador de carga de rede de passagem interno com suporte a failover direciona o tráfego para o host secundário em um cluster do SAP HANA com base em um serviço de verificação de integridade.

Para configurar o suporte a failover para o host secundário, siga estas etapas:

1. Abra o Cloud Shell:

   Acesse o Cloud Shell

2. Reserve um endereço IP para o IP virtual executando o comando a seguir.

   O endereço IP virtual (VIP) segue o sistema secundário do SAP HANA. Esse é o endereço IP que os aplicativos usam para acessar o sistema SAP HANA secundário. O balanceador de carga roteia o tráfego enviado ao VIP para a instância de VM que hospeda o sistema secundário atualmente.

   Se você omitir a sinalização --addresses no comando a seguir, um endereço IP na sub-rede especificada será escolhido para você. Para mais informações sobre como reservar um IP estático, consulte Como reservar um endereço IP interno estático.

   $ gcloud compute addresses create secondary-vip-name \
     --region cluster-region --subnet cluster-subnet \
     --addresses secondary-vip-address

3. Crie uma verificação de integridade do Compute Engine executando o comando a seguir.

   Para a porta usada pela verificação de integridade, escolha uma porta que esteja no intervalo privado 49152-65535 para evitar conflitos com outros serviços. A porta precisa ser diferente da configurada para a verificação de integridade usada para o acesso ao sistema principal do HANA. Os valores de intervalo de verificação e tempo limite são um pouco mais longos do que os padrões para 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.

   $ gcloud compute health-checks create tcp secondary-health-check-name \
     --port=secondary-healthcheck-port-num \
     --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
     --healthy-threshold=2

4. Configure o balanceador de carga e o grupo de failover executando os comandos a seguir.

   Aqui você cria um serviço de back-end extra e usa os mesmos grupos de instâncias criados anteriormente para o serviço de back-end por trás do balanceador de carga TCP/UDP interno no sistema principal do SAP HANA.

   1. Crie o serviço de back-end do balanceador de carga:

      $ gcloud compute backend-services create secondary-backend-service-name \
        --load-balancing-scheme internal \
        --health-checks secondary-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:

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-zone \
        --region cluster-region

   3. Adicione o grupo de instâncias de failover secundário ao serviço de back-end:

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-zone \
        --failover \
        --region cluster-region

   4. Crie uma regra de encaminhamento.

      No caso do endereço IP, especifique aquele que você reservou para o VIP. Se você precisar acessar o sistema secundário do HANA de fora da região especificada no comando a seguir, inclua a sinalização --allow-global-access na definição da regra de encaminhamento.

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

      Para mais informações sobre o acesso entre regiões ao sistema de alta disponibilidade do SAP HANA, consulte Balanceamento de carga TCP/UDP interno.

Ativar HANA ativo/ativo (ativado para leitura)

No host secundário, ative Ativo/Ativo (ativado para leitura) para replicação do sistema SAP HANA seguindo estas etapas:

1. Como raiz, coloque o cluster no modo de manutenção:

   $ pcs property set maintenance-mode=true

2. Como SID_LCadm, interrompa o SAP HANA:

   > HDB stop

3. Como SID_LCadm, registre novamente o sistema secundário do HANA SAP com a replicação do sistema usando o modo de operação logreplay_readaccess:

   > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
    --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name

4. Como SID_LCadm, inicie o SAP HANA:

   > HDB start

5. Como SID_LCadm, confirme se o status de sincronização do HANA é ACTIVE:

   > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

   O resultado será semelhante a este:

   overall_replication_status=ACTIVE

Configurar o Pacemaker

Configure o cluster de alta disponibilidade do Pacemaker para Activo/Activo (ativado para leitura) executando os seguintes comandos como raiz:

1. Configure listeners para as verificações de integridade:

   1. Copie e renomeie o arquivo de configuração haproxy.service padrão para torná-lo um modelo de várias instâncias haproxy:

      # cp /usr/lib/systemd/system/haproxy.service \
           /etc/systemd/system/haproxy@.service

   2. Editar as seções [Unidade] e [Serviço] do arquivo haproxy@.service para incluir o parâmetro de instância %i, como mostrado no exemplo a seguir:

      RHEL 7

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target
      
      
      [Service]
      EnvironmentFile=/etc/sysconfig/haproxy
      ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-%i.cfg -p /run/haproxy-%i.pid $OPTIONS
      ...
      

      RHEL 8

      [Unit]
      Description=HAProxy Load Balancer %i
      After=network-online.target
      Wants=network-online.target
      
      
      [Service]
      Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
      ...
      

      Para ver mais informações da Red Hat sobre modelos de unidades de systemd, consulte Como trabalhar com unidades instanciadas.

   3. Crie um arquivo de configuração haproxy.cfg para o sistema principal do SAP HANA. Exemplo:

      # vi /etc/haproxy/haproxy-primary.cfg

   4. No arquivo de configuração haproxy-primary.cfg do sistema primário do SAP HANA, insira a seguinte configuração e substitua healthcheck-port-num pelo número da porta que você especificou ao criar a verificação de integridade do Compute Engine para o sistema HANA primário com antecedência:

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:healthcheck-port-num

   5. Crie um arquivo de configuração haproxy.cfg para o sistema secundário do SAP HANA. Exemplo:

      # vi /etc/haproxy/haproxy-secondary.cfg

   6. No arquivo de configuração haproxy-secondary.cfg do sistema secundário do SAP HANA, insira a seguinte configuração e substitua secondary-healthcheck-port-num pelo número da porta que você especificou ao criar a verificação de integridade do Compute Engine para o sistema HANA secundário com antecedência:

      global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
      defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
      
      # Listener for SAP healthcheck
      listen healthcheck
        bind *:secondary-healthcheck-port-num

   7. Remova a configuração de listener existente de /etc/haproxy/haproxy.cfg:

      #---------------------------------------------------------------------
      # Health check listener port for SAP HANA HA cluster
      #---------------------------------------------------------------------
      listen healthcheck
        bind *:healthcheck-port-num

   8. Atualize os serviços do systemd para carregar as mudanças:

      # systemctl daemon-reload

   9. Confirme se os dois serviços haproxy estão configurados corretamente:

      # systemctl start haproxy@primary
      # systemctl start haproxy@secondary
      
      # systemctl status haproxy@primary
      # systemctl status haproxy@secondary

      O status retornado precisa mostrar [e-mail] e [e-mail] como active (running). Veja a seguir um exemplo de saída para [e-mail]:

      ● [e-mail] - Cluster Controlled haproxy@primary
        Loaded: loaded (/etc/systemd/system/haproxy@.service; disabled; vendor preset: disabled)
        Drop-In: /run/systemd/system/[e-mail].d
                 └─50-pacemaker.conf
        Active: active (running) since Fri 2022-10-07 23:36:09 UTC; 1h 13min ago
      Main PID: 21064 (haproxy-systemd)
        CGroup: /system.slice/system-haproxy.slice/[e-mail]
                ├─21064 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-primary.cfg -p /run/hapro...
                ├─21066 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
                └─21067 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
      
      Oct 07 23:36:09 hana-ha-vm-1 systemd[1]: Started Cluster Controlled haproxy@primary.

   10. No Cloud Shell, depois de esperar alguns segundos até que a verificação de integridade detecte o listener, verifique a integridade dos grupos de instâncias de back-end nos serviços de back-end primário e secundário:

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

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

       Você vai ver uma saída semelhante à seguinte, mostrando a VM em que está trabalhando no momento, a healthState é HEALTHY:

       ---
       backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
       status:
       healthStatus:
       ‐ healthState: HEALTHY
         instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
         ipAddress: 10.0.0.35
         port: 80
       kind: compute#backendServiceGroupHealth
       

   11. Interrompa os dois serviços para permitir que o Pacemaker gerencie os serviços:

       # systemctl stop haproxy@primary
       # systemctl stop haproxy@secondary

   12. Repita as etapas anteriores em cada host do cluster.

2. Crie um recurso de IP de cluster local para o endereço VIP que você reservou para o sistema secundário:

   # pcs resource create secondary_vip_resource_name \
     IPaddr2 ip="secondary-vip-address" nic=eth0 cidr_netmask=32 \
     op monitor interval=3600s timeout=60s

3. Configure o serviço de verificação de integridade auxiliar executando os seguintes comandos.

   O balanceador de carga usa um listener na porta de verificação de integridade de cada host para determinar onde a instância secundária do cluster do SAP HANA está sendo executada.

   1. Para gerenciar os listeners no cluster, crie um recurso para o listener:

      1. Exclua o recurso do serviço de verificação de integridade para o sistema principal do HANA:

         # pcs resource delete healthcheck_resource_name --force

      2. Adicione um novo recurso ao serviço de verificação de integridade para o sistema principal do HANA:

         # pcs resource create primary_healthcheck_resource_name \
          service:haproxy@primary op monitor interval=10s timeout=20s

      3. Adicione um novo recurso ao serviço de verificação de integridade para o sistema secundário do HANA:

         # pcs resource create secondary_healthcheck_resource_name \
          service:haproxy@secondary op monitor interval=10s timeout=20s

   2. Agrupar os recursos de serviço de verificação de integridade VIP e auxiliar

      1. Adicione o novo recurso de verificação de integridade ao grupo de recursos para recursos VIP primários:

         # pcs resource group add rsc-group-name primary_healthcheck_resource_name \
          --before vip_resource_name

      2. Adicione um novo grupo de recursos para agrupar os recursos de verificação de integridade auxiliar e VIP para o sistema secundário do HANA:

         # pcs resource group add secondary-rsc-group-name \
          secondary_healthcheck_resource_name secondary_vip_resource_name

4. Crie duas restrições de local executando os seguintes comandos:

   Essas restrições garantem que o grupo de recursos VIP secundário seja colocado no nó do cluster correto:

   # pcs constraint location secondary-rsc-group-name rule score=INFINITY \
     hana_sid_sync_state eq SOK and hana_sid_roles eq 4:S:master1:master:worker:master

   # pcs constraint location secondary-rsc-group-name rule score=2000 \
     hana_sid_sync_state eq PRIM and hana_sid_roles eq 4:P:master1:master:worker:master

5. Sair do modo de manutenção do cluster:

   # pcs property set maintenance-mode=false

6. Verifique o status do cluster:

   # pcs status

   Os exemplos a seguir mostram o status de um cluster ativo e configurado corretamente para a replicação do sistema SAP HANA com Ativo/Ativo (leitura ativada). Você verá um grupo extra para os recursos VIP do sistema secundário. No exemplo a seguir, o nome desse grupo de recursos é g-secondary.

   Cluster name: hacluster
     Stack: corosync
     Current DC: hana-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Sat Oct  8 00:37:08 2022
     Last change: Sat Oct  8 00:36:57 2022 by root via crm_attribute on hana-test-2
   
     2 nodes configured
     10 resource instances configured
   
   Online: [ hana-ha-vm-1 hana-ha-vm-2 ]
   
   Full list of resources:
     STONITH-hana-ha-vm-1    (stonith:fence_gce):    Started hana-ha-vm-2
     STONITH-hana-ha-vm-2    (stonith:fence_gce):    Started hana-ha-vm-1
     Resource Group: g-primary
       rsc_healthcheck_HA1-primary        (service:haproxy@primary):      Started hana-ha-vm-1
       rsc_vip_HA1_00     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
     Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
     Master/Slave Set: SAPHana_HA1_00-master [SAPHana_HA1_00]
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
     Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
       Masters: [ hana-ha-vm-1 ]
       Slaves: [ hana-ha-vm-2 ]
     Resource Group: g-secondary
       rsc_healthcheck_HA1-secondary        (service:haproxy@secondary):      Started hana-ha-vm-2
       rsc_vip_HA1_00-secondary     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
   

Avaliar sua carga de trabalho do SAP HANA

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

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

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

Solução de problemas

Para resolver problemas com as configurações de alta disponibilidade do SAP HANA no RHEL, consulte Como solucionar problemas de configurações de alta disponibilidade para SAP.

Como receber suporte para o SAP HANA no RHEL

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

Suporte

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

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

Requisitos de suporte

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

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

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

Como se conectar ao SAP HANA

Se as VMs do host não tiverem um endereço IP externo para SAP HANA, você só conseguirá se conectar às instâncias do SAP HANA por meio da instância Bastion usando SSH ou por meio do servidor Windows via SAP HANA Studio.

• Para se conectar ao SAP HANA por meio da instância Bastion, conecte-se ao Bastion Host e depois às instâncias do SAP HANA usando o cliente SSH de sua escolha.

• Para conectar o banco de dados SAP HANA por meio do SAP HANA Studio, use um cliente de área de trabalho remota para se conectar à instância do Windows Server. Após a conexão, instale o SAP HANA Studio (em inglês) manualmente e acesse o banco de dados SAP HANA.

Tarefas pós-implantação

Depois de concluir a implantação, siga estas etapas:

1. Altere as senhas temporárias do superusuário do sistema SAP HANA e do superusuário do banco de dados. Por exemplo:

   sudo passwd SID_LCadm

   Para informações da SAP sobre alteração de senha, consulte Redefinir a senha do usuário do SISTEMA do banco de dados do sistema.

2. Antes de usar a instância do SAP HANA, configure e faça o backup do novo banco de dados do SAP HANA.

3. Se o sistema SAP HANA for implantado em uma interface de rede VirtIO, recomendamos que você garanta que o valor do parâmetro TCP /proc/sys/net/ipv4/tcp_limit_output_bytes esteja definido como 1048576. Essa modificação ajuda a melhorar a capacidade geral da rede na interface de rede VirtIO sem afetar a latência da rede.

Veja mais informações em:

• Guia de operações do SAP HANA.
• Guia de instalação e atualização do SAP HANA.

A seguir

Consulte os tópicos aseguir para saber mais:

• Como instalar e configurar um cluster de alta disponibilidade do Red Hat Enterprise Linux 7.6 (ou posterior) no Google Compute Cloud
• Replicação automatizada do sistema SAP HANA em escalonamento vertical no cluster do Pacemaker
• Políticas de suporte para clusters de alta disponibilidade do RHEL - requisitos gerais para isolamento/STONITH
• Guia de planejamento de alta disponibilidade do SAP HANA
• Guia de planejamento de recuperação de desastres do SAP HANA
• Para mais informações sobre administração e monitoramento de VMs, consulte o Guia de operações do SAP HANA