Compartilhar via


Alta disponibilidade para o sistema de expansão SAP HANA com HSR no SUSE Linux Enterprise Server

Este artigo descreve como implantar um sistema SAP HANA altamente disponível em uma configuração de expansão com HSR (replicação de sistema do HANA) e Pacemaker nas máquinas virtuais (VMs) do Azure SUSE Linux Enterprise Server. Os sistemas de arquivos compartilhados na arquitetura apresentada são montados com NFS e fornecidos pelo Azure NetApp Files ou pelo compartilhamento de NFS nos Arquivos do Azure.

Nos exemplos de configurações, comandos de instalação e assim por diante, a instância do HANA é 03 e a ID do sistema HANA é HN1.

Antes de começar, consulte as seguintes notas e documentos do SAP:

Visão geral

Um método para obter alta disponibilidade do HANA para instalações de expansão do HANA é configurar a replicação do sistema HANA e proteger a solução com o cluster Pacemaker para permitir o failover automático. Quando um nó ativo falha, o cluster executa o failover dos recursos do HANA para o outro site.
A configuração apresentada mostra três nós do HANA em cada site, além do nó do fabricante principal para evitar o cenário de dupla personalidade. As instruções podem ser adaptadas para incluir mais VMs como nós de banco de dados do HANA (BD).

Na arquitetura apresentada, você pode implantar o sistema /hana/shared de arquivos compartilhados do HANA usando o Azure NetApp Files ou o compartilhamento NFS nos Arquivos do Azure. Cada nó do HANA dentro do mesmo site de replicação do sistema HANA monta o sistema de arquivos compartilhados do HANA por meio do NFS. Os sistemas de arquivos /hana/data e /hana/log são sistemas de arquivos locais e não são compartilhados entre os nós do banco de dados HANA. Você instalará o SAP HANA no modo não compartilhado.

Para as configurações de armazenamento SAP HANA recomendadas, consulte Configurações de armazenamento de VMs do Azure no SAP HANA.

Importante

Se estiver implantando todos os sistemas de arquivos do HANA no Azure NetApp Files, para sistemas de produção, onde o desempenho é uma chave, recomendamos que você avalie e considere o uso do grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA.

Aviso

Não há suporte para a implantação de /hana/data e /hana/log no NFS em Arquivos do Azure.

Expansão do SAP HANA com HSR e cluster Pacemaker no SLES

No diagrama anterior, três sub-redes são representadas em uma rede virtual do Azure, seguindo as recomendações de rede do SAP HANA:

  • para comunicação com o cliente – client 10.23.0.0/24
  • para comunicação interna entre nós do HANA – inter 10.23.1.128/26
  • para replicação de sistema do HANA – hsr 10.23.1.192/26

Como /hana/data e /hana/log são implantados em discos locais, não é necessário implantar uma sub-rede separada e separar placas de rede virtuais para comunicação com o armazenamento.

Caso esteja usando o Azure NetApp Files, os volumes de NFS para /hana/shared serão implantados em uma sub-rede separada, delegada ao Azure NetApp Files: anf 10.23.1.0/26.

Preparar a infraestrutura

Nas instruções a seguir, supõe-se que você já tenha criado o grupo de recursos e a rede virtual do Azure com três sub-redes: client, intere hsr.

Implantar máquinas virtuais do Linux por meio do portal do Azure

  1. Implantar as VMs do Azure.

    Para a configuração apresentada neste documento, implante sete máquinas virtuais:

    • três máquinas virtuais para servir como nós de banco de BD do HANA para o site 1 da replicação do HANA: hana-s1-db1, hana-s1-db2 e hana-s1-db3
    • três máquinas virtuais para servir como nós de banco de BD do HANA para o site 2 da replicação do HANA: hana-s2-db1, hana-s2-db2 e hana-s2-db3
    • uma pequena máquina virtual para servir como o principal fabricante: hana-s-mm

Implante as VMs como nós do SAP DB usando tamanhos de VM certificados para SAP HANA, conforme listado em plataformas IaaS certificadas pelo SAP HANA. Verifique se a Rede Acelerada está habilitada ao implantar os nós do BD do HANA.

Para o nó do fabricante principal, você pode implantar uma VM pequena, pois essa VM não executa nenhum dos recursos de SAP HANA. A VM do fabricante principal é usada na configuração do cluster para obter um número ímpar de nós de cluster em um cenário de dupla personalidade. A VM do fabricante principal precisa apenas de uma interface de rede virtual na sub-rede client neste exemplo.

Implantar discos gerenciados locais para o /hana/data e o /hana/log. A configuração mínima de armazenamento recomendada para o /hana/data e o /hana/log é descrita em Configurações de armazenamento de VMs SAP HANA do Azure.

Implante a interface de rede primária para cada VM na sub-rede da rede virtual client.
Quando a VM é implantada via portal do Azure, o nome da interface de rede é gerado automaticamente. Nestas instruções para simplificar, vamos nos referir às interfaces de rede primárias, geradas automaticamente, que são anexadas à sub-rede da rede virtual do Azure client, como hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-Cliente assim por diante.

