Udostępnij za pośrednictwem

Wysoka dostępność wystąpienia SAP ASCS/SCS z wieloma identyfikatorami SID przy użyciu klastra trybu failover systemu Windows Server i dysku udostępnionego platformy Azure

System operacyjny Windows Windows

Ten artykuł koncentruje się na tym, jak przejść z pojedynczej instalacji SAP ASCS/SCS do konfiguracji wielu identyfikatorów systemu SAP (SID), instalując dodatkowe wystąpienia klastrowe SAP ASCS/SCS w istniejącym klastrze Windows Server Failover Clustering (WSFC) z użyciem współdzielonego dysku Azure. Po zakończeniu tego procesu skonfigurowano klaster SAP z wieloma SID-ami.

Wymagania wstępne i ograniczenia

Dyski SSD w warstwie Premium platformy Azure można używać jako dysków udostępnionych platformy Azure dla instancji SAP ASCS/SCS. Obecnie obowiązują następujące ograniczenia:

  • Dyski Azure Ultra Disk Storage i dyski Azure Standard SSD nie są obsługiwane jako dyski udostępnione platformy Azure dla obciążeń SAP.
  • Udostępnione dyski Azure z dyskami SSD Premium są obsługiwane dla wdrożenia SAP w zestawach dostępności i strefach dostępności.
  • Udostępniane dyski Azure z dyskami SSD Premium mają dwie opcje przechowywania:
    • Magazyn lokalnie nadmiarowy (LRS) dla udostępnionych dysków SSD w wersji Premium (skuName wartość Premium_LRS) jest obsługiwany podczas wdrażania w zestawach dostępności.
    • Magazyn redundacyjny w strefach (ZRS) dla współdzielonych dysków SSD klasy Premium (wartość skuName) jest obsługiwany we wdrożeniu w strefach dostępności Premium_ZRS.
  • Wartość dysku udostępnionego platformy Azure maxShares określa, ile węzłów klastra może używać dysku udostępnionego. W przypadku wystąpienia SAP ASCS/SCS zwykle konfigurujesz dwa węzły w klastrze WSFC. Następnie należy ustawić wartość parametru maxShares na 2.
  • Grupa umiejscowienia w pobliżu Azure (PPG) nie jest wymagana dla współdzielonych dysków Azure. Jednak w przypadku wdrożenia SAP z grupami PPG postępuj zgodnie z następującymi wytycznymi:
    • Jeśli używasz PPG dla systemu SAP wdrożonego w regionie, wszystkie maszyny wirtualne współużytkujące dysk muszą być częścią tego samego PPG.
    • Jeśli używasz grup bliskiego umieszczania (PPG) dla systemu SAP wdrożonego w różnych strefach, zgodnie z opisem w temacie Grupy umieszczania w pobliżu z wdrożeniami strefowymi, możesz dołączyć Premium_ZRS magazyn do maszyn wirtualnych, które współużytkują dysk.

Aby uzyskać więcej informacji, zapoznaj się z sekcją Ograniczenia dokumentacji dotyczącej dysków udostępnionych platformy Azure.

Ważne zagadnienia dotyczące udostępnionych dysków SSD w warstwie Premium

Weź pod uwagę następujące ważne kwestie dotyczące dysków udostępnionych SSD w warstwie Premium platformy Azure:

  • LRS dla udostępnionych dysków SSD w warstwie Premium:

    • Wdrożenie SAP z magazynem LRS dla udostępnionych dysków SSD w warstwie Premium działa z jednym udostępnionym dyskiem platformy Azure w jednym klastrze magazynowania. Jeśli występuje problem z klastrem storage, w którym wdrożono dysk udostępniony platformy Azure, ma to wpływ na instancję SAP ASCS/SCS.

  • Strefowe replikowanie danych dla udostępnionych dysków SSD w warstwie Premium:

    • Opóźnienie zapisu dla magazynu ZRS jest wyższe niż w przypadku magazynu LRS ze względu na kopiowanie danych między strefami.
    • Odległość między strefami dostępności w różnych regionach jest różna, podobnie jak opóźnienie dostępu do dysków ZRS między różnymi strefami dostępności. Zbenchmarkuj dyski ZRS, aby określić opóźnienie w twoim regionie.
    • ZRS dla współdzielonych dysków SSD Premium synchronicznie replikuje dane w trzech strefach dostępności w regionie. Jeśli wystąpi problem w jednym z klastrów magazynu, wystąpienie SAP ASCS/SCS będzie nadal działać, ponieważ przełączenie awaryjne magazynu jest przezroczyste dla warstwy aplikacji.
    • Aby uzyskać więcej informacji, zapoznaj się z sekcją Ograniczenia w dokumentacji dotyczącej ZRS dla dysków zarządzanych.

Ważne

Konfiguracja musi spełniać następujące warunki:

  • Identyfikator SID dla każdego systemu zarządzania bazami danych (DBMS) musi mieć własny dedykowany klaster WSFC.
  • Serwery aplikacji SAP należące do jednego identyfikatora SID SAP muszą mieć własne dedykowane maszyny wirtualne.
  • Połączenie Enqueue Replication Server 1 (ERS1) i Enqueue Replication Server 2 (ERS2) w tym samym klastrze nie jest obsługiwane.

Obsługiwane wersje systemu operacyjnego

Obsługiwane są systemy Windows Server 2016, 2019 i nowsze. Użyj najnowszych obrazów centrum danych.

Zdecydowanie zalecamy używanie co najmniej systemu Windows Server 2019 Datacenter z następujących powodów:

  • Usługa WSFC w systemie Windows Server 2019 jest świadoma platformy Azure.
  • System Windows Server 2019 Datacenter obejmuje integrację i świadomość konserwacji hosta w Azure oraz udoskonalone działanie dzięki monitorowaniu planowanych zdarzeń w Azure.
  • Można użyć nazw sieci rozproszonych. (Jest to opcja domyślna). Nie ma potrzeby posiadania dedykowanego adresu IP dla nazwy sieci klastra. Ponadto nie trzeba konfigurować adresu IP w wewnętrznym module równoważenia obciążenia platformy Azure.

Architektura

Obie wersje ERS1 i ERS2 są obsługiwane w konfiguracji z wieloma identyfikatorami SID. Połączenie ERS1 i ERS2 nie jest obsługiwane w tym samym klastrze.

W poniższym przykładzie przedstawiono dwa identyfikatory SID systemu SAP. Obie mają architekturę ERS1, w której:

  • Identyfikator SID1 systemu SAP jest wdrażany na klasterze dysków razem z systemem ERS1. Wystąpienie usługi ERS jest instalowane na hoście lokalnym i na dysku lokalnym.

    Identyfikator SID1 systemu SAP ma własny wirtualny adres IP (SID1 (A)SCS IP1), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

  • SID2 systemu SAP jest wdrażany na udostępnionym dysku razem z ERS1. Wystąpienie ERS jest zainstalowane na lokalnym hoście i lokalnym dysku.

    Identyfikator SID2 systemu SAP ma własny wirtualny adres IP (SID2 (A)SCS IP2), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

Diagram przedstawiający dwa wystąpienia SAP ASCS/SCS o wysokiej dostępności z konfiguracją ERS1.

W następnym przykładzie przedstawiono również dwa identyfikatory SID systemu SAP. Obie mają architekturę ERS2, w której:

  • SAP SID1 jest wdrażany na dysku shard z ERS2, które jest klastrowane i wdrażane na lokalnym dysku.

    Identyfikator SID1 systemu SAP ma własny wirtualny adres IP (SID1 (A)SCS IP1), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

    System SAP ERS2 ma własny wirtualny adres IP (SID1 ERS2 IP2), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

  • SAP SID2 jest wdrażany na dysku typu shard z systemem ERS2, który jest klastrowany i znajduje się na dysku lokalnym.

    Identyfikator SID2 systemu SAP ma własny wirtualny adres IP (SID2 (A)SCS IP3), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

    System SAP ERS2 ma własny wirtualny adres IP (SID2 ERS2 IP4), który jest skonfigurowany w wewnętrznym module równoważenia obciążenia platformy Azure.

  • Istnieje łącznie cztery wirtualne adresy IP:

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

Diagram dwóch wystąpień SAP ASCS/SCS o wysokiej dostępności z konfiguracją ERS1 i ERS2.

Przygotowanie infrastruktury

Oprócz istniejącego klastrowanego wystąpienia SAP PR1 ASCS/SCS należy zainstalować nowe wystąpienie SAP SID PR2.

Nazwy hostów i adresy IP

Na podstawie typu wdrożenia nazwy hostów i adresy IP scenariusza powinny być podobne do poniższych przykładów.

Poniżej przedstawiono szczegóły wdrożenia SAP w zestawie dostępności Azure.

