Partilhar via

Alta disponibilidade de escalonamento do SAP HANA com arquivos NetApp do Azure no SUSE Linux Enterprise Server

  • Artigo

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

Quando as etapas neste documento são marcadas com os seguintes prefixos, elas significam:

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

Leia primeiro as seguintes notas e documentos do SAP:

Nota

Este artigo contém referências a um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.

Descrição geral

Tradicionalmente, em um ambiente de expansão, todos os sistemas de arquivos para SAP HANA são montados a partir do armazenamento local. A configuração da HA da replicação do sistema SAP HANA no SUSE Linux Enterprise Server é publicada em Configurar a replicação do sistema SAP HANA no SLES.

Para obter o SAP HANA HA de um sistema de expansão em compartilhamentos NFS do Azure NetApp Files, precisamos de configuração de recursos extras no cluster. Essa configuração é necessária para que os recursos do HANA possam se recuperar quando um nó perde o acesso aos compartilhamentos NFS nos Arquivos NetApp do Azure.

Diagrama que mostra a expansão do SAP HANA HA nos Arquivos NetApp do Azure.

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

Montado no nó1 (hanadb1):

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

Montado no nó2 (hanadb2):

  • 10.3.1.4:/hanadb2-data-mnt00001 em /hana/data
  • 10.3.1.4:/hanadb2-log-mnt00001 em /hana/log
  • 10.3.1.4:/hanadb2-shared-mnt0001 em /hana/shared

Nota

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

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

  • Endereço IP de configuração front-end: 10.3.0.50 para hn1-db
  • Porta da sonda: 62503

Configurar a infraestrutura do Azure NetApp Files

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

Os Arquivos NetApp do Azure estão disponíveis em várias regiões do Azure. Verifique se a região do Azure selecionada oferece Arquivos NetApp do Azure.

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

Considerações importantes

Ao criar seus arquivos NetApp do Azure para sistemas de expansão do SAP HANA, esteja ciente das considerações importantes documentadas nos volumes NFS v4.1 nos Arquivos NetApp do Azure para SAP HANA.

Dimensionamento do banco de dados HANA em arquivos NetApp do Azure

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

Ao projetar a infraestrutura do SAP HANA no Azure com Arquivos NetApp do Azure, esteja ciente das recomendações nos volumes NFS v4.1 nos Arquivos NetApp do Azure para SAP HANA.

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

Importante

Para sistemas de produção, onde o desempenho é fundamental, recomendamos que você avalie e considere o uso do grupo de volumes de aplicativos Arquivos NetApp do Azure para SAP HANA.

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

Implantar recursos do Azure NetApp Files

As instruções a seguir pressupõem que você já implantou sua rede virtual do Azure. Os recursos e VMs dos Arquivos NetApp do Azure, onde os recursos dos Arquivos NetApp do Azure são montados, devem ser implantados na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas.

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

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

    A arquitetura HANA apresentada neste artigo usa um único pool de capacidade de Arquivos NetApp do Azure no nível de serviço Ultra. Para cargas de trabalho HANA no Azure, recomendamos usar o Nível de serviço Azure NetApp Files Ultra ou Premium.

  3. Delegue uma sub-rede aos Arquivos NetApp do Azure, conforme descrito nas instruções em Delegar uma sub-rede aos Arquivos NetApp do Azure.

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

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

    Os recursos dos Arquivos NetApp do Azure e as VMs do Azure devem estar na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas. Por exemplo, hanadb1-data-mnt00001, hanadb1-log-mnt00001 e assim por diante são os nomes de volume, e nfs://10.3.1.4/hanadb1-data-mnt00001, nfs://10.3.1.4/hanadb1-log-mnt00001 e assim por diante são os caminhos de arquivo para os volumes de Arquivos NetApp do Azure.

    Em hanadb1:

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

    Em hanadb2:

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

Preparar a infraestrutura

O agente de recursos para SAP HANA está incluído no SUSE Linux Enterprise Server for SAP Applications. Uma imagem para o SUSE Linux Enterprise Server for SAP Applications 12 ou 15 está disponível no Azure Marketplace. Você pode usar a imagem para implantar novas VMs.

Implantar VMs Linux manualmente por meio do portal do Azure

Este documento pressupõe que você já implantou um grupo de recursos, a Rede Virtual do Azure e a sub-rede.

