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 replicação de sistema HANA (HSR) e Pacemaker em máquinas virtuais (VMs) do Azure SUSE Linux Enterprise Server. Os sistemas de arquivos compartilhados na arquitetura apresentada são montados em NFS e são fornecidos pelos Arquivos NetApp do Azure ou pelo compartilhamento NFS nos Arquivos do Azure.

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

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

Descriçã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 failover automático. Quando um nó ativo falha, o cluster faz failover dos recursos HANA para o outro site.
A configuração apresentada mostra três nós HANA em cada local, além do nó de fabricante majoritário para evitar o cenário de cérebro dividido. As instruções podem ser adaptadas para incluir mais VMs como nós de banco de dados HANA.

O sistema /hana/shared de arquivos compartilhados HANA na arquitetura apresentada pode ser fornecido pelos Arquivos NetApp do Azure ou pelo compartilhamento NFS nos Arquivos do Azure. O sistema de arquivos compartilhado HANA é montado em NFS em cada nó HANA no mesmo local de replicação do sistema HANA. /hana/data Sistemas de arquivos e /hana/log são sistemas de arquivos locais e não são compartilhados entre os nós de banco de dados HANA. O SAP HANA será instalado no modo não compartilhado.

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

Importante

Se estiver implantando todos os sistemas de arquivos HANA nos Arquivos NetApp do Azure, para sistemas de produção, onde o desempenho é uma chave, recomendamos avaliar e considerar o uso do grupo de volumes de aplicativos Arquivos NetApp do Azure para SAP HANA.

Aviso

Não há suporte para implantação /hana/data e /hana/log em NFS em 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 HANA - inter 10.23.1.128/26
  • para replicação do sistema HANA - hsr 10.23.1.192/26

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

Se você estiver usando Arquivos NetApp do Azure, os volumes NFS para /hana/shared, serão implantados em uma sub-rede separada, delegada aos Arquivos NetApp do Azure: anf 10.23.1.0/26.

