다음을 통해 공유

Windows Server 장애 조치(failover) 클러스터링 및 Azure 공유 디스크를 사용하는 SAP ASCS/SCS 인스턴스 다중 SID 고가용성

  • 아티클

Windows OS Windows

이 문서에서는 Azure 공유 디스크를 사용하는 기존 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터에 추가 SAP ASCS/SCS 클러스터형 인스턴스를 설치하여 단일 ASCS/SCS 설치에서 다중 SAP SID(시스템 ID) 구성으로 이동하는 방법을 중점적으로 설명합니다. 이 프로세스를 완료하면 SAP 다중 SID 클러스터가 구성됩니다.

필수 구성 요소 및 제한 사항

Azure 프리미엄 SSD 디스크를 SAP ASCS/SCS 인스턴스용 Azure 공유 디스크로 사용할 수 있습니다. 현재 적용 중인 제한 사항은 다음과 같습니다.

  • Azure Ultra Disk 스토리지 디스크 및 Azure 표준 SSD 디스크는 SAP 워크로드용 Azure 공유 디스크로 지원되지 않습니다.
  • 프리미엄 SSD 디스크가 있는 Azure 공유 디스크는 가용성 집합 및 가용성 영역에서 SAP 배포를 위해 지원됩니다.
  • 프리미엄 SSD 디스크가 있는 Azure 공유 디스크에는 2개의 스토리지 옵션이 제공됩니다.
    • 프리미엄 SSD 공유 디스크(Premium_LRS의 skuName 값)에 대한 LRS(로컬 중복 스토리지)는 가용성 집합의 배포와 함께 지원됩니다.
    • 프리미엄 SSD 공유 디스크(Premium_ZRS의 skuName 값)에 대한 ZRS(영역 중복 스토리지)는 가용성 영역의 배포와 함께 지원됩니다.
  • Azure 공유 디스크 값인 maxShares는 공유 디스크로 사용할 수 있는 클러스터 노드의 개수를 결정합니다. SAP ASCS/SCS 인스턴스의 경우 일반적으로 WSFC에서 두 개의 노드를 구성합니다. 그런 다음, maxShares 값을 2로 설정합니다.
  • Azure 공유 디스크에는 PPG(Azure 근접 배치 그룹)이 필요하지 않습니다. 그러나 PPG를 사용하여 SAP를 배포하는 경우 다음 지침을 따릅니다.
    • 특정 지역에 배포된 SAP 시스템용 PPG를 사용하는 경우 디스크를 공유하는 모든 가상 머신은 동일한 PPG에 속해야 합니다.
    • 영역 배포가 있는 근접 배치 그룹에 설명된 대로 여러 영역에 배포된 SAP 시스템용 PPG를 사용하는 경우 디스크를 공유하는 가상 머신에 Premium_ZRS 스토리지를 연결할 수 있습니다.

자세한 내용은 Azure 공유 디스크에 대한 설명서의 제한 사항 섹션을 참조하세요.

프리미엄 SSD 공유 디스크에 대한 중요 고려 사항

Azure 프리미엄 SSD 공유 디스크에 대한 다음의 중요 사항을 고려합니다.

  • 프리미엄 SSD 공유 디스크용 LRS:

    • 프리미엄 SSD 공유 디스크용 LRS를 사용한 SAP 배포는 하나의 스토리지 클러스터에서 단일 Azure 공유 디스크로 작동합니다. Azure 공유 디스크가 배포된 스토리지 클러스터에 문제가 있으면 SAP ASCS/SCS 인스턴스에 영향을 미칩니다.

  • 프리미엄 SSD 공유 디스크용 ZRS:

    • ZRS의 쓰기 대기 시간은 데이터의 교차 영역 복사 때문에 LRS의 쓰기 대기 시간보다 깁니다.
    • 다른 지역의 가용성 영역 간의 거리는 다양하며 가용성 영역 전체의 ZRS 디스크 대기 시간도 마찬가지입니다. 디스크를 벤치마킹하여 해당 지역의 ZRS 디스크 대기 시간을 식별합니다.
    • 프리미엄 SSD 공유 디스크용 ZRS는 해당 지역의 3개 가용성 영역에 걸쳐 데이터를 동기적으로 복제합니다. 스토리지 클러스터 중 하나에 문제가 있는 경우 스토리지 장애 조치(failover)가 애플리케이션 계층에 투명하기 때문에 SAP ASCS/SCS 인스턴스가 계속 실행됩니다.
    • 자세한 내용은 관리 디스크의 ZRS에 대한 설명서의 제한 사항 섹션을 참조하세요.