Rola nazwy hosta Nazwa hosta Statyczny adres IP Zestaw dostępności Wartość dysku SkuName
Pierwszy węzeł klastra ASCS/SCS pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Drugi węzeł klastra ASCS/SCS pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Nazwa sieci klastrów pr1clust 10.0.0.42 (tylko w przypadku klastra systemu Windows Server 2016) Nie dotyczy
Nazwa sieci klastra ASCS SID1 pr1-ascscl 10.0.0.43 Nie dotyczy
Nazwa sieci klastra SID1 ERS (tylko dla ERS2) pr1-erscl 10.0.0.44 Nie dotyczy
Nazwa sieci klastra ASCS SID2 pr2-ascscl 10.0.0.45 Nie dotyczy
Nazwa sieci klastra SID2 ERS (tylko dla ERS2) pr1-erscl 10.0.0.46 Nie dotyczy

Poniżej przedstawiono szczegółowe informacje dotyczące wdrożenia sap w strefach dostępności platformy Azure:

Rola nazwy hosta Nazwa hosta Statyczny adres IP Strefa dostępności Wartość dysku SkuName
Pierwszy węzeł klastra ASCS/SCS pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Drugi węzeł klastra ASCS/SCS pr1-ascs-11 10.0.0.5 AZ02
Nazwa sieci klastrów pr1clust 10.0.0.42 (tylko w przypadku klastra systemu Windows Server 2016) Nie dotyczy
Nazwa sieci klastra ASCS SID1 pr1-ascscl 10.0.0.43 Nie dotyczy
Nazwa sieci klastra SID2 ERS (tylko dla ERS2) pr1-erscl 10.0.0.44 Nie dotyczy
Nazwa sieci klastra ASCS SID2 Pr2-ascscl 10.0.0.45 Nie dotyczy
Nazwa sieci klastra SID2 ERS (tylko dla ERS2) pr1-erscl 10.0.0.46 Nie dotyczy

Kroki opisane w tym artykule pozostają takie same dla obu typów wdrożeń. Ale jeśli Twój klaster działa w zestawie dostępności, musisz wdrożyć lokalnie redundantne magazynowanie (LRS) dla współdzielonych dysków SSD w warstwie Premium platformy Azure (Premium_LRS). Jeśli klaster jest uruchomiony w strefie dostępności, musisz wdrożyć magazyn ZRS dla udostępnionych dysków SSD w warstwie Azure Premium (Premium_ZRS).

Tworzenie wewnętrznego modułu równoważenia obciążenia platformy Azure

Dla wielosystemowej konfiguracji SAP SID PR2 można użyć tego samego wewnętrznego modułu równoważenia obciążenia, który został utworzony dla SAP SID systemu PR1. W przypadku architektury ENSA1 w systemie Windows potrzebny jest tylko jeden wirtualny adres IP dla oprogramowania SAP ASCS/SCS. Z drugiej strony architektura ENSA2 wymaga dwóch wirtualnych adresów IP — jeden dla systemu SAP ASCS, a drugi dla usługi ERS2.

Skonfiguruj dodatkowy zewnętrzny adres IP i regułę równoważenia obciążenia dla systemu SAP SID, PR2 w istniejącym systemie równoważenia obciążenia, korzystając z poniższych wytycznych. W tej sekcji założono, że konfiguracja standardowego wewnętrznego równoważnika obciążenia dla identyfikatora SID systemu SAP, PR1, jest już dostępna zgodnie z opisem w create load balancer.

  1. Otwórz ten sam standardowy wewnętrzny moduł równoważenia obciążenia utworzony dla systemu SAP SID, PR1.
  2. Konfiguracja adresu IP frontonu: utwórz adres IP frontonu (na przykład: 10.0.0.45).
  3. Pula zaplecza: pula zaplecza jest taka sama jak w przypadku systemu SAP SID PR1.
  4. Reguły ruchu przychodzącego: tworzenie reguły równoważenia obciążenia.
    • Adres IP frontonu: wybierz adres IP frontonu
    • Pula zaplecza: wybierz pulę zaplecza
    • Sprawdź "Porty wysokiej dostępności"
    • Protokół: TCP
    • Sonda kondycji: utwórz sondę kondycji z poniższymi szczegółami
      • Protokół: TCP
      • Port: [na przykład: 620<Numer-instancji> dla SAP SID, PR2 ASCS]
      • Interwał: 5
      • Próg sondy: 2
    • Limit czasu bezczynności (minuty): 30
    • Sprawdź pozycję "Włącz pływający adres IP"
  5. Dotyczy tylko architektury ENSA2: Utwórz dodatkowy adres IP dla interfejsu frontowego (10.0.0.44), regułę równoważenia obciążenia (użyj 621<Instance-no.> dla portu sondy kondycji ERS2), jak opisano w punkcie 1 i 3.