Preparar a infraestrutura

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

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

  1. Implante 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 dados HANA para o local de replicação HANA 1: hana-s1-db1, hana-s1-db2 e hana-s1-db3
    • três máquinas virtuais para servir como nós de banco de dados HANA para o local de replicação HANA 2: hana-s2-db1, hana-s2-db2 e hana-s2-db3
    • Uma pequena máquina virtual para servir como fabricante majoritário: HANA-S-MM

    As VMs, implantadas como nós SAP DB HANA, devem ser certificadas pelo SAP for HANA, conforme publicado no diretório SAP HANA Hardware. Ao implantar os nós de banco de dados HANA, certifique-se de que Rede acelerada esteja selecionado.

    Para o nó maker majoritário, você pode implantar uma VM pequena, pois essa VM não executa nenhum dos recursos do SAP HANA. A VM do criador majoritário é usada na configuração do cluster para obter um número ímpar de nós de cluster em um cenário de cérebro dividido. Neste exemplo, a VM do criador majoritário só precisa de uma interface de client rede virtual na sub-rede.

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

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

    Importante

    • Certifique-se de que o sistema operacional selecionado é certificado SAP para SAP HANA nos tipos específicos de VM que você está usando. Para obter uma lista dos tipos de VM certificados pelo SAP HANA e das versões do sistema operacional para esses tipos, acesse o site de plataformas IaaS certificadas pelo SAP HANA. Clique nos detalhes do tipo de VM listado para obter a lista completa das versões do sistema operacional suportadas pelo SAP HANA para esse tipo.
    • Se você optar por implantar /hana/shared em NFS nos Arquivos do Azure, recomendamos implantar no SLES 15 SP2 e superior.

  2. Crie seis interfaces de rede, uma para cada máquina virtual de banco de dados HANA, na sub-rede de rede virtual (neste exemplo, hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter e hana-s2-db3-interinter).

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

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

    1. Vá para 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 selecione a máquina virtual.
    3. No painel Visão geral, selecione Parar para desalocar a máquina virtual.
    4. Selecione Rede e anexe a interface de rede. Na lista suspensa Anexar interface de rede, selecione as interfaces de rede já criadas para as interhsr e sub-redes.
    5. Selecione Guardar.
    6. Repita as etapas b a e para as máquinas virtuais restantes (em nosso 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 interrompido por enquanto. Em seguida, habilitaremos a rede acelerada para todas as interfaces de rede recém-conectadas.

  5. Habilite a rede acelerada para as interfaces de rede adicionais para as inter sub-redes e hsr executando as seguintes etapas:

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

    2. Execute os seguintes comandos para habilitar a rede acelerada para as interfaces de rede adicionais, que estão conectadas às inter sub-redes 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 HANA DB

Configurar o balanceador de carga do Azure

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

Nota

  • Para expansão do HANA, selecione a NIC para a client sub-rede 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 configuração do balanceador de carga, considere os seguintes pontos:

  1. Configuração de IP Frontend: Crie um IP front-end. Selecione a mesma rede virtual e o mesmo nome de sub-rede que suas 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 frontend: Selecione um IP front-end.
    • Pool de back-end: selecione um pool de back-end.
    • Portas de alta disponibilidade: selecione esta 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: Digite 5.
      • Limite da sonda: Digite 2.
    • Tempo limite de inatividade (minutos): Digite 30.
    • Ativar IP flutuante: selecione esta opção.

Nota

A propriedade numberOfProbesde configuração da sonda de integridade, também conhecida como Limite não íntegro no portal, não é respeitada. Para controlar o número de testes consecutivos bem-sucedidos ou com falha, defina a propriedade probeThreshold como 2. Atualmente, não é possível definir essa propriedade usando o portal do Azure, portanto, use a CLI do Azure ou o comando PowerShell.

Importante

O IP flutuante não é suportado em uma configuração de IP secundário da NIC em cenários de balanceamento de carga. Para obter detalhes, consulte Limitações do balanceador de carga do Azure. Se você precisar de um endereço IP adicional para a VM, implante uma segunda NIC.

Nota

Quando VMs sem endereços IP públicos são colocadas no pool de back-end do balanceador de carga interno (sem endereço IP público) Standard do Azure, não haverá conectividade de saída com a Internet, a menos que uma configuração adicional seja executada para permitir o roteamento para pontos finais públicos. Para obter detalhes sobre como obter 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 SAP.

Importante

  • Não habilite carimbos de data/hora TCP em VMs do Azure colocadas atrás do Balanceador de Carga do Azure. Habilitar carimbos de data/hora TCP fará com que as sondas de integridade falhem. Defina o parâmetro net.ipv4.tcp_timestamps como 0. Para obter detalhes, consulte Sondas de integridade do balanceador de carga e Nota 2382421 SAP.
  • Para evitar que o saptune altere o valor definido net.ipv4.tcp_timestamps manualmente de 0 volta para 1, atualize a versão do saptune para 3.1.1 ou superior. Para obter mais detalhes, consulte saptune 3.1.1 – Preciso atualizar?.

Implantar NFS

Há duas opções para implantar o Azure NFS nativo para /hana/shared. Você pode implantar o volume NFS nos Arquivos NetApp do Azure ou o compartilhamento NFS nos Arquivos do Azure. Os ficheiros do Azure suportam o protocolo NFSv4.1, o NFS nos ficheiros NetApp do Azure suporta NFSv4.1 e NFSv3.

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

Gorjeta

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

Implantar a infraestrutura de Arquivos NetApp do Azure

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

Neste exemplo, os seguintes volumes de Arquivos NetApp do Azure 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 do Azure Files

Implante compartilhamentos NFS de Arquivos do Azure para o /hana/shared sistema de arquivos. Você precisará de um compartilhamento NFS do Azure Files separado /hana/shared para cada site de replicação do sistema HANA. Para obter mais informações, consulte Como criar um compartilhamento NFS.

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

  • 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 nas secções seguintes são precedidas de uma das seguintes abreviaturas:

  • [A]: Aplicável a todos os nós, incluindo o criador da maioria
  • [AH]: Aplicável a todos os nós de banco de dados HANA
  • [M]: Aplicável apenas ao nó do criador majoritário
  • [AH1]: Aplicável a todos os nós de banco de dados HANA no SITE 1
  • [AH2]: Aplicável a todos os nós de banco de dados HANA no SITE 2
  • [1]: Aplicável apenas ao nó 1 do HANA DB, SITE 1
  • [2]: Aplicável apenas ao nó 1 do HANA DB, SITE 2

Configure e prepare seu sistema operacional executando as seguintes etapas:

  1. [A] Mantenha os arquivos host nas máquinas virtuais. Inclua entradas para todas as sub-redes. As seguintes entradas foram adicionadas para /etc/hosts este 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 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

    Gorjeta

    Evite definir net.ipv4.ip_local_port_range e net.ipv4.ip_local_reserved_ports explicitamente nos arquivos de configuração do sysctl para permitir que o SAP Host Agent gerencie os intervalos de portas. Para obter mais informações, consulte SAP note 2382421.

  3. [R] A SUSE fornece agentes de recursos especiais para SAP HANA e, por padrão, agentes para scale-up do SAP HANA são instalados. Desinstale os pacotes para scale-up, se instalados, e instale os pacotes para o cenário de scale-out do SAP HANA. A etapa precisa ser executada em todas as VMs de cluster, incluindo o fabricante majoritário.

    Nota

    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] Prepare as VMs - aplique as configurações recomendadas por 2205917 de observação SAP para o SUSE Linux Enterprise Server for SAP Applications.