Important

설치 프로그램은 다음 조건을 충족해야 합니다.

  • 각 DBMS(데이터베이스 관리 시스템)의 SID에는 해당하는 고유한 전용 WSFC 클러스터가 있어야 합니다.
  • 하나의 SAP 시스템 SID에 속하는 SAP 애플리케이션 서버에는 고유한 전용 VM(가상 머신)이 있어야 합니다.
  • 동일한 클러스터에서 ERS1(인큐 복제 서버1)과 ERS2(인큐 복제 서버2)를 함께 사용하는 것은 지원되지 않습니다.

지원된 OS 버전

Windows Server 2016, 2019 이상이 지원됩니다. 최신 데이터 센터 이미지를 사용합니다.

다음과 같은 이유로 인해 Windows Server 2019 Datacenter를 사용하는 것이 좋습니다.

  • Windows Server 2019의 WSFC는 Azure를 인식합니다.
  • Windows Server 2019 Datacenter에는 Azure 호스트 유지 관리에 대한 통합 및 인식과 Azure 일정 이벤트 모니터링을 통한 향상된 경험이 포함되어 있습니다.
  • 분산 네트워크 이름을 사용할 수 있습니다. (기본 옵션입니다.) 클러스터 네트워크 이름을 위해 전용 IP 주소가 있을 필요가 없습니다. 또한 해당 IP 주소를 Azure 내부 부하 분산 장치에 구성할 필요도 없습니다.

아키텍처

ERS1 및 ERS2는 모두 다중 SID 구성에서 지원됩니다. ERS1와 ERS2를 동일한 클러스터에서 동시에 사용하는 것은 지원되지 않습니다.

다음 예제는 두 개의 SAP SID를 보여 줍니다. 둘 다 다음과 같은 ERS1 아키텍처가 있습니다.

  • SAP SID1은 ERS1과 함께 공유 디스크에 배포됩니다. ERS 인스턴스는 로컬 호스트와 로컬 드라이브에 설치됩니다.

    SAP SID1에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체(가상) IP 주소(SID1 (A)SCS IP1)가 있습니다.

  • SAP SID2는 ERS1과 함께 공유 디스크에 배포됩니다. ERS 인스턴스는 로컬 호스트와 로컬 드라이브에 설치됩니다.

    SAP SID2에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체(가상) IP 주소(SID2 (A)SCS IP2)가 있습니다.

ERS1 구성이 포함된 두 개의 고가용성 SAP ASCS/SCS 인스턴스 다이어그램.

다음 예제에서는 두 개의 SAP SID도 보여 줍니다. 둘 다 다음과 같은 ERS2 아키텍처가 있습니다.

  • SAP SID1은 클러스터형이며 로컬 드라이브에 배포되는 ERS2를 사용하여 분할된 데이터베이스 디스크에 배포됩니다.

    SAP SID1에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체(가상) IP 주소(SID1 (A)SCS IP1)가 있습니다.

    SAP ERS2에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체 가상 IP 주소(SID1 ERS2 IP2)가 있습니다.

  • SAP SID2는 클러스터형이며 로컬 드라이브에 배포되는 ERS2를 사용하여 분할된 데이터베이스 디스크에 배포됩니다.

    SAP SID2에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체(가상) IP 주소(SID2 (A)SCS IP3)가 있습니다.

    SAP ERS2에는 Azure 내부 부하 분산 장치에 구성되어 있는 자체 가상 IP 주소(SID2 ERS2 IP4)가 있습니다.

  • 다음과 같은 총 4개의 가상 IP 주소가 있습니다.

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

ERS1 및 ERS2 구성이 포함된 두 개의 고가용성 SAP ASCS/SCS 인스턴스 다이어그램.

인프라 준비

기존 클러스터형 SAP PR1 ASCS/SCS 인스턴스와 함께 새 SAP SID PR2 인스턴스를 설치합니다.

호스트 이름 및 IP 주소

배포 유형에 따라 시나리오의 호스트 이름과 IP 주소는 다음 예제와 같습니다.

Azure 가용성 집합의 SAP 배포에 대한 세부 정보는 다음과 같습니다.

호스트 이름 역할 호스트 이름 고정 IP 주소 가용성 집합 디스크 SkuName 값
첫 번째 클러스터 노드 ASCS/SCS 클러스터 pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
두 번째 클러스터 노드 ASCS/SCS 클러스터 pr1-ascs-11 10.0.0.5 pr1-ascs-avset
클러스터 네트워크 이름 pr1clust 10.0.0.42(Windows Server 2016 클러스터에만 해당) 해당 없음
SID1 ASCS 클러스터 네크워크 이름 pr1-ascscl 10.0.0.43 해당 없음
SID1 ERS 클러스터 네크워크 이름(ERS2에만 해당) pr1-erscl 10.0.0.44 해당 없음
SID2 ASCS 클러스터 네트워크 이름 pr2-ascscl 10.0.0.45 해당 없음
SID2 ERS 클러스터 네트워크 이름(ERS2에만 해당) pr1-erscl 10.0.0.46 해당 없음

Azure 가용성 영역의 SAP 배포에 대한 세부 정보는 다음과 같습니다.

호스트 이름 역할 호스트 이름 고정 IP 주소 가용성 영역 디스크 SkuName 값
첫 번째 클러스터 노드 ASCS/SCS 클러스터 pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
두 번째 클러스터 노드 ASCS/SCS 클러스터 pr1-ascs-11 10.0.0.5 AZ02
클러스터 네트워크 이름 pr1clust 10.0.0.42(Windows Server 2016 클러스터에만 해당) 해당 없음
SID1 ASCS 클러스터 네크워크 이름 pr1-ascscl 10.0.0.43 해당 없음
SID2 ERS 클러스터 네트워크 이름(ERS2에만 해당) pr1-erscl 10.0.0.44 해당 없음
SID2 ASCS 클러스터 네트워크 이름 pr2-ascscl 10.0.0.45 해당 없음
SID2 ERS 클러스터 네트워크 이름(ERS2에만 해당) pr1-erscl 10.0.0.46 해당 없음

이 문서의 단계는 두 배포 유형에 모두 동일하게 유지됩니다. 그러나 클러스터가 가용성 집합에서 실행 중인 경우 Azure 프리미엄 SSD 공유 디스크(Premium_LRS)용 LRS를 배포해야 합니다. 클러스터가 가용성 영역에서 실행 중인 경우 Azure 프리미엄 SSD 공유 디스크(Premium_ZRS)용 ZRS를 배포해야 합니다.

Azure 내부 부하 분산 장치 만들기

SAP SID, PR2의 다중 SID 구성의 경우 SAP SID, PR1 시스템용으로 생성한 것과 동일한 내부 부하 분산 장치를 사용할 수 있습니다. Windows의 ENSA1 아키텍처의 경우 SAP ASCS/SCS에 대한 가상 IP 주소가 하나만 필요합니다. 반면 ENSA2 아키텍처에는 두 개의 가상 IP 주소(SAP ASCS용 하나와 ERS2용 하나)가 필요합니다.

다음 지침을 사용하여 기존 부하 분산 장치에서 SAP SID, PR2 시스템에 대한 추가 프런트 엔드 IP 및 부하 분산 규칙을 구성합니다. 이 섹션에서는 SAP SID, PR1용 표준 내부 부하 분산 장치 구성이 부하 분산 장치 만들기에 설명된 대로 이미 설정되어 있다고 가정합니다.

  1. SAP SID, PR1 시스템에 대해 만든 것과 동일한 표준 내부 부하 분산 장치를 엽니다.
  2. 프런트 엔드 IP 구성: 프런트 엔드 IP(예: 10.0.0.45)를 만듭니다.
  3. 백 엔드 풀: 백 엔드 풀은 SAP SID PR1 시스템의 풀과 동일합니다.
  4. 인바운드 규칙: 부하 분산 규칙을 만듭니다.
    • 프런트 1엔드 IP 주소: 프런트 엔드 IP 선택
    • 백 엔드 풀: 백 엔드 풀 선택
    • "고가용성 포트" 확인
    • 프로토콜: TCP
    • 상태 프로브: 아래 세부 정보로 상태 프로브를 만듭니다.
      • 프로토콜: TCP
      • 포트: [예: SAP SID, PR2 ASCS의 경우 620<인스턴스-번호>]
      • 간격: 5
      • 프로브 임계값: 2
    • 유휴 제한 시간(분): 30
    • "부동 IP 사용" 확인
  5. ENSA2 아키텍처에만 적용: 1번과 3번에 설명된 대로 추가 프런트 엔드 IP(10.0.0.44), 부하 분산 규칙(ERS2 상태 프로브 포트에 621<인스턴스 번호> 사용)을 만듭니다.

참고 항목

상태 프로브 구성 속성 numberOfProbes(포털에서 “비정상 임계값”으로 알려짐)는 적용되지 않습니다. 따라서 성공하거나 실패한 연속 프로브 수를 제어하려면 "probeThreshold" 속성을 2로 설정합니다. 현재 Azure Portal을 사용하여 이 속성을 설정할 수 없으므로 Azure CLI 또는 PowerShell 명령을 사용합니다.

참고 항목

공용 IP 주소가 없는 VM이 내부(공용 IP 주소 없음) 표준 Azure Load Balancer의 백 엔드 풀에 배치되면 공용 엔드포인트에 대한 라우팅을 허용하도록 추가 구성을 수행하지 않는 한 아웃바운드 인터넷 연결이 이루어지지 않습니다. 아웃바운드 연결을 설정하는 방법에 대한 자세한 내용은 SAP 고가용성 시나리오에서 Azure 표준 Load Balancer를 사용하는 Virtual Machines에 대한 퍼블릭 엔드포인트 연결을 참조하세요.

두 번째 Azure 공유 디스크 만들기 및 연결

클러스터 노드 중 하나에서 이 명령을 실행합니다. 리소스 그룹, Azure 지역 및 SAP SID와 같은 세부 정보에 대한 값을 조정합니다.

$ResourceGroupName = "MyResourceGroup"
$location = "MyRegion"
$SAPSID = "PR2"
$DiskSizeInGB = 512
$DiskName = "$($SAPSID)ASCSSharedDisk"
$NumberOfWindowsClusterNodes = 2

# For SAP deployment in an availability set, use this storage SkuName value
$SkuName = "Premium_LRS"
# For SAP deployment in an availability zone, use this storage SkuName value
$SkuName = "Premium_ZRS"

$diskConfig = New-AzDiskConfig -Location $location -SkuName $SkuName  -CreateOption Empty  -DiskSizeGB $DiskSizeInGB -MaxSharesCount $NumberOfWindowsClusterNodes
    
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroupName -DiskName $DiskName -Disk $diskConfig
##################################
## Attach the disk to cluster VMs
##################################
# ASCS cluster VM1
$ASCSClusterVM1 = "pr1-ascs-10"
# ASCS cluster VM2
$ASCSClusterVM2 = "pr1-ascs-11"
# Next free LUN
$LUNNumber = 1

# Add the Azure shared disk to Cluster Node 1
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM1 
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

# Add the Azure shared disk to Cluster Node 2
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

PowerShell을 사용하여 공유 디스크 포맷

  1. 디스크 번호를 가져옵니다. 클러스터 노드 중 하나에서 PowerShell 명령을 실행합니다.

     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. 디스크를 포맷합니다. 이 예제에서는 디스크 번호 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. 이제 디스크가 클러스터 디스크로 표시되는지 확인합니다.

     # 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. 클러스터에 디스크를 등록합니다.

     # 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

클러스터형 SAP ASCS/SCS 인스턴스의 가상 호스트 이름 만들기

  1. Windows DNS 관리자에서 ASCS/SCS 인스턴스의 가상 호스트 이름에 대한 DNS 항목을 만듭니다.

    DNS에서 가상 호스트 이름에 할당하는 IP 주소는 Azure Load Balancer에 할당한 IP 주소와 동일해야 합니다.

    SAP ASCS/SCS 클러스터 가상 이름 및 IP 주소에 대한 DNS 항목을 정의하는 옵션을 보여 주는 스크린샷.

  2. SAP ERS2의 클러스터형 인스턴스를 사용하는 경우 ERS2에 대한 가상 호스트 이름을 DNS에 예약해야 합니다.

    DNS에서 ERS2의 가상 호스트 이름에 할당하는 IP 주소는 Azure Load Balancer에 할당한 IP 주소와 동일해야 합니다.

    SAP ERS2 클러스터 가상 이름 및 IP 주소에 대한 DNS 항목을 정의하는 옵션을 보여 주는 스크린샷.

  3. 가상 호스트 이름에 할당된 IP 주소를 정의하려면 DNS 관리자>도메인을 선택합니다.

    SAP ASCS/SCS 및 ERS2 클러스터 구성을 위한 새로운 가상 이름과 IP 주소를 보여 주는 스크린샷.

SAP 설치

SAP 첫 번째 클러스터 노드 설치

SAP에 설명된 설치 절차를 따릅니다. 설치를 시작하기 위한 옵션으로 첫 번째 클러스터 노드를 선택해야 합니다. 구성 옵션으로 클러스터 공유 디스크를 선택합니다. 새로 만든 공유 디스크를 선택합니다.

ASCS/SCS 인스턴스의 SAP 프로필 수정

ERS1을 실행하는 경우 SAP 프로필 매개 변수 enque/encni/set_so_keepalive를 추가합니다. 이 프로필 매개 변수는 연결이 너무 오랫동안 유휴 상태일 때 SAP 작업 프로세스와 큐에 넣기 서버 사이의 연결이 닫히지 않도록 합니다. ERS2에는 SAP 매개 변수가 필요하지 않습니다.

  1. ERS1을 사용하는 경우 SAP ASCS/SCS 인스턴스 프로필에 이 프로필 매개 변수를 추가합니다.

    enque/encni/set_so_keepalive = true

    ERS1 및 ERS2 모두에서 keepalive OS 매개 변수는 SAP 메모 1410736에 설명된 대로 설정해야 합니다.

  2. SAP 프로필 매개 변수에 대한 변경 내용을 적용하려면 SAP ASCS/SCS 인스턴스를 다시 시작합니다.

클러스터 리소스에서 프로브 포트 구성

내부 부하 분산 장치의 프로브 기능을 사용하여 전체 클러스터 구성이 Azure Load Balancer에서 작동하도록 합니다. 일반적으로 Azure 내부 부하 분산 장치는 참여하는 가상 머신 간에 동일하게 들어오는 작업 부하를 분산합니다.

그러나 이 접근 방식은 하나의 인스턴스만 활성 상태가 되므로 일부 클러스터 구성에서는 작동하지 않습니다. 다른 인스턴스는 수동 상태이므로 워크로드를 받아들일 수 없습니다. 프로브 기능을 사용하면 Azure 내부 부하 분산 장치가 활성 상태인 인스턴스를 감지하고 활성 인스턴스만 대상으로 할 때 도움이 됩니다.

Important

이 예제 구성에서 프로브 포트는 620nr로 설정됩니다. 인스턴스 번호가 02인 SAP ASCS의 경우 62002입니다.

SAP 인스턴스 번호 및 SAP SID와 일치하도록 구성을 조정해야 합니다.

프로브 포트를 추가하려면 클러스터 VM 중 하나에서 이 PowerShell 모듈을 실행합니다.

  • 인스턴스 번호가 02인 SAP ASC/SCS를 사용하는 경우:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • 인스턴스 번호가 12인 ERS2를 사용하는 경우 프로브 포트를 구성합니다. ERS1에 대한 프로브 포트를 구성할 필요가 없습니다. 인스턴스 번호가 12인 ERS2는 클러스터형인 반면 ERS1은 클러스터형이 아닙니다.

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

Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource 함수의 코드는 다음 예제와 같습니다.

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

SAP 설치 계속 진행

  1. SAP 설치 가이드에 설명된 프로세스를 따라 데이터베이스 인스턴스를 설치합니다.

  2. SAP 설치 가이드에 설명된 단계에 따라 두 번째 클러스터 노드에 SAP를 설치합니다.

  3. PAS(기본 애플리케이션 서버)를 호스트하도록 지정된 가상 머신에 SAP PAS 인스턴스를 설치합니다.

    SAP 설치 가이드에 설명된 프로세스를 따릅니다. Azure와는 관련이 없습니다.

  4. SAP 애플리케이션 서버 인스턴스를 호스트하도록 지정된 가상 머신에 추가 SAP 애플리케이션 서버를 설치합니다.

    SAP 설치 가이드에 설명된 프로세스를 따릅니다. Azure와는 관련이 없습니다.

SAP ASCS/SCS 인스턴스 장애 조치(failover) 테스트

앞서 설명한 장애 조치(failover) 테스트에서는 SAP ASCS가 노드 A에서 활성화되어 있다고 가정합니다.

  1. SAP 시스템이 노드 A에서 노드 B로 성공적으로 장애 조치(failover)할 수 있는지 확인합니다. 이 예제에서는 SAPSID PR2에 대한 테스트입니다.

    각 SAPSID를 다른 클러스터 노드로 이동할 수 있는지 확인합니다. 이러한 옵션 중 하나를 선택하여 클러스터 노드 A에서 클러스터 노드 B로 SAP <SID> 클러스터 그룹의 장애 조치(failover)를 시작합니다.

    • 장애 조치(failover) 클러스터 관리자
    • 장애 조치(failover) 클러스터에 대한 PowerShell 명령
    $SAPSID = "PR2"     # SAP <SID>

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

  2. Windows 게스트 운영 체제 내에서 클러스터 노드 A를 다시 시작합니다. 이 단계를 따르면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.

  3. Azure Portal에서 클러스터 노드 A를 다시 시작합니다. 이 단계를 따르면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.

  4. Azure PowerShell을 사용하여 클러스터 노드 A를 다시 시작합니다. 이 단계를 따르면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.

다음 단계