Обеспечение высокого уровня доступности для масштабируемой системы SAP HANA с помощью HSR на основе SUSE Linux Enterprise Server

Статья
06/18/2024

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

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

Прежде чем начать, ознакомьтесь со следующими примечаниями и документацией по SAP.

Документация по Azure NetApp Files
Документация по Файлам Azure
К 1928533 заметки SAP относятся:
- список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
- важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
- сведения о поддерживаемом программном обеспечении SAP и сочетаниях операционных систем и баз данных;
- сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
В примечании к SAP 2015553 описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure
В примечании к SAP 2205917 содержатся рекомендуемые параметры ОС для SUSE Linux Enterprise Server for SAP Applications
В примечании к SAP 1944799 содержатся рекомендации по SAP HANA для SUSE Linux Enterprise Server for SAP Applications
Примечание SAP 2178632, в котором содержатся подробные сведения обо всех доступных метриках мониторинга для SAP в Azure.
Примечание SAP 2191498, в котором содержатся сведения о необходимой версии агента SAP Host Agent для Linux в Azure.
Примечание SAP 2243692, в котором содержатся сведения о лицензировании SAP для Linux в Azure.
В примечании к SAP 1984787 содержатся общие сведения о SUSE Linux Enterprise Server 12
Примечание SAP 1999351, в котором содержатся дополнительные сведения об устранении неполадок, связанных с расширением для расширенного мониторинга Azure для SAP.
Примечание SAP 1900823, в котором содержатся сведения о требованиях к хранилищу SAP HANA.
Вики-сайт сообщества SAP, который содержит все необходимые примечания SAP для Linux.
SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению
Развертывание программного обеспечения SAP на виртуальных машинах Linux в Azure
Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
Рекомендации профессионалов по использованию SUSE SAP: содержит все необходимые сведения для настройки высокой доступности и репликации системы SAP HANA локально (для использования в качестве общего базового показателя; они предоставляют намного более подробную информацию)
Заметки о выпуске расширения SUSE высокого уровня доступности 12 SP5
Обработка неисправной общей папки NFS в кластере SUSE с высоким уровнем доступности для репликации системы HANA
Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA

Обзор

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

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

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

Внимание

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

Предупреждение

Развертывание /hana/data и /hana/log в NFS в Файлах 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.

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

Разверните виртуальные машины 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 имя сетевого интерфейса создается автоматически. В этих инструкциях для простоты мы будем называть автоматически создаваемые основные сетевые интерфейсы, подключенные к подсети client виртуальной сети Azure, следующим образом: hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client и т. д.
Внимание
- Убедитесь, что выбранная операционная система была сертифицирована для использования SAP HANA на конкретных типах виртуальных машин. Список сертифицированных для SAP HANA типов виртуальных машин и выпусков ОС доступен на сайте Certified and Supported SAP HANA® Hardware (Сертифицированное и поддерживаемое оборудование SAP HANA®). Чтобы просмотреть подробные сведения о поддерживаемых SAP HANA на определенных типах виртуальных машин выпусках ОС, щелкните необходимый тип виртуальной машины.
- Если вы решили развернуть /hana/shared в NFS на Файлы Azure, рекомендуется развернуть в SLES 15 с пакетом обновления 2 (SP2) и выше.
Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных 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).
Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных 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).
Подключите созданные виртуальные сетевые интерфейсы к соответствующим виртуальным машинам, выполнив следующие действия.
1. Перейдите к виртуальной машине на портале Azure.
2. В меню слева выберите Виртуальные машины. Выполните фильтрацию по имени виртуальной машины (например, hana-s1-db1), а затем выберите виртуальную машину.
3. В области Обзор выберите Остановить, чтобы освободить виртуальную машину.
4. Выберите Сеть, а затем подключите сетевой интерфейс. Из раскрывающегося списка Подключение сетевого интерфейса выберите уже созданные сетевые интерфейсы для подсетей inter и hsr.
5. Выберите Сохранить.
6. Повторите шаги б–е для остальных виртуальных машин (в нашем примере это hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 и hana-s2-db3).
7. Пока оставьте виртуальные машины в остановленном состоянии. Далее мы включим функцию ускорения сети для всех новых подключенных сетевых интерфейсов.

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

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

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

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

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

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

Примечание.

Для горизонтального масштабирования HANA выберите сетевой адаптер для client подсети при добавлении виртуальных машин в серверный пул.
Полный набор команд в Azure CLI и PowerShell добавляет виртуальные машины с основным сетевым адаптером в серверном пуле.

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

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

Примечание.

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

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

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

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

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

Примечание.

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

Внимание

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

Развертывание NFS

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

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

Совет

Вы решили развернуть /hana/shared в общей папке NFS в Файлах Azure или в томе NFS в Azure NetApp Files.

Развертывание инфраструктуры Azure NetApp Files

Разверните тома 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

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

В этом примере использовались следующие общие папки NFS в Файлах Azure:

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]: применимо только к узлу базы данных HANA 1 на сайте 1;
[2]: применимо только к узлу базы данных HANA 1 на сайте 2.

Настройте и подготовьте ОС, выполнив следующие действия.

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

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[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.
[A] SUSE предоставляет специальные агенты ресурсов для SAP HANA и по умолчанию для масштабирования SAP HANA. Удалите пакеты для горизонтального масштабирования, если установлены и установлены пакеты для сценария горизонтального масштабирования SAP HANA. Шаг необходимо выполнить на всех виртуальных машинах кластера, включая создателя большинства.

Примечание.

Необходимо установить SAPHanaSR-ScaleOut версии 0.181 или более поздней.
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] Подготовка виртуальных машин. Примените рекомендуемые параметры в соответствии с заметкой SAP 2205917 для SUSE Linux Enterprise Server для приложений SAP.

Подготовка файловых систем

Вы решили развернуть общие каталоги SAP в общей папке NFS в Файлах Azure или в томе NFS в Azure NetApp Files.

Подключение общих файловых систем (Azure NetApp Files NFS)

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

[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

[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
```
[A]: создайте точки подключения для томов базы данных HANA.
```
mkdir -p /hana/shared
```
[A]: проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, т. е. defaultv4iddomain.com, а для сопоставления установлено значение Никто.
Этот шаг необходим, если используется служба Azure NetApp Files с NFS 4.1.

Внимание

Обязательно укажите домен NFS в /etc/idmapd.conf виртуальной машине в соответствии с конфигурацией домена по умолчанию в Azure NetApp Files: defaultv4iddomain.com. В случае несоответствия между конфигурацией домена на клиенте NFS (т. е. виртуальной машине) и NFS-сервере (т. е. конфигурацией Azure NetApp) разрешения для файлов на томах NetApp в Azure, подключенных к виртуальным машинам, будут отображаться как nobody.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
[AH]: проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, где nfs4_disable_idmapping находится, выполните команду подключения. Вы не сможете вручную создать каталог в /sys/modules, так как доступ зарезервирован для ядра или драйверов.
Этот шаг необходим, если используется служба Azure NetApp Files с NFS 4.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.23.1.7:/HN1-share-s1 /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
```

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

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

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

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

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

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.19,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.22,local_lock=none,addr=10.23.1.7

Подключение общих файловых систем (NFS в Файлах Azure)

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

[A]: создайте точки подключения для томов базы данных HANA.
```
mkdir -p /hana/shared
```

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

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

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

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

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 подключены три диска данных, на которых созданы два тома.

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

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

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

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

[AH]: создайте физические тома для всех дисков, которые вы хотите использовать.
```
sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2
```
[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
```
[AH]: создайте логические тома.

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

Внимание

Параметр -i, значение которого соответствует числу базовых физических томов, необходимо указать для всех томов данных или журналов, для которых используется более одного физического тома. Используйте параметр -I, чтобы указать размер блока чередования при создании чередующегося тома.
Сведения о рекомендуемых конфигурациях хранилища, включая размеры блоков чередования и количество дисков, см. в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```
[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
```

[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

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

Следуйте указаниям из статьи Setting up Pacemaker on SUSE Linux Enterprise Server in Azure (Настройка Pacemaker на SUSE Linux Enterprise Server в Azure), чтобы создать базовый кластер Pacemaker для этого сервера HANA. Добавьте в кластер все виртуальные машины, включая виртуальную машину создания большинства.

Внимание

Не устанавливайте для свойства quorum expected-votes значение 2, так как это не кластер с двумя узлами.
Убедитесь, что свойство кластера concurrent-fencing включено, чтобы обеспечить десериализацию ограждения узлов.

Установка

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

Подготовка к установке SAP HANA

[A]: перед установкой HANA задайте корневой пароль. После завершения установки можно будет отключить корневой пароль. Выполните как root команду passwd.
[1, 2]: измените разрешения для /hana/shared.
```
chmod 775 /hana/shared
```
[1]: убедитесь, что вы можете войти с помощью протокола SSH на виртуальные машины базы данных HANA hana-s1-db2 и hana-s1-db3 на этом сайте без запроса пароля. Если это не так, обмен ключами SSH, как описано в разделе "Включение доступа SSH через открытый ключ".
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2]: убедитесь, что вы можете войти с помощью протокола SSH на виртуальные машины базы данных HANA hana-s2-db2 и hana-s2-db3 на этом сайте без запроса пароля.
Если это не так, обмен ключами SSH.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[A]: установите дополнительные пакеты, необходимые для HANA 2.0 SP4 и более поздних версий. Дополнительные сведения см. в заметке SAP 2593824 для используемой версии SLES.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

Установка HANA на первом узле на каждом сайте

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

a. Запустите с правами пользователя root программу hdblcm из каталога с установочным программным обеспечением HANA. Используйте параметр internal_network и передайте диапазон адресов подсети, используемой для обмена данными между узлами HANA.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. Введите следующие значения на запрос в командной строке:
- На запрос Choose an action (Выберите действие): введите 1 (установка).
- На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
- Для пути установки: нажмите клавишу ВВОД (путь по умолчанию — /hana/shared).
- На запрос Local Host Name (Имя локального узла): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- На запрос Do you want to add hosts to the system? (Желаете добавить узлы в систему?) введите n (Нет).
- На запрос SAP HANA System ID (Идентификатор системы SAP HANA): введите HN1.
- На запрос Instance number [00] (Номер экземпляра [00]): введите 03.
- На запрос Local Host Worker Group [default] (Рабочая группа локального узла [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- На запрос Select System Usage / Enter index [4] (Выберите использование системы или введите индекс [4]): введите 4 (пользовательское значение).
- На запрос Location of Data Volumes [/hana/hata/HN1] (Расположение томов данных [/hana/hata/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 (Пароль пользователя SAP Host Agent (sapadm)): введите пароль.
- На запрос Confirm SAP Host Agent User (sapadm) Password (Подтвердите пароль пользователя SAP Host Agent (sapadm)): еще раз введите пароль.
- На запрос System Administrator (hn1adm) Password (Пароль системного администратора (hn1adm)): введите пароль.
- На запрос System Administrator Home Directory [/usr/sap/HN1/home] (Корневой каталог системного администратора [/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] (Введите идентификатор группы пользователей (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]: повторите предыдущий шаг, чтобы установить SAP HANA на первом узле на сайте 2.
[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.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1, 2]: подготовьте global.ini к установке в среде без общего доступа, как описано в примечании SAP 2080991.
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[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

[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.22"
```
Сведения о том, как проверить конфигурацию, см. в примечании SAP 2183363 - Configuration of SAP HANA internal network (2183363: настройка внутренней сети SAP HANA).
[AH]: измените разрешения для каталогов данных и журналов, чтобы избежать ошибок установки HANA.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1]: установите дополнительные узлы HANA. Примеры инструкций на этом шаге приведены для сайта 1.

a. Запустите резидентную программу hdblcm с правами пользователя root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. Введите следующие значения на запрос в командной строке:
- На запрос Choose an action (Выберите действие): введите 2 (добавление узлов).
- На запрос Enter comma separated host names to add (Введите имена узлов с разделителями-запятыми): введите hana-s1-db2, hana-s1-db3.
- На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
- На запрос Enter Root User Name [root] (Введите имя привилегированного пользователя [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] (Выберите роли для узла 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 (Пароль системного администратора (hn1adm)): введите пароль.
- На запрос Enter SAP Host Agent User (sapadm) Password (Введите пароль пользователя SAP Host Agent (sapadm)): введите пароль.
- На запрос Confirm SAP Host Agent User (sapadm) Password (Подтвердите пароль пользователя 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): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- На запрос Do you want to continue (y/n)? (Продолжить (да или нет)?): проверьте сводку и, если все настроено правильно, введите y (Да).
[2]: повторите предыдущий шаг, чтобы установить дополнительные узлы SAP HANA на сайте 2.

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

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

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

[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

[1, 2]: измените конфигурацию HANA таким образом, чтобы данные репликации системы HANA направлялись через виртуальные сетевые интерфейсы репликации системы HANA.
- Остановите экземпляры HANA на обоих сайтах.
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- Измените файл 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.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- Запустите экземпляры HANA на обоих сайтах.
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
Дополнительные сведения см. в разделе Host Name Resolution for System Replication (Разрешение имен узлов для репликации системы).

Создание ресурсов файловой системы

Создайте фиктивный ресурс кластера файловой системы, который будет отслеживать и сообщать о сбоях, если возникла проблема с доступом к подключенной к NFS файловой системе /hana/shared. Это позволяет кластеру активировать отработку отказа, если возникла проблема с доступом /hana/shared. Дополнительные сведения см. в статье Об обработке общей папки NFS в кластере SUSE HA для репликации системы HANA

[1]: переведите Pacemaker в режим обслуживания, чтобы подготовиться к созданию кластерных ресурсов HANA.
```
crm configure property maintenance-mode=true
```
[1,2] Создайте в файловой системе, подключенной к NFS, каталог /hana/shared, который будет использоваться в специальном ресурсе мониторинга файловой системы. Эти каталоги необходимо создать на обоих сайтах.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Создайте каталог, который будет использоваться для подключения специального ресурса мониторинга файловой системы. Этот каталог необходимо создать на всех узлах кластера HANA.
```
mkdir -p /hana/check
```
[1] Создайте ресурсы кластера файловой системы.
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
В операцию монитора добавляется атрибут OCF_CHECK_LEVEL=20, так что каждая операция монитора выполняет тест чтения и записи в файловой системе. Без этого атрибута операция монитора проверяет только подключение файловой системы. Это может оказаться проблемой, так как при потере соединения файловая система может оставаться подключенной, являясь при этом недоступной.

Атрибут on-fail=fence также добавляется в операцию монитора. С этим параметром в случае сбоя операции монитора на узле этот узел немедленно ограждается.

Реализация перехватчиков HA HANASrMultiTarget и susChkSrv

Этот важный шаг заключается в оптимизации интеграции с кластером и обнаружении при возможности отработки отказа кластера. Настоятельно рекомендуется настроить перехватчик Python SAPHanaSrMultiTarget. Для HANA 2.0 с пакетом обновления 5 (SP5) и более поздних версий рекомендуется реализовать устройства SAPHanaSrMultiTarget и susChkSrv.

Примечание.

Поставщик SAPHanaSrMultiTarget HA заменяет SAPHanaSR для горизонтального масштабирования HANA. SAPHanaSR описан в более ранней версии этого документа.
См . запись блога SUSE об изменениях с новым перехватчиком высокого уровня доступности HANA.

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

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

SUSE SLES 15 с пакетом обновления 1 (SP1) или более поздней версии требуется для работы обоих перехватчиков высокого уровня доступности HANA. В следующей таблице показаны другие зависимости.

Перехватчик ВЫСОКОГО уровня доступности SAP HANA	Требуемая версия HANA	Требуется SAPHanaSR-ScaleOut
SAPHanaSrMultiTarget	HANA 2.0 SPS4 или более поздней версии	0.180 или более поздней версии
susChkSrv	HANA 2.0 SPS5 или более поздней версии	0.184.1 или более поздней версии

Шаги по реализации обоих перехватчиков:

[1,2] Остановите HANA на обоих сайтах репликации системы. Выполните приведенные команды с правами пользователя <sid>adm:
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Настройте на global.ini каждом сайте кластера. Если необходимые условия для перехватчика susChkSrv не выполнены, не следует настраивать весь блок [ha_dr_provider_suschksrv] .
Поведение susChkSrv можно настроить с помощью параметра action_on_lost. Допустимые значения: [ ignore | stop | kill | fence ].
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
Расположение перехватчиков высокого уровня доступности по умолчанию, предоставляемых SUSE, — /usr/share/SAPHanaSR-ScaleOut. Использование стандартного расположения дает преимущество, что код перехватчика Python автоматически обновляется с помощью ос или обновлений пакетов и используется HANA при следующем перезапуске. Необязательный собственный путь, например /hana/shared/myHooks, можно отделить обновления ОС от используемой версии перехватчика.
[AH] Для кластера требуется настройка sudoers на узлах кластера для <идентификатора>adm. В примере для этого создается новый файл. Выполните команды, root адаптируя значения hn1 с правильным строчным идентификатором безопасности.
```
cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF
```
[1, 2]: запустите экземпляры SAP HANA на обоих сайтах репликации. Выполните приведенные команды с правами пользователя <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Убедитесь, что установка перехватчика активна на всех узлах кластера. Выполните приведенные команды с правами пользователя <sid>adm.

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

Проверьте установку перехватчика susChkSrv. Выполните приведенные команды с правами пользователя <sid>adm.

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

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

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

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

Затем создайте топологию ресурсов HANA.

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

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

Примечание.

В этой статье содержатся ссылки на термины, которые корпорация Майкрософт больше не использует. Когда эти термины будут удалены из программных продуктов, мы удалим их и из этой статьи.
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  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="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
Внимание

Рекомендуется установить для параметра AUTOMATED_REGISTER значение no (Нет) при выполнении тщательного тестирования отработки отказа, чтобы предотвратить автоматическую регистрацию экземпляра-получателя вместо неисправного экземпляра-источника. После успешного завершения тестов отработки отказа задайте для параметра AUTOMATED_REGISTER значение yes (Да), чтобы после переключения репликация системы могла возобновить работу автоматически.

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

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

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

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] Настройте дополнительные свойства кластера.

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

[1]: выведите кластер из режима обслуживания. Убедитесь, что состоянию кластера соответствует значение ОК и все ресурсы запущены.
```
# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false
```
[1] Проверьте связь между перехватчиком высокого уровня доступности HANA и кластером, показывая состояние SOK для безопасности безопасности и обоих сайтов репликации с состоянием P(rimary) или S(econdary).
```
sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S
```
Примечание.

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

Тестовая отработка отказа SAP HANA

Примечание.

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

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

a. Убедитесь в отсутствии действий с ошибками кластера.

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. Проверьте, синхронизируется ли репликация системы 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 |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| 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-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | 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

Мы рекомендуем тщательно проверить конфигурацию кластера SAP HANA, выполнив тесты по инструкциям в документе Обеспечение высокого уровня доступности SAP HANA на виртуальных машинах Azure в SUSE Linux Enterprise Server и SLES Replication scale-out Performance Optimized Scenario (Сценарий с оптимизированной производительностью для горизонтального масштабирования с репликацией SLES).
Проверьте конфигурацию кластера на случай сбоя, когда узел теряет доступ к общей папке NFS (/hana/shared).

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

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

Состояние ресурсов кластера можно проверить, выполнив команду crm_mon или crm status. Состояние ресурсов перед запуском теста:
```
# Output of crm_mon
#7 nodes configured
#24 resource instances 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:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_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 [rsc_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_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
```
Чтобы сымитировать сбой для /hana/shared, выполните следующие действия:
- При использовании NFS в Azure NetApp Files сначала подтвердите IP-адрес тома /hana/shared Azure NetApp Files на основном сайте. Для этого можно выполнить команду df -kh|grep /hana/shared.
- При использовании NFS в Файлах Azure сначала определите IP-адрес частной конечной точки для учетной записи хранения.
Затем настройте временное правило брандмауэра, чтобы заблокировать доступ к IP-адресу файловой системы /hana/shared, подключенной к NFS, выполнив следующую команду на одной из виртуальных машин основного сайта репликации системы HANA.

В этом примере команда была выполнена в томе hana-s1-db1 для тома /hana/sharedAzure NetApp Files.
```
iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
```
Кластерные ресурсы переносятся на другой сайт репликации системы HANA.

Если задано значение 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 cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03
```
Состояние ресурсов после теста:
```
# Output of crm_mon
#7 nodes configured
#24 resource instances 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:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_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 [rsc_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_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
```

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

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

Поделиться через

Обеспечение высокого уровня доступности для масштабируемой системы SAP HANA с помощью HSR на основе SUSE Linux Enterprise Server

Обзор

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

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

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

Развертывание NFS

Развертывание инфраструктуры Azure NetApp Files

Развертывание инфраструктуры NFS в Файлах Azure

Настройка и подготовка операционной системы

Подготовка файловых систем

Подключение общих файловых систем (Azure NetApp Files NFS)

Подключение общих файловых систем (NFS в Файлах Azure)

Подготовка локальных файловых систем для данных и журналов

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

Установка

Подготовка к установке SAP HANA

Установка HANA на первом узле на каждом сайте

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

Создание ресурсов файловой системы

Реализация перехватчиков HA HANASrMultiTarget и susChkSrv

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

Тестовая отработка отказа SAP HANA

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

Обратная связь

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