Preparar os sistemas de arquivos

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

Monte os sistemas de arquivos compartilhados (Azure NetApp Files NFS)

Neste exemplo, os sistemas de arquivos HANA compartilhados são implantados nos Arquivos NetApp do Azure e montados sobre NFSv4.1. Siga as etapas nesta seção, somente se estiver usando NFS nos Arquivos NetApp do Azure.

  1. [AH] Prepare o sistema operacional para executar o SAP HANA em sistemas NetApp com NFS, conforme descrito na nota 3024346 SAP - Configurações do kernel Linux para NFS NetApp. Crie o arquivo de configuração /etc/sysctl.d/91-NetApp-HANA.conf para as definições de configuração da 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 sunrpc, conforme recomendado na nota 3024346 SAP - Configurações do kernel Linux para NetApp 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 do banco de dados HANA.

    mkdir -p /hana/shared

  4. [AH] Verifique a configuração de domínio NFS. Verifique se o domínio está configurado como o domínio padrão dos Arquivos NetApp do Azure, ou seja, defaultv4iddomain.com e se o mapeamento está definido como ninguém.
    Esta etapa só é necessária se estiver usando o Azure NetAppFiles NFSv4.1.

    Importante

    Certifique-se de definir o domínio NFS na /etc/idmapd.conf VM para corresponder à configuração de domínio padrão nos Arquivos NetApp do Azure: 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 do Azure NetApp, as permissões para arquivos nos volumes NetApp do Azure 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] Verificar nfs4_disable_idmapping. Deve ser definido como Y. Para criar a estrutura de diretórios onde nfs4_disable_idmapping está localizado, execute o comando mount. Você não poderá criar manualmente o diretório em /sys/modules, porque o acesso é reservado para o kernel / drivers.
    Esta etapa só é necessária se 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 compartilhados dos Arquivos NetApp do Azure nas VMs de banco de dados HANA SITE1.

    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 compartilhados dos Arquivos NetApp do Azure nas VMs de banco de dados HANA do SITE2.

    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 correspondentes /hana/shared/ estão montados em todas as VMs de banco de dados HANA com a versão do protocolo NFS 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

Monte os sistemas de arquivos compartilhados (Azure Files NFS)

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

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

    mkdir -p /hana/shared

  2. [AH1] Monte os volumes compartilhados dos Arquivos NetApp do Azure nas VMs de banco de dados HANA SITE1.

    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 compartilhados dos Arquivos NetApp do Azure nas VMs de banco de dados HANA do SITE2.

    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 correspondentes /hana/shared/ estão montados em todas as VMs de banco de dados HANA com a versão do protocolo NFS 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 sistemas de arquivos locais

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

Configure o layout do disco com o LVM (Logical Volume Manager). O exemplo a seguir pressupõe que cada máquina virtual HANA tenha 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 o -i switch. Sugerimos que você crie um volume distribuído para um melhor desempenho de E/S e alinhe os tamanhos de distribuição aos valores documentados nas configurações de armazenamento SAP HANA VM. O -i argumento deve ser o número dos volumes físicos subjacentes e o -I argumento é o tamanho da faixa. Neste documento, dois volumes físicos são usados para o volume de dados, portanto, o -i argumento switch é definido como 2. O tamanho da faixa para o volume de dados é de 256 KiB. Um volume físico é usado para o volume de log, portanto, nenhum -i ou -I switches são explicitamente usados para os comandos de volume de log.

    Importante

    Use o -i switch e defina-o como o número do volume físico subjacente quando usar mais de um volume físico para cada volume de dados ou de log. Use a -I opção para especificar o tamanho da faixa ao criar um volume listrado.
    Consulte Configurações de armazenamento SAP HANA VM para obter 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 fstab entradas para os volumes lógicos e monte:

    sudo vi /etc/fstab

    Insira a seguinte linha no /etc/fstab ficheiro:

    /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 de marcapasso

