Compartilhar via

Alta disponibilidade de vários SIDs para instância do SAP ASCS/SCS com clustering de failover do Windows Server e disco compartilhado do Azure

  • Artigo

Windows OS Windows

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

Pré-requisitos e limitações

Você pode usar os discos SSD Premium do Azure como discos compartilhados do Azure para a instância do SAP ASCS/SCS. Existem as seguintes limitações no momento:

  • Os discos de Armazenamento de Disco Ultra do Azure e os discos SSD Standard do Azure não tem suporte como discos compartilhados do Azure para cargas de trabalho do SAP.
  • Os discos compartilhados do Azure com os discos SSD Premium tem suporte para a implantação do SAP nos conjuntos de disponibilidade e nas zonas de disponibilidade.
  • Os discos compartilhados do Azure com discos SSD Premium vêm com duas opções de armazenamento:
    • O armazenamento com redundância local (LRS) para discos compartilhados SSD Premium (valor do skuName de Premium_LRS) tem suporte com a implantação em conjuntos de disponibilidade.
    • O armazenamento com redundância de zona (ZRS) para discos compartilhados SSD Premium (valor skuName de Premium_ZRS) tem suporte com a implantação em zonas de disponibilidade.
  • O valor do disco compartilhado do Azure maxShares determina quantos nós de cluster podem usar o disco compartilhado. Para uma instância do ASCS/SCS do SAP, você de modo geral configura dois nós no WSFC. Em seguida, defina o valor de maxShares como 2.
  • Um grupo de posicionamento por proximidade do Azure não é necessário para discos compartilhados do Azure. No entanto, para implantar o 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 precisam fazer parte do mesmo PPG.
    • Se estiver usando PPGs para um sistema SAP implantado em diversas zonas, conforme descrito em Grupos de Posicionamento por Proximidade com implantações zonais, você poderá anexar o armazenamento Premium_ZRS às máquinas virtuais que compartilham um disco.

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

Considerações importantes para discos compartilhados SSD Premium

Leve em conta esses pontos importantes sobre discos compartilhados SSD Premium do Azure:

  • LRS para discos compartilhados 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 ocorrer um problema com o cluster de armazenamento em que o disco compartilhado do Azure estiver implantado, sua instância do ASCS/SCS do SAP será afetada.

  • ZRS para discos compartilhados do SSD Premium:

    • A latência de gravação para ZRS é maior do que a do LRS devido à cópia de dados entre as zona cruzada.
    • A distância entre as zonas de disponibilidade em uma região diferente varia e a latência de disco ZRS em zonas de disponibilidade também. Crie um parâmetro de comparação de seus discos para identificar a latência dos discos ZRS na 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 ocorrer um problema em um dos clusters de armazenamento, sua instância do ASCS/SCS do SAP continuará sendo executada porque o failover de armazenamento é transparente para a camada de aplicativo.
    • Para obter mais informações, examine 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 DBMS (sistema de gerenciamento de banco de dados) deve ter seu próprio cluster WSFC dedicado.
  • Os servidores de aplicativos SAP que pertencem a um SID do SAP deverão ter suas próprias VMs (máquinas virtuais) dedicadas.
  • Não há suporte para uma combinação do Servidor de Replicação de Enfileiramento 1 (ERS1) e do Servidor de Replicação de Enfileiramento 2 (ERS2) no mesmo cluster.

Versões de SO com suporte

O Windows Server 2016, 2019 e posteriores têm suporte. Use as imagens do datacenter mais recentes.

Recomendamos fortemente 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 de host do Azure e uma experiência aprimorada ao monitorar os eventos agendados do Azure.
  • Você pode usar nomes de rede distribuída (essa é a opção padrão). Não é necessário ter um endereço IP dedicado para o nome de rede do cluster. Além disso, você não precisa configurar um endereço IP em um balanceador de carga interno do Azure.

Arquitetura

Há suporte para ERS1 e ERS2 em uma configuração de vários SID. Não há suporte para uma combinação de ERS1 e ERS2 no mesmo cluster.

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

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

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

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

    O SID2 do SAP tem um endereço IP virtual (SID2 (A) SCS IP2), configurado no balanceador de carga interno do Azure interno.

Diagrama de duas instâncias SAP ASCS/SCS de alta disponibilidade com uma configuração ERS1.

O exemplo a seguir também mostra dois SIDs do SAP. Ambos têm uma arquitetura ERS2 em que:

  • O SID1 do SAP é implantado em um disco de fragmento com ERS2, que é clusterizado e implantado em uma unidade local.

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

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

  • O SID2 do SAP é implantado em um disco de fragmento com ERS2, que é clusterizado e implantado em uma unidade local.

    A SID2 do SAP tem um endereço IP virtual (SID2 (A) SCS IP3), configurado no balanceador de carga interno do Azure.

    O ERS2 do SAP 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

Diagrama de duas instâncias SAP ASCS/SCS de alta disponibilidade com uma configuração ERS1 e ERS2.

Preparação da infraestrutura

Instale uma nova instância do SID do SAP PR2, além da instância do ASCS/SCS do SAP PR1 clusterizado 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 deveriam ser como os exemplos a seguir.

Aqui estão os detalhes de uma implantação do 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 SkuName de disco
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 do SAP em zonas de disponibilidade do Azure:

Função de nome de host Nome do host Endereço IP estático Zona de disponibilidade Valor SkuName de disco
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 em execução em um conjunto de disponibilidade, você precisará implantar o LRS para discos compartilhados do SSD Premium do Azure (Premium_LRS). Se o cluster estiver em execução 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 de vários SIDs do SAP, PR2, você pode usar o mesmo balanceador de carga interno criado para o SID do SAP, sistema PR1. Para a arquitetura ENSA1 no Windows, você precisaria apenas de um endereço IP virtual para SAP ASCS/SCS. Por outro lado, a arquitetura ENSA2 necessita de dois endereços IP virtuais - um para SAP ASCS e outro para ERS2.

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

  1. Abra o mesmo balanceador de carga interno padrão que você criou para o SID do SAP, sistema 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 é igual ao do sistema SID do SAP PR1.
  4. Regras de entrada: criar regras de balanceamento de carga.
    • Endereço IP de front-end: Selecionar o IP de front-end
    • Pool de back-end: Selecionar o pool de back-end
    • Verifique "Portas de alta disponibilidade"
    • Protocolo: TCP
    • Investigação de integridade: Crie uma investigação de integridade com os detalhes abaixo
      • Protocolo: TCP
      • Porta: [por exemplo: 620<Instance-no.> para SID do SAP, PR2 ASCS]
      • Intervalo: 5
      • Limite de Investigação: 2
    • Tempo limite ocioso (minutos): 30
    • Verificar "Habilitar IP Flutuante"
  5. Aplicável apenas à arquitetura ENSA2: Crie IP de front-end adicional (10.0.0.44), regra de balanceamento de carga (use 621<Instance-no.> para porta de investigação de integridade do 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 investigações consecutivas bem-sucedidas 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 da CLI do Azure ou do PowerShell.

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 obter detalhes como o grupo de recursos, a região do Azure e o SID do SAP.

$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. Nesse 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 que você atribuiu ao nome de host virtual no DNS deve ser o mesmo que o endereço IP atribuído no Azure Load Balancer.

    Captura de tela que mostra as opções para definir uma entrada DNS para o nome virtual do cluster SAP ASCS/SCS e o endereço IP.

  2. Se você estiver usando uma instância clusterizada do ERS2 do SAP, precisará reservar no DNS um nome de host virtual para 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 atribuído no Azure Load Balancer.

    Captura de tela que mostra as opções para definir uma entrada DNS para o nome virtual do cluster ERS2 do SAP e o endereço IP.

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

    Captura de tela que mostra um novo nome virtual e endereço IP para a configuração de cluster do SAP ASCS/SCS e ERS2.

Instalação do SAP

Instalar o primeiro nó do cluster do SAP

Siga o procedimento de instalação descrito do SAP. Selecione 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 criado recentemente.

Modificar o perfil SAP da instância do ASCS/SCS

Se você estiver executando o ERS1, adicione o parâmetro de perfil SAP enque/encni/set_so_keepalive. O parâmetro de perfil impede conexões entre os processos de trabalho do SAP e o servidor de enfileiramento de fechar quando estão ociosas por muito tempo. O parâmetro do SAP não é necessário para ERS2.

  1. Adicione este parâmetro de perfil ao perfil da instância do SAP ASCS/SCS, se você 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 no parâmetro do perfil SAP, reinicie a instância do SAP ASCS/SCS.

Configurar uma porta de investigação 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 investigação ajuda quando o balanceador de carga interno do Azure detecta qual instância está ativa e só tem esta como alvo.

Importante

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

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

Para adicionar uma porta de investigação, execute este módulo do PowerShell em uma das VMs do cluster:

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

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • Se você estiver usando o ERS2 com o número da instância 12, configure uma porta de investigação. Não é necessário configurar uma porta de investigação para ERS1. O ERS2 com o número da instância 12 está clusterizado, enquanto o ERS1 não está clusterizado.

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

O código da 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 {}
 }

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 PAS (Servidor de Aplicativos Primário) do SAP na máquina virtual que você designou 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 que são 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 o failover da instância do SAP ASCS/SCS

Os testes de failover descritos presumem 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 SID do SAP PR2.

    Confira se cada SID do SAP pode 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