Importante

  • Certifique-se de que o sistema operacional que você selecionar tenha certificação SAP para o SAP HANA nos tipos de VM específicos que você está usando. Para obter uma lista de tipos de VMs certificadas do SAP HANA e das versões de sistemas operacionais para esses tipos, acesse o site de Plataformas de IaaS certificadas do SAP HANA. Clique nos detalhes do tipo de VM listado para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para esse tipo de VM.
  • Se você optar por implantar /hana/shared no NFS nos Arquivos do Azure, recomendamos que você implante no SUSE Linux Enterprise Server (SLES) 15 SP2 e posterior.
  1. Crie seis interfaces de rede, uma para cada máquina virtual do HANA DB, na sub-rede da rede virtual inter (neste exemplo, hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-intere hana-s2-db3-inter).

  2. Crie seis interfaces de rede, uma para cada máquina virtual do HANA DB, na sub-rede da rede virtual hsr (neste exemplo, hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsre hana-s2-db3-hsr).

  3. Anexe as interfaces da rede virtual recém-criadas às máquinas virtuais correspondentes:

    1. Acesse a máquina virtual no portal do Azure.
    2. No painel esquerdo, selecione Máquinas Virtuais. Filtre o nome da máquina virtual (por exemplo, hana-s1-db1) e, em seguida, escolha a máquina virtual.
    3. No painel Visão geral, escolha Parar para desalocar a máquina virtual.
    4. Escolha Rede e, em seguida, anexe a interface de rede. Na lista suspensa Anexar interface de rede, selecione as interfaces de rede já criadas para as sub-redes inter e hsr.
    5. Selecione Salvar.
    6. Repita as etapas B a E nas máquinas virtuais restantes (no exemplo: hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 e hana-s2-db3).
    7. Deixe as máquinas virtuais no estado parado por enquanto. Em seguida, vamos habilitar a rede acelerada para todas as interfaces de rede recém-anexadas.
  4. Habilite a rede acelerada para as interfaces de rede adicionais das sub-redes inter e hsr seguindo estas etapas:

    1. Abra o Azure Cloud Shell no portal do Azure.

    2. Execute os comandos a seguir para habilitar a rede acelerada para as interfaces de rede adicionais, que estão anexadas às sub-redes inter e hsr.

      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true
      
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true
      

      Observação

      Você não precisa instalar o pacote da CLI do Azure em seus nós do HANA para executar az o comando. Você pode executá-lo em qualquer computador que tenha a CLI instalada ou usar o Azure Cloud Shell.

  5. Iniciar as máquinas virtuais do BD HANA

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.

Observação

  • Para expansão do HANA, selecione o adaptador de rede para a sub-rede client ao adicionar as máquinas virtuais no pool de back-end.
  • O conjunto completo de comandos na CLI do Azure e no PowerShell adiciona as VMs com a interface de rede primária no pool de back-end.

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 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 investigação: insira 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. No momento, não é possível definir essa propriedade usando o portal do Azure, portanto, use o comando da CLI do Azure ou do PowerShell.

Observação

Quando VMs sem endereços IP públicos são colocadas no pool de back-end de um balanceador de carga interno (sem endereço IP público), não há conectividade de saída com a Internet, a menos que uma configuração adicional seja executada para habilitar o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como configurar a conectividade de saída, consulte conectividade de ponto de extremidade público para máquinas virtuais usando o Azure Standard 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 de TCP fará com que as investigações de integridade falhem. Defina o parâmetro net.ipv4.tcp_timestamps como 0. Para obter detalhes, confira Investigações de integridade do Load Balancer e observação do SAP 2382421.
  • Para evitar que o saptune altere o valor net.ipv4.tcp_timestamps definido manualmente de 0 para 1, atualize a versão do saptune para 3.1.1 ou superior. Para obter mais detalhes, confira Saptune 3.1.1 - Preciso atualizar?.

Implantar o NFS

Há duas opções para implantar o NFS nativo do Azure para /hana/shared. Você pode implantar o volume do NFS no Azure NetApp Files ou no compartilhamento NFS nos Arquivos do Azure. Os arquivos do Azure dão suporte ao protocolo NFSv4.1, os arquivos NFS no Azure NetApp dão suporte ao NFSv4.1 e NFSv3.

As próximas seções descrevem as etapas para implantar o NFS – você precisará selecionar apenas uma das opções.

Dica

Você optou por implantar /hana/shared no compartilhamento NFS nos Arquivos do Azure ou no volume NFS no Azure NetApp Files.

Implantar a infraestrutura do Azure NetApp Files

Implante volumes do Azure NetApp Files para o sistema de arquivos /hana/shared. Você precisa de um volume /hana/shared separado para cada site de replicação do sistema HANA. Para obter mais informações, confira Configurar a infraestrutura do Azure NetApp Files.

