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

  • Artigo

Windows OS Windows

Este artigo se concentra em como mover 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 (Windows Server Failover Clustering) 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. Existem as seguintes limitações no momento:

  • Os discos de Armazenamento em Disco Ultra do Azure e os discos SSD Padrão do Azure não têm suporte como discos compartilhados do Azure para cargas de trabalho SAP.
  • Os discos compartilhados do Azure com discos SSD Premium têm suporte para implantação SAP em conjuntos de disponibilidade e zonas de disponibilidade.
  • Os discos compartilhados do Azure com discos SSD Premium vêm 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, você normalmente configura dois nós no WSFC. Em seguida, defina o valor para maxShares2como .
  • Um PPG (grupo de posicionamento de proximidade) do Azure não é necessário para discos compartilhados do Azure. Mas para 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 para 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 compartilhados SSD Premium:

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

  • ZRS para discos compartilhados SSD Premium:

    • A latência de gravação do ZRS é maior do que a do LRS devido à cópia entre zonas de dados.
    • A distância entre zonas de disponibilidade em diferentes regiões varia, assim como a latência de disco ZRS entre zonas de disponibilidade. Faça um benchmark de seus discos para identificar a latência dos discos ZRS em sua região.
    • Os discos compartilhados ZRS for Premium SSD replicam 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.

Importante

A instalação deve atender às seguintes condições:

  • O SID para cada sistema de gerenciamento de banco de dados (DBMS) deve ter seu próprio cluster WSFC dedicado.
  • Os servidores de aplicativos SAP que pertencem a um SID SAP devem ter suas próprias máquinas virtuais (VMs) dedicadas.
  • Não há suporte para uma combinação de Enqueue Replication Server 1 (ERS1) e Enqueue Replication Server 2 (ERS2) no mesmo cluster.

Versões de SO com suporte

Há suporte para o Windows Server 2016, 2019 e versões posteriores. 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 por meio do monitoramento de 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. Não há suporte para uma combinação de ERS1 e ERS2 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.

Diagram of two high-availability SAP ASCS/SCS instances with an ERS1 configuration.

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

Diagram of two high-availability SAP ASCS/SCS instances with an ERS1 and ERS2 configuration.

Preparação da infraestrutura

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

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:

Função de nome de host Nome do host Endereço IP estático Conjunto de disponibilidade Valor do disco SkuName
Primeiro cluster ASCS/SCS do nó de cluster pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Segundo cluster ASCS/SCS do nó de cluster pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Nome da rede de cluster pr1clust 10.0.0.42 (somente para um cluster do Windows Server 2016) Não aplicável
SID1 Nome da rede do cluster de ASCS pr1-ascscl 10.0.0.43 Não aplicável
SID1 Nome da rede do cluster de ERS (somente para ERS2) pr1-erscl 10.0.0.44 Não aplicável
SID2 Nome da rede do cluster de ASCS pr2-ascscl 10.0.0.45 Não aplicável
SID2 Nome de rede de cluster de ERS (somente para ERS2) pr1-erscl 10.0.0.46 Não aplicável

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

Função de nome de host Nome do host Endereço IP estático Zona de disponibilidade Valor do disco SkuName
Primeiro cluster ASCS/SCS do nó de cluster pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Segundo cluster ASCS/SCS do nó de cluster pr1-ascs-11 10.0.0.5 AZ02
Nome da rede de cluster pr1clust 10.0.0.42 (somente para um cluster do Windows Server 2016) Não aplicável
SID1 Nome da rede do cluster de ASCS pr1-ascscl 10.0.0.43 Não aplicável
SID2 Nome de rede de cluster de ERS (somente para ERS2) pr1-erscl 10.0.0.44 Não aplicável
SID2 Nome da rede do cluster de ASCS pr2-ascscl 10.0.0.45 Não aplicável
SID2 Nome de rede de cluster de ERS (somente para ERS2) pr1-erscl 10.0.0.46 Não aplicável

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 do 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 do SSD Premium do Azure (Premium_ZRS).

Criar um balanceador de carga interno do Azure

Para a 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 de front-end 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á está 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 de front-end: Criar IP de front-end (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 de front-end: Selecione IP de front-end
    • Pool de back-end: selecione o pool de back-end
    • Verifique "Portas de alta disponibilidade"
    • Protocolo: TCP
    • Sonda de integridade: crie uma sonda de integridade com detalhes abaixo
      • Protocolo: TCP
      • Porta: [por exemplo: 620<Instance-no.> for SAP SID, PR2 ASCS]
      • Intervalo: 5
      • Limite da sonda: 2
    • Tempo limite ocioso (minutos): 30
    • Marque "Ativar IP flutuante"
  5. Aplicável apenas à arquitetura ENSA2: Criar IP de front-end adicional (10.0.0.44), regra de balanceamento de carga (use 621<Instance-no. para porta de teste de integridade ERS2), conforme descrito nos pontos 1 e 3.>

Observação

A propriedade de configuração Investigação de integridade, também conhecida como "Limite não íntegro" no portal, não é respeitada. Portanto, para controlar o número de testes consecutivos bem-sucedidos ou com falha, defina a propriedade "probeThreshold" como 2. No momento, não é possível definir essa propriedade usando o portal do Azure, portanto, use o comando CLI do Azure ou PowerShell .

Importante

Não há suporte para um endereço IP flutuante em uma configuração IP secundária de placa de interface de rede (NIC) em cenários de balanceamento de carga. Confira Limitações do Azure Load Balancer, para mais detalhes. Se você precisar de um endereço IP adicional para a VM, implante um segunda NIC.

Observação

Quando as VMs sem endereços IP públicos forem colocadas no pool de back-end de um balanceador de carga Standard interno do Azure (sem endereço IP público), não haverá nenhuma conectividade de saída com a Internet, a menos que você execute configurações adicionais a fim de permitir o roteamento para pontos de extremidade públicos. Para obter detalhes sobre como alcançar conectividade de saída, veja Conectividade de ponto de extremidade público para máquinas virtuais usando um Standard Load Balancer do Azure em cenários de alta disponibilidade do SAP.

Criar e anexar um segundo disco compartilhado do Azure

Execute o comando em um dos nós do cluster. Ajuste os valores para 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 esses 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 clusterizada do SAP ASCS/SCS

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

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

    Screenshot that shows options for defining a DNS entry for the SAP ASCS/SCS cluster virtual name and IP address.

  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 atribuído ao nome do host virtual para ERS2 no DNS deve ser o mesmo que o endereço IP atribuído no Balanceador de Carga do Azure.

    Screenshot that shows options for defining a DNS entry for the SAP ERS2 cluster virtual name and IP address.

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

    Screenshot that shows a new virtual name and IP address for SAP ASCS/SCS and ERS2 cluster configuration.

Instalação do SAP

Instalar o primeiro nó do cluster do 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 de Cluster como a opção de configuração. Escolha o disco compartilhado recém-criado.

Modificar o perfil SAP da instância do 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 enfileirado sejam fechadas quando elas ficam ociosas por muito tempo. O parâmetro SAP não é necessário para o 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, verifique se os parâmetros keepalive do sistema operacional estão definidos conforme descrito na observação do SAP número 1410736.

  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 investigação do balanceador interno de carga para fazer com que toda a configuração do cluster funcione com o Azure Load Balancer. Normalmente, um balanceador de carga interno do Azure 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 parte da carga de trabalho. Uma funcionalidade de teste ajuda quando o balanceador de carga interno do Azure detecta qual instância está ativa e tem como alvo apenas a instância ativa.

Importante

Nesta configuração de exemplo, a porta de teste é definida como 620nr. Para SAP ASCS com número de instância 02, é 62002.

Você precisa ajustar a configuração para corresponder aos números da instância SAP e ao SID do SAP.

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

  • Se você estiver usando 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á em cluster, enquanto o ERS1 não está em cluster.

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

O código para a função Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource tem a seguinte aparência:

 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 {}
 }

Continuar 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ó de 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 esteja 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 SAP possa ser movido com êxito para o outro nó de cluster. Você pode usar estas opções para iniciar um failover do grupo de clusters <SID> do SAP do nó A para o nó B de cluster:

    • 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ó A do cluster no sistema operacional Windows convidado. Esta etapa inicia um failover automático do grupo de clusters SAP <SID> do nó A para o nó B.

  3. Reinicie o nó A do cluster no 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ó A do cluster 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óximas etapas