Alta disponibilidade do SAP HANA em expansão com o Azure NetApp Files no RHEL

  • Artigo

Este artigo descreve como configurar a replicação de sistema do SAP HANA em expansão de implantação, quando os sistemas de arquivos do HANA são montados via NFS, usando o Azure NetApp Files. Nas configurações e comandos de instalação de exemplo, são usados o número da instância 03 e a ID do sistema do HANA HN1. A Replicação de Sistema do SAP HANA consiste em um nó primário e, pelo menos, um nó secundário.

Quando as etapas deste documento são marcadas com os seguintes prefixos, o significado é o seguinte:

  • [A] : a etapa aplica-se a todos os nós
  • [1] : a etapa se aplica apenas ao nó 1
  • [2] : a etapa aplica-se apenas ao nó 2

Pré-requisitos

Primeiro, leia os seguintes documentos e Notas SAP:

Visão geral

Tradicionalmente em um ambiente de expansão, todos os sistemas de arquivos para SAP HANA são montados no armazenamento local. A configuração de HA (alta disponibilidade) da replicação de sistema do SAP HANA no Red Hat Enterprise Linux foi publicada em Configurar a replicação de sistema do SAP HANA no RHEL.

Para obter HA do SAP HANA de um sistema de expansão em compartilhamentos de NFS do Azure NetApp Files, precisamos de mais configuração de recursos no cluster para que os recursos do HANA sejam recuperados, quando um nó perde o acesso aos compartilhamentos de NFS em ANF. O cluster gerencia as montagens de NFS, permitindo que ele monitore a integridade dos recursos. As dependências entre as montagens do sistema de arquivos e os recursos de SAP HANA são obrigatórias.

Diagram that shows SAP HANA HA scale-up on Azure NetApp Files.

Os sistemas de arquivos do SAP HANA são montados em compartilhamentos de NFS usando o Azure NetApp Files em cada nó. Sistemas de arquivos /hana/data, /hana/log e /hana/shared exclusivos para cada nó.

Montado em node1 (hanadb1):

  • 10.32.2.4:/hanadb1-data-mnt00001 em /hana/data
  • 10.32.2.4:/hanadb1-log-mnt00001 em /hana/log
  • 10.32.2.4:/hanadb1-shared-mnt00001 em /hana/shared

Montado em node2 (hanadb2):

  • 10.32.2.4:/hanadb2-data-mnt00001 em /hana/data
  • 10.32.2.4:/hanadb2-log-mnt00001 em /hana/log
  • 10.32.2.4:/hanadb2-shared-mnt00001 em /hana/shared

Observação

Sistemas de arquivos /hana/shared, /hana/data e /hana/log não são compartilhados entre os dois nós. Cada nó de cluster tem seus próprios sistemas de arquivos separados.

A configuração da replicação de sistema do SAP HANA usa um nome do host virtual dedicado e endereços IP virtuais. No Azure, um balanceador de carga é necessário para usar um endereço IP virtual. A configuração mostrada aqui tem um balanceador de carga com:

  • Endereço IP de front-end: 10.32.0.10 para hn1-db
  • Porta de investigação: 62503

Configurar a infraestrutura do Azure NetApp Files

Antes de prosseguir com a configuração da infraestrutura do Azure NetApp Files, familiarize-se com a documentação do Azure NetApp Files.

O Azure NetApp Files está disponível em várias regiões do Azure. Verifique se a região do Azure selecionada oferece o Azure NetApp Files.

Para obter informações sobre a disponibilidade do Azure NetApp Files por região do Azure, consulte Disponibilidade do Azure NetApp Files por região do Azure.

Considerações importantes

Ao criar os volumes de Azure NetApp Files para sistemas de expansão do SAP HANA, esteja ciente das considerações importantes documentadas em Volumes de NFS v4.1 no Azure NetApp Files para SAP HANA.

Dimensionamento do banco de dados do HANA no Azure NetApp Files