Neste exemplo, os seguintes volumes do Azure NetApp Files foram usados:

  • volume HN1-shared-s1 (nfs://10.23.1.7/ HN1-shared-s1)
  • volume HN1-shared-s2 (nfs://10.23.1.7/ HN1-shared-s2)

Implantar o NFS na infraestrutura dos Arquivos do Azure

Implante compartilhamentos NFS dos Arquivos do Azure para o sistema de arquivos /hana/shared. É necessário um compartilhamento NFS dos Arquivos do Azure /hana/shared separado para cada local de replicação do sistema HANA. Para obter mais informações, confira Como criar um compartilhamento NFS.

Neste exemplo, foram usados os seguintes compartilhamentos NFS dos Arquivos do Azure:

  • compartilhar hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
  • compartilhar hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Configuração e preparação do sistema operacional

As instruções das próximas seções têm como prefixo uma das seguintes abreviações:

  • [A]: aplicável a todos os nós, incluindo o fabricante principal
  • [AH]: aplicável a todos os nós de BD do HANA
  • [M]: aplicável somente ao nó do fabricante principal
  • [AH1]: aplicável a todos os nós de BD do HANA no SITE 1
  • [AH2]: aplicável a todos os nós de BD do HANA no SITE 2
  • [AH1]: aplicável somente ao nó de BD do HANA 1, SITE 1
  • [AH2]: aplicável somente ao nó de BD do HANA 1, SITE 2

Configure e prepare seu sistema operacional executando as seguintes etapas:

  1. [A] Mantenha os arquivos do host nas máquinas virtuais. Inclua entradas para todas as sub-redes. As entradas a seguir foram adicionadas a /etc/hosts neste exemplo.

    # Client subnet
    10.23.0.19      hana-s1-db1
    10.23.0.20      hana-s1-db2
    10.23.0.21      hana-s1-db3
    10.23.0.22      hana-s2-db1
    10.23.0.23      hana-s2-db2
    10.23.0.24      hana-s2-db3
    10.23.0.25      hana-s-mm    
    
    # Internode subnet
    10.23.1.132     hana-s1-db1-inter
    10.23.1.133     hana-s1-db2-inter
    10.23.1.134     hana-s1-db3-inter
    10.23.1.135     hana-s2-db1-inter
    10.23.1.136     hana-s2-db2-inter
    10.23.1.137     hana-s2-db3-inter
    
    # HSR subnet
    10.23.1.196     hana-s1-db1-hsr
    10.23.1.197     hana-s1-db2-hsr
    10.23.1.198     hana-s1-db3-hsr
    10.23.1.199     hana-s2-db1-hsr
    10.23.1.200     hana-s2-db2-hsr
    10.23.1.201     hana-s2-db3-hsr
    
  2. [A] Crie o arquivo de configuração /etc/sysctl.d/ms-az.conf com a Microsoft para as definições de configuração do Azure.

    vi /etc/sysctl.d/ms-az.conf
    
    # Add the following entries in the configuration file
    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 configurar 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, veja a nota do SAP 2382421.

  3. [AH] Preparar as VMs – aplique as configurações recomendadas de acordo com a nota SAP 2205917 para SUSE Linux Enterprise Server para aplicativos SAP.

Preparar os sistemas de arquivos

Você optou por implantar os diretórios compartilhados do SAP no compartilhamento NFS no volume Arquivos do Azure ou NFS no Azure NetApp Files.

Montar os sistemas de arquivos compartilhados (NFS do Azure NetApp Files)

Neste exemplo, os sistemas de arquivos compartilhados do HANA são implantados no Azure NetApp Files e montados via NFSv4.1. Siga as etapas desta seção somente se estiver usando NFS no Azure NetApp Files.

  1. [AH] Prepare o sistema operacional para executar o SAP HANA nos sistemas NetApp com o NFS, conforme descrito na nota do SAP 3024346 – Configurações do kernel do Linux para NetApp com o NFS. Crie o arquivo de configuração /etc/sysctl.d/91-NetApp-HANA.conf para as definições de configuração do NetApp.

    vi /etc/sysctl.d/91-NetApp-HANA.conf
    
    # Add the following entries in the configuration file
    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
    
  2. [AH] Ajuste as configurações de sunrpc, conforme recomendado na nota do SAP 3024346 – Configurações do kernel do Linux para NetApp com o NFS.

    vi /etc/modprobe.d/sunrpc.conf
    
    # Insert the following line
    options sunrpc tcp_max_slot_table_entries=128
    
  3. [AH] Crie pontos de montagem para os volumes de banco de dados do HANA.

    mkdir -p /hana/shared
    
  4. [AH] 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 está definido como nobody.
    Esta etapa só é necessária se você estiver usando o Azure NetAppFiles NFSv4.1.

    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 NFS (ou seja, a VM) e o servidor NFS, ou seja, a configuração da Azure NetApp, as permissões para arquivos nos volumes do Azure NetApp que forem montados nas VMs serão exibidas como nobody.

    sudo cat /etc/idmapd.conf
    # Example
    [General]
    Domain = defaultv4iddomain.com
    [Mapping]
    Nobody-User = nobody
    Nobody-Group = nobody
    
  5. [AH] 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 mount. Você não poderá criar o diretório manualmente em /sys/modules, pois o acesso é reservado para o kernel e os drivers.
    Esta etapa só é necessária se você estiver usando o Azure NetAppFiles NFSv4.1.

    # Check nfs4_disable_idmapping 
    cat /sys/module/nfs/parameters/nfs4_disable_idmapping
    # If you need to set nfs4_disable_idmapping to Y
    mkdir /mnt/tmp
    mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
    umount  /mnt/tmp
    echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
    # Make the configuration permanent
    echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    
  6. [AH1] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE1 HANA DB.

    sudo vi /etc/fstab
    # Add the following entry
    10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    # Mount all volumes
    sudo mount -a 
    
  7. [AH2] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE2 HANA DB.

    sudo vi /etc/fstab
    # Add the following entry
    10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    # Mount the volume
    sudo mount -a 
    
  8. [AH] Verifique se os sistemas de arquivos /hana/shared/ correspondentes estão montados em todas as VMs do BD HANA com o protocolo NFS versão NFSv4.1.

    sudo nfsstat -m
    # Verify that flag vers is set to 4.1 
    # Example from SITE 1, hana-s1-db1
    /hana/shared from 10.23.1.7:/HN1-shared-s1
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
    # Example from SITE 2, hana-s2-db1
    /hana/shared from 10.23.1.7:/HN1-shared-s2
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7
    

Montar os sistemas de arquivos compartilhados (NFS dos Arquivos do Azure)

Neste exemplo, os sistemas de arquivos compartilhados do HANA são implantados no NFS nos Arquivos do Azure. Siga as etapas desta seção apenas se estiver usando NFS no Arquivos do Azure.

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

    mkdir -p /hana/shared
    
  2. [AH1] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE1 HANA DB.

    sudo vi /etc/fstab
    # Add the following entry
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
    # Mount all volumes
    sudo mount -a 
    
  3. [AH2] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE2 HANA DB.

    sudo vi /etc/fstab
    # Add the following entries
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
    # Mount the volume
    sudo mount -a 
    
  4. [AH] Verifique se os sistemas de arquivos /hana/shared/ correspondentes estão montados em todas as VMs do BD HANA com o protocolo NFS versão NFSv4.1.

    sudo nfsstat -m
    # Example from SITE 1, hana-s1-db1
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
     Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
    # Example from SITE 2, hana-s2-db1
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
     Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35
    

Preparar os dados e registrar em log os sistemas de arquivos locais

Na configuração apresentada, os sistemas de arquivos /hana/data e /hana/log são implantados no disco gerenciado e são anexados localmente a cada VM do HANA DB. Você precisa executar as etapas para criar os volumes de dados e logs locais em cada máquina virtual do BD HANA.

Configure o layout do disco com o LVM (gerenciador de volumes lógicos) . O exemplo a seguir supõe que cada máquina virtual HANA tem três discos de dados anexados, que são usados para criar dois volumes.

  1. [AH] Liste todos os discos disponíveis:

    ls /dev/disk/azure/scsi1/lun*
    

    Saída de exemplo:

    /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2 
    
  2. [AH] Crie volumes físicos para todos os discos que você deseja usar:

    sudo pvcreate /dev/disk/azure/scsi1/lun0
    sudo pvcreate /dev/disk/azure/scsi1/lun1
    sudo pvcreate /dev/disk/azure/scsi1/lun2
    
  3. [AH] Crie um grupo de volumes para os arquivos de dados. Use um grupo de volumes para os arquivos de log e outro para o diretório compartilhado do SAP HANA:\

    sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
    sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
    
  4. [AH] Crie os volumes lógicos.

    Um volume linear é criado quando você usa lvcreate sem a opção -i. Sugerimos que você crie um volume distribuído para melhorar o desempenho de E/S e alinhe os tamanhos de distribuição aos valores documentados em Configurações de armazenamento de VM do SAP HANA. O argumento -i deve ser o número de volumes físicos subjacentes e o argumento -I é o tamanho da distribuição. Neste documento, dois volumes físicos são usados para o volume de dados, portanto, o argumento da chave -i é definido com 2. O tamanho da distribuição para o volume de dados é de 256 KiB. Um volume físico é usado para o volume do log, portanto, nenhuma opção -i ou -I é usada explicitamente para os comandos do volume do log.

    Importante

    Use a opção -i e defina-a para o número do volume físico subjacente quando você usar mais de um volume físico para cada volume de dados ou do log. Use a opção -I para especificar o tamanho da distribuição, quando criar um volume distribuído.
    Veja Configurações de armazenamento de VM do SAP HANA para ver as configurações de armazenamento recomendadas, incluindo tamanhos de distribuição e número de discos.

    sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
    sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
    sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
    sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
    
  5. [AH] Crie os diretórios de montagem e copie o UUID de todos os volumes lógicos:

    sudo mkdir -p /hana/data/HN1
    sudo mkdir -p /hana/log/HN1
    # Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
    sudo blkid
    
  6. [AH] Crie as entradas fstab para os volumes lógicos e monte:

    sudo vi /etc/fstab
    

    Insira a seguinte linha no arquivo /etc/fstab:

    /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
    /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2
    

    Monte os novos volumes:

    sudo mount -a
    

Criar um cluster do Pacemaker

Siga as etapas em Configurar Pacemaker no SUSE Linux Enterprise Server no Azure para criar um cluster Pacemaker básico para esse servidor HANA. Inclua todas as máquinas virtuais, incluindo o fabricante principal no cluster.

Para um cluster de expansão, verifique se os seguintes parâmetros estão definidos corretamente:

  • Não defina quorum expected-votes como 2, pois este não é um cluster de dois nós.
  • Verifique se a propriedade concurrent-fencing=true do cluster está definida, de modo que a isolamento de nó seja desserializada.
  • O recurso stonith-sbd deve incluir parâmetro pcmk_action_limit=-1 com valor negativo 1 (ilimitado) para permitir ações de stonith desserializadas.

Instalação

Neste exemplo, para implantar o SAP HANA na configuração de expansão com HSR em VMs do Azure, usamos o HANA 2.0 SP5.

Preparar para a instalação do HANA

  1. [AH] Antes da instalação do HANA, defina a senha raiz. Você pode desabilitar a senha raiz após a conclusão da instalação. Execute como root o comando passwd.

  2. [1,2] Mudar as permissões em /hana/shared

    chmod 775 /hana/shared
    
  3. [1] Verifique se você pode fazer logon via SSH para as VMs do HANA DB neste site hana-s1-db2 e hana-s1-db3, sem ser solicitado a fornecer uma senha. Se esse não for o caso, troque as chaves SSH conforme descrito em Habilitar acesso SSH via chave pública.

    ssh root@hana-s1-db2
    ssh root@hana-s1-db3
    
  4. [2] Verifique se você pode fazer logon via SSH para as VMs do HANA DB neste site hana-s2-db2 e hana-s2-db3, sem ser solicitado a fornecer uma senha.
    Se esse não for o caso, troque as chaves SSH.

    ssh root@hana-s2-db2
    ssh root@hana-s2-db3
    
  5. [AH] Instale pacotes adicionais, que são necessários para o HANA 2.0 SP4 e posterior. Para obter mais informações, confira a Nota do SAP 2593824 para sua versão do SLES.

    # In this example, using SLES12 SP5
    sudo zypper install libgcc_s1 libstdc++6 libatomic1
    

Instalação do HANA no primeiro nó de cada site

  1. [1] Instale o SAP HANA seguindo as instruções no Guia de instalação e atualização do SAP HANA 2.0. Nas instruções a seguir, mostramos a instalação do SAP HANA no primeiro nó do SITE 1.

    um. Inicie o programa hdblcm como root do diretório de software de instalação do HANA. Use o parâmetro internal_network e passe o espaço de endereço para a sub-rede que é usada para a comunicação interna entre nós do HANA.

    ./hdblcm --internal_network=10.23.1.128/26
    

    b. No prompt, insira os valores a seguir:

    • Em Escolher uma ação: insira 1 (para instalar)
    • Em Componentes adicionais para a instalação: insira 2, 3
    • Em caminho de instalação: pressione Enter (o padrão é /hana/shared)
    • Em Nome do Host Local: pressione Enter para aceitar o padrão
    • Em Você deseja adicionar outros hosts ao sistema? : insira n
    • Em ID do sistema do SAP HANA: insira HN1
    • Em Número de instância [00]: insira 03
    • Em Grupo de Trabalho do Host Local [padrão]: pressione Enter para aceitar o padrão
    • Em Selecionar Uso do Sistema / Inserir Índice [4] : insira 4 (personalizado)
    • Em Local dos Volumes de Dados [/hana/data/HN1]: pressione Enter para aceitar o padrão
    • Em Local dos Volumes do Log [/hana/log/HN1]: pressione Enter para aceitar o padrão
    • Para restringir a alocação máxima de memória? [n]: insira n
    • Em Nome do Host do Certificado Para o Host hana-s1-db1 [hana-s1-db1]: pressione Enter para aceitar o padrão
    • Em Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
    • Em Confirmar a Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
    • Em Senha do Administrador do Sistema (hn1adm) : insira a senha
    • Em Diretório Base do Administrador do Sistema [/usr/SAP/HN1/Home]: pressione ENTER para aceitar o padrão
    • Em Shell de Logon do Administrador do Sistema [/bin/sh]: pressione ENTER para aceitar o padrão
    • Em ID de Usuário do Administrador do Sistema [1001]: pressione ENTER para aceitar o padrão
    • Em Inserir ID do Grupo de Usuários (sapsys) [79]: pressione ENTER para aceitar o padrão
    • Em Senha do Usuário do Banco de Dados do Sistema (sistema) : insira a senha do sistema
    • Em Confirmar Senha do Usuário do Banco de Dados do Sistema (sistema) : insira a senha do sistema
    • Para Reiniciar sistema após a reinicialização do computador? [n]: insira n
    • Em Você deseja continuar (s/n) : valide o resumo e, se tudo estiver correto, digite y
  2. [2] Repita a etapa anterior para instalar o SAP HANA no primeiro nó no SITE 2.

  3. [1,2] Verifique o global.ini

    Abra o global.ini e verifique se a configuração da comunicação interna entre nós do SAP HANA está funcionando. Verifique a seção Comunicação. Ele deve ter o espaço de endereço para a sub-rede inter e listeninterface deve ser definido como .internal. Verifique a seção internal_hostname_resolution. Ele deve ter os endereços IP para as máquinas virtuais HANA que pertencem à sub-rede inter.

      sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
      # Example from SITE1 
      [communication]
      internal_network = 10.23.1.128/26
      listeninterface = .internal
      [internal_hostname_resolution]
      10.23.1.132 = hana-s1-db1
      10.23.1.133 = hana-s1-db2
      10.23.1.134 = hana-s1-db3
    
  4. [1, 2] Prepare-se global.ini para a instalação em um ambiente não compartilhado, conforme descrito na nota SAP 2080991.

     sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
     [persistence]
     basepath_shared = no
    
  5. [1,2] Reinicie o SAP HANA para ativar as alterações.

     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem
    
  6. [1,2] Verifique se a interface do cliente usará os endereços IP da sub-rede client para comunicação.

    # Execute as hn1adm
    /usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
    # Expected result - example from SITE 2
    "hana-s2-db1","net_publicname","10.23.0.22"
    

    Para obter informações sobre como verificar a configuração, consulte a Nota SAP 2183363 – Configuração da rede interna do SAP HANA.

  7. [AH] Altere as permissões nos diretórios de dados e de log para evitar o erro de instalação do HANA.

     sudo chmod o+w -R /hana/data /hana/log
    
  8. [1] Instale os nós do HANA secundários. As instruções de exemplo nesta etapa são para o SITE 1.

    um. Inicie o programa hdblcm residente como root.

     cd /hana/shared/HN1/hdblcm
     ./hdblcm 
    

    b. No prompt, insira os valores a seguir:

    • Em Escolher uma ação: insira 2 (para adicionar hosts)
    • Em Inserir nomes de host separados por vírgula para adicionar: hana-s1-db2, hana-s1-db3
    • Em Componentes adicionais para a instalação: insira 2, 3
    • Em Inserir Nome do Usuário Raiz [root] : pressione Enter para aceitar o padrão
    • Em Selecionar funções para o host 'hana-s1-db2' [1] : 1 (para o trabalho)
    • Em Inserir Grupo de Failover para o host 'hana-s1-db2' [padrão] : pressione Enter para aceitar o padrão
    • Em Inserir o número da partição de armazenamento do host 'hana-s1-db2' [<<atribuir automaticamente>>], pressione Enter para aceitar o padrão
    • Em Inserir Grupo de Trabalho para o host 'hana-s1-db2' [padrão] : pressione Enter para aceitar o padrão
    • Em Selecionar funções para o host 'hana-s1-db3' [1] : 1 (para o trabalho)
    • Em Inserir Grupo de Failover para o host 'hana-s1-db3' [padrão] : pressione Enter para aceitar o padrão
    • Em Inserir o Número de Partição de Armazenamento do host 'hana-s1-db3' [<<atribuir automaticamente>>], pressione Enter para aceitar o padrão
    • Em Inserir Grupo de Trabalho para o host 'hana-s1-db3' [padrão] : pressione Enter para aceitar o padrão
    • Em Senha do Administrador do Sistema (hn1adm) : insira a senha
    • Em Inserir Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
    • Em Confirmar a Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
    • Em Nome do Host do Certificado Para o Host hana-s1-db2 [hana-s1-db2]: pressione Enter para aceitar o padrão
    • Em Nome do Host do Certificado Para o Host hana-s1-db3 [hana-s1-db3]: pressione Enter para aceitar o padrão
    • Em Você deseja continuar (s/n) : valide o resumo e, se tudo estiver correto, digite y
  9. [2] Repita a etapa anterior para instalar os nós de SAP HANA secundários no SITE 2.

Configurar a replicação do Sistema SAP HANA 2.0

  1. [1] Configurar a Replicação do Sistema no SITE 1:

    Faça backup dos bancos de dados como hn1adm:

    hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
    hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
    

    Copie os arquivos de chave de armazenamento seguro do sistema para o site secundário:

    scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
    scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
    

    Crie o site primário:

    hdbnsutil -sr_enable --name=HANA_S1
    
  2. [2] Configurar a Replicação do Sistema no SITE 2:

    Registre o segundo site para iniciar a replicação do sistema. Execute o seguinte comando como <hanasid>adm:

    sapcontrol -nr 03 -function StopWait 600 10
    hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
    sapcontrol -nr 03 -function StartSystem
    
  3. [1] Verificar status de replicação

    Verifique o status de replicação e aguarde até que todos os bancos de dados estão em sincronizado.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
    # | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
    # |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
    # | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
    # | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #
    # status system replication site "2": ACTIVE
    # overall system replication status: ACTIVE
    #
    # Local System Replication State
    #
    # mode: PRIMARY
    # site id: 1
    # site name: HANA_S1
    
  4. [1,2] Altere a configuração do HANA para que a comunicação para a replicação do sistema HANA seja direcionada por meio dos adaptadores de rede virtual de replicação do sistema HANA.

    • Parar o HANA em ambos os sites

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
      
    • Editar o global.ini para adicionar o mapeamento de host para replicação de sistema do HANA: use os endereços IP da sub-rede hsr.

      sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
      #Add the section
      [system_replication_hostname_resolution]
      10.23.1.196 = hana-s1-db1
      10.23.1.197 = hana-s1-db2
      10.23.1.198 = hana-s1-db3
      10.23.1.199 = hana-s2-db1
      10.23.1.200 = hana-s2-db2
      10.23.1.201 = hana-s2-db3
      
    • Parar o HANA em ambos os sites

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
      

    Para obter mais informações, confira Resolução de nome do host para replicação do sistema.

Implementar agentes de recursos do HANA

O SUSE fornece dois pacotes de software diferentes para o agente de recursos do Pacemaker gerenciar o SAP HANA. Pacotes de software SAPHanaSR-ScaleOut e SAPHanaSR-angi estão usando sintaxe e parâmetros ligeiramente diferentes e não são compatíveis. Consulte as notas de versão do SUSE e a documentação para obter detalhes e diferenças entre SAPHanaSR-angi e SAPHanaSR-ScaleOut. Esse documento aborda os dois pacotes em guias separadas nas respectivas seções.

Aviso

Não substitua o pacote SAPHanaSR-ScaleOut pelo SAPHanaSR-angi em um cluster já configurado. O upgrade do SAPHanaSR para o SAPHanaSR-angi requer um procedimento específico. Para obter mais detalhes, consulte a postagem no blog do SUSE Como atualizar para o SAPHanaSR-angi.

  • [A] Instale os pacotes de alta disponibilidade do SAP HANA:

Observação

O SAPHanaSR-angi tem um requisito mínimo de versão do SAP HANA 2.0 SPS 05 e SUSE SLES para Aplicativos SAP 15 SP4 ou superior.

Execute o seguinte comando em todas as VMs de cluster, incluindo o criador majoritário para instalar os pacotes de alta disponibilidade:

sudo zypper install SAPHanaSR-angi
sudo zypper in -t pattern ha_sles

Configurar provedores de HA/DR do SAP HANA

Os provedores de HA/DR do SAP HANA otimizam a integração com o cluster e aprimoram a detecção quando um failover do cluster é necessário. O script de gancho principal é susHanaSR (para SAPHanaSR-angi) ou SAPHanaSrMultiTarget (para o pacote SAPHanaSR-ScaleOut). É obrigatório para a integração de clusters que você configure o hook do Python susHanaSR/SAPHanaSrMultiTarget. Para o HANA 2.0 SPS 05 e posterior, recomendamos implementar os ganchos susHanaSR/SAPHanaSrMultiTarget e susChkSrv.

O gancho susChkSrv estende a funcionalidade do principal provedor de HA susHanaSR/SAPHanaSrMultiTarget. Ele atua quando o processo do HANA hdbindexserver falha. Se apenas um processo falha, normalmente o HANA tenta reiniciá-lo. Reiniciar o processo indexserver pode levar muito tempo, durante o qual o banco de dados do HANA não responde.

Com o susChkSrv implementado, uma ação imediata e configurável é executada. A ação dispara um failover durante o período de tempo limite configurado em vez de aguardar que o processo hdbindexserver seja reiniciado no mesmo nó. No expansão do HANA, susChkSrv atua para cada nó de cluster executando o HANA de forma independente. A ação configurada elimina o HANA ou isola a VM afetada, o que dispara um failover no período de timeout configurado.

  1. [1,2] Interrompa o HANA em ambos os sites de replicação do sistema. Execute como <sid>adm:

    sapcontrol -nr 03 -function StopSystem
    
  2. [1,2] Instale os ganchos do provedor de HA do HANA. Os ganchos devem ser instalados em ambos os sites de banco de dados do HANA.

    1. [1,2] Ajuste global.ini em cada site do cluster. Se os pré-requisitos para o gancho susChkSrv não forem atendidos, o bloco [ha_dr_provider_suschksrv] inteiro não deverá ser configurado.
      Você pode ajustar o comportamento de susChkSrv com o parâmetro action_on_lost. Os valores válidos são [ ignore | stop | kill | fence ].

      # add to global.ini on both sites. Do not copy global.ini between sites.
      [ha_dr_provider_sushanasr]
      provider = susHanaSR
      path = /usr/share/SAPHanaSR-angi
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR-angi
      execution_order = 3
      action_on_lost = kill
      
      [trace]
      ha_dr_sushanasr = info
      ha_dr_suschksrv = info
      

      O SUSE fornece os ganchos de HA por padrão no /usr/share/SAPHanaSR-angi diretório. Usar a localização padrão garante que as atualizações dos pacotes do sistema operacional atualizem automaticamente o código de gancho do Python, e o HANA utilize o código atualizado na próxima reinicialização. Como alternativa, você pode especificar seu próprio caminho, como /hana/shared/myHooks, para desacoplar as atualizações do sistema operacional da versão do gancho que você usa.

    2. [AH] O cluster requer configuração de sudoers nos nós de cluster para <sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo. Execute o seguinte comando como root. Substitua o <sid> pela ID do sistema SAP em minúsculas, o <SID> pela ID do sistema SAP em maiúsculas e <siteA/B> pelos nomes de site do HANA escolhidos.

      cat << EOF > /etc/sudoers.d/20-saphana
      # SAPHanaSR-angi requirements for HA/DR hook scripts
      Cmnd_Alias SOK_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER  = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE     = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      

      Para obter detalhes sobre como implementar o gancho de replicação do sistema SAP HANA, consulte Configurar provedores de HA/DR do HANA.


  1. [1,2] Iniciar o SAP HANA em ambos os sites de replicação. Execute como <sid>adm.
sapcontrol -nr 03 -function StartSystem 
  1. [1] Verifique a instalação do gancho. Execute o seguinte comando como um <sap-sid>adm no site de replicação do sistema HANA ativo:
cdtrace    
grep HADR.*load.*susHanaSR nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140145]{-1}[-1/-1] 2025-05-26 07:51:34.677221 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
grep susHanaSR.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140157]{-1}[-1/-1] 2025-05-26 07:51:34.724422 i ha_dr_susHanaSR  susHanaSR.py(00042) : susHanaSR.init() version 1.001.1
  1. [AH] Verifique a instalação do gancho susChkSrv. Execute o seguinte comando como <sap-sid>adm em qualquer nó do HANA:
cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Crie os recursos de cluster do SAP HANA

  1. [1] Criar o recurso de Topologia do HANA. Verifique se o cluster está no modo de manutenção.
sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<SID>_HDB<InstNum> ocf:suse:SAPHanaTopology \
  op monitor interval="50" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<SID>" InstanceNumber="<InstNum>"

sudo crm configure clone cln_SAPHanaTopology_<SID>_HDB<InstNum> rsc_SAPHanaTopology_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true"
  1. [1] Em seguida, crie o recurso de instância do HANA.
# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaController_<SID>_HDB<InstNum> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="900" \
  op demote interval="0" timeout="320" \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<SID>" InstanceNumber="<InstNum>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  HANA_CALL_TIMEOUT="120"

sudo crm configure clone mst_SAPHanaController_<SID>_HDB<InstNum> rsc_SAPHanaController_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true" promotable="true"

Importante

Como uma prática recomendada, sugerimos que você só defina AUTOMATED_REGISTER como no, enquanto executa testes de failover completos, para evitar que a instância primária com falha seja registrada automaticamente como secundária. Depois que os testes de failover forem concluídos com êxito, defina AUTOMATED_REGISTER como sim, para que, após o processo de tomada de controle, a replicação do sistema possa ser retomada automaticamente.

  1. [1] Criar agentes de recursos do sistema de arquivos para /hana/shared

O SAPHanaSR-angi adiciona um novo agente de recursos sapHanaFilesystem para monitorar o acesso de leitura/gravação ao /hana/shared/SID. O sistema operacional estático monta o sistema de arquivos /hana/shared/SID com cada host tendo entradas em /etc/fstab. O SAPHanaFilesystem e o Pacemaker não montam o sistema de arquivos para o HANA.

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<SID>" InstanceNumber="<InstNum>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFilesystem_<SID>_HDB<InstNum> rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true"

# Add a location constraint to not run filesystem check on majority maker VM
sudo crm configure location loc_SAPHanaFilesystem_not_on_majority_maker cln_SAPHanaFilesystem_<SID>_HDB<InstNum> -inf: hana-s-mm
  1. [1] Continue com recursos de cluster para IPs virtuais e restrições.
# Replace <placeholders> with your instance number and HANA system ID, and respective IP address and load balancer port  

sudo crm configure primitive rsc_ip_<SID>_HDB<InstNum> ocf:heartbeat:IPaddr2 \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"
  
sudo crm configure primitive rsc_nc_<SID>_HDB<InstNum> azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0
  
sudo crm configure group g_ip_<SID>_HDB<InstNum> rsc_ip_<SID>_HDB<InstNum> rsc_nc_<SID>_HDB<InstNum>

Criar as restrições de cluster

# Colocate the IP with primary HANA node
sudo crm configure colocation col_saphana_ip_<SID>_HDB<InstNum> 4000: g_ip_<SID>_HDB<InstNum>:Started \
  mst_SAPHanaController_<SID>_HDB<InstNum>:Promoted  
  
# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_<SID>_HDB<InstNum> Optional: cln_SAPHanaTopology_<SID>_HDB<InstNum> \
  mst_SAPHanaController_<SID>_HDB<InstNum>
  
# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaController_not_on_majority_maker mst_SAPHanaController_<SID>_HDB<InstNum> -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTopology_not_on_majority_maker cln_SAPHanaTopology_<SID>_HDB<InstNum> -inf: hana-s-mm
  1. [1] Configure propriedades de cluster adicionais
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50
  1. [1] Retire o cluster do modo de manutenção. Certifique-se de que o status do cluster está correto e que todos os recursos foram iniciados.
# Cleanup any failed resources - the following command is example 
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false
  1. [1] Verifique a comunicação entre o gancho de HA do HANA e o cluster, mostrando o status SOK para o SID e os sites de replicação com status P(rimary) ou S(econdary).
sudo SAPHanaSR-showAttr
Global cib-update dcid prim       sec        sid topology
----------------------------------------------------------
global 0.165361.0 7    HANA_S2 HANA_S1    HN1 ScaleOut

