Высокий уровень доступности SAP HANA на виртуальных машинах Azure на SUSE Linux Enterprise Server

Чтобы установить высокий уровень доступности в локальном развертывании SAP HANA, можно использовать репликацию системы SAP HANA или общее хранилище.

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

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

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

Перед началом работы ознакомьтесь со следующими заметками и документами SAP:

• Заметка SAP 1928533. Примечание включает в себя следующее:
  • список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
  • важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
  • Поддерживаемые сочетания программного обеспечения SAP, операционной системы (ОС) и базы данных.
  • Необходимые версии ядра SAP для Windows и Linux в Microsoft Azure.
• Примечание к SAP № 2015553 перечисляет предварительные требования для развертывания поддерживаемого SAP программного обеспечения SAP в Azure.
• Примечание SAP 2205917 содержит рекомендуемые параметры ОС для SUSE Linux Enterprise Server 12 (SLES 12) для приложений SAP.
• Примечание SAP 2684254 содержит рекомендуемые параметры ОС для SUSE Linux Enterprise Server 15 (SLES 15) для приложений SAP.
• Sap Note 2235581 поддерживает операционные системы SAP HANA.
• Примечание SAP 2178632 содержит подробные сведения обо всех метрик мониторинга, сообщающихся для SAP в Azure.
• Примечание SAP 2191498 имеет необходимую версию агента узла SAP для Linux в Azure.
• Примечание SAP 2243692 содержит сведения о лицензировании SAP для Linux в Azure.
• примечание к SAP 1984787, содержащее общие сведения о SUSE Linux Enterprise Server 12;
• SAP Примечание 1999351 содержит больше информации по устранению неполадок, связанных с расширением Azure Enhanced Monitoring для SAP.
• Примечание SAP 401162 содержит сведения о том, как избежать ошибок "адрес уже используется" при настройке репликации системы HANA.
• Вики-сайт поддержки сообщества SAP содержит все необходимые заметки SAP для Linux.
• Платформы IaaS с сертификатом SAP HANA.
• Руководство по планированию и внедрению виртуальных машин Azure для SAP на Linux
• Руководство по развертыванию виртуальных машин Azure для SAP на Linux.
• Руководство по развертыванию СУБД для SAP на виртуальных машинах Azure с Linux
• Рекомендации по использованию SUSE Linux Enterprise Server для приложений SAP 15 и рекомендации по SUSE Linux Enterprise Server для приложений SAP 12:
  • Настройка оптимизированной для производительности SAP HANA SR инфраструктуры (SLES для приложений SAP). В руководстве содержатся все необходимые сведения для настройки репликации системы SAP HANA для локальной разработки. Используйте это руководство как основу.
  • Настройка оптимизированной для затрат инфраструктуры SAP HANA SR (SLES для приложений SAP).

План для высокой доступности SAP HANA

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

Настройка репликации системы SAP HANA использует выделенное имя виртуального узла и виртуальные IP-адреса. В Azure требуется подсистема балансировки нагрузки для развертывания виртуального IP-адреса.

На предыдущем рисунке показан пример подсистемы балансировки нагрузки с этими конфигурациями:

• Внешний IP-адрес: 10.0.0.13 для HN1-db
• Порт пробы: 62503

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

Агент ресурсов для SAP HANA включен в состав SUSE Linux Enterprise Server for SAP Applications. Образ SUSE Linux Enterprise Server для приложений SAP 12 или 15 доступен в Azure Marketplace. Образ можно использовать для развертывания новых виртуальных машин.

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

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

Развертывание виртуальных машин для SAP HANA. Выберите подходящий образ SLES, поддерживаемый для системы 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.

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

Выполните действия, описанные в разделе "Настройка Pacemaker на SUSE Linux Enterprise Server в Azure ", чтобы создать базовый кластер Pacemaker для этого сервера HANA. Также вы можете применить один кластер Pacemaker для SAP HANA и SAP NetWeaver (A)SCS.

Установка SAP HANA

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

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