Siga as etapas em Configurando o Pacemaker no SUSE Linux Enterprise Server no Azure para criar um cluster Pacemaker básico para este servidor HANA. Inclua todas as máquinas virtuais, incluindo o criador majoritário no cluster.

Importante

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

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 de root. Você pode desativar a senha de root após a conclusão da instalação. Executar como root comando passwd.

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

    chmod 775 /hana/shared

  3. [1] Verifique se você pode fazer login via SSH para as VMs de banco de dados HANA neste site hana-s1-db2 e hana-s1-db3, sem ser solicitada uma senha. Se esse não for o caso, troque 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 login via SSH para as VMs HANA DB neste site hana-s2-db2 e hana-s2-db3, sem ser solicitada uma senha.
    Se não for esse 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 superior. Para obter mais informações, consulte SAP Note 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ó em cada local

  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 a root partir do diretório do software de instalação HANA. Use o internal_network parâmetro e passe o espaço de endereço para a sub-rede, que é usado para a comunicação interna entre nós HANA.

    ./hdblcm --internal_network=10.23.1.128/26

    b. No prompt, insira os seguintes valores:

    • Para Escolha uma ação: digite 1 (para instalar)
    • Para componentes adicionais para instalação: insira 2, 3
    • Para o caminho de instalação: pressione Enter (o padrão é /hana/shared)
    • Para Nome do Host Local: pressione Enter para aceitar o padrão
    • Para Deseja adicionar hosts ao sistema?: digite n
    • Para SAP HANA System ID: insira HN1
    • Para o número da instância [00]: digite 03
    • Para Grupo de Trabalho de Host Local [padrão]: pressione Enter para aceitar o padrão
    • Para Selecionar Uso do Sistema / Inserir índice [4]: digite 4 (para personalizado)
    • Para Localização de Volumes de Dados [/hana/data/HN1]: pressione Enter para aceitar o padrão
    • Para Localização dos Volumes de Log [/hana/log/HN1]: pressione Enter para aceitar o padrão
    • Para Restringir alocação máxima de memória? [n]: digite n
    • Para Nome do Host do Certificado Para Host hana-s1-db1 [hana-s1-db1]: pressione Enter para aceitar o padrão
    • Para SAP Host Agent User (sapadm) Senha: digite a senha
    • Para Confirmar senha do usuário do SAP Host Agent (sapadm): digite a senha
    • Para a palavra-passe do administrador do sistema (hn1adm): introduza a palavra-passe
    • Para o diretório inicial do administrador do sistema [/usr/sap/HN1/home]: pressione Enter para aceitar o padrão
    • Para o Shell de Login do Administrador do Sistema [/bin/sh]: pressione Enter para aceitar o padrão
    • Para o ID de usuário do administrador do sistema [1001]: pressione Enter para aceitar o padrão
    • Para Enter ID of User Group (sapsys) [79]: pressione Enter para aceitar o padrão
    • Para Senha do Usuário do Banco de Dados do Sistema (sistema): digite a senha do sistema
    • Para Confirmar Senha do Usuário do Banco de Dados do Sistema (sistema): digite a senha do sistema
    • Para Reiniciar o sistema após a reinicialização da máquina? [n]: digite n
    • Para Deseja continuar (s/n): valide o resumo e, se tudo parecer bom, digite y

  2. [2] Repita a etapa anterior para instalar o SAP HANA no primeiro nó do SITE 2.

  3. [1,2] Verificar global.ini

    Exiba global.ini e verifique se a configuração para a comunicação interna entre nós do SAP HANA está em vigor. Verifique a seção de comunicação . Ele deve ter o espaço de endereço para a inter sub-rede 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 à inter sub-rede.

      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] Preparar global.ini para instalação em ambiente não compartilhado, conforme descrito na nota 2080991 da SAP.

     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 utilizará os endereços IP da client sub-rede 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 SAP Note 2183363 - Configuration of SAP HANA internal network.

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

     sudo chmod o+w -R /hana/data /hana/log

  8. [1] Instale os nós 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 seguintes valores:

    • Para Escolha uma ação: digite 2 (para adicionar hosts)
    • Para inserir nomes de host separados por vírgulas para adicionar: hana-s1-db2, hana-s1-db3
    • Para componentes adicionais para instalação: insira 2, 3
    • Para Enter Root Root User Name [root]: pressione Enter para aceitar o padrão
    • Para funções selecionadas para host 'hana-s1-db2' [1]: 1 (para trabalhador)
    • Para Enter Host Failover Group for host 'hana-s1-db2' [default]: pressione Enter para aceitar o padrão
    • Para inserir o número da partição de armazenamento para o host 'hana-s1-db2' [<<atribuir automaticamente>>]: pressione Enter para aceitar o padrão
    • Para Enter Worker Group para host 'hana-s1-db2' [default]: pressione Enter para aceitar o padrão
    • Para funções selecionadas para host 'hana-s1-db3' [1]: 1 (para trabalhador)
    • Para Enter Host Failover Group for host 'hana-s1-db3' [default]: pressione Enter para aceitar o padrão
    • Para Digite o número da partição de armazenamento para o host 'hana-s1-db3' [<<atribuir automaticamente>>]: pressione Enter para aceitar o padrão
    • Para Enter Worker Group para host 'hana-s1-db3' [default]: pressione Enter para aceitar o padrão
    • Para a palavra-passe do administrador do sistema (hn1adm): introduza a palavra-passe
    • Para Enter SAP Host Agent User (sapadm) Password: digite a senha
    • Para Confirmar senha do usuário do SAP Host Agent (sapadm): digite a senha
    • Para Nome do Host do Certificado Para Host hana-s1-db2 [hana-s1-db2]: pressione Enter para aceitar o padrão
    • Para Nome do Host do Certificado Para Host hana-s1-db3 [hana-s1-db3]: pressione Enter para aceitar o padrão
    • Para Deseja continuar (s/n): valide o resumo e, se tudo parecer bom, digite y

  9. [2] Repita a etapa anterior para instalar os nós secundários do SAP HANA 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 principal:

    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 o estado da replicação

    Verifique o status da replicação e aguarde até que todos os bancos de dados estejam sincronizados.

    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 através das interfaces de rede virtual de replicação do sistema HANA.

    • Pare o HANA em ambos os sites

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

    • Edite global.ini para adicionar o mapeamento de host para replicação do sistema HANA: use os endereços IP da hsr sub-rede.

      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

    • Inicie o HANA em ambos os sites

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

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

