Высокая доступность масштабируемой системы SAP HANA на Red Hat Enterprise Linux

В этой статье описывается, как развернуть высокодоступную систему SAP HANA в конфигурации с горизонтальным масштабированием. В частности, в конфигурации используется репликация системы HANA (HSR) и Pacemaker на виртуальных машинах Azure Red Hat Enterprise Linux. Общие файловые системы в представленной архитектуре смонтированы с помощью NFS и предоставляются с помощью Azure NetApp Files или NFS-ресурса на Azure Files.

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

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

• Заметка SAP 1928533 включает:
  • список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
  • важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
  • сведения о поддерживаемом программном обеспечении SAP и сочетаниях операционных систем (ОС) и баз данных;
  • сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
• Примечание SAP 2015553: перечисляет предварительные требования для развертывания программного обеспечения SAP в Azure, поддерживаемого SAP.
• Примечание SAP [2002167], содержащее рекомендуемые параметры ОС для RHEL.
• Примечание SAP 2009879, содержащее рекомендации по SAP HANA для RHEL.
• Примечание 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 1900823, в котором содержатся сведения о требованиях к хранилищу SAP HANA.
• Вики-сайт сообщества SAP, который содержит все необходимые примечания SAP для Linux.
• Планирование и внедрение Azure Virtual Machines для SAP на Linux
• Развертывание программного обеспечения SAP на виртуальных машинах Linux в Azure
• Развертывание СУБД на виртуальных машинах Azure для SAP на Linux
• Требования к сети SAP HANA.
• Общая документация по RHEL:
  • Обзор модуля высокой доступности
  • Администрирование надстройки для обеспечения высокой доступности
  • Справочник по надстройке для обеспечения высокой доступности
  • Руководство по сетям Red Hat Enterprise Linux.
  • Как настроить репликацию системы SAP HANA с масштабированием в кластере Pacemaker, если файловые системы HANA находятся на общих ресурсах NFS?
  • Активный/активный (с поддержкой чтения): решение RHEL HA для горизонтального увеличения масштаба и репликации системы SAP HANA.
• Документация по RHEL для конкретной службы Azure:
  • Установка SAP HANA в Red Hat Enterprise Linux для использования в Microsoft Azure
  • Решение Red Hat Enterprise Linux для SAP HANA с функцией масштабируемости и репликации системы.
• Документация по Azure NetApp Files
• Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA.
• Документация по Файлам Azure

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

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

Общие файловые системы HANA /hana/shared в представленной архитектуре могут предоставляться службой Azure NetApp Files или общей папкой NFS в Файлах Azure. Общая файловая система HANA монтирована в NFS на каждом узле HANA в одной и той же локальной сети репликации системы HANA. Файловые системы /hana/data и /hana/log являются локальными файловыми системами и не разделяются между узлами HANA DB. Экземпляр SAP HANA будет установлен в режиме без общего доступа.

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

На предыдущей схеме, которая соответствует рекомендациям по сети для SAP HANA, в одной виртуальной сети Azure представлены три подсети:

• client 10.23.0.0/24 — для связи с клиентами;
• inter 10.23.1.128/26 — для обмена данными между узлами SAP HANA;
• hsr 10.23.1.192/26 — для репликации системы HANA.

Поскольку /hana/data и /hana/log развертываются на локальных дисках, развертывать отдельную подсеть и отдельные виртуальные сетевые адаптеры для связи с хранилищем нет необходимости.

Если вы используете Azure NetApp Files, тома NFS для /hana/shared развертываются в отдельной подсети, подпоряжённой Azure NetApp Files: anf 10.23.1.0/26.

В следующих инструкциях предполагается, что вы уже создали группу ресурсов, виртуальную сеть Azure и три подсети виртуальной сети Azure: client, inter и hsr.

1. Разверните виртуальные машины Azure. Для этой конфигурации разверните семь виртуальных машин:

   • три виртуальных машины для узлов базы данных HANA на сайте репликации HANA 1: hana-s1-db1, hana-s1-db2 и hana-s1-db3;
   • три виртуальных машины для узлов базы данных HANA на сайте репликации HANA 2: hana-s2-db1, hana-s2-db2 и hana-s2-db3;
   • небольшую виртуальную машину, которая будет служить для формирования большинства: hana-s-mm.

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

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

   Разверните локальные управляемые диски для /hana/data и /hana/log. Минимальная рекомендуемая конфигурация хранилища для /hana/data и /hana/log описана в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure.

   Разверните основной сетевой интерфейс для каждой виртуальной машины в подсети client виртуальной сети. При развертывании виртуальной машины с помощью портала Azure имя сетевого интерфейса создается автоматически. В этой статьи мы будем называть автоматически создаваемые основные сетевые интерфейсы следующим образом: hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client и т. д. Эти сетевые интерфейсы подключены к подсети виртуальной сети Azure client.

   Важно!

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

2. Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных HANA, в подсети inter виртуальной сети (в этом примере это hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter и hana-s2-db3-inter).

3. Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных HANA, в подсети hsr виртуальной сети (в этом примере это hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr и hana-s2-db3-hsr).

4. Подключите созданные виртуальные сетевые интерфейсы к соответствующим виртуальным машинам, выполнив следующие действия.

   1. Перейдите к виртуальной машине на портале Azure.
   2. В области слева выберите Виртуальные машины. Выполните фильтрацию по имени виртуальной машины (например, hana-s1-db1), а затем выберите виртуальную машину.
   3. В области Обзор выберите Остановить, чтобы освободить виртуальную машину.
   4. Выберите Сеть, а затем подключите сетевой интерфейс. Из раскрывающегося списка Подключение сетевого интерфейса выберите уже созданные сетевые интерфейсы для подсетей inter и hsr.
   5. Выберите Сохранить.
   6. Повторите шаги b через e для оставшихся виртуальных машин (в нашем примере hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 и hana-s2-db3)
   7. Пока оставьте виртуальные машины в остановленном состоянии.

5. Включите ускорение сети для дополнительных сетевых интерфейсов для подсетей inter и hsr, выполнив указанные ниже действия.

   1. Откройте Azure Cloud Shell на портале Azure.

   2. Выполните следующие команды, чтобы включить ускорение сети для дополнительных сетевых интерфейсов, подключенных к подсетям inter и hsr.

      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true
      
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true
      

6. Запуск виртуальных машин базы данных HANA

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

Существует два варианта развертывания нативного NFS в Azure для /hana/shared. Вы можете развернуть том NFS в Azure NetApp Files или общей папке NFS в Файлах Azure. Файлы Azure поддерживают протокол NFSv4.1, NFS в Azure NetApp files поддерживает как NFSv4.1, так и NFSv3.

В следующих разделах описаны шаги по развертыванию NFS. Вам нужно выбрать один из вариантов.

