Alta disponibilidade para SAP HANA em VMs do Azure no SUSE Linux Enterprise Server

Para estabelecer alta disponibilidade em uma implantação local do SAP HANA, você pode usar a replicação do sistema SAP HANA ou o armazenamento compartilhado.

Atualmente, nas máquinas virtuais (VMs) do Azure, a replicação do sistema SAP HANA no Azure é a única função de alta disponibilidade suportada.

A replicação do sistema SAP HANA consiste em um nó primário e pelo menos um nó secundário. As alterações nos dados no nó primário são replicadas para o nó secundário de forma síncrona ou assíncrona.

Este artigo descreve como implantar e configurar as VMs, instalar a estrutura de cluster e instalar e configurar a replicação do sistema SAP HANA.

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

• Nota SAP 1928533. A nota inclui:
  • A lista de tamanhos de VM do Azure com suporte para a implantação do software SAP.
  • Informações de capacidade importantes para tamanhos de VM do Azure.
  • O software SAP, o sistema operacional (SO) e as combinações de banco de dados suportados.
  • As versões necessárias do kernel SAP para Windows e Linux no Microsoft Azure.
• A Nota 2015553 do SAP lista os pré-requisitos para implantações de software SAP suportadas pelo SAP no Azure.
• O SAP Note 2205917 recomendou as configurações do sistema operacional para o SUSE Linux Enterprise Server 12 (SLES 12) para aplicativos SAP.
• O SAP Note 2684254 recomendou as configurações do sistema operacional para o SUSE Linux Enterprise Server 15 (SLES 15) para aplicativos SAP.
• SAP Note 2235581 tem sistemas operacionais compatíveis com SAP HANA
• O SAP Note 2178632 tem informações detalhadas sobre todas as métricas de monitoramento que são relatadas para SAP no Azure.
• O SAP Note 2191498 tem a versão necessária do agente host SAP para Linux no Azure.
• O SAP Note 2243692 tem informações sobre o licenciamento SAP para Linux no Azure.
• O SAP Note 1984787 tem informações gerais sobre o SUSE Linux Enterprise Server 12.
• O SAP Note 1999351 tem mais informações de solução de problemas para a Extensão de Monitoramento Avançado do Azure para SAP.
• O SAP Note 401162 tem informações sobre como evitar erros de "endereço já em uso" ao configurar a replicação do sistema HANA.
• O SAP Community Support Wiki tem todas as notas SAP necessárias para Linux.
• Plataformas IaaS certificadas SAP HANA.
• Guia de planejamento e implementação de Máquinas Virtuais do Azure para SAP no Linux .
• Guia de implantação de Máquinas Virtuais do Azure para SAP no Linux .
• Guia de implantação do DBMS de Máquinas Virtuais do Azure para SAP no Linux .
• Guias de práticas recomendadas do SUSE Linux Enterprise Server for SAP Applications 15 e guias de práticas recomendadas do SUSE Linux Enterprise Server for SAP Applications 12:
  • Configuração de uma infraestrutura otimizada de desempenho SAP HANA SR (SLES for SAP Applications). O guia contém todas as informações necessárias para configurar a replicação do sistema SAP HANA para desenvolvimento local. Use este guia como uma linha de base.
  • Configuração de uma infraestrutura SAP HANA SR Cost Optimized (SLES for SAP Applications).

Planejar a alta disponibilidade do SAP HANA

Para obter alta disponibilidade, instale o SAP HANA em duas VMs. Os dados são replicados usando a replicação do sistema HANA.

A configuração de replicação do sistema SAP HANA usa um nome de host virtual dedicado e endereços IP virtuais. No Azure, você precisa de um balanceador de carga para implantar um endereço IP virtual.

A figura anterior mostra um exemplo de balanceador de carga que tem estas configurações:

• Endereço IP front-end: 10.0.0.13 para HN1-db
• Porta da sonda: 62503

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á tenha implantado um grupo de recursos, a Rede Virtual do Azure e a sub-rede.

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

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.

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

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.

