Alta disponibilidade para o sistema de expansão SAP HANA com HSR no SUSE Linux Enterprise Server

Artigo
06/18/2024

Este artigo descreve como implantar um sistema SAP HANA altamente disponível em uma configuração de expansão com HSR (replicação de sistema do HANA) e Pacemaker nas máquinas virtuais (VMs) do Azure SUSE Linux Enterprise Server. Os sistemas de arquivos compartilhados na arquitetura apresentada são montados com NFS e fornecidos pelo Azure NetApp Files ou pelo compartilhamento de NFS nos Arquivos do Azure.

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

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

Documentação do Azure NetApp Files
Documentação dos Arquivos do Azure
A Nota do SAP 1928533 inclui:
- Um lista de tamanhos de VMs do Azure compatíveis com a implantação de software SAP
- Informações importantes sobre capacidade para tamanhos de VM do Azure
- Software SAP e 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
Nota SAP 2015553: lista pré-requisitos para implantações de software SAP com suporte para SAP no Azure
Nota SAP 2205917: contém configurações de SO recomendadas do SUSE Linux Enterprise Server para aplicativos SAP
Nota SAP 1944799: contém Diretrizes do SAP HANA para SUSE Linux Enterprise Server para aplicativos SAP
Nota SAP 2178632: contém informações detalhadas sobre todas as métricas de monitoramentos relatadas para o SAP no Azure
Nota do SAP 2191498: contém a versão necessária do SAP Host Agent para Linux no Azure
Nota SAP 2243692: contém informações sobre o licenciamento do SAP para o Linux no Azure
Nota SAP 1984787: contém informações gerais sobre o SUSE Linux Enterprise Server 12
Nota SAP 1999351: contém informações de solução de problemas adicionais para a Extensão de Monitoramento Avançado do Azure para SAP
Nota do SAP 1900823: contém informações sobre os requisitos de armazenamento de SAP HANA
Wiki da comunidade do SAP: contém todas as notas do 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
Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux
Guias de melhores práticas de HA (alta disponibilidade) do SAP para SUSE: contém todas as informações necessárias para configurar a alta disponibilidade do NetWeaver e a replicação do sistema SAP HANA no local (para ser usada como uma linha de base geral; elas fornecem informações muito mais detalhadas)
Notas de versão do SP5 com a extensão de alta disponibilidade do SUSE 12
Falha no tratamento do compartilhamento de NFS no cluster de alta disponibilidade do SUSE para replicação do sistema HANA
Volumes NFS v4.1 no Azure NetApp Files para SAP HANA

Visão geral

Um método para obter alta disponibilidade do HANA para instalações de expansão do HANA é configurar a replicação do sistema HANA e proteger a solução com o cluster Pacemaker para permitir o failover automático. Quando um nó ativo falha, o cluster executa o failover dos recursos do HANA para o outro site.
A configuração apresentada mostra três nós do HANA em cada site, além do nó do fabricante principal para evitar o cenário de dupla personalidade. As instruções podem ser adaptadas para incluir mais VMs como nós de BD do HANA.

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

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

Importante

Se estiver implantando todos os sistemas de arquivos do HANA no Azure NetApp Files, para sistemas de produção, em que o desempenho é uma chave, é recomendável avaliar e considerar o uso do Grupo de volumes de aplicativos do Azure NetApp Files para SAP HANA.

Aviso

Não há suporte para a implantação de /hana/data e /hana/log no NFS nos Arquivos do Azure.

No diagrama anterior, três sub-redes são representadas em uma rede virtual do Azure, seguindo as recomendações de rede do SAP HANA:

para comunicação com o cliente – client 10.23.0.0/24
para comunicação interna entre nós do HANA – inter 10.23.1.128/26
para replicação de sistema do HANA – hsr 10.23.1.192/26

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

Caso esteja usando o Azure NetApp Files, os volumes de NFS para /hana/shared serão implantados em uma sub-rede separada, delegada ao Azure NetApp Files: anf 10.23.1.0/26.

Preparar a infraestrutura

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

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

Implantar as VMs do Azure.

Para a configuração apresentada neste documento, implante sete máquinas virtuais:
- três máquinas virtuais para servir como nós de banco de BD do HANA para o site 1 da replicação do HANA: hana-s1-db1, hana-s1-db2 e hana-s1-db3
- três máquinas virtuais para servir como nós de banco de BD do HANA para o site 2 da replicação do HANA: hana-s2-db1, hana-s2-db2 e hana-s2-db3
- uma pequena máquina virtual para servir como o principal fabricante: hana-s-mm
As VMs, implantadas como nós do SAP BD HANA, devem ser certificadas pelo SAP para HANA, conforme publicado no diretório de Hardware SAP HANA. Ao implantar os nós de BD do HANA, verifique se a Rede acelerada está escolhida.

Para o nó do fabricante principal, você pode implantar uma VM pequena, pois essa VM não executa nenhum dos recursos de SAP HANA. A VM do fabricante principal é usada na configuração do cluster para obter um número ímpar de nós de cluster em um cenário de dupla personalidade. A VM do fabricante principal precisa apenas de uma interface de rede virtual na sub-rede client neste exemplo.

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

Implante a interface de rede primária para cada VM na sub-rede da rede virtual client.
Quando a VM é implantada via portal do Azure, o nome da interface de rede é gerado automaticamente. Nestas instruções para simplificar, vamos nos referir às interfaces de rede primárias, geradas automaticamente, que são anexadas à sub-rede da rede virtual do Azure client, como hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-Cliente assim por diante.
Importante
- Certifique-se de que o sistema operacional que você selecionar tenha certificação SAP para o SAP HANA nos tipos de VM específicos que você está usando. Para obter uma lista de tipos de VMs certificadas do SAP HANA e das versões de sistemas operacionais para esses tipos, acesse o site de Plataformas de IaaS certificadas do SAP HANA. Clique nos detalhes do tipo de VM listado para obter a lista completa de versões do sistema operacional com suporte do SAP HANA para esse tipo de VM.
- Caso opte por implantar /hana/shared no NFS nos Arquivos do Azure, é recomendável implantar no SLES 15 SP2 e superior.
Crie seis interfaces de rede, uma para cada máquina virtual do HANA DB, na sub-rede da rede virtual inter (neste exemplo, hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-intere hana-s2-db3-inter).
Crie seis interfaces de rede, uma para cada máquina virtual do HANA DB, na sub-rede da rede virtual hsr (neste exemplo, hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsre hana-s2-db3-hsr).
Anexe as interfaces da rede virtual recém-criadas às máquinas virtuais correspondentes:
1. Acesse a máquina virtual no portal do Azure.
2. No painel esquerdo, selecione Máquinas Virtuais. Filtre o nome da máquina virtual (por exemplo, hana-s1-db1) e, em seguida, escolha a máquina virtual.
3. No painel Visão geral, escolha Parar para desalocar a máquina virtual.
4. Escolha Rede e, em seguida, anexe a interface de rede. Na lista suspensa Anexar interface de rede, selecione as interfaces de rede já criadas para as sub-redes inter e hsr.
5. Selecione Salvar.
6. Repita as etapas B a E nas máquinas virtuais restantes (no exemplo: hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 e hana-s2-db3).
7. Deixe as máquinas virtuais no estado parado por enquanto. Em seguida, vamos habilitar a rede acelerada para todas as interfaces de rede recém-anexadas.

Habilite a rede acelerada para as interfaces de rede adicionais das sub-redes inter e hsr seguindo estas etapas:

Abra o Azure Cloud Shell no portal do Azure.

Execute os comandos a seguir para habilitar a rede acelerada para as interfaces de rede adicionais, que estão anexadas às sub-redes inter e hsr.

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

Iniciar as máquinas virtuais do BD HANA

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.

Observação

Para escalar horizontalmente o HANA, selecione a NIC para a sub-rede client ao adicionar as máquinas virtuais no pool de back-end.
O conjunto completo de comandos na CLI do Azure e no PowerShell adiciona as VMs com NIC primária no pool de back-end.

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

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. No momento, não é possível definir essa propriedade usando o portal do Azure, portanto, use o comando da CLI do Azure ou do PowerShell.

O conjunto completo de códigos da CLI do Azure exibe a configuração do balanceador de carga, que inclui duas VMs no pool de back-end. Dependendo do número de VMs na sua expansão do HANA, é possível adicionar mais VMs no pool de back-end.

# 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

O conjunto completo de código do PowerShell exibe a configuração do balanceador de carga, que inclui duas VMs no pool de back-end. Dependendo do número de VMs na sua expansão do HANA, é possível adicionar mais VMs no pool de back-end.

# 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

Observação

Quando as VMs sem endereços IP públicos forem colocadas no pool de back-end do Standard Azure Load Balancer (sem endereço IP público), não haverá nenhuma conectividade de saída com a Internet se não houver configuração adicional a fim de permitir o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como alcançar conectividade de saída, confira Conectividade de ponto de extremidade público para Máquinas Virtuais 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 posicionadas subjacentemente ao Azure Load Balancer. Habilitar carimbos de data/hora de TCP fará com que as investigações de integridade falhem. Defina o parâmetro net.ipv4.tcp_timestamps como 0. Para obter detalhes, confira Investigações de integridade do Load Balancer e observação 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?.

Implantar o NFS

Há duas opções para implantar o NFS nativo do Azure para /hana/shared. Você pode implantar o volume do NFS no Azure NetApp Files ou no compartilhamento NFS nos Arquivos do Azure. Os arquivos do Azure dão suporte ao protocolo NFSv4.1, os arquivos NFS no Azure NetApp dão suporte ao NFSv4.1 e NFSv3.

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

Dica

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

Implantar a infraestrutura do Azure NetApp Files

Implante volumes do Azure NetApp Files para o sistema de arquivos /hana/shared. É necessário um volume /hana/shared separado para cada site de replicação do sistema HANA. Para obter mais informações, confira Configurar a infraestrutura do Azure NetApp Files.

Neste exemplo, os seguintes volumes do Azure NetApp Files foram usados:

volume HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
volume HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2)

Implantar o NFS na infraestrutura dos Arquivos do Azure

Implante compartilhamentos NFS dos Arquivos do Azure para o sistema de arquivos /hana/shared. É necessário um compartilhamento NFS dos Arquivos do Azure /hana/shared separado para cada local de replicação do sistema HANA. Para obter mais informações, confira Como criar um compartilhamento NFS.

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

share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Configuração e preparação do sistema operacional

As instruções das próximas seções têm como prefixo uma das seguintes abreviações:

[A]: aplicável a todos os nós, incluindo o fabricante principal
[AH]: aplicável a todos os nós de BD do HANA
[M]: aplicável somente ao nó do fabricante principal
[AH1]: aplicável a todos os nós de BD do HANA no SITE 1
[AH2]: aplicável a todos os nós de BD do HANA no SITE 2
[AH1]: aplicável somente ao nó de BD do HANA 1, SITE 1
[AH2]: aplicável somente ao nó de BD do HANA 1, SITE 2

Configure e prepare seu sistema operacional executando as seguintes etapas:

[A] Mantenha os arquivos do host nas máquinas virtuais. Inclua entradas para todas as sub-redes. As entradas a seguir foram adicionadas a /etc/hosts neste exemplo.

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] Crie o arquivo de configuração /etc/sysctl.d/ms-az.conf com a Microsoft para as definições de configuração do Azure.
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10
```
Dica

Evite configurar net.ipv4.ip_local_port_range e net.ipv4.ip_local_reserved_ports explicitamente nos arquivos de configuração sysctl para permitir que o Agente de Host do SAP gerencie os intervalos de portas. Para saber mais, veja a nota do SAP 2382421.
[A] SUSE entrega agentes de recurso especiais para SAP HANA e, por padrão, agentes para dimensionamento vertical do SAP HANA são instalados. Desinstale os pacotes para dimensionamento vertical, se instalados, e instale os pacotes para o cenário de expansão do SAP HANA. A etapa precisa ser executada em todas as VMs do cluster, incluindo o criador majoritário.

Observação

O SAPHanaSR-ScaleOut versão 0.181 ou superior deve ser instalado.
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] Preparar as VMs – aplique as configurações recomendadas de acordo com a nota SAP 2205917 para SUSE Linux Enterprise Server para aplicativos SAP.

Preparar os sistemas de arquivos

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

Montar os sistemas de arquivos compartilhados (NFS do Azure NetApp Files)

Neste exemplo, os sistemas de arquivos compartilhados do HANA são implantados no Azure NetApp Files e montados via NFSv4.1. Siga as etapas desta seção somente se estiver usando NFS no Azure NetApp Files.

[AH] Prepare o sistema operacional para executar o SAP HANA nos sistemas NetApp com o NFS, conforme descrito na nota do SAP 3024346 – Configurações do kernel do Linux para NetApp com o NFS. Crie o arquivo de configuração /etc/sysctl.d/91-NetApp-HANA.conf para as definições de configuração do NetApp.

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

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

[AH] Ajuste as configurações de sunrpc, conforme recomendado na nota do SAP 3024346 – Configurações do kernel do Linux para NetApp com o NFS.
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] Crie pontos de montagem para os volumes de banco de dados do HANA.
```
mkdir -p /hana/shared
```
[AH] Verifique a configuração do domínio NFS. Verifique se o domínio está configurado como o domínio do Azure NetApp Files padrão, ou seja, defaultv4iddomain.com, e o mapeamento está definido como nobody.
Esta etapa só é necessária se você estiver usando o Azure NetAppFiles NFSv4.1.

Importante

É preciso que você defina o domínio NFS em /etc/idmapd.conf na VM para corresponder à configuração de domínio padrão no Azure NetApp Files: defaultv4iddomain.com . Se houver uma incompatibilidade entre a configuração de domínio no cliente NFS (ou seja, a VM) e o servidor NFS, ou seja, a configuração da Azure NetApp, as permissões para arquivos nos volumes do Azure NetApp que forem montados nas VMs serão exibidas como nobody.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
[AH] Verifique nfs4_disable_idmapping. Ele deve ser definido como Y. Para criar a estrutura de diretório em que nfs4_disable_idmapping está localizado, execute o comando mount. Você não poderá criar o diretório manualmente em /sys/modules, pois o acesso é reservado para o kernel e os drivers.
Esta etapa só é necessária se você estiver usando o Azure NetAppFiles NFSv4.1.
```
# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
```

[AH1] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE1 HANA DB.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE2 HANA DB.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Verifique se os sistemas de arquivos /hana/shared/ correspondentes estão montados em todas as VMs do BD HANA com o protocolo NFS versão NFSv4.1.

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

Montar os sistemas de arquivos compartilhados (NFS dos Arquivos do Azure)

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

[AH] Crie pontos de montagem para os volumes de banco de dados do HANA.
```
mkdir -p /hana/shared
```

[AH1] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE1 HANA DB.

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Monte os volumes do Azure NetApp Files compartilhados nas VMs do SITE2 HANA DB.

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Verifique se os sistemas de arquivos /hana/shared/ correspondentes estão montados em todas as VMs do BD HANA com o protocolo NFS versão NFSv4.1.

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

Preparar os dados e registrar em log os sistemas de arquivos locais

Na configuração apresentada, os sistemas de arquivos /hana/data e /hana/log são implantados no disco gerenciado e são anexados localmente a cada VM do HANA DB. É necessário executar as etapas para criar os volumes de dados e de log locais em cada máquina virtual do HANA DB.

Configure o layout do disco com o LVM (gerenciador de volumes lógicos) . O exemplo a seguir supõe que cada máquina virtual HANA tem três discos de dados anexados, que são usados para criar dois volumes.

[AH] Liste todos os discos disponíveis:

ls /dev/disk/azure/scsi1/lun*

Saída de exemplo:

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

[AH] Crie volumes físicos para todos os discos que você deseja usar:

sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2

[AH] Crie um grupo de volumes para os arquivos de dados. Use um grupo de volumes para os arquivos de log e outro para o diretório compartilhado do SAP HANA:\
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
```
[AH] Crie 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 e alinhe os tamanhos de distribuição aos valores documentados em 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. 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 256 KiB. 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 ou do log. Use a opção -I para especificar o tamanho da distribuição, quando criar 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.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] Crie os diretórios de montagem e copie o UUID de todos os volumes lógicos:

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] Crie as entradas fstab para os volumes lógicos e monte:

sudo vi /etc/fstab

Insira a seguinte linha no arquivo /etc/fstab:

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

Monte os novos volumes:

sudo mount -a

Criar um cluster 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. Inclua todas as máquinas virtuais, incluindo o fabricante principal no cluster.

Importante

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

Instalação

Neste exemplo, para implantar o SAP HANA na configuração de expansão com HSR em VMs do Azure, usamos o HANA 2.0 SP5.

Preparar para a instalação do HANA

[AH] Antes da instalação do HANA, defina a senha raiz. Você pode desabilitar a senha raiz após a conclusão da instalação. Execute como root o comando passwd.
[1,2] Mudar as permissões em /hana/shared
```
chmod 775 /hana/shared
```
[1] Verifique se você pode fazer logon via SSH para as VMs do HANA DB neste site hana-s1-db2 e hana-s1-db3, sem ser solicitado a fornecer uma senha. Se esse não for o caso, troque as chaves SSH conforme descrito em Habilitar acesso SSH via chave pública.
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] Verifique se você pode fazer logon via SSH para as VMs do HANA DB neste site hana-s2-db2 e hana-s2-db3, sem ser solicitado a fornecer uma senha.
Se esse não for o caso, troque as chaves SSH.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] Instale os pacotes adicionais que são necessários para o HANA 2.0 SP4 e superiores. Para obter mais informações, confira a Nota do SAP 2593824 para sua versão do SLES.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

Instalação do HANA no primeiro nó de cada site

[1] Instale o SAP HANA seguindo as instruções no Guia de instalação e atualização do SAP HANA 2.0. Nas instruções a seguir, mostramos a instalação do SAP HANA no primeiro nó do SITE 1.

a. Inicie o programa hdblcm como root do diretório de software de instalação do HANA. Use o parâmetro internal_network e passe o espaço de endereço para a sub-rede que é usada para a comunicação interna entre nós do HANA.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. No prompt, insira os valores a seguir:
- Em Escolher uma ação: insira 1 (para instalar)
- Em Componentes adicionais para a instalação: insira 2, 3
- Em caminho de instalação: pressione Enter (o padrão é /hana/shared)
- Em Nome do Host Local: pressione Enter para aceitar o padrão
- Em Você deseja adicionar outros hosts ao sistema? : insira n
- Em ID do sistema do SAP HANA: insira HN1
- Em Número de instância [00]: insira 03
- Em Grupo de Trabalho do Host Local [padrão]: pressione Enter para aceitar o padrão
- Em Selecionar Uso do Sistema / Inserir Índice [4] : insira 4 (personalizado)
- Em Local dos Volumes de Dados [/hana/data/HN1]: pressione Enter para aceitar o padrão
- Em Local dos Volumes do Log [/hana/log/HN1]: pressione Enter para aceitar o padrão
- Para restringir a alocação máxima de memória? [n]: insira n
- Em Nome do Host do Certificado Para o Host hana-s1-db1 [hana-s1-db1]: pressione Enter para aceitar o padrão
- Em Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
- Em Confirmar a Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
- Em Senha do Administrador do Sistema (hn1adm) : insira a senha
- Em Diretório Base do Administrador do Sistema [/usr/SAP/HN1/Home]: pressione ENTER para aceitar o padrão
- Em Shell de Logon do Administrador do Sistema [/bin/sh]: pressione ENTER para aceitar o padrão
- Em ID de Usuário do Administrador do Sistema [1001]: pressione ENTER para aceitar o padrão
- Em Inserir ID do Grupo de Usuários (sapsys) [79]: pressione ENTER para aceitar o padrão
- Em Senha do Usuário do Banco de Dados do Sistema (sistema) : insira a senha do sistema
- Em Confirmar Senha do Usuário do Banco de Dados do Sistema (sistema) : insira a senha do sistema
- Para Reiniciar sistema após a reinicialização do computador? [n]: insira n
- Em Você deseja continuar (s/n) : valide o resumo e, se tudo estiver correto, digite y
[2] Repita a etapa anterior para instalar o SAP HANA no primeiro nó no SITE 2.
[1,2] Verifique o global.ini

Abra o global.ini e verifique se a configuração da comunicação interna entre nós do SAP HANA está funcionando. Verifique a seção Comunicação. Ele deve ter o espaço de endereço para a sub-rede inter e listeninterface deve ser definido como .internal. Verifique a seção internal_hostname_resolution. Ele deve ter os endereços IP para as máquinas virtuais HANA que pertencem à sub-rede inter.
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1, 2] Prepare-se global.ini para a instalação em um ambiente não compartilhado, conforme descrito na nota SAP 2080991.
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[1,2] Reinicie o SAP HANA para ativar as alterações.

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

[1,2] Verifique se a interface do cliente usará os endereços IP da sub-rede client para comunicação.
```
# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"
```
Para obter informações sobre como verificar a configuração, consulte a Nota SAP 2183363 – Configuração da rede interna do SAP HANA.
[AH] Altere as permissões nos diretórios de dados e de log para evitar o erro de instalação do HANA.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] Instale os nós do HANA secundários. As instruções de exemplo nesta etapa são para o SITE 1.

a. Inicie o programa hdblcm residente como root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. No prompt, insira os valores a seguir:
- Em Escolher uma ação: insira 2 (para adicionar hosts)
- Em Inserir nomes de host separados por vírgula para adicionar: hana-s1-db2, hana-s1-db3
- Em Componentes adicionais para a instalação: insira 2, 3
- Em Inserir Nome do Usuário Raiz [root] : pressione Enter para aceitar o padrão
- Em Selecionar funções para o host 'hana-s1-db2' [1] : 1 (para o trabalho)
- Em Inserir Grupo de Failover para o host 'hana-s1-db2' [padrão] : pressione Enter para aceitar o padrão
- Em Inserir o número da partição de armazenamento do host 'hana-s1-db2' [<<atribuir automaticamente>>], pressione Enter para aceitar o padrão
- Em Inserir Grupo de Trabalho para o host 'hana-s1-db2' [padrão] : pressione Enter para aceitar o padrão
- Em Selecionar funções para o host 'hana-s1-db3' [1] : 1 (para o trabalho)
- Em Inserir Grupo de Failover para o host 'hana-s1-db3' [padrão] : pressione Enter para aceitar o padrão
- Em Inserir o Número de Partição de Armazenamento do host 'hana-s1-db3' [<<atribuir automaticamente>>], pressione Enter para aceitar o padrão
- Em Inserir Grupo de Trabalho para o host 'hana-s1-db3' [padrão] : pressione Enter para aceitar o padrão
- Em Senha do Administrador do Sistema (hn1adm) : insira a senha
- Em Inserir Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
- Em Confirmar a Senha de Usuário do Agente Host SAP (sapadm) : insira a senha
- Em Nome do Host do Certificado Para o Host hana-s1-db2 [hana-s1-db2]: pressione Enter para aceitar o padrão
- Em Nome do Host do Certificado Para o Host hana-s1-db3 [hana-s1-db3]: pressione Enter para aceitar o padrão
- Em Você deseja continuar (s/n) : valide o resumo e, se tudo estiver correto, digite y
[2] Repita a etapa anterior para instalar os nós de SAP HANA secundários no SITE 2.

Configurar a replicação do Sistema SAP HANA 2.0

[1] Configurar a Replicação do Sistema no SITE 1:

Faça backup dos bancos de dados como hn1adm:

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

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

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Crie o site primário:

hdbnsutil -sr_enable --name=HANA_S1

[2] Configurar a Replicação do Sistema no SITE 2:

Registre o segundo site para iniciar a replicação do sistema. Execute o seguinte comando como <hanasid>adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