Implante VMs para SAP HANA. Escolha uma imagem SLES adequada que seja suportada para o sistema HANA. Você pode implantar uma VM em qualquer uma das opções de disponibilidade: conjunto de escala de máquina virtual, zona de disponibilidade ou conjunto de disponibilidade.

Importante

Certifique-se de que o sistema operacional selecionado é certificado SAP para SAP HANA nos tipos específicos de VM que você planeja usar em sua implantação. Você pode procurar tipos de VM certificados pelo SAP HANA e suas versões de SO em plataformas IaaS certificadas pelo SAP HANA. Certifique-se de examinar os detalhes do tipo de VM para obter a lista completa de versões do sistema operacional suportadas pelo SAP HANA para o tipo de VM específico.

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 existente na seção de rede. Siga as próximas etapas para configurar um balanceador de carga padrão para a configuração HA do banco de dados HANA.

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

  1. Configuração de IP 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.

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

Quando VMs sem endereços IP públicos são colocadas no pool de back-end do Balanceador de Carga do Azure Standard interno (sem endereço IP público), não há conectividade de saída com a Internet, a menos que mais configuração seja executada para permitir o roteamento para pontos de extremidade públicos. Para obter mais informações sobre como obter conectividade de saída, consulte Conectividade de ponto de extremidade público para VMs 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. A ativação de carimbos de data/hora TCP faz com que os testes de integridade falhem. Defina o parâmetro net.ipv4.tcp_timestamps como 0. Para obter mais informações, consulte Sondas de integridade do balanceador de carga e SAP Note 2382421.
  • 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 informações, consulte saptune 3.1.1 – Do I Need to Update?.

Monte o volume de Arquivos NetApp do Azure

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

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

  2. [A] Verifique a configuração do 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.

    sudo cat /etc/idmapd.conf

    Saída de exemplo:

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

    Importante

    Certifique-se de definir o domínio NFS em /etc/idmapd.conf na 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 dos Arquivos NetApp do Azure), as permissões para arquivos nos volumes dos Arquivos NetApp do Azure montados nas VMs serão exibidas como ninguém.

  3. [A] Edite /etc/fstab em ambos os nós para montar permanentemente os volumes relevantes para cada nó. O exemplo a seguir mostra como você monta os volumes permanentemente.

    sudo vi /etc/fstab

    Adicione as seguintes entradas em /etc/fstab ambos os nós.

    Exemplo para hanadb1:

    10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Exemplo para hanadb2:

    10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Monte todos os volumes.

    sudo mount -a

    Para cargas de trabalho que exigem uma taxa de transferência mais alta, considere usar a nconnect opção mount, conforme descrito em volumes NFS v4.1 no Azure NetApp Files for SAP HANA. Verifique se nconnect é suportado pelos Arquivos NetApp do Azure na sua versão do Linux.

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

    sudo nfsstat -m

    Verifique se o sinalizador vers está definido como 4.1.

    Exemplo de hanadb1:

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

  5. [A] Verifique 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.

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

#If you need to set nfs4_disable_idmapping to Y
sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

#Make the configuration permanent
sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

Instalação do SAP HANA

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

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

    sudo vi /etc/hosts

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

    10.3.0.4   hanadb1