A taxa de transferência de um volume do Azure NetApp Files é uma função do tamanho de volume e do nível de serviço, conforme documentado no Nível de serviço para Azure NetApp Files.

Ao projetar a infraestrutura do SAP HANA no Azure com Azure NetApp Files, esteja ciente das recomendações em Volumes de NFS v4.1 no Azure NetApp Files para SAP HANA.

A configuração neste artigo é apresentada com volumes do Azure NetApp Files simples.

Importante

Para sistemas de produção, em que o desempenho é fundamental, é recomendável avaliar e considerar o uso do grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA.

Implantar recursos do Azure NetApp Files

As instruções a seguir pressupõem que você já implantou a Rede virtual do Azure. Os recursos do Azure NetApp Files e as VMs nas quais os recursos do Azure NetApp Files serão montados precisam ser implantados na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas.

  1. Crie uma conta do NetApp na região do Azure selecionada, seguindo as instruções em Criar uma conta do NetApp.

  2. Configure um pool de capacidade do Azure NetApp Files seguindo as instruções em Configurar um pool de capacidade do Azure NetApp Files.

    A arquitetura do HANA mostrada neste artigo usa um único pool de capacidade do Azure NetApp Files no nível de serviço Ultra. Para cargas de trabalho do HANA no Azure, é recomendável usar um nível de serviçoUltra ou Premium do Azure NetApp Files.

  3. Delegue uma sub-rede para o Azure NetApp Files, conforme descrito nas instruções em Delegar uma sub-rede ao Azure NetApp Files.

  4. Implante volumes do Azure NetApp Files seguindo as instruções em Criar um volume NFS para o Azure NetApp Files.

    Enquanto estiver implantando os volumes, certifique-se de selecionar a versão NFSv4.1. Implante os volumes na sub-rede designada do Azure NetApp Files. Os endereços IP dos volumes do Azure NetApp são atribuídos automaticamente.

    Lembre-se de que os recursos do Azure NetApp Files e as VMs do Azure precisam estar na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas. Por exemplo, hanadb1-data-mnt00001 e hanadb1-log-mnt00001 são os nomes de volume nfs://10.32.2.4/hanadb1-log-mnt00001 e nfs://10.32.2.4/hanadb1-data-mnt00001 são os caminhos de arquivo para os volumes do Azure NetApp Files.

    Em hanadb1:

    • Volume hanadb1-data-mnt00001 (nfs://10.32.2.4:/hanadb1-data-mnt00001)
    • Volume hanadb1-log-mnt00001 (nfs://10.32.2.4:/hanadb1-log-mnt00001)
    • Volume hanadb1-shared-mnt00001 (nfs://10.32.2.4:/hanadb1-shared-mnt00001)

    Em hanadb2:

    • Volume hanadb2-data-mnt00001 (nfs://10.32.2.4:/hanadb2-data-mnt00001)
    • Volume hanadb2-log-mnt00001 (nfs://10.32.2.4:/hanadb2-log-mnt00001)
    • Volume hanadb2-shared-mnt00001 (nfs://10.32.2.4:/hanadb2-shared-mnt00001)

Observação

Todos os comandos a serem montados /hana/shared neste artigo são apresentados para volumes do NFSv4.1 /hana/shared. Se você implantou os /hana/shared volumes como volumes do NFSv3, não se esqueça de ajustar os comandos de montagem /hana/shared para o NFSv3.

Preparar a infraestrutura

O Azure Marketplace contém imagens qualificadas para SAP HANA com o complemento de alta disponibilidade, que é possível usar para implantar novas VMs usando várias versões do Red Hat.

Implantar VMs do Linux manualmente por meio do portal do Azure

Este documento considera que você já implantou um grupo de recursos, uma Rede virtual do Azure e uma sub-rede.

Implantar VMs para SAP HANA. Escolha uma imagem RHEL adequada com suporte para o sistema HANA. Você pode implantar uma VM em qualquer uma das opções de disponibilidade: conjunto de dimensionamento de máquinas virtuais, zona de disponibilidade ou conjunto de disponibilidade.

Importante

Certifique-se de que o sistema operacional selecionado conte com a certificação SAP para o SAP HANA para os tipos de VM específicas que você planeja usar em sua implantação. Você pode pesquisar tipos de VM certificadas pelo SAP HANA e suas versões do sistema operacional nas Plataformas de IaaS Certificadas do SAP HANA. Certifique-se de clicar nos detalhes do tipo de VM para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para o tipo de VM específico.

Configurar o Azure Load Balancer

Durante a configuração da VM, você tem a opção de criar ou selecionar o balanceador de carga existente na seção de rede. Siga as etapas abaixo para configurar o balanceador de carga padrão para a configuração de alta disponibilidade do banco de dados HANA.

Siga as etapas em Criar balanceador de carga para configurar um balanceador de carga padrão para um sistema SAP de alta disponibilidade usando o portal do Azure. Durante a configuração do balanceador de carga, considere os seguintes pontos:

  1. Configuração de IP front-end: crie um IP de front-end. Selecione a mesma rede virtual e nome de sub-rede das máquinas virtuais de banco de dados.
  2. Pool de back-end: crie um pool de back-end e adicione VMs de banco de dados.
  3. Regras de entrada: crie uma regra de balanceamento de carga. Siga as mesmas etapas para ambas as regras de balanceamento de carga.
    • Endereço IP de front-end: selecione um IP de front-end.
    • Pool de back-end: selecione um pool de back-end.
    • Portas de alta disponibilidade: selecione essa opção.
    • Protocolo: selecione TCP.
    • Sonda de integridade: crie uma sonda de integridade com os seguintes detalhes:
      • Protocolo: selecione TCP.
      • Porta: por exemplo, 625<instância-não.>.
      • Intervalo: inserir 5.
      • Limite de Sonda: inserir 2.
    • Tempo limite de inatividade (minutos): inserir 30.
    • Habilitar IP Flutuante: selecione essa opção.

Observação

A propriedade de configuração da investigação de integridade numberOfProbes, também conhecida como Limite não íntegro no portal, não é respeitada. Para controlar o número de análises consecutivas bem-sucedidas ou com falha, configure a propriedade probeThreshold para 2. Atualmente não é possível definir essa propriedade utilizando o portal do Azure, por isso utilize a CLI do Azure ou o comando PowerShell.

Para obter mais informações sobre as portas necessárias para o SAP HANA, leia o capítulo Conexões aos bancos de dados de locatário no guia Bancos de dados de locatário do SAP HANA ou Nota SAP 2388694.

Importante

Não há suporte para IP flutuante em uma configuração de IP de adaptador de rede secundário em cenários de balanceamento de carga. Para obter mais informações, veja Limitações do Azure Load Balancer. Se você precisar de um endereço IP adicional para a VM, implante um segunda NIC.

Observação

Quando VMs sem endereços IP públicos são colocados no pool de back-end de uma instância interna (sem endereço IP público) do Standard Azure Load Balancer, não há conectividade de saída com a internet, a menos que seja realizada mais configuração para permitir o roteamento para pontos extremidade públicos. Para obter informações sobre como alcançar conectividade de saída, veja Conectividade de ponto de extremidade público para máquinas virtuais usando o Standard Azure Load Balancer em cenários de alta disponibilidade do SAP.

Importante

Não habilite carimbos de data/hora de TCP em VMs do Azure posicionadas de forma subjacente em relação ao Azure Load Balancer. Habilitar carimbos de data/hora do TCP pode causar falha nas sondagens de integridade. Defina o parâmetro net.ipv4.tcp_timestamps para 0. Para saber mais, confira Investigações de integridade do Load Balancer e Nota do SAP 2382421.

Montar o volume de Azure NetApp Files

  1. [A] Crie pontos de montagem para os volumes de banco de dados do HANA.

    sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared

  2. [A] Verifique a configuração do domínio NFS. Verifique se o domínio está configurado como o domínio do Azure NetApp Files padrão, ou seja, defaultv4iddomain.com e o mapeamento é definido para ninguém.

    sudo cat /etc/idmapd.conf

    Exemplo de saída:

    [General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

    Importante

    É preciso que você defina o domínio NFS em /etc/idmapd.conf na VM para corresponder à configuração de domínio padrão no Azure NetApp Files: defaultv4iddomain.com. Se houver uma incompatibilidade entre a configuração de domínio no cliente do NFS (ou seja, a VM) e o servidor do NFS, ou seja, a configuração do Azure NetApp Files, as permissões para arquivos nos volumes do Azure NetApp Files que forem montados nas VMs serão exibidas como nobody.

  3. [1] Monte os volumes específicos do nó em node1 (hanadb1).

    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data

  4. [2] Monte os volumes específicos do nó em node2 (hanadb2).

    sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data

  5. [A] Verifique se todos os volumes do HANA estão montados com o protocolo NFS versão NFSv4.

    sudo nfsstat -m

    Verifique se o sinalizador vers está definido como 4.1. Exemplo do hanadb1:

    /hana/log from 10.32.2.4:/hanadb1-log-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
/hana/data from 10.32.2.4:/hanadb1-data-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
/hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4

  6. [A] Verifique nfs4_disable_idmapping. Ele deve ser definido como Y. Para criar a estrutura de diretório em que nfs4_disable_idmapping está localizado, execute o comando de montagem. Não é possível criar o diretório manualmente em /sys/modules, pois o acesso é reservado para o kernel e os drivers.

    Verifique nfs4_disable_idmapping.

    sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping

    Se você precisar definir nfs4_disable_idmapping como:

    sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

    Tornar a configuração permanente.

    sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

    ​Para obter mais informações sobre como alterar o parâmetro nfs_disable_idmapping, consulte a Base de conhecimento do Red Hat.

Instalação do SAP HANA

  1. [A] Configure a resolução do nome do host de todos os hosts.

    Você pode usar um servidor DNS ou modificar o arquivo /etc/hosts em todos os nós. Este exemplo mostra como usar o arquivo /etc/hosts. Substitua o endereço IP e o nome do host nos comandos a seguir:

    sudo vi /etc/hosts

    Insira as linhas a seguir no arquivo /etc/hosts. Altere o endereço IP e o nome do host para corresponder ao seu ambiente.

    10.32.0.4   hanadb1
10.32.0.5   hanadb2

  2. [A] Prepare o sistema operacional para executar o SAP HANA no Azure NetApp com o NFS, conforme descrito na Nota do SAP 3024346 – Configurações do Kernel do Linux para NetApp com o NFS. Crie um arquivo /etc/sysctl.d/91-NetApp-HANA.conf de configuração para as configurações do NetApp.

    sudo vi /etc/sysctl.d/91-NetApp-HANA.conf

    Adicionar as seguintes entradas no arquivo de configuração.

    net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000 
net.ipv4.tcp_slow_start_after_idle=0 
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1    
net.ipv4.tcp_sack = 1

  3. [A] Crie o arquivo de configuração /etc/sysctl.d/ms-az.conf com mais configurações de otimização.

    sudo vi /etc/sysctl.d/ms-az.conf

    Adicionar as seguintes entradas no arquivo de configuração.

    net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10

    Dica

    Evite definir net.ipv4.ip_local_port_range e net.ipv4.ip_local_reserved_ports explicitamente nos arquivos de configuração sysctl, para permitir que o Agente de Host do SAP gerencie os intervalos de portas. Para saber mais, consulte a Nota do SAP 2382421.

  4. [A] Ajuste as configurações de sunrpc, conforme recomendado na Nota do SAP 3024346 – Configurações do Kernel do Linux para NetApp com o NFS.

    sudo vi /etc/modprobe.d/sunrpc.conf

    Insira a seguinte linha:

    options sunrpc tcp_max_slot_table_entries=128

  5. [A] Executar a configuração do sistema operacional do RHEL para o HANA.

    Configure o sistema operacional conforme descrito nas seguintes Notas do SAP com base na sua versão do RHEL:

  6. [A] Instalar o SAP HANA.

    Iniciar com o HANA 2.0 SPS 01, MDC é a opção padrão. Ao instalar o sistema HANA, o SYSTEMDB e um locatário com o mesmo SID são criados juntos. Em alguns casos, você não deseja o locatário padrão. Caso não queira criar um locatário inicial junto com a instalação, segua a Nota do SAP 2629711.

    Execute o hdblcm programa a partir do DVD do HANA. Insira os valores a seguir no prompt:

    1. Escolha a instalação: insira 1 (para instalar).
    2. Selecione mais componentes para instalação: insira 1.
    3. Insira o Caminho de instalação [/hana/shared]: selecione Enter para aceitar o padrão.
    4. Insira o Nome do host local [..]: selecione Enter para aceitar o padrão. Você deseja adicionar outros hosts ao sistema? (s/n) [n]: n.
    5. Insira a ID do sistema SAP HANA: insira HN1.
    6. Insira o número da instância [00]: insira 03.
    7. Selecione o Modo de banco de dados/Insira o índice [1]: selecione Enter para aceitar o padrão.
    8. Selecione Uso do sistema/Inseria índice [4]: insira 4 (para personalizado)
    9. Insira o Local dos volumes de dados [/hana/data]: selecione Enter para aceitar o padrão.
    10. Insira o Local dos volumes de log [/hana/log]: selecione Enter para aceitar o padrão.
    11. Restringir a alocação máxima de memória? [n]: selecione Enter para aceitar o padrão.
    12. Insira o Nome do host do certificado para o host '...' [...]: selecione Enter para aceitar o padrão.
    13. Insira a Senha (sapadm) de usuário de agente de host do SAP : insira a senha de usuário de agente de host.
    14. Confirme a Senha (sapadm) de usuário de agente de host SAP: insira a senha de usuário de agente de host novamente para confirmar.
    15. Insira a Senha do administrador do sistema (hn1adm): insira a senha do administrador do sistema.
    16. Confirme a Senha do administrador do sistema (hn1adm): insira a senha do administrador do sistema novamente para confirmar.
    17. Insira o Diretório base do administrador do sistema [/usr/sap/HN1/home]: selecione Enter para aceitar o padrão.
    18. Insira o Shell de login do administrador do sistema [/bin/sh]: selecione Enter para aceitar o padrão.
    19. Insira a ID de usuário do administrador do sistema [1001]: selecione Enter para aceitar o padrão.
    20. Insira a ID do grupo de usuários (SAPs) [79]: selecione Enter para aceitar o padrão.
    21. Insira a Senha de usuário do banco de dados (SISTEMA) : insira a senha do usuário do banco de dados.
    22. Confirme a Senha do usuário do banco de dados (SISTEMA): insira a senha do usuário do banco de dados novamente para confirmar.
    23. Reiniciar o sistema após a reinicialização do computador? [n]: selecione Enter para aceitar o padrão.
    24. Deseja continuar? (s/n):Valide o resumo. Insira y para continuar.

  7. [A] Atualize o Agente de Host do SAP.

    Baixe o último arquivo do Agente de Host do SAP no Centro de Software do SAP e execute o comando a seguir para atualizar o agente. Substitua o caminho do arquivo para apontar para o arquivo que você baixou:

    sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>

  8. [A] Configurar um firewall.

    Crie a regra de firewall para a porta de investigação do Azure Load Balancer.

    sudo firewall-cmd --zone=public --add-port=62503/tcp
sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent

Configurar a replicação do sistema do SAP HANA

Siga as etapas em Configurar replicação do sistema SAP HANA para configurar a replicação do sistema SAP HANA.

Configuração do cluster

Esta seção descreve as etapas necessárias para que um cluster opere de forma direta quando o SAP HANA é instalado em compartilhamentos de NFS usando Azure NetApp Files.

Criar um cluster do Pacemaker

Siga as etapas em Configurar o Pacemaker no Red Hat Enterprise Linux no Azure para criar um cluster básico do Pacemaker para esse servidor HANA.

Importante

Com o Estrutura de inicialização do SAP baseado em sistema, as instâncias do SAP HANA agora podem ser gerenciadas pelo systemd. A versão mínima necessária do Red Hat Enterprise Linux (RHEL) é RHEL 8 para SAP. Conforme descrito na Nota do SAP 3189534, todas as novas instalações da revisão 70 ou superior do SAP HANA SPS07 ou atualizações para sistemas HANA para a revisão 70 ou superior do HANA 2.0 SPS07, a estrutura de Inicialização do SAP será registrada automaticamente com o sistema.

Ao usar soluções de HA para gerenciar a replicação do sistema SAP HANA combinadas com instâncias do SAP HANA habilitadas para sistema (consulte a Nota do SAP 3189534), etapas adicionais são necessárias para garantir que o cluster de HA possa gerenciar a instância do SAP sem interferência do systemd. Portanto, para o sistema SAP HANA integrado ao sistema, etapas adicionais descritas no KBA 7029705 do Red Hat, devem ser seguidas em todos os nós de cluster.

Implementar o gancho SAPHanaSR de replicação do sistema Python

Essa é uma etapa importante para otimizar a integração com o cluster e melhorar a detecção, quando um failover de cluster for necessário. É fortemente recomendável que você configure o gancho do Python do SAPHanaSR. Siga as etapas em, Implementar o gancho SAPHanaSR de replicação do sistema Python.

Configurar recursos do sistema de arquivos

Neste exemplo, cada nó de cluster tem seus próprios sistemas de arquivos de NFS do HANA /hana/shared, /hana/data e /hana/log.

  1. [1] Coloque o cluster no modo de manutenção.

    sudo pcs property set maintenance-mode=true

  2. [1] Crie os recursos do sistema de arquivos para as montagens hanadb1.

    sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs

  3. [2] Crie os recursos do sistema de arquivos para as montagens hanadb2.

    sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs

    O atributo OCF_CHECK_LEVEL=20 é adicionado à operação de monitoramento para que cada monitor execute um teste de leitura/gravação no sistema de arquivos. Sem esse atributo, a operação de monitoramento só verifica se o sistema de arquivos está montado. Isso pode ser um problema pois, quando a conectividade é perdida, o sistema de arquivos pode permanecer montado, apesar de estar inacessível.

    O atributo on-fail=fence também é adicionado à operação de monitoramento. Com essa opção, se a operação de monitoramento falhar em um nó, esse nó será imediatamente isolado. Sem essa opção, o comportamento padrão é parar todos os recursos que dependem do recurso com falha, reiniciar o recurso com falha e, em seguida, iniciar todos os recursos que dependem do recurso com falha.

    Esse comportamento não só pode levar muito tempo quando um recurso SAP HANA depende do recurso com falha, mas também pode falhar completamente. O recurso SAP HANA não poderá parar com êxito se o servidor NFS que contém os executáveis do HANA estiver inacessível.

    Os valores de tempo limite sugeridos permitem que os recursos do cluster resistam à pausa específica do protocolo, relacionada às renovações de tempo de concessão do NFSv4.1. Para obter mais informações, confira Melhor prática do NFS no NetApp. Os tempos limite na configuração anterior podem ser adaptados à configuração específica do SAP.

    Para cargas de trabalho que exigem maior taxa de transferência, considere usar a opção de montagem nconnect, conforme a descrição em Volumes NFS v4.1 no Azure NetApp Files para SAP HANA. Verifique se nconnect é compatível com o Azure NetApp Files em sua versão do Linux.

  4. [1] Configurar restrições de localização.

    Configure restrições de local para garantir que os recursos que gerenciam montagens exclusivas hanadb1 nunca possam ser executados em hanadb2 e vice versa.

    sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1

    A opção resource-discovery=never é definida porque as montagens exclusivas para cada nó compartilham o mesmo ponto de montagem. Por exemplo, hana_data1 usa o ponto /hana/data de montagem e hana_data2 também usa o ponto de montagem /hana/data. Compartilhar o mesmo ponto de montagem pode causar um falso positivo para uma operação de investigação de integridade, quando o estado do recurso é verificado na inicialização do cluster e, por sua vez, causar um comportamento de recuperação desnecessário. Para evitar esse cenário, defina resource-discovery=never.

  5. [1] Configurar recursos de atributo.

    Configurar recursos de atributo. Esses atributos serão definidos como verdadeiros, se todas as montagens do NFS de um nó (/hana/data, /hana/log e /hana/data) forem montadas. Caso contrário, eles são definidos como falsos.

    sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active

  6. [1] Configurar restrições de localização.

    Configure restrições de local para garantir que o recurso de atributo do hanadb1 nunca seja executado em hanadb2 e vice versa.

    sudo pcs constraint location hana_nfs1_active avoids hanadb2
sudo pcs constraint location hana_nfs2_active avoids hanadb1

  7. [1] Criar restrições de ordenação.

    Configure restrições de ordenação para que os recursos de atributo de um nó sejam iniciados somente depois que todas as montagens NFS do nó forem montadas.

    sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
sudo pcs constraint order hanadb2_nfs then hana_nfs2_active

    Dica

    Se sua configuração incluir sistemas de arquivos, fora do grupo hanadb1_nfs ou hanadb2_nfs, inclua a sequential=false opção, de modo que não haja nenhuma dependência de ordenação entre os sistemas de arquivos. Todos os sistemas de arquivos devem iniciar antes hana_nfs1_active, mas não precisam iniciar em nenhuma ordem relativa uns ao outros. Para maiores informações, consulte Como fazer para configurar a replicação do sistema SAP HANA na expansão em um cluster do Pacemaker quando os sistemas de recursos do HANA estiverem em compartilhamentos de NFS

Configurar os recursos de cluster do SAP HANA

  1. Siga as etapas em Criar os recursos de cluster do SAP HANA, para criar os recursos de SAP HANA no cluster. Após criar os recursos de SAP HANA, é necessário criar uma restrição de regra de local entre os recursos de SAP HANA e os arquivos do sistema (montagens do NFS).

  2. [1] Configurar restrições entre os recursos de SAP HANA e as montagens de NFS.

    As restrições de regra de local são definidas para que os recursos de SAP HANA possam ser executados em um nó apenas se todas as montagens do NFS do nó estiverem montadas.

    sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true

    No RHEL 7.x:

    sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true

    No RHEL 8.x/9.x:

    sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true

    Retire o cluster do modo de manutenção.

    sudo pcs property set maintenance-mode=false

    Verificar o status do cluster e de todos os recursos.

    Observação

    Este artigo contém referências a um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

    sudo pcs status

    Exemplo de saída:

    Online: [ hanadb1 hanadb2 ]

Full list of resources:

rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1

Resource Group: hanadb1_nfs
hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1

Resource Group: hanadb2_nfs
hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2

hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
Started: [ hanadb1 hanadb2 ]

Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hanadb1 ]
Slaves: [ hanadb2 ]

Resource Group: g_ip_HN1_03
nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1

Configurar a replicação de sistema ativa/habilitada para leitura do HANA no cluster do Pacemaker

Iniciar com o SAP HANA 2.0 do Microsoft SharePoint Server 01, o SAP permite a configuração ativa/habilitada para leitura da replicação de sistema do SAP HANA, em que os sistemas secundários de replicação de sistema do SAP HANA podem ser usados ativamente para cargas de trabalho com uso intensivo de leitura. Para dar suporte esse tipo de configuração em um cluster, é necessário ter um segundo endereço IP virtual. Isso permite que os clientes acessem o banco de dados secundário do SAP HANA habilitado para leitura.

Para garantir que o site de replicação secundária ainda possa ser acessado após uma tomada de controle, o cluster precisará mover o endereço IP virtual com o secundário do recurso SAPHana.

A configuração extra, que é necessária para gerenciar a Replicação de Sistema ativa/habilitada para leitura do HANA em um cluster de HA do Red Hat com um segundo IP virtual, é descrita em Configurar a replicação de sistema do HANA ativo/leitura habilitado no cluster Pacemaker.

Antes de continuar, verifique se você configurou totalmente o cluster de alta disponibilidade do Red Hat gerenciando o banco de dados do SAP HANA conforme descrito nas seções anteriores da documentação.

Testar a configuração do cluster

Esta seção descreve como é possível testar a configuração.

  1. Antes de iniciar um teste, verifique se o Pacemaker não possui nenhuma ação com falha (via status de pcs), não há restrições de local inesperadas (por exemplo, sobras de um teste de migração) e que a replicação do sistema HANA é o estado de sincronização, por exemplo com systemReplicationStatus:

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

  2. Verifique a configuração do cluster para um cenário de falha, quando um nó perde o acesso ao compartilhamento NFS (/hana/shared).

    Os agentes de recurso de SAP HANA dependem de binários, armazenados/hana/shared para executar operações durante o failover. O sistema de arquivos /hana/shared é montado em NFS no cenário apresentado.

    É difícil simular uma falha, em que um dos servidores perde o acesso ao compartilhamento NFS. Como um teste, monte novamente o sistema de arquivos como somente leitura. Essa abordagem valida que o cluster pode fazer o failover, se o acesso a /hana/shared for perdido no nó ativo.

    Resultado esperado: ao fazer /hana/shared como um sistema de arquivos somente leitura, o atributo OCF_CHECK_LEVEL do recurso hana_shared1, que executa operações de leitura/gravação em sistemas de arquivos, falha. Ele não consegue de gravar nada no sistema de arquivos e executa o failover de recursos do HANA. O mesmo resultado é esperado quando o nó do HANA perde o acesso aos compartilhamentos NFS.

    Estado do recurso antes de iniciar o teste:

    sudo pcs status

    Exemplo de saída:

    Full list of resources:
 rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1

 Resource Group: hanadb1_nfs
     hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
     hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
     hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1

Resource Group: hanadb2_nfs
     hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
     hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
     hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2

 hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
 hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2

 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
     Started: [ hanadb1 hanadb2 ]

 Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
     Masters: [ hanadb1 ]
     Slaves: [ hanadb2 ]

 Resource Group: g_ip_HN1_03
     nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
     vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1

    Coloque /hana/shared no modo somente leitura no nó de cluster ativo usando este comando:

    sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared

    hanadb será reinicializado ou desligado com base na ação definida em stonith (pcs property show stonith-action). Após o servidor (hanadb1) estiver inativo, o recurso do HANA será movido para hanadb2. É possível verificar o status do cluster em hanadb2.

    sudo pcs status

    Exemplo de saída:

    Full list of resources:

 rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2

 Resource Group: hanadb1_nfs
     hana_data1 (ocf::heartbeat:Filesystem):    Stopped
     hana_log1  (ocf::heartbeat:Filesystem):    Stopped
     hana_shared1       (ocf::heartbeat:Filesystem):    Stopped

 Resource Group: hanadb2_nfs
     hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
     hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
     hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2

 hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
 hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2

 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
     Started: [ hanadb2 ]
     Stopped: [ hanadb1 ]

 Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
     Masters: [ hanadb2 ]
     Stopped: [ hanadb1 ]

 Resource Group: g_ip_HN1_03
     nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
     vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2

    É recomendável que você teste completamente a configuração de cluster do SAP HANA, executando também os testes descritos na Instalação da replicação do sistema de SAP HANA no sistema no RHEL.

Próximas etapas