Alta disponibilidade de instância SAP ASCS/SCS multi-SID com Clustering de Failover do Windows Server e disco compartilhado do Azure

Mac OS

Este artigo se concentra em como passar de uma única instalação SAP ASCS/SCS para a configuração de vários SIDs (IDs de sistema) SAP instalando instâncias clusterizadas SAP ASCS/SCS adicionais em um cluster WSFC (Cluster de Failover do Windows Server) existente com um disco compartilhado do Azure. Ao concluir esse processo, você configurou um cluster SAP multi-SID.

Pré-requisitos e limitações

Você pode usar discos SSD Premium do Azure como discos compartilhados do Azure para a instância SAP ASCS/SCS. Estão atualmente em vigor as seguintes limitações:

• Os discos de Armazenamento de Disco Ultra do Azure e os discos SSD Padrão do Azure não são suportados como discos partilhados do Azure para cargas de trabalho SAP.
• Os discos partilhados do Azure com discos SSD Premium têm suporte para implementação SAP em conjuntos de disponibilidade e zonas de disponibilidade.
• Os discos partilhados do Azure com discos SSD Premium são fornecidos com duas opções de armazenamento:
  • O armazenamento localmente redundante (LRS) para discos compartilhados SSD Premium (skuName valor de) é suportado com a implantação em conjuntos de Premium_LRSdisponibilidade.
  • O armazenamento com redundância de zona (ZRS) para discos compartilhados SSD Premium (skuName valor de ) é suportado com a implantação em zonas de Premium_ZRSdisponibilidade.
• O valor de disco compartilhado do Azure maxShares determina quantos nós de cluster podem usar o disco compartilhado. Para uma instância SAP ASCS/SCS, normalmente você configura dois nós no WSFC. Em seguida, defina o valor para maxShares 2.
• Um grupo de posicionamento de proximidade (PPG) do Azure não é necessário para discos compartilhados do Azure. Mas para a implantação do SAP com PPGs, siga estas diretrizes:
  • Se você estiver usando PPGs para um sistema SAP implantado em uma região, todas as máquinas virtuais que compartilham um disco devem fazer parte do mesmo PPG.
  • Se você estiver usando PPGs para um sistema SAP implantado em zonas, conforme descrito em Grupos de posicionamento de proximidade com implantações zonais, poderá anexar Premium_ZRS armazenamento a máquinas virtuais que compartilham um disco.

Para obter mais informações, consulte a seção Limitações da documentação dos discos compartilhados do Azure.

Considerações importantes para discos compartilhados SSD Premium

Considere estes pontos importantes sobre os discos compartilhados do SSD Premium do Azure:

• LRS para discos partilhados SSD Premium:

  • A implantação do SAP com LRS para discos compartilhados SSD Premium opera com um único disco compartilhado do Azure em um cluster de armazenamento. Se houver um problema com o cluster de armazenamento onde o disco compartilhado do Azure está implantado, isso afetará sua instância SAP ASCS/SCS.

• ZRS para discos compartilhados SSD Premium:

  • A latência de gravação para ZRS é maior do que a do LRS porque a cópia interzonal de dados.
  • A distância entre as zonas de disponibilidade em diferentes regiões varia, assim como a latência do disco ZRS nas zonas de disponibilidade. Faça um benchmark de seus discos para identificar a latência dos discos ZRS em sua região.
  • O ZRS para discos compartilhados SSD Premium replica dados de forma síncrona em três zonas de disponibilidade na região. Se houver um problema em um dos clusters de armazenamento, sua instância SAP ASCS/SCS continuará a ser executada porque o failover de armazenamento é transparente para a camada de aplicativo.
  • Para obter mais informações, consulte a seção Limitações da documentação sobre o ZRS para discos gerenciados.

Versões de SO suportadas

Windows Server 2016, 2019 e posterior são suportados. Use as imagens mais recentes do datacenter.

É altamente recomendável usar pelo menos o Windows Server 2019 Datacenter, pelos seguintes motivos:

• O WSFC no Windows Server 2019 reconhece o Azure.
• O Windows Server 2019 Datacenter inclui integração e reconhecimento da manutenção do host do Azure e experiência aprimorada monitorando eventos agendados do Azure.
• Você pode usar nomes de rede distribuídos. (É a opção padrão.) Não é necessário ter um endereço IP dedicado para o nome da rede do cluster. Além disso, você não precisa configurar um endereço IP em um balanceador de carga interno do Azure.

Arquitetura

Tanto o ERS1 quanto o ERS2 são suportados em uma configuração multi-SID. Uma combinação de ERS1 e ERS2 não é suportada no mesmo cluster.

O exemplo a seguir mostra dois SIDs SAP. Ambos têm uma arquitetura ERS1 onde:

• O SAP SID1 é implantado em um disco compartilhado com o ERS1. A instância do ERS é instalada em um host local e em uma unidade local.

  O SAP SID1 tem seu próprio endereço IP virtual (SID1 (A)SCS IP1), que é configurado no balanceador de carga interno do Azure.

• O SAP SID2 é implantado em um disco compartilhado com o ERS1. A instância do ERS é instalada em um host local e em uma unidade local.

  O SAP SID2 tem seu próprio endereço IP virtual (SID2 (A)SCS IP2), que é configurado no balanceador de carga interno do Azure.

O próximo exemplo também mostra dois SIDs SAP. Ambos têm uma arquitetura ERS2 onde:

• O SAP SID1 é implantado em um disco rígido com ERS2, que é clusterizado e implantado em uma unidade local.

  O SAP SID1 tem seu próprio endereço IP virtual (SID1 (A)SCS IP1), que é configurado no balanceador de carga interno do Azure.

  O SAP ERS2 tem seu próprio endereço IP virtual (SID1 ERS2 IP2), que é configurado no balanceador de carga interno do Azure.

• O SAP SID2 é implantado em um disco rígido com ERS2, que é clusterizado e implantado em uma unidade local.

  O SAP SID2 tem seu próprio endereço IP virtual (SID2 (A)SCS IP3), que é configurado no balanceador de carga interno do Azure.

  O SAP ERS2 tem seu próprio endereço IP virtual (SID2 ERS2 IP4), que é configurado no balanceador de carga interno do Azure.

• Há um total de quatro endereços IP virtuais:

  • SID1 (A)SCS IP1
  • SID2 ERS2 IP2
  • SID2 (A)SCS IP3
  • SID2 ERS2 IP4

Preparação de infraestruturas

Você instala uma nova instância do SAP SID PR2, além da instância existente do SAP PR1 ASCS/SCS clusterizada.

Nomes de host e endereços IP

Com base no seu tipo de implantação, os nomes de host e os endereços IP do cenário devem ser como os exemplos a seguir.

Aqui estão os detalhes de uma implantação SAP em um conjunto de disponibilidade do Azure:

Aqui estão os detalhes de uma implantação SAP nas zonas de disponibilidade do Azure:

As etapas neste artigo permanecem as mesmas para ambos os tipos de implantação. Mas se o cluster estiver sendo executado em um conjunto de disponibilidade, você precisará implantar o LRS para discos compartilhados SSD Premium do Azure (Premium_LRS). Se o cluster estiver sendo executado em uma zona de disponibilidade, você precisará implantar o ZRS para discos compartilhados SSD Premium do Azure (Premium_ZRS).

Criar um balanceador de carga interno do Azure

Para configuração multi-sid do SAP SID, PR2, você pode usar o mesmo balanceador de carga interno que você criou para o sistema SAP SID, PR1. Para a arquitetura ENSA1 no Windows, você precisaria de apenas um endereço IP virtual para SAP ASCS/SCS. Por outro lado, a arquitetura ENSA2 requer dois endereços IP virtuais - um para SAP ASCS e outro para ERS2.

Configure IP frontend adicional e regra de balanceamento de carga para o sistema SAP SID, PR2 no balanceador de carga existente usando as seguintes diretrizes. Esta seção pressupõe que a configuração do balanceador de carga interno padrão para SAP SID, PR1 já esteja em vigor conforme descrito em create load balancer.

1. Abra o mesmo balanceador de carga interno padrão que você criou para o sistema SAP SID, PR1.
2. Configuração de IP Frontend: Crie IP frontend (exemplo: 10.0.0.45).
3. Pool de back-end: O pool de back-end é o mesmo do sistema SAP SID PR1.
4. Regras de entrada: crie uma regra de balanceamento de carga.
   • Endereço IP frontend: Selecione frontend IP
   • Pool de back-end: selecione pool de back-end
   • Marque "Portas de alta disponibilidade"
   • Protocolo: TCP
   • Sonda de saúde: crie uma sonda de saúde com os detalhes abaixo
     • Protocolo: TCP
     • Porta: [por exemplo: 620<Instance-no.> for SAP SID, PR2 ASCS]
     • Intervalo: 5
     • Limiar da sonda: 2
   • Tempo limite de inatividade (minutos): 30
   • Marque "Ativar IP flutuante"
5. Aplicável apenas à arquitetura ENSA2: Crie IP de frontend adicional (10.0.0.44), regra de balanceamento de carga (use 621<Instance-no.> para a porta de sonda de integridade ERS2), conforme descrito nos pontos 1 e 3.

Criar e anexar um segundo disco compartilhado do Azure

Execute este comando em um dos nós do cluster. Ajuste os valores para obter detalhes como seu grupo de recursos, região do Azure e SAP SID.

$ResourceGroupName = "MyResourceGroup"
$location = "MyRegion"
$SAPSID = "PR2"
$DiskSizeInGB = 512
$DiskName = "$($SAPSID)ASCSSharedDisk"
$NumberOfWindowsClusterNodes = 2

# For SAP deployment in an availability set, use this storage SkuName value
$SkuName = "Premium_LRS"
# For SAP deployment in an availability zone, use this storage SkuName value
$SkuName = "Premium_ZRS"

$diskConfig = New-AzDiskConfig -Location $location -SkuName $SkuName  -CreateOption Empty  -DiskSizeGB $DiskSizeInGB -MaxSharesCount $NumberOfWindowsClusterNodes
    
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroupName -DiskName $DiskName -Disk $diskConfig
##################################
## Attach the disk to cluster VMs
##################################
# ASCS cluster VM1
$ASCSClusterVM1 = "pr1-ascs-10"
# ASCS cluster VM2
$ASCSClusterVM2 = "pr1-ascs-11"
# Next free LUN
$LUNNumber = 1

# Add the Azure shared disk to Cluster Node 1
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM1 
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

# Add the Azure shared disk to Cluster Node 2
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

Formatar o disco compartilhado usando o PowerShell

1. Obtenha o número do disco. Execute estes comandos do PowerShell em um dos nós do cluster:

    Get-Disk | Where-Object PartitionStyle -Eq "RAW"  | Format-Table -AutoSize 
    # Example output
    # Number Friendly Name     Serial Number HealthStatus OperationalStatus Total Size Partition Style
    # ------ -------------     ------------- ------------ ----------------- ---------- ---------------
    # 3      Msft Virtual Disk               Healthy      Online                512 GB RAW            
   
   

2. Formate o disco. Neste exemplo, é o disco número 3:

    # Format SAP ASCS disk number 3, with drive letter S
    $SAPSID = "PR2"
    $DiskNumber = 3
    $DriveLetter = "S"
    $DiskLabel = "$SAPSID" + "SAP"
   
    Get-Disk -Number $DiskNumber | Where-Object PartitionStyle -Eq "RAW" | Initialize-Disk -PartitionStyle GPT -PassThru |  New-Partition -DriveLetter $DriveLetter -UseMaximumSize | Format-Volume  -FileSystem ReFS -NewFileSystemLabel $DiskLabel -Force -Verbose
    # Example outout
    # DriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining      Size
    # ----------- --------------- ---------- --------- ------------ ----------------- -------------      ----
    # S           PR2SAP          ReFS       Fixed     Healthy      OK                    504.98 GB 511.81 GB
   

3. Verifique se o disco agora está visível como um disco de cluster:

    # List all disks
    Get-ClusterAvailableDisk -All
    # Example output
    # Cluster    : pr1clust
    # Id         : c469b5ad-d089-4d8f-ae4c-d834cbbde1a2
    # Name       : Cluster Disk 2
    # Number     : 3
    # Size       : 549755813888
    # Partitions : {\\?\GLOBALROOT\Device\Harddisk3\Partition2\}
   

4. Registre o disco no cluster:

    # Add the disk to the cluster 
    Get-ClusterAvailableDisk -All | Add-ClusterDisk
    # Example output 
    # Name           State  OwnerGroup        ResourceType 
    # ----           -----  ----------        ------------ 
    # Cluster Disk 2 Online Available Storage Physical Disk
   

Criar um nome de host virtual para a instância SAP ASCS/SCS clusterizada

1. Crie uma entrada DNS para o nome do host virtual para a nova instância SAP ASCS/SCS no gerenciador de DNS do Windows.

   O endereço IP que você atribuiu ao nome do host virtual no DNS deve ser o mesmo que o endereço IP que você atribuiu no Balanceador de Carga do Azure.

   

2. Se você estiver usando uma instância clusterizada do SAP ERS2, precisará reservar no DNS um nome de host virtual para o ERS2.

   O endereço IP que você atribuiu ao nome de host virtual para ERS2 no DNS deve ser o mesmo que o endereço IP que você atribuiu no Balanceador de Carga do Azure.

   

3. Para definir o endereço IP atribuído ao nome do host virtual, selecione Domínio do Gerenciador>DNS.

   

Instalação SAP

Instalar o primeiro nó de cluster SAP

Siga o procedimento de instalação descrito pelo SAP. Certifique-se de selecionar Primeiro nó de cluster como a opção para iniciar a instalação. Selecione Disco compartilhado do cluster como a opção de configuração. Escolha o disco compartilhado recém-criado.

Modificar o perfil SAP da instância ASCS/SCS

Se você estiver executando o ERS1, adicione o parâmetro enque/encni/set_so_keepalivede perfil SAP . O parâmetro profile impede que as conexões entre os processos de trabalho SAP e o servidor enqueue sejam fechadas quando estiverem ociosas por muito tempo. O parâmetro SAP não é necessário para ERS2.

1. Adicione este parâmetro de perfil ao perfil de instância SAP ASCS/SCS, se estiver usando ERS1:

   enque/encni/set_so_keepalive = true
   

   Para ERS1 e ERS2, certifique-se de que os parâmetros do keepalive SO estão definidos conforme descrito na nota 1410736 do SAP.

2. Para aplicar as alterações ao parâmetro de perfil SAP, reinicie a instância SAP ASCS/SCS.

Configurar uma porta de teste no recurso de cluster

Use a funcionalidade de teste do balanceador de carga interno para fazer com que toda a configuração do cluster funcione com o Balanceador de Carga do Azure. O balanceador de carga interno do Azure geralmente distribui a carga de trabalho de entrada igualmente entre as máquinas virtuais participantes.

No entanto, essa abordagem não funcionará em algumas configurações de cluster porque apenas uma instância está ativa. A outra instância é passiva e não pode aceitar nenhuma carga de trabalho. Uma funcionalidade de teste ajuda quando o balanceador de carga interno do Azure deteta qual instância está ativa e direciona apenas a instância ativa.

Para adicionar uma porta de teste, execute este módulo do PowerShell em uma das VMs de cluster:

• Se você estiver usando o SAP ASC/SCS com o número de instância 02:

  Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002
  

• Se você estiver usando ERS2 com o número de instância 12, configure uma porta de teste. Não há necessidade de configurar uma porta de teste para ERS1. O ERS2 com o número de instância 12 está agrupado, enquanto o ERS1 não está agrupado.

  Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62012 -IsSAPERSClusteredInstance $True
  

O código para a função Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource se parece com este exemplo:

 function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource {
 <#
 .SYNOPSIS 
 Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer health probe port on the SAP $SAPSID IP cluster resource.
    
 .DESCRIPTION
 Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer health probe port on the SAP $SAPSID IP cluster resource.
 It will also restart the SAP cluster group (default behavior), to activate the changes. 
    
 You need to run it on one of the SAP ASCS/SCS Windows cluster nodes.
    
 The expectation is that the SAP group is installed with the official SWPM installation tool, which will set the default expected naming convention for:
 - SAP cluster group:               SAP $SAPSID
 - SAP cluster IP address resource: SAP $SAPSID IP 
    
 .PARAMETER SAPSID 
 SAP SID - three characters, starting with a letter.
    
 .PARAMETER ProbePort 
 Azure Load Balancer health check probe port.
    
 .PARAMETER RestartSAPClusterGroup 
 Optional parameter. Default value is $True, so the SAP cluster group will be restarted to activate the changes.
    
 .PARAMETER IsSAPERSClusteredInstance 
 Optional parameter. Default value is $False.
 If it's set to $True, then handle the clustered new SAP ERS2 instance.
    
    
 .EXAMPLE 
 # Set the probe port to 62000 on SAP cluster resource SAP AB1 IP, and restart the SAP cluster group SAP AB1 to activate the changes.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 
    
 .EXAMPLE 
 # Set the probe port to 62000 on SAP cluster resource SAP AB1 IP. SAP cluster group SAP AB1 is not restarted, so the changes are not active.
 # To activate the changes, you need to manually restart the SAP AB1 cluster group.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -RestartSAPClusterGroup $False
    
 .EXAMPLE 
 # Set the probe port to 62001 on SAP cluster resource SAP AB1 ERS IP. SAP cluster group SAP AB1 ERS is restarted to activate the changes.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -IsSAPERSClusteredInstance $True
        
 #> 
    
     [CmdletBinding()]
     param(
            
         [Parameter(Mandatory=$True)]
         [ValidateNotNullOrEmpty()]  
         [ValidateLength(3,3)]      
         [string]$SAPSID,

         [Parameter(Mandatory=$True)]
         [ValidateNotNullOrEmpty()]        
         [int] $ProbePort,
    
         [Parameter(Mandatory=$False)] 
         [bool] $RestartSAPClusterGroup = $True,
    
         [Parameter(Mandatory=$False)] 
         [bool] $IsSAPERSClusteredInstance = $False
      
     )
  
     BEGIN{}
        
     PROCESS{
         try{                                      
                
             if($IsSAPERSClusteredInstance){
                 #Handle clustered SAP ERS instance
                 $SAPClusterRoleName = "SAP $SAPSID ERS"
                 $SAPIPresourceName = "SAP $SAPSID ERS IP"            
             }else{
                 #Handle clustered SAP ASCS/SCS instance
                 $SAPClusterRoleName = "SAP $SAPSID"
                 $SAPIPresourceName = "SAP $SAPSID IP"
             }

             $SAPIPResourceClusterParameters =  Get-ClusterResource $SAPIPresourceName | Get-ClusterParameter
             $IPAddress = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Address" }).Value
             $NetworkName = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Network" }).Value
             $SubnetMask = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "SubnetMask" }).Value
             $OverrideAddressMatch = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "OverrideAddressMatch" }).Value
             $EnableDhcp = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "EnableDhcp" }).Value
             $OldProbePort = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "ProbePort" }).Value
    
             $var = Get-ClusterResource | Where-Object {  $_.name -eq $SAPIPresourceName  }
    
             #Write-Host "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" -ForegroundColor Cyan
             Write-Output "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" 
   
             Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
    
             Write-Output " "
             Write-Output "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'." 
             Write-Output " "
             Write-Output "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..." 
             Write-Output " "
    
             $var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
    
             Write-Output " "
    
             #$ActivateChanges = Read-Host "Do you want to take restart SAP cluster role '$SAPClusterRoleName', to activate the changes (yes/no)?"
    
             if($RestartSAPClusterGroup){
                 Write-Output ""
                 Write-Output "Activating changes..." 
    
                 Write-Output " "
                 Write-Output "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..."
                 Stop-ClusterResource -Name $SAPIPresourceName
                 sleep 5
    
                 Write-Output "Starting SAP cluster role '$SAPClusterRoleName' ..."
                 Start-ClusterGroup -Name $SAPClusterRoleName
    
                 Write-Output "New ProbePort parameter is active." 
                 Write-Output " "
    
                 Write-Output "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':" 
                 Write-Output " " 
                 Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
             }else
             {
                 Write-Output "SAP cluster role '$SAPClusterRoleName' is not restarted, therefore changes are not activated."
             }
         }
         catch{
            Write-Error  $_.Exception.Message
        }
    
     }
    
     END {}
 }

Continue com a instalação do SAP

1. Instale a instância do banco de dados seguindo o processo descrito no guia de instalação do SAP.

2. Instale o SAP no segundo nó do cluster seguindo as etapas descritas no guia de instalação do SAP.

3. Instale a instância do SAP Primary Application Server (PAS) na máquina virtual designada para hospedar o PAS.

   Siga o processo descrito no guia de instalação do SAP. Não há dependências no Azure.

4. Instale servidores de aplicativos SAP adicionais nas máquinas virtuais designadas para hospedar instâncias do servidor de aplicativos SAP.

   Siga o processo descrito no guia de instalação do SAP. Não há dependências no Azure.

Testar failover de instância SAP ASCS/SCS

Os testes de failover descritos pressupõem que o SAP ASCS está ativo no nó A.

1. Verifique se o sistema SAP pode fazer failover com êxito do nó A para o nó B. Neste exemplo, o teste é para SAP SID PR2.

   Certifique-se de que cada SID do SAP possa ser movido com êxito para o outro nó do cluster. Escolha uma destas opções para iniciar um failover do grupo de clusters SAP <SID> do nó de cluster A para o nó de cluster B:

   • Gerenciador de Cluster de Failover
   • Comandos do PowerShell para clusters de failover

   $SAPSID = "PR2"     # SAP <SID>
   
   $SAPClusterGroup = "SAP $SAPSID"
   Move-ClusterGroup -Name $SAPClusterGroup
   
   

2. Reinicie o nó de cluster A no sistema operacional convidado do Windows. Esta etapa inicia um failover automático do grupo de clusters SAP <SID> do nó A para o nó B.

3. Reinicie o nó de cluster A a partir do portal do Azure. Esta etapa inicia um failover automático do grupo de clusters SAP <SID> do nó A para o nó B.

4. Reinicie o nó de cluster A usando o Azure PowerShell. Esta etapa inicia um failover automático do grupo de clusters SAP <SID> do nó A para o nó B.

Próximos passos

• Preparar a infraestrutura do Azure para SAP HA usando um cluster de failover do Windows e um disco compartilhado para uma instância SAP ASCS/SCS
• Instalar o SAP NetWeaver HA em um cluster de failover do Windows e disco compartilhado para uma instância SAP ASCS/SCS