Обеспечение высокого уровня доступности SAP HANA на виртуальных машинах Azure в Red Hat Enterprise Linux

Статья
04/08/2024

Для локальной разработки можно использовать репликацию системы HANA или общее хранилище, чтобы установить высокий уровень доступности для SAP HANA. В Azure Виртуальные машины репликация системы HANA в Azure в настоящее время является единственной поддерживаемой функцией высокой доступности.

Для репликации SAP HANA используются один основной узел и по крайней мере один вторичный узел. Изменения данных на основном узле синхронно или асинхронно реплицируются на вторичные узлы.

В этой статье описывается, как развернуть и настроить виртуальные машины , установить платформу кластера и установить и настроить репликацию системы SAP HANA.

В примерах конфигурации и командах установки используется номер экземпляра 03 и идентификатор системы HANA HN1.

Необходимые компоненты

Прежде всего прочитайте следующие примечания и документы SAP:

Заметка SAP 1928533, которая имеет следующее:
- список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
- важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
- Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
- сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
примечание к SAP 2015553, в котором описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure;
примечание к SAP 2002167, содержащее рекомендуемые параметры ОС для Red Hat Enterprise Linux;
примечание к SAP 2009879, содержащее рекомендации по SAP HANA для Red Hat Enterprise Linux;
Примечание SAP 3108302 содержит рекомендации ПО SAP HANA для Red Hat Enterprise Linux 9.x.
примечание к SAP 2178632, содержащее подробные сведения обо всех доступных метриках мониторинга для SAP в Azure;
примечание к SAP 2191498, содержащее сведения о необходимой версии агента SAP Host Agent для Linux в Azure;
примечание к SAP 2243692, содержащее сведения о лицензировании SAP в Linux в Azure;
примечание к SAP 1999351, в котором приведены дополнительные сведения об устранении неполадок, связанных с расширением для расширенного мониторинга Azure для SAP;
вики-сайт сообщества SAP, содержащий все необходимые примечания к SAP для Linux;
SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению
Развертывание виртуальных машин Azure для SAP в Linux (данная статья)
Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
Репликация системы SAP HANA в кластере Pacemaker
Общая документация по RHEL:
Документация по RHEL для конкретной службы Azure:

Обзор

Для достижения высокой доступности SAP HANA устанавливается на двух виртуальных машинах. Данные реплицируются с использованием системной репликации HANA.

Схема с обзором высокого уровня доступности SAP HANA.

Программа установки репликации системы SAP HANA использует выделенное имя виртуального узла и виртуальные IP-адреса. Load Balancer в Azure должен использовать виртуальный IP-адрес. В представленной конфигурации показана следующая подсистема балансировки нагрузки:

Интерфейсный IP-адрес: 10.0.0.13 для HN1-DB
Порт пробы: 62503

Подготовка инфраструктуры

Azure Marketplace содержит образы, квалифицированные для SAP HANA с надстройкой с высокой доступностью, которую можно использовать для развертывания новых виртуальных машин с помощью различных версий Red Hat.

Развертывание виртуальных машин Linux вручную с помощью портал Azure

В этом документе предполагается, что вы уже развернули группу ресурсов, виртуальную сеть Azure и подсеть.

Развертывание виртуальных машин для SAP HANA. Выберите подходящий образ RHEL, поддерживаемый для системы HANA. Виртуальную машину можно развернуть в любом из вариантов доступности: масштабируемый набор виртуальных машин, зона доступности или группу доступности.

Внимание

Убедитесь, что выбранная ОС сертифицирована для SAP HANA на определенных типах виртуальных машин, которые планируется использовать в развертывании. Вы можете искать типы виртуальных машин, сертифицированные SAP HANA, и их выпуски ОС на платформах IaaS, сертифицированных sap HANA. Убедитесь, что вы просматриваете сведения о типе виртуальной машины, чтобы получить полный список выпусков ОС, поддерживаемых SAP HANA, для конкретного типа виртуальной машины.

Настройка Azure Load Balancer

Во время настройки виртуальной машины можно создать или выбрать выход из подсистемы балансировки нагрузки в разделе сети. Выполните следующие действия, чтобы настроить стандартную подсистему балансировки нагрузки для установки высокой доступности базы данных HANA.