Разверните тома Azure NetApp Files для файловой системы /hana/shared. Вам потребуется отдельный том /hana/shared для каждой площадки репликации системы HANA. Дополнительные сведения см. в разделе Настройка инфраструктуры Azure NetApp Files.

В этом примере используются следующие тома Azure NetApp Files:

• том HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
• том HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2).

Разверните ресурсы общего доступа NFS в Azure Files для файловой системы /hana/shared. Вам потребуется отдельная NFS-ресурс Azure Files для каждого сайта репликации HANA-системы. Дополнительные сведения см. в разделе Как создать общую папку NFS.

В этом примере использовались следующие ресурсы NFS Azure Files:

• share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
• share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Инструкции в следующих разделах начинаются с одной из следующих аббревиатур:

• [A]: применимо ко всем узлам;
• [AH]: применимо ко всем узлам базы данных HANA;
• [M]: применимо к узлу-создателю большинства.
• [AH1]: применимо ко всем узлам базы данных HANA на сайте 1;
• [AH2]: применимо ко всем узлам базы данных HANA на сайте 2;
• [1]: применимо только к узлу 1 базы данных HANA на площадке SITE 1;
• [2]: применимо только к узлу базы данных HANA 1 на месте 2.

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

1. [A]: сохраните файлы узлов на виртуальных машинах. Включите в них записи для всех подсетей. Для этого примера в /etc/hosts были добавлены приведенные ниже записи.

   # Client subnet
   10.23.0.11 hana-s1-db1
   10.23.0.12 hana-s1-db1
   10.23.0.13 hana-s1-db2
   10.23.0.14 hana-s2-db1
   10.23.0.15 hana-s2-db2
   10.23.0.16 hana-s2-db3
   10.23.0.17 hana-s-mm
   # Internode subnet
   10.23.1.138 hana-s1-db1-inter
   10.23.1.139 hana-s1-db2-inter
   10.23.1.140 hana-s1-db3-inter
   10.23.1.141 hana-s2-db1-inter
   10.23.1.142 hana-s2-db2-inter
   10.23.1.143 hana-s2-db3-inter
   # HSR subnet
   10.23.1.202 hana-s1-db1-hsr
   10.23.1.203 hana-s1-db2-hsr
   10.23.1.204 hana-s1-db3-hsr
   10.23.1.205 hana-s2-db1-hsr
   10.23.1.206 hana-s2-db2-hsr
   10.23.1.207 hana-s2-db3-hsr
   

2. [A] Создайте файл конфигурации /etc/sysctl.d/ms-az.conf с параметрами конфигурации Microsoft для Azure.

   vi /etc/sysctl.d/ms-az.conf
   
   # Add the following entries in the configuration file
   
   net.ipv6.conf.all.disable_ipv6 = 1
   net.ipv4.tcp_max_syn_backlog = 16348
   net.ipv4.conf.all.rp_filter = 0
   sunrpc.tcp_slot_table_entries = 128
   vm.swappiness=10
   

   Совет

   Не следует явно задавать параметры net.ipv4.ip_local_port_range и net.ipv4.ip_local_reserved_ports в файлах конфигурации sysctl, чтобы разрешить агенту узла SAP управлять диапазонами портов. Дополнительные сведения см. в примечании к SAP 2382421.

3. [A]: установите пакет клиента NFS.

   yum install nfs-utils
   

4. [AH] Конфигурация Red Hat для HANA.

   Настройте RHEL, как описано на портале клиентов Red Hat и в следующих примечаниях SAP:

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

В следующих разделах приведены действия по подготовке файловых систем. Вы решили развернуть /hana/shared на ресурсе NFS на Azure Files или в ресурсе NFS на Azure NetApp Files.

В этом примере общие файловые системы HANA развертываются в Azure NetApp Files и монтируются посредством NFSv4.1. Выполните действия, описанные в этом разделе, только если вы используете NFS в Azure NetApp Files.

1. [AH] Подготовьте ОС для запуска SAP HANA в NetApp Systems с NFS, как описано в заметке SAP 3024346 — параметры ядра Linux для NetApp NFS. Создайте файл /etc/sysctl.d/91-NetApp-HANA.conf для параметров конфигурации NetApp.

   vi /etc/sysctl.d/91-NetApp-HANA.conf
   
   # Add the following entries in the configuration file
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.ipv4.tcp_rmem = 4096 131072 16777216
   net.ipv4.tcp_wmem = 4096 16384 16777216
   net.core.netdev_max_backlog = 300000
   net.ipv4.tcp_slow_start_after_idle=0
   net.ipv4.tcp_no_metrics_save = 1
   net.ipv4.tcp_moderate_rcvbuf = 1
   net.ipv4.tcp_window_scaling = 1
   net.ipv4.tcp_sack = 1
   

2. [AH] Настройте параметры sunrpc, как рекомендуется в примечании SAP 3024346 — параметры ядра Linux для NetApp NFS.

   vi /etc/modprobe.d/sunrpc.conf
   
   # Insert the following line
   options sunrpc tcp_max_slot_table_entries=128
   

3. [A]: создайте точки подключения для томов базы данных HANA.

   mkdir -p /hana/shared
   

4. [A]: проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, т. е. defaultv4iddomain.com, Убедитесь, что для сопоставления установлено значение nobody.
   Этот шаг необходим, если вы используете Azure NetApp Files версии NFS 4.1.

   Важно!

   Обязательно укажите домен NFS в /etc/idmapd.conf виртуальной машине в соответствии с конфигурацией домена по умолчанию в Azure NetApp Files: defaultv4iddomain.com. В случае несоответствия между конфигурацией домена на клиенте NFS и NFS-сервере разрешения для файлов на томах NetApp в Azure, подключенных к виртуальным машинам, будут отображаться как nobody.

   sudo cat /etc/idmapd.conf
   # Example
   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

5. [AH]: проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, в которой находится параметр nfs4_disable_idmapping, выполните команду mount. Вы не сможете вручную создать каталог в /sys/modules, так как доступ зарезервирован для ядра или драйверов.
   Этот шаг необходим, если используется служба Azure NetApp Files с NFSv4.1.

   # Check nfs4_disable_idmapping 
   cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   # If you need to set nfs4_disable_idmapping to Y
   mkdir /mnt/tmp
   mount 10.9.0.4:/HN1-shared /mnt/tmp
   umount  /mnt/tmp
   echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   # Make the configuration permanent
   echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   Дополнительные сведения о том, как изменить параметр nfs4_disable_idmapping, см. на портале клиентов Red Hat.

6. [AH1] Подключите общие тома Azure NetApp Files к виртуальным машинам базы данных HANA на SITE1.

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.23.1.7:/HN1-shared-s1 /hana/shared
   

7. [AH2] Подключите тома Azure NetApp Files общего доступа к виртуальным машинам базы данных HANA на SITE2.

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.23.1.7:/HN1-shared-s2 /hana/shared
   

