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

Artigo
10/16/2024

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

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

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

Este artigo descreve como implantar e configurar as VMs, instalar a estrutura de cluster e instalar e configurar a replicação de sistema do 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 que têm suporte para a implantação de software SAP.
- Informações importantes sobre capacidade para tamanhos de VM do Azure.
- O software, as combinações de SO (sistema operacional) e de banco de dados do SAP com suporte.
- As versões de kernel do SAP necessária para Windows e Linux no Microsoft Azure.
A Nota SAP 2015553 lista os pré-requisitos para implantações de software SAP com suporte do SAP no Azure.
A Nota SAP 2205917 recomendou as configurações de sistema operacional para SLES 12 (SUSE Linux Enterprise Server 12) para aplicativos SAP.
A Nota SAP 2684254 recomendou as configurações de sistema operacional para SLES 15 (SUSE Linux Enterprise Server 15) para aplicativos SAP.
A Nota SAP 2235581 tem sistemas operacionais com suporte para SAP HANA
A nota SAP 2178632 contém informações detalhadas sobre todas as métricas de monitoramento relatadas para o SAP no Azure.
A nota SAP 2191498 tem a versão necessária do agente host do SAP para o Linux no Azure.
A nota SAP 2243692 tem informações sobre o licenciamento do SAP para o Linux no Azure.
A Nota SAP 1984787 tem informações gerais sobre o SUSE Linux Enterprise Server 12.
A Nota SAP 1999351 tem mais informações de solução de problemas para a Extensão de Monitoramento Avançado do Azure para SAP.
A nota SAP 401162 tem informações sobre como evitar erros de "endereço já em uso" ao configurar a replicação de sistema do HANA.
O Wiki da comunidade de suporte do SAP tem todas as Notas do SAP necessárias para o Linux.
Plataformas de IaaS certificada do SAP HANA.
Guia de Planejamento e implementação de Máquinas Virtuais do Azure para SAP no Linux.
Guia Implantação de Máquinas Virtuais do Azure para o SAP no Linux.
Guia de Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux.
Guias de melhores práticas do SUSE Linux Enterprise Server para aplicativos SAP 15 e guias de melhores práticas do SUSE Linux Enterprise Server para aplicativos SAP 12:
- Configuração de uma infraestrutura otimizada de desempenho do SAP HANA SR (SLES para aplicativos do SAP). O guia contém todas as informações necessárias para configurar a replicação do sistema do SAP HANA para desenvolvimento local. Use este guia como uma linha de base.
- Configuração de uma infraestrutura otimizada para custo de SR do SAP HANA (SLES para aplicativos SAP).

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 de sistema do HANA.

Diagrama que mostra uma visão geral de alta disponibilidade do SAP HANA.

A configuração da replicação de sistema do SAP HANA usa um nome do 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 balanceador de carga de exemplo que tem estas configurações:

Endereço IP do front-end: 10.0.0.13 para HN1-db
Porta de investigação: 62503

Preparar a infraestrutura

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

Implantar VMs do Linux manualmente por meio do portal do Azure

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

Implantar máquinas virtuais para SAP HANA. Escolha uma imagem SLES adequada com suporte para o sistema HANA. Você pode implementar a VM em qualquer uma das opções de disponibilidade, conjunto de dimensionamento de máquinas virtuais, zona de disponibilidade ou conjunto de disponibilidade.

Importante

Certifique-se de que o sistema operacional selecionado conte com a certificação SAP para o SAP HANA para os tipos de VM específicas que você planeja usar em sua implantação. Você pode pesquisar tipos de VM certificadas pelo SAP HANA e suas versões do sistema operacional nas Plataformas de IaaS Certificadas do SAP HANA. Certifique-se de clicar nos detalhes do tipo de VM para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para o tipo de VM específico.

Configurar o Azure Load Balancer

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

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:

Configuração de IP front-end: Crie um IP front-end. Selecione a mesma rede virtual e nome de sub-rede das máquinas virtuais de banco de dados.
Pool de back-end: Crie um pool de back-end e adicione VMs de banco de dados.
Regras de entrada: Crie uma regra de balanceamento de carga. Siga as mesmas etapas para ambas as regras de balanceamento de carga.
- Endereço IP de front-end: Selecione um IP de front-end.
- Pool de back-end: selecione um pool de back-end.
- Portas de alta disponibilidade: selecione essa opção.
- Protocolo: selecione TCP.
- Sonda de integridade: crie uma sonda de integridade com os seguintes detalhes:
  - Protocolo: selecione TCP.
  - Porta: Por exemplo, 625<instância-não.>.
  - Intervalo: Inserir 5.
  - Limite de investigação: insira 2.
- Tempo limite de inatividade (minutos): Inserir 30.
- Habilitar IP Flutuante: Selecione essa opção.

Observação

A propriedade de configuração da investigação de integridade numberOfProbes, também conhecida como Limite não íntegro no portal, não é respeitada. Para controlar o número de análises consecutivas bem-sucedidas ou com falha, configure a propriedade probeThreshold para 2. Atualmente não é possível definir essa propriedade utilizando o portal do Azure, por isso utilize o CLI do Azure ou o comando PowerShell.

# 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

Expandir para exibir o código completo da CLI

# 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

Expandir para exibir o código completo do PowerShell

# 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 aos bancos de dados de locatário no guia Bancos de dados de locatário do SAP HANA ou Nota SAP 2388694.

Observação

Quando as VMs que não têm endereços IP públicos são colocadas no pool de back-end de uma instância padrão interna (sem endereço IP público) do Azure Load Balancer, a configuração padrão não é nenhuma conectividade de saída com a Internet. Você pode executar etapas extras para permitir o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como alcançar conectividade de saída, veja Conectividade de ponto de extremidade público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade do SAP.

Importante

Não habilite carimbos de data/hora de TCP em VMs do Azure que estão posicionadas de forma subjacente em relação ao Azure Load Balancer. Habilitar carimbos de data/hora de TCP faz as investigações de integridade falharem. Defina o parâmetro net.ipv4.tcp_timestamps como 0. Para obter detalhes, confira Investigações de integridade do Load Balancer ou a nota do SAP 2382421.
Para evitar que o saptune altere o valor net.ipv4.tcp_timestamps definido manualmente de 0 para 1, atualize a versão do saptune para 3.1.1 ou superior. Para obter mais detalhes, confira saptune 3.1.1 - Preciso atualizar?.

Criar um cluster do Pacemaker

Siga as etapas em Configurar Pacemaker no SUSE Linux Enterprise Server no Azure para criar um cluster Pacemaker básico para esse servidor HANA. É possível usar o mesmo cluster do Pacemaker para SAP HANA e SAP NetWeaver (A)SCS.

Instalar SAP HANA

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

[A] : A etapa se aplica a todos os nós.
[1]: A etapa se aplica somente ao nó 1.
[2]: A etapa se aplica somente ao nó 2 do cluster do Pacemaker.

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

[A] Configure o layout do disco usando o LVM (Gerenciador de Volume Lógico).

É recomendável que você use o LVM para volumes que armazenam dados e arquivos de log. O exemplo a seguir considera que as VMs têm 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*
```
  Exemplo de saída:
```
/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. Criar os volumes lógicos.
  
  Um volume linear é criado quando você usa lvcreate sem a opção -i. Sugerimos que você crie um volume distribuído para melhorar o desempenho de E/S. Alinhe os tamanhos das distribuições aos valores descritos nas configurações de armazenamento de VM do SAP HANA. O argumento -i deve ser o número de volumes físicos subjacentes e o argumento -I é o tamanho da distribuição.
  
  Por exemplo, se dois volumes físicos forem usados para o volume de dados, o argumento de opção -i será definido como 2 e o tamanho da distribuição do volume de dados será 256KiB. Um volume físico é usado para o volume do log, portanto, nenhuma opção -i ou -I é usada explicitamente para os comandos do volume do log.
  
  Importante
  
  Ao usar mais de um volume físico para cada volume de dados, de log ou compartilhado, use a opção -i e defina-a para o número do volumes físicos subjacentes. Ao criar um volume distribuído, use a opção -I para especificar o tamanho da distribuição.
  
  Para obter as configurações de armazenamento recomendadas, incluindo tamanhos de distribuição e número de discos, confira as Configurações de armazenamento de VM do SAP HANA.
```
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 UUID (identificador universal exclusivo) 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 entradas fstab 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
```
[A] Configure o layout do disco usando discos simples.

Para sistemas de demonstração, você pode colocar os arquivos de log e dados do HANA em um disco.
1. Crie uma partição em /dev/disk/azure/scsi1/lun0 e formate-a usando o 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
```
[A] Configure a resolução do nome do host para todos os hosts.

É possível 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 do 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 os nomes do host para corresponder ao seu ambiente.
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[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:

[A] : A etapa se aplica a todos os nós.
[1]: A etapa se aplica somente ao nó 1.
[2]: A etapa se aplica somente ao nó 2 do cluster do Pacemaker.

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

[1] Crie o banco de dados de locatário.

Se você estiver usando o SAP HANA 2.0 ou o MDC do SAP HANA, crie um banco de dados de locatário para o 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>"'
```

[1] Configure a replicação de 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 da 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 primário:

hdbnsutil -sr_enable --name=<site 1>

[2] Configure a replicação de sistema no segundo nó:

Registre o segundo nó para iniciar a replicação de 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 do HANA

O 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 uma sintaxe e parâmetros ligeiramente diferentes e não são compatíveis. Confira as notas de versão do SUSE e a documentação para obter detalhes e diferenças entre o SAPHanaSR e o SAPHanaSR-angi. Esse documento aborda os dois pacotes em guias separadas nas respectivas seções.

Aviso

Não substitua o pacote SAPHanaSR pelo SAPHanaSR-angi em um cluster já configurado. O upgrade do SAPHanaSR para o SAPHanaSR-angi requer um procedimento específico.

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

SAPHanaSR
SAPHanaSR-angi

Execute o seguinte comando para instalar os pacotes de alta disponibilidade:

sudo zypper install SAPHanaSR

Importante

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

Execute o seguinte comando para instalar os pacotes de alta disponibilidade:

sudo zypper install SAPHanaSR-angi

Configurar provedores de HA/DR do SAP HANA

Os provedores de HA/DR do SAP HANA otimizam a integração com o cluster e aprimoram a detecção quando um failover do cluster é necessário. O script do gancho principal é SAPHanaSR (para o pacote SAPHanaSR) / susHanaSR (para SAPHanaSR-angi). Recomendamos fortemente que você configure o gancho do Python SAPHanaSR/susHanaSR. Para o HANA 2.0 SPS 05 e posterior, recomendamos que você implemente tanto o gancho SAPHanaSR/susHanaSR quanto o gancho susChkSrv.

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

Com o susChkSrv implementado, uma ação imediata e configurável é executada. A ação dispara um failover durante o período de tempo limite configurado em vez de aguardar que o processo hdbindexserver seja reiniciado no mesmo nó.

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

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

sapcontrol -nr <instance number> -function StopSystem

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

Dica

O gancho Python do SAPHanaSR pode ser implementado para o HANA 2.0. O pacote SAPHanaSR deve ser pelo menos da versão 0.153.
O gancho do Python SAPHanaSR-angi só pode ser implementado para o HANA 2.0 SPS 05 e posterior.
O gancho do Python susChkSrv requer o SAP HANA 2.0 SP5 e a versão do SAPHanaSR 0.161.1_BF ou posterior precisa estar instalada.
- SAPHanaSR
- SAPHanaSR-angi
1. [A] Ajuste o global.ini em cada nó do cluster.
  
  Se os requisitos para o gancho susChkSrv não forem atendidos, remova todo o bloco [ha_dr_provider_suschksrv] dos parâmetros a seguir. Você pode ajustar o comportamento de susChkSrv usando o parâmetro action_on_lost. Os valores válidos são: [ ignore | stop | kill | fence ].
```
[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 /usr/share/SAPHanaSR padrão, o código de gancho do Python será atualizado automaticamente por meio de atualizações do sistema operacional ou de atualizações do pacote. O HANA usará as atualizações de código de gancho quando for reiniciado na próxima vez. Com um caminho próprio opcional como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional da versão do gancho que você estiver usando.
2. [A] O cluster requer a configuração do sudoers em cada nó do cluster para <sap-sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo.
  
  Execute o comando a seguir como raiz. Substitua o <sid> pela ID do sistema SAP em minúsculas, o <SID> pela ID do sistema SAP em maiúsculas e <siteA/B> pelos nomes de site do HANA escolhidos.
```
cat << EOF > /etc/sudoers.d/20-saphana
# 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 como implementar o gancho de replicação do sistema SAP HANA, consulte Configurar provedores de HA/DR do HANA.
1. [A] Ajuste o global.ini em cada nó do cluster.
  
  Se você optar por não usar o gancho susChkSrv recomendado, remova todo o bloco [ha_dr_provider_suschksrv] dos parâmetros a seguir. Você pode ajustar o comportamento de susChkSrv usando o parâmetro action_on_lost. Os valores válidos são: [ ignore | stop | kill | fence ].
```
[ha_dr_provider_sushanasr]
provider = susHanaSR
path = /usr/share/SAPHanaSR-angi
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-angi
execution_order = 3
action_on_lost = fence

[trace]
ha_dr_sushanasr = info
ha_dr_saphanasr = info
```
  Se você apontar o caminho do parâmetro para o local /usr/share/SAPHanaSR-angi padrão, o código de gancho do Python será atualizado automaticamente por meio de atualizações do sistema operacional ou de atualizações do pacote. O HANA usará as atualizações de código de gancho quando for reiniciado na próxima vez. Com um caminho próprio opcional como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional da versão do gancho que você estiver usando.
2. [A] O cluster requer a configuração do sudoers em cada nó do cluster para <sap-sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo.
  
  Execute o comando a seguir como raiz. Substitua o <sid> pela ID do sistema SAP em minúsculas, o <SID> pela ID do sistema SAP em maiúsculas e <siteA/B> pelos nomes de site do HANA escolhidos.
```
cat << EOF > /etc/sudoers.d/20-saphana
# Needed for susHanaSR 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/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
Cmnd_Alias HELPER_FENCE     = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe

<sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
EOF
```
  Para obter detalhes sobre como implementar o gancho de replicação do sistema SAP HANA, consulte Configurar provedores de HA/DR do HANA.

[A] Iniciar o SAP HANA em ambos os nós. Execute o seguinte comando como um <sap-sid>adm:
```
sapcontrol -nr <instance number> -function StartSystem 
```

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

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

cdtrace
grep HADR.*load.*SAPHanaSR nameserver_*.trc
# Example output
# ha_dr_provider HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi

[1] Verifique a instalação do gancho susChkSrv. Execute o seguinte comando como um <sap-sid>adm em todas as VMs do 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)

Crie os recursos de cluster do SAP HANA

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

SAPHanaSR
SAPHanaSR-angi

Execute os seguintes comandos em um dos nós de cluster do Pacemaker:

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"

Execute os seguintes comandos em um dos nós de cluster do Pacemaker:

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"

[1] A seguir, crie os recursos do HANA:

SAPHanaSR
SAPHanaSR-angi

Observação

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

# 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"

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

Recomendamos implementar o SAPHanaFilesystem se você estiver usando o NFS para o local do /hana/shared/SID. Quando o /hana/shared/SID estiver localizado em um dispositivo de blocos, como o disco gerenciado do Azure, o uso do SAPHanaFilesystem será opcional.

# 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"

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

SAPHanaSR
SAPHanaSR-angi

# 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

Importante

É recomendável definir AUTOMATED_REGISTER como false apenas enquanto concluir testes de failover completos, para impedir que uma instância primária com falha se registre automaticamente como secundária. Quando os testes de failover forem concluídos com êxito, defina AUTOMATED_REGISTER como true, para que após a aquisição, a replicação do sistema seja retomada automaticamente.

Verifique se o status do cluster é OK e se todos os recursos iniciaram. 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 de sistema ativa/habilitada para leitura do HANA em um cluster do Pacemaker

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

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

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

Antes de continuar, verifique se você configurou totalmente o cluster de alta disponibilidade do SUSE que gerencia o banco de dados SAP HANA, conforme descrito nas seções anteriores.

Diagrama que mostra um exemplo de alta disponibilidade do SAP HANA com um IP secundário habilitado para leitura.

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

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

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

Crie um segundo pool de IPs de front-end:
1. Abra o balanceador de carga, selecione pool de front-end e selecione Adicionar.
2. Insira o nome do segundo pool de IPs de front-end (por exemplo, hana-secondaryIP).
3. Defina a Atribuição como Estático e insira o endereço IP (por exemplo, 10.0.0.14).
4. Selecione OK.
5. Depois que o novo pool de IPs de front-end for criado, anote o endereço IP do front-end.
Crie uma investigação de integridade:
1. No balanceador de carga, selecione investigações de integridade e selecione Adicionar.
2. Insira o nome da nova investigação 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 do Intervalo como 5 e o valor Limite não íntegro como 2.
4. Selecione OK.
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 de front-end, o pool de back-end e a investigação de integridade que você criou anteriormente (por exemplo, hana-secondaryIP, hana-backend e hana-secondaryhp).
4. Selecione Portas de HA.
5. Aumente o tempo limite ocioso para 30 minutos.
6. Lembre-se de Habilitar o IP flutuante.
7. Selecione OK.

Configurar a replicação de 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 do 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 colocação apropriada usando os seguintes comandos:

SAPHanaSR
SAPHanaSR-angi

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 é OK e se todos os recursos iniciaram. O segundo IP virtual é executado no site secundário com o recurso secundário do 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 de testes típico de failover a serem executados.

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

Quando você migra o recurso de cluster SAPHana_<HANA SID>_HDB<instance number> para hn1-db-1, o segundo IP virtual é movido para hn1-db-0. Se você tiver configurado AUTOMATED_REGISTER="false" e a replicação do sistema do HANA não for registrada automaticamente, o segundo IP virtual será executado em hn1-db-0 porque o servidor está disponível e os serviços de cluster estão online.
Quando você testa uma falha do servidor, os recursos do segundo IP virtual (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>) executam no servidor primário com os recursos de IP virtual primários. Enquanto o servidor secundário está inativo, os aplicativos que estão 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 se movem automaticamente para o servidor secundário, mesmo que a replicação do sistema HANA não possa ser registrada como secundária. Verifique se você registrou o banco de dados secundário do HANA como habilitado para leitura antes de iniciar os serviços de cluster nesse servidor. Você pode configurar o recurso de cluster da instância do 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 do HANA podem ser interrompidas.

Testar a configuração do cluster

Esta seção descreve como é possível testar a configuração. Cada teste pressupõe que você está conectado como raiz e que o mestre do SAP HANA está em execução na VM hn1-db-0.

Testar a migração

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

SAPHanaSR
SAPHanaSR-angi

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

É possível migrar o nó mestre do SAP HANA executando o comando a seguir:

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

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

Quando a migração for concluída, a saída crm_mon -r será semelhante a 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 o AUTOMATED_REGISTER="false", o cluster não conseguiria reiniciar o banco de dados do HANA com falha nem registrá-lo no novo primário em hn1-db-0. Nesse caso, configure a instância do 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>

Também é necessário 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 do HANA usando crm_mon -r. Quando o HANA é iniciado em hn1-db-0, a saída é semelhante a 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 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 a 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 nós de cluster não podem se comunicar entre si, há o risco de um cenário de divisão cerebral. Nessas situações, os nós de cluster tentarão isolar uns aos outros simultaneamente, resultando em disputa por limites.

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

Além disso, para garantir que o nó que executa o mestre do HANA tenha prioridade e ganhe a disputa por limites em um cenário de partição de rede, é recomendável definir a propriedade priority-fencing-delay na configuração do cluster. Ao habilitar a propriedade priority-fencing-delay, o cluster pode introduzir um atraso adicional na ação de isolamento especificamente no nó que hospeda o recurso mestre do HANA, permitindo que o nó ganhe a disputa por limites.

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

Testar isolamento de SBD

É possível testar a configuração de SBD eliminando o processo de 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 nó do cluster <HANA SID>-db-<database 1> é reinicializado. O serviço Pacemaker pode não ser reinicializado. Certifique-se de inicializá-lo novamente.

Testar um failover manual

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

service pacemaker stop

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

Nesse caso, configure a instância do 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 de SUSE

Importante

Confira se o sistema operacional selecionado conta com a certificação SAP para o SAP HANA nos tipos de VM específicas que você planeja usar. Você pode pesquisar tipos de VM certificadas pelo SAP HANA e suas versões do sistema operacional nas Plataformas de IaaS Certificadas do SAP HANA. Certifique-se de clicar nos detalhes do tipo de VM que você planeja usar para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para desse tipo de VM.

Execute todos os casos de teste listados no guia Cenário otimizado para desempenho do SR do SAP HANA ou Cenário otimizado para custo do SR do SAP HANA, dependendo do cenário. Você pode encontrar os guias listados em Melhores práticas de SLES para o SAP.

Os testes a seguir são uma cópia das descrições de teste do guia de Cenário otimizado para desempenho do SR do SAP HANA do SUSE Linux Enterprise Server para Aplicativos SAP 12 SP1. Para uma versão atualizada, leia também o próprio guia. Antes de iniciar o teste, sempre verifique se o HANA está sincronizado e se a configuração do Pacemaker está correta.

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

Observação

Os testes a seguir foram projetados para serem executados em sequência. Cada teste depende do estado de saída do teste anterior.

Teste 1: parar 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 sid>adm no nó hn1-db-0:

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

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

Execute os seguintes comandos para registrar o nó hn1-db-0 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

Teste 2: parar 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 sid>adm no nó hn1-db-1:

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

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

Execute os seguintes comandos para registrar o nó hn1-db-1 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

Teste 3: 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 sid>adm no nó hn1-db-0:

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

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

Execute os seguintes comandos para registrar o nó hn1-db-0 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

Teste 4: 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 sid>adm no nó hn1-db-1:

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

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

Execute os seguintes comandos para registrar o nó hn1-db-1 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

Teste 5: obter falha no nó de 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 comandos a seguir como raiz no nó hn1-db-0:

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

O Pacemaker detecta o nó do cluster encerrado e isola o nó. Depois que o nó é isolado, o Pacemaker dispara a tomada de controle da instância do HANA. Quando o nó isolado é reiniciado, o Pacemaker não inicializa automaticamente.

Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens de SBD do nó hn1-db-0, registre o nó hn1-db-0 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

Teste 6: obter falha no nó de 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 comandos a seguir como raiz no nó hn1-db-1:

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

Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens de SBD do nó hn1-db-1, registre o nó hn1-db-1 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>

Teste 7: interromper 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 sid>adm no nó hn1-db-1:

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

O Pacemaker detecta a instância do HANA interrompida e marca o recurso como com falha no nó hn1-db-1. O Pacemaker reinicia automaticamente a instância do HANA.

Execute o seguinte comando para limpar o estado com 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

Teste 8: banco de dados secundário com falha 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 sid>adm no nó hn1-db-1:

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

O Pacemaker detecta a instância do HANA encerrada e marca o recurso como com falha no nó hn1-db-1. Execute o seguinte comando para limpar o estado com falha. Em seguida, o Pacemaker reinicia automaticamente a instância do 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

Teste 9: obter falha do nó do site secundário (nó 2) que está executando o banco de dados secundário do 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 comandos a seguir como raiz no nó hn1-db-1:

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

O Pacemaker detecta o nó do cluster encerrado e isola o nó. Quando o nó isolado é reiniciado, o Pacemaker não inicializa automaticamente.

Execute os seguintes comandos para iniciar o Pacemaker, limpe as mensagens de SBD para o nó hn1-db-1 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  

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

Teste 10: obter falha do indexserver de banco de dados primário

Esse teste é relevante somente quando você configura o gancho susChkSrv, conforme descrito em Implementar agentes de recursos do 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 comandos a seguir como raiz no nó hn1-db-0:

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

Quando o indexserver é encerrado, o gancho susChkSrv detecta o evento e dispara uma ação para isolar o nó "hn1-db-0" e iniciar o processo de assumir o controle.

Execute os seguintes comandos para registrar o nó hn1-db-0 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 obtenha falha. Na eventualidade de o indexserver falhar, o gancho susChkSrv reconhecerá a ocorrência e irá iniciar uma ação para isolar o nó secundário.

Compartilhar via

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

Planejar a alta disponibilidade do SAP HANA

Preparar a infraestrutura

Implantar VMs do Linux manualmente por meio do portal do Azure

Configurar o Azure Load Balancer

Criar um cluster do Pacemaker

Instalar SAP HANA

Configurar a replicação do sistema SAP HANA 2.0

Implementar agentes de recursos do HANA

Configurar provedores de HA/DR do SAP HANA

Crie os recursos de cluster do SAP HANA

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

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

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

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

Testar a configuração do cluster

Testar a migração

Bloquear comunicação de rede

Testar isolamento de SBD

Testar um failover manual

Testes de SUSE

Próximas etapas

Comentários

Recursos adicionais