Azure에서 Windows 장애 조치(Failover) 클러스터 및 공유 디스크에 SAP ASCS/SCS 인스턴스용 SAP NetWeaver HA 설치
이 문서에서는 Azure에서 Windows Server 장애 조치(Failover)클러스터와 클러스터 공유 디스크를 사용하여 SAP ASCS/SCS 인스턴스 클러스터링을 위한 고가용성 SAP 시스템을 설치하고 구성하는 방법을 설명합니다. 아키텍처 가이드: 클러스터 공유 디스크를 사용하여 Windows 장애 조치(failover) 클러스터에서 SAP ASCS/SCS 인스턴스 클러스터링에 설명된 대로 클러스터 공유 디스크에는 두 가지 대안이 있습니다.
- Azure 공유 디스크
- SIOS DataKeeper 클러스터 버전을 사용하여 미러링된 스토리지를 만들면 클러스터된 공유 디스크를 시뮬레이션합니다.
필수 조건
설치를 시작하기 전에 먼저 다음 문서를 검토하세요.
아키텍처 가이드: Windows 장애 조치(Failover) 클러스터에서 클러스터 공유 디스크를 사용하여 SAP ASCS/SCS 인스턴스 클러스터링
Windows 장애 조치(Failover) 클러스터 및 공유 디스크를 사용하여 SAP ASCS/SCS 인스턴스를 위한 SAP HA용 Azure 인프라 준비
DBMS 설정 방법은 사용 중인 DBMS 시스템에 따라 다르기 때문에 이 문서에서는 설명하지 않습니다. DBMS의 고가용성 문제는 다양한 DBMS 공급업체가 Azure에 대해 지원하는 기능으로 해결되었다고 가정합니다. 그 예로 SQL Server용 데이터베이스 미러링 또는 Always On, Oracle 데이터베이스용 Oracle Data Guard를 들 수 있습니다. DBMS의 고가용성 시나리오는 이 문서에서 다루지 않습니다.
Azure에서 다양한 DBMS 서비스가 클러스터형 SAP ASCS/SCS 구성과 상호 작용하는 경우 특별히 고려해야 하는 사항은 없습니다.
참고 항목
SAP NetWeaver ABAP 시스템, Java 시스템 및 ABAP+Java 시스템의 설치 절차는 거의 동일합니다. 가장 중요한 차이점은 SAP ABAP 시스템에 ASCS 인스턴스가 하나 있다는 것입니다. SAP Java 시스템에는 하나의 SCS 인스턴스가 있습니다. SAP ABAP+Java 시스템에서는 동일한 Microsoft 장애 조치 클러스터 그룹에 하나의 ASCS 인스턴스와 하나의 SCS 인스턴스가 실행되고 있습니다. 각 SAP NetWeaver 설치 스택에 대한 설치 차이점은 명시적으로 언급됩니다. 나머지 단계는 동일하다고 가정할 수 있습니다.
고가용성 ASCS/SCS 인스턴스를 갖는 SAP 설치
Important
SIOS를 사용하여 공유 디스크를 제공하는 경우 페이지 파일을 SIOS DataKeeper 미러된 볼륨에 배치하지 마세요. Azure Virtual Machines의 임시 드라이브 D에 페이지 파일을 둘 수 있습니다. 이것이 기본 설정입니다. Windows 페이지 파일을 Azure Virtual Machines의 D 드라이브로 이동하지 않은 경우 이동합니다.
고가용성 ASCS/SCS 인스턴스에 SAP 설치는 다음과 같은 작업을 포함합니다.
- 클러스터형 SAP ASCS/SCS 인스턴스의 가상 호스트 이름 만들기.
- 첫 번째 클러스터 노드에 SAP를 설치합니다.
- ASCS/SCS 인스턴스의 SAP 프로필을 수정합니다.
- 프로브 포트 추가하기.
- Windows 방화벽 프로브 포트 열기.
클러스터형 SAP ASCS/SCS 인스턴스의 가상 호스트 이름 만들기
Windows DNS 관리자에서 ASCS/SCS 인스턴스의 가상 호스트 이름에 대한 DNS 항목을 만듭니다.
Important
ASCS/SCS 인스턴스의 가상 호스트 이름에 할당하는 IP 주소는 Azure Load Balancer에 할당한 IP 주소와 동일해야 합니다.
SAP ASCS/SCS 클러스터 가상 이름 및 TCP/IP 주소에 대한 DNS 항목 정의
클러스터된 인스턴스인 새 SAP 큐에 넣기 복제 서버 2를 사용하는 경우 ERS2에 대한 가상 호스트 이름도 DNS에서 예약해야 합니다.
Important
ERS2 인스턴스의 가상 호스트 이름에 할당하는 IP 주소는 Azure Load Balancer에 할당한 두 번째 IP 주소여야 합니다.
SAP ERS2 클러스터 가상 이름 및 TCP/IP 주소에 대한 DNS 항목 정의
가상 호스트 이름에 할당된 IP 주소를 정의하려면 DNS 관리자>도메인을 선택합니다.
SAP ASCS/SCS 클러스터 구성을 위한 새 가상 이름 및 TCP/IP 주소
SAP 첫 번째 클러스터 노드 설치
클러스터 노드 A에서 첫 번째 클러스터 노드 옵션을 실행합니다. 다음을 선택합니다.
- ABAP 시스템: ASCS 인스턴스 번호 00
- Java 시스템: SCS 인스턴스 번호 01
- ABAP+Java 시스템: ASCS 인스턴스 번호 00 및 SCS 인스턴스 번호 01
Important
Azure 내부 부하 분산 장치 부하 분산 규칙의 구성(기본 SKU를 사용하는 경우)과 선택한 SAP 인스턴스 번호가 일치해야 합니다.
SAP에 설명된 설치 절차를 따릅니다. 설치 시작 옵션인 “첫 번째 클러스터 노드”에서 “클러스터 공유 디스크”를 구성 옵션으로 선택해야 합니다.
팁
SAP 설치 설명서에는 첫 번째 ASCS/SCS 클러스터 노드를 설치하는 방법을 설명합니다.
ASCS/SCS 인스턴스의 SAP 프로필 수정
큐에 넣기 복제 서버 1이 있는 경우 아래 설명된 대로 SAP 프로필 매개 변수 enque/encni/set_so_keepalive를 추가합니다. 이 프로필 매개 변수는 연결이 너무 오랫동안 유휴 상태일 때 SAP 작업 프로세스와 큐에 넣기 서버 사이의 연결이 닫히지 않도록 합니다. ERS2에는 SAP 매개 변수가 필요하지 않습니다.
ERS1을 사용하는 경우 SAP ASCS/SCS 인스턴스 프로필에 이 프로필 매개 변수를 추가합니다.
enque/encni/set_so_keepalive = trueERS1 및 ERS2 모두에서
keepaliveOS 매개 변수는 SAP 메모 1410736에 설명된 대로 설정해야 합니다.SAP 프로필 매개 변수 변경 내용을 적용하려면 SAP ASCS/SCS 인스턴스를 다시 시작합니다.
프로브 포트 추가
내부 부하 분산 장치의 프로브 기능을 사용하여 전체 클러스터 구성이 Azure Load Balancer에서 작동하도록 합니다. 일반적으로 Azure 내부 부하 분산 장치는 참여하는 가상 머신 간에 동일하게 들어오는 작업 부하를 분산합니다.
그러나 하나의 인스턴스만 활성 상태가 되므로 일부 클러스터 구성에서는 작동하지 않습니다. 다른 인스턴스는 수동 상태이므로 워크로드를 받아들일 수 없습니다. 프로브 기능을 사용하면 Azure 내부 부하 분산 장치가 활성 상태인 인스턴스를 감지하고 활성 인스턴스만 대상으로 할 때 도움이 됩니다.
Important
이 예제 구성에서 ProbePort는 620Nr로 설정됩니다. 번호가 00인 SAP ASCS 인스턴스의 경우 62000입니다. SAP 인스턴스 번호 및 SAP SID와 일치하도록 구성을 조정해야 합니다.
프로브 포트를 추가하려면 클러스터 VM 중 하나에서 이 PowerShell 모듈을 실행합니다.
SAP ASC/SCS 인스턴스의 경우
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62000클러스터된 ERS2를 사용하는 경우. ERS1에 대한 프로브 포트는 클러스터되지 않으므로 구성할 필요가 없습니다.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62001 -IsSAPERSClusteredInstance $True
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource 함수의 코드는 다음과 같습니다.
function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource {
<#
.SYNOPSIS
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.
.DESCRIPTION
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.
It will also restart SAP Cluster group (default behavior), to activate the changes.
You need to run it on one of the SAP ASCS/SCS Windows cluster nodes.
Expectation is that SAP group is installed with official SWPM installation tool, which will set default expected naming convention for:
- SAP Cluster Group: 'SAP $SAPSID'
- SAP Cluster IP Address Resource: 'SAP $SAPSID IP'
.PARAMETER SAPSID
SAP SID - 3 characters staring with letter.
.PARAMETER ProbePort
Azure Load Balancer Health Check Probe Port.
.PARAMETER RestartSAPClusterGroup
Optional parameter. Default value is '$True', so SAP cluster group will be restarted to activate the changes.
.PARAMETER IsSAPERSClusteredInstance
Optional parameter.Default value is '$False'.
If set to $True , then handle clsutered new SAP ERS2 instance.
.EXAMPLE
# Set 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 probe port to 62000, on SAP cluster resource 'SAP AB1 IP'. SAP cluster group 'SAP AB1' IS NOT restarted, therefore changes are NOT active.
# To activate the changes you need to manualy restart 'SAP AB1' cluster group.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -RestartSAPClusterGroup $False
.EXAMPLE
# Set 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-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 " "
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 {}
}
Windows 방화벽 프로브 포트 열기
두 클러스터 노드에서 Windows 방화벽 프로브 포트를 엽니다. 다음 스크립트를 사용하여 Windows 방화벽 프로브 포트를 엽니다. 사용자 환경에 맞게 PowerShell 변수를 업데이트합니다.
ERS2를 사용하는 경우 ERS2 프로브 포트에 대한 방화벽 포트도 열어야 합니다.
$ProbePort = 62000 # ProbePort of the Azure internal load balancer
New-NetFirewallRule -Name AzureProbePort -DisplayName "Rule for Azure Probe Port" -Direction Inbound -Action Allow -Protocol TCP -LocalPort $ProbePort
데이터베이스 인스턴스 설치
데이터베이스 인스턴스를 설치하려면 SAP 설치 설명서에 설명된 프로세스를 따릅니다.
두 번째 클러스터 노드 설치
두 번째 클러스터 노드를 설치하려면 SAP 설치 가이드에 설명된 단계를 따릅니다.
SAP 기본 애플리케이션 서버 설치
PAS(기본 애플리케이션 서버)를 호스트하도록 지정한 가상 머신에 PAS 인스턴스 <SID>-di-0을 설치합니다. Azure와는 관련이 없습니다. SIOS를 사용하는 경우 DataKeeper 관련 설정이 없습니다.
SAP 추가 애플리케이션 서버 설치
SAP 애플리케이션 서버 인스턴스를 호스트하도록 지정한 모든 가상 머신에 SAP AAS(추가 애플리케이션 서버)를 설치합니다.
SAP ASCS/SCS 인스턴스 장애 조치(failover) 테스트
앞서 설명한 장애 조치(failover) 테스트에서는 SAP ASCS가 노드 A에서 활성화되어 있다고 가정합니다.
SAP 시스템이 노드 A에서 노드 B로 성공적으로 장애 조치(failover)할 수 있는지 확인합니다. 다음 옵션 중 하나를 선택하여 클러스터 노드 A에서 클러스터 노드 B로 SAP <SID> 클러스터 그룹의 장애 조치(failover)를 시작합니다.
- 장애 조치(failover) 클러스터 관리자
- 장애 조치 클러스터 PowerShell
$SAPSID = "PR1" # SAP <SID> $SAPClusterGroup = "SAP $SAPSID" Move-ClusterGroup -Name $SAPClusterGroupWindows 게스트 운영 체제 내에서 클러스터 노드 A를 다시 시작합니다. 이렇게 하면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.
Azure Portal에서 클러스터 노드 A를 다시 시작합니다. 이렇게 하면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.
Azure PowerShell을 사용하여 클러스터 노드 A를 다시 시작합니다. 이렇게 하면 노드 A에서 노드 B로의 SAP <SID> 클러스터 그룹의 자동 장애 조치(Failover)가 시작됩니다.
확인
장애 조치(failover) 후 SAP <SID> 클러스터 그룹이 클러스터 노드 B에서 실행 중인지 확인합니다.
장애 조치(failover) 클러스터 관리자에서 클러스터 노드 B에서 실행 중인 SAP <SID> 클러스터 그룹
장애 조치(failover) 후 공유 디스크가 이제 클러스터 노드 B에 탑재되었는지 확인합니다.
장애 조치(failover) 후 SIOS를 사용하는 경우 SIOS DataKeeper가 클러스터 노드 B의 원본 볼륨 드라이브 S에서 클러스터 노드 A의 대상 볼륨 드라이브 S로 데이터를 복제하는지 확인합니다.
SIOS DataKeeper에서 클러스터 노드 B로부터 클러스터 노드 A에 로컬 볼륨 복제