Выполните действия, описанные в статье "Создание подсистемы балансировки нагрузки", чтобы настроить стандартную подсистему балансировки нагрузки для системы SAP с высоким уровнем доступности с помощью портал Azure. Во время настройки подсистемы балансировки нагрузки рассмотрите следующие моменты:

Конфигурация внешнего IP-адреса: создание внешнего IP-адреса. Выберите ту же виртуальную сеть и имя подсети, что и виртуальные машины базы данных.
Серверный пул: создайте внутренний пул и добавьте виртуальные машины базы данных.
Правила для входящего трафика: создание правила балансировки нагрузки. Выполните те же действия для обоих правил балансировки нагрузки.
- Внешний IP-адрес: выберите внешний IP-адрес.
- Внутренний пул: выберите внутренний пул.
- Порты высокой доступности: выберите этот параметр.
- Протокол. Выберите TCP.
- Проба работоспособности: создайте пробу работоспособности со следующими сведениями:
  - Протокол. Выберите TCP.
  - Порт: например, 625<экземпляра no.>.
  - Интервал. Введите 5.
  - Пороговое значение пробы: введите 2.
- Время ожидания простоя (минуты): введите 30.
- Включите плавающий IP-адрес: выберите этот параметр.

Примечание.

Свойство конфигурации пробы работоспособности , в противном случае известное как неработоспособное пороговое значение numberOfProbesна портале, не учитывается. Чтобы управлять числом успешных или неудачных последовательных проб, задайте для свойства probeThreshold значение 2. В настоящее время невозможно задать это свойство с помощью портал Azure, поэтому используйте Azure CLI или команду PowerShell.

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

Развертывание для просмотра полного кода CLI

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

Развертывание для просмотра полного кода PowerShell

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Дополнительные сведения о необходимых портах для SAP HANA см. в главе Подключения к базам данных клиента руководства Базы данных клиента SAP HANA или в примечании к SAP 2388694.

Внимание

Плавающий IP-адрес не поддерживается для дополнительных IP-конфигураций сетевых карт в сценариях с балансировкой нагрузки. Дополнительные сведения см. в разделе об ограничениях Azure Load Balancer. Если вам нужен другой IP-адрес для виртуальной машины, разверните второй сетевой адаптер.

Примечание.

Если виртуальные машины без общедоступных IP-адресов помещаются в внутренний пул внутреннего (без общедоступного IP-адреса) экземпляра Azure Load Balancer уровня "Стандартный", исходящее подключение к Интернету не выполняется, если не выполняется дополнительная настройка, чтобы разрешить маршрутизацию на общедоступные конечные точки. Дополнительные сведения о том, как обеспечить исходящее подключение, см. в статье "Подключение к общедоступной конечной точке для виртуальных машин" с помощью Azure Load Balancer (цен. категория в сценариях высокой доступности SAP.

Внимание

Не включайте метки времени TCP на виртуальных машинах Azure, размещенных за Azure Load Balancer. Включение меток времени TCP может привести к сбою проб работоспособности. Задайте для параметра net.ipv4.tcp_timestamps значение 0. Дополнительные сведения см. в статье "Пробы работоспособности Load Balancer" и 2382421 заметкиSAP.

Установка SAP HANA

Во всех действиях этого раздела используются следующие префиксы.

[A] — шаг применяется ко всем узлам.
[1] — шаг применяется только к узлу 1.
[2] — шаг применяется только к узлу 2 в кластере Pacemaker.

[A] Настройте разметку диска (для диспетчера логических томов).

Мы рекомендуем использовать диспетчер логических томов для всех томов, предназначенных для хранения данных и файлов журнала. В следующем примере предполагается, что виртуальные машины имеют четыре диска данных, подключенные для создания двух томов.

Список всех доступных дисков:
```
ls /dev/disk/azure/scsi1/lun*
```
Пример результата:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
Создайте физические тома для всех дисков, которые вы хотите использовать:
```
sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2
sudo pvcreate /dev/disk/azure/scsi1/lun3
```
Создайте группу томов для файлов данных. Используйте одну группу томов для файлов журналов и другую — для общей папки SAP HANA.
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
```
Создайте логические тома. Линейный том создается при использовании lvcreate без параметра -i. Для повышения производительности операций ввода-вывода мы рекомендуем создать том с чередованием. Для определения размеров блоков чередования руководствуйтесь значениям из статьи Конфигурации хранилища виртуальных машин SAP HANA в Azure. Аргумент -i должен быть числом базовых физических томов, а -I аргументом является размер полосы.

В этом документе для тома данных используется 2 физических тома, поэтому аргумент -i имеет значение 2. Размер блока чередования для тома данных составляет 256 КиБ. Журнальный том использует один физический том, поэтому параметры -i и -I не используются явным образом в командах для журнального тома.

Внимание

Параметр -i, значение которого соответствует числу базовых физических томов, необходимо указывать для всех томов данных, журналов или общих томов, для которых используется более одного физического тома. Используйте параметр -I, чтобы указать размер блока чередования при создании чередующегося тома. Сведения о рекомендуемых конфигурациях хранилища, включая размеры блоков чередования и количество дисков, см. в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure. Следующие примеры макета не обязательно соответствуют рекомендациям по производительности для определенного размера системы. Они только для иллюстрации.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
```
Не подключайте каталоги, выдавая команды подключения. Вместо этого введите конфигурации в fstab и оставьте окончательный mount -a для проверки синтаксиса. Начните с создания каталогов подключения для каждого тома:
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
Затем создайте fstab записи для трех логических томов, вставив в файл следующие строки /etc/fstab :

/dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 22

Наконец, подключите новые тома одновременно:
```
sudo mount -a
```
[A] Настройте разрешение имен узлов для всех узлов.

Вы можете использовать DNS-сервер или изменить /etc/hosts файл на всех узлах, создав записи для всех узлов, как показано ниже /etc/hosts.

10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] Выполните RHEL для конфигурации HANA.

