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

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

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

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

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

Предварительные условия

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

• Заметка SAP 1928533, которая имеет следующее:
  • список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
  • важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
  • Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
  • сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
• Заметка SAP 2015553 содержит предварительные требования для развертывания решений 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;
• Планирование и внедрение виртуальных машин Azure для SAP на Linux
• Развертывание виртуальных машин Azure для SAP в Linux (данная статья)
• Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
• Репликация системы SAP HANA в кластере Pacemaker
• Общая документация по RHEL:
  • Общие сведения о надстройке для обеспечения высокой доступности
  • Администрирование надстройки для обеспечения высокой доступности
  • Справочник по надстройке для обеспечения высокой доступности
  • Репликация системы HANA с масштабированием с помощью дополнения RHEL HA
• Документация по RHEL для конкретной службы Azure:
  • Политики поддержки для кластеров высокой доступности RHEL — виртуальные машины Microsoft Azure как члены кластера
  • Установка и настройка кластера высокой доступности Red Hat Enterprise Linux 7.4 (и более поздних версий) в Microsoft Azure
  • Установка SAP HANA в Red Hat Enterprise Linux для использования в Microsoft Azure

Обзор

Чтобы достичь HA, SAP HANA устанавливается на двух виртуальных машинах. Данные реплицируются с использованием системной репликации 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. Виртуальную машину можно развернуть в любом из вариантов доступности: масштабируемый набор виртуальных машин, зона доступности или группу доступности.

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

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

# 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

# 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

# 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.

Установка SAP HANA

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

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

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

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

   Список всех доступных дисков:

   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. Аргумент -i должен быть числом базовых физических объемов, а аргумент -I — размером полосы.

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

   Внимание

   Используйте переключатель -i и установите его значение, равное числу базового физического тома, если используется более одного физического тома для каждого из томов данных, журналов или общих томов. Используйте параметр -I, чтобы указать размер полосы при создании полосного тома. См. Конфигурации хранилища виртуальных машин SAP HANA для получения рекомендаций по конфигурациям хранилища, включая размеры блоков чередования и количество дисков. Следующие примеры макета не обязательно соответствуют рекомендациям по производительности для определенного размера системы. Они только для иллюстрации.

   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 2

   Наконец, подключите все новые тома сразу.

   sudo mount -a
   

2. [A] Настройте разрешение имен узлов для всех узлов.

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

   10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1

