你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用 Windows Server 故障转移群集和 Azure 共享磁盘实现 SAP ASCS/SCS 实例多 SID 高可用性
Windows
本文重点介绍如何通过将其他 SAP ASCS/SCS 群集实例安装到具有 Azure 共享磁盘的现有 Windows Server 故障转移群集 (WSFC) 群集中,从单个 SAP ASCS/SC 安装转移到多个 SAP 系统 ID (SID) 的配置。 完成此过程后,即已配置 SAP 多 SID 群集。
先决条件和限制
可以使用 Azure 高级 SSD 磁盘作为 SAP ASCS/SCS 实例的 Azure 共享磁盘。 目前存在以下限制:
- Azure 超级 SSD 磁盘和 Azure 标准 SSD 磁盘不支持作为 SAP 工作负载的 Azure 共享磁盘。
- 可用性集和可用性区域中的 SAP 部署支持具有高级 SSD 磁盘的 Azure 共享磁盘。
- 采用高级 SSD 磁盘的 Azure 共享磁盘附带两个存储选项:
- 可用性集中的部署支持高级 SSD 共享磁盘的本地冗余存储 (LRS)(
Premium_LRS
的skuName
值)。 - 可用性区域中的部署支持高级 SSD 共享磁盘的区域冗余存储 (ZRS)(
Premium_ZRS
的skuName
值)。
- 可用性集中的部署支持高级 SSD 共享磁盘的本地冗余存储 (LRS)(
- Azure 共享磁盘值 maxShares 确定可以使用共享磁盘的群集节点数。 对于 SAP ASCS/SCS 实例,通常会在 WSFC 中配置两个节点。 然后将
maxShares
的值设置为2
。 - Azure 共享磁盘不需要 Azure 邻近放置组 (PPG)。 但对于带有 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:
重要
该设置必须满足以下条件:
- 每个数据库管理系统 (DBMS) 的 SID 必须有自己的专用 WSFC 群集。
- 属于一个 SAP SID 的 SAP 应用程序服务器必须有自己的专用虚拟机 (VM)。
- 不支持在同一个群集中混合使用排队复制服务器 1 (ERS1) 和排队复制服务器 2 (ERS2)。
支持的操作系统版本
支持 Windows Server 2016、2019 和更高版本。 使用最新的数据中心映像。
强烈建议至少使用 Windows Server 2019 Datacenter,原因如下:
- Windows Server 2019 中的 WSFC 可识别 Azure。
- Windows Server 2019 Datacenter 包括通过监视 Azure 计划事件来集成和了解 Azure 主机维护和改进体验。
- 可以使用分布式网络名称。 (这是默认选项。)无需为群集网络名称提供专用 IP 地址。 此外,无需在 Azure 内部负载均衡器上配置 IP 地址。
体系结构
多 SID 配置支持 ERS1 和 ERS2。 同一群集不支持混合使用 ERS1 和 ERS2。
以下示例显示了两个 SAP SID。 两者都有一个 ERS1 体系结构,其中:
SAP SID1 部署在具有 ERS1 的共享磁盘上。 ERS 实例安装在本地主机和本地驱动器上。
SAP SID1 具有自己的虚拟 IP 地址 (SID1 (A)SCS IP1),该地址是在 Azure 内部负载均衡器上配置的。
SAP SID2 部署在具有 ERS1 的共享磁盘上。 ERS 实例安装在本地主机和本地驱动器上。
SAP SID2 具有自己的虚拟 IP 地址 (SID2 (A)SCS IP2),该地址是在 Azure 内部负载均衡器上配置的。
下一个示例还演示了两个 SAP SID。 两者都有一个 ERS2 体系结构,其中:
SAP SID1 部署在具有 ERS2 的分片磁盘上,该磁盘已群集化,并部署在本地驱动器上。
SAP SID1 具有自己的虚拟 IP 地址 (SID1 (A)SCS IP1),该地址是在 Azure 内部负载均衡器上配置的。
SAP ERS2 具有自己的虚拟 IP 地址 (SID1 ERS2 IP2),该地址是在 Azure 内部负载均衡器上配置的。
SAP SID2 部署在具有 ERS2 的分片磁盘上,该磁盘已群集化,并部署在本地驱动器上。
SAP SID2 具有自己的虚拟 IP 地址 (SID2 (A)SCS IP3),这是在 Azure 内部负载均衡器上配置的。
SAP ERS2 具有自己的虚拟 IP 地址 (SID2 ERS2 IP4),这是在 Azure 内部负载均衡器上配置的。
共有四个虚拟 IP 地址:
- SID1 (A)SCS IP1
- SID2 ERS2 IP2
- SID2 (A)SCS IP3
- SID2 ERS2 IP4
基础结构准备
除了现有的群集 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 的标准内部负载平衡器的配置已经到位,如创建负载均衡器中所述。
- 打开为 SAP SID PR1 系统创建的相同标准内部负载均衡器。
- 前端 IP 配置:创建前端 IP(例如:10.0.0.45)。
- 后端池:后端池与 SAP SID PR1 系统相同。
- 入站规则:创建负载均衡规则。
- 前端 IP 地址:选择前端 IP
- 后端池:选择后端池
- 检查“高可用性端口”
- 协议:TCP
- 运行状况探测:创建具有以下详细信息的运行状况探测
- 协议:TCP
- 端口:[例如:对 SAP SID、PR2 ASCS 使用 620<Instance-no.>]
- 间隔: 5
- 探测阈值: 2
- 空闲超时 (分钟):30
- 选中“启用浮动 IP”
- 仅适用于 ENSA2 体系结构:创建其他前端 IP (10.0.0.44)、负载均衡规则(对 ERS2 运行状况探测端口使用 621<Instance-no.>),如第 1 点和第 3 点中所述。
注意
不会遵循运行状况探测配置属性 numberOfProbes(在门户中也称为“运行不正常阈值”)。 因此,要控制成功或失败的连续探测数量,请将属性“probeThreshold”设置为 2。 当前无法使用 Azure 门户设置此属性,请使用 Azure CLI 或 PowerShell 命令。
注意
如果没有公共 IP 地址的 VM 放在内部(无公共 IP 地址)标准 Azure 负载均衡器的后端池中,就不会有出站 Internet 连接,除非执行额外的配置来允许路由到公共终结点。 有关如何实现出站连接的详细信息,请参阅 SAP 高可用性方案中使用 Azure 标准负载均衡器的虚拟机的公共终结点连接。
创建并附加第二个 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 格式化共享磁盘
获取磁盘编号。 在其中一个群集节点上运行以下 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
格式化磁盘。 在此示例中,磁盘号为 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
验证磁盘现在是否作为群集磁盘显示:
# 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\}
在群集中注册磁盘:
# 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 实例创建虚拟主机名
在 Windows DNS 管理器中,为新 SAP ASCS/SCS 实例的虚拟主机名创建 DNS 条目。
分配给 DNS 中虚拟主机名的 IP 地址必须与分配给 Azure 负载均衡器的 IP 地址相同。
如果使用 SAP ERS2 的群集实例,则需要在 DNS 中保留 ERS2 的虚拟主机名。
分配给 DNS 中 ERS2 虚拟主机名的 IP 地址必须与分配给 Azure 负载均衡器的 IP 地址相同。
若要定义分配给虚拟主机名的 IP 地址,请选择“DNS 管理器”>“域”。
SAP 安装
安装 SAP 的第一个群集节点
按照 SAP 描述的安装过程进行操作。 请务必选择“第一个群集节点”作为开始安装的选项。 选择“群集共享磁盘”作为配置选项。 选择新创建的共享磁盘。
修改 ASCS/SCS 实例的 SAP 配置文件
如果运行的是 ERS1,请添加 SAP 配置文件参数 enque/encni/set_so_keepalive
。 配置文件参数可避免 SAP 工作进程与排队服务器之间的连接在空闲时间太长时关闭。 ERS2 不需要 SAP 参数。
如果使用的是 ERS1,请将此配置文件参数添加到 SAP ASCS/SCS 实例配置文件:
enque/encni/set_so_keepalive = true
对于 ERS1 和 ERS2,请确保按 SAP 说明 1410736 中所述设置
keepalive
OS 参数。若要将更改应用到 SAP 配置文件参数,请重启 SAP ASCS/SCS 实例。
在群集资源上配置探测端口
使用内部负载均衡器探测功能,让整个群集配置使用 Azure Load Balancer。 Azure 内部负载均衡器通常在参与的虚拟机之间平均分配传入的工作负荷。
但是,此方法在某些群集配置中不起作用,因为只有一个实例处于活动状态。 其他实例处于被动状态,并且无法接受任何工作负荷。 当 Azure 内部负载均衡器检测到哪个实例处于活动状态并且仅面向活动实例时,探测功能会有所帮助。
重要
在此示例配置中,探测端口设置为 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
按照 SAP 安装指南中所述的过程安装数据库实例。
按照 SAP 安装指南中描述的下列步骤,在第二个群集节点上安装 SAP。
在指定用于托管 PAS 的虚拟机上安装 SAP 主应用程序服务器 (PAS) 实例。
按照 SAP 安装指南中所述的流程操作。 Azure 上没有依赖项。
在指定用于托管 SAP 应用程序服务器实例的虚拟机上安装其他 SAP 应用程序服务器。
按照 SAP 安装指南中所述的流程操作。 Azure 上没有依赖项。
测试 SAP ASCS/SCS 实例故障转移
概述的故障转移测试假定 SAP ASCS 在节点 A 上处于活动状态。
验证 SAP 系统是否可以成功从节点 A 故障转移到节点 B。在本例中,测试针对 SAP SID PR2。
确保每个 SAP SID 都可以成功移动到其他群集节点。 选择以下选项之一,开始将 SAP<SID> 群集组从群集节点 A 故障转转到群集节点 B 的故障转移:
- 故障转移群集管理器
- 故障转移群集的 PowerShell 命令
$SAPSID = "PR2" # SAP <SID> $SAPClusterGroup = "SAP $SAPSID" Move-ClusterGroup -Name $SAPClusterGroup
重启 Windows 来宾操作系统中的群集节点 A。 此步骤会启动将 SAP <SID> 群集组从节点 A 故障转移到节点 B 的自动故障转移。
重启 Azure 门户中的群集节点 A。 此步骤会启动将 SAP <SID> 群集组从节点 A 故障转移到节点 B 的自动故障转移。
使用 Azure PowerShell 重启群集节点 A。 此步骤会启动将 SAP <SID> 群集组从节点 A 故障转移到节点 B 的自动故障转移。