Настройте RHEL, как описано в следующих примечаниях:
- 2447641 — дополнительные пакеты, необходимые для установки SAP HANA SPS 12 на RHEL 7.X
- 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (Примечание по поддержке SAP № 2292690. База данных SAP HANA: рекомендуемые параметры операционной системы для RHEL 7).
- 2777782. SAP HANA DB: рекомендуемые параметры ОС для RHEL 8;
- 2455582. Linux: запуск приложений SAP, скомпилированных с помощью GCC 6.x;
- 2593824. Linux: запуск приложений SAP, скомпилированных с помощью GCC 7.x;
- 2886607. Linux: запуск приложений SAP, скомпилированных с помощью GCC 9.x.
[A] Установите SAP HANA.

Сведения об установке репликации системы SAP HANA см. в разделе Автоматизация репликации системы SAP HANA при вертикальном масштабировании с помощью надстройки RHEL HA.

Запустите программу hdblcm с DVD-диска HANA. Введите следующие значения на запрос в командной строке:
1. Choose installation (Выберите установку): введите 1.
2. Select additional components for installation (Выберите дополнительные компоненты для установки): введите 1.
3. Введите путь установки [/hana/shared]: нажмите клавишу ВВОД.
4. Введите имя локального узла [.]: нажмите клавишу ВВОД.
5. "Do you want to add additional hosts to the system? (y/n)" (y/n) [n]: нажмите клавишу ВВОД.
6. Введите идентификатор системы SAP HANA: введите идентификатор безопасности HANA, например HN1.
7. Введите номер экземпляра [00]: введите номер экземпляра HANA. Введите 03, если вы использовали шаблон Azure или выполняли развертывание вручную по инструкциям из этой статьи.
8. Select Database Mode / Enter Index (Выберите режим базы данных / введите индекс) [1]: нажмите клавишу ВВОД.
9. Выберите системное использование и введите индекс [4]: выберите значение использования системы.
10. Введите расположение томов данных [/hana/data]: нажмите клавишу ВВОД.
11. Введите расположение томов журнала [/hana/log]: нажмите клавишу ВВОД.
12. Restrict maximum memory allocation? [n]: нажмите клавишу ВВОД.
13. Введите имя узла сертификата "..." [...]: нажмите клавишу ВВОД.
14. Введите пароль пользователя агента узла SAP (sapadm): введите пароль пользователя агента узла.
15. Подтвердите пароль пользователя агента узла SAP (sapadm): снова введите пароль пользователя агента узла, чтобы подтвердить.
16. Введите пароль system Администратор istrator (hdbadm): введите пароль системного администратора.
17. Подтвердите пароль Администратор istrator (hdbadm): введите пароль системного администратора еще раз, чтобы подтвердить.
18. Введите системный Администратор istrator Home Directory [/usr/sap/HN1/home]: нажмите клавишу ВВОД.
19. Введите system Администратор istrator Login Shell [/bin/sh]: нажмите клавишу ВВОД.
20. Введите идентификатор пользователя system Администратор istrator [1001]: нажмите клавишу ВВОД.
21. Введите идентификатор группы пользователей (sapsys) [79]: нажмите клавишу ВВОД.
22. Введите пароль пользователя базы данных (SYSTEM): введите пароль пользователя базы данных.
23. Подтвердите пароль пользователя базы данных (SYSTEM): снова введите пароль пользователя базы данных, чтобы подтвердить.
24. Restart system after machine reboot? [n]: нажмите клавишу ВВОД.
25. Вы действительно хотите продолжить? (y/n): проверьте сводку. Для продолжения введите y.
[A]. Обновите агент узла SAP.

Скачайте последний архив агента узла SAP на сайте центра программного обеспечения SAP и выполните следующую команду, чтобы обновить этот агент. Замените путь к архиву, чтобы он указывал на скачанный файл.
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent>;
```
[A] Настройте брандмауэр.

Создайте правило брандмауэра для порта пробы Azure Load Balancer.
```
sudo firewall-cmd --zone=public --add-port=62503/tcp
sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent
```

Настройка репликации системы SAP HANA 2.0

Во всех действиях этого раздела используются следующие префиксы.

[A] — шаг применяется ко всем узлам.
[1] — шаг применяется только к узлу 1.
[2] — шаг применяется только к узлу 2 в кластере Pacemaker.

[A] Настройте брандмауэр.

Создайте правила брандмауэра, разрешающие передачу трафика репликации системы HANA и клиентов. Требуемые порты перечислены в разделе Порты TCP/IP для всех продуктов SAP. Приведенные ниже команды — это просто пример, позволяющий HANA 2.0 системной репликации и трафику клиента в базу данных SYSTEMDB, HN1 и NW1.
```
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
```
[1] Создайте базу данных клиента.

Если вы используете SAP HANA 2.0 или MDC, создайте базу данных клиента для системы SAP NetWeaver. Замените NW1 идентификатором SID для системы SAP.

Выполните следующую команду от имени <hanasid>adm:
```
hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
```

[1] Настройка системного реплика tion на первом узле.

Создайте резервную копию баз данных с правами пользователя <hanasid>adm:

hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

Скопируйте системные файлы PKI на вторичный сайт.

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Создайте основной сайт:

hdbnsutil -sr_enable --name=SITE1

[2] Настройка реплика системных реплика на втором узле.

Зарегистрируйте второй узел, чтобы запустить репликацию системы. Выполните следующую команду от имени <hanasid>adm:
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```

[1] Проверьте состояние реплика.

Проверьте состояние реплика и дождитесь синхронизации всех баз данных. Если состояние остается НЕИЗВЕСТНЫм, проверка параметры брандмауэра.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
# | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# mode: PRIMARY
# site id: 1
# site name: SITE1

Настройка репликации системы SAP HANA 1.0

Во всех действиях этого раздела используются следующие префиксы.

[A] — шаг применяется ко всем узлам.
[1] — шаг применяется только к узлу 1.
[2] — шаг применяется только к узлу 2 в кластере Pacemaker.

[A] Настройте брандмауэр.

Создайте правила брандмауэра, разрешающие передачу трафика репликации системы HANA и клиентов. Требуемые порты перечислены в разделе Порты TCP/IP для всех продуктов SAP. Приведенные ниже команды — лишь пример того, как разрешить репликацию системы HANA 2.0. Адаптируйте его в соответствии со своей установкой SAP HANA 1.0.
```
sudo firewall-cmd --zone=public --add-port=40302/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40302/tcp
```
[1] Создайте обязательных пользователей.