Замените <placeholders> значениями, соответствующими вашей установке SAP HANA.

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

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

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

      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
      

   2. Создайте физические тома для всех дисков, которые вы хотите использовать:

      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
      

   3. Создайте группу томов для файлов данных. Используйте одну группу томов для файлов журналов и одной группы томов для общего каталога SAP HANA:

      sudo vgcreate vg_hana_data_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
      sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
      sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3
      

   4. Создайте логические тома.

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

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

      Внимание

      При использовании нескольких физических томов для каждого тома данных, тома журнала или общего тома используйте -i коммутатор и задайте для него количество базовых физических томов. При создании тома с полосами используйте переключатель -I, чтобы указать размер полосы.

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

      sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
      sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
      sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
      sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
      

   5. Создайте каталоги монтирования и скопируйте универсальный уникальный идентификатор (UUID) всех логических томов.

      sudo mkdir -p /hana/data/<HANA SID>
      sudo mkdir -p /hana/log/<HANA SID>
      sudo mkdir -p /hana/shared/<HANA SID>
      # Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
      sudo blkid
      

   6. Измените /etc/fstab файл, чтобы добавить fstab записи для трех логических томов.

      sudo vi /etc/fstab
      

   7. Вставьте следующие строки в файл /etc/fstab :

      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2
      

   8. Подключите новые тома:

      sudo mount -a
      

2. [A] Настройте разметку диска с помощью обычных дисков.

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

   1. Создайте раздел на /dev/disk/azure/scsi1/lun0 и отформатируйте его с помощью XFS:

      sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
      sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1
      
      # Write down the ID of /dev/disk/azure/scsi1/lun0-part1
      sudo /sbin/blkid
      sudo vi /etc/fstab
      

   2. Вставьте следующую строку в файл /etc/fstab:

      /dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
      

   3. Создайте целевой каталог и подключите диск:

      sudo mkdir /hana
      sudo mount -a
      

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

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

   1. Измените файл /etc/hosts :

      sudo vi /etc/hosts
      

   2. Вставьте следующие строки в файл /etc/hosts . Измените IP-адреса и имена узлов в соответствии с вашей средой.

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

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

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

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

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

Замените <placeholders> значениями, соответствующими вашей установке SAP HANA.

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

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

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

   hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
   

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

   Во-первых, создайте резервную копию баз данных в качестве <HANA SID>adm:

   hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')"
   hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')"
   hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"
   

   Затем скопируйте файлы инфраструктуры открытых ключей системы (PKI) на дополнительный сайт:

   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/
   

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

   hdbnsutil -sr_enable --name=<site 1>
   

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

   Зарегистрируйте второй узел, чтобы запустить репликацию системы.

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

   sapcontrol -nr <instance number> -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
   

Реализация агентов ресурсов HANA

SUSE предоставляет два различных пакета программного обеспечения для агента ресурсов Pacemaker для управления SAP HANA. Пакеты программного обеспечения SAPHanaSR и SAPHanaSR-angi используют немного другой синтаксис и параметры и несовместимы. См. заметки о выпуске SUSE и документацию для подробностей и различий между SAPHanaSR и SAPHanaSR-angi. В этом документе рассматриваются оба пакета на отдельных вкладках в соответствующих разделах.

1. [A] Установите пакеты высокого уровня доступности SAP HANA.

sudo zypper install SAPHanaSR

sudo zypper install SAPHanaSR-angi

Настройка поставщиков SAP HANA HA/DR

Поставщики SAP HANA HA/DR оптимизируют интеграцию с кластером и повышают эффективность обнаружения, когда требуется отказа кластера. Основной скрипт-инструмент — SAPHanaSR (для пакета SAPHanaSR) / susHanaSR (для SAPHanaSR-angi). Настоятельно рекомендуется настроить Python-хук SAPHanaSR/susHanaSR. Для HANA 2.0 SPS 05 и более поздних версий мы рекомендуем реализовать как SAPHanaSR/susHanaSR, так и хуки susChkSrv.

Перехватчик susChkSrv расширяет функциональные возможности основного поставщика SAPHanaSR/susHanaSR HA. Он действует, когда процесс HANA аварийно завершает работу hdbindexserver. Если один процесс завершается сбоем, HANA обычно пытается перезапустить его. Перезапуск процесса indexserver может занять много времени, в течение которого база данных HANA не реагирует.

При реализации susChkSrv выполняется немедленное и настраиваемое действие. Действие инициирует переход на резервную систему в течение настроенного тайм-аута вместо ожидания перезапуска процесса hdbindexserver на том же узле.

1. [A] Остановите HANA на обоих узлах.

Выполните следующий код как <sap-sid>adm:

sapcontrol -nr <instance number> -function StopSystem

2. [A] Установите хуки репликации системы HANA. Хуки должны быть установлены на обоих узлах базы данных HANA.

   Совет

   Реализация перехватчика SAPHanaSR на Python возможна только для HANA 2.0. Пакет SAPHanaSR должен иметь по крайней мере версию 0.153.
   Хук Python SAPHanaSR-angi можно реализовать только для HANA 2.0 SPS 05 и более поздних версий.
   Для перехватчика Python susChkSrv требуется установка SAP HANA 2.0 SPS 05, а также нужно установить SAPHanaSR версии 0.161.1_BF или более поздней.

   • SAPHanaSR
   • SAPHanaSR-angi

   1. [A] Настройте global.ini на каждом узле кластера.

      Если требования к перехватчику susChkSrv не выполнены, удалите весь блок [ha_dr_provider_suschksrv] из следующих параметров. Поведение susChkSrv можно настроить с помощью action_on_lost параметра. Допустимые значения : [ ignore | stop | kill | fence].

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR
      execution_order = 3
      action_on_lost = fence
      
      [trace]
      ha_dr_saphanasr = info
      

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

   2. [A] Кластер требует настройки sudoers на каждом узле кластера для <sap-sid>adm. В этом примере это достигается путем создания нового файла.

      Выполните следующую команду от имени привилегированного пользователя. Замените <sid> на системный идентификатор SAP в нижнем регистре, <SID> на системный идентификатор SAP в верхнем регистре и <siteA/B> на выбранные имена сайтов HANA.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for SAPHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE    = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

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