10.3.0.5   hanadb2

  2. [A] Prepare o SO para executar o SAP HANA no Azure NetApp com NFS, conforme descrito em SAP Note 3024346 - Linux Kernel Settings for NetApp NFS. Crie o arquivo de /etc/sysctl.d/91-NetApp-HANA.conf configuração para as definições de configuração da NetApp.

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

    Adicione as seguintes entradas no arquivo de configuração:

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

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

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

    Adicione as seguintes entradas no arquivo de configuração:

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

    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.

  4. [A] Ajuste as sunrpc configurações, conforme recomendado no SAP Note 3024346 - Linux Kernel Settings for NetApp NFS.

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

    Insira a seguinte linha:

    options sunrpc tcp_max_slot_table_entries=128

  5. [A] Configure o SLES para HANA.

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

  6. [A] Instale o SAP HANA.

    A partir do HANA 2.0 SPS 01, o MDC (Multitenant Database Containers) é a opção padrão. Quando você instala o sistema HANA, SYSTEMDB e um locatário com o mesmo SID são criados juntos. Em alguns casos, você não quer o locatário padrão. Se você não quiser criar o locatário inicial junto com a instalação, siga as instruções no SAP Note 2629711.

    1. Inicie o hdblcm programa a partir do diretório do software de instalação do HANA.

      ./hdblcm

    2. No prompt, insira os seguintes valores:

      • Para Escolher instalação: Digite 1 (para instalar).
      • Para Selecionar componentes adicionais para instalação: Digite 1.
      • Para Enter Installation Path [/hana/shared]: Pressione Enter para aceitar o padrão.
      • Para Enter Local Host Name [..]: Pressione Enter para aceitar o padrão.
      • Em Deseja adicionar outros hosts ao sistema? (s/n) [n]: Selecione n.
      • Para Digite o ID do sistema SAP HANA: Digite HN1.
      • Para Digite o número da instância [00]: digite 03.
      • Para Select Database Mode / Enter Index [1]: pressione Enter para aceitar o padrão.
      • Para Selecionar Uso do Sistema / Inserir Índice [4]: Digite 4 (para personalizado).
      • Para Enter Location of Data Volumes [/hana/data]: pressione Enter para aceitar o padrão.
      • Para Enter Location of Log Volumes [/hana/log]: Pressione Enter para aceitar o padrão.
      • Para Restringir alocação máxima de memória? [n]: Pressione Enter para aceitar o padrão.
      • Para Digite o Nome do Host do Certificado para o Host '...' [...]: Pressione Enter para aceitar o padrão.
      • Para Digite a senha do usuário do SAP Host Agent (sapadm): Digite a senha do usuário do host agent.
      • Para Confirmar senha do usuário do SAP Host Agent (sapadm): Digite a senha do usuário do host agent novamente para confirmar.
      • Para Digite a senha do administrador do sistema (hn1adm): Digite a senha do administrador do sistema.
      • Para Confirmar Senha do Administrador do Sistema (hn1adm): Digite a senha do administrador do sistema novamente para confirmar.
      • Para Enter System Administrator Home Directory [/usr/sap/HN1/home]: Pressione Enter para aceitar o padrão.
      • Para Enter System Administrator Login Shell [/bin/sh]: Pressione Enter para aceitar o padrão.
      • Para Enter System Administrator User ID [1001]: pressione Enter para aceitar o padrão.
      • Para Enter ID of User Group (sapsys) [79]: Pressione Enter para aceitar o padrão.
      • Para Digite a senha do usuário do banco de dados (SYSTEM): Digite a senha do usuário do banco de dados.
      • Para Confirmar senha do usuário do banco de dados (SYSTEM): Digite a senha do usuário do banco de dados novamente para confirmar.
      • Para reiniciar o sistema após a reinicialização da máquina? [n]: Pressione Enter para aceitar o padrão.
      • Pois quer continuar? (s/n): Validar o resumo. Digite y para continuar.

  7. [A] Atualize o SAP Host Agent.

    Faça o download do arquivo mais recente do SAP Host Agent no SAP Software Center e execute o seguinte comando para atualizar o agente. Substitua o caminho para o arquivo morto para apontar para o arquivo que você baixou.

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

Configurar a replicação do sistema SAP HANA

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

Configuração do cluster

Esta seção descreve as etapas necessárias para que o cluster opere perfeitamente quando o SAP HANA é instalado em compartilhamentos NFS usando Arquivos NetApp do Azure.

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.

Implementar ganchos HANA SAPHanaSR e susChkSrv

Esta etapa importante otimiza a integração com o cluster e melhora a deteção quando um failover de cluster é necessário. É altamente recomendável que você configure os ganchos SAPHanaSR e susChkSrv Python. Siga as etapas em Implementar os ganchos de replicação do sistema Python SAPHanaSR/SAPHanaSR-angi e susChkSrv.

Configurar recursos de cluster do SAP HANA

Esta seção descreve as etapas necessárias para configurar os recursos de cluster do SAP HANA.

Criar recursos de cluster do SAP HANA

Siga as etapas em Criação de recursos de cluster do SAP HANA para criar os recursos de cluster para o servidor HANA. Depois que os recursos forem criados, você verá o status do cluster com o seguinte comando:

sudo crm_mon -r

Saída de exemplo:

# Online: [ hn1-db-0 hn1-db-1 ]
# Full list of resources:
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Criar recursos do sistema de arquivos

O sistema de arquivos /hana/shared/SID é necessário para a operação do HANA e também para as ações de monitoramento do Pacemaker que determinam o estado do HANA. Implementar agentes de recursos para monitorar e agir em caso de falhas. A seção contém duas opções, uma para SAPHanaSR e outra para SAPHanaSR-angi.

Crie um recurso de cluster de sistema de arquivos fictício. Ele monitora e relata falhas se houver um problema para acessar o sistema de arquivos montado em NFS /hana/shared. Isso permite que o cluster acione o failover se houver um problema ao acessar /hana/shared. Para obter mais informações, consulte Manipulando compartilhamento NFS com falha no cluster SUSE HA para replicação do sistema HANA.

  1. [A] Crie a estrutura de diretórios em ambos os nós.

    sudo mkdir -p /hana/shared/HN1/check
sudo mkdir -p /hana/shared/check

  2. [1] Configure o cluster para adicionar a estrutura de diretórios para monitoramento.

    sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
    device="/hana/shared/HN1/check/" \
    directory="/hana/shared/check/" fstype=nfs  \
    options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
    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

  3. [1] Clone e verifique o volume recém-configurado no cluster.

    sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true

    Saída de exemplo:

    sudo crm status

# Cluster Summary:
# Stack: corosync
# Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Tue Nov  2 17:57:39 2021
# Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]

# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
#  Slaves: [ hanadb2 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    O OCF_CHECK_LEVEL=20 atributo é 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.

    O on-fail=fence atributo 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.

Importante

Os tempos limite na configuração anterior podem precisar ser adaptados à configuração específica do HANA para evitar ações de vedação desnecessárias. Não defina os valores de tempo limite muito baixos. Lembre-se de que o monitor do sistema de arquivos não está relacionado à replicação do sistema HANA. Para obter mais informações, consulte a documentação da SUSE.

Testar a configuração do cluster

Esta seção descreve como você pode testar sua configuração.

  1. Antes de iniciar um teste, certifique-se de que o Pacemaker não tem nenhuma ação com falha (via status crm) e nenhuma restrição de local inesperada (por exemplo, sobras de um teste de migração). Além disso, verifique se a replicação do sistema HANA está em estado sincronizado, por exemplo, com systemReplicationStatuso .

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

  2. Verifique o status dos recursos HANA usando este comando:

    SAPHanaSR-showAttr

# You should see something like below
# hanadb1:~ SAPHanaSR-showAttr
# Global cib-time                 maintenance
# --------------------------------------------
# global Mon Nov  8 22:50:30 2021 false
# Sites srHook
# -------------
# SITE1 PRIM
# SITE2 SOK
# Site2 SOK
# Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
# --------------------------------------------------------------------------------------------------------------------------------------------------------------
# hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
# hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2

  3. Verifique a configuração do cluster para um cenário de falha quando um nó é desligado. O exemplo a seguir mostra o nó 1 de desligamento:

    sudo crm status
sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
sudo crm resource cleanup

    Saída de exemplo:

    sudo crm status

#Cluster Summary:
# Stack: corosync
# Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Mon Nov  8 23:25:36 2021
# Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]
# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  Masters: [ hanadb2 ]
#  Stopped: [ hanadb1 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    Pare o HANA no nó1:

    sudo su - hn1adm
sapcontrol -nr 03 -function StopWait 600 10

    Registre o Nó 1 como o Nó Secundário e verifique o status:

    hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay

    Saída de exemplo:

    #adding site ...
#nameserver hanadb1:30301 not responding.
#collecting information ...
#updating local ini files ...
#done.

    sudo crm status

    sudo SAPHanaSR-showAttr

  4. 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 em /hana/shared para executar operações durante o failover. O sistema de arquivos /hana/shared é montado sobre NFS no cenário apresentado.

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

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

    Estado do recurso antes de iniciar o teste:

    sudo crm  status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Mon Nov  8 23:01:27 2021
 # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb1 ]
   # Slaves: [ hanadb2 ]
 # Resource Group: g_ip_HN1_HDB03:
   # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    Você pode colocar /hana/shared no modo somente leitura no nó de cluster ativo usando este comando:

    sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb

    O servidor hanadb1 é reinicializado ou desligado com base no conjunto de ações. Depois que o servidor hanadb1 estiver inativo, o recurso HANA será movido para hanadb2. Você pode verificar o status do cluster em hanadb2.

    sudo crm status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Wed Nov 10 22:00:27 2021
 # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb2 ]
   # Stopped: [ hanadb1 ]
 # Resource Group: g_ip_HN1_HDB03:
      # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    Recomendamos testar completamente a configuração do cluster SAP HANA fazendo os testes descritos em Replicação do sistema SAP HANA.

Próximos passos