Alta disponibilidade do SAP HANA em expansão com o Azure NetApp Files no RHEL

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

Quando as etapas deste documento são marcadas com os seguintes prefixos, o significado é o seguinte:

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

Pré-requisitos

Primeiro, leia os seguintes documentos e Notas SAP:

• A Nota SAP 1928533, que tem:
  • A lista dos tamanhos de Máquinas Virtuais 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 do SAP 405827 lista os sistemas de arquivos recomendados para os ambientes HANA.
• 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.
• A wiki da comunidade 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
• Implantação de Máquinas Virtuais do Azure do DBMS para SAP no Linux
• Replicação do sistema SAP HANA no cluster do Pacemaker
• Documentação geral do RHEL (Red Hat Enterprise Linux):
  • Visão geral do complemento de alta disponibilidade
  • Administração de complemento de alta disponibilidade
  • Referência de complemento de alta disponibilidade
  • Configurar a replicação de sistema do SAP HANA na expansão em um cluster Pacemaker quando os sistemas de arquivos do HANA estiverem em compartilhamentos de NFS
• Documentação do RHEL específica do Azure:
  • Políticas de suporte para clusters de alta disponibilidade do RHEL - máquinas virtuais do Microsoft Azure como membros de cluster
  • Instalando e configurando um Cluster de alta disponibilidade do Red Hat Enterprise Linux 7.4 (e posterior) no Microsoft Azure
  • Configurar a replicação de sistema de expansão do SAP HANA em um cluster do Pacemaker quando os sistemas de arquivos do HANA estiverem em compartilhamentos de NFS
• Volumes NFS v4.1 no Azure NetApp Files para SAP HANA

Visão geral

Tradicionalmente em um ambiente de expansão, todos os sistemas de arquivos para SAP HANA são montados no armazenamento local. A configuração de HA (alta disponibilidade) da replicação de sistema do SAP HANA no Red Hat Enterprise Linux foi publicada em Configurar a replicação de sistema do SAP HANA no RHEL.

Para obter HA do SAP HANA de um sistema de expansão em compartilhamentos de NFS do Azure NetApp Files, precisamos de mais configuração de recursos no cluster para que os recursos do HANA sejam recuperados, quando um nó perde o acesso aos compartilhamentos de NFS em ANF. O cluster gerencia as montagens de NFS, permitindo que ele monitore a integridade dos recursos. As dependências entre as montagens do sistema de arquivos e os recursos de SAP HANA são obrigatórias.

.

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

Montado em node1 (hanadb1):

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

Montado em node2 (hanadb2):

• 10.32.2.4:/hanadb2-data-mnt00001 em /hana/data
• 10.32.2.4:/hanadb2-log-mnt00001 em /hana/log
• 10.32.2.4:/hanadb2-shared-mnt00001 em /hana/shared

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 mostrada aqui tem um balanceador de carga com:

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

Configurar a infraestrutura do Azure NetApp Files

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

O Azure NetApp Files está disponível em várias regiões do Azure. Verifique se a região do Azure selecionada oferece o Azure NetApp Files.

Para obter informações sobre a disponibilidade do Azure NetApp Files por região do Azure, confira Disponibilidade do Azure NetApp Files por região do Azure.

Considerações importantes

Ao criar os volumes de Azure NetApp Files para sistemas de expansão do SAP HANA, esteja ciente das considerações importantes documentadas em Volumes de NFS v4.1 no Azure NetApp Files para SAP HANA.

Dimensionamento do banco de dados do HANA no Azure NetApp Files

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

Ao projetar a infraestrutura do SAP HANA no Azure com Azure NetApp Files, esteja ciente das recomendações em Volumes de NFS v4.1 no Azure NetApp Files para SAP HANA.

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

Implantar recursos do Azure NetApp Files

As instruções a seguir pressupõem que você já implantou a Rede virtual do Azure. Os recursos do Azure NetApp Files e as VMs nas quais os recursos do Azure NetApp Files serão montados precisam ser implantados na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas.

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

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

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

3. Delegue uma sub-rede para o Azure NetApp Files, conforme descrito nas instruções em Delegar uma sub-rede ao Azure NetApp Files.

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

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

   Lembre-se de que os recursos do Azure NetApp Files e as VMs do Azure precisam estar na mesma rede virtual do Azure ou em redes virtuais do Azure emparelhadas. Por exemplo, hanadb1-data-mnt00001 e hanadb1-log-mnt00001 são os nomes de volume nfs://10.32.2.4/hanadb1-log-mnt00001 e nfs://10.32.2.4/hanadb1-data-mnt00001 são os caminhos de arquivo para os volumes do Azure NetApp Files.

   Em hanadb1:

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

   Em hanadb2:

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

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.

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.

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

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

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

Montar o volume de Azure NetApp Files

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

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

2. [A] Verifique a configuração do domínio NFS. Certifique-se de que o domínio esteja configurado como o domínio padrão do Azure NetApp Files, ou seja, defaultv4iddomain.com e de que o mapeamento esteja definido como nobody.

   sudo cat /etc/idmapd.conf
   

   Exemplo de saída:

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

   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 do NFS (ou seja, a VM) e o servidor do NFS, ou seja, a configuração do Azure NetApp Files, as permissões para arquivos nos volumes do Azure NetApp Files que forem montados nas VMs serão exibidas como nobody.

3. [1] Monte os volumes específicos do nó em node1 (hanadb1).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
   

4. [2] Monte os volumes específicos do nó em node2 (hanadb2).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
   

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

   sudo nfsstat -m
   

   Verifique se o sinalizador vers está definido como 4.1. Exemplo do hanadb1:

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

6. [A] 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 de montagem. Não é possível criar o diretório manualmente em /sys/modules, pois o acesso é reservado para o kernel e os drivers.

   Verifique nfs4_disable_idmapping.

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

   Se você precisar definir nfs4_disable_idmapping como:

   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Tornar a configuração permanente.

   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   Para obter mais informações sobre como alterar o parâmetro nfs_disable_idmapping, consulte a Base de conhecimento do Red Hat.

Instalação do SAP HANA

1. [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. Este exemplo mostra como usar o arquivo /etc/hosts. Substitua o endereço IP e o nome do host nos comandos a seguir:

   sudo vi /etc/hosts
   

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

   10.32.0.4   hanadb1
   10.32.0.5   hanadb2
   

2. [A] Prepare o sistema operacional para executar o SAP HANA no Azure NetApp com o NFS, conforme descrito na Nota do SAP 3024346 – Configurações do Kernel do Linux para NetApp com o NFS. Crie um arquivo /etc/sysctl.d/91-NetApp-HANA.conf de configuração para as configurações do NetApp.

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

   Adicionar as seguintes entradas no arquivo de configuração.

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

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

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

   Adicionar as seguintes entradas no arquivo de configuração.

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

   Dica

   Evite definir 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, consulte a Nota do SAP 2382421.

4. [A] Ajuste as configurações de sunrpc, conforme recomendado na Nota do SAP 3024346 — Configurações do Kernel do Linux para o NetApp NFS.

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

   Insira a seguinte linha:

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] Executar a configuração do sistema operacional do RHEL para o HANA.

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

   • 2292690 - Banco de dados do SAP HANA: configurações do sistema operacional recomendadas para RHEL 7
   • 2777782 - Banco de dados do SAP HANA: configurações do sistema operacional recomendadas para RHEL 8
   • 2455582 – Linux: executar aplicativos SAP compilados com GCC 6.x
   • 2593824 – Linux: executar aplicativos SAP compilados com GCC 7.x
   • 2886607 – Linux: executando aplicativos SAP compilados com GCC 9.x

6. [A] Instalar o SAP HANA.

   Iniciar com o HANA 2.0 SPS 01, MDC é a opção padrão. Ao instalar o sistema HANA, o SYSTEMDB e um locatário com o mesmo SID são criados juntos. Em alguns casos, você não deseja o locatário padrão. Caso não queira criar um locatário inicial junto com a instalação, segua a Nota do SAP 2629711.

   Execute o hdblcm programa a partir do DVD do HANA. Insira os valores a seguir no prompt:

   1. Escolha a instalação: insira 1 (para instalar).
   2. Selecione mais componentes para instalação: insira 1.
   3. Insira o Caminho de instalação [/hana/shared]: selecione Enter para aceitar o padrão.
   4. Insira o Nome do host local [..]: selecione Enter para aceitar o padrão. Você deseja adicionar outros hosts ao sistema? (s/n) [n]: n.
   5. Insira a ID do sistema SAP HANA: insira HN1.
   6. Insira o número da instância [00]: insira 03.
   7. Selecione o Modo de banco de dados/Insira o índice [1]: selecione Enter para aceitar o padrão.
   8. Selecione Uso do sistema/Inseria índice [4]: insira 4 (para personalizado)
   9. Insira o Local dos volumes de dados [/hana/data]: selecione Enter para aceitar o padrão.
   10. Insira o Local dos volumes de log [/hana/log]: selecione Enter para aceitar o padrão.
   11. Restringir a alocação máxima de memória? [n]: selecione Enter para aceitar o padrão.
   12. Insira o Nome do host do certificado para o host '...' [...]: selecione Enter para aceitar o padrão.
   13. Insira a Senha (sapadm) de usuário de agente de host do SAP : insira a senha de usuário de agente de host.
   14. Confirme a Senha (sapadm) de usuário de agente de host SAP: insira a senha de usuário de agente de host novamente para confirmar.
   15. Insira a Senha do administrador do sistema (hn1adm): insira a senha do administrador do sistema.
   16. Confirme a Senha do administrador do sistema (hn1adm): insira a senha do administrador do sistema novamente para confirmar.
   17. Insira o Diretório base do administrador do sistema [/usr/sap/HN1/home]: selecione Enter para aceitar o padrão.
   18. Insira o Shell de login do administrador do sistema [/bin/sh]: selecione Enter para aceitar o padrão.
   19. Insira a ID de usuário do administrador do sistema [1001]: selecione Enter para aceitar o padrão.
   20. Insira a ID do grupo de usuários (SAPs) [79]: selecione Enter para aceitar o padrão.
   21. Insira a Senha de usuário do banco de dados (SISTEMA) : insira a senha do usuário do banco de dados.
   22. Confirme a Senha do usuário do banco de dados (SISTEMA): insira a senha do usuário do banco de dados novamente para confirmar.
   23. Reiniciar o sistema após a reinicialização do computador? [n]: selecione Enter para aceitar o padrão.
   24. Deseja continuar? (S/N): Valide o resumo. Insira y para continuar.

7. [A] Atualize o Agente de Host do SAP.

   Baixe o último arquivo do Agente de Host do SAP no Centro de Software do SAP e execute o comando a seguir para atualizar o agente. Substitua o caminho do arquivo para apontar para o arquivo que você baixou:

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

8. [A] Configurar um 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 do SAP HANA

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

Configuração do cluster

Esta seção descreve as etapas necessárias para que um cluster opere de forma direta quando o SAP HANA é instalado em compartilhamentos de NFS usando Azure NetApp Files.

Criar um cluster do Pacemaker

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

Implementar o gancho SAPHanaSR de replicação do sistema Python

Essa é uma etapa importante para otimizar a integração com o cluster e melhorar a detecção, quando um failover de cluster for necessário. É fortemente recomendável que você configure o gancho do Python do SAPHanaSR. Siga as etapas em, Implementar o gancho SAPHanaSR de replicação do sistema Python.

Configurar recursos do sistema de arquivos

Neste exemplo, cada nó de cluster tem seus próprios sistemas de arquivos de NFS do HANA /hana/shared, /hana/data e /hana/log.

1. [1] Coloque o cluster no modo de manutenção.

   sudo pcs property set maintenance-mode=true
   

2. [1] Crie os recursos do sistema de arquivos para as montagens hanadb1.

   sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   

3. [2] Crie os recursos do sistema de arquivos para as montagens hanadb2.

   sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   

   O atributo OCF_CHECK_LEVEL=20 é adicionado à operação de monitoramento para que cada monitor execute 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. Sem essa opção, o comportamento padrão é parar todos os recursos que dependem do recurso com falha, reiniciar o recurso com falha e, em seguida, iniciar todos os recursos que dependem do recurso com falha.

   Esse comportamento não só pode levar muito tempo quando um recurso SAP HANA depende do recurso com falha, mas também pode falhar completamente. O recurso SAP HANA não poderá parar com êxito se o servidor NFS que contém os executáveis do HANA estiver inacessível.

   Os valores de tempo limite sugeridos permitem que os recursos do cluster resistam à pausa específica do protocolo, relacionada às renovações de tempo de concessão do NFSv4.1. Para obter mais informações, confira Melhor prática do NFS no NetApp. Os tempos limite na configuração anterior podem ser adaptados à configuração específica do SAP.

   Para cargas de trabalho que exigem maior taxa de transferência, considere usar a opção de montagem nconnect, conforme a descrição em Volumes NFS v4.1 no Azure NetApp Files para SAP HANA. Verifique se nconnect é compatível com o Azure NetApp Files em sua versão do Linux.

4. [1] Configurar restrições de localização.

   Configure restrições de local para garantir que os recursos que gerenciam montagens exclusivas hanadb1 nunca possam ser executados em hanadb2 e vice versa.

   sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
   sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
   

   A opção resource-discovery=never é definida porque as montagens exclusivas para cada nó compartilham o mesmo ponto de montagem. Por exemplo, hana_data1 usa o ponto /hana/data de montagem e hana_data2 também usa o ponto de montagem /hana/data. Compartilhar o mesmo ponto de montagem pode causar um falso positivo para uma operação de investigação de integridade, quando o estado do recurso é verificado na inicialização do cluster e, por sua vez, causar um comportamento de recuperação desnecessário. Para evitar esse cenário, defina resource-discovery=never.

5. [1] Configurar recursos de atributo.

   Configurar recursos de atributo. Esses atributos serão definidos como verdadeiros, se todas as montagens do NFS de um nó (/hana/data, /hana/log e /hana/data) forem montadas. Caso contrário, eles são definidos como falsos.

   sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
   sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
   

6. [1] Configurar restrições de localização.

   Configure restrições de local para garantir que o recurso de atributo do hanadb1 nunca seja executado em hanadb2 e vice versa.

   sudo pcs constraint location hana_nfs1_active avoids hanadb2
   sudo pcs constraint location hana_nfs2_active avoids hanadb1
   

7. [1] Criar restrições de ordenação.

   Configure restrições de ordenação para que os recursos de atributo de um nó sejam iniciados somente depois que todas as montagens NFS do nó forem montadas.

   sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
   sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
   

   Dica

   Se sua configuração incluir sistemas de arquivos, fora do grupo hanadb1_nfs ou hanadb2_nfs, inclua a sequential=false opção, de modo que não haja nenhuma dependência de ordenação entre os sistemas de arquivos. Todos os sistemas de arquivos devem iniciar antes hana_nfs1_active, mas não precisam iniciar em nenhuma ordem relativa uns ao outros. Para maiores informações, consulte Como fazer para configurar a replicação do sistema SAP HANA na expansão em um cluster do Pacemaker quando os sistemas de recursos do HANA estiverem em compartilhamentos de NFS

Configurar os recursos de cluster do SAP HANA

1. Siga as etapas em Criar os recursos de cluster do SAP HANA, para criar os recursos de SAP HANA no cluster. Após criar os recursos de SAP HANA, é necessário criar uma restrição de regra de local entre os recursos de SAP HANA e os arquivos do sistema (montagens do NFS).

2. [1] Configurar restrições entre os recursos de SAP HANA e as montagens de NFS.

   As restrições de regra de local são definidas para que os recursos de SAP HANA possam ser executados em um nó apenas se todas as montagens do NFS do nó estiverem montadas.

   sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   No RHEL 7.x:

   sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   No RHEL 8.x/9.x:

   sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

3. [1] Configurar restrições de ordenação para que os recursos do SAP em um nó interrompa antes de uma parada para qualquer uma das montagens do NFS.

   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
   

   No RHEL 7.x:

   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
   

   No RHEL 8.x/9.x:

   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
   

   Retire o cluster do modo de manutenção.

   sudo pcs property set maintenance-mode=false
   

   Verificar o status do cluster e de todos os recursos.

   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.

   sudo pcs status
   

   Exemplo de saída:

   Online: [ hanadb1 hanadb2 ]
   
   Full list of resources:
   
   rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1
   
   Resource Group: hanadb1_nfs
   hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
   hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
   hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1
   
   Resource Group: hanadb2_nfs
   hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
   hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
   hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2
   
   hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
   hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2
   
   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
   Started: [ hanadb1 hanadb2 ]
   
   Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
   Masters: [ hanadb1 ]
   Slaves: [ hanadb2 ]
   
   Resource Group: g_ip_HN1_03
   nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
   vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1
   

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 precisará mover o endereço IP virtual com o secundário do recurso SAPHana.

A configuração extra, que é necessária 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, é descrita em Configurar a replicação de sistema do HANA ativo/leitura habilitado no cluster Pacemaker.

Antes de continuar, verifique se você configurou totalmente o cluster de alta disponibilidade do Red Hat gerenciando o banco de dados do SAP HANA conforme descrito nas seções anteriores da documentação.

Testar a configuração do cluster

Esta seção descreve como é possível testar a configuração.

1. 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 a replicação do sistema HANA é o estado de sincronização, por exemplo com systemReplicationStatus:

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

2. 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 de SAP HANA dependem de binários, armazenados/hana/shared para executar operações durante o failover. O sistema de arquivos /hana/shared é montado em NFS no cenário apresentado.

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

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

   Estado do recurso antes de iniciar o teste:

   sudo pcs status
   

   Exemplo de saída:

   Full list of resources:
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1
   
   Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb1 hanadb2 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb1 ]
        Slaves: [ hanadb2 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1
   

   Coloque /hana/shared no modo somente leitura no nó de cluster ativo usando este comando:

   sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   

   hanadb será reinicializado ou desligado com base na ação definida em stonith (pcs property show stonith-action). Após o servidor (hanadb1) estiver inativo, o recurso do HANA será movido para hanadb2. É possível verificar o status do cluster em hanadb2.

   sudo pcs status
   

   Exemplo de saída:

   Full list of resources:
   
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Stopped
        hana_log1  (ocf::heartbeat:Filesystem):    Stopped
        hana_shared1       (ocf::heartbeat:Filesystem):    Stopped
   
    Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2
   

   É recomendável que você teste completamente a configuração de cluster do SAP HANA, executando também os testes descritos na Instalação da replicação do sistema de SAP HANA no sistema no RHEL.

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