Share via

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

  • Artykuł

Windows OS 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 klastra SAP ASCS/SCS do istniejącego klastra trybu failover systemu Windows Server (WSFC) z udostępnionym dyskiem platformy Azure. Po zakończeniu tego procesu skonfigurowano klaster z wieloma identyfikatorami SID systemu SAP.

Wymagania wstępne i ograniczenia

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

  • Dyski usługi Azure Ultra Disk Storage i dyski SSD w warstwie Standardowa platformy Azure nie są obsługiwane jako dyski udostępnione platformy Azure dla obciążeń SAP.
  • Dyski udostępnione platformy Azure z dyskami SSD w warstwie Premium są obsługiwane w przypadku wdrażania oprogramowania SAP w zestawach dostępności i strefach dostępności.
  • Dyski udostępnione platformy Azure z dyskami SSD w warstwie Premium mają dwie opcje magazynowania:
    • Magazyn lokalnie nadmiarowy (LRS) dla dysków udostępnionych SSD w warstwie Premium (skuName wartość Premium_LRS) jest obsługiwany we wdrożeniu w zestawach dostępności.
    • Magazyn strefowo nadmiarowy (ZRS) dla dysków udostępnionych SSD w warstwie Premium (skuName wartość ) jest obsługiwany we wdrożeniu Premium_ZRSw strefach dostępności.
  • 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 usłudze WSFC. Następnie należy ustawić wartość parametru maxShares na 2.
  • Grupa umieszczania w pobliżu platformy Azure (PPG) nie jest wymagana dla dysków udostępnionych platformy Azure. Jednak w przypadku wdrożenia sap z grupami ppg postępuj zgodnie z następującymi wytycznymi:
    • Jeśli używasz grup ppg dla systemu SAP wdrożonego w regionie, wszystkie maszyny wirtualne współużytkujące dysk muszą być częścią tej samej grupy PPG.
    • Jeśli używasz grup 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ące 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 dysków udostępnionych 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:

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

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

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

    • Opóźnienie zapisu dla magazynu ZRS jest wyższe niż w przypadku magazynu LRS, ponieważ kopiowanie danych między strefami.
    • Odległość między strefami dostępności w różnych regionach jest różna, a więc opóźnienie dysku magazynu ZRS w różnych strefach dostępności. Przeprowadź test porównawczy dysków, aby zidentyfikować opóźnienie dysków magazynu ZRS w twoim regionie.
    • Magazyn ZRS dla dysków udostępnionych SSD w warstwie 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ż tryb failover magazynu jest niewidoczny dla warstwy aplikacji.
    • Aby uzyskać więcej informacji, zapoznaj się z sekcją Ograniczenia dokumentacji dotyczącej magazynu 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 serwera replikacji enqueue 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 platformy Azure oraz ulepszone środowisko dzięki monitorowaniu zaplanowanych zdarzeń platformy 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 udostępnionym dysku 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.

  • Identyfikator SID2 systemu SAP jest wdrażany na dysku udostępnionym z systemem ERS1. Wystąpienie usługi ERS jest instalowane na hoście lokalnym i na dysku lokalnym.

    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 of two high-availability SAP ASCS/SCS instances with an ERS1 configuration.

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

  • Identyfikator SID1 systemu SAP jest wdrażany na dysku fragmentu z systemem ERS2, który jest klastrowany i wdrażany 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.

    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.

  • Identyfikator SID2 sap jest wdrażany na dysku fragmentu z systemem ERS2, który jest klastrowany i wdrażany 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 of two high-availability SAP ASCS/SCS instances with an ERS1 and ERS2 configuration.

Przygotowanie infrastruktury

Oprócz istniejącego klastrowanego wystąpienia usługi SAP PRCS/SCS należy zainstalować nowe wystąpienie IDENTYFIKATORa SID SAP 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 platformy 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 Availability zone 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ń. Jeśli jednak klaster jest uruchomiony w zestawie dostępności, musisz wdrożyć magazyn LRS dla dysków udostępnionych 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