Criar um cluster de marcapasso

Siga as etapas em Configurar o Pacemaker no SUSE Linux Enterprise Server no Azure para criar um cluster Pacemaker básico para este servidor HANA. Você pode usar o mesmo cluster Pacemaker para SAP HANA e SAP NetWeaver (A)SCS.

Instalar o SAP HANA

As etapas nesta seção usam os seguintes prefixos:

• [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 do cluster Pacemaker.

Substitua <placeholders> pelos valores para sua instalação do SAP HANA.

1. [A] Configure o layout do disco usando o LVM (Logical Volume Manager).

   Recomendamos que você use o LVM para volumes que armazenam dados e arquivos de log. O exemplo a seguir pressupõe que as VMs tenham quatro discos de dados anexados que são usados para criar dois volumes.

   1. Execute este comando para listar todos os discos disponíveis:

      /dev/disk/azure/scsi1/lun*
      

      Saída de exemplo:

      /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
      

   2. 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
      sudo pvcreate /dev/disk/azure/scsi1/lun3
      

   3. Crie um grupo de volumes para os arquivos de dados. Use um grupo de volumes para os arquivos de log e um grupo de volumes para o diretório compartilhado do SAP HANA:

      sudo vgcreate vg_hana_data_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
      sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
      sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3
      

   4. 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. Alinhe os tamanhos de distribuição aos valores descritos nas configurações de armazenamento SAP HANA VM. O -i argumento deve ser o número de volumes físicos subjacentes e o -I argumento é o tamanho da faixa.

      Por exemplo, se dois volumes físicos forem usados para o volume de dados, o -i argumento switch será definido como 2 e o tamanho da faixa para o volume de dados será 256KiB. 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

      Quando você usa mais de um volume físico para cada volume de dados, volume de log ou volume compartilhado, use o -i switch e defina o número de volumes físicos subjacentes. Ao criar um volume distribuído, use a -I opção para especificar o tamanho da faixa.

      Para obter as configurações de armazenamento recomendadas, incluindo tamanhos de distribuição e o número de discos, consulte Configurações de armazenamento SAP HANA VM.

      sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
      sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
      sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
      sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
      

   5. Crie os diretórios de montagem e copie o identificador universalmente exclusivo (UUID) de todos os volumes lógicos:

      sudo mkdir -p /hana/data/<HANA SID>
      sudo mkdir -p /hana/log/<HANA SID>
      sudo mkdir -p /hana/shared/<HANA SID>
      # Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
      sudo blkid
      

   6. Edite o arquivo /etc/fstab para criar fstab entradas para os três volumes lógicos:

      sudo vi /etc/fstab
      

   7. Insira as seguintes linhas no arquivo /etc/fstab :

      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2
      

   8. Monte os novos volumes:

      sudo mount -a
      

2. [A] Configure o layout do disco usando discos simples.

   Para sistemas de demonstração, você pode colocar seus dados HANA e arquivos de log em um disco.

   1. Crie uma partição em /dev/disk/azure/scsi1/lun0 e formate-a usando XFS:

      sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
      sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1
      
      # Write down the ID of /dev/disk/azure/scsi1/lun0-part1
      sudo /sbin/blkid
      sudo vi /etc/fstab
      

   2. Insira esta linha no arquivo /etc/fstab :

      /dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
      

   3. Crie o diretório de destino e monte o disco:

      sudo mkdir /hana
      sudo mount -a
      

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

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

   1. Edite o arquivo /etc/hosts :

      sudo vi /etc/hosts
      

   2. Insira as seguintes linhas no arquivo /etc/hosts . Altere os endereços IP e nomes de host para corresponder ao seu ambiente.

      10.0.0.5 hn1-db-0
      10.0.0.6 hn1-db-1
      

4. [A] Instale o SAP HANA, seguindo a documentação do SAP.

Configurar a replicação do sistema SAP HANA 2.0

As etapas nesta seção usam os seguintes prefixos:

• [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 do cluster Pacemaker.

Substitua <placeholders> pelos valores para sua instalação do SAP HANA.

1. [1] Crie a base de dados de inquilinos.

   Se você estiver usando o SAP HANA 2.0 ou o SAP HANA MDC, crie um banco de dados de locatário para seu sistema SAP NetWeaver.

   Execute o seguinte comando como <HANA SID>adm:

   hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
   

2. [1] Configure a replicação do sistema no primeiro nó:

   Primeiro, faça backup dos bancos de dados como <HANA SID>adm:

   hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')"
   hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')"
   hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"
   

   Em seguida, copie os arquivos PKI (infraestrutura de chave pública) do sistema para o site secundário:

   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/
   

   Crie o site principal:

   hdbnsutil -sr_enable --name=<site 1>
   

3. [2] Configure a replicação do sistema no segundo nó:

   Registre o segundo nó para iniciar a replicação do sistema.

   Execute o seguinte comando como <HANA SID>adm:

   sapcontrol -nr <instance number> -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
   

Implementar agentes de recursos HANA

A SUSE fornece dois pacotes de software diferentes para o agente de recursos do Pacemaker gerenciar o SAP HANA. Os pacotes de software SAPHanaSR e SAPHanaSR-angi estão usando sintaxe e parâmetros ligeiramente diferentes e não são compatíveis. Consulte as notas de versão e a documentação do SUSE para obter detalhes e diferenças entre SAPHanaSR e SAPHanaSR-angi. Este documento abrange ambos os pacotes em separadores separados nas respetivas secções.

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

sudo zypper install SAPHanaSR

sudo zypper install SAPHanaSR-angi

Configurar fornecedores SAP HANA HA/DR

Os provedores SAP HANA HA/DR otimizam a integração com o cluster e melhoram a deteção quando um failover de cluster é necessário. O script de gancho principal é SAPHanaSR (para o pacote SAPHanaSR) / susHanaSR (para SAPHanaSR-angi). É altamente recomendável que você configure o gancho SAPHanaSR/susHanaSR Python. Para HANA 2.0 SPS 05 e posterior, recomendamos que você implemente os ganchos SAPHanaSR/susHanaSR e susChkSrv.

O gancho susChkSrv estende a funcionalidade do provedor principal SAPHanaSR/susHanaSR HA. Ele age quando o processo HANA hdbindexserver falha. Se um único processo falhar, o HANA normalmente 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 o susChkSrv implementado, uma ação imediata e configurável é executada. A ação dispara um failover no período de tempo limite configurado em vez de aguardar que o processo hdbindexserver seja reiniciado no mesmo nó.

1. [A] Pare o HANA em ambos os nós.

Execute o seguinte código como <sap-sid>adm:

sapcontrol -nr <instance number> -function StopSystem

2. [A] Instale os ganchos de replicação do sistema HANA. Os ganchos devem ser instalados em ambos os nós do banco de dados HANA.

   Gorjeta

   O gancho SAPHanaSR Python pode ser implementado apenas para HANA 2.0. O pacote SAPHanaSR deve ter pelo menos a versão 0.153.
   O gancho SAPHanaSR-angi Python pode ser implementado apenas para HANA 2.0 SPS 05 e posterior.
   O gancho Python susChkSrv requer SAP HANA 2.0 SPS 05 e SAPHanaSR versão 0.161.1_BF ou posterior deve ser instalado.

   • SAPHanaSR
   • SAPHanaSR-angi

   1. [A] Ajuste global.ini em cada nó do cluster.

      Se os requisitos para o gancho susChkSrv não forem atendidos, remova o bloco inteiro [ha_dr_provider_suschksrv] dos seguintes parâmetros. Você pode ajustar o comportamento de susChkSrv usando o action_on_lost parâmetro. Os valores válidos são [ ignorefence | | stop | kill].

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR
      execution_order = 3
      action_on_lost = fence
      
      [trace]
      ha_dr_saphanasr = info
      

      Se você apontar o caminho do parâmetro para o local padrão /usr/share/SAPHanaSR , o código de gancho do Python será atualizado automaticamente por meio de atualizações do sistema operacional ou atualizações de pacote. O HANA usa as atualizações do código de gancho quando for reiniciado na próxima reinicialização. Com um caminho próprio opcional como /hana/shared/myHookso , você pode desacoplar as atualizações do sistema operacional da versão de gancho que você usa.

   2. [A] O cluster requer configuração de sudoers em cada nó de cluster para <sap-sid>adm. Neste exemplo, isso é conseguido através da criação de um novo ficheiro.

      Execute o seguinte comando como root. Substitua <sid> por ID de sistema SAP minúsculo, <SID> por ID de sistema SAP maiúsculo e <siteA/B> com nomes de site HANA escolhidos.

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

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

3. [A] Inicie o SAP HANA em ambos os nós. Execute o seguinte comando como <sap-sid>adm:

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] Verifique a instalação do gancho. Execute o seguinte comando como <sap-sid>adm no site de replicação do sistema HANA ativo:

   • SAPHanaSR
   • SAPHanaSR-angi

   cdtrace
   awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
   { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
   # Example output
   # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK
   

5. [1] Verifique a instalação do gancho susChkSrv. Execute o seguinte comando como <sap-sid>adm em VMs HANA:

   cdtrace
   egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
   # Example output
   # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
   # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
   # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)
   

Criar recursos de cluster do SAP HANA

1. [1] Primeiro, crie o recurso de topologia HANA.

sudo crm configure property maintenance-mode=true

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

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

sudo crm configure property maintenance-mode=true

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

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

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

2. [1] Em seguida, crie os recursos HANA:

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

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  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="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

# Run the following command if the cluster nodes are running on SLES 12 SP05.
sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true" promotable="true"

sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaCon_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop  interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op demote  interval="0" timeout="320"  \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  meta priority=100

sudo crm configure clone mst_SAPHanaCon_<HANA SID>_HDB<instance number> rsc_SAPHanaCon_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true" promotable="true"

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaFil_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFil_<HANA SID>_HDB<instance number> rsc_SAPHanaFil_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

3. [1] Continue com recursos de cluster para IPs virtuais, padrões e restrições.

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  msl_SAPHana_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Promoted  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHanaCon_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

Verifique se o status do cluster está OK e se todos os recursos foram iniciados. Não importa em qual nó os recursos estão sendo executados.

sudo crm_mon -r

# 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

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

No SAP HANA 2.0 SPS 01 e versões posteriores, o SAP permite uma configuração ativa/habilitada para leitura para replicação do sistema SAP HANA. Nesse cenário, os sistemas secundários de replicação do sistema SAP HANA podem ser usados ativamente para cargas de trabalho de leitura intensiva.

Para dar suporte a essa configuração em um cluster, um segundo endereço IP virtual é necessário para que os clientes possam acessar o banco de dados secundário SAP HANA habilitado para leitura. Para garantir que o local de replicação secundária ainda possa ser acessado após uma aquisição, o cluster precisa mover o endereço IP virtual com o secundário do recurso SAPHana.

Esta seção descreve as etapas adicionais necessárias para gerenciar uma replicação de sistema ativa/habilitada para leitura HANA em um cluster de alta disponibilidade SUSE que usa um segundo endereço IP virtual.

Antes de continuar, certifique-se de ter configurado totalmente o cluster de alta disponibilidade SUSE que gerencia o banco de dados SAP HANA, conforme descrito nas seções anteriores.

Configurar o balanceador de carga para replicação de sistema ativa/habilitada para leitura

Para prosseguir com etapas extras para provisionar o segundo IP virtual, verifique se você configurou o Azure Load Balancer conforme descrito em Implantar VMs Linux manualmente por meio do portal do Azure.

Para o balanceador de carga padrão , conclua essas etapas extras no mesmo balanceador de carga que você criou anteriormente.

1. Crie um segundo pool de IP front-end:
   1. Abra o balanceador de carga, selecione pool de IP frontend e selecione Adicionar.
   2. Digite o nome do segundo pool de IP front-end (por exemplo, hana-secondaryIP).
   3. Defina a Atribuição como Estática e insira o endereço IP (por exemplo, 10.0.0.14).
   4. Selecione OK.
   5. Depois que o novo pool de IP front-end for criado, anote o endereço IP front-end.
2. Crie uma sonda de integridade:
   1. No balanceador de carga, selecione testes de integridade e selecione Adicionar.
   2. Digite o nome da nova sonda de integridade (por exemplo, hana-secondaryhp).
   3. Selecione TCP como o protocolo e o número> da instância da porta 626<. Mantenha o valor Interval definido como 5 e o valor do limite Não íntegro definido como 2.
   4. Selecione OK.
3. Crie as regras de balanceamento de carga:
   1. No balanceador de carga, selecione regras de balanceamento de carga e selecione Adicionar.
   2. Insira o nome da nova regra do balanceador de carga (por exemplo, hana-secondarylb).
   3. Selecione o endereço IP front-end, o pool de back-end e a sonda de integridade que você criou anteriormente (por exemplo, hana-secondaryIP, hana-backend e hana-secondaryhp).
   4. Selecione Portas HA.
   5. Aumente o tempo limite de inatividade para 30 minutos.
   6. Certifique-se de ativar o IP flutuante.
   7. Selecione OK.

Configurar a replicação do sistema ativa/habilitada para leitura do HANA

As etapas para configurar a replicação do sistema HANA são descritas em Configurar a replicação do sistema SAP HANA 2.0. Se você estiver implantando um cenário secundário habilitado para leitura, ao configurar a replicação do sistema no segundo nó, execute o seguinte comando como <HANA SID>adm:

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess 

Adicionar um recurso de endereço IP virtual secundário

Você pode configurar o segundo IP virtual e a restrição de colocation apropriada usando os seguintes comandos:

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Unpromoted 

crm configure property maintenance-mode=false

Verifique se o status do cluster está OK e se todos os recursos foram iniciados. O segundo IP virtual é executado no site secundário juntamente com o recurso secundário SAPHana.

sudo crm_mon -r

# 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
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

A próxima seção descreve o conjunto típico de testes de failover a serem executados.

Considerações ao testar um cluster HANA configurado com um secundário habilitado para leitura:

• Quando você migra o recurso de SAPHana_<HANA SID>_HDB<instance number> cluster para hn1-db-1o , o segundo IP virtual é movido para hn1-db-0. Se você configurou AUTOMATED_REGISTER="false" e a replicação do sistema HANA não é registrada automaticamente, o segundo IP virtual é executado porque hn1-db-0 o servidor está disponível e os serviços de cluster estão online.

• Quando você testa uma falha de servidor, os segundos recursos IP virtuais (rsc_secip_<HANA SID>_HDB<instance number>) e o recurso de porta do balanceador de carga do Azure (rsc_secnc_<HANA SID>_HDB<instance number>) são executados no servidor primário junto com os recursos IP virtuais primários. Enquanto o servidor secundário está inativo, os aplicativos conectados a um banco de dados HANA habilitado para leitura se conectam ao banco de dados HANA primário. O comportamento é esperado porque você não deseja que os aplicativos conectados a um banco de dados HANA habilitado para leitura fiquem inacessíveis enquanto o servidor secundário não estiver disponível.

• Quando o servidor secundário está disponível e os serviços de cluster estão online, o segundo IP virtual e os recursos de porta são automaticamente movidos para o servidor secundário, mesmo que a replicação do sistema HANA possa não estar registrada como secundária. Certifique-se de registrar o banco de dados HANA secundário como habilitado para leitura antes de iniciar os serviços de cluster nesse servidor. Você pode configurar o recurso de cluster de instância HANA para registrar automaticamente o secundário definindo o parâmetro AUTOMATED_REGISTER="true".

• Durante o failover e o fallback, as conexões existentes para aplicativos, que estão usando o segundo IP virtual para se conectar ao banco de dados HANA, podem ser interrompidas.

Testar a configuração do cluster

Esta seção descreve como você pode testar sua configuração. Cada teste pressupõe que você esteja conectado como root e que o mestre do SAP HANA esteja sendo executado na hn1-db-0 VM.

Testar a migração

Antes de iniciar o teste, verifique se o Pacemaker não tem nenhuma ação com falha (executar crm_mon -r), se não há restrições de local inesperadas (por exemplo, sobras de um teste de migração) e se o HANA está em estado de sincronização, por exemplo, executando SAPHanaSR-showAttr.

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

hn1-db-0:~ # SAPHanaSR-showAttr
Global cib-update dcid prim      sec sid topology
--------------------------------------------------
global 0.130728.2 1    SITE1 -   HN1 ScaleUp

Resource                      promotable
-----------------------------------------
mst_SAPHanaCon_HN1_HDB03      true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns      opMode    srHook srMode srPoll srr
-----------------------------------------------------------------------
SITE1       1722604101 4   hn1-db-0 logreplay PRIM   sync   PRIM   P
SITE2       30         4   hn1-db-1 logreplay SWAIT  sync   SOK    S

Host     clone_state roles                        score site    sra srah version     vhost
---------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1   -   -    2.00.074.00 hn1-db-0
hn1-db-1 DEMOTED     master1:master:worker:master 100   SITE2       -    2.00.074.00 hn1-db-1

Host     clone_state roles                        score site      sra srah version     vhost
------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1     -   -    2.00.074.00 hn1-db-0
hn1-db-1                                                SITE2                          hn1-db-1

Você pode migrar o nó mestre do SAP HANA executando o seguinte comando:

crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force

O cluster migraria o nó principal do SAP HANA e o grupo que contém o endereço IP virtual para .hn1-db-1

Quando a migração estiver concluída, a saída será semelhante a crm_mon -r este exemplo:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 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-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

Com AUTOMATED_REGISTER="false"o , o cluster não reiniciaria o banco de dados HANA com falha nem o registraria no novo primário no hn1-db-0. Nesse caso, configure a instância HANA como secundária executando este comando:

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

A migração cria restrições de local que precisam ser excluídas novamente:

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>

Você também precisa limpar o estado do recurso de nó secundário:

hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Monitore o estado do recurso HANA usando crm_mon -r. Quando o HANA é iniciado no hn1-db-0, a saída se parece com este exemplo:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 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-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Bloquear a comunicação de rede

Estado do recurso antes de iniciar o teste:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 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-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Execute uma regra de firewall para bloquear a comunicação em um dos nós.

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

Quando os nós de cluster não conseguem se comunicar entre si, há um risco de um cenário de cérebro dividido. Em tais situações, os nós de cluster tentarão cercar simultaneamente uns aos outros, resultando em corrida de cerca.

Ao configurar um dispositivo de esgrima, é recomendável configurar pcmk_delay_max a propriedade. Assim, no caso de cenário de cérebro dividido, o cluster introduz um atraso aleatório até o pcmk_delay_max valor, para a ação de vedação em cada nó. O nó com o menor atraso será selecionado para esgrima.

Além disso, para garantir que o nó que executa o mestre HANA tenha prioridade e vença a corrida de cerca em um cenário de cérebro dividido, é recomendável definir priority-fencing-delay a propriedade na configuração do cluster. Ao habilitar a propriedade priority-fencing-delay, o cluster pode introduzir um atraso adicional na ação de esgrima especificamente no nó que hospeda o recurso mestre HANA, permitindo que o nó vença a corrida de cerca.

Execute o comando abaixo para excluir a regra de firewall.

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

Teste de esgrima SBD

Você pode testar a configuração do SBD matando o processo do inquisidor:

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

O <HANA SID>-db-<database 1> nó do cluster é reinicializado. O serviço Pacemaker pode não ser reiniciado. Certifique-se de iniciá-lo novamente.

Testar um failover manual

Você pode testar um failover manual interrompendo o serviço Pacemaker no hn1-db-0 nó:

service pacemaker stop

Após o failover, você pode iniciar o serviço novamente. Se você definir AUTOMATED_REGISTER="false", o recurso SAP HANA no hn1-db-0 nó não será iniciado como secundário.

Nesse caso, configure a instância HANA como secundária executando este comando:

service pacemaker start
su - <hana sid>adm

# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> 

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Testes SUSE

Execute todos os casos de teste listados no guia de cenários otimizados para desempenho do SAP HANA SR ou no guia de cenários otimizados para custos do SAP HANA SR, dependendo do seu cenário. Você pode encontrar os guias listados em SLES for SAP best practices.

Os testes a seguir são uma cópia das descrições de teste do guia SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 SP1. Para uma versão atualizada, leia também o próprio guia. Certifique-se sempre de que o HANA está sincronizado antes de iniciar o teste e certifique-se de que a configuração do Pacemaker está correta.

Nas descrições de teste a seguir, assumimos PREFER_SITE_TAKEOVER="true" e AUTOMATED_REGISTER="false".

1. Teste 1: Pare o banco de dados primário no nó 1.

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como <hana hn1-db-0 sid>adm no nó:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop
   

   O Pacemaker deteta a instância HANA parada e faz failover para o outro nó. Quando o failover é concluído, a instância HANA no nó é interrompida porque o hn1-db-0 Pacemaker não registra automaticamente o nó como HANA secundário.

   Execute os seguintes comandos para registrar o hn1-db-0 nó como secundário e limpar o recurso com falha:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   O estado do recurso após o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

2. Teste 2: Pare o banco de dados primário no nó 2.

   O estado do recurso antes de iniciar o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Execute os seguintes comandos como <hana hn1-db-1 sid>adm no nó:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stop
   

   O Pacemaker deteta a instância HANA parada e faz failover para o outro nó. Quando o failover é concluído, a instância HANA no nó é interrompida porque o hn1-db-1 Pacemaker não registra automaticamente o nó como HANA secundário.

   Execute os seguintes comandos para registrar o hn1-db-1 nó como secundário e limpar o recurso com falha:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   O estado do recurso após o teste:

   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
   

3. Teste 3: Travar o banco de dados primário no nó 1.

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como <hana hn1-db-0 sid>adm no nó:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9
   

   O Pacemaker deteta a instância HANA morta e faz failover para o outro nó. Quando o failover é concluído, a instância HANA no nó é interrompida porque o hn1-db-0 Pacemaker não registra automaticamente o nó como HANA secundário.

   Execute os seguintes comandos para registrar o hn1-db-0 nó como secundário e limpar o recurso com falha:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   O estado do recurso após o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

4. Teste 4: Travar o banco de dados primário no nó 2.

   O estado do recurso antes de iniciar o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Execute os seguintes comandos como <hana hn1-db-1 sid>adm no nó:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   O Pacemaker deteta a instância HANA morta e faz failover para o outro nó. Quando o failover é concluído, a instância HANA no nó é interrompida porque o hn1-db-1 Pacemaker não registra automaticamente o nó como HANA secundário.

   Execute os seguintes comandos para registrar o hn1-db-1 nó como secundário e limpar o recurso com falha.

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   O estado do recurso após o teste:

   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
   

5. Teste 5: Travar o nó do site primário (nó 1).

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como raiz no hn1-db-0 nó:

   hn1-db-0:~ #  echo 'b' > /proc/sysrq-trigger
   

   O Pacemaker deteta o nó de cluster morto e cerca o nó. Quando o nó é cercado, o Pacemaker aciona uma aquisição da instância HANA. Quando o nó cercado é reinicializado, o Pacemaker não é iniciado automaticamente.

   Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens SBD do hn1-db-0 nó, registre o hn1-db-0 nó como secundário e limpe o recurso com falha:

   # run as root
   # list the SBD device(s)
   hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear
   
   hn1-db-0:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   O estado do recurso após o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

6. Teste 6: Travar o nó do site secundário (nó 2).

   O estado do recurso antes de iniciar o teste:

   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-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Execute os seguintes comandos como raiz no hn1-db-1 nó:

   hn1-db-1:~ #  echo 'b' > /proc/sysrq-trigger
   

   O Pacemaker deteta o nó de cluster morto e cerca o nó. Quando o nó é cercado, o Pacemaker aciona uma aquisição da instância HANA. Quando o nó cercado é reinicializado, o Pacemaker não é iniciado automaticamente.

   Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens SBD do hn1-db-1 nó, registre o hn1-db-1 nó como secundário e limpe o recurso com falha:

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   O estado do recurso após o teste:

   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
   </code></pre>
   

7. Teste 7: Pare o banco de dados secundário no nó 2.

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como <hana hn1-db-1 sid>adm no nó:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop
   

   O Pacemaker deteta a instância HANA parada e marca o recurso como falha no hn1-db-1 nó. O Pacemaker reinicia automaticamente a instância HANA.

   Execute o seguinte comando para limpar o estado de falha:

   # run as root
   hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   O estado do recurso após o teste:

   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
   

8. Teste 8: Travar o banco de dados secundário no nó 2.

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como <hana hn1-db-1 sid>adm no nó:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   O Pacemaker deteta a instância HANA morta e marca o recurso como falha no hn1-db-1 nó. Execute o seguinte comando para limpar o estado de falha. Em seguida, o Pacemaker reinicia automaticamente a instância HANA.

   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1
   

   O estado do recurso após o teste:

   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
   

9. Teste 9: Travar o nó do site secundário (nó 2) que está executando o banco de dados HANA secundário.

   O estado do recurso antes de iniciar o teste:

   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
   

   Execute os seguintes comandos como raiz no hn1-db-1 nó:

   hn1-db-1:~ # echo b > /proc/sysrq-trigger
   

   O Pacemaker deteta o nó de cluster morto e cerca o nó. Quando o nó cercado é reinicializado, o Pacemaker não é iniciado automaticamente.

   Execute os seguintes comandos para iniciar o Pacemaker, limpar as mensagens SBD do hn1-db-1 nó e limpar o recurso com falha:

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker  
   
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   O estado do recurso após o teste:

   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
   

10. Teste 10: Falha do indexserver do banco de dados primário

    Este teste é relevante somente quando você configurou o gancho susChkSrv, conforme descrito em Implementar agentes de recursos HANA.

    O estado do recurso antes de iniciar o teste:

    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
    

    Execute os seguintes comandos como raiz no hn1-db-0 nó:

    hn1-db-0:~ # killall -9 hdbindexserver
    

    Quando o indexserver é encerrado, o gancho susChkSrv deteta o evento e dispara uma ação para cercar o nó 'hn1-db-0' e iniciar um processo de aquisição.

    Execute os seguintes comandos para registrar hn1-db-0 o nó como secundário e limpar o recurso com falha:

    # run as <hana sid>adm
    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
    

    O estado do recurso após o teste:

    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-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    

    Você pode executar um caso de teste comparável fazendo com que o indexserver no nó secundário falhe. No caso de falha do indexserver, o gancho susChkSrv reconhece a ocorrência e inicia uma ação para cercar o nó secundário.

Próximos passos

• Planejamento e implementação de Máquinas Virtuais do Azure para SAP
• Implantação de Máquinas Virtuais do Azure para SAP
• Implantação de DBMS de Máquinas Virtuais do Azure para SAP