Высокий уровень доступности экземпляра SAP ASCS/SCS с поддержкой отказоустойчивой кластеризации Windows Server и общего диска Azure
Windows
В этой статье описывается, как перейти от одной установки SAP ASCS/SCS к настройке нескольких идентификаторов систем SAP (SID) путем установки дополнительных кластеризованных экземпляров SAP ASCS/SCS в существующий кластер отказоустойчивой кластеризации Windows Server (WSFC) с общим диском Azure. После завершения этого процесса вы настроили кластер SAP с несколькими идентификаторами БЕЗОПАСНОСТИ.
Предварительные требования и ограничения
Диски SSD Azure уровня "Премиум" можно использовать в качестве общих дисков Azure для экземпляра SAP ASCS/SCS. В настоящее время действуют следующие ограничения.
- Диски хранилища дисков Azure ценовой категории "Ультра" и диски SSD Azure уровня "Стандартный" не поддерживаются в качестве общих дисков Azure для рабочих нагрузок SAP.
- Общие диски Azure с дисками SSD уровня "Премиум" поддерживаются для развертывания SAP в группах доступности и зонах доступности.
- Общие диски Azure с дисками SSD уровня "Премиум" доступны в двух вариантах хранения:
- Локально избыточное хранилище (LRS) для общих дисков SSD класса Premium (
skuName
значениеPremium_LRS
) поддерживается при развертывании в группах доступности. - Хранилище, избыточное между зонами (ZRS) для общих дисков SSD уровня "Премиум" (
skuName
значениеPremium_ZRS
) поддерживается при развертывании в зонах доступности.
- Локально избыточное хранилище (LRS) для общих дисков SSD класса Premium (
- Значение общего диска Azure maxShares определяет, сколько узлов кластера может использовать общий диск. Для экземпляра SAP ASCS/SCS обычно настраивается два узла в WSFC. Затем задайте для параметра значение
maxShares
2
. - Группа размещения близкого взаимодействия Azure (PPG) не требуется для общих дисков Azure. Но для развертывания SAP с помощью PPG следуйте приведенным ниже рекомендациям.
- Если вы используете PPG для системы SAP, развернутой в регионе, все виртуальные машины, которые совместно используют диск, должны быть частью одного и того же PPG.
- Если вы используете PPG для системы SAP, развернутой в зонах, как описано в группах размещения близкого взаимодействия с зональными развертываниями, вы можете подключить
Premium_ZRS
хранилище к виртуальным машинам, которые совместно используют диск.
Дополнительные сведения см. в разделе "Ограничения " документации по общим дискам Azure.
Важные рекомендации по общим дискам SSD уровня "Премиум"
Рассмотрим следующие важные моменты о общих дисках SSD azure Premium:
LRS для общих дисков SSD уровня "Премиум":
- Развертывание SAP с LRS для общих дисков SSD уровня "Премиум" работает с одним общим диском Azure в одном кластере хранилища. Если возникла проблема с кластером хранения, на котором развернут общий диск Azure, это влияет на экземпляр SAP ASCS/SCS.
ZRS для общих дисков SSD уровня "Премиум":
- Задержка записи для ZRS выше, чем в LRS, так как межзональное копирование данных.
- Расстояние между зонами доступности в разных регионах зависит и поэтому задержка дисков ZRS между зонами доступности. Проверьте свои диски, чтобы определить задержку дисков ZRS в вашем регионе.
- ZRS для общих дисков SSD уровня "Премиум" синхронно реплицирует данные в трех зонах доступности в регионе. Если в одном из кластеров хранилища возникла проблема, экземпляр SAP ASCS/SCS продолжает выполняться, так как отработка отказа хранилища является прозрачной для уровня приложения.
- Дополнительные сведения см. в разделе "Ограничения " документации по ZRS для управляемых дисков.
Внимание
Установка должна соответствовать двум таким условиям:
- Идентификатор безопасности для каждой системы управления базами данных (СУБД) должен иметь собственный выделенный кластер WSFC.
- Серверы приложений SAP, принадлежащие одному идентификатору безопасности SAP, должны иметь собственные выделенные виртуальные машины .
- Сочетание сервера репликации Enqueue 1 (ERS1) и сервера репликации Enqueue 2 (ERS2) в одном кластере не поддерживается.
Поддерживаемые версии ОС
Windows Server 2016, 2019 и более поздних версий поддерживаются. Используйте последние образы центра обработки данных.
Мы настоятельно рекомендуем использовать по крайней мере Windows Server 2019 Datacenter по следующим причинам:
- WSFC в Windows Server 2019 — это azure.
- Центр обработки данных Windows Server 2019 включает интеграцию и осведомленность о обслуживании узлов Azure и улучшенную работу, отслеживая запланированные события Azure.
- Вы можете использовать имена распределенных сетей. (Это параметр по умолчанию.) Нет необходимости иметь выделенный IP-адрес для имени сети кластера. Кроме того, вам не нужно настраивать IP-адрес во внутренней подсистеме балансировки нагрузки Azure.
Архитектура
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 SID PR2 в дополнение к существующему кластеризованному экземпляру SAP PR1 ASCS/SCS.
Имена узлов и IP-адреса
В зависимости от типа развертывания имена узлов и IP-адреса сценария должны быть следующими примерами.
Ниже приведены сведения о развертывании SAP в группе доступности Azure:
Роль имени узла | Host name | Статический 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) | Нет данных | |
Имя сети кластера SAP ASCS SID1 | pr1-ascscl | 10.0.0.43 | Нет данных | |
SID1 Сетевое имя кластера ERS (только для ERS2) | pr1-erscl | 10.0.0.44 | Нет данных | |
Имя сети кластера SAP ASCS SID2 | pr2-ascscl | 10.0.0.45 | Нет данных | |
SID2 Сетевое имя кластера ERS (только для ERS2) | pr1-erscl | 10.0.0.46 | Нет данных |
Ниже приведены сведения о развертывании SAP в зонах доступности Azure:
Роль имени узла | Host name | Статический IP-адрес | Availability zone | Значение диска 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) | Нет данных | |
Имя сети кластера SAP ASCS SID1 | pr1-ascscl | 10.0.0.43 | Нет данных | |
SID2 Сетевое имя кластера ERS (только для ERS2) | pr1-erscl | 10.0.0.44 | Нет данных | |
Имя сети кластера SAP ASCS SID2 | pr2-ascscl | 10.0.0.45 | Нет данных | |
SID2 Сетевое имя кластера ERS (только для ERS2) | pr1-erscl | 10.0.0.46 | Нет данных |
Действия, описанные в этой статье, остаются одинаковыми для обоих типов развертывания. Но если кластер работает в группе доступности, необходимо развернуть LRS для общих дисков SSD Azure premium (Premium_LRS
). Если кластер работает в зоне доступности, необходимо развернуть ZRS для общих дисков SSD Azure Premium (Premium_ZRS
).
Создание внутренней подсистемы балансировки нагрузки Azure
Для конфигурации SAP SID с несколькими идентификаторами безопасности (PR2) можно использовать тот же внутренний балансировщик нагрузки, который вы создали для SAP SID, pr1 системы. Для архитектуры ENSA1 в Windows потребуется только один виртуальный IP-адрес для SAP ASCS/SCS. С другой стороны, архитектура ENSA2 требует двух виртуальных IP-адресов — один для SAP ASCS и другой для ERS2.
Настройте дополнительное правило балансировки внешних IP-адресов и балансировки нагрузки для SAP SID, PR2 в существующей подсистеме балансировки нагрузки, используя следующие рекомендации. В этом разделе предполагается, что конфигурация стандартной внутренней подсистемы балансировки нагрузки для БЕЗОПАСНОСТИ SAP PR1 уже создана, как описано в статье о создании подсистемы балансировки нагрузки.
- Откройте ту же стандартную внутреннюю подсистему балансировки нагрузки, которую вы создали для SAP SID, PR1 системы.
- Конфигурация внешнего IP-адреса: создание внешнего IP-адреса (например, 10.0.0.45).
- Внутренний пул: внутренний пул совпадает с системой SAP SID PR1.
- Правила для входящего трафика: создание правила балансировки нагрузки.
- Внешний IP-адрес: выбор внешнего IP-адреса
- Серверный пул: выбор внутреннего пула
- Проверьте "Порты высокой доступности"
- Протокол: TCP
- Проба работоспособности: создание пробы работоспособности со следующими сведениями
- Протокол: TCP
- Порт: [например: 620<экземпляров нет.> для SAP SID, PR2 ASCS]
- Интервал: 5
- Пороговое значение пробы: 2
- Время ожидания простоя (минуты): 30
- Установите флажок "Включить плавающий IP-адрес"
- Применимо только к архитектуре ENSA2: создайте дополнительный интерфейсный IP-адрес (10.0.0.44), правило балансировки нагрузки (используйте 621<экземпляр без> порта пробы работоспособности ERS2, как описано в точке 1 и 3).
Примечание.
Номер свойства конфигурации пробы работоспособностиOfProbes, иначе известный как "Неработоспособное пороговое значение" на портале, не учитывается. Таким образом, чтобы управлять числом успешных или неудачных последовательных проб, задайте для свойства "probeThreshold" значение 2. В настоящее время невозможно задать это свойство с помощью портал Azure, поэтому используйте команду Azure CLI или PowerShell.
Примечание.
Если во внутренний пул (без общедоступного IP-адреса) внутренней подсистемы балансировки нагрузки Azure (цен. категория "Стандартный") помещаются виртуальные машины без общедоступных IP-адресов, у них не будет исходящего подключения к Интернету, если вы не выполните дополнительную настройку, чтобы разрешить маршрутизацию к общедоступным конечным точкам. Подробные сведения о такой настройке см. в статье Подключение к общедоступной конечной точке для виртуальных машин с помощью Azure Load Balancer (цен. категория "Стандартный") в сценариях SAP с высоким уровнем доступности.
Создание и присоединение второго общего диска Azure
Выполните эту команду в одном из узлов кластера. Настройте значения таких сведений, как группа ресурсов, регион Azure и идентификатор БЕЗОПАСНОСТИ 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
Форматирование общего диска с помощью 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
Создайте запись DNS для имени виртуального узла для нового экземпляра SAP ASCS/SCS в диспетчере DNS Windows.
IP-адрес, назначенный имени виртуального узла в DNS, должен совпадать с IP-адресом, назначенным в Azure Load Balancer.
Если вы используете кластеризованный экземпляр SAP ERS2, необходимо зарезервировать в DNS имя виртуального узла для ERS2.
IP-адрес, назначенный виртуальному узлу для ERS2 в DNS, должен совпадать с IP-адресом, назначенным в Azure Load Balancer.
Чтобы определить IP-адрес виртуального имени узла, выберите Диспетчер DNS>Домен.
Установка SAP
Установка первого узла кластера SAP
Выполните процедуру установки, описанную в SAP. Не забудьте выбрать первый узел кластера в качестве параметра запуска установки. Выберите общий диск кластера в качестве параметра конфигурации. Выберите только что созданный общий диск.
Изменение профиля SAP экземпляра ASCS/SCS
Если вы используете ERS1, добавьте параметр enque/encni/set_so_keepalive
профиля SAP. Параметр профиля запрещает подключения между рабочими процессами SAP и сервером очереди закрывать, когда они неактивно. Параметр SAP не требуется для ERS2.
Добавьте этот параметр профиля в профиль экземпляра SAP ASCS/SCS, если вы используете ERS1:
enque/encni/set_so_keepalive = TRUE
Убедитесь, что для ERS1 и ERS2 параметры ОС
keepalive
заданы так, как указано в примечании для SAP 1410736.Чтобы применить изменения к параметру профиля SAP, перезапустите экземпляр SAP ASCS/SCS.
Настройка порта пробы в ресурсе кластера
Чтобы вся конфигурация кластера работала с Azure Load Balancer, нужно использовать функцию проб внутреннего балансировщика нагрузки. Обычно внутренний балансировщик нагрузки Azure распределяет входящую рабочую нагрузку поровну между участвующими виртуальными машинами.
Однако этот подход не будет работать в некоторых конфигурациях кластера, так как активен только один экземпляр. Другой экземпляр пассивен и не может принимать рабочую нагрузку. Функция пробы помогает, когда внутренняя подсистема балансировки нагрузки Azure определяет, какой экземпляр активен и предназначен только для активного экземпляра.
Внимание
В этом примере конфигурации порт пробы имеет значение 620nr. Для SAP ASCS с номером 02 экземпляра — 62002.
Необходимо настроить конфигурацию в соответствии с номерами экземпляров SAP и идентификатором безопасности SAP.
Чтобы добавить порт пробы, запустите этот модуль PowerShell на одной из виртуальных машин кластера:
Если вы используете SAP ASC/SCS с номером экземпляра 02:
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002
Если вы используете ERS2 с номером экземпляра 12, настройте порт пробы. Нет необходимости настраивать порт пробы для ERS1. ERS2 с номером 12 экземпляра кластеризован, а 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.
Установите экземпляр сервера приложений SAP (PAS) на виртуальной машине, предназначенной для размещения PAS.
Выполните процедуру, описанную в разделе руководства по установке SAP. В Azure нет зависимостей.
Установите дополнительные серверы приложений SAP на виртуальных машинах, назначенных для размещения экземпляров сервера приложений SAP.
Выполните процедуру, описанную в разделе руководства по установке SAP. В Azure нет зависимостей.
Тестирование отработки отказа экземпляра SAP ASCS/SCS
В описанных тестах отработки отказа предполагается, что SAP ASCS активна на узле A.
Убедитесь, что система SAP может успешно выполнить отработку отказа с узла A на узел B. В этом примере тест предназначен для SAP SID PR2.
Убедитесь, что каждый идентификатор безопасности SAP может успешно перейти на другой узел кластера. Выберите один из следующих вариантов, чтобы инициировать отработку отказа кластерной группы SAP <SID> из узла кластера A на узел кластера B:
- Диспетчер отказоустойчивости кластеров
- Команды PowerShell для отказоустойчивых кластеров
$SAPSID = "PR2" # SAP <SID> $SAPClusterGroup = "SAP $SAPSID" Move-ClusterGroup -Name $SAPClusterGroup
Перезапустите узел A кластера из гостевой ОС Windows. На этом шаге инициируется автоматическая отработка отказа группы кластеров SAP <SID> с узла A на узел B.
Перезапустите узел A кластера с помощью портала Azure. На этом шаге инициируется автоматическая отработка отказа группы кластеров SAP <SID> с узла A на узел B.
Перезапустите узел A кластера с помощью Azure PowerShell. На этом шаге инициируется автоматическая отработка отказа группы кластеров SAP <SID> с узла A на узел B.