Выполните следующую команду от имени привилегированного пользователя. Обязательно замените значения для идентификатора системы HANA (например, HN1), номера экземпляра (03) и всех имен пользователей с значениями установки SAP HANA:
```
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"'
hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'
```
[A] Создайте запись в хранилище ключей.

Выполните следующую команду от имени привилегированного пользователя, чтобы создать новую запись в хранилище ключей.
```
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd
```
[1] Создайте резервную копию базы данных.

Выполните резервное копирование баз данных от имени привилегированного пользователя.
```
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"
```
При использовании мультитенантной установки также создайте резервную копию базы данных клиента:
```
hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"
```
[1] Настройка системного реплика tion на первом узле.

Создайте основной сайт от имени <hanasid>adm:
```
su - hdbadm
hdbnsutil -sr_enable –-name=SITE1
```
[2] Настройка реплика системных реплика на вторичном узле.

Зарегистрируйте дополнительный сайт с правами пользователя <hanasid>adm:
```
HDB stop
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
HDB start
```

Создание кластера Pacemaker

Чтобы создать базовый кластер Pacemaker для этого сервера HANA, выполните действия, приведенные в разделе Настройка Pacemaker в Red Hat Enterprise Linux в Azure.

Внимание

Благодаря системной платформе SAP Startup Framework экземпляры SAP HANA теперь могут управляться системой. Минимальная требуемая версия Red Hat Enterprise Linux (RHEL) — RHEL 8 для SAP. Как описано в примечании к SAP 3189534, все новые установки SAP HANA SPS07 версии 70 или более поздней версии или обновления систем HANA до версии HANA 2.0 SPS07 версии 70 или более поздней версии, платформа запуска SAP будет автоматически зарегистрирована в системном режиме.

При использовании решений высокого уровня доступности для управления реплика системы SAP HANA в сочетании с экземплярами SAP HANA с поддержкой системы (см. примечание SAP 3189534), необходимо выполнить дополнительные действия, чтобы кластер высокого уровня доступности может управлять экземпляром SAP без системного вмешательства. Поэтому для системы SAP HANA, интегрированной с системой, необходимо выполнить дополнительные шаги, описанные в Red Hat КБ A 7029705 на всех узлах кластера.

Внедрение перехватчика репликации системы Python для SAPHanaSR

Этот важный шаг оптимизирует интеграцию с кластером и улучшает обнаружение при необходимости отработки отказа кластера. Настоятельно рекомендуется настроить перехватчик Python SAPHanaSR.

[A]Установите агенты ресурсов SAP HANA на всех узлах. Обязательно включите репозиторий, содержащий пакет. Вам не нужно включать дополнительные репозитории, если вы используете образ RHEL 8.x с поддержкой высокой доступности.
```
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo yum install -y resource-agents-sap-hana
```
[A] Установите HANA system replication hook. Перехватчик должен быть установлен на обоих узлах базы данных HANA.

Совет

Перехватчик Python можно внедрить только для HANA 2.0.
1. Подготовьте перехватчик с правами пользователя root.
```
 mkdir -p /hana/shared/myHooks
 cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
 chown -R hn1adm:sapsys /hana/shared/myHooks
```
2. Остановите экземпляры HANA на обоих узлах. Выполните команду от имени <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```
3. Настройте global.ini на каждом узле кластера.
```
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /hana/shared/myHooks
execution_order = 1

[trace]
ha_dr_saphanasr = info
```

[A] Кластеру требуется sudoers конфигурация на каждом узле кластера для <идентификатора>adm. В этом примере это достигается путем создания нового файла. visudo Используйте команду, чтобы изменить 20-saphana раскрывающийся файл как root.

sudo visudo -f /etc/sudoers.d/20-saphana

Вставьте следующие строки и сохраните:

Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty

[A] Запустите SAP HANA на обоих узлах. Выполните команду от имени <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1]: проверьте установку перехватчика. Выполните приведенные команды с правами пользователя <sid>adm на активном сайте репликации системы HANA.

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

 # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
 # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK

Дополнительные сведения о реализации перехватчика репликации системы SAP HANA см. в разделе "Включение перехватчика поставщика SAP HA/DR".

Создание ресурсов кластера SAP HANA

Создайте топологию HANA. Выполните следующие команды на одном из узлов кластера Pacemaker. В этих инструкциях обязательно замените номер экземпляра, идентификатор системы HANA, IP-адреса и системные имена.

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

Теперь создайте ресурсы HANA.

Примечание.

В этой статье содержатся ссылки на термин, который корпорация Майкрософт больше не использует. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.

Если вы создаете кластер на RHEL 7.x, используйте следующие команды:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000

sudo pcs property set maintenance-mode=false

Если вы создаете кластер на RHEL 8.x/9.x, используйте следующие команды:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  promotable notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

sudo pcs property set maintenance-mode=false

Чтобы настроить priority-fencing-delay SAP HANA (применимо только к pacemaker-2.0.4-6.el8 или более поздней версии), необходимо выполнить следующие команды.

Примечание.

Если у вас есть кластер с двумя узлами, можно настроить priority-fencing-delay свойство кластера. Это свойство представляет задержку в ограждении узла, имеющего более высокий общий приоритет ресурсов при возникновении сценария разделения мозга. Дополнительные сведения см. в статье "Можно ли Pacemaker заборить узел кластера с наименьшими работающими ресурсами?".

Свойство priority-fencing-delay применимо к pacemaker-2.0.4-6.el8 или более поздней версии. Если вы настраиваете priority-fencing-delay существующий кластер, не забудьте настроить pcmk_delay_max параметр на устройстве ограждения.

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

Внимание

При выполнении тестов отработки отказа рекомендуется установить для параметра AUTOMATED_REGISTER значение false, чтобы предотвратить автоматическую регистрацию в качестве получателя основного экземпляра, завершившего работу со сбоем. После тестирования, как рекомендуется, установите для AUTOMATED_REGISTERtrue этого значение после перехода, система реплика tion может возобновиться автоматически.

Убедитесь, что состояние кластера нормально и все ресурсы запущены. Какой узел, на котором выполняются ресурсы, не важен.

Примечание.

Время ожидания в предыдущей конфигурации — это только примеры и может потребоваться адаптироваться к определенной настройке HANA. Например, время ожидания при запуске лучше увеличить, если запуск базы данных SAP HANA выполняется долго.

Используйте командуsudo pcs status, чтобы проверка состояние созданных ресурсов кластера:

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Настройка реплика системы с поддержкой HANA в кластере Pacemaker

Начиная с SAP HANA 2.0 с пакетом обновления 01 (SPS 01), SAP поддерживает активные и чтение установки для репликации системы SAP HANA, где вторичные системы репликации системы SAP HANA можно использовать активно для рабочих нагрузок с интенсивным чтением.

Для поддержки такой настройки в кластере требуется второй виртуальный IP-адрес, который позволяет клиентам получить доступ к базе данных SAP HANA с поддержкой чтения. Чтобы обеспечить доступ к вторичному сайту реплика tion после того, как произошел переход, кластеру необходимо переместить виртуальный IP-адрес вокруг вторичного ресурса SAPHana.

В этом разделе описаны другие шаги, необходимые для управления HANA активным и чтением системных реплика tion в кластере Red Hat HA со вторым виртуальным IP-адресом.

Прежде чем продолжить, убедитесь, что кластер Red Hat HA полностью настроен для управления базой данных SAP HANA, как описано в предыдущих сегментах документации.

Схема, показывющая высокий уровень доступности SAP HANA с дополнительным доступом для чтения.

Дополнительная настройка в подсистеме балансировки нагрузки Azure для активных и доступных для чтения настроек

Чтобы выполнить дополнительные действия по подготовке второго виртуального IP-адреса, убедитесь, что вы настроили Azure Load Balancer, как описано в разделе "Развертывание виртуальных машин Linux вручную с помощью портал Azure".

Для стандартной подсистемы балансировки нагрузки выполните следующие действия в том же подсистеме балансировки нагрузки, которую вы создали в предыдущем разделе.

a. Создайте второй пул внешних IP-адресов:
- Откройте подсистему балансировки нагрузки, выберите пул интерфейсных IP-адресов и щелкните Добавить.
- Введите имя нового пула интерфейсных IP-адресов (например, hana-frontend).
- Задайте значение "Назначение" статическим и введите IP-адрес (например, 10.0.0.14).
- Нажмите ОК.
- Когда пул интерфейсных IP-адресов будет создан, запишите его IP-адрес.
b. Создайте пробу работоспособности:
- Откройте подсистему балансировки нагрузки, выберите Зонды работоспособности и щелкните Добавить.
- Введите имя нового зонда работоспособности (например, hana-secondaryhp).
- Выберите протокол TCP и порт 62603. Сохраните значение интервала, равное 5, а пороговое значение неработоспособного значения — 2.
- Нажмите ОК.
c. Создайте правила балансировки нагрузки:
- Откройте подсистему балансировки нагрузки, выберите Правила балансировки нагрузки щелкните Добавить.
- Введите имя нового правила балансировки нагрузки (например, hana-secondarylb).
- Выберите интерфейсный пул IP-адресов, серверный пул и зонд работоспособности, который вы создали ранее (например, hana-secondaryIP, hana-backend и hana-secondaryhp).
- Выберите Порты высокой доступности.
- Не забудьте включить плавающий IP-адрес.
- Нажмите ОК.

Настройка репликации системы (Active/Read) с поддержкой HANA

Действия по настройке репликации системы HANA описаны в разделе "Настройка репликации системы SAP HANA 2.0". Если вы развертываете дополнительный сценарий с поддержкой чтения при настройке системного реплика tion на втором узле, выполните следующую команду как hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess

Добавление дополнительного ресурса виртуального IP-адреса для установки с активной или доступной для чтения конфигурацией

Второй виртуальный IP-адрес и соответствующее ограничение совместного размещения можно настроить с помощью следующих команд:

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"

pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603

pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master

pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

pcs property set maintenance-mode=false

Убедитесь, что состояние кластера нормально и все ресурсы запущены. Второй виртуальный IP-адрес выполняется на вторичном сайте вместе со вторичным ресурсом SAPHana.

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

В следующем разделе можно найти типичный набор тестов отработки отказа для выполнения.

Помните о втором поведении виртуальных IP-адресов при тестировании кластера HANA, настроенного с поддержкой чтения вторичную:

При переносе ресурса кластера SAPHana_HN1_03 на вторичный сайт hn1-db-1 второй виртуальный IP-адрес продолжает работать на том же сайте hn1-db-1. Если вы установили AUTOMATED_REGISTER="true" для ресурса и системы HANA реплика tion регистрируется автоматически в hn1-db-0, второй виртуальный IP-адрес также перемещается в hn1-db-0.
При тестировании сбоя сервера второй виртуальный IP-ресурс (secvip_HN1_03) и ресурс порта Azure Load Balancer (secnc_HN1_03) выполняются на основном сервере вместе с основными виртуальными IP-ресурсами. Таким образом, до тех пор, пока сервер-получатель не будет отключен, приложения, подключенные к базе данных HANA с поддержкой чтения, подключаются к основной базе данных HANA. Ожидается, что поведение не требуется, чтобы приложения, подключенные к базе данных HANA с поддержкой чтения, были недоступны до тех пор, пока сервер-получатель недоступен.
Во время отработки отказа и резервного копирования второго виртуального IP-адреса существующие подключения в приложениях, использующих второй виртуальный IP-адрес для подключения к базе данных HANA, могут быть прерваны.

Программа установки максимально увеличивает время, когда второй виртуальный IP-ресурс назначается узлу, в котором запущен работоспособный экземпляр SAP HANA.

Проверка настройки кластера

В этом разделе описано, как проверить настроенную систему. Перед началом теста убедитесь, что Pacemaker не имеет каких-либо неудачных действий (с помощью состояния пк), нет непредвиденных ограничений расположения (например, оставшиеся элементы теста миграции), и что HANA находится в состоянии синхронизации, например с systemReplicationStatus.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

Проверка миграции

Состояние ресурсов перед запуском теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Главный узел SAP HANA можно перенести, выполнив следующую команду в качестве корневого узла:

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

Кластер перенесите главный узел SAP HANA и группу, содержащую виртуальный IP-адрес hn1-db-1.

После завершения миграции выходные sudo pcs status данные выглядят следующим образом:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

При этом AUTOMATED_REGISTER="false"кластер не перезагрузит неудачную базу данных HANA или зарегистрирует ее в новой первичной базе hn1-db-0данных. В этом случае настройте экземпляр HANA в качестве дополнительного, выполнив следующие команды, как hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

При переносе устанавливаются ограничения расположения, которые должны быть удалены. Выполните следующую команду в качестве корневого каталога или с помощью sudo:

pcs resource clear SAPHana_HN1_03-master

Отслеживайте состояние ресурса HANA с помощью pcs status. После запуска hn1-db-0HANA выходные данные должны выглядеть следующим образом:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Блокировка сетевого взаимодействия

Состояние ресурсов перед запуском теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Запустите правило брандмауэра, чтобы заблокировать связь на одном из узлов.

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

Если узлы кластера не могут взаимодействовать друг с другом, существует риск сценария разделения мозга. В таких ситуациях узлы кластера пытаются одновременно заборить друг друга, что приводит к гонке забора. Чтобы избежать такой ситуации, рекомендуется задать свойство priority-fencing-delay в конфигурации кластера (применимо только для pacemaker-2.0.4-6.el8 или более поздней версии).

Включив priority-fencing-delay свойство, кластер вводит задержку в действии ограждения специально на узле, на котором размещен главный ресурс HANA, что позволяет узлу выиграть гонку забора.

Выполните следующую команду, чтобы удалить правило брандмауэра:

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

Проверка агента ограждения Azure

Примечание.

Состояние ресурсов перед запуском теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Чтобы проверить конфигурацию агента ограждения, отключите сетевой интерфейс в главном узле SAP HANA. Описание того, как имитировать сбой сети, см. в статье Базы знаний Red Hat 79523.

В этом примере скрипт используется в качестве корневого net_breaker каталога для блокировки всего доступа к сети:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

Теперь виртуальная машина должна перезапустить или остановиться в зависимости от конфигурации кластера. Если задано значение параметраoff, виртуальная stonith-action машина остановлена, а ресурсы переносятся на запущенную виртуальную машину.

После повторного запуска виртуальной машины ресурс SAP HANA не может запуститься как дополнительный, если задано.AUTOMATED_REGISTER="false" В этом случае настройте экземпляр HANA в качестве дополнительного , выполнив следующую команду в качестве пользователя hn1adm :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

Вернитесь в корневой каталог и очистите состояние сбоя:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Состояние ресурсов после теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Тестирование отработки отказа вручную

Состояние ресурсов перед запуском теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Вы можете протестировать отработку отказа вручную, остановив кластер на узле в качестве корневого hn1-db-0 каталога:

pcs cluster stop

После отработки отказа можно снова запустить кластер. Если задано AUTOMATED_REGISTER="false", ресурс SAP HANA на hn1-db-0 узле не запускается как дополнительный. В этом случае настройте экземпляр HANA в качестве вторичного, выполнив следующую команду в качестве корневого каталога:

pcs cluster start

Выполните следующую команду как hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

Затем в качестве корневого:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Состояние ресурсов после теста:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Обеспечение высокого уровня доступности SAP HANA на виртуальных машинах Azure в Red Hat Enterprise Linux

Необходимые компоненты

Обзор

Подготовка инфраструктуры

Развертывание виртуальных машин Linux вручную с помощью портал Azure

Настройка Azure Load Balancer

Установка SAP HANA

Настройка репликации системы SAP HANA 2.0

Настройка репликации системы SAP HANA 1.0

Создание кластера Pacemaker

Внедрение перехватчика репликации системы Python для SAPHanaSR

Создание ресурсов кластера SAP HANA

Настройка реплика системы с поддержкой HANA в кластере Pacemaker

Дополнительная настройка в подсистеме балансировки нагрузки Azure для активных и доступных для чтения настроек

Настройка репликации системы (Active/Read) с поддержкой HANA

Добавление дополнительного ресурса виртуального IP-адреса для установки с активной или доступной для чтения конфигурацией

Проверка настройки кластера

Проверка миграции

Блокировка сетевого взаимодействия

Проверка агента ограждения Azure

Тестирование отработки отказа вручную

Следующие шаги

Дополнительные ресурсы