Guia de configuração de cluster de alta disponibilidade para SAP HANA no RHEL

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

Este guia inclui as etapas de:

  • Como configurar o balanceamento de carga TCP/UDP 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 hosts em espera, use o Guia de implantação do SAP HANA.

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

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

O sistema que este guia implanta

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

Visão geral de um cluster de alta disponibilidade do Linux para um sistema SAP HANA de escalonamento vertical e nó único

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

  • Duas VMs de host, cada uma com uma instância do SAP HANA
  • Replicação síncrona do sistema SAP HANA.
  • O gerenciador de recursos do cluster de alta disponibilidade do Pacemaker
  • Um mecanismo de cercas STONITH.
  • Reinicialização automática da instância com falha como nova instância secundária

Neste guia, você usa os modelos do Cloud Deployment Manager fornecidos pelo Google Cloud para implantar as máquinas virtuais (VMs) do Compute Engine e as instâncias do SAP HANA, garantindo que as VMs e os sistemas SAP HANA de base atendam aos requisitos de compatibilidade da SAP e as práticas recomendadas atuais.

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

Pré-requisitos

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

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

Para configurar a rede:

  1. Acesse o Cloud Shell.

    Acesse o Cloud Shell

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

    gcloud compute networks create NETWORK_NAME --subnet-mode custom

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

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

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

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

    Substitua:

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

Como configurar um gateway NAT

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

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

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

Como adicionar regras de firewall

Por padrão, 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 a 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 banco de dados do host, o que pode ser feito criando regras de firewall.

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

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

Para criar uma regra de firewall:

Console

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

    ABRIR "REGRAS DE FIREWALL"

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

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

gcloud

Crie uma regra de firewall usando o seguinte comando:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Como implantar as VMs e o SAP HANA

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

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

No entanto, para implantar dois sistemas em vez de um, você precisa adicionar a definição do segundo sistema ao arquivo de configuração copiando e colando a definição do primeiro sistema. Depois de criar a segunda definição, você precisa alterar os nomes dos recursos e das instâncias na segunda definição. Para se proteger contra uma falha zonal, especifique uma zona diferente na mesma região. Todos os outros valores de propriedade nas duas definições permanecem os mesmos.

Depois que os sistemas SAP HANA forem implantados, você definirá e configurará o cluster de alta disponibilidade.

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

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

    Acessar a página de cotas

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

    Acessar o Cloud Shell

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

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml
  4. Você tem a opção de renomear o arquivo template.yaml para identificar a configuração que ele define.

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

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

  6. No arquivo template.yaml, conclua a definição da primeira VM e do sistema SAP HANA. Especifique os valores da propriedade substituindo os colchetes e o conteúdo pelos valores da instalação. As propriedades estão descritas na tabela a seguir.

    Para criar as instâncias de VM sem instalar o SAP HANA, exclua ou comente todas as linhas que começam com sap_hana_.

    Propriedade Tipo de dados Descrição
    tipo String

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

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

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

    instanceName String O nome da instância de VM que está sendo definida no momento. Especifique nomes diferentes nas definições de VM principal e secundária. Os nomes precisam ser especificados em letras minúsculas, números ou hífens.
    instanceType String O tipo de máquina virtual do Compute Engine em que é necessário executar o SAP HANA. Se você precisar de um tipo de VM personalizado, especifique um tipo de VM predefinido com um número de vCPUs o mais próximo possível do necessário, mesmo que maior. Após a conclusão da implantação, modifique o número de vCPUs e a quantidade de memória..
    zone String A zona do Google Cloud em que a instância da VM que você está definindo será implantada. Especifique zonas diferentes na mesma região para as definições de VM principal e secundária. As zonas precisam estar na mesma região selecionada para a sub-rede.
    subnetwork String Nome da sub-rede criado em uma etapa anterior. Se estiver implantando em uma VPC compartilhada, especifique esse valor como [SHAREDVPC_PROJECT]/[SUBNETWORK]. Por exemplo, myproject/network1.
    linuxImage String Nome da imagem do sistema operacional Linux ou da família de imagens que você está usando com o SAP HANA. Para especificar uma família de imagens, adicione o prefixo family/ ao nome da família. Por exemplo, family/rhel-7-6-sap-ha. Para definir uma imagem específica, determine somente o nome da imagem. Para ver a lista de imagens e famílias disponíveis, consulte a página Imagens no Console do Cloud.
    linuxImageProject String O projeto do Google Cloud que contém a imagem que você usará. Ele pode ser o próprio projeto ou um projeto de imagem do Google Cloud, como rhel-sap-cloud. Para mais informações sobre projetos de imagem do GCP, consulte a página Imagens na documentação do Compute Engine.
    sap_hana_deployment_bucket String Nome do bucket do armazenamento do GCP no projeto que contém os arquivos de instalação do SAP HANA enviados em uma etapa anterior. Todos os arquivos de revisão de upgrade no bucket são aplicados ao SAP HANA durante o processo de implantação.
    sap_hana_sid String O ID do sistema (SID, na sigla em inglês) do SAP HANA. O ID precisa ter três caracteres alfanuméricos e começar com uma letra. Todas as letras precisam ser maiúsculas.
    sap_hana_instance_number Número inteiro Número da instância, 0 a 99, do sistema SAP HANA. O padrão é.
    sap_hana_sidadm_password String A senha do administrador do sistema operacional (SO). As senhas precisam ter no mínimo oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número.
    sap_hana_system_password String A senha do superusuário do banco de dados. As senhas precisam ter pelo menos oito caracteres e incluir pelo menos uma letra maiúscula, uma letra minúscula e um número.
    sap_hana_sidadm_uid Inteiro O valor padrão do ID do usuário sidadm é 900 para evitar que grupos criados por usuários entrem em conflito com o SAP HANA. É possível alterar para um valor diferente, se necessário.
    sap_hana_sapsys_gid Inteiro O ID de grupo padrão do sapsys é 79. Ao especificar um valor acima, é possível substituir esse valor pelos seus requisitos.
    sap_hana_scaleout_nodes Inteiro Especifique 0. Estas instruções são apenas para sistemas SAP HANA de escalonamento vertical.
    networkTag String Uma tag de rede que representa a instância de VM para fins de firewall ou roteamento. Se você especificar "publicIP: No" e não especificar uma tag de rede, certifique-se de fornecer outro meio de acesso à Internet.
    publicIP Booleano Opcional. Determina se um endereço IP público é adicionado à instância da VM. O padrão é Yes.
    serviceAccount String Opcional. Especifica uma conta de serviço a ser usada pelas VMs de host e pelos programas executados nas VMs de host. Especifique a conta de e-mail de membro da conta de serviço. Por exemplo, svc-acct-name@project-id.iam.gserviceaccount.com. Por padrão, a conta de serviço padrão do Compute Engine é usada. Para mais informações, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.
  7. Crie a definição da segunda VM e sistema SAP HANA copiando a definição da primeira e colando a cópia após a primeira definição. Veja o exemplo seguindo estas etapas.

  8. Na definição do segundo sistema, especifique valores diferentes para as seguintes propriedades do que você especificou na primeira definição:

    • name
    • instanceName
    • zone
  9. Crie as instâncias:

    gcloud deployment-manager deployments create deployment-name --config template-name.yaml

    O comando acima invoca o Deployment Manager, que implanta as VMs, faz o download do software do SAP HANA a partir do bucket de armazenamento e instala o SAP HANA de acordo com as especificações do arquivo template.yaml.

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

Exemplo de um arquivo de configuração template.yaml completo

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

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

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

As propriedades networkTag, serviceAccount, sap_hana_sidadm_uid e sap_hana_sapsys_gid são da seção Opções avançadas do modelo de arquivo de configuração. As propriedades sap_hana_sidadm_uid e sap_hana_sapsys_gid são incluídas para mostrar os valores padrão, que são usados porque as propriedades são comentadas.

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

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

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

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

  • Para fins de configuração, sua estação de trabalho local, um Bastion Host ou um servidor do Jump
  • Para acesso entre os nós do cluster, as outras VMs de host no cluster de alta disponibilidade

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

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

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

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

Como verificar a implantação das VMs e do SAP HANA

Antes de começar a configurar o cluster de alta disponibilidade, verifique se as VMs e o SAP HANA foram implantados corretamente verificando os registros, o mapeamento do diretório do SO e a instalação do SAP HANA.

Como verificar os registros

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

    Acesse o Cloud Logging

  2. Na guia Recursos, selecione Global como o recurso de geração de registros.

    • Se "INSTANCE DEPLOYMENT COMPLETE" for exibido, o processamento do Deployment Manager estará concluído, e será possível prosseguir para a próxima etapa.
    • Se você vir um erro de cota:

      1. Na página Cotas do IAM e Admin, aumente as cotas que não atendem aos requisitos do SAP HANA listados no Guia de planejamento do SAP HANA.
      2. Na página Implantações do Deployment Manager, exclua a implantação para limpar as VMs e discos permanentes da instalação com falha.
      3. Execute novamente o Deployment Manager.

      Tela do Logging.

Como verificar a configuração das VMs e do SAP HANA

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

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

  2. Mude para o usuário raiz.

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

    Filesystem                        Size  Used Avail Use% Mounted on
    /dev/sda2                          30G  4.0G   26G  14% /
    devtmpfs                          126G     0  126G   0% /dev
    tmpfs                             126G     0  126G   0% /dev/shm
    tmpfs                             126G   17M  126G   1% /run
    tmpfs                             126G     0  126G   0% /sys/fs/cgroup
    /dev/sda1                         200M  9.7M  191M   5% /boot/efi
    /dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
    /dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
    /dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
    /dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
    /dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
    tmpfs                              26G     0   26G   0% /run/user/900
    tmpfs                              26G     0   26G   0% /run/user/899
    tmpfs                              26G     0   26G   0% /run/user/1000
  4. Altere para o usuário administrador do SAP substituindo sid no comando a seguir pelo ID do sistema especificado no modelo do arquivo de configuração.

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

    > HDB info

Desativar o início automático do SAP HANA

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 sidadm, 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 sidadm, inicie o SAP HANA:

    > HDB start

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

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

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

Se a configuração de conexões SSH diretas não estiver em conformidade com as diretrizes da sua organização, será possível sincronizar as chaves SSFS e transferir arquivos usando outros métodos, como:

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

  1. Na VM do host principal:

    1. Conecte-se por SSH à VM.

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

      $ ssh-keygen
    3. Nas solicitações, aceite os padrões pressionando a tecla Enter.

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

      $ gcloud compute instances add-metadata secondary-host-name \
           --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
           --zone secondary-zone
    5. Autorizar a VM principal para si mesma

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  2. Na VM do host secundário:

    1. Conecte-se por SSH à VM.

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

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

      $ gcloud compute instances add-metadata primary-host-name \
            --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
            --zone primary-zone
    4. Autorizar a VM secundária para si mesma

      $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. Confirme se as chaves SSH estão configuradas corretamente abrindo uma conexão SSH do sistema secundário para o sistema principal.

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

    $ ssh secondary-host-name

Fazer backup dos bancos de dados

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

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

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

Para criar backups de novos bancos de dados SAP HANA:

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

    sudo -i -u sidadm
  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 sidadm, ative a replicação do sistema:

    > hdbnsutil -sr_enable --name=primary-host-name
  2. No host secundário como sidadm, interrompa o SAP HANA:

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

    $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
    $ myid=$(whoami)
    $ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
    $ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
    $ rm -r /home/"${myid}"/rsecssfs
    
  4. No host secundário, como o mesmo usuário da etapa anterior:

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

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

      $ rm -r /home/"${myid}"/rsecssfs
    3. Como sidadm, registre o sistema SAP HANA secundário com a replicação do sistema SAP HANA:

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
      --replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name
    4. Como sidadm, inicie o SAP HANA:

      > HDB start

Como validar a replicação do sistema

No host principal como sidadm, 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.

Somente SAP HANA 1.0 SPS 12: crie um usuário do Linux para o agente de monitoramento

Você precisa registrar agentes de recursos como um usuário do banco de dados SAP HANA para que eles possam executar consultas no status de replicação do sistema. Os agentes de recursos precisam dos privilégios CATALOG READ e MONITOR ADMIN.

Para registrar os agentes de recursos como um usuário de banco de dados:

  1. No host principal:

    1. Como sidadm, crie o usuário rhelhasync:

      > hdbsql -i inst_num -u system -p system-password \
        "create user rhelhasync password \"monitoring-user-password\""
      > hdbsql -i inst_num -u system -p system-password \
        "grant CATALOG READ to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "grant MONITOR ADMIN to rhelhasync"
      > hdbsql -i inst_num -u system -p system-password \
        "ALTER USER rhelhasync DISABLE PASSWORD LIFETIME"
    2. Como raiz, armazene a credencial para que ela possa ser acessada pelo usuário raiz:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
        "monitoring-user-password"
    3. Como raiz, confirme se as credenciais foram armazenadas com sucesso:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      O resultado será semelhante a:

      ha1adm@hana-ha-vm-1:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-1/SSFS_HDB.KEY
      
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync
    4. Como raiz, confirme se a raiz pode se conectar ao banco de dados usando a chave armazenada:

      # /usr/sap/SID/HDBinst_num/exe/hdbsql -U SAPHANASIDSR -i inst_num \
        "select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION"
  2. No host secundário:

    1. Como raiz, armazene a credencial para que ela possa ser acessada pelo usuário raiz:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore \
        SET SAPHANASIDSR localhost:3inst_num15 rhelhasync \
          "monitoring-user-password"
    2. Como raiz, confirme se as credenciais foram armazenadas com sucesso:

      # /usr/sap/SID/HDBinst_num/exe/hdbuserstore list

      O resultado será semelhante a:

      ha1adm@hana-ha-vm-2:/usr/sap/HA1/HDB22> /usr/sap/HA1/HDB22/exe/hdbuserstore list
      DATA FILE       : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.DAT
      KEY FILE        : /usr/sap/HA1/home/.hdb/hana-ha-vm-2/SSFS_HDB.KEY
      KEY SAPHANAHA1SR
       ENV : localhost:32215
       USER: rhelhasync

Se você receber mensagens de erro ou precisar alterar a senha, use o comando hdbsql ou o SAP HANA Studio para confirmar que a senha do usuário do agente de recursos não está configurada para ser alterada no primeiro login ou que ela não expirou.

Configurar o suporte a failover do Cloud Load Balancing

O serviço de balanceamento de carga TCP/UDP 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. O procedimento oferece proteção em uma configuração ativo/passivo e pode ser estendido para oferecer suporte a uma configuração ativo/ativo (secundária ativada para leitura).

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 principal a um e a VM do host 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
    $ gcloud compute instances add-tags  secondary-host-name \
      --tags network-tags
    
  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. Para o endereço IP, especifique o endereço IP que você reservou para o VIP:

    $ 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

Testar a configuração do balanceador de carga

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

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

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

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

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

    $ sudo yum install -y socat

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

    $ sudo timeout 60s socat - TCP-LISTEN:hlth-chk-port-num,fork

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

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

    A resposta será assim:

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

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

Instalar os agentes do cluster nos dois nós

Conclua as etapas a seguir nos dois nós.

  1. Como raiz, instale os componentes do Pacemaker:

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

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

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

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

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

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  5. Inicie o serviço de PCs e configure-o para iniciar no momento da inicialização:

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  6. Verifique o status do serviço de PCs:

    # systemctl status pcsd.service

    A resposta será assim:

    ● pcsd.service - PCS GUI and remote configuration interface
      Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
      Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
        Docs: man:pcsd(8)
              man:pcs(8)
    Main PID: 31627 (pcsd)
      CGroup: /system.slice/pcsd.service
              └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
    Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
    Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
  7. No arquivo /etc/hosts, adicione o nome completo do host e os endereços IP internos dos dois hosts no cluster. Exemplo:

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

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

Crie o cluster

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

    RHEL 8 e versões mais recentes

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

    RHEL 7

    # pcs cluster auth primary-host-name secondary-host-name
  2. Nas solicitações, digite o nome de usuário hacluster e a senha que você definiu para o usuário hacluster.

  3. Crie o cluster:

    RHEL 8 e versões mais recentes

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

    RHEL 7

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

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

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

  1. Nos dois hosts, abra o arquivo /etc/corosync/corosync.conf para edição:

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

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

    RHEL 8 e versões mais recentes

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

    Exemplo:

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

    RHEL 7

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

    Exemplo:

    totem {
    version: 2
    cluster_name: hacluster
    secauth: off
    transport: udpu
    token: 20000
    token_retransmits_before_loss_const: 10
    join: 60
    max_messages: 20
    }
    ...
  4. No host com o arquivo corosync.conf editado, sincronize a configuração do corosync em todo o cluster:

    RHEL 8 e versões mais recentes

    # pcs cluster sync corosync

    RHEL 7

    # pcs cluster sync
  5. Configure o cluster a ser iniciado automaticamente:

    1. # pcs cluster enable --all
    2. # pcs cluster start --all
  6. Confirme se as novas configurações do corosync estão ativas no cluster por meio do utilitário corosync-cmapctl:

    # corosync-cmapctl

Configurar o isolamento

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

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

  1. No host principal como raiz:

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

      # pcs stonith create primary-fence-name fence_gce \
        port=primary-host-name \
        zone=primary-host-zone \
        project=project-id
      # pcs stonith create secondary-fence-name fence_gce \
        port=secondary-host-name \
        zone=secondary-host-zone \
        project=project-id
    2. Restrinja cada dispositivo de isolamento à outra VM do host:

      # pcs constraint location primary-fence-name avoids primary-host-name
      # pcs constraint location secondary-fence-name avoids secondary-host-name
  2. No host principal como raiz, teste o dispositivo de isolamento secundário:

    1. Encerre a VM do host secundário:

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

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

    2. Reinicie a VM do host secundário:

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
  3. No host secundário como raiz, teste o dispositivo de isolamento primário repetindo as etapas anteriores e usando os valores do host principal nos comandos.

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

    # pcs status

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

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

SAP HANA 2.0 SPS 03 e posterior: ative o gancho de provedor HA/DR do SAP HANA

Se você estiver usando o RHEL 7.6 ou posterior com o SAP HANA 2.0 SPS 03 ou posterior, o Red Hat recomenda o uso do hook de provedor de HA/DR do SAP HANA.

O gancho de provedor HA/DR do SAP HANA permite que o SAP HANA envie notificações para determinados eventos e melhora a detecção de falhas.

Se sua versão do RHEL for anterior à 7.6 ou se a versão do SAP HANA for anterior à 2.0 SPS 03, o hook não será compatível com o RHEL.

As etapas a seguir ativam o gancho de provedor HA/DR do SAP HANA.

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

    # pcs cluster stop --all
  2. Nos dois hosts:

    1. Como sidadm, pare o SAP HANA:

      > HDB stop
    2. Como raiz, instale o script do SAP HANA fornecido:

      # mkdir -p /hana/shared/myHooks
      # cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
      # chown -R sidadm:sapsys /hana/shared/myHooks
    3. Como raiz, abra o arquivo global.ini para edição:

      # vi /hana/shared/SID/global/hdb/custom/config/global.ini
    4. Adicione as seguintes definições ao arquivo global.ini:

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /hana/shared/myHooks
      execution_order = 1
      
      [trace]
      ha_dr_saphanasr = info
    5. Como raiz, crie um arquivo de configuração sudo para permitir que o script do gancho atualize os atributos do nó quando o gancho srConnectionChanged() for chamado:

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

      1 Cmnd_Alias SOK   = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SOK -t crm_config -s SAPHanaSR
      2 Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
      3 sidadm ALL=(ALL) NOPASSWD: SOK, SFAIL
    7. Como sidadm, inicie o SAP HANA:

      > HDB start
    8. Como sidadm, teste o status informado pelo script do gancho:

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

Definir os padrões do cluster

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

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

    # pcs cluster start --all #start the cluster
  2. Defina os padrões do recurso:

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

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

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

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

  3. Se as propriedades startup-fencing e stonith-enabled ainda não estiverem definidas como true, defina-as como true agora:

    # pcs property set startup-fencing="true"
    # pcs property set stonith-enabled="true"

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

    # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
       InstanceNumber=inst_num \
       op start timeout=600 \
       op stop timeout=300 \
       op monitor interval=10 timeout=600 \
       clone clone-max=2 clone-node-max=1 interleave=true
  2. Depois que o recurso for criado, verifique a configuração. Anexe -clone ao nome do recurso para incluir as informações do conjunto de clones na resposta:

    RHEL 8 e versões mais recentes

    # pcs resource config topology_resource_name-clone

    RHEL 7

    # pcs resource show topology_resource_name-clone

    A resposta será semelhante a esta:

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

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

Criar o recurso SAPHana

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

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

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

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

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

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

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

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

    RHEL 8 e versões mais recentes

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

    RHEL 7

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

    RHEL 8 e versões mais recentes

    # pcs resource config sap_hana_resource_name

    RHEL 7

    # pcs resource show sap_hana_resource_name

    O resultado será semelhante a:

     Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
      Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
      Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
      Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
                  methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
                  monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
                  monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
                  promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
                  reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
                  start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
                  stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)
  3. Depois que o recurso for iniciado, verifique os atributos do nó para ver o estado atual dos bancos de dados do SAP HANA nos nós:

    # crm_mon -A1

    A resposta será assim:

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

Criar um recurso de endereço IP virtual

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

Como raiz em um dos hosts:

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32

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

Criar as restrições

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

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

    RHEL 8 e versões mais recentes

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

    RHEL 7

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

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

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

  2. Verifique as restrições:

    # pcs constraint

    A resposta será assim:

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

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

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

Instalar um listener

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

  1. Em cada host como raiz, instale um listener TCP simples. Estas instruções instalam e usam o HAProxy como listener.

    # yum install haproxy
  2. 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
  3. Em cada host como raiz, inicie o serviço para confirmar se ele está configurado corretamente:

    # systemctl start haproxy.service
  4. Na página do balanceador de carga no Console do 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.

    A captura de tela mostra "1/1" na coluna íntegra dos dois grupos de instâncias,
indicando que ambos estão íntegros.

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

    A captura de tela mostra "0/1" na coluna íntegra de cada
grupo de instâncias, indicando que não há listener ativo.

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

Criar o recurso de verificação de integridade

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

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

    # pcs status

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

    # pcs resource move healthcheck_resource_name target_host_name
    # pcs resource clear healthcheck_resource_name

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

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

    Full list of resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
    rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2
  3. Agrupe os recursos VIP e de verificação de integridade:

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

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

    Full list of resources:
    
    STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
    STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
    Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
        Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
    Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
        Masters: [ hana-ha-vm-1 ]
        Slaves: [ hana-ha-vm-2 ]
    Resource Group: g-primary
        rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
        rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
  4. Crie uma restrição que localize o novo grupo no mesmo nó que a instância mestre do SAP HANA.

    RHEL 8 e versões mais recentes

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

    RHEL 7

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

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

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

Testar o failover

Para testar seu cluster, simule uma falha no host principal. Use um sistema de teste ou execute o teste no sistema de produção antes de liberar o sistema para uso.

Faça backup do sistema antes do teste.

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

  • HDB stop
  • HDB kill
  • shutdown -r (no nó ativo)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

Estas instruções usam ip link set eth0 down para colocar a interface de rede off-line porque ela valida o failover e o isolamento.

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

    # ip link set eth0 down
  2. Reconecte-se ao host usando o SSH e mude para o usuário raiz

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

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

Solução de problemas

Você encontra os registros nos seguintes locais:

RHEL 8 e versões mais recentes

  • /var/log/pacemaker/pacemaker.log
  • /var/log/cluster/corosync.log

RHEL 7

  • /var/log/pacemaker.log
  • /var/log/cluster/corosync.log

Se você não encontrar os arquivos de registros nesses locais, verifique as configurações de registro em /etc/sysconfig/pacemaker.

Status do cluster válido:

# pcs status
Cluster name: hana-ha-cluster
Stack: corosync
Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Wed Jun 17 00:34:16 2020
Last change: Wed Jun 17 00:34:09 2020 by root via crm_attribute on hana-ha-vm-1

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:

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

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Se você tiver problemas com o cluster de alta disponibilidade do RHEL, colete as seguintes informações dos nós do cluster e entre em contato com o suporte:

  • Liste os processos do Pacemaker em execução:

    ps axf | grep pacemaker

  • Instale a ferramenta sos e gere um sosreport. Para mais informações, consulte O que é um sosreport e como criar um no Red Hat Enterprise Linux?:

    • Instalar a sos ferramenta
      yum install -y sos
    • Execute a ferramenta sos em todos os nós:
      sosreport -o logs, corosync, pacemaker -k pacemaker.crm_from="yyyy-mm-dd hh:mm:ss"
  • Se não for possível instalar a ferramenta sos, forneça uma cópia de /etc/corosync/corosync.conf, o arquivo de configuração do Corosync de todos os sistemas.

  • Forneça a versão do Pacemaker:

    crmadmin --version

  • Forneça a saída do crm_report:

    crm_report -f "yyyy/mm/dd hh:mm"

  • Execute journalctl, especificando os horários de início e término que correspondem à hora em que o problema ocorreu:

    journalctl -a --utc --no-pager -S "yyyy-mm-dd hh:mm:ss UTC" -U "yyyy-mm-dd hh:mm:ss UTC"

  • Forneça uma contagem de falhas de todos os recursos em cada nó do Pacemaker:

    crm config show | grep primitive | awk '{print $2}' | xargs -L 1 -I "{}" crm resource failcount {} show node-name

Suporte

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

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

Requisitos de suporte

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

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

Como 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 se conectar ao 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.

Como realizar tarefas pós-implantação

Antes de usar sua instância do SAP HANA, recomendamos que você configure e faça backup do novo banco de dados SAP HANA.

Para mais informações:

A seguir

Consulte os tópicos aseguir para saber mais: