Alta disponibilidade do SAP HANA em VMs do Azure no Red Hat Enterprise Linux

Artigo
12/04/2024

Para desenvolvimento local, é possível usar a replicação de sistema do HANA ou o armazenamento compartilhado para estabelecer alta disponibilidade (HA) para SAP HANA. Em Máquinas Virtuais do Azure, a replicação de sistema do HANA no Azure é atualmente a única função de HA com suporte.

A replicação 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 VMs (máquinas virtuais), instalar a estrutura de cluster e instalar e configurar a replicação de sistema do SAP HANA.

Nas configurações de exemplo, são usados os comandos de instalação, o número da instância 03 a ID do Sistema do HANA HN1.

Pré-requisitos

Primeiro, leia os seguintes documentos e Notas SAP:

A Nota SAP 1928533, que tem:
- 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 SAP, combinações de SO (sistema operacional) e banco de dados com suporte.
- A versão do kernel do SAP necessária para Windows e Linux no Microsoft Azure.
A Nota SAP 2015553 lista pré-requisitos para implantações de software SAP com suporte do SAP no Azure.
A Nota SAP 2002167 recomendou configurações do sistema operacional para o Red Hat Enterprise Linux.
A Nota SAP 2009879 tem diretrizes SAP HANA para Red Hat Enterprise Linux.
A Nota SAP 3108302 tem diretrizes SAP HANA para Red Hat Enterprise Linux 9.x.
A Nota SAP 2178632 contém informações detalhadas sobre todas as métricas de monitoramentos relatadas para o SAP no Azure.
A Nota SAP 2191498 tem a versão necessária do SAP Host Agent para Linux no Azure.
A Nota SAP 2243692 tem informações sobre o licenciamento do SAP no Linux no Azure.
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.
WIKI da comunidade do SAP tem todas as Notas SAP necessárias para Linux.
Planejamento e implementação de Máquinas Virtuais do Azure para SAP no Linux
Implantação de Máquinas Virtuais do Azure para SAP no Linux (este artigo)
Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux
Replicação de sistema SAP HANA em um cluster Pacemaker
Documentação geral do RHEL:
Documentação do RHEL específica do Azure:

Visão geral

Para obter HA, o SAP HANA é instalado em duas VMs. Os dados são replicados usando a Replicação de Sistema do HANA.

Diagrama que mostra a 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, um balanceador de carga é necessário para usar um endereço IP virtual. A configuração apresentada mostra um balanceador de carga com:

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

Preparar a infraestrutura

O Azure Marketplace contém imagens qualificadas para SAP HANA com o complemento de alta disponibilidade, que você pode usar para implantar novas VMs usando várias versões do Red Hat.

Implantar VMs do Linux manualmente por meio do portal do Azure

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

Implantar VMs para SAP HANA. Escolha uma imagem RHEL adequada com suporte para o sistema HANA. Você pode implantar uma 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 VMs sem endereços IP públicos são colocados no pool de back-end de uma instância interna (sem endereço IP público) do Standard Azure Load Balancer, não há conectividade de saída com a Internet, a menos que seja realizada mais configuração para permitir o roteamento para pontos extremidade públicos. Para obter mais informações sobre como obter conectividade de saída, veja Conectividade de ponto final público para VMs usando o Azure Standard Load Balancer em cenários de alta disponibilidade SAP.

Importante

Não habilite carimbos de data/hora de TCP em VMs do Azure posicionadas de forma subjacente em relação ao Azure Load Balancer. Habilitar carimbos de data/hora TCP pode causar falha nas sondagens de integridade. Defina o parâmetro net.ipv4.tcp_timestampscomo 0. Para saber mais, confira Investigações de integridade do Load Balancer e Nota SAP 2382421.

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 apenas ao nó 1.
[2] : A etapa se aplica ao nó 2 do cluster do Pacemaker apenas.

[A] Configurar o layout de disco: discos sem formatação: Gerenciamento de volumes lógicos (LVM) .

É recomendável que você use o LVM para volumes que armazenam dados e arquivos de log. O exemplo a seguir considera que as VMs tem quatro discos de dados anexados que são usados para criar dois volumes.

Listar todos os discos disponíveis:
```
ls /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
```
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
```
Crie um grupo de volumes para os arquivos de dados. Use um grupo de volumes para os arquivos de log e outro para o diretório compartilhado do SAP HANA:
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
```
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 documentados 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 faixa.

Neste documento, dois volumes físicos são usados para o volume de dados, portanto, o argumento da chave -i é definido com 2. O tamanho da distribuição para o volume de dados é de 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

Use a opção -i e defina-a para o número do volume físico subjacente quando você usar mais de um volume físico para cada volume de dados, log ou compartilhado. Use a opção -I para especificar o tamanho da distribuição na criação de um volume distribuído. Veja Configurações de armazenamento de VM do SAP HANA para ver as configurações de armazenamento recomendadas, incluindo tamanhos de distribuição e número de discos. Os exemplos de layout a seguir não atendem necessariamente às diretrizes de desempenho de um determinado tamanho do sistema. Eles servem apenas para ilustração.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
```
Não monte os diretórios emitindo comandos de montagem. Em vez disso, insira as configurações no fstab e emita uma final mount -a para validar a sintaxe. Comece criando os diretórios de montagem para cada volume:
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
Em seguida, crie entradas de fstab para os três volumes lógicos inserindo as seguintes linhas no arquivo /etc/fstab:

/dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 2

Por fim, monte os novos volumes de uma só vez:
```
sudo mount -a
```
[A] Configure a resolução do nome do host de todos os hosts.

Você pode usar um servidor DNS ou modificar o arquivo /etc/hosts em todos os nós criando entradas para todos os nós como este em /etc/hosts:

10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] Execute o RHEL para configuração do HANA.

Configure o RHEL conforme descrito nas seguintes notas:
[A] Instale o SAP HANA, seguindo a documentação do SAP.

[A] Configurar o firewall.

Crie a regra de firewall para a porta de investigação do Azure Load Balancer.

sudo firewall-cmd --zone=public --add-port=62503/tcp
sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent

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 apenas ao nó 1.
[2] : A etapa se aplica ao nó 2 do cluster do Pacemaker apenas.

[A] Configurar o firewall.

Crie regras de firewall para permitir a replicação do sistema HANA e o tráfego do cliente. As portas necessárias estão listadas em Portas TCP / IP de todos os produtos SAP. Os comandos a seguir são apenas um exemplo para permitir o tráfego de replicação de sistema do HANA 2.0 e do cliente para o banco de dados SYSTEMDB, HN1 e NW1.
```
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
```

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

Execute o seguinte comando como <hanasid>adm:

hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'

[1] Configurar a replicação de sistema no primeiro nó.

Faça backup dos bancos de dados como <hanasid>adm:

hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

Copie os arquivos PKI do sistema para o site secundário:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Crie o site primário:

hdbnsutil -sr_enable --name=SITE1

[2] Configurar a replicação de sistema no segundo nó.

Registre o segundo nó para iniciar a replicação de sistema. Execute o seguinte comando como <hanasid>adm:
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```
[2] Iniciar o HANA.

Execute o seguinte comando como administrador do <hanasid> para iniciar o HANA:
```
sapcontrol -nr 03 -function StartSystem
```

[1] Verificar status de replicação.

Verifique o status de replicação e aguarde até que todos os bancos de dados estão em sincronizado. Se o status permanece desconhecido, verifique suas configurações de firewall.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
# | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# mode: PRIMARY
# site id: 1
# site name: SITE1

Criar um cluster do Pacemaker

Siga as etapas em Configurando o Pacemaker no Red Hat Enterprise Linux no Azure para criar um cluster básico do Pacemaker para esse servidor HANA.

Importante

Com o Estrutura de inicialização do SAP baseado em sistema, as instâncias do SAP HANA agora podem ser gerenciadas pelo systemd. A versão mínima necessária do Red Hat Enterprise Linux (RHEL) é RHEL 8 para SAP. Conforme descrito na Nota do SAP 3189534, todas as novas instalações da revisão 70 ou superior do SAP HANA SPS07 ou atualizações para sistemas HANA para a revisão 70 ou superior do HANA 2.0 SPS07, a estrutura de inicialização do SAP será registrada automaticamente com o sistema.

Ao usar soluções de HA para gerenciar a replicação do sistema SAP HANA combinadas com instâncias do SAP HANA habilitadas para sistema (consulte a Nota do SAP 3189534), etapas adicionais são necessárias para garantir que o cluster de HA possa gerenciar a instância do SAP sem interferência do systemd. Portanto, para o sistema SAP HANA integrado ao sistema, etapas adicionais descritas no KBA 7029705 do Red Hat devem ser seguidas em todos os nós de cluster.

Implemente ganchos de replicação do sistema SAP HANA

Essa importante etapa otimiza a integração com o cluster e melhora a detecção quando um failover de cluster é necessário. É obrigatório para a operação correta do cluster habilitar o gancho SAPHanaSR. É altamente recomendável que você configure ambos os ganchos Python SAPHanaSR e ChkSrv.

[A] Instale os agentes de recursos do SAP HANA em todos os nós. Certifique-se de habilitar um repositório que contém o pacote. Você não precisará habilitar mais repositórios, se estiver usando uma imagem habilitada para HA do RHEL 8.x ou superior.
```
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo dnf install -y resource-agents-sap-hana
```
Observação

Para RHEL 8.x e RHEL 9.x, verifique se o pacote instalado resource-agents-sap-hana é a versão 0.162.3-5 ou posterior.
[A] Instalar o HANA system replication hooks. A configuração para os ganchos de replicação precisa ser instalada em ambos os nós do BD HANA.
1. Pare o HANA em ambos os nós. Executar como <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```
2. Ajuste global.ini em cada nó de cluster.
```
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/SAPHanaSR/srHook
execution_order = 2
action_on_lost = kill

[trace]
ha_dr_saphanasr = info
ha_dr_chksrv = info
```
Se você apontar o parâmetro path para a localização padrão /usr/share/SAPHanaSR/srHook, o código do gancho Python será atualizado automaticamente por meio de atualizações do SO ou atualizações de pacotes. 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 SO da versão do gancho que o HANA vai usar.

Você pode ajustar o comportamento do gancho ChkSrv usando o parâmetro action_on_lost. Os valores válidos são: [ ignore | stop | kill ].

[A] O cluster exige a configuração de sudoers em cada nó de cluster para <sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo. Use o comando visudo para editar o arquivo suspenso 20-saphana como root.

sudo visudo -f /etc/sudoers.d/20-saphana

Insira as seguintes linhas e salve:

Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty

[A] Iniciar o SAP HANA em ambos os nós. Executar como <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1] Verifique a instalação do gancho SRHanaSR. Executar como <sid>adm no site de replicação do sistema do HANA ativo.

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

 # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK

[1] Verifique a instalação do gancho ChkSrv. Executar como <sid>adm no site de replicação do sistema do HANA ativo.
```
 cdtrace
 tail -20 nameserver_chksrv.trc
```

Para obter mais informações sobre a implementação dos ganchos do SAP HANA, confira Habilitando o gancho SAP HANA srConnectionChanged() e Habilitando o gancho SAP HANA srServiceStateChanged() para ação de falha do processo hdbindexserver (opcional).

Crie os recursos de cluster do SAP HANA

Crie a topologia do HANA. Execute os seguintes comandos em um dos nós de cluster do Pacemaker. Ao longo dessas instruções, substitua o número da instância, a ID do sistema HANA, os endereços IP e os nomes do sistema, quando apropriado.

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

Em seguida, crie os recursos HANA.

Observação

Este artigo contém referências a um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Se você estiver criando um cluster no RHEL 7.x, use os seguintes comandos:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000

sudo pcs property set maintenance-mode=false

Se você estiver criando um cluster no RHEL 8.x/9.x, use os seguintes comandos:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  promotable notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

sudo pcs property set maintenance-mode=false

Para configurar priority-fencing-delay para o SAP HANA (aplicável somente a partir do pacemaker-2.0.4-6.el8 ou superior), os comandos a seguir precisam ser executados.

Observação

Se você tiver um cluster de dois nós, é possível configurar a propriedade do clusterpriority-fencing-delay. Essa propriedade introduz um atraso no isolamento de um nó que tem uma prioridade total de recursos mais alta quando ocorre um cenário de split-brain. Para obter mais informações, confira O Pacemaker pode isolar o nó de cluster com o menor número de recursos em execução?.

A propriedade priority-fencing-delay é aplicável para a versão pacemaker-2.0.4-6.el8 ou superior. Se você estiver configurando priority-fencing-delay em um cluster existente, remova a definição da opção pcmk_delay_max no dispositivo de isolamento.

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

Importante

É uma boa ideia definir AUTOMATED_REGISTER como false, enquanto você está executando testes de failover, para impedir que uma instância primária com falha seja registrada automaticamente como secundária. Após o teste, como uma melhor prática, defina AUTOMATED_REGISTER como true para que após a tomada de controle, a replicação do sistema possa ser retomada automaticamente.

Verifique se o status do cluster está certo e se todos os recursos foram iniciados. Não é importante saber em qual nó os recursos estão sendo executados.

Observação

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

Use o comando sudo pcs status para verificar o estado dos recursos de cluster criados:

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

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

Começando com o SAP HANA 2.0 SPS 01, o SAP permite a configuração ativa/habilitada para leitura da replicação de sistema do SAP HANA, em que 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 esse tipo de configuração em um cluster, é necessário ter um segundo endereço IP virtual. Isso permite que os clientes acessem 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 recurso SAPHana secundário.

Esta seção descreve as outras etapas necessárias para gerenciar a replicação de sistema ativa/habilitada para leitura do HANA em um cluster de HA do Red Hat com um segundo IP virtual.

Antes de continuar, verifique se você configurou totalmente o cluster de HA do Red Hat que gerencia um banco de dados SAP HANA, conforme descrito nos segmentos anteriores da documentação.

Diagrama que mostra SAP HANA HA com secundário habilitado para leitura.

Configuração adicional no Azure Load Balancer para configuração ativa/habilitada para leitura

Para continuar com mais etapas sobre o provisionamento de um segundo IP virtual, verifique se você configurou o Azure Load Balancer conforme descrito na seção Implantar VMs do Linux manualmente por meio do portal do Azure.

Para o balanceador de carga padrão, siga estas etapas no mesmo balanceador de carga que você criou em uma seção anterior.

a. Crie um segundo pool de IPs de front-end:
- Abra o balanceador de carga, selecione pool de front-end e selecione Adicionar.
- Insira o nome do segundo pool de IPs de front-end (por exemplo, hana-secondaryIP).
- Defina a Atribuição como Estática e insira o endereço IP (por exemplo, 10.0.0.14).
- Selecione OK.
- Depois que o novo pool de IP de front-end for criado, anote o endereço IP do pool.
b. Crie uma investigação de integridade:
- Abra o balanceador de carga, selecione investigações de integridade e selecione Adicionar.
- Insira o nome da nova investigação de integridade (por exemplo, hana-secondaryhp).
- Selecione TCP como o protocolo e a porta 62603. Mantenha o valor do Intervalo definido como 5 e o valor Limite não íntegro definido como 2.
- Selecione OK.
c. Crie as regras de balanceamento de carga:
- Abra o balanceador de carga, selecione Regras de balanceamento de carga e selecione Adicionar.
- Insira o nome da nova regra do balanceador de carga (por exemplo hana-secondarylb).
- 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).
- Selecione Portas de HA.
- Certifique-se de habilitar IP Flutuante.
- 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 na seção Configurar a replicação do sistema SAP HANA 2.0. Se você estiver implantando um cenário secundário habilitado para leitura durante a configuração da replicação do sistema no segundo nó, execute o seguinte comando como hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess

Adicionar um recurso de endereço IP virtual secundário para uma configuração ativa/habilitada para leitura

O segundo IP virtual e a restrição de colocação apropriada podem ser configurados com os seguintes comandos:

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603
pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master
pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5

pcs property set maintenance-mode=false

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

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Na próxima seção, você pode encontrar o conjunto típico de testes de failover para executar.

Cuidado com o comportamento do segundo IP virtual ao testar um cluster HANA configurado com um secundário habilitado para leitura:

Ao migrar o recurso de cluster SAPHana_HN1_03 para o site secundário hn1-db-1, o segundo IP virtual continua sendo executado no mesmo site hn1-db-1. Se você tiver definido AUTOMATED_REGISTER="true" para o recurso e a replicação de sistema HANA for registrada automaticamente no hn1-db-0, seu segundo IP virtual também passará para hn1-db-0.
Ao testar uma falha do servidor, os recursos do segundo IP virtual (secvip_HN1_03) e o recurso de porta do Azure Load Balancer (secnc_HN1_03) executam no servidor primário com os recursos de IP virtual primários. Portanto, até que o servidor secundário esteja inativo, os aplicativos que estão conectados ao banco de dados HANA habilitado para leitura estão conectados ao banco de dados HANA primário. O comportamento é esperado porque você não deseja que os aplicativos conectados ao banco de dados HANA habilitado para leitura fiquem inacessíveis até que o servidor secundário não esteja disponível.
Durante o failover e fallback do segundo endereço IP virtual, as conexões existentes em aplicativos que usam o segundo IP virtual para se conectar ao banco de dados HANA podem ser interrompidas.

A configuração maximiza o tempo em que o segundo recurso de IP virtual é atribuído a um nó em que uma instância SAP HANA íntegra está em execução.

Testar a configuração do cluster

Esta seção descreve como é possível testar a configuração. Antes de iniciar um teste, verifique se o Pacemaker não possui nenhuma ação com falha (via status de pcs), não há restrições de local inesperadas (por exemplo, sobras de um teste de migração) e que o HANA é o estado de sincronização, por exemplo com systemReplicationStatus.

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

Testar a migração

Estado do recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

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

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

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

Depois que a migração for concluída, a saída sudo pcs status terá a seguinte semelhança:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

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

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

A migração cria restrições de local que precisam ser excluídas novamente. Execute o comando a seguir como raiz ou via sudo:

pcs resource clear SAPHana_HN1_03-master

Monitore o estado do recurso do HANA usando pcs status. Depois que o HANA é inicializado em hn1-db-0, a saída deve ser semelhante a:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Bloquear comunicação de rede

Estado do recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       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 obter um cenário de split-brain. Nessas situações, nós de cluster tentam se isolar simultaneamente, resultando em uma disputa por limites. Para evitar tal situação, recomendamos que definir a propriedade priority-fencing-delay na configuração do cluster (aplicável somente para pacemaker-2.0.4-6.el8 ou superior).

Ao habilitar a propriedade priority-fencing-delay, o cluster insere um atraso 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 seguinte comando 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 o agente de isolamento do Azure

Observação

Este artigo contém referências a um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Estado do recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Você pode testar a configuração do agente de fence do Azure desativando a interface de rede no nó em que o SAP HANA está sendo executado como mestre. Para obter uma descrição sobre como simular uma falha de rede, confira o Artigo 79523 da base de dados de conhecimento do Red Hat.

Neste exemplo, usamos o script net_breaker para bloquear todo o acesso à rede:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

A VM agora deverá reiniciar ou parar, dependendo da configuração do cluster. Se você definir a configuração stonith-action como off, a VM será interrompida e os recursos serão migrados para a VM em execução.

Após iniciar a VM novamente, o recurso SAP HANA não será iniciado como secundário se você definir AUTOMATED_REGISTER="false". Nesse caso, configure a instância do HANA como secundária executando este comando como o usuário hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

Retorne para a raiz e limpe o estado com falha:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Estado do recurso após o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Testar um failover manual

Estado do recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Você pode testar um failover manual interrompendo o cluster no nó hn1-db-0, como raiz:

pcs cluster stop

Após o failover, você pode iniciar o cluster 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 como raiz:

pcs cluster start

Execute o seguinte como hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

Em seguida, como raiz:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Estado do recurso após o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Compartilhar via

Alta disponibilidade do SAP HANA em VMs do Azure no Red Hat Enterprise Linux

Pré-requisitos

Visão geral

Preparar a infraestrutura

Implantar VMs do Linux manualmente por meio do portal do Azure

Configurar o Azure Load Balancer

Instalar SAP HANA

Configurar a replicação do Sistema SAP HANA 2.0

Criar um cluster do Pacemaker

Implemente ganchos de replicação do sistema SAP HANA

Crie os recursos de cluster do SAP HANA

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

Configuração adicional no Azure Load Balancer para configuração 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 para uma configuração ativa/habilitada para leitura

Testar a configuração do cluster

Testar a migração

Bloquear comunicação de rede

Testar o agente de isolamento do Azure

Testar um failover manual

Próximas etapas

Comentários

Recursos adicionais