Criar 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 para acessar o sistema /hana/sharedde arquivos montado no NFS. Isso permite que o cluster acione o failover, caso haja um problema para acessar /hana/sharedo . Para obter mais informações, consulte Manipulando compartilhamento NFS com falha no cluster SUSE HA para replicação do sistema HANA

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

    crm configure property maintenance-mode=true

  2. [1,2] Crie o diretório no sistema de arquivos montado no NFS /hana/shared, 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 ficheiros.

    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

    OCF_CHECK_LEVEL=20 é adicionado à operação do monitor, para que as operações do monitor executem um teste de leitura/gravação no sistema de arquivos. Sem esse atributo, a operação do monitor apenas verifica se o sistema de arquivos está montado. Isso pode ser um problema porque quando a conectividade é perdida, o sistema de arquivos pode permanecer montado, apesar de estar inacessível.

    on-fail=fence também é adicionado à operação do monitor. Com essa opção, se a operação do monitor falhar em um nó, esse nó será imediatamente cercado.

Implementar ganchos HANA HA SAPHanaSrMultiTarget e susChkSrv

Esta etapa importante é otimizar a integração com o cluster e a deteção quando um failover de cluster é possível. É altamente recomendável configurar o gancho Python SAPHanaSrMultiTarget. Para HANA 2.0 SP5 e superior, recomenda-se a implementação de ganchos SAPHanaSrMultiTarget e susChkSrv.

Nota

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

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 são descritas neste documento. Se o ambiente existente não usar um terceiro local para recuperação de desastres e a replicação do sistema HANA de vários destinos não for usada, o provedor de HA SAPHanaSR poderá permanecer em uso.