Uwaga

Właściwość konfiguracji sondy kondycji NumberOfProbes, inaczej znana jako "Próg złej kondycji" w portalu, nie jest uwzględniana. Aby więc kontrolować liczbę pomyślnych lub zakończonych niepowodzeniem kolejnych sond, ustaw właściwość "probeThreshold" na 2. Obecnie nie można ustawić tej właściwości za pomocą Azure Portal, więc użyj polecenia Azure CLI lub PowerShell.

Uwaga

Jeśli maszyny wirtualne bez publicznych adresów IP są umieszczane w puli zaplecza wewnętrznego (bez publicznego adresu IP) standardowego modułu równoważenia obciążenia platformy Azure, nie będzie żadnych wychodzących połączeń internetowych, chyba że wykonasz dodatkową konfigurację, aby umożliwić routing do publicznych punktów końcowych. Aby uzyskać szczegółowe informacje na temat sposobu uzyskiwania łączności wychodzącej, zobacz Publiczna łączność punktu końcowego dla maszyn wirtualnych korzystających z usługi Azure Standard Load Balancer w scenariuszach wysokiej dostępności SAP.

Tworzenie i dołączanie drugiego dysku udostępnionego platformy Azure

Uruchom to polecenie w jednym z węzłów klastra. Dostosuj wartości, aby uzyskać szczegółowe informacje, takie jak grupa zasobów, region świadczenia usługi Azure i identyfikator SID systemu 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

Formatowanie dysku udostępnionego przy użyciu programu PowerShell

  1. Pobierz numer dysku. Uruchom następujące polecenia programu PowerShell w jednym z węzłów klastra:

     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. Sformatuj dysk. W tym przykładzie jest to numer dysku 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 output
 # DriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining      Size
 # ----------- --------------- ---------- --------- ------------ ----------------- -------------      ----
 # S           PR2SAP          ReFS       Fixed     Healthy      OK                    504.98 GB 511.81 GB

  3. Sprawdź, czy dysk jest teraz widoczny jako dysk klastra:

     # 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. Zarejestruj dysk w klastrze:

     # 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

Utwórz nazwę hosta wirtualnego dla klastrowanego wystąpienia SAP ASCS/SCS

  1. Utwórz wpis DNS dla wirtualnej nazwy hosta dla nowego wystąpienia SAP ASCS/SCS w Menedżerze DNS systemu Windows.

    Adres IP przypisany do nazwy hosta wirtualnego w systemie DNS musi być taki sam jak adres IP przypisany w usłudze Azure Load Balancer.

    Zrzut ekranu przedstawiający opcje definiowania wpisu DNS dla nazwy wirtualnej i adresu IP klastra SAP ASCS/SCS.

  2. Jeśli używasz klastrowanego wystąpienia systemu SAP ERS2, musisz zarezerwować w systemie DNS nazwę wirtualnego hosta dla usługi ERS2.

    Adres IP przypisany do nazwy hosta wirtualnego dla usługi ERS2 w systemie DNS musi być taki sam jak adres IP przypisany w usłudze Azure Load Balancer.

    Zrzut ekranu przedstawiający opcje definiowania wpisu DNS dla nazwy wirtualnej i adresu IP klastra SAP ERS2.

  3. Aby zdefiniować adres IP przypisany do nazwy hosta wirtualnego, wybierz Menedżer DNS>Domena.

    Zrzut ekranu przedstawiający nową nazwę wirtualną i adres IP dla konfiguracji klastra SAP ASCS/SCS i ERS2.

Instalacja oprogramowania SAP

Instalowanie pierwszego węzła klastra SAP

Postępuj zgodnie z procedurą instalacji opisanej w oprogramowaniu SAP. Pamiętaj, aby wybrać pozycję Pierwszy węzeł klastra jako opcję rozpoczęcia instalacji. Wybierz Dysk wspólny klastra jako opcję konfiguracji. Wybierz nowo utworzony dysk udostępniony.

Modyfikacja profilu SAP instancji ASCS/SCS