Resource                        promotable
-------------------------------------------
msl_SAPHanaController_HN1_HDB03 true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns     opMode    srHook srMode srPoll srr
----------------------------------------------------------------------
HANA_S2  1748611494 4   hana-s2-db1 logreplay PRIM   sync   PRIM   P
HANA_S1  10         4   hana-s1-db1 logreplay SOK    sync   SFAIL  S

Host     clone_state roles                        score  site       srah version     vhost
----------------------------------------------------------------------------------------------
hana-s1-db1  DEMOTED     master1:master:worker:master 100    HANA_S1 -    2.00.074.00 hana-s1-db1
hana-s1-db2  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db2
hana-s1-db3  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db3
hana-s2-db1  PROMOTED    master1:master:worker:master 150    HANA_S2 -    2.00.074.00 hana-s2-db1
hana-s2-db2  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db2
hana-s2-db3  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db3
hana-mm                                                                               hana-mm

Observação

Os tempos limite na configuração acima são apenas exemplos e devem ser adaptados à configuração específica do HANA. Por exemplo, talvez seja necessário aumentar o tempo limite de início, se o banco de dados do SAP HANA demorar mais para iniciar. O SAPHanaSR-angi permite mais opções para uma ação mais rápida durante um evento de cluster. Consulte a documentação do SUSE para obter detalhes sobre o parâmetro ON_FAIL_ACTION do SAPHanaController, o agente opcional SAPHanaSR-alert-fencing e outras opções. A implementação deve ser seguida por testes de cluster extensivos adicionais em seu ambiente.