W przypadku konfiguracji z wieloma identyfikatorami SID sap SID, PR2 można użyć tego samego wewnętrznego modułu równoważenia obciążenia utworzonego dla identyfikatora SID SAP, 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 dodatkową regułę adresu IP frontonu i równoważenia obciążenia dla systemu SAP SID, PR2 w istniejącym module równoważenia obciążenia, korzystając z poniższych wskazówek. W tej sekcji założono, że konfiguracja standardowego wewnętrznego modułu równoważenia obciążenia dla identyfikatora SID systemu SAP, żądanie ściągnięcia 1 jest już dostępne zgodnie z opisem w temacie Create Load Balancer (Tworzenie modułu równoważenia obciążenia).

  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<Instance-no.> for 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 frontonu (10.0.0.44), regułę równoważenia obciążenia (użyj polecenia 621<Instance-no.> dla portu sondy kondycji ERS2), zgodnie z opisem 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 przy użyciu witryny Azure Portal, dlatego użyj polecenia interfejsu wiersza polecenia platformy Azure lub programu PowerShell .

Ważne

Pływający adres IP nie jest obsługiwany w pomocniczej konfiguracji adresu IP karty sieciowej w scenariuszach równoważenia obciążenia. Aby uzyskać szczegółowe informacje, zobacz Ograniczenia usługi Azure Load Balancer. Jeśli potrzebujesz innego adresu IP maszyny wirtualnej, wdróż drugą kartę sieciową.

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 usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania 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 outout
 # 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

Tworzenie nazwy hosta wirtualnego dla klastrowanego wystąpienia sap ASCS/SCS

  1. Utwórz wpis DNS dla nazwy hosta wirtualnego 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.

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

  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.

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

  3. Aby zdefiniować adres IP przypisany do nazwy hosta wirtualnego, wybierz pozycję Domena menedżera>DNS.

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

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 opcję Dysk udostępniony klastra jako opcję konfiguracji. Wybierz nowo utworzony dysk udostępniony.

Modyfikowanie profilu SAP wystąpienia usługi ASCS/SCS

Jeśli używasz programu ERS1, dodaj parametr enque/encni/set_so_keepaliveprofilu SAP . Parametr profilu uniemożliwia nawiązywanie połączeń między procesami roboczymi SAP i serwerem kolejki przed zamknięciem, gdy są bezczynne zbyt długo. Parametr SAP nie jest wymagany dla ERS2.

  1. Dodaj ten parametr profilu do profilu wystąpienia sap ASCS/SCS, jeśli używasz usługi 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 do parametru profilu SAP, uruchom ponownie wystąpienie 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ń. Funkcja sondy pomaga, gdy wewnętrzny moduł równoważenia obciążenia platformy Azure wykrywa, które wystąpienie jest aktywne i dotyczy tylko aktywnego wystąpienia.

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 wystąpień sap i identyfikatorowi SID systemu SAP.

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 numerem 12 wystąpienia, skonfiguruj port sondy. Nie ma potrzeby konfigurowania portu sondy dla usługi ERS1. Klaster ERS2 o numerze 12 wystąpień, natomiast ERS1 nie jest klastrowany.

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

    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 przejść w tryb failover z węzła A do węzła B. W tym przykładzie test dotyczy identyfikatora SAP SID PR2.

    Upewnij się, że każdy identyfikator SID SAP może pomyślnie przejść do innego węzła klastra. Wybierz jedną z tych opcji, aby zainicjować tryb failover grupy klastra IDENTYFIKATORÓW SID> SAP <z węzła klastra A do węzła klastra B:

    • Menedżer klastra trybu failover
    • Polecenia programu PowerShell dla klastrów trybu 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 IDENTYFIKATORÓW SID> SAP <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 przejście w tryb failover grupy klastra IDENTYFIKATORÓW SID> SAP <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 IDENTYFIKATORÓW SID> SAP <z węzła A do węzła B.

Następne kroki