Jeśli używasz programu ERS1, dodaj parametr enque/encni/set_so_keepaliveprofilu SAP . Parametr profilu zapobiega zamykaniu połączeń między procesami roboczymi SAP a serwerem blokady, gdy są bezczynne zbyt długo. Parametr SAP nie jest wymagany dla ERS2.

  1. Dodaj ten parametr profilu do profilu instancji SAP ASCS/SCS, jeśli używasz ERS1:

    enque/encni/set_so_keepalive = TRUE

    W przypadku obu systemów ERS1 i ERS2 upewnij się, że keepalive parametry systemu operacyjnego są ustawione zgodnie z opisem w notatce SAP 1410736.

  2. Aby zastosować zmiany parametru profilu SAP, należy zrestartować instancję SAP ASCS/SCS.

Konfigurowanie portu sondy w zasobie klastra

Użyj funkcji sondy wewnętrznego modułu równoważenia obciążenia, aby cała konfiguracja klastra działała z usługą Azure Load Balancer. Wewnętrzny moduł równoważenia obciążenia platformy Azure zwykle dystrybuuje obciążenie przychodzące równomiernie między uczestniczącymi maszynami wirtualnymi.

Jednak takie podejście nie będzie działać w niektórych konfiguracjach klastra, ponieważ tylko jedno wystąpienie jest aktywne. Drugie wystąpienie jest pasywne i nie może zaakceptować żadnego z obciążeń. Funkcjonalność sondy pomaga w sytuacji, gdy wewnętrzny moduł równoważenia obciążenia w Azure wykrywa, które wystąpienie jest aktywne, i celuje jedynie w aktywne wystąpienie.

Ważne

W tej przykładowej konfiguracji port sondy jest ustawiony na 620nr. W przypadku usługi SAP ASCS z numerem 02 jest to 62002.

Musisz dostosować konfigurację tak, aby odpowiadała numerom instancji SAP i identyfikatorowi SAP SID.

Aby dodać port sondy, uruchom ten moduł programu PowerShell na jednej z maszyn wirtualnych klastra:

  • Jeśli używasz usługi SAP ASC/SCS z numerem wystąpienia 02:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • Jeśli używasz ERS2 z wystąpieniem numer 12, skonfiguruj port sondy. Nie ma potrzeby konfigurowania portu sondy dla usługi ERS1. ERS2 z instancją numer 12 jest zgrupowany, podczas gdy ERS1 nie jest zgrupowany.

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

Kod funkcji Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource wygląda następująco:

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

Kontynuuj instalację oprogramowania SAP

  1. Zainstaluj wystąpienie bazy danych, postępując zgodnie z procesem opisanym w przewodniku instalacji oprogramowania SAP.

  2. Zainstaluj oprogramowanie SAP w drugim węźle klastra, wykonując kroki opisane w przewodniku instalacji oprogramowania SAP.

  3. Zainstaluj wystąpienie podstawowego serwera aplikacji SAP na maszynie wirtualnej wyznaczonej do hostowania PAS.

    Postępuj zgodnie z procesem opisanym w przewodniku instalacji oprogramowania SAP. Nie ma żadnych zależności na platformie Azure.

  4. Zainstaluj dodatkowe serwery aplikacji SAP na maszynach wirtualnych wyznaczonych do hostowania wystąpień serwera aplikacji SAP.

    Postępuj zgodnie z procesem opisanym w przewodniku instalacji oprogramowania SAP. Nie ma żadnych zależności na platformie Azure.

Testowanie trybu failover wystąpienia SAP ASCS/SCS

Opisane testy trybu failover zakładają, że usługa SAP ASCS jest aktywna w węźle A.

  1. Sprawdź, czy system SAP może pomyślnie przełączyć się z węzła A do węzła B. W tym przykładzie test dotyczy SAP SID PR2.

    Upewnij się, że każdy identyfikator SID SAP może pomyślnie przenieść się do innego węzła klastra. Wybierz jedną z tych opcji, aby zainicjować przełączenie awaryjne grupy klastra SAP <SID>z węzła klastra A do węzła klastra B:

    • Menadżer klastra przełączania awaryjnego
    • Polecenia programu PowerShell dla klastrów failover
    $SAPSID = "PR2"     # SAP <SID>

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

  2. Uruchom ponownie węzeł klastra A w systemie operacyjnym gościa systemu Windows. Ten krok inicjuje automatyczne przejście w tryb failover grupy klastra SAP <SID> z węzła A do węzła B.

  3. Uruchom ponownie węzeł klastra A z witryny Azure Portal. Ten krok inicjuje automatyczne przełączenie grupy klastra SAP <SID> z węzła A do węzła B.

  4. Uruchom ponownie węzeł klastra A przy użyciu programu Azure PowerShell. Ten krok inicjuje automatyczne przejście w tryb failover grupy klastra SAP <SID> z węzła A do węzła B.

Następne kroki