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

  • Artigo

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 BD do HANA.

O sistema de arquivos compartilhados HANA /hana/shared na arquitetura apresentada pode ser fornecido pelo Azure NetApp Files ou pelo compartilhamento NFS nos Arquivos do Azure. O sistema de arquivos compartilhados do HANA é montado com NFS em cada nó do HANA no mesmo local de replicação do sistema HANA. Sistemas de arquivos /hana/data e /hana/log são locais e não são compartilhados entre os nós de BD do HANA. O SAP HANA será instalado 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, em que o desempenho é uma chave, é recomendável avaliar e considerar 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 nos Arquivos do Azure.

SAP HANA scale-out with HSR and Pacemaker cluster on 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, presumimos que você já criou o grupo de recursos, a rede virtual do Azure com três sub-redes da rede do Azure: clientinter e 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

    As VMs, implantadas como nós do SAP BD HANA, devem ser certificadas pelo SAP para HANA, conforme publicado no diretório de Hardware SAP HANA. Ao implantar os nós de BD do HANA, verifique se a Rede acelerada está escolhida.

    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.
    • Caso opte por implantar /hana/shared no NFS nos Arquivos do Azure, é recomendável implantar no SLES 15 SP2 e superior.

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

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

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

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

  6. 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 a NIC 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 NIC 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 instalação do balanceador de carga, considere os pontos a seguir:

  1. Configuração de IP de front-end: criar um IP de front-end. Selecione a mesma rede virtual e o nome de sub-rede que as 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 esta opção.
    • Protocolo: selecione TCP.
    • Investigação de integridade: crie uma investigação de integridade com as seguintes informações:
      • Protocolo: selecione TCP.
      • Porta: por exemplo, 625<sem-instância.>.
      • Intervalo: insira 5.
      • Limite de investigação: insira 2.
    • Tempo limite ocioso (minutos): insira 30.
    • Habilitar IP flutuante: selecione esta opção.

Observação

A propriedade numberOfProbes da configuração de investigação de integridade, também conhecida como Limite não íntegro no portal, não é respeitada. Para controlar o número de investigações consecutivas bem-sucedidas ou com falha, defina a propriedade probeThreshold como 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.

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. Confira Limitações do Azure Load Balancer para mais detalhes. Se você precisar de um endereço IP adicional para a VM, implante um segundo adaptador de rede.

Observação

Quando as VMs sem endereços IP públicos forem colocadas no pool de back-end do Standard Azure Load Balancer (sem endereço IP público), não haverá nenhuma conectividade de saída com a Internet se não houver configuração adicional a fim de permitir o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como alcançar conectividade de saída, confira 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 subjacentemente 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; o NFS no Azure NetApp Files dá suporte a 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 os volumes ANF para o sistema de arquivos /hana/shared. É necessário 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:

  • share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
  • share 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. [A] SUSE entrega agentes de recurso especiais para SAP HANA e, por padrão, agentes para dimensionamento vertical do SAP HANA são instalados. Desinstale os pacotes para dimensionamento vertical, se instalados, e instale os pacotes para o cenário de expansão do SAP HANA. A etapa precisa ser executada em todas as VMs do cluster, incluindo o criador majoritário.

    Observação

    O SAPHanaSR-ScaleOut versão 0.181 ou superior deve ser instalado.

    # Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles

  4. [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 nesta seção somente se estiver usando o 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 nesta seção somente se estiver usando o NFS nos 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. É necessário executar as etapas para criar os volumes de dados e de log locais em cada máquina virtual do HANA DB.

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.

Importante

Não defina quorum expected-votes como 2, pois esse não é um cluster de dois nós.
Verifique se a propriedade de cluster concurrent-fencing está habilitada, para que o isolamento de nó não seja desserializado.

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 os pacotes adicionais que são necessários para o HANA 2.0 SP4 e superiores. 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.

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

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

Criar os recursos do sistema de arquivos

Crie um recurso de cluster de sistema de arquivos fictício, que monitorará e relatará falhas, caso haja um problema ao acessar o sistema de arquivos montado em NFS /hana/shared. Isso permite que o cluster acione o failover, caso haja um problema ao acessar /hana/shared. Para obter mais detalhes, confira Falha no tratamento do compartilhamento de NFS no cluster de alta disponibilidade do SUSE para replicação do sistema HANA

  1. [1] Coloque pacemaker no modo de manutenção, em preparo para a criação dos recursos de cluster do HANA.

    crm configure property maintenance-mode=true

  2. [1, 2] Crie o diretório no sistema de arquivos/hana/compartilhado montado com NFS, que será usado no recurso especial de monitoramento do sistema de arquivos. Os diretórios precisam ser criados em ambos os sites.

    mkdir -p /hana/shared/HN1/check

  3. [AH] Crie o diretório que será usado para montar o recurso especial de monitoramento do sistema de arquivos. O diretório precisa ser criado em todos os nós de cluster HANA.

    mkdir -p /hana/check

  4. [1] Crie os recursos de cluster do sistema de arquivos.

    crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm

    O atributo OCF_CHECK_LEVEL=20 é adicionado à operação de monitoramento, para que as operações de monitoramento realizem 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.

Implementar os ganchos de HA do HANA SAPHanaSrMultiTarget e susChkSrv

Essa etapa importante tem a finalidade de otimizar a integração com o cluster e a detecção quando um failover de cluster é possível. É altamente recomendável configurar o gancho Python SAPHanaSrMultiTarget. Para o HANA 2.0 SP5 e superior, é recomendável implementar os ganchos SAPHanaSrMultiTarget e susChkSrv.

Observação

O provedor de HA SAPHanaSrMultiTarget substitui o SAPHanaSR para expansão do HANA. O SAPHanaSR foi descrito na versão anterior deste documento.
Confira a postagem no blog sobre o SUSE sobre as alterações com o novo gancho de HA do HANA.

As etapas fornecidas para o gancho SAPHanaSrMultiTarget são para uma nova instalação. A atualização de um ambiente existente do SAPHanaSR para o provedor SAPHanaSrMultiTarget requer várias alterações e NÃO é descrita neste documento. Se o ambiente existente não usar um terceiro site para recuperação de desastre e a replicação de sistema de vários destinos do HANA não for usada, o provedor de alta disponibilidade SAPHanaSR poderá permanecer em uso.

SusChkSrv estende a funcionalidade do principal provedor de HA do SAPHanaSrMultiTarget. Ele atua na situação em que 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 susChkSrv implementado, uma ação imediata e configurável é executada em vez de aguardar o processo hdbindexserver para reiniciar no mesmo nó. Na expansão do HANA, susChkSrv atua para cada VM do HANA de modo independente. A ação configurada encerrará o HANA ou isolará a VM afetada, o que dispara um failover no período de tempo limite configurado.

O SUSE SLES 15 SP1 ou superior é necessário para a operação de ambos os ganchos de HA do HANA. A tabela a seguir mostra outras dependências.

Gancho de HA do SAP HANA Versão necessária do HANA SAPHanaSR-ScaleOut necessário
SAPHanaSrMultiTarget HANA 2.0 SPS4 ou superior 0.180 ou superior
susChkSrv HANA 2.0 SPS5 ou superior 0.184.1 ou superior

Etapas para implementar ambos os ganchos:

  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] 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_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info

    O local padrão dos ganchos de alta disponibilidade fornecidos pelo SUSE é /usr/share/SAPHanaSR-ScaleOut. Usar o local padrão traz o benefício de que o código do gancho Python é atualizado automaticamente por meio de atualizações do sistema operacional ou do pacote e é usado pelo HANA na próxima reinicialização. Com um caminho opcional, como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional com a versão do gancho usada.

  3. [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 os comandos como root e adapte os valores de hn1 com o SID correto em minúsculas.

    cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

  4. [1,2] Iniciar o SAP HANA em ambos os sites de replicação. Execute como <sid>adm.

    sapcontrol -nr 03 -function StartSystem

  5. [A] Verifique se a instalação do gancho está ativa em todos os nós de cluster. Execute como <sid>adm.

    cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

    Verifique a instalação do gancho susChkSrv. Execute como <sid>adm.

    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] Crie os recursos de cluster do HANA. Execute os comandos a seguir como root.

    1. Confira se o cluster já está no modo de manutenção.

    2. Em seguida, crie o recurso de topologia do HANA.

      sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

    3. Em seguida, crie o recurso de instância do HANA.

      Observação

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

      sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="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 yes, para que, após a aquisição, a replicação do sistema possa ser retomada automaticamente.

    4. Criar o IP virtual e os recursos associados.

      sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

    5. Criar as restrições de cluster

      # Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

  2. [1] Configure propriedades de cluster adicionais

    sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

  3. [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 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

  4. [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 /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

    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.

Testar failover do SAP HANA

Observação

Este artigo contém referências a termos que a Microsoft não usa 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.

    a. 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 sistema de arquivos montado com NFS /hana/shared 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 do recurso 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 NFS em ANF, confirme primeiro o endereço IP do volume ANF /hana/shared 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 em hana-s1-db1 para o volume ANF /hana/shared.

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

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

    Caso defina AUTOMATED_REGISTER="false", será necessário configurar a replicação de sistema SAP HANA no site secundário. 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