O SusChkSrv estende a funcionalidade do principal provedor de HA SAPHanaSrMultiTarget. Ele atua na situação em que o processo HANA hdbindexserver falha. Se um único processo falhar, normalmente o HANA tenta reiniciá-lo. Reiniciar o processo do servidor de indexação pode levar muito tempo, durante o qual o banco de dados HANA não responde. Com susChkSrv implementado, uma ação imediata e configurável é executada, em vez de esperar no processo hdbindexserver para reiniciar no mesmo nó. Na expansão do HANA, o susChkSrv atua para cada VM HANA de forma independente. A ação configurada matará o HANA ou cercará 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 HA HANA. A tabela a seguir mostra outras dependências.

Gancho SAP HANA HA Versão HANA necessária 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] Pare o HANA em ambos os locais de replicação do sistema. Executar como <sid>adm:

    sapcontrol -nr 03 -function StopSystem

  2. [1,2] Ajuste global.ini em cada local de cluster. Se os pré-requisitos para o gancho susChkSrv não forem atendidos, todo o bloco [ha_dr_provider_suschksrv] não deverá ser configurado.
    Você pode ajustar o comportamento do 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 HA conforme fornecidos pela SUSE é /usr/share/SAPHanaSR-ScaleOut. Usar o local padrão traz um benefício, que o código de gancho python é atualizado automaticamente através de atualizações do sistema operacional ou do pacote e é usado pelo HANA na próxima reinicialização. Com um caminho próprio opcional, como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional da versão de gancho usada.

  3. [AH] O cluster requer configuração de sudoers nos nós do cluster para <sid>adm. Neste exemplo, isso é conseguido criando um novo arquivo. Execute os comandos como root adaptar os valores de hn1 com SID minúsculo correto.

    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] Inicie o SAP HANA em ambos os locais 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 do 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)

Criar recursos de cluster do SAP HANA

  1. [1] Crie os recursos do cluster HANA. Execute os seguintes comandos como root.

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

    2. Em seguida, crie o recurso de topologia 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 HANA.

      Nota

      Este artigo contém referências a termos que a Microsoft já não utiliza. Quando estes termos forem removidos do software, iremos removê-los 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

      Recomendamos como prática recomendada que você defina apenas AUTOMATED_REGISTER como não, ao executar testes de failover completos, para evitar que a instância primária com falha se registre automaticamente como secundária. Depois que os testes de failover forem concluídos com êxito, defina AUTOMATED_REGISTER como sim, para que, após a aquisição, a replicação do sistema possa ser retomada automaticamente.

    4. Crie IP virtual e 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] Configurar propriedades de cluster adicionais

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

  3. [1] Coloque o cluster fora do modo de manutenção. Verifique se o status do cluster está ok e se 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 HANA HA e o cluster, mostrando o status SOK para SID e ambos os locais 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

    Nota

    Os tempos limite na configuração acima são apenas exemplos e podem precisar ser adaptados à configuração específica do HANA. Por exemplo, pode ser necessário aumentar o tempo limite de início, se demorar mais para iniciar o banco de dados do SAP HANA.

Testar failover do SAP HANA

Nota

Este artigo contém referências a termos que a Microsoft já não utiliza. Quando estes termos forem removidos do software, iremos removê-los deste artigo.

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

    a. Verifique se não há ações 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 do cluster SAP HANA, executando os testes, documentados em HA para SAP HANA em VMs do Azure no SLES e no Cenário de Desempenho Otimizado de 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 recursos do SAP HANA dependem de binários, armazenados para /hana/shared executar operações durante o failover. O sistema /hana/shared de arquivos é montado sobre NFS na configuração apresentada. Um teste que pode ser executado é criar uma regra de firewall temporária para bloquear o acesso ao sistema de arquivos montado no /hana/shared NFS em uma das VMs do site primário. Essa abordagem valida que o cluster fará failover se 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 no 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 é possível acessar o sistema de arquivos e acionará o failover de recursos HANA. O mesmo resultado é esperado quando o nó HANA perde o acesso ao compartilhamento NFS.

    Você pode verificar o estado dos recursos do 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 falhas para /hana/shared:

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

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

    Neste exemplo, o comando foi executado em hana-s1-db1 para o volume /hana/sharedANF.

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

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

    Se você definir AUTOMATED_REGISTER="false", precisará configurar a replicação do sistema SAP HANA no local 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óximos passos