Testar failover do SAP HANA

Observação

Esse artigo contém referências a termos que a Microsoft não utiliza mais. Quando esses termos forem removidos do software, nós os removeremos deste artigo.

  1. Antes de iniciar um teste, verifique o cluster e o status de replicação do sistema SAP HANA.

    um. Verifique se não há nenhuma ação de cluster com falha

    #Verify that there are no failed cluster actions
    crm status
    # Example 
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Full list of resources:
    #
    # stonith-sbd    (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s1-db1 ]
    #     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1
    

    b. Verifique se a replicação do sistema SAP HANA está sincronizada

    # Verify HANA HSR is in sync
    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    #| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
    #|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
    #| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
    #| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #
    #status system replication site "1": ACTIVE
    #overall system replication status: ACTIVE
    #
    #Local System Replication State
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #
    #mode: PRIMARY
    #site id: 1
    #site name: HANA_S1
    
  2. Recomendamos validar completamente a configuração de cluster SAP HANA, executando os testes documentados em Alta disponibilidade para SAP HANA em VMs do Azure no SLES e no Cenário otimizado de desempenho de expansão da replicação do SLES.

  3. 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 do SAP HANA dependem de binários, armazenados em /hana/shared para executar operações durante o failover. O sistema de arquivos /hana/shared é montado em NFS na configuração apresentada. Um teste executável é criar uma regra de firewall temporária para bloquear o acesso ao sistema de arquivos montado com NFS /hana/shared em uma das VMs do site primário. Esse método valida se o cluster fará o failover, caso o acesso a /hana/shared for perdido no site de replicação do sistema ativo.

    Resultado esperado: quando você bloqueia o acesso ao /hana/shared sistema de arquivos montado do NFS em uma das VMs do site primário, a operação de monitoramento que executa a operação de leitura/gravação no sistema de arquivos falhará, pois não poderá acessar o sistema de arquivos e disparará o failover de recursos do HANA. O mesmo resultado é esperado quando o nó do HANA perde o acesso ao compartilhamento NFS.

    Você pode verificar o estado dos recursos de cluster executando crm_mon ou crm status. Estado do recurso antes de iniciar o teste:

    # Output of crm_mon
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Active resources:
    #
    #stonith-sbd     (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s1-db1 ]
    #     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
    

    Para simular falha para /hana/shared:

    • Se estiver usando o NFS no Azure NetApp Files, primeiro confirme o endereço IP do volume /hana/shared do Azure NetApp Files no site primário. Você pode fazer ao executar df -kh|grep /hana/shared.
    • Se estiver usando o NFS nos Arquivos do Azure, primeiro determine o endereço IP do ponto de extremidade privado para a sua conta de armazenamento.

    Em seguida, configure uma regra de firewall temporária para bloquear o acesso ao endereço IP do sistema de arquivos NFS /hana/shared executando o comando a seguir em uma das VMs do site primário de replicação do sistema HANA.

    Neste exemplo, o comando foi executado no hana-s1-db1 para o volume /hana/shared do Azure NetApp Files.

    iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
    

    Os recursos de cluster são migrados para outro site de replicação do sistema do HANA.

    Se você definir AUTOMATED_REGISTER="false", será necessário configurar a replicação do sistema SAP HANA no site secundário após a aquisição. Nesse caso, você pode executar esses comandos para reconfigurar o SAP HANA como secundário.

    # Execute on the secondary 
    su - hn1adm
    # Make sure HANA is not running on the secondary site. If it is started, stop HANA
    sapcontrol -nr 03 -function StopWait 600 10
    # Register the HANA secondary site
    hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
    # Switch back to root and cleanup failed resources
    crm resource cleanup SAPHana_HN1_HDB03
    

    O estado dos recursos, após o teste:

    # Output of crm_mon
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Active resources:
    #
    #stonith-sbd     (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s2-db1 ]
    #     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
    

Próximas etapas