8. [AH]: убедитесь, что соответствующие файловые системы /hana/shared/ подключены ко всем виртуальным машинам базы данных HANA с помощью протокола NFS версии NFS 4.

   sudo nfsstat -m
   # Verify that flag vers is set to 4.1 
   # Example from SITE 1, hana-s1-db1
   /hana/shared from 10.23.1.7:/HN1-shared-s1
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.11,local_lock=none,addr=10.23.1.7
   # Example from SITE 2, hana-s2-db1
   /hana/shared from 10.23.1.7:/HN1-shared-s2
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.14,local_lock=none,addr=10.23.1.7
   

В этом примере общие файловые системы HANA развертываются в NFS в Файлах Azure. Выполните действия, описанные в этом разделе, только если вы используете NFS в службе Azure Files.

1. [AH] Создайте точки подключения для томов базы данных HANA.

   mkdir -p /hana/shared
   

2. [AH1] подключите общие тома Azure NetApp Files к виртуальным машинам базы данных HANA на SITE1.

   sudo vi /etc/fstab
   # Add the following entry
   sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
   # Mount all volumes
   sudo mount -a 
   

3. [AH2] Монтируйте общие тома Azure NetApp Files на виртуальные машины базы данных HANA на SITE2.

   sudo vi /etc/fstab
   # Add the following entries
   sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
   # Mount the volume
   sudo mount -a 
   

4. [AH]: убедитесь, что соответствующие файловые системы /hana/shared/ подключены ко всем виртуальным машинам базы данных HANA с помощью протокола NFS версии NFS 4.1.

   sudo nfsstat -m
   # Example from SITE 1, hana-s1-db1
   sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
    Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
   # Example from SITE 2, hana-s2-db1
   sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
    Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35
   

В представленной конфигурации файловые системы /hana/data и /hana/log развертываются на управляемом диске и локально подключаются к каждой виртуальной машине базы данных HANA. Выполните указанные ниже действия по созданию локальных томов данных и журналов на каждой виртуальной машине базы данных HANA.

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

1. [AH]: выведите список всех доступных дисков.

   ls /dev/disk/azure/scsi1/lun*
   

   Пример результата:

   /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2 
   

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

   sudo pvcreate /dev/disk/azure/scsi1/lun0
   sudo pvcreate /dev/disk/azure/scsi1/lun1
   sudo pvcreate /dev/disk/azure/scsi1/lun2
   

3. [AH] Создайте группу томов для файлов данных. Используйте одну группу томов для файлов журналов и другую — для общей папки 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
   

4. [AH] Создайте логические тома. Линейный том создается при использовании lvcreate без переключателя -i. Мы предлагаем создать полосатый том для повышения производительности операций ввода-вывода. Согласуйте размеры полос с задокументированными значениями в Конфигурациях хранилища виртуальных машин SAP HANA. Аргумент -i должен обозначать число базовых физических томов, а аргумент -I — размер полосы. В этой статье для тома данных используется 2 физических тома, поэтому аргумент -i имеет значение 2. Размер полосы для тома данных равен 256 KiB. Для журналирования используется один физический том, поэтому нет необходимости задавать параметры -i и -I в командах для журнального тома.

   Важно!

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

   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 mkfs.xfs /dev/vg_hana_data_HN1/hana_data
   sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
   

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

   sudo mkdir -p /hana/data/HN1
   sudo mkdir -p /hana/log/HN1
   # Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
   sudo blkid
   

6. [AH] Создайте fstab записи для логических томов и монтируйте.

   sudo vi /etc/fstab
   

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

   /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
   /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2
   

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

   sudo mount -a
   

В этом примере для развертывания SAP HANA в масштабируемой конфигурации с HSR на виртуальных машинах Azure вы используете HANA 2.0 SP4.

1. [A]: перед установкой HANA задайте корневой пароль. После завершения установки можно будет отключить корневой пароль. Выполните команду root от имени passwd, чтобы задать пароль.

2. [1,2] Измените разрешения на /hana/shared.

   chmod 775 /hana/shared
   

3. [1] Убедитесь, что вы можете войти в hana-s1-db2 и hana-s1-db3 через безопасную оболочку (SSH) без запроса пароля. Если это не так, смените ключи ssh, как описано в разделе Использование проверки подлинности на основе ключей.

   ssh root@hana-s1-db2
   ssh root@hana-s1-db3
   

4. [2]: убедитесь, что можете войти с помощью протокола SSH на виртуальные машины базы данных HANA hana-s2-db2 и hana-s2-db3 без запроса пароля. Если это не так, смените ключи ssh, как описано в разделе Использование проверки подлинности на основе ключей.

   ssh root@hana-s2-db2
   ssh root@hana-s2-db3
   

5. [A]: установите дополнительные пакеты, необходимые для HANA 2.0 SP4. Дополнительные сведения см. в примечании SAP 2593824 для RHEL 7.

   # If using RHEL 7
   yum install libgcc_s1 libstdc++6 compat-sap-c++-7 libatomic1
   # If using RHEL 8
   yum install libatomic libtool-ltdl.x86_64
   

6. [A] Временно отключите брандмауэр, чтобы он не влиял на установку HANA. После завершения установки HANA его можно будет включить снова.

   # Execute as root
   systemctl stop firewalld
   systemctl disable firewalld
   