3. [A] Запустите SAP HANA на обоих узлах. Выполните следующую команду как <sap-sid>adm:

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] проверьте установку крюка. Выполните следующую команду от имени <sap-sid>adm на активном узле репликации системы HANA.

   • SAPHanaSR
   • SAPHanaSR-angi

   cdtrace
   awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
   { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
   # Example output
   # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK
   

5. [1] Проверьте установку хука susChkSrv. Выполните следующую команду от имени пользователя <sap-sid>adm на виртуальных машинах SAP HANA:

   cdtrace
   egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
   # Example output
   # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
   # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
   # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)
   

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

1. [1] Сначала создайте ресурс топологии HANA.

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  op monitor interval="50" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

2. [1] Далее создайте ресурсы HANA:

# Replace <placeholders> with your instance number and HANA system ID.

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

# Run the following command if the cluster nodes are running on SLES 12 SP05.
sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true" promotable="true"

sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaCon_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop  interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op demote  interval="0" timeout="320"  \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  meta priority=100

sudo crm configure clone mst_SAPHanaCon_<HANA SID>_HDB<instance number> rsc_SAPHanaCon_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true" promotable="true"

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaFil_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFil_<HANA SID>_HDB<instance number> rsc_SAPHanaFil_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

3. [1] Продолжайте использовать ресурсы кластера для виртуальных IP-адресов, значений по умолчанию и ограничений.

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  msl_SAPHana_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Promoted  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHanaCon_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

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

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

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

В SAP HANA 2.0 SPS 01 и более поздних версиях SAP позволяет настроить активную/чтение-готовую настройку для репликации системы SAP HANA. В этом сценарии вторичные системы репликации системы SAP HANA можно активно использовать для рабочих нагрузок с интенсивным чтением.

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

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

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

Настройте балансировщик нагрузки для активной/с поддержкой чтения системной репликации

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

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

1. Создайте второй интерфейсный пул IP-адресов:
   1. Откройте подсистему балансировки нагрузки, выберите пул интерфейсных IP-адресов и щелкните Добавить.
   2. Введите имя нового пула интерфейсных IP-адресов (например, hana-frontend).
   3. Для параметра Назначение выберите значение Статическое и введите IP-адрес (например, 10.0.0.14).
   4. Нажмите ОК.
   5. После создания нового внешнего пула IP-адресов обратите внимание на внешний IP-адрес.
2. Создайте пробу работоспособности:
   1. В подсистеме балансировки нагрузки выберите пробы работоспособности и нажмите кнопку "Добавить".
   2. Введите имя новой проверки состояния (например, hana-secondaryhp).
   3. Выберите TCP в качестве протокола и порт < номер экземпляра>. Сохраните значение Интервала равным 5, а значение неработоспособного порога равным 2.
   4. Нажмите ОК.
3. Создайте правила балансировки нагрузки:
   1. В подсистеме балансировки нагрузки выберите правила балансировки нагрузки и нажмите кнопку "Добавить".
   2. Введите имя нового правила балансировки нагрузки (например, hana-secondarylb).
   3. Выберите интерфейсный пул IP-адресов, серверный пул и зонд работоспособности, который вы создали ранее (например, hana-secondaryIP, hana-backend и hana-secondaryhp).
   4. Выберите Порты высокой доступности.
   5. Увеличьте время ожидания простоя до 30 минут.
   6. Убедитесь, что вы включите плавающий IP-адрес.
   7. Нажмите ОК.

Настройка репликации системы с активным и читаемым режимом HANA

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

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess 

Добавление ресурса вторичного виртуального IP-адреса

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

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Unpromoted 

crm configure property maintenance-mode=false

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

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

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

Рекомендации при тестировании кластера HANA, настроенного с поддержкой чтения на вторичном узле:

• При миграции ресурса кластера SAPHana_<HANA SID>_HDB<instance number> на hn1-db-1 второй виртуальный IP-адрес перемещается на hn1-db-0. Если вы настроили AUTOMATED_REGISTER="false", и системная репликация HANA не зарегистрирована автоматически, второй виртуальный IP-адрес выполняется на hn1-db-0, так как сервер доступен и службы кластеров находятся в сети.

• При проверке сбоя сервера второй виртуальный IP-ресурс (rsc_secip_<HANA SID>_HDB<instance number>) и ресурсrsc_secnc_<HANA SID>_HDB<instance number> порта подсистемы балансировки нагрузки Azure выполняются на основном сервере вместе с основными виртуальными IP-ресурсами. Пока сервер-получатель отключен, приложения, подключенные к базе данных HANA с поддержкой чтения, подключаются к базе данных-источнику HANA. Это поведение ожидается, так как вы не хотите, чтобы приложения, подключенные к базе данных HANA с поддержкой чтения, были недоступны, пока сервер-получатель недоступен.

• Если вторичный сервер доступен и службы кластера находятся в сети, второй виртуальный IP-адрес и портовые ресурсы автоматически перемещаются на вторичный сервер, даже если репликация системы HANA может не быть зарегистрирована как вторичная. Перед запуском служб кластеров на этом сервере следует зарегистрировать вторичную базу данных HANA с доступом только для чтения. Вы можете настроить ресурс кластера экземпляра HANA, чтобы автоматически зарегистрировать вторичный узел, задав параметр AUTOMATED_REGISTER="true".

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

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

В этом разделе описано, как проверить настроенную систему. Каждый тест предполагает, что вы вошли в систему как пользователь root и что главный сервер SAP HANA выполняется на виртуальной машине hn1-db-0.

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

Прежде чем начать тест, убедитесь, что в Pacemaker нет неудачных действий (выполните команду crm_mon -r), что не существует неожиданных ограничений расположения (например, остатков теста миграции), и что HANA находится в состоянии синхронизации, например, путем выполнения команды SAPHanaSR-showAttr.

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

hn1-db-0:~ # SAPHanaSR-showAttr
Global cib-update dcid prim      sec sid topology
--------------------------------------------------
global 0.130728.2 1    SITE1 -   HN1 ScaleUp

Resource                      promotable
-----------------------------------------
mst_SAPHanaCon_HN1_HDB03      true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns      opMode    srHook srMode srPoll srr
-----------------------------------------------------------------------
SITE1       1722604101 4   hn1-db-0 logreplay PRIM   sync   PRIM   P
SITE2       30         4   hn1-db-1 logreplay SWAIT  sync   SOK    S

Host     clone_state roles                        score site    sra srah version     vhost
---------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1   -   -    2.00.074.00 hn1-db-0
hn1-db-1 DEMOTED     master1:master:worker:master 100   SITE2       -    2.00.074.00 hn1-db-1

Host     clone_state roles                        score site      sra srah version     vhost
------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1     -   -    2.00.074.00 hn1-db-0
hn1-db-1                                                SITE2                          hn1-db-1

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

crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force

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

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

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

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

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

При миграции создаются дополнительные ограничения расположения, которые следует удалить:

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>

Очистите также состояние ресурса на вторичном узле:

hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

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

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

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

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

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      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

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

При настройке устройства ограждения рекомендуется настроить параметр pcmk_delay_max. Таким образом, в случае сценария разделённого мозга кластер вводит случайную задержку, до значения pcmk_delay_max в процедуру ограждения на каждом узле. Узел с самой короткой задержкой будет выбран для ограждения.

Кроме того, чтобы узел, на котором работает главный узел HANA, имел приоритет и выигрывал аварийный барьер в сценарии расщепления мозга, рекомендуется задать priority-fencing-delay свойство в конфигурации кластера. Включив свойство 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

Тестирование ограждения SBD

Вы можете проверить настройку SBD, завершив процесс инквизитора.

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

Узел <HANA SID>-db-<database 1> кластера перезагружается. Служба Pacemaker может не перезапуститься. Убедитесь, что вы снова запустите его.

Тестирование ручного переключения

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

service pacemaker stop

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

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

service pacemaker start
su - <hana sid>adm

# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> 

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Тесты SUSE

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

Следующие тесты являются копией описаний тестов из руководства по сценарию оптимизации производительности SAP HANA SR на сервере SUSE Linux Enterprise Server для приложений SAP версии 12 с пакетом обновлений 1 (SP1). Для актуальной версии также ознакомьтесь с самим руководством. Всегда убедитесь, что HANA синхронизирована перед началом теста и убедитесь, что конфигурация Pacemaker правильна.

В следующих описаниях тестов предполагается PREFER_SITE_TAKEOVER="true" и AUTOMATED_REGISTER="false".

1. Тест 1. Остановка базы данных-источника на узле 1.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды от имени <hana sid>adm на hn1-db-0 узле:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop
   

   Pacemaker обнаруживает остановленный экземпляр HANA и переключается на другой узел. После завершения отработки отказа экземпляр HANA на узле hn1-db-0 останавливается, так как Pacemaker не регистрирует узел в качестве вторичного HANA автоматически.

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

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

2. Тест 2. Остановка базы данных-источника на узле 2.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Выполните следующие команды, как <hana sid>adm на hn1-db-1 узле:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stop
   

   Pacemaker обнаруживает остановленный экземпляр HANA и переключается на другой узел. После завершения отработки отказа экземпляр HANA на узле hn1-db-1 останавливается, так как Pacemaker не регистрирует узел в качестве вторичного HANA автоматически.

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

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

3. Тест 3. Сбой базы данных-источника на узле 1.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды, как <hana sid>adm на hn1-db-0 узле:

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker обнаруживает отключенный экземпляр HANA и переключается на другой узел. После завершения отработки отказа экземпляр HANA на узле hn1-db-0 останавливается, так как Pacemaker не регистрирует узел в качестве вторичного HANA автоматически.

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

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

4. Тест 4. Сбой базы данных-источника на узле 2.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Выполните следующие команды, как <hana sid>adm на hn1-db-1 узле:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker обнаруживает отключенный экземпляр HANA и переключается на другой узел. После завершения отработки отказа экземпляр HANA на узле hn1-db-1 останавливается, так как Pacemaker не регистрирует узел в качестве вторичного HANA автоматически.

   Выполните следующие команды, чтобы зарегистрировать узел hn1-db-1 в качестве вторичного и очистить неисправный ресурс.

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

5. Тест 5. Сбой первичного узла сайта (узел 1).

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды от имени пользователя root на узле hn1-db-0:

   hn1-db-0:~ #  echo 'b' > /proc/sysrq-trigger
   

   Pacemaker обнаруживает вышедший из строя узел кластера и изолирует его. Когда узел изолирован, Pacemaker активирует передачу управления экземпляром HANA. Когда ограниченный узел перезагружается, Pacemaker не запускается автоматически.

   Выполните следующие команды, чтобы запустить Pacemaker, очистить сообщения SBD для узла hn1-db-0, зарегистрировать узел hn1-db-0 в качестве дополнительного, и очистить неудачный ресурс.

   # run as root
   # list the SBD device(s)
   hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear
   
   hn1-db-0:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

6. Тест 6. Сбой вторичного узла сайта (узел 2).

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Выполните следующие команды от имени пользователя root на узле hn1-db-1:

   hn1-db-1:~ #  echo 'b' > /proc/sysrq-trigger
   

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

   Выполните следующие команды, чтобы запустить Pacemaker, очистить сообщения SBD для узла hn1-db-1, зарегистрировать узел hn1-db-1 в качестве дополнительного, и очистить неудачный ресурс.

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   </code></pre>
   

7. Тест 7: Остановите вторичную базу данных на узле 2.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды, как <hana sid>adm на hn1-db-1 узле:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop
   

   Pacemaker обнаруживает остановленный экземпляр HANA и отмечает ресурс как сбойный на hn1-db-1 узле. Pacemaker автоматически перезапускает экземпляр HANA.

   Для устранения ошибки выполните следующую команду:

   # run as root
   hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

8. Тест 8: Вызвать сбой вторичной базы данных на узле 2.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды, как <hana sid>adm на hn1-db-1 узле:

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker обнаруживает убитый экземпляр HANA и помечает ресурс как неудачный на hn1-db-1 узле. Выполните следующую команду, чтобы очистить неисправное состояние. Pacemaker автоматически перезапускает экземпляр HANA.

   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

9. Тест 9: Проведите аварию узла вторичного сайта (узел 2), на котором выполняется вторичная база данных HANA.

   Состояние ресурса перед началом теста:

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Выполните следующие команды от имени пользователя root на узле hn1-db-1:

   hn1-db-1:~ # echo b > /proc/sysrq-trigger
   

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

   Выполните следующие команды, чтобы запустить Pacemaker, очистить сообщения SBD для hn1-db-1 узла и очистить неудачный ресурс:

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker  
   
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

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

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

10. Тест 10: Сбой основного сервера базы данных indexserver

    Этот тест актуален только в случае, если вы настроили перехватчик susChkSrv, как указано в разделе «Реализация агентов ресурсов HANA».

    Состояние ресурса перед началом теста:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    

    Выполните следующие команды от имени пользователя root на узле hn1-db-0:

    hn1-db-0:~ # killall -9 hdbindexserver
    

    После завершения indexserver хук susChkSrv обнаруживает событие и активирует действие, чтобы изолировать узел hn1-db-0 и инициировать процесс взятия на себя.

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

    # run as <hana sid>adm
    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
    

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

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    

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

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

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