Alta disponibilidad de varios SID de instancia de ASCS/SCS de SAP con clústeres de conmutación por error de Windows Server y disco compartido de Azure

  • Artículo

Windows OS Windows

Este artículo se centra en cómo pasar de una única instalación de ASCS/SCS de SAP a la configuración de varios identificadores de sistema SAP (SID) mediante la instalación de instancias en clúster de ASCS/SCS de SAP adicionales en un clúster existente de clústeres de conmutación por error de Windows Server (WSFC) con un disco compartido de Azure. Al completar este proceso, ha configurado un clúster de varios SID de SAP.

Requisitos previos y limitaciones

Puede usar discos SSD Premium de Azure como discos compartidos de Azure para la instancia de ASCS/SCS de SAP. Actualmente están en vigor las siguientes limitaciones:

  • Los discos de Azure Ultra Disk Storage y los discos SSD estándar de Azure no se admiten como discos compartidos de Azure para cargas de trabajo de SAP.
  • Los discos compartidos de Azure con discos SSD Premium son compatibles con la implementación de SAP en conjuntos de disponibilidad y zonas de disponibilidad.
  • Los discos compartidos de Azure con discos SSD Premium incluyen dos opciones de almacenamiento:
    • El almacenamiento con redundancia local (LRS) para discos compartidos SSD Premium (skuName valor de ) se admite con la implementación en conjuntos de Premium_LRSdisponibilidad.
    • El almacenamiento con redundancia de zona (ZRS) para discos compartidos SSD Premium (skuName valor de Premium_ZRS) se admite con la implementación en zonas de disponibilidad.
  • El valor de disco compartido de Azure maxShares determina cuántos nodos de clúster pueden usar el disco compartido. En el caso de una instancia de ASCS/SCS de SAP, normalmente se configuran dos nodos en WSFC. A continuación, establezca el valor de en maxShares2.
  • No se requiere un grupo de selección de ubicación de proximidad de Azure (PPG) para los discos compartidos de Azure. Pero para la implementación de SAP con PPG, siga estas directrices:
    • Si usa PPG para un sistema SAP implementado en una región, todas las máquinas virtuales que comparten un disco deben formar parte del mismo PPG.
    • Si usa PPG para un sistema SAP implementado entre zonas, como se describe en Grupos de selección de ubicación de proximidad con implementaciones zonales, puede conectar Premium_ZRS el almacenamiento a máquinas virtuales que comparten un disco.

Para más información, consulte la sección Limitaciones de la documentación de discos compartidos de Azure.

Consideraciones importantes para discos compartidos SSD Premium

Tenga en cuenta estos puntos importantes sobre los discos compartidos SSD Premium de Azure:

  • LRS para discos compartidos SSD Premium:

    • La implementación de SAP con LRS para discos compartidos SSD Premium funciona con un único disco compartido de Azure en un clúster de almacenamiento. Si hay un problema con el clúster de almacenamiento en el que se implementa el disco compartido de Azure, afecta a la instancia de ASCS/SCS de SAP.

  • ZRS para discos compartidos SSD Premium:

    • La latencia de escritura para ZRS es mayor que la de LRS porque la copia entre zonas de los datos.
    • La distancia entre las zonas de disponibilidad de diferentes regiones varía y, por tanto, la latencia del disco ZRS entre zonas de disponibilidad. Realice pruebas comparativas de los discos para identificar la latencia de los discos ZRS en su región.
    • ZRS para discos compartidos SSD Premium replica de forma sincrónica los datos en tres zonas de disponibilidad de la región. Si hay un problema en uno de los clústeres de almacenamiento, la instancia de ASCS/SCS de SAP continúa ejecutándose porque la conmutación por error de almacenamiento es transparente para la capa de aplicación.
    • Para más información, consulte la sección Limitaciones de la documentación sobre ZRS para discos administrados.

Importante

Debe cumplir las condiciones siguientes:

  • El SID de cada sistema de administración de bases de datos (DBMS) debe tener su propio clúster WSFC dedicado.
  • Los servidores de aplicaciones de SAP que pertenecen a un SID de SAP deben tener sus propias máquinas virtuales dedicadas.
  • No se admite una combinación de Enqueue Replication Server 1 (ERS1) y Enqueue Replication Server 2 (ERS2) en el mismo clúster.

Versiones de SO admitidas

Se admiten Windows Server 2016, 2019 y versiones posteriores. Use las imágenes más recientes del centro de datos.

Se recomienda encarecidamente usar al menos Windows Server 2019 Datacenter, por estos motivos:

  • WSFC en Windows Server 2019 es consciente de Azure.
  • Windows Server 2019 Datacenter incluye integración y reconocimiento del mantenimiento del host de Azure y una experiencia mejorada mediante la supervisión de eventos programados de Azure.
  • Puede usar nombres de red distribuidos. (Es la opción predeterminada). No es necesario tener una dirección IP dedicada para el nombre de red del clúster. Además, no es necesario configurar una dirección IP en un equilibrador de carga interno de Azure.

Architecture

Tanto ERS1 como ERS2 se admiten en una configuración de varios SID. No se admite una combinación de ERS1 y ERS2 en el mismo clúster.

En el ejemplo siguiente se muestran dos SID de SAP. Ambos tienen una arquitectura ERS1 donde:

  • EL SID1 de SAP se implementa en un disco compartido con ERS1. La instancia de ERS se instala en un host local y en una unidad local.

    EL SID1 de SAP tiene su propia dirección IP virtual (SID1 (A)SCS IP1), que está configurada en el equilibrador de carga interno de Azure.

  • EL SID2 de SAP se implementa en un disco compartido con ERS1. La instancia de ERS se instala en un host local y en una unidad local.

    SAP SID2 tiene su propia dirección IP virtual (SID2 (A)SCS IP2), que se configura en el equilibrador de carga interno de Azure.

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

En el ejemplo siguiente también se muestran dos SID de SAP. Ambos tienen una arquitectura ERS2 donde:

  • EL SID1 de SAP se implementa en un disco de partición con ERS2, que está agrupado y se implementa en una unidad local.

    EL SID1 de SAP tiene su propia dirección IP virtual (SID1 (A)SCS IP1), que está configurada en el equilibrador de carga interno de Azure.

    SAP ERS2 tiene su propia dirección IP virtual (SID1 ERS2 IP2), que está configurada en el equilibrador de carga interno de Azure.

  • EL SID2 de SAP se implementa en un disco de partición con ERS2, que está en clúster y se implementa en una unidad local.

    SAP SID2 tiene su propia dirección IP virtual (SID2 (A)SCS IP3), que se configura en el equilibrador de carga interno de Azure.

    SAP ERS2 tiene su propia dirección IP virtual (SID2 ERS2 IP4), que está configurada en el equilibrador de carga interno de Azure.

  • Hay un total de cuatro direcciones IP virtuales:

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

Preparación de la infraestructura

Instale una nueva instancia de SAP SID PR2, además de la instancia de ASCS/SCS de SAP pr1 en clúster existente.

Nombres de host y direcciones IP

En función del tipo de implementación, los nombres de host y las direcciones IP del escenario deben ser similares a los ejemplos siguientes.

Estos son los detalles de una implementación de SAP en un conjunto de disponibilidad de Azure:

Rol de nombre de host Nombre de host Dirección IP estática Conjunto de disponibilidad Valor de disco SkuName
Primer clúster ASCS/SCS de nodo de clúster pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Segundo clúster ASCS/SCS de nodo de clúster pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Nombre de red del clúster pr1clust 10.0.0.42 (solo para un clúster de Windows Server 2016) No aplicable
Nombre de red del clúster de ASCS de SID1 pr1-ascscl 10.0.0.43 No aplicable
Nombre de red del clúster de ERS de SID1 (solo para ERS2) pr1-erscl 10.0.0.44 No aplicable
Nombre de red del clúster de ASCS de SID2 pr2-ascscl 10.0.0.45 No aplicable
Nombre de red del clúster de ERS de SID2 (solo para ERS2) pr1-erscl 10.0.0.46 No aplicable

Estos son los detalles de una implementación de SAP en zonas de disponibilidad de Azure:

Rol de nombre de host Nombre de host Dirección IP estática Zona de disponibilidad Valor de disco SkuName
Primer clúster ASCS/SCS de nodo de clúster pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Segundo clúster ASCS/SCS de nodo de clúster pr1-ascs-11 10.0.0.5 AZ02
Nombre de red del clúster pr1clust 10.0.0.42 (solo para un clúster de Windows Server 2016) No aplicable
Nombre de red del clúster de ASCS de SID1 pr1-ascscl 10.0.0.43 No aplicable
Nombre de red del clúster de ERS de SID2 (solo para ERS2) pr1-erscl 10.0.0.44 No aplicable
Nombre de red del clúster de ASCS de SID2 pr2-ascscl 10.0.0.45 No aplicable
Nombre de red del clúster de ERS de SID2 (solo para ERS2) pr1-erscl 10.0.0.46 No aplicable

Los pasos de este artículo siguen siendo los mismos para ambos tipos de implementación. Pero si el clúster se ejecuta en un conjunto de disponibilidad, debe implementar LRS para discos compartidos SSD Premium de Azure (Premium_LRS). Si el clúster se ejecuta en una zona de disponibilidad, debe implementar ZRS para discos compartidos SSD Premium de Azure (Premium_ZRS).

Creación de un equilibrador de carga interno de Azure

Para la configuración de varios identificadores de SID de SAP, PR2, puede usar el mismo equilibrador de carga interno que ha creado para el SID de SAP, el sistema PR1. Para la arquitectura ENSA1 en Windows, solo necesitaría una dirección IP virtual para ASCS/SCS de SAP. Por otro lado, la arquitectura ENSA2 requiere dos direcciones IP virtuales: una para ASCS de SAP y otra para ERS2.

Configure una regla adicional de ip de front-end y equilibrio de carga para el SID de SAP, el sistema PR2 en el equilibrador de carga existente mediante las instrucciones siguientes. En esta sección se da por supuesto que la configuración del equilibrador de carga interno estándar para el SID de SAP, PR1 ya está en vigor, como se describe en creación de equilibrador de carga.

  1. Abra el mismo equilibrador de carga interno estándar que ha creado para el sistema SID de SAP, PR1.
  2. Configuración de IP de front-end: cree una dirección IP de front-end (ejemplo: 10.0.0.45).
  3. Grupo de back-end: el grupo de back-end es el mismo que el del sistema SAP SID PR1.
  4. Reglas de entrada: cree una regla de equilibrio de carga.
    • Dirección IP de front-end: selección de ip de front-end
    • Grupo de back-end: selección del grupo de back-end
    • Comprobación de "Puertos de alta disponibilidad"
    • Protocolo: TCP
    • Sondeo de estado: creación de sondeo de estado con los detalles siguientes
      • Protocolo: TCP
      • Puerto: [por ejemplo: 620<Instance-no.> for SAP SID, PR2 ASCS]
      • Intervalo: 5
      • Umbral de sondeo: 2
    • Tiempo de espera de inactividad (minutos): 30
    • Active "Habilitar IP flotante"
  5. Aplicable solo a la arquitectura de ENSA2: cree una dirección IP de front-end adicional (10.0.0.44), regla de equilibrio de carga (use 621<Instance-no.> para el puerto de sondeo de estado ERS2), como se describe en el punto 1 y 3.

Nota:

No se respeta la propiedad de configuración del sondeo de estado numberOfProbes, también conocida como "umbral incorrecto" en el Portal. Por lo tanto, para controlar el número de sondeos consecutivos correctos o erróneos, establezca la propiedad "probeThreshold" en 2. Actualmente no es posible establecer esta propiedad mediante Azure Portal, por lo que puede usar la CLI de Azure o el comando de PowerShell.

Importante

No se admite una dirección IP flotante en una configuración ip secundaria de tarjeta de interfaz de red (NIC) en escenarios de equilibrio de carga. Para ver detalles, consulte Limitaciones de Azure Load Balancer. Si necesita otra dirección IP para la VM, implemente una segunda NIC.

Nota:

Cuando las máquinas virtuales sin direcciones IP públicas se colocan en el grupo de back-end de una instancia interna de Standard Load Balancer (sin dirección IP pública), no habrá conectividad saliente a Internet, a menos que se realice una configuración adicional para permitir el enrutamiento a puntos de conexión públicos. Para más información sobre cómo conseguir conectividad saliente, consulte Conectividad de punto de conexión público para máquinas virtuales con Azure Standard Load Balancer en escenarios de alta disponibilidad de SAP.

Creación y conexión de un segundo disco compartido de Azure

Ejecute este comando en uno de los nodos del clúster. Ajuste los valores para obtener detalles como el grupo de recursos, la región de Azure y el SID de 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

Dar formato al disco compartido mediante PowerShell

  1. Obtenga el número de disco. Ejecute los comandos de PowerShell en uno de los nodos del clúster:

     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. Aplique formato al disco. En este ejemplo, es el número de disco 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. Compruebe que el disco ahora está visible como un disco de clúster:

     # 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 el disco en el clúster:

     # 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

Creación de un nombre de host virtual para la instancia de SAP ASCS/SCS en clúster

  1. Cree una entrada de DNS para el nombre de host virtual de la instancia de ASCS/SCS de SAP en el Administrador de DNS de Windows.

    La dirección IP que asignó al nombre de host virtual en DNS debe ser la misma que la dirección IP que asignó en Azure Load Balancer.

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

  2. Si usa una instancia en clúster de SAP ERS2, debe reservar en DNS un nombre de host virtual para ERS2.

    La dirección IP que asignó al nombre de host virtual para ERS2 en DNS debe ser la misma que la dirección IP que asignó en Azure Load Balancer.

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

  3. Para definir la dirección IP asignada al nombre de host virtual, seleccione Administrador de DNS>Dominio.

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

Instalación de SAP

Instalación del primer nodo de clúster de SAP

Siga el procedimiento de instalación descrito por SAP. Asegúrese de seleccionar First Cluster Node (Primer nodo de clúster) como opción para iniciar la instalación. Seleccione Disco compartido de clúster como opción de configuración. Elija el disco compartido recién creado.

Modificación del perfil SAP de la instancia de ASCS/SCS

Si ejecuta ERS1, agregue el parámetro enque/encni/set_so_keepalivede perfil de SAP . El parámetro profile impide que las conexiones entre los procesos de trabajo de SAP y el servidor de puesta en cola se cierren cuando estén inactivos durante demasiado tiempo. El parámetro SAP no es necesario para ERS2.

  1. Agregue este parámetro de perfil al perfil de instancia de ASCS/SCS de SAP, si usa ERS1:

    enque/encni/set_so_keepalive = true

    En el caso de ERS1 y ERS2, asegúrese de que los parámetros del sistema operativo keepalive se establecen tal y como se describe en la nota de SAP 1410736.

  2. Para aplicar los cambios en el parámetro de perfil de SAP, reinicie la instancia de ASCS/SCS de SAP.

Configuración de un puerto de sondeo en el recurso de clúster

Use la funcionalidad de sondeo del equilibrador de carga interno para que toda la configuración del clúster funcione con Azure Load Balancer. Habitualmente, el equilibrador de carga interno de Azure distribuye la carga de trabajo entrante de manera equitativa entre las máquinas virtuales que participan.

Sin embargo, este enfoque no funcionará en algunas configuraciones de clúster porque solo hay una instancia activa. La otra instancia es pasiva y no puede aceptar nada de la carga de trabajo. Una funcionalidad de sondeo ayuda cuando el equilibrador de carga interno de Azure detecta qué instancia está activa y tiene como destino solo la instancia activa.

Importante

En esta configuración de ejemplo, el puerto de sondeo se establece en 620nr. Para ASCS de SAP con el número de instancia 02, es 62002.

Debe ajustar la configuración para que coincida con los números de instancia de SAP y el SID de SAP.

Para agregar un puerto de sondeo, ejecute este módulo de PowerShell en una de las máquinas virtuales del clúster:

  • Si usa ASC/SCS de SAP con el número de instancia 02:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • Si usa ERS2 con el número de instancia 12, configure un puerto de sondeo. No es necesario configurar un puerto de sondeo para ERS1. ERS2 con el número de instancia 12 está agrupado, mientras que ERS1 no está agrupado.

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

El código de la función Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource tiene el siguiente aspecto:

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

Continuación de la instalación de SAP

  1. Instale la instancia de base de datos siguiendo el proceso descrito en la guía de instalación de SAP.

  2. Para instalar SAP en el segundo nodo de clúster, siga los pasos que se describen en la guía de instalación de SAP.

  3. Instale la instancia del servidor de aplicaciones principal (PAS) de SAP en la máquina virtual designada para hospedar el PAS.

    Siga el proceso descrito en la guía de instalación de SAP. No hay ninguna dependencia en Azure.

  4. Instale servidores de aplicaciones de SAP adicionales en las máquinas virtuales designadas para hospedar instancias de servidor de aplicaciones de SAP.

    Siga el proceso descrito en la guía de instalación de SAP. No hay ninguna dependencia en Azure.

Prueba de la conmutación por error de la instancia de ASCS/SCS de SAP

Las pruebas de conmutación por error descritas suponen que ASCS de SAP está activo en el nodo A.

  1. Compruebe que el sistema SAP puede conmutar por error correctamente desde el nodo A al nodo B. En este ejemplo, la prueba es para SAP SID PR2.

    Asegúrese de que cada SID de SAP pueda moverse correctamente al otro nodo del clúster. Elija una de estas opciones para iniciar una conmutación por error del grupo de clústeres <SID> de SAP desde el nodo del clúster A al nodo del clúster B:

    • Administrador de clústeres de conmutación por error
    • Comandos de PowerShell para clústeres de conmutación por error
    $SAPSID = "PR2"     # SAP <SID>

$SAPClusterGroup = "SAP $SAPSID"
Move-ClusterGroup -Name $SAPClusterGroup

  2. Reinicie el nodo del clúster A dentro del sistema operativo invitado Windows. Este paso inicia una conmutación automática por error del grupo de clústeres de SID> de SAP <desde el nodo A al nodo B.

  3. Reinicie el nodo del clúster A desde Azure Portal. Este paso inicia una conmutación automática por error del grupo de clústeres de SID> de SAP <desde el nodo A al nodo B.

  4. Reinicie el nodo del clúster A mediante Azure PowerShell. Este paso inicia una conmutación automática por error del grupo de clústeres de SID> de SAP <desde el nodo A al nodo B.

Pasos siguientes