[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.

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

# | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
#
# mode: PRIMARY
# site id: 1
# site name: HANA_S1

[1,2] Altere a configuração do HANA para que a comunicação para a replicação do sistema HANA seja direcionada por meio dos adaptadores de rede virtual de replicação do sistema HANA.
- Parar o HANA em ambos os sites
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- Editar o global.ini para adicionar o mapeamento de host para replicação de sistema do HANA: use os endereços IP da sub-rede hsr.
```
sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- Parar o HANA em ambos os sites
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
Para obter mais informações, confira Resolução de nome do host para replicação do sistema.

Criar os recursos do sistema de arquivos

Crie um recurso de cluster de sistema de arquivos fictício, que monitorará e relatará falhas, caso haja um problema ao acessar o sistema de arquivos montado em NFS /hana/shared. Isso permite que o cluster acione o failover, caso haja um problema ao acessar /hana/shared. Para obter mais detalhes, confira Falha no tratamento do compartilhamento de NFS no cluster de alta disponibilidade do SUSE para replicação do sistema HANA

[1] Coloque pacemaker no modo de manutenção, em preparo para a criação dos recursos de cluster do HANA.
```
crm configure property maintenance-mode=true
```
[1, 2] Crie o diretório no sistema de arquivos/hana/compartilhado montado com NFS, que será usado no recurso especial de monitoramento do sistema de arquivos. Os diretórios precisam ser criados em ambos os sites.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Crie o diretório que será usado para montar o recurso especial de monitoramento do sistema de arquivos. O diretório precisa ser criado em todos os nós de cluster HANA.
```
mkdir -p /hana/check
```
[1] Crie os recursos de cluster do sistema de arquivos.
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
O atributo OCF_CHECK_LEVEL=20 é adicionado à operação de monitoramento, para que as operações de monitoramento realizem um teste de leitura/gravação no sistema de arquivos. Sem esse atributo, a operação de monitoramento só verifica se o sistema de arquivos está montado. Isso pode ser um problema pois, quando a conectividade é perdida, o sistema de arquivos pode permanecer montado, apesar de estar inacessível.

O atributo on-fail=fence também é adicionado à operação de monitoramento. Com essa opção, se a operação de monitoramento falhar em um nó, esse nó será imediatamente isolado.

Implementar os ganchos de HA do HANA SAPHanaSrMultiTarget e susChkSrv

Essa etapa importante tem a finalidade de otimizar a integração com o cluster e a detecção quando um failover de cluster é possível. É altamente recomendável configurar o gancho Python SAPHanaSrMultiTarget. Para o HANA 2.0 SP5 e superior, é recomendável implementar os ganchos SAPHanaSrMultiTarget e susChkSrv.

Observação

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

As etapas fornecidas para o gancho SAPHanaSrMultiTarget são para uma nova instalação. A atualização de um ambiente existente do SAPHanaSR para o provedor SAPHanaSrMultiTarget requer várias alterações e NÃO é descrita neste documento. Se o ambiente existente não usar um terceiro site para recuperação de desastre e a replicação de sistema de vários destinos do HANA não for usada, o provedor de alta disponibilidade SAPHanaSR poderá permanecer em uso.

SusChkSrv estende a funcionalidade do principal provedor de HA do SAPHanaSrMultiTarget. Ele atua na situação em que 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 susChkSrv implementado, uma ação imediata e configurável é executada em vez de aguardar o processo hdbindexserver para reiniciar no mesmo nó. Na expansão do HANA, susChkSrv atua para cada VM do HANA de modo independente. A ação configurada encerrará o HANA ou isolará a VM afetada, o que dispara um failover no período de tempo limite configurado.

O SUSE SLES 15 SP1 ou superior é necessário para a operação de ambos os ganchos de HA do HANA. A tabela a seguir mostra outras dependências.

Gancho de HA do SAP HANA	Versão necessária do HANA	SAPHanaSR-ScaleOut necessário
SAPHanaSrMultiTarget	HANA 2.0 SPS4 ou superior	0.180 ou superior
susChkSrv	HANA 2.0 SPS5 ou superior	0.184.1 ou superior

Etapas para implementar ambos os ganchos:

[1,2] Interrompa o HANA em ambos os sites de replicação do sistema. Execute como <sid>adm:
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Ajuste global.ini em cada site do cluster. Se os pré-requisitos para o gancho susChkSrv não forem atendidos, o bloco [ha_dr_provider_suschksrv] inteiro não deverá ser configurado.
Você pode ajustar o comportamento de susChkSrv com o parâmetro action_on_lost. Os valores válidos são [ ignore | stop | kill | fence ].
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
O local padrão dos ganchos de alta disponibilidade fornecidos pelo SUSE é /usr/share/SAPHanaSR-ScaleOut. Usar o local padrão traz o benefício de que o código do gancho Python é atualizado automaticamente por meio de atualizações do sistema operacional ou do pacote e é usado pelo HANA na próxima reinicialização. Com um caminho opcional, como /hana/shared/myHooks, você pode desacoplar as atualizações do sistema operacional com a versão do gancho usada.

[AH] O cluster requer configuração de sudoers nos nós de cluster para <sid>adm. Neste exemplo, isso é obtido com a criação de um novo arquivo. Execute os comandos como root e adapte os valores de hn1 com o SID correto em minúsculas.

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] Iniciar o SAP HANA em ambos os sites de replicação. Execute como <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Verifique se a instalação do gancho está ativa em todos os nós de cluster. Execute como <sid>adm.

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

Verifique a instalação do gancho susChkSrv. Execute como <sid>adm.

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Crie os recursos de cluster do SAP HANA

[1] Crie os recursos de cluster do HANA. Execute os comandos a seguir como root.

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

Em seguida, crie o recurso de topologia do HANA.

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

Em seguida, crie o recurso de instância do HANA.

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.
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
Importante

Como uma prática recomendada, sugerimos que você só defina AUTOMATED_REGISTER como no, enquanto executa testes de failover completos, para evitar que a instância primária com falha seja registrada automaticamente como secundária. Depois que os testes de failover forem concluídos com êxito, defina AUTOMATED_REGISTER como yes, para que, após a aquisição, a replicação do sistema possa ser retomada automaticamente.

Criar o IP virtual e os recursos associados.

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

Criar as restrições de cluster

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] Configure propriedades de cluster adicionais

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

[1] Retire o cluster do modo de manutenção. Certifique-se de que o status do cluster está correto e que todos os recursos foram iniciados.

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] Verifique a comunicação entre o gancho de HA do HANA e o cluster, mostrando o status SOK para o SID e os sites de replicação com status P(rimary) ou S(econdary).

sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

Observação

Os tempos limite na configuração acima são apenas exemplos e devem 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.

Testar failover do SAP HANA

Observação

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

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

a. Verifique se não há nenhuma ação de cluster com falha

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. Verifique se a replicação do sistema SAP HANA está sincronizada

# Verify HANA HSR is in sync
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
#| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
#|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

Recomendamos validar completamente a configuração de cluster SAP HANA, executando os testes documentados em Alta disponibilidade para SAP HANA em VMs do Azure no SLES e no Cenário otimizado de desempenho de expansão da replicação do SLES.

Verifique a configuração do cluster para um cenário de falha, quando um nó perde o acesso ao compartilhamento NFS (/hana/shared).

Os agentes de recurso do SAP HANA dependem de binários, armazenados em /hana/shared para executar operações durante o failover. O sistema de arquivos /hana/shared é montado em NFS na configuração apresentada. Um teste executável é criar uma regra de firewall temporária para bloquear o acesso ao sistema de arquivos montado com NFS /hana/shared em uma das VMs do site primário. Esse método valida se o cluster fará o failover, caso o acesso a /hana/shared for perdido no site de replicação do sistema ativo.

Resultado esperado: quando você bloqueia o acesso ao sistema de arquivos montado com NFS /hana/shared em uma das VMs do site primário, a operação de monitoramento que executa a operação de leitura/gravação no sistema de arquivos falhará, pois não poderá acessar o sistema de arquivos e disparará o failover do recurso HANA. O mesmo resultado é esperado quando o nó do HANA perde o acesso ao compartilhamento NFS.

Você pode verificar o estado dos recursos de cluster executando crm_mon ou crm status. Estado do recurso antes de iniciar o teste:

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

Para simular falha para /hana/shared:

Se estiver usando o NFS no Azure NetApp Files, primeiro confirme o endereço IP do volume /hana/shared do Azure NetApp Files no site primário. Você pode fazer ao executar df -kh|grep /hana/shared.
Se estiver usando o NFS nos Arquivos do Azure, primeiro determine o endereço IP do ponto de extremidade privado para a sua conta de armazenamento.

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

Neste exemplo, o comando foi executado no hana-s1-db1 para o volume /hana/shared do Azure NetApp Files.

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

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

Caso defina AUTOMATED_REGISTER="false", será necessário configurar a replicação de sistema SAP HANA no site secundário. Nesse caso, você pode executar esses comandos para reconfigurar o SAP HANA como secundário.

# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03

O estado dos recursos, após o teste:

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

Próximas etapas

Planejamento e implementação de Máquinas Virtuais do Azure para o SAP
Implantação de Máquinas Virtuais do Azure para SAP
Implantação do DBMS de Máquinas Virtuais do Azure para SAP
Volumes NFS v4.1 no Azure NetApp Files para SAP HANA
Para saber como estabelecer a alta disponibilidade e o plano de recuperação de desastre do SAP HANA em VMs do Azure, consulte Alta disponibilidade do SAP HANA em VMs (Máquinas Virtuais) do Azure.

Compartilhar via

Alta disponibilidade para o sistema de expansão SAP HANA com HSR no SUSE Linux Enterprise Server

Visão geral

Preparar a infraestrutura

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

Configurar o Azure Load Balancer

Implantar o NFS

Implantar a infraestrutura do Azure NetApp Files

Implantar o NFS na infraestrutura dos Arquivos do Azure

Configuração e preparação do sistema operacional

Preparar os sistemas de arquivos

Montar os sistemas de arquivos compartilhados (NFS do Azure NetApp Files)

Montar os sistemas de arquivos compartilhados (NFS dos Arquivos do Azure)

Preparar os dados e registrar em log os sistemas de arquivos locais

Criar um cluster do Pacemaker

Instalação

Preparar para a instalação do HANA

Instalação do HANA no primeiro nó de cada site

Configurar a replicação do Sistema SAP HANA 2.0

Criar os recursos do sistema de arquivos

Implementar os ganchos de HA do HANA SAPHanaSrMultiTarget e susChkSrv

Crie os recursos de cluster do SAP HANA

Testar failover do SAP HANA

Próximas etapas

Comentários

Recursos adicionais