1. [1]: установите SAP HANA, следуя инструкциям из руководства по установке и обновлению SAP HANA 2.0. В приведенных ниже инструкциях мы опишем установку SAP HANA на первом узле сайта 1.

   1. Запустите программу hdblcm как root из каталога программного обеспечения установки HANA. Используйте параметр internal_network и передайте диапазон адресов подсети, используемой для обмена данными между узлами HANA.

      ./hdblcm --internal_network=10.23.1.128/26
      

   2. Когда появится приглашение, введите следующие значения:

      • На запрос Choose an action (Выберите действие): введите 1 (установка).
      • На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
      • Для пути установки нажмите Enter (путь по умолчанию — /hana/shared).
      • Для Local Host Name нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Желаете добавить узлы в систему? введите n.
      • На запрос SAP HANA System ID (Идентификатор системы SAP HANA): введите HN1.
      • Для Номер экземпляра [00] введите 03.
      • На запрос Local Host Worker Group [default] (Рабочая группа локального узла [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Select System Usage / Enter index [4] введите 4 (для пользовательских настроек).
      • На запрос Location of Data Volumes [/hana/data/HN1] (Расположение томов данных [/hana/data/HN1]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Location of Log Volumes [/hana/hata/HN1] (Расположение томов журналов [/hana/hata/HN1]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Restrict maximum memory allocation? [n] (Ограничить максимальное выделение памяти? [n]): введите n.
      • Для Certificate Host Name For Host hana-s1-db1 [hana-s1-db1] нажмите ВВОД, чтобы принять значение по умолчанию.
      • Для SAP Host Agent User (sapadm) Password введите пароль.
      • Введите пароль для Confirm SAP Host Agent User (sapadm) Password.
      • Введите пароль для System Administrator (hn1adm) Password.
      • Для домашнего каталога системного администратора [/usr/sap/HN1/home] нажмите ВВОД, чтобы принять значение по умолчанию.
      • На запрос System Administrator Login Shell [/bin/sh] (Оболочка для входа системного администратора [/bin/sh]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос System Administrator User ID [1001] (Идентификатор пользователя системного администратора [1001]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода Enter ID of User Group (sapsys) [79], нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Введите пароль системы для System Database User (system) Password (пароль пользователя системной базы данных (system)).
      • На запрос Confirm System Database User (system) Password (Подтвердите пароль пользователя системной базы данных (system)): еще раз введите пароль системы.
      • На запрос Restart system after machine reboot? (Перезапустить систему после перезагрузки компьютера?) [n]: введите n.
      • На запрос Do you want to continue (y/n)? (Продолжить (да или нет)?): проверьте сводку и, если все настроено правильно, введите y (Да).

2. [2]: повторите предыдущий шаг, чтобы установить SAP HANA на первом узле на сайте 2.

3. [1, 2]: проверьте файл global.ini.

   Откройте файл global.ini и убедитесь, что конфигурация внутреннего взаимодействия между узлами SAP HANA настроена. Проверьте раздел communication. В нем должен быть указан диапазон адресов для подсети inter, а параметр listeninterface должен иметь значение .internal. Проверьте раздел internal_hostname_resolution. Он должен содержать IP-адреса виртуальных машин HANA, принадлежащих к подсети inter.

     sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
     # Example from SITE1 
     [communication]
     internal_network = 10.23.1.128/26
     listeninterface = .internal
     [internal_hostname_resolution]
     10.23.1.138 = hana-s1-db1
     10.23.1.139 = hana-s1-db2
     10.23.1.140 = hana-s1-db3
   

4. [1, 2]: подготовьте global.ini к установке в среде без общего доступа, как описано в примечании SAP 2080991.

    sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
    [persistence]
    basepath_shared = no
   

5. [1, 2]: перезапустите SAP HANA, чтобы активировать изменения.

    sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
    sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem
   

6. [1, 2]: убедитесь, что интерфейс клиента будет использовать IP-адреса из подсети client для обмена данными.

   # Execute as hn1adm
   /usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
   # Expected result - example from SITE 2
   "hana-s2-db1","net_publicname","10.23.0.14"
   

   Сведения о том, как проверить конфигурацию, см. в примечании SAP 2183363 - Configuration of SAP HANA internal network (2183363: настройка внутренней сети SAP HANA).

7. [AH]: измените разрешения для каталогов данных и журналов, чтобы избежать ошибок установки HANA.

    sudo chmod o+w -R /hana/data /hana/log
   

8. [1]: установите дополнительные узлы HANA. Примеры инструкций на этом шаге приведены для сайта 1.

   1. Запустите резидентную hdblcm программу как root.

       cd /hana/shared/HN1/hdblcm
       ./hdblcm 
      

   2. На запросе введите следующие значения:

      • Для Choose an action введите 2 (чтобы добавить узлы).
      • На запрос Enter comma separated host names to add (Введите имена узлов с разделителями-запятыми): введите hana-s1-db2, hana-s1-db3.
      • На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
      • Нажмите Enter на запрос Enter Root User Name [root], чтобы принять значение по умолчанию.
      • На запрос Select roles for host 'hana-s1-db2' [1] (Выберите роли для узла hana-s1-db2 [1]): выберите 1 (рабочий узел).
      • На запрос Enter Host Failover Group for host 'hana-s1-db2' [default] (Введите группу отработки отказа для узла hana-s1-db2 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Enter Storage Partition Number for host 'hana-s1-db2' [<<assign automatically>>] (Введите номер раздела хранилища для узла hana-s1-db2 [<<автоматическое назначение>>]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Enter Worker Group for host 'hana-s1-db2' [default] (Введите группу рабочих узлов для узла hana-s1-db2 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Select roles for host 'hana-s1-db3' [1], выберите 1 (рабочий).
      • На запрос Enter Host Failover Group for host 'hana-s1-db3' [default] (Введите группу отработки отказа для узла hana-s1-db3 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Enter Storage Partition Number for host 'hana-s1-db3' [<<assign automatically>>] (Введите номер раздела хранилища для узла hana-s1-db3 [<<автоматическое назначение>>]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Enter Worker Group for host 'hana-s1-db3' [default] (Введите группу рабочих узлов для узла hana-s1-db3 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для System Administrator (hn1adm) Password введите пароль.
      • На запрос Enter SAP Host Agent User (sapadm) Password (Введите пароль пользователя SAP Host Agent (sapadm)): введите пароль.
      • Введите пароль для подтверждения пароля пользователя SAP Host Agent (sapadm).
      • На запрос Certificate Host Name For Host hana-s1-db2 (Имя узла сертификата для узла hana-s1-db2): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • На запрос Certificate Host Name For Host hana-s1-db3 [hana-s1-db3] нажмите Enter, чтобы принять значение по умолчанию.
      • На запрос Do you want to continue (y/n)? (Продолжить (да или нет)?): проверьте сводку и, если все настроено правильно, введите y (Да).

9. [2]: повторите предыдущий шаг, чтобы установить дополнительные узлы SAP HANA на сайте 2.

Следующие шаги помогут настроить репликацию системы:

1. [1] Настройте репликацию системы на Сайте 1.

   Выполните резервное копирование баз данных от имени пользователя hn1adm.

   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')"
   

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

   scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
   scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
   

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

   hdbnsutil -sr_enable --name=HANA_S1
   

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

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

   sapcontrol -nr 03 -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
   sapcontrol -nr 03 -function StartSystem
   

3. [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 |
   # | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
   # | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
   # | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | 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: HANA_S1
   

4. [1, 2]: измените конфигурацию HANA таким образом, чтобы данные репликации системы HANA направлялись через виртуальные сетевые интерфейсы репликации системы HANA.

   1. Остановите HANA на обоих сайтах.

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
      

   2. Измените файл global.ini, чтобы добавить сопоставление узлов для репликации системы HANA. Используйте IP-адреса из подсети hsr.

      sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
      #Add the section
      [system_replication_hostname_resolution]
      10.23.1.202 = hana-s1-db1
      10.23.1.203 = hana-s1-db2
      10.23.1.204 = hana-s1-db3
      10.23.1.205 = hana-s2-db1
      10.23.1.206 = hana-s2-db2
      10.23.1.207 = hana-s2-db3
      

   3. Запустите HANA на обоих сайтах.

       sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
      

   Дополнительные сведения см. в разделе Host Name Resolution for System Replication (Разрешение имен узлов для репликации системы).

5. [AH] Снова включите брандмауэр и откройте необходимые порты.

   1. Повторно включите брандмауэр.

      # Execute as root
      systemctl start firewalld
      systemctl enable firewalld
      

   2. Откройте необходимые порты брандмауэра. Необходимо будет настроить порты для вашего номера экземпляра HANA.

      Важно!

      Создайте правила брандмауэра, разрешающие передачу внутреннего трафика узлов HANA и трафика клиентов. Требуемые порты перечислены в разделе Порты TCP/IP для всех продуктов SAP. Следующие команды приведены исключительно в качестве примера. В этом сценарии используется система номер 03.

       # Execute as root
       sudo firewall-cmd --zone=public --add-port={30301,30303,30306,30307,30313,30315,30317,30340,30341,30342,1128,1129,40302,40301,40307,40303,40340,50313,50314,30310,30302}/tcp --permanent
       sudo firewall-cmd --zone=public --add-port={30301,30303,30306,30307,30313,30315,30317,30340,30341,30342,1128,1129,40302,40301,40307,40303,40340,50313,50314,30310,30302}/tcp
      

Чтобы создать базовый кластер Pacemaker, выполните действия по настройке Pacemaker в Red Hat Enterprise Linux в Azure. Добавьте в кластер все виртуальные машины, включая машину, ответственную за формирование большинства.

В следующей части этого процесса необходимо создать ресурсы файловой системы. Это делается следующим образом:

1. [1, 2] Остановите SAP HANA на обоих сайтах репликации. Выполните команду от имени <sid>adm.

   sapcontrol -nr 03 -function StopSystem
   

2. [AH]: отключите файловую систему /hana/shared, которая была временно подключена для установки на всех виртуальных машинах базы данных HANA. Перед ее отключением нужно остановить все процессы и сеансы, использующие эту файловую систему.

   umount /hana/shared 
   

3. [1]: создайте кластерные ресурсы файловой системы для /hana/shared в отключенном состоянии. Параметр --disabled используется потому, что необходимо определить ограничения расположения перед включением подключений.
   Вы решили развернуть /hana/shared в NFS-ресурсе на Файлы Azure или томе NFS в Azure NetApp Files.

   • В этом примере файловая система "/hana/shared" развернута на Azure NetApp Files и смонтирована по протоколу NFSv4.1. Выполните действия, описанные в этом разделе, только если вы используете NFS в Azure NetApp Files.

     # /hana/shared file system for site 1
     pcs resource create fs_hana_shared_s1 --disabled ocf:heartbeat:Filesystem device=10.23.1.7:/HN1-shared-s1  directory=/hana/shared \
     fstype=nfs options='defaults,rw,hard,timeo=600,rsize=262144,wsize=262144,proto=tcp,noatime,sec=sys,nfsvers=4.1,lock,_netdev' op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 \
     op start interval=0 timeout=120 op stop interval=0 timeout=120
     
     # /hana/shared file system for site 2
     pcs resource create fs_hana_shared_s2 --disabled ocf:heartbeat:Filesystem device=10.23.1.7:/HN1-shared-s1 directory=/hana/shared \
     fstype=nfs options='defaults,rw,hard,timeo=600,rsize=262144,wsize=262144,proto=tcp,noatime,sec=sys,nfsvers=4.1,lock,_netdev' op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 \
     op start interval=0 timeout=120 op stop interval=0 timeout=120
     
     # clone the /hana/shared file system resources for both site1 and site2
     pcs resource clone fs_hana_shared_s1 meta clone-node-max=1 interleave=true
     pcs resource clone fs_hana_shared_s2 meta clone-node-max=1 interleave=true
     
     

   Предлагаемые значения таймаутов позволяют ресурсам кластера выдерживать протокол-специфическую паузу, связанную с продлением аренды по NFSv4.1 в Azure NetApp Files. Дополнительные сведения см. в документе Рекомендации по использованию NFS в NetApp.

   • В этом примере файловая система "/hana/shared" развертывается на NFS на Azure Files. Выполните действия, описанные в этом разделе, только если вы используете NFS в Azure Files.

     # /hana/shared file system for site 1
     pcs resource create fs_hana_shared_s1 --disabled ocf:heartbeat:Filesystem device=sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1  directory=/hana/shared \
     fstype=nfs options='defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock' op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 \
     op start interval=0 timeout=120 op stop interval=0 timeout=120
     
     # /hana/shared file system for site 2
     pcs resource create fs_hana_shared_s2 --disabled ocf:heartbeat:Filesystem device=sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 directory=/hana/shared \
     fstype=nfs options='defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock' op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 \
     op start interval=0 timeout=120 op stop interval=0 timeout=120
     
     # clone the /hana/shared file system resources for both site1 and site2
     pcs resource clone fs_hana_shared_s1 meta clone-node-max=1 interleave=true
     pcs resource clone fs_hana_shared_s2 meta clone-node-max=1 interleave=true
     

     В операцию монитора добавляется атрибут OCF_CHECK_LEVEL=20, так что каждая операция монитора выполняет тест чтения и записи в файловой системе. Без этого атрибута операция монитора проверяет только подключение файловой системы. Это может оказаться проблемой, так как при потере соединения файловая система может оставаться подключенной, являясь при этом недоступной.

     Атрибут on-fail=fence также добавляется в операцию монитора. С этим параметром в случае сбоя операции монитора на узле этот узел немедленно ограждается. Без этого параметра по умолчанию выполняется остановка всех ресурсов, зависящих от неисправного ресурса. Затем неисправный ресурс перезапускается, после чего запускаются все ресурсы, зависящие от него. Когда ресурс SAP HANA зависит от неисправного ресурса, такая обработка не только занимает много времени, но также может привести к общему сбою. Ресурс SAP HANA не может быть успешно остановлен, если общая папка NFS, где находятся двоичные файлы HANA, недоступна.

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

4. [1]: настройте и проверьте атрибуты узла. Всем узлам базы данных SAP HANA на сайте репликации 1 назначается атрибут S1, а всем узлам базы данных SAP HANA на сайте репликации 2 — атрибут S2.

   # HANA replication site 1
   pcs node attribute hana-s1-db1 NFS_SID_SITE=S1
   pcs node attribute hana-s1-db2 NFS_SID_SITE=S1
   pcs node attribute hana-s1-db3 NFS_SID_SITE=S1
   # HANA replication site 2
   pcs node attribute hana-s2-db1 NFS_SID_SITE=S2
   pcs node attribute hana-s2-db2 NFS_SID_SITE=S2
   pcs node attribute hana-s2-db3 NFS_SID_SITE=S2
   # To verify the attribute assignment to nodes execute
   pcs node attribute
   

5. [1]: настройте ограничения, которые определяют, где будут подключены файловые системы NFS, и включите ресурсы файловой системы.

   # Configure the constraints
   pcs constraint location fs_hana_shared_s1-clone rule resource-discovery=never score=-INFINITY NFS_SID_SITE ne S1
   pcs constraint location fs_hana_shared_s2-clone rule resource-discovery=never score=-INFINITY NFS_SID_SITE ne S2
   # Enable the file system resources
   pcs resource enable fs_hana_shared_s1
   pcs resource enable fs_hana_shared_s2
   

   При включении ресурсов файловой системы кластер смонтирует файловые системы /hana/shared.

6. [AH] убедитесь, что тома Azure NetApp Files смонтированы под /hana/shared на всех виртуальных машинах базы данных HANA на обоих сайтах.

   • Например, при использовании Azure NetApp Files:

     sudo nfsstat -m
     # Verify that flag vers is set to 4.1 
     # Example from SITE 1, hana-s1-db1
     /hana/shared from 10.23.1.7:/HN1-shared-s1
      Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.11,local_lock=none,addr=10.23.1.7
     # Example from SITE 2, hana-s2-db1
     /hana/shared from 10.23.1.7:/HN1-shared-s2
      Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.14,local_lock=none,addr=10.23.1.7
     

   • Например, если используется Azure Files с NFS:

     sudo nfsstat -m
     # Example from SITE 1, hana-s1-db1
     sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
      Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
     # Example from SITE 2, hana-s2-db1
     sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
      Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35
     

7. [1]: настройте и клонируйте ресурсы атрибутов и настройте ограничения описанным ниже образом.

   # Configure the attribute resources
   pcs resource create hana_nfs_s1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs_s1_active
   pcs resource create hana_nfs_s2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs_s2_active
   # Clone the attribute resources
   pcs resource clone hana_nfs_s1_active meta clone-node-max=1 interleave=true
   pcs resource clone hana_nfs_s2_active meta clone-node-max=1 interleave=true
   # Configure the constraints, which will set the attribute values
   pcs constraint order fs_hana_shared_s1-clone then hana_nfs_s1_active-clone
   pcs constraint order fs_hana_shared_s2-clone then hana_nfs_s2_active-clone
   

   Совет

   Если в конфигурацию включены файловые системы, отличные от /hana/shared, а эти файловые системы подключены к NFS, добавьте параметр sequential=false. Он обеспечивает отсутствие зависимостей упорядочения между файловыми системами. Все файловые системы, подключенные посредством NFS, должны запускаться до соответствующего ресурса атрибута, но их не нужно запускать в определённом порядке относительно друг друга. Дополнительные сведения см. в разделе Как настроить репликацию системы SAP HANA с горизонтальным увеличением масштаба в кластере Pacemaker, если файловые системы HANA размещены в общих папках NFS?.

8. [1]: переведите Pacemaker в режим обслуживания, чтобы подготовиться к созданию кластерных ресурсов HANA.

   pcs property set maintenance-mode=true
   

Теперь можно приступать к созданию ресурсов кластера:

1. [A] Установите агент ресурсов HANA для масштабирования кластера на всех узлах кластера, включая основной узел.

   yum install -y resource-agents-sap-hana-scaleout 
   

   Примечание

   Ознакомьтесь с Политиками поддержки кластеров RHEL HA — Управление SAP HANA в кластере, чтобы узнать минимально поддерживаемую версию пакета resource-agents-sap-hana-scaleout для вашей версии операционной системы.

2. [1,2] Настройте хуки репликации системы HANA на одном узле базы данных HANA на каждом сайте репликации системы. SAP HANA всё ещё должна быть отключена. resource-agents-sap-hana-scaleout версия 0.185.3-0 или более поздняя версия включает в себя как модули SAPHanaSR, так и ChkSrv. Для корректного функционирования кластера необходимо включить перехватчик SAPHanaSR. Мы настоятельно рекомендуем настроить как хуки SAPHanaSR, так и ChkSrv Python.

   1. Внесите изменения в файл global.ini.

      # add to global.ini
      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR-ScaleOut
      execution_order = 1
      
      [ha_dr_provider_chksrv]
      provider = ChkSrv
      path = /usr/share/SAPHanaSR-ScaleOut
      execution_order = 2
      action_on_lost = kill
      
      [trace]
      ha_dr_saphanasr = info
      ha_dr_chksrv = info
      

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

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

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

3. [AH]: для кластера требуется конфигурация sudoers на узле кластера для <sid>adm. В примере для этого создается новый файл. Выполните команды как root.

   sudo visudo -f /etc/sudoers.d/20-saphana
   # Insert the following lines and then save
   Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_hn1_glob_srHook -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_hn1_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SRREBOOT = /usr/sbin/crm_attribute -n hana_hn1_gsh -v * -l reboot -t crm_config -s SAPHanaSR
   hn1adm ALL=(ALL) NOPASSWD: SOK, SFAIL, SRREBOOT
   Defaults!SOK, SFAIL, SRREBOOT !requiretty
   

4. [1, 2] Запустите SAP HANA на обоих сайтах репликации. Выполните команду от имени <sid>adm.

   sapcontrol -nr 03 -function StartSystem 
   

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

   cdtrace
   awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
   { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
   
   # Example entries
   # 2020-07-21 22:04:52.782774 ha_dr_SAPHanaSR SFAIL
   # 2020-07-21 22:04:53.117492 ha_dr_SAPHanaSR SFAIL
   # 2020-07-21 22:06:35.599324 ha_dr_SAPHanaSR SOK
   

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

    cdtrace
    tail -20 nameserver_chksrv.trc
   

7. [1]: создайте кластерные ресурсы HANA. Выполните следующие команды от имени root.

   1. Убедитесь, что кластер уже находится в режиме обслуживания.

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

      pcs resource create SAPHanaTopology_HN1_HDB03 SAPHanaTopologyScaleOut \
       SID=HN1 InstanceNumber=03 \
       op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600
      
      pcs resource clone SAPHanaTopology_HN1_HDB03 meta clone-node-max=1 interleave=true
      

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

      pcs resource create SAPHanaTopology_HN1_HDB03 SAPHanaTopology \
       SID=HN1 InstanceNumber=03 meta clone-node-max=1 interleave=true \
       op methods interval=0s timeout=5 \
       op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600
      
      pcs resource clone SAPHanaTopology_HN1_HDB03 meta clone-node-max=1 interleave=true
      

   3. Создайте ресурс экземпляра HANA.

      Примечание

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

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

      pcs resource create SAPHana_HN1_HDB03 SAPHanaController \
       SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
       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
      
      pcs resource master msl_SAPHana_HN1_HDB03 SAPHana_HN1_HDB03 \
       meta master-max="1" clone-node-max=1 interleave=true
      

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

      pcs resource create SAPHana_HN1_HDB03 SAPHanaController \
       SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
       op demote interval=0s timeout=320 op methods interval=0s timeout=5 \
       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
      
      pcs resource promotable SAPHana_HN1_HDB03 \
       meta master-max="1" clone-node-max=1 interleave=true
      

      Важно!

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

   4. Создайте виртуальный IP-адрес и связанные ресурсы.

      pcs resource create vip_HN1_03 ocf:heartbeat:IPaddr2 ip=10.23.0.18 op monitor interval="10s" timeout="20s"
      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
      

   5. Создание ограничений кластера

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

      #Start HANA topology, before the HANA instance
      pcs constraint order SAPHanaTopology_HN1_HDB03-clone then msl_SAPHana_HN1_HDB03
      
      pcs constraint colocation add g_ip_HN1_03 with master msl_SAPHana_HN1_HDB03 4000
      #HANA resources are only allowed to run on a node, if the node's NFS file systems are mounted. The constraint also avoids the majority maker node
      pcs constraint location SAPHanaTopology_HN1_HDB03-clone rule resource-discovery=never score=-INFINITY hana_nfs_s1_active ne true and hana_nfs_s2_active ne true
      

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

      #Start HANA topology, before the HANA instance
      pcs constraint order SAPHanaTopology_HN1_HDB03-clone then SAPHana_HN1_HDB03-clone
      
      pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_HDB03-clone 4000
      #HANA resources are only allowed to run on a node, if the node's NFS file systems are mounted. The constraint also avoids the majority maker node
      pcs constraint location SAPHanaTopology_HN1_HDB03-clone rule resource-discovery=never score=-INFINITY hana_nfs_s1_active ne true and hana_nfs_s2_active ne true
      

8. [1]: выведите кластер из режима обслуживания. Убедитесь, что кластер находится в состоянии ok и все ресурсы запущены.

   sudo pcs property set maintenance-mode=false
   #If there are failed cluster resources, you may need to run the next command
   pcs resource cleanup
   

   Примечание

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

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

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

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

Чтобы продолжить подготовку второго виртуального IP-адреса, убедитесь, что вы настроили Azure Load Balancer, как описано в разделе "Настройка Azure Load Balancer".

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

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

   1. Откройте подсистему балансировки нагрузки, выберите пул интерфейсных IP-адресов и щелкните Добавить.
   2. Введите имя нового пула интерфейсных IP-адресов (например, hana-frontend).
   3. Для параметра Назначение выберите значение Статический и введите IP-адрес (например, 10.23.0.19).
   4. Нажмите ОК.
   5. После создания нового пула внешних IP-адресов запишите его IP-адрес.

2. Создайте зонд работоспособности.

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

3. Теперь создайте правила балансировки нагрузки.

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

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

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2 --operationMode=logreplay_readaccess 

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

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.23.0.19"
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

# RHEL 8.x: 
pcs constraint location g_ip_HN1_03 rule score=500 role=master hana_hn1_roles eq "master1:master:worker:master" and hana_hn1_clone_state eq PROMOTED
pcs constraint location g_secip_HN1_03 rule score=50  hana_hn1_roles eq 'master1:master:worker:master'
pcs constraint order promote  SAPHana_HN1_HDB03-clone then start g_ip_HN1_03
pcs constraint order start g_ip_HN1_03 then start g_secip_HN1_03
pcs constraint colocation add g_secip_HN1_03 with Slave SAPHana_HN1_HDB03-clone 5

# RHEL 7.x:
pcs constraint location g_ip_HN1_03 rule score=500 role=master hana_hn1_roles eq "master1:master:worker:master" and hana_hn1_clone_state eq PROMOTED
pcs constraint location g_secip_HN1_03 rule score=50  hana_hn1_roles eq 'master1:master:worker:master'
pcs constraint order promote  msl_SAPHana_HN1_HDB03 then start g_ip_HN1_03
pcs constraint order start g_ip_HN1_03 then start g_secip_HN1_03
pcs constraint colocation add g_secip_HN1_03 with Slave msl_SAPHana_HN1_HDB03 5

pcs property set maintenance-mode=false

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

# Example output from crm_mon
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#rsc_st_azure    (stonith:fence_azure_arm):      Started hana-s-mm
#Clone Set: fs_hana_shared_s1-clone [fs_hana_shared_s1]
#    Started: [ hana--s1-db1 hana-s1-db2 hana-s1-db3 ]
#Clone Set: fs_hana_shared_s2-clone [fs_hana_shared_s2]
#    Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#Clone Set: hana_nfs_s1_active-clone [hana_nfs_s1_active]
#    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
#Clone Set: hana_nfs_s2_active-clone [hana_nfs_s2_active]
#    Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#Clone Set: SAPHanaTopology_HN1_HDB03-clone [SAPHanaTopology_HN1_HDB03]
#    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#Master/Slave Set: msl_SAPHana_HN1_HDB03 [SAPHana_HN1_HDB03]
#    Masters: [ hana-s1-db1 ]
#    Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#Resource Group: g_ip_HN1_03
#    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hana-s1-db1
#    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#Resource Group: g_secip_HN1_03
#    secnc_HN1_03       (ocf::heartbeat:azure-lb):      Started hana-s2-db1
#    secvip_HN1_03      (ocf::heartbeat:IPaddr2):       Started hana-s2-db1

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

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

• При переносе ресурса кластера SAPHANA_HN1_HDB03 на дополнительный сайт (S2), второй виртуальный IP-адрес будет перемещен на другой сайт hana-s1-db1. Если вы настроили AUTOMATED_REGISTER="false", а репликация системы HANA не зарегистрирована автоматически, второй виртуальный IP-адрес будет работать на hana-s2-db1.

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

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

1. Перед началом теста проверьте состояние репликации кластера и системы SAP HANA.

   1. Проверьте, что в кластере нет неудачных действий.

      #Verify that there are no failed cluster actions
      pcs status
      # Example
      #Stack: corosync
      #Current DC: hana-s-mm (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
      #Last updated: Thu Sep 24 06:00:20 2020
      #Last change: Thu Sep 24 05:59:17 2020 by root via crm_attribute on hana-s1-db1
      #
      #7 nodes configured
      #45 resources configured
      #
      #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
      #
      #Active resources:
      #
      #rsc_st_azure    (stonith:fence_azure_arm):      Started hana-s-mm
      #Clone Set: fs_hana_shared_s1-clone [fs_hana_shared_s1]
      #    Started: [ hana--s1-db1 hana-s1-db2 hana-s1-db3 ]
      #Clone Set: fs_hana_shared_s2-clone [fs_hana_shared_s2]
      #    Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
      #Clone Set: hana_nfs_s1_active-clone [hana_nfs_s1_active]
      #    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
      #Clone Set: hana_nfs_s2_active-clone [hana_nfs_s2_active]
      #    Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
      #Clone Set: SAPHanaTopology_HN1_HDB03-clone [SAPHanaTopology_HN1_HDB03]
      #    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
      #Master/Slave Set: msl_SAPHana_HN1_HDB03 [SAPHana_HN1_HDB03]
      #    Masters: [ hana-s1-db1 ]
      #    Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
      #Resource Group: g_ip_HN1_03
      #    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hana-s1-db1
      #    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
      

   2. Проверьте, синхронизируется ли репликация системы SAP HANA.

      # Verify HANA HSR is in sync
      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 |
      #| -------- | ----------- | ----- | ------------ | --------- | ------- | --------- | ------------- | -------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
      #| HN1      | hana-s1-db3 | 30303 | indexserver  |         5 |       2 | HANA_S1   | hana-s2-db3 |     30303  |         1 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
      #| HN1      | hana-s1-db2 | 30303 | indexserver  |         4 |       2 | HANA_S1   | hana-s2-db2 |     30303  |         1 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |  
      #| SYSTEMDB | hana-s1-db1 | 30301 | nameserver   |         1 |       2 | HANA_S1   | hana-s2-db1 |     30301  |         1 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
      #| HN1      | hana-s1-db1 | 30307 | xsengine     |         2 |       2 | HANA_S1   | hana-s2-db1 |     30307  |         1 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
      #| HN1      | hana-s1-db1 | 30303 | indexserver  |         3 |       2 | HANA_S1   | hana-s2-db1 |     30303  |         1 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
      
      #status system replication site "1": ACTIVE
      #overall system replication status: ACTIVE
      
      #Local System Replication State
      #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      #mode: PRIMARY
      #site id: 1
      #site name: HANA_S1
      

2. Проверьте конфигурацию кластера на случай сбоя, когда узел теряет доступ к общей папке NFS (/hana/shared).

   Агенты ресурсов SAP HANA зависят от двоичных файлов, хранящихся в /hana/shared, для выполнения операций при переключении в случае отказа. В представленной конфигурации файловая система /hana/shared подключена посредством NFS. Можно протестировать систему, создав временное правило брандмауэра для блокировки доступа к файловой системе /hana/shared, подключенной к NFS, на одной из виртуальных машин основного сайта. Этот подход позволяет проверить, произойдет ли переключение кластера, если будет утрачен доступ к /hana/shared на активном узле репликации системы.

   Ожидаемый результат: при блокировке доступа к файловой системе /hana/shared, подключенной к NFS, на одной из виртуальных машин основного сайта операция мониторинга, выполняющая операции чтения и записи в файловой системе, завершится ошибкой, так как она не сможет получить доступ к файловой системе, и это активирует переключение ресурса HANA. Ожидается аналогичный результат, когда узел HANA теряет доступ к NFS-ресурсу.

   Состояние ресурсов кластера можно проверить, выполнив команду crm_mon или pcs status. Состояние ресурсов перед запуском теста:

   # Output of crm_mon
   #7 nodes configured
   #45 resources configured
   
   #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   #
   #Active resources:
   
   #rsc_st_azure    (stonith:fence_azure_arm):      Started hana-s-mm
   # Clone Set: fs_hana_shared_s1-clone [fs_hana_shared_s1]
   #    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
   # Clone Set: fs_hana_shared_s2-clone [fs_hana_shared_s2]
   #     Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Clone Set: hana_nfs_s1_active-clone [hana_nfs_s1_active]
   #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
   # Clone Set: hana_nfs_s2_active-clone [hana_nfs_s2_active]
   #     Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Clone Set: SAPHanaTopology_HN1_HDB03-clone [SAPHanaTopology_HN1_HDB03]
   #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Master/Slave Set: msl_SAPHana_HN1_HDB03 [SAPHana_HN1_HDB03]
   #     Masters: [ hana-s1-db1 ]
   #     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Resource Group: g_ip_HN1_03
   #     nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hana-s1-db1
   #     vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
   

   Чтобы сымитировать сбой для /hana/shared, выполните следующие действия:

   • Если вы используете NFS в ANF, сначала подтвердите IP-адрес для тома ANF /hana/shared на основном сайте. Для этого можно выполнить команду df -kh|grep /hana/shared.
   • При использовании NFS в Файлах Azure сначала определите IP-адрес частной конечной точки для учетной записи хранения.

   Затем настройте временное правило брандмауэра, чтобы заблокировать доступ к IP-адресу файловой системы /hana/shared, подключенной к NFS, выполнив следующую команду на одной из виртуальных машин основного сайта репликации системы HANA.

   В этом примере команда была выполнена в hana-s1-db1 для тома /hana/sharedANF.

   iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
   

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

   Если кластер не запустился на виртуальной машине, которая была перезапущена, запустите его, выполнив следующие команды:

   # Start the cluster 
   pcs cluster start
   

   После запуска кластера файловая система /hana/shared будет автоматически подключена. Если задать параметр AUTOMATED_REGISTER="false", то необходимо будет настроить репликацию системы SAP HANA на дополнительном сайте. В этом случае можно выполнить приведенные ниже команды, чтобы перенастроить SAP HANA как вторичный.

   # Execute on the secondary 
   su - hn1adm
   # Make sure HANA is not running on the secondary site. If it is started, stop HANA
   sapcontrol -nr 03 -function StopWait 600 10
   # Register the HANA secondary site
   hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
   # Switch back to root and clean up failed resources
   pcs resource cleanup SAPHana_HN1_HDB03
   

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

   # Output of crm_mon
   #7 nodes configured
   #45 resources configured
   
   #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   
   #Active resources:
   
   #rsc_st_azure    (stonith:fence_azure_arm):      Started hana-s-mm
   # Clone Set: fs_hana_shared_s1-clone [fs_hana_shared_s1]
   #    Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
   # Clone Set: fs_hana_shared_s2-clone [fs_hana_shared_s2]
   #     Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Clone Set: hana_nfs_s1_active-clone [hana_nfs_s1_active]
   #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 ]
   # Clone Set: hana_nfs_s2_active-clone [hana_nfs_s2_active]
   #     Started: [ hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Clone Set: SAPHanaTopology_HN1_HDB03-clone [SAPHanaTopology_HN1_HDB03]
   #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
   # Master/Slave Set: msl_SAPHana_HN1_HDB03 [SAPHana_HN1_HDB03]
   #     Masters: [ hana-s2-db1 ]
   #     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
   # Resource Group: g_ip_HN1_03
   #     nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hana-s2-db1
   #     vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
   

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

• Планирование и реализация виртуальных машин Azure для SAP
• Развертывание виртуальных машин Azure для SAP
• Развертывание СУБД на виртуальных машинах Azure для SAP
• Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA
• Чтобы узнать больше об обеспечении высокого уровня доступности и планировании аварийного восстановления SAP HANA на виртуальных машинах Azure, ознакомьтесь со статьей Высокий уровень доступности SAP HANA на виртуальных машинах Azure.