3. [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.

4. [A] Установите SAP HANA, следуя документации SAP.

5. [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.

1. [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
   
   

2. [1] Создайте базу данных клиента.

   Выполните следующую команду от имени <hanasid>adm:

   hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
   

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

   Создайте резервную копию баз данных как <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
   

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

   Зарегистрируйте второй узел, чтобы запустить репликацию системы. Выполните следующую команду от имени <hanasid>adm:

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

5. [2] Запуск HANA.

   Выполните следующую команду как <adm hanasid>, чтобы запустить HANA:

   sapcontrol -nr 03 -function StartSystem
   

6. [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
   

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

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

Внедрение хуков репликации системы SAP HANA

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

1. [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 dnf install -y resource-agents-sap-hana
   

   Примечание.

   Для RHEL 8.x и RHEL 9.x убедитесь, что установленный пакет resource-agent-sap-hana версии 0.162.3-5 или более поздней версии.

2. [A] Установите HANA system replication hooks. Конфигурацию для перехватчиков репликации необходимо установить на обоих узлах базы данных HANA.

   1. Остановите HANA на обоих узлах. Выполните команду от имени <sid>adm.

      sapcontrol -nr 03 -function StopSystem
      

   2. Настройте global.ini на каждом узле кластера.

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 1
      
      [ha_dr_provider_chksrv]
      provider = ChkSrv
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 2
      action_on_lost = kill
      
      [trace]
      ha_dr_saphanasr = info
      ha_dr_chksrv = info
      

   При указании параметра path в расположение по умолчанию /usr/share/SAPHanaSR/srHook код хуков Python обновляется автоматически через обновления ОС или пакетов. HANA использует обновления кода хуков при следующем перезапуске. При необходимости указания собственного пути, например /hana/shared/myHooks, можно отделить обновления ОС от версии перехватчика, которую будет использовать HANA.

   Поведение перехватчика ChkSrv можно изменить при помощи параметра action_on_lost. Допустимые значения : [ ignore | stop | kill ].

3. [A] Кластеру требуется sudoers конфигурация на каждом узле кластера для <sid>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
   

4. [A] Запустите SAP HANA на обоих узлах. Запустите приложение от имени <sid>adm.

   sapcontrol -nr 03 -function StartSystem 
   

5. [1] Проверьте установку крючка SRHanaSR. Выполните приведенные команды с правами пользователя <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
   

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

    cdtrace
    tail -20 nameserver_chksrv.trc
   

Для получения дополнительных сведений о реализации перехватчиков SAP HANA см. разделы Включение перехватчика SAP HANA srConnectionChanged() и Включение перехватчика SAP HANA srServiceStateChanged() для действия сбоя процесса hdbindexserver (необязательно).

Создание ресурсов кластера 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 или более поздних версий), необходимо выполнить следующие команды.

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

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

Используйте команду 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 SPS 01, SAP поддерживает активные/чтение-ориентированные настройки в SAP HANA System Replication, где вторичные системы репликации SAP HANA могут активно использоваться для рабочих нагрузок с интенсивным чтением.

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

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

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

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

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

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

   a. Создайте второй пул внешних IP-адресов:

   • Откройте подсистему балансировки нагрузки, выберите пул интерфейсных IP-адресов и щелкните Добавить.
   • Введите имя нового пула интерфейсных IP-адресов (например, hana-frontend).
   • Установите Назначение на статическое и введите IP-адрес (например, 10.0.0.14).
   • Нажмите ОК.
   • Когда пул интерфейсных IP-адресов будет создан, запишите его IP-адрес.

   b. Создайте зонд проверки состояния:

   • Откройте балансировщик нагрузки, выберите Зонды работоспособности и щелкните Добавить.
   • Введите имя нового зонда работоспособности (например, hana-secondaryhp).
   • Выберите протокол TCP и порт 62603. Сохраните значение интервала равным 5 и значение порогового значения для неработоспособности равным 2.
   • Нажмите ОК.

   с. Создайте правила балансировки нагрузки:

   • Откройте подсистему балансировки нагрузки, выберите Правила балансировки нагрузки щелкните Добавить.
   • Введите имя нового правила балансировки нагрузки (например, hana-secondarylb).
   • Выберите интерфейсный пул IP-адресов, серверный пул и зонд работоспособности, который вы создали ранее (например, hana-secondaryIP, hana-backend и hana-secondaryhp).
   • Выберите Порты высокой доступности.
   • Не забудьте включить плавающий IP-адрес.
   • Нажмите ОК.

Настройка репликации системы HANA с активным/читаемым доступом.

Действия по настройке репликации системы HANA описаны в разделе "Настройка репликации системы SAP HANA 2.0". Если при настройке репликации системы на втором узле развертывается дополнительный сценарий с поддержкой чтения, выполните следующую команду как 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

# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5

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, настроенного с поддержкой чтения вторичного.

1. При переносе ресурса кластера SAPHana_HN1_03 на вторичный сайт hn1-db-1 второй виртуальный IP-адрес продолжает работать на том же сайте hn1-db-1. Если вы установили AUTOMATED_REGISTER="true" для ресурса, и репликация системы HANA автоматически регистрируется на hn1-db-0, второй виртуальный IP также перемещается на hn1-db-0.

2. При тестировании сбоя сервера второй виртуальный IP-ресурс (secvip_HN1_03) и ресурс порта Azure Load Balancer (secnc_HN1_03) выполняются на основном сервере вместе с основными виртуальными IP-ресурсами. Таким образом, до тех пор, пока сервер-получатель не будет отключен, приложения, подключенные к базе данных HANA с поддержкой чтения, подключаются к основной базе данных HANA. Ожидаемое поведение связано с тем, что вы не хотите, чтобы приложения, подключенные к базе данных HANA с поддержкой чтения, были недоступны в то время, когда вторичный сервер недоступен.

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

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

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

В этом разделе описано, как проверить настроенную систему. Перед началом теста убедитесь, что в Pacemaker нет неудачных действий (через команду pcs status), нет неожиданных ограничений местоположения (например, оставшихся элементов теста миграции), и что 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

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

pcs resource clear SAPHana_HN1_03-master

Отслеживайте состояние ресурса HANA с помощью pcs status. После запуска HANA на 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-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

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

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

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

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

После повторного запуска виртуальной машины ресурс 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 в качестве вторичного, выполнив следующую команду от имени пользователя root:

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

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

• Планирование и реализация виртуальных машин Azure для SAP
• Развертывание виртуальных машин Azure для SAP
• Развертывание СУБД на виртуальных машинах Azure для SAP
• Конфигурации хранилища виртуальных машин SAP HANA