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

Neste guia, mostramos como implantar e configurar manualmente um cluster de alta disponibilidade (HA, na sigla em inglês) do Red Hat Enterprise Linux (RHEL) para um sistema de escalonamento horizontal do SAP HANA no Google Cloud que usa um balanceador de carga de rede de passagem interna para gerenciar o endereço IP virtual (VIP).

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.

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á um sistema de alta disponibilidade do SAP HANA de vários nós configurado para redundância total da zona com uma instância adicional que atua como fabricante majoritário, também conhecido como nó desempatador. Isso garante que o quórum do cluster seja mantido em caso de perda de uma zona.

A implantação final é composta pelos seguintes recursos:

• Um localprimário e secundário onde cada instância tem uma contraparte zonal.
• Dois locais configurados para replicação síncrona.
• Uma única instância de computação que atua como fabricante majoritário.
• Um gerenciador de recursos de cluster de alta disponibilidade do Pacemaker com um mecanismo de isolamento.
• Discos permanentes para dados e volumes de registro do SAP HANA anexados a cada instância do SAP HANA.

Neste guia, você usa os modelos do Terraform 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

• Você tem uma solução de NFS, como a Filestore gerenciada, para compartilhar os volumes /hana/shared e /hanabackup do SAP HANA entre os hosts no sistema de escalonamento horizontal SAP HANA. Para implantar servidores NFS do Filestore, veja Como criar instâncias.

  • Os sites principal e secundário precisam ter acesso aos próprios caminhos NFS dedicados para evitar a substituição de dados. Para usar uma única instância do Filestore, configure a implantação para usar subdiretórios distintos como caminho de montagem.

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ê usa o arquivo de configuração do Terraform fornecido pelo Google Cloud, especifique uma tag com network_tags = "TAG".
  • Crie as VMs sem um IP externo. Se você usar o arquivo de configuração do Terraform fornecido pelo Google Cloud, especifique public_ip = false.

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

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

2. Crie uma sub-rede e especifique a região e o intervalo de IP. Para mais informações, consulte Como adicionar sub-redes.

Como configurar um gateway NAT

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

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.

Para criar as regras de firewall para seu projeto, consulte Como criar regras de firewall.

Como implantar as VMs e o SAP HANA

Neste guia, você vai usar um arquivo de configuração do Terraform fornecido pelo Google Cloud para implantar o seguinte:

• Dois sistemas SAP HANA correspondentes, cada um com duas ou mais instâncias de VM.
• Uma única instância do fabricante majoritário, também conhecida como nó desempatador, garante que o quórum de clusters seja mantido em caso de perda de uma zona.

Os sistemas SAP HANA usam a replicação assíncrona do sistema, de modo que um dos sistemas SAP HANA funcione como o sistema principal ativo e o outro como um sistema secundário em espera. Implante os dois sistemas SAP HANA na mesma região, de preferência em diferentes zonas.

Se você precisar de um sistema de escalonamento horizontal com hosts em espera para failover automático do host do SAP HANA, consulte Terraform: sistema de escalonamento horizontal do SAP HANA com guia de implantação de failover automático do host do Google Analytics.

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

As instruções a seguir usam o Cloud Shell, mas geralmente são aplicáveis a um terminal local com o Terraform instalado e configurado com o Provedor do Google.

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 forem insuficientes, 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 "Cotas"

2. Abra o Cloud Shell ou seu terminal local.

   Abrir o Cloud Shell

3. Faça o download do arquivo de configuração manual_sap_hana_scaleout_ha.tf para o diretório de trabalho executando o comando a seguir no Cloud Shell ou no terminal:

   $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana_ha/terraform/manual_sap_hana_scaleout_ha.tf

   Observação: verifique se há apenas um arquivo de configuração do Terraform no seu diretório de trabalho.

4. Abra o arquivo manual_sap_hana_scaleout_ha.tf no editor de código do Cloud Shell ou, se estiver usando seu terminal, abra o arquivo em um 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.

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

   Argumento	Tipo de dado	Descrição
   source	String	Especifica o local e a versão do módulo do Terraform a serem usados durante a implantação. O arquivo de configuração manual_sap_hana_scaleout_ha.tf inclui duas instâncias do argumento source: uma que está ativa e outra incluída como um comentário. O argumento source, que é ativo por padrão, especifica latest como a versão do módulo. A segunda instância do argumento source, que, por padrão, é desativada por um caractere # inicial, especifica um carimbo de data/hora que identifica uma versão do módulo. Se você precisar que todas as implantações usem a mesma versão do módulo, remova o caractere # líder do argumento source que especifica o carimbo de data/hora da versão e o adiciona aos source que especifica latest.
   project_id	String	Especifique o ID do projeto do Google Cloud em que você está implantando esse sistema. Por exemplo, my-project-x.
   machine_type	String	Especifique o tipo de máquina virtual (VM) do Compute Engine em que você precisa executar o sistema SAP. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido com um número de vCPUs o mais próximo possível do necessário, mesmo que maior. Após a conclusão da implantação, modifique o número de vCPUs e a quantidade de memória. Por exemplo, n1-highmem-32.
   network	String	Especifique o nome da rede em que você precisa criar o balanceador de carga que gerencia o VIP. Se você estiver usando uma rede VPC compartilhada, será preciso adicionar o ID do projeto host como um diretório pai do nome da rede. Por exemplo, HOST_PROJECT_ID/NETWORK_NAME.
   subnetwork	String	O nome da sub-rede criada em um passo anterior. Se você estiver implantando em uma VPC compartilhada, especifique esse valor como SHARED_VPC_PROJECT_ID/SUBNETWORK. Por exemplo, myproject/network1.
   linux_image	String	Especifique o nome da imagem do sistema operacional Linux em que você quer implantar o sistema SAP. Por exemplo, rhel-9-2-sap-ha ou sles-15-sp5-sap. Para ver a lista de imagens do sistema operacional disponíveis, consulte a página Imagens no console do Google Cloud.
   linux_image_project	String	Especifique o projeto do Google Cloud que contém a imagem que você especificou para o argumento linux_image. Talvez seja seu próprio projeto ou um projeto de imagem do Google Cloud. Para uma imagem do Compute Engine, especifique rhel-sap-cloud ou suse-sap-cloud. Para encontrar o projeto de imagem do sistema operacional, consulte Detalhes do sistema operacional.
   primary_instance_name	String	Especifique um nome da instância de VM para o sistema SAP HANA principal. O nome pode conter letras minúsculas, números ou hífens.
   primary_zone	String	Especifique uma zona em que o sistema SAP HANA principal está implantado. As zonas principal e secundária precisam estar na mesma região. Por exemplo, us-east1-c
   secondary_instance_name	String	Especifique um nome da instância de VM para o sistema secundário do SAP HANA. O nome pode conter letras minúsculas, números ou hífens.
   secondary_zone	String	Especifique uma zona em que o sistema secundário do SAP HANA está implantado. As zonas principal e secundária precisam estar na mesma região. Por exemplo, us-east1-b
   sap_hana_deployment_bucket	String	Para instalar automaticamente o SAP HANA nas VMs implantadas, especifique o caminho do bucket do Cloud Storage que contém os arquivos de instalação do SAP HANA. Não inclua gs:// no caminho. Inclua apenas o nome do bucket e os nomes das pastas. Por exemplo, my-bucket-name/my-folder. O bucket do Cloud Storage precisa existir no projeto do Google Cloud especificado para o argumento project_id.
   sap_hana_scaleout_nodes	Número inteiro	Especifique o número de hosts workers necessários para seu sistema de escalonamento horizontal. Para implantar um sistema de escalonamento horizontal, você precisa de pelo menos um host de worker. O Terraform cria os hosts de worker além da instância principal do SAP HANA. Por exemplo, se você especificar 3, quatro instâncias do SAP HANA serão implantadas no sistema de escalonamento horizontal.
   sap_hana_sid	String	Para instalar automaticamente o SAP HANA nas VMs implantadas, especifique o ID do sistema SAP HANA. O ID precisa ter três caracteres alfanuméricos e começar com uma letra. Todas as letras precisam estar em maiúsculas. Por exemplo, ED1.
   sap_hana_instance_number	Número inteiro	Opcional. Especifique o número da instância, de 0 a 99, do sistema SAP HANA. O padrão é 0.
   sap_hana_sidadm_password	String	Para instalar automaticamente o SAP HANA nas VMs implantadas, especifique uma senha temporária SIDadm para os scripts de instalação a serem usados durante a implantação. A senha precisa conter pelo menos oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. Importante: depois que a instalação for concluída, mude a senha. Em vez de especificar uma senha como texto simples, recomendamos o uso de um secret. Para mais informações, consulte Gerenciamento de senhas.
   sap_hana_sidadm_password_secret	String	Opcional. Se você estiver usando o Secret Manager para armazenar aSIDadm e depois especifique o Nome do secret que corresponde a essa senha. No Secret Manager, verifique se o valor do Secret, que é a senha, contém pelo menos oito caracteres e inclui pelo menos uma letra maiúscula, uma minúscula e um número. Importante: o Secret precisa existir no projeto do Google Cloud que você especificar para o argumento project_id. Para mais informações, consulte Gerenciamento de senhas.
   sap_hana_system_password	String	Para instalar automaticamente o SAP HANA nas VMs implantadas, especifique uma senha temporária de superusuário do banco de dados para os scripts de instalação usarem durante a implantação. A senha precisa conter pelo menos oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número. Importante: depois que a instalação for concluída, mude a senha. Em vez de especificar uma senha como texto simples, recomendamos o uso de um secret. Para mais informações, consulte Gerenciamento de senhas.
   sap_hana_system_password_secret	String	Opcional. Se você estiver usando o Secret Manager para armazenar a senha de superusuário do banco de dados, especifique o Nome do secret que corresponde a essa senha. No Secret Manager, verifique se o valor do Secret, que é a senha, contém pelo menos oito caracteres e inclui pelo menos uma letra maiúscula, uma minúscula e um número. Importante: o Secret precisa existir no projeto do Google Cloud que você especificar para o argumento project_id. Para mais informações, consulte Gerenciamento de senhas.
   sap_hana_double_volume_size	Booleano	Opcional. Para duplicar o tamanho do volume do HANA, especifique true. Esse argumento é útil quando você quer implantar várias instâncias do SAP HANA ou uma instância de recuperação de desastres do SAP HANA na mesma VM. Por padrão, o tamanho do volume é calculado automaticamente para ser o tamanho mínimo necessário para o tamanho da VM, sem deixar de atender aos requisitos de certificação e suporte da SAP. O valor padrão é false.
   sap_hana_backup_size	Número inteiro	Opcional. Especifique o tamanho do volume /hanabackup em GB. Se você não especificar ou definir esse argumento como 0, o script de instalação vai provisionar a instância do Compute Engine com um volume de backup do HANA duas vezes maior que a memória total.
   sap_hana_sidadm_uid	Número inteiro	Opcional. Especifique um valor para substituir o valor padrão do ID do usuário SID_LCadm. O valor padrão é 900. É possível alterá-lo para um valor diferente para maior consistência no cenário da SAP.
   sap_hana_sapsys_gid	Número inteiro	Opcional. Substitui o ID do grupo padrão para sapsys. O valor padrão é 79.
   sap_vip	String	Especifique o endereço IP que você usará para o VIP. O endereço IP precisa estar dentro do intervalo de endereços IP atribuídos à sua sub-rede. O arquivo de configuração do Terraform reserva esse endereço IP para você.
   primary_instance_group_name	String	Opcional. Define o nome do grupo de instâncias não gerenciadas para o nó principal.a O nome padrão é ig-PRIMARY_INSTANCE_NAME.
   secondary_instance_group_name	String	Opcional. Define o nome do grupo de instâncias não gerenciadas para o nó secundário. O nome padrão é ig-SECONDARY_INSTANCE_NAME.
   loadbalancer_name	String	Opcional. Especifique o nome do balanceador de carga de rede de passagem interno. O nome padrão é lb-SAP_HANA_SID-ilb.
   network_tags	String	Opcional. Especifique uma ou mais tags de rede separadas por vírgula que você quer associar às suas instâncias de VM para fins de firewall ou roteamento. Se você especificar public_ip = false e não inserir uma tag de rede, forneça outro meio de acesso à Internet.
   nic_type	String	Opcional. Especifique 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), você precisa especificar uma imagem do SO compatível com gVNIC como o valor do argumento linux_image. Para conferir a lista de imagens do SO, consulte Detalhes do sistema operacional. Se você não especificar um valor para esse argumento, a interface de rede será selecionada automaticamente com base no tipo de máquina especificado para o argumento machine_type. Este argumento está disponível na versão 202302060649 do módulo sap_hana ou posterior.
   disk_type	String	Opcional. Especifique o tipo padrão de disco permanente ou Volume do hiperdisco que você quer implantar para os dados do SAP e os volumes de registro da implantação. Para informações sobre a implantação do disco padrão feita pelas configurações do Terraform fornecidas pelo Google Cloud, consulte Implantação de disco pelo Terraform (em inglês). Os seguintes valores são válidos para esse argumento: pd-ssd, pd-balanced, hyperdisk-extreme, hyperdisk-balanced e pd-extreme. Nas implantações de escalonamento vertical do SAP HANA, um disco permanente equilibrado e separado também é implantado no diretório /hana/shared. É possível modificar esse tipo de disco padrão e o tamanho do disco padrão associado e as IOPS padrão usando alguns argumentos avançados. Para ver mais informações, navegue até seu diretório de trabalho, execute o comando terraform init e veja o arquivo /.terraform/modules/manual_sap_hana_scaleout_ha/variables.tf. Antes de usar esses argumentos na produção, é preciso testá-los em um ambiente que não seja de produção.
   use_single_shared_data_log_disk	Booleano	Opcional. O valor padrão é false, que direciona o Terraform para implantar um disco permanente ou hiperdisco separado para cada um dos seguintes volumes SAP: /hana/data ,/hana/log e/hana/shared e/usr/sap. Para montar esses volumes SAP no mesmo disco permanente ou Hyperdisk, especifique true.
   include_backup_disk	Booleano	Opcional. Esse argumento é aplicável a implantações de escalonamento vertical do SAP HANA. O valor padrão é true, que direciona o Terraform para implantar um disco separado que hospeda o diretório /hanabackup. O tipo de disco é determinado pelo argumento backup_disk_type. O tamanho desse disco é determinado pelo argumento sap_hana_backup_size. Se você definir o valor de include_backup_disk como false, nenhum disco será implantado no diretório /hanabackup.
   public_ip	Booleano	Opcional. Determina se um endereço IP público é adicionado na sua instância de VM. O valor padrão é true. Cuidado: não especifique false a menos que você tenha um gateway NAT configurado com uma tag de rede definida para a VM ou tenha fornecido à VM outro trajeto para a Internet. Se não houver rota para a Internet, a instalação falhará.
   service_account	String	Opcional. Especifique o endereço de e-mail de uma conta de serviço gerenciada pelo usuário que será usada pelas VMs do host e pelos programas executados nas VMs do host. Por exemplo, [e-mail]. Se você especificar esse argumento sem um valor ou omiti-lo, o script de instalação usará a conta de serviço padrão do Compute Engine. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.
   sap_deployment_debug	Booleano	Opcional. Somente quando o Cloud Customer Care solicitar que você ative a depuração da sua implantação, especifique true, o que faz com que a implantação gere registros de implantação detalhados. O valor padrão é false.
   primary_reservation_name	String	Opcional. Para usar uma reserva de VM do Compute Engine específica para provisionar a instância da VM que hospeda a instância principal do SAP HANA do cluster de alta disponibilidade, especifique o nome da reserva. Por padrão, o script de instalação seleciona qualquer reserva disponível do Compute Engine com base nas condições a seguir. Para que uma reserva seja utilizável, independentemente de você especificar um nome ou o script de instalação a selecionar automaticamente, a reserva precisa ser definida com o seguinte: A opção specificReservationRequired está definida como true ou, no console do Google Cloud, a opção Selecionar uma reserva específica está selecionada. Alguns tipos de máquina do Compute Engine são compatíveis com plataformas de CPU que não são cobertas pela certificação SAP do tipo de máquina. Se a reserva de destino for de qualquer um dos seguintes tipos de máquina, a reserva precisará especificar as plataformas mínimas de CPU, conforme indicado: n1-highmem-32: Intel Broadwell n1-highmem-64: Intel Broadwell n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake As plataformas de CPU mínimas para todos os outros tipos de máquina que são certificadas pela SAP para uso no Google Cloud estão em conformidade com o requisito de CPU mínimo da SAP.
   secondary_reservation_name	String	Opcional. Para usar uma reserva de VM específica do Compute Engine para provisionar a instância da VM que hospeda a instância secundária do SAP HANA do cluster de alta disponibilidade, especifique o nome da reserva. Por padrão, o script de instalação seleciona qualquer reserva disponível do Compute Engine com base nas condições a seguir. Para que uma reserva seja utilizável, independentemente de você especificar um nome ou o script de instalação a selecionar automaticamente, a reserva precisa ser definida com o seguinte: A opção specificReservationRequired está definida como true ou, no console do Google Cloud, a opção Selecionar uma reserva específica está selecionada. Alguns tipos de máquina do Compute Engine são compatíveis com plataformas de CPU que não são cobertas pela certificação SAP do tipo de máquina. Se a reserva de destino for de qualquer um dos seguintes tipos de máquina, a reserva precisará especificar as plataformas mínimas de CPU, conforme indicado: n1-highmem-32: Intel Broadwell n1-highmem-64: Intel Broadwell n1-highmem-96: Intel Skylake m1-megamem-96: Intel Skylake As plataformas de CPU mínimas para todos os outros tipos de máquina que são certificadas pela SAP para uso no Google Cloud estão em conformidade com o requisito de CPU mínimo da SAP.
   primary_static_ip	String	Opcional. Especifique um endereço IP estático válido para a instância de VM primária no cluster de alta disponibilidade. Se não houver uma especificação, um endereço IP será gerado automaticamente para sua instância de VM. Por exemplo, 128.10.10.10. Este argumento está disponível na versão 202306120959 do módulo sap_hana_ha ou posterior.
   secondary_static_ip	String	Opcional. Especifique um endereço IP estático válido para a instância de VM secundária no cluster de alta disponibilidade. Se não houver uma especificação, um endereço IP será gerado automaticamente para sua instância de VM. Por exemplo, 128.11.11.11. Este argumento está disponível na versão 202306120959 do módulo sap_hana_ha ou posterior.
   primary_worker_static_ips	List(String)	Opcional. Especifique uma matriz de endereços IP estáticos válidos para as instâncias de worker na instância principal do sistema de alta disponibilidade de escalonamento horizontal do SAP HANA. Se você não especificar um valor para esse argumento, um endereço IP será gerado automaticamente para cada instância de VM de worker. Por exemplo, [ "1.0.0.1", "2.3.3.4" ]. Os endereços IP estáticos são atribuídos na ordem de criação da instância. Por exemplo, se você optar por implantar três instâncias de worker, mas especificar apenas dois endereços IP para o argumentoprimary_worker_static_ips, esses endereços IP são atribuídos às duas primeiras instâncias de VM implantadas pela configuração do Terraform. Para a terceira instância da VM de worker, o endereço IP é gerado automaticamente. Este argumento está disponível na versão 202307270727 do módulo sap_hana_ha ou posterior.
   secondary_worker_static_ips	List(String)	Opcional. Especifique uma matriz de endereços IP estáticos válidos para as instâncias de worker na instância secundária do sistema de alta disponibilidade de escalonamento horizontal do SAP HANA. Se você não especificar um valor para esse argumento, um endereço IP será gerado automaticamente para cada instância de VM de worker. Por exemplo, [ "1.0.0.2", "2.3.3.5" ]. Os endereços IP estáticos são atribuídos na ordem de criação da instância. Por exemplo, se você optar por implantar três instâncias de worker, mas especificar apenas dois endereços IP para o argumentosecondary_worker_static_ips, esses endereços IP são atribuídos às duas primeiras instâncias de VM implantadas pela configuração do Terraform. Para a terceira instância da VM de worker, o endereço IP é gerado automaticamente. Este argumento está disponível na versão 202307270727 do módulo sap_hana_ha ou posterior.

   Os exemplos a seguir mostram arquivos de configuração concluídos que definem um cluster de alta disponibilidade para um sistema de escalonamento horizontal do SAP HANA. O cluster usa um balanceador de carga de rede de passagem interno para gerenciar o VIP.

   O Terraform implanta os recursos do Google Cloud definidos no arquivo de configuração e, em seguida, os scripts assumem a configuração do sistema operacional e instalam o SAP HANA.

   Observação: os scripts de implantação instalarão o SAP HANA somente se os argumentos apropriados estiverem especificados no arquivo de configuração do Terraform. Para instalar automaticamente o SAP HANA nas VMs implantadas, especifique os seguintes argumentos:

   • sap_hana_deployment_bucket
   • sap_hana_sid
   • sap_hana_sidadm_password ou sap_hana_sidadm_password_secret
   • sap_hana_system_password ou sap_hana_system_password_secret

6. No mesmo arquivo manual_sap_hana_scaleout_ha.tf, atualize os valores do argumento para majority_maker. Os argumentos são descritos na tabela a seguir.

   Argumento	Tipo de dado	Descrição
   project	String	Especifique o ID do projeto do Google Cloud em que você está implantando esse sistema.
   majority_maker_instance_name	String	Especifique um nome para a instância de VM do Compute Engine que atua como maior fabricante. Este argumento está disponível na versão 202307270727 do módulo sap_hana_ha ou posterior.
   majority_maker_instance_type	String	Especifique o tipo de máquina virtual (VM, na sigla em inglês) do Compute Engine que você quer usar para a instância de maioria. Por exemplo, n1-highmem-32. 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.. Este argumento está disponível na versão 202307270727 do módulo sap_hana_ha ou posterior.
   majority_maker_zone	String	Especifique uma zona em que a instância de VM da maioria dos fabricantes está implantada. Essa zona precisa estar na mesma região que as zonas principal e secundária. Por exemplo, us-east1-d. O Google Cloud recomenda que a instância de VM da maioria dos fabricantes seja implantada em uma zona diferente dos sistemas principal e secundário do SAP HANA. Este argumento está disponível na versão 202307270727 do módulo sap_hana_ha ou posterior.
   majority_maker_linux_image	String	Usando os mesmos valores da etapa anterior, especifique o caminho completo da imagem como "linux_image_project/linux_image". Por exemplo, "rhel-sap-cloud/rhel-9-0-sap-v20230708".
   subnetwork	String	O nome da sub-rede criada em um passo anterior. Se você estiver implantando em uma VPC compartilhada, especifique esse valor como SHARED_VPC_PROJECT_ID/SUBNETWORK. Por exemplo, myproject/network1.
   service_account	String	Opcional. Especifique o endereço de e-mail de uma conta de serviço gerenciada pelo usuário que será usada pelas VMs do host e pelos programas executados nas VMs do host. Por exemplo, [e-mail]. Se você especificar esse argumento sem um valor ou omiti-lo, o script de instalação usará a conta de serviço padrão do Compute Engine. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.
   metadata_startup_script	String	Não edite esse argumento. Por padrão, o criador majoritário vai fazer o download do script de inicialização mais recente para preparar a instância para o clustering do Pacemaker.

   Para esclarecer, os comentários na configuração de exemplo a seguir são omitidos.

  module "sap_hana_primary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-a"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-1"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.1:/hana_scaleout/hana_a/shared"
    sap_hana_backup_nfs             = "10.10.10.1:/hana_scaleout/hana_a/backup"

  }
  module "sap_hana_secondary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-b"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-2"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.2:/hana_scaleout/hana_b/shared"
    sap_hana_backup_nfs             = "10.10.10.2:/hana_scaleout/hana_b/backup"
  }

  resource "google_compute_instance" "majority_maker" {

    project =  "example-project-123456"

    # majority_maker_instance_name
    name         = "majority-maker"

    # majority_maker_instance_type
    machine_type = "n1-standard-8"

    # majority_maker_zone
    zone         = "us-west1-c"

    boot_disk {
      initialize_params {
        # majority_maker_linux_image
        image = "rhel-sap-cloud/rhel-9-0-sap-v20230711"
      }
    }

    network_interface {
      # network or subnetwork
      network = "default"
    }

      service_account {
      # service_account (Optional)
      # email  = [e-mail].
      scopes = ["cloud-platform"]
    }

    # Do not edit
    metadata_startup_script = "curl -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh | bash -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh"

  }

1. Para inicializar seu diretório de trabalho atual e fazer o download do plug-in do provedor do Terraform e dos arquivos de módulo para o Google Cloud:

   terraform init

   O comando terraform init prepara seu diretório de trabalho para outros comandos do Terraform.

   Para forçar uma atualização do plug-in do provedor e dos arquivos de configuração no diretório de trabalho, especifique a sinalização --upgrade. Se a --upgrade sinalização é omitida e você não faz alterações no seu diretório de trabalho, o Terraform usa as cópias em cache local, mesmo selatest é especificado nasource URL

   terraform init --upgrade 

2. Como opção, crie o plano de execução do Terraform:

   terraform plan

   O comando terraform plan mostra as alterações exigidas pela configuração atual. Se você pular essa etapa, o comando terraform apply criará automaticamente um novo plano e solicitará que você o aprove.

3. Aplique o plano de execução:

   terraform apply

   Quando for solicitada a aprovação das ações, digite yes.

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

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

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

Verificar os registros

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

   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. Abra o Cloud Shell.

        Acessar o Cloud Shell

     3. Acesse seu diretório de trabalho e exclua a implantação para limpar as VMs e os discos permanentes da instalação com falha:

        terraform destroy

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

     4. Execute a implantação novamente.

Verificar a configuração da VM e a instalação do SAP HANA

Observação: os scripts de implantação instalarão o SAP HANA somente se os argumentos apropriados estiverem especificados no arquivo de configuração do Terraform. Se eles não tiverem sido especificados, pule esta etapa.

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. Verifique se você vê uma saída que inclui os diretórios /hana, como /hana/data.

   [root@example-ha-vm1 ~]# df -h
     Filesystem                        Size  Used Avail Use% Mounted on
     devtmpfs                          126G     0  126G   0% /dev
     tmpfs                             126G   54M  126G   1% /dev/shm
     tmpfs                             126G   25M  126G   1% /run
     tmpfs                             126G     0  126G   0% /sys/fs/cgroup
     /dev/sda2                          30G  5.4G   25G  18% /
     /dev/sda1                         200M  6.9M  193M   4% /boot/efi
     /dev/mapper/vg_hana-shared        251G   52G  200G  21% /hana/shared
     /dev/mapper/vg_hana-sap            32G  477M   32G   2% /usr/sap
     /dev/mapper/vg_hana-data          426G  9.8G  417G   3% /hana/data
     /dev/mapper/vg_hana-log           125G  7.0G  118G   6% /hana/log
     /dev/mapper/vg_hanabackup-backup  512G  9.3G  503G   2% /hanabackup
     tmpfs                              26G     0   26G   0% /run/user/900
     tmpfs                              26G     0   26G   0% /run/user/899
     tmpfs                              26G     0   26G   0% /run/user/1003

Limpar e tentar implantar novamente

Se alguma das etapas de verificação de implantação nas seções anteriores mostrar que a instalação não foi concluída, desfaça a implantação e tente novamente seguindo as etapas a seguir:

1. Resolva os erros para garantir que a implantação não falhe novamente pelo mesmo motivo. Para mais informações sobre como verificar os registros ou resolver erros relacionados a cotas, consulte Verificar os registros.

2. Abra o Cloud Shell ou, se você instalou a CLI do Google Cloud na sua estação de trabalho local, abra um terminal.

   Abrir o Cloud Shell

3. Acesse o diretório que contém o arquivo de configuração do Terraform que você usou nesta implantação.

4. Exclua todos os recursos que fazem parte da implantação executando o seguinte comando:

   terraform destroy

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

5. Tente fazer a implantação novamente, conforme indicado anteriormente neste guia.

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

Depois de implantar todas as instâncias 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 de VM do host.

2. Execute este comando:

   systemctl status google-cloud-sap-agent

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

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

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

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

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

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

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

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

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.

(Opcional) Criar uma lista de instâncias para automação de scripts

Para automatizar parcialmente algumas das tarefas repetitivas durante a configuração do cluster do sistema SAP HANA e do Pacemaker, use scripts bash. Ao longo deste guia, esses scripts bash são usados para acelerar a configuração do sistema SAP HANA e do cluster do Pacemaker. Esses scripts exigem uma lista de todas as instâncias de VM implantadas e as zonas correspondentes como entrada.

Para ativar essa automação, crie um arquivo chamado nodes.txt e inclua os detalhes de todas as instâncias de VM implantadas no seguinte formato: nome da zona, espaço em branco e o nome da instância da VM. O arquivo de amostra a seguir é usado ao longo deste guia:

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2
 

Configurar o acesso SSH sem senha

Para configurar o cluster do Pacemaker e sincronizar as chaves de armazenamento seguro do SAP HANA (SSFS, na sigla em inglês), o acesso SSH sem senha é necessário entre todos os nós, incluindo a instância do fabricante majoritário. Para acesso SSH sem senha, é necessário adicionar as chaves públicas SSH aos metadados de todas as instâncias implantadas.

O formato dos metadados é USERNAME: PUBLIC-KEY-VALUE.

Para mais informações sobre como adicionar chaves SSH a VMs, consulte Adicionar chaves SSH a VMs que usam chaves SSH baseadas em metadados.

Etapas manuais

1. Para cada instância nos sistemas principal e secundário, bem como para a instância do fabricante majoritário, colete a chave pública para o usuário root.

   gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub

2. Inclua a string root: no início da chave e a escreva como uma nova linha no arquivo public-ssh-keys.txt. Por exemplo:

   root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME

3. Depois de coletar todas as chaves públicas SSH, faça upload das chaves como metadados para todas as instâncias:

   gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME

Etapas automatizadas

Como alternativa, para automatizar o processo de configuração do acesso SSH sem senha para todas as instâncias listadas em nodes.txt, execute as seguintes etapas no console do Google Cloud:

1. Crie uma lista de chaves públicas de todas as instâncias implantadas:

   while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

2. Atribua as chaves públicas SSH como entradas de metadados a todas as instâncias:

   while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt 

Desativar o início automático do SAP HANA

Etapas manuais

Para cada instância do SAP HANA no cluster, verifique se o início automático do SAP HANA está desativado. Para failovers, o Pacemaker gerencia o início e a interrupção das instâncias do SAP HANA em um cluster.

1. Em cada host como SID_LCadm, pare o SAP HANA:

   > HDB stop

2. Em cada host, abra o perfil do SAP HANA usando um editor, como o vi:

   vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

3. Defina a propriedade Autostart como 0:

   Autostart=0

4. Salve o perfil.

5. Em cada host como SID_LCadm, inicie o SAP HANA:

   > HDB start

Etapas automatizadas

Como alternativa, para desativar o início automático do SAP HANA em todas as instâncias listadas em nodes.txt, execute o seguinte script no console do Google Cloud:

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt
 

Observação: ignore o erro "Este arquivo ou diretório não existe" exibido quando o script de automação acessa a instância do fabricante majoritário. Esse erro é exibido porque a instância do fabricante majoritário não tem o SAP HANA instalado.

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

Etapas automatizadas

Para automatizar esse processo, use nodes.txt e os seguintes scripts do console do Google Cloud:

1. Gere um arquivo hosts.txt com uma lista de endereços IP e nomes de host:

   while read -u10 ZONE HOST ; do gcloud compute instances list --filter="name=( 'NAME' $HOST )" --format="csv[separator=' ',no-heading](networkInterfaces[0].networkIP,name)" >> hosts.txt; done 10< nodes.txt

2. Verifique se o arquivo hosts.txt é semelhante ao exemplo a seguir:

   10.138.0.1 rhel-hana-primary
   10.138.0.2 rhel-hana-primaryw1
   10.138.0.3 rhel-hana-secondary
   10.138.0.4 rhel-hana-secondaryw1
   10.138.0.5 rhel-sap-mm
   

3. Em todos os hosts no cluster, incluindo o criador majoritário, atualize o arquivo /etc/hosts para incluir os nomes do host e os endereços IP internos de todas as instâncias no cluster do Pacemaker.

   while read -u10 ZONE HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet $HOST --zone $ZONE -- "sudo tee -a /etc/hosts" < hosts.txt; done 10< nodes.txt

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:

   1. Como SID_LCadm, interrompa o SAP HANA:

      > sapcontrol -nr INST_NUM -function StopSystem

   2. Como raiz, arquive os dados e arquivos de chave SSFS atuais:

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

   3. Copie o arquivo de dados do host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

   4. Copie o arquivo de chave do host principal:

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   5. Atualize a propriedade dos arquivos:

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   6. Atualize as permissões dos arquivos:

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

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

   8. Como SID_LCadm, inicie o SAP HANA:

      > sapcontrol -nr INST_NUM -function StartSystem

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.

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 de HA/DR em um sistema SAP HANA preexistente com tempo de inatividade quase zero, consulte o artigo 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:

   > sapcontrol -nr 00 -function StopSystem

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:

   [ha_dr_provider_SAPHanaSR]
   provider = SAPHanaSR
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [trace]
   ha_dr_saphanasr = 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 SID_LC pelo SID em letras minúsculas.

   Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SOK, SFAIL
   Defaults!SOK, 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:

   > sapcontrol -nr 00 -function StartSystem

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

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

   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 VMs primárias e secundárias de host do mestre, 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 horizontalmente no cluster do Pacemaker

Etapas manuais

Conclua as etapas a seguir em todos os hosts. Na imagem RHEL para SAP fornecida pelo Google, alguns pacotes já estão instalados, mas outras modificações são necessárias.

1. Como raiz, remova o agente de recursos de escalonamento vertical do SAP HANA que veio pré-instalado na imagem:

   # yum -y remove resource-agents-sap-hana

2. Instale o Pacemaker e os agentes de recursos ausentes:

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

3. Update packages to latest version:

   # yum update -y

4. Defina a senha do usuário hacluster, que foi criada como parte dos pacotes:

   # passwd hacluster

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

6. Nas imagens do RHEL para SAP 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

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

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

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

   # systemctl status pcsd.service

   A resposta será semelhante a esta:

   ● 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-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-1 systemd[1]: Started PCS GUI and remote configuration interface.

Etapas automatizadas

Para automatizar esse processo, use nodes.txt e o script a seguir do console do Google Cloud.

No prompt, digite uma senha a ser usada pelo usuário do hacluster que foi criada durante a instalação dos agentes de recursos do Pacemaker.

echo "Set password for hacluster user:"; read -r HA_PASSWD; while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo yum -y remove resource-agents-sap-hana; sudo yum -y install pcs pacemaker fence-agents-gce resource-agents-sap-hana-scaleout resource-agents-gcp; sudo yum update -y; sudo firewall-cmd --permanent --add-service=high-availability; sudo firewall-cmd --reload; sudo systemctl start pcsd.service; sudo systemctl enable pcsd.service; yes $HA_PASSWD | sudo passwd hacluster"; done 10< nodes.txt

Atualizar o arquivo /etc/hosts

Em todos os hosts no cluster, incluindo o criador majoritário, atualize o arquivo /etc/hosts para incluir os nomes do host e os endereços IP internos de todas as instâncias no cluster do Pacemaker.

A saída do arquivo /etc/hosts será semelhante ao exemplo abaixo:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1                localhost localhost.localdomain localhost6 localhost6.localdomain6
10.138.0.1 rhel-hana-primary.us-west1-a.c.project-name.internal rhel-hana-primary # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
10.138.0.1 rhel-hana-primary
10.138.0.2 rhel-hana-primaryw1
10.138.0.3 rhel-hana-secondary
10.138.0.4 rhel-hana-secondaryw1
10.138.0.5 rhel-sap-mm

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 no host mestre principal, autorize o usuário hacluster. É importante incluir todos os hosts do cluster neste comando, que devem fazer parte do cluster.

   RHEL 8 e versões mais recentes

   pcs host auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

   RHEL 7.6 e versões mais recentes

   pcs cluster auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

2. Nas solicitações, insira o nome de usuário hacluster e a senha que você definiu para o usuário hacluster na seção anterior.

3. Definir o cluster no modo de manutenção.

   pcs property set maintenance-mode=true

4. Gere e sincronize a configuração do corosync.

   RHEL 8 e versões mais recentes

   pcs cluster setup scale_out_hsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

   RHEL 7.6 e versões mais recentes

   pcs cluster setup --start --name hanascaleoutsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

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

1. Abra o arquivo /etc/corosync/corosync.conf usando um editor.

2. Remova o parâmetro consensus.

3. Modifique os parâmetros restantes de acordo com as recomendações do Google Cloud.

   A tabela a seguir mostra os parâmetros totem para os quais o Google Cloud recomenda valores, além do impacto da alteração dos valores. Para os valores padrão desses parâmetros, que podem diferir entre as distribuições do Linux, consulte a documentação da distribuição do Linux.

   Parâmetro	Valor recomendado	Impacto da alteração do valor
   secauth	off	Desativa a autenticação e a criptografia de todas as mensagens totem.
   join	60 (ms)	Aumenta o tempo que o nó aguarda as mensagens join no protocolo de associação.
   max_messages	20	Aumenta o número máximo de mensagens que podem ser enviadas pelo nó após o recebimento do token.
   token	20000 (ms)	Aumenta o tempo de espera do nó para um token de protocolo totem antes que o nó declare uma perda de token, adote uma falha do nó e comece a agir. Aumentar o valor do parâmetro token torna o cluster mais tolerante a eventos de infraestrutura momentâneos, como uma migração em tempo real. No entanto, isso também pode fazer com que o cluster demore mais para detectar e se recuperar de uma falha de nó. O valor do parâmetro token também determina o valor padrão do parâmetro consensus, que controla quanto tempo um nó aguarda por um consenso antes de tentar restabelecer a associação da configuração.
   consensus	N/A	Especifica, em milissegundos, quanto tempo esperar pelo consenso antes de iniciar uma nova rodada de configuração de assinatura. Recomendamos que você omita esse parâmetro. Quando o parâmetro consensus não é especificado, o Corosync define o valor como 1,2 vez o valor do parâmetro token. Se você usar o valor recomendado de 20000 do parâmetro token, o parâmetro consesus será definido com o valor 24000. No entanto, se você especificar explicitamente um valor para consensus, verifique se ele é 24000 ou 1.2*token, o que for maior.
   token_retransmits_before_loss_const	10	Aumenta o número de retransmissões de token que o nó tenta antes de concluir que o nó do destinatário falhou e entrar em ação.
   transport	Para SLES: udpu Para o RHEL 8 ou mais recente: knet Para o RHEL 7: udpu	Especifica o mecanismo de transporte usado pelo corosync.

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:

   # pcs cluster enable --all
   # 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

Definir um atraso para a reinicialização do Corosync

Etapas manuais

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

Etapas automatizadas

Como alternativa, para automatizar esse processo para todas as instâncias listadas em nodes.txt, execute o script a seguir no Console do Google Cloud:

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

Configurar o isolamento

As imagens do RHEL fornecidas pelo Google Cloud incluem um agente de isolamento chamado fence_gce, que é específico para o Google Cloud. Use fence_gce para criar dispositivos de isolamento para cada VM de host.

Para garantir que a sequência correta de eventos ocorra após uma ação de isolamento, é necessário configurar o sistema operacional para atrasar a reinicialização do Corosync depois que uma VM é cercada. 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, execute 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 sejam iguais aos nomes das instâncias de VM.

Etapas manuais

1. No host principal, como usuário raiz, crie os dispositivos de isolamento para todos os hosts, incluindo o criador majoritário:

   pcs stonith create STONITH-host-name fence_gce \
   port=host-name \
   zone=host-zone \
   project=project-id \
   pcmk_host_list=host-name pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
   op monitor interval="300s" timeout="120s" \
   op start interval="0" timeout="60s"

2. Defina a restrição de local para os dispositivos de isolamento:

   pcs constraint location STONITH-host-name avoids host-name

3. Repita as duas etapas anteriores para todos os outros hosts nos clusters primário e secundário e para o host fabricante principal inserindo valores adequados para as variáveis host-name e host-zone.

Etapas automatizadas

Para automatizar esse processo, você precisa usar o arquivo nodes.txt e o seguinte script do console do Google Cloud:

while read -u10 ZONE HOST; do gcloud compute ssh $HOST --tunnel-through-iap --quiet --zone $ZONE -- "sudo pcs stonith create STONITH-$HOST fence_gce project=project-id port=$HOST zone=$ZONE pcmk_host_list=$HOST pcmk_reboot_timeout=300 pcmk_monitor_retries=4 op monitor interval=300s timeout=120s op start interval=0 timeout=60s && sudo pcs constraint location STONITH-$HOST avoids $HOST"; done 10< nodes.txt

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 de qualquer host, defina os padrões do recurso:

   RHEL 8 e versões mais recentes

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

   RHEL 7.6 e versões mais recentes

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

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

   RHEL 8 e versões mais recentes

   # pcs resource op defaults update timeout=600s

   RHEL 7.6 e versões mais recentes

   # pcs resource op defaults timeout=600s

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

3. Defina abaixo as propriedades do cluster:

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

   É possível verificar suas configurações de 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:

   RHEL 8 e versões mais recentes

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopology SID=SID \
   InstanceNumber=inst_num \
   op methods interval=0s timeout=5 \
   op monitor interval=10 timeout=600 \
   clone meta clone-node-max=1 interleave=true

   RHEL 7.6 e versões mais recentes

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopologyScaleOut SID=SID \
   InstanceNumber=inst_num \
   op start timeout=600 \
   op stop timeout=300 \
   op monitor interval=10 timeout=600

   # pcs resource clone  rsc_SAPHanaTopology_SID_HDBinstNr meta 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 rsc_SAPHanaTopology_SID_HDBinstNr-clone

   A resposta será semelhante a esta:

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

   RHEL 7.6 e versões mais recentes

   # pcs resource show rsc_SAPHanaTopology_SID_HDBinstNr-clone

   A resposta será semelhante a esta:

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

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

Criar o recurso SAPHanaController

O agente de recursos SAPHanaController 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 qualquer um dos hosts, crie o recurso SAPHanaController:

   RHEL 8 e versões mais recentes

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op demote interval=0s timeout=320 \
   op methods interval=0s timeout=5 \
   op monitor interval=59 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700 \
   op promote interval=0 timeout=3600 \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600e

   # pcs resource promotable rsc_SAPHana_SID_HDBinstNr meta master-max="1" clone-node-max=1 interleave=true

   RHEL 7.6 e versões mais recentes

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600 \
   op promote interval=0 timeout=3600 \
   op monitor interval=60 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700

   # pcs resource master msl_rsc_SAPHana_SID_HDBinstNr rsc_SAPHana_SID_HDBinstNr master-max="1" clone-node-max=1 interleave=true

2. Verifique os atributos de recursos resultantes:

   RHEL 8 e versões mais recentes

   # pcs resource config rsc_SAPHana_SID_HDBinstNr-clone

   O resultado será semelhante a:

   Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (SAPHana_HA1_00-demote-interval-0s)
         methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
         monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
         promote interval=0 timeout=3600 (SAPHana_HA1_00-promote-interval-0)
         reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
         start interval=0 timeout=3600 (SAPHana_HA1_00-start-interval-0)
         stop interval=0 timeout=3600 (SAPHana_HA1_00-stop-interval-0)
         monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)

   RHEL 7.6 e versões mais recentes

   # pcs resource show msl_rsc_SAPHana_SID_HDBinstNr

   O resultado será semelhante a:

   Master: msl_rsc_SAPHana_HA1_HDB00
   Meta Attrs: clone-node-max=1 interleave=true master-max=1
   Resource: rsc_SAPHana_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (rsc_SAPHana_HA1_HDB00-demote-interval-0s)
          methods interval=0s timeout=5 (rsc_SAPHana_HA1_HDB00-methods-interval-0s)
          monitor interval=60 role=Master timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-60)
          monitor interval=61 role=Slave timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-61)
          promote interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-promote-interval-0)
          start interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-start-interval-0)
          stop interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-stop-interval-0)

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

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

   RHEL 8 e versões mais recentes

   # pcs constraint order start rsc_SAPHanaTopology_SID_HDBinstNr-clone then start rsc_SAPHana_SID_HDBinstNr-clone
   

   RHEL 7.6

   # pcs constraint order rsc_SAPHanaTopology_SID_HDBinstNr-clone then rsc_SAPHana_SID_HDBinstNr-master
   

2. Configure the majority maker to avoid taking an an active role in the cluster environment:

   RHEL 8.0 and later

   # pcs constraint location rsc_SAPHana_SID_HDBinstNr-clone avoids majority-maker-name
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

   RHEL 7.6

   # pcs constraint location msl_rsc_SAPHana_SID_HDBinstNr avoids majoritymaker
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

3. Verifique as restrições:

   # pcs constraint

   A resposta será assim:

   Location Constraints:
   Resource: STONITH-hana-ha-1
     Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
     Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
     Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
     Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
     Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
     start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)

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

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

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

   # pcs resource group add rsc-group-name hc_SID_HDBinstNr rsc_ip_SAPHANA_SID_HDBinstNr

3. Crie uma restrição que coloque o 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 rsc_SAPHana_SID_HDBinstNr-clone

   RHEL 7.6 e versões mais recentes

   # pcs constraint colocation add rsc-group-name with master msl_rsc_SAPHana_SID_HDBinstNr

4. Crie uma restrição de pedido para iniciar o grupo somente após a promoção do HANA:

   # pcs constraint order promote rsc_SAPHana_SID_HDBinstNr-clone then start rsc-group-name

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

   # pcs constraint
   
   Location Constraints:
   Resource: STONITH-hana-ha-1
    Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
    Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
    Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
    Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
    Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
    start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)
    promote rsc_SAPHana_HA1_HDB00-clone then start g-primary (kind:Mandatory) (id:order-rsc_SAPHana_HA1_HDB00-clone-g-primary-mandatory)
   Colocation Constraints:
    g-primary with rsc_SAPHana_HA1_HDB00-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

Finalizar configuração

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

   pcs property set maintenance-mode=false

2. 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á semelhante a esta:

   RHEL 8 e versões mais recentes

   Cluster Summary:
   Stack: corosync
   Current DC: hana-ha-2w1 (version 2.0.5-9.el8_4.7-ba59be7122) - partition with quorum
   Last updated: Wed Oct 11 17:59:51 2023
   Last change:  Wed Oct 11 17:59:48 2023 by hacluster via crmd on hana-ha-2
   5 nodes configured
   17 resource instances configured
   
   Node List:
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 dru-somm ]
   
   Active Resources:
   STONITH-hana-ha-1     (stonith:fence_gce):     Started hana-ha-2
   STONITH-hana-ha-1w1   (stonith:fence_gce):     Started hana-ha-1
   STONITH-hana-ha-2     (stonith:fence_gce):     Started hana-ha-2w1
   STONITH-hana-ha-2w1   (stonith:fence_gce):     Started dru-somm
   STONITH-dru-somm    (stonith:fence_gce):     Started hana-ha-1
   Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00]-(promotable):
    Slaves: [ hana-ha-1w1 hana-ha-2w1 ]
   Resource Group: g-primary:
    healthcheck_HA1   (service:haproxy):       Started hana-ha-1
    ip_SAPHANA_HA1_00 (ocf::heartbeat:IPaddr2):        Started hana-ha-1
   
   Node Attributes:
   Node: hana-ha-1:
    hana_ha1_clone_state              : PROMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-1
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1
    master-SAPHana_HA1_00             : 5
   Node: hana-ha-1w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-1
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1w1
    master-SAPHana_HA1_00             : -INFINITY
   Node: hana-ha-2:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-2
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2
    master-SAPHana_HA1_00             : 100
   Node: hana-ha-2w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-2
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2w1
    master-SAPHana_HA1_00             : -12200
   Node: dru-somm:
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_srmode                   : syncmem

   RHEL 7.6 e versões mais recentes

   Stack: corosync
   Current DC: majority-maker (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
   Last updated: Wed Oct 11 17:58:07 2023
   Last change: Wed Oct 11 17:57:57 2023 by hacluster via crmd on hana-ha-2w1
   
   5 nodes configured
   17 resource instances configured
   
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 majority-maker ]
   
   Active resources:
   
   STONITH-hana-ha-1 (stonith:fence_gce):    Started hana-ha-1w1
   STONITH-hana-ha-1w1       (stonith:fence_gce):    Started hana-ha-2
   STONITH-hana-ha-2 (stonith:fence_gce):    Started hana-ha-1
   STONITH-hana-ha-2w1       (stonith:fence_gce):    Started majority-maker
   STONITH-majority-maker (stonith:fence_gce):    Started hana-ha-1w1
   Master/Slave Set: msl_rsc_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00]
    rsc_SAPHana_HA1_HDB00      (ocf::heartbeat:SAPHanaController):     Master hana-ha-1 (Monitoring)
    Slaves: [ hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: rsc_SAPHanaTopology_HA1_HDB00-clone [rsc_SAPHanaTopology_HA1_HDB00]
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Resource Group: g-primary
    hc_HA1_HDB00       (service:haproxy):      Started hana-ha-1
    rsc_ip_SAPHANA_HA1_HDB00   (ocf::heartbeat:IPaddr2):       Started hana-ha-1
   
   Node Attributes:
   Node hana-ha-1:
     hana_ha1_clone_state              : PROMOTED
     hana_ha1_remoteHost               : hana-ha-2
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-1
     master-rsc_SAPHana_HA1_HDB00      : 150
   Node hana-ha-1w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_version                  : 2.00.052.00.1599235305
     hana_ha1_vhost                    : hana-ha-1w1
     master-rsc_SAPHana_HA1_HDB00      : -10000
   Node hana-ha-2:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2
     master-rsc_SAPHana_HA1_HDB00      : 100
   Node hana-ha-2w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2w1
     master-rsc_SAPHana_HA1_HDB00      : -12200
   Node majority-maker:
     hana_ha1_srmode                   : syncmem

3. Se houver recursos de cluster com falha, talvez seja necessário executar o próximo comando:

   pcs resource cleanup

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 hana-ha-vm-1w1 hana-ha-vm-2w1]
   
   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
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:fence_gce):    Started hana-ha-vm-1w1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   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

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