Высокая доступность масштабирования SAP HANA с помощью Azure NetApp Files в SUSE Enterprise Linux

В этой статье описывается, как настроить репликацию системы SAP HANA в масштабируемом развертывании при подключении файловых систем HANA через NFS с помощью Azure NetApp Files. В примерах конфигураций и команд установки используются номера экземпляра 03 и HANA System ID HN1. Репликация SAP HANA состоит из одного первичного узла и по крайней мере одного вторичного узла.

Когда шаги в этом документе помечены следующими префиксами, они означают:

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

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

• В 1928533 заметки SAP:
  • список размеров виртуальных машин Azure, поддерживаемых для развертывания ПО SAP;
  • Важные сведения о емкости для размеров виртуальной машины Azure.
  • Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
  • Требуемая версия ядра SAP для Windows и Linux в Azure.
• примечание к SAP 2015553, в котором описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure;
• Примечания SAP 405827 перечисляет рекомендуемую файловую систему для среды HANA.
• Примечание SAP 2684254 содержит рекомендуемые параметры ОС для SUSE Linux Enterprise Server (SLES) 15/SLES для приложений SAP 15.
• В 1944799 sap Note 1944799 есть рекомендации по установке ОС SLES ДЛЯ SAP HANA.
• примечание к 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 (HA) SUSE содержат все необходимые сведения для настройки локальной репликации системы NetWeaver и репликации системы SAP HANA (для использования в качестве общего базового плана). Они содержат намного более подробные сведения.
• вики-сайт сообщества SAP, где имеются все необходимые примечания к SAP для Linux;
• SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению
• Развертывание программного обеспечения SAP на виртуальных машинах Linux в Azure
• Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
• Общая документация по SLES:
  • Настройка кластера SAP HANA
  • Заметки о выпуске расширения SLES высокого уровня доступности 15 SP3
  • Руководство по обеспечению безопасности операционной системы для SAP HANA для SUSE Linux Enterprise Server 15
  • Руководство по SUSE Linux Enterprise Server для SAP Applications 15 SP3
  • Автоматизация SAP для SUSE Linux Enterprise Server для SAP Applications 15 SP3
  • Мониторинг SAP для SUSE Linux Enterprise Server для SAP Applications 15 SP3
• Документация по SLES для конкретной службы Azure:
  • Начало работы с автоматизацией кластеров высокой доступности SAP HANA в Azure
  • Упрощенное развертывание шаблонов решений SUSE и Microsoft для приложений SAP от Майкрософт
• Приложения NetApp SAP в Microsoft Azure. Использование Azure NetApp Files
• Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA
• SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению

Примечание.

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

Обзор

Традиционно в среде масштабирования все файловые системы sap HANA подключены из локального хранилища. Настройка высокой доступности репликации системы SAP HANA в SUSE Enterprise Linux опубликована в разделе "Настройка репликации системы SAP HANA в SLES".

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

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

Подключено к node1 (hanadb1):

• 10.3.1.4:/hanadb1-data-mnt00001 on /hana/data
• 10.3.1.4:/hanadb1-log-mnt00001 on /hana/log
• 10.3.1.4:/hanadb1-shared-mnt00001 on /hana/shared

Подключено на узле 2 (hanadb2):

• 10.3.1.4:/hanadb2-data-mnt00001 on /hana/data
• 10.3.1.4:/hanadb2-log-mnt00001 on /hana/log
• 10.3.1.4:/hanadb2-shared-mnt0001 on /hana/shared

Примечание.

Файловые системы /hana/shared, /hana/data и /hana/log не используются между двумя узлами. Каждый узел кластера имеет собственные отдельные файловые системы.

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

• IP-адрес конфигурации внешнего интерфейса: 10.3.0.50 для hn1-db
• Порт пробы: 62503

Настройка инфраструктуры Azure NetApp Files

Прежде чем продолжить настройку инфраструктуры Azure NetApp Files, ознакомьтесь с документацией по Azure NetApp Files.

Служба Azure NetApp Files доступна в нескольких регионах Azure. Проверьте, предоставляется ли служба Azure NetApp Files в выбранном регионе Azure.

Сведения о доступности Azure NetApp Files в регионе Azure см. в статье о доступности Azure NetApp Files по регионам Azure.

Важные замечания

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

Выбор размера базы данных HANA в Azure NetApp Files

Пропускная способность тома Azure NetApp Files зависит от размера тома и уровня обслуживания, как описано в разделе Уровни обслуживания для Azure NetApp Files.

При разработке инфраструктуры SAP HANA в Azure с помощью Azure NetApp Files помните о рекомендациях в томах NFS версии 4.1 в Azure NetApp Files для SAP HANA.

Конфигурация в этой статье представлена простыми томами Azure NetApp Files.

Внимание

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

Все команды для подключения /hana/shared в этой статье представлены для томов /hana/shared NFSv4.1. Если вы развернули тома /hana/shared в качестве томов NFSv3, не забудьте настроить команды подключения /hana/shared для NFSv3.

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

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

1. Создайте учетную запись NetApp в выбранном регионе Azure, следуя инструкциям в разделе Создание учетной записи NetApp.

2. Настройте пул емкости Azure NetApp Files, следуя инструкциям по настройке пула емкости Azure NetApp Files.

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

3. Делегируйте подсеть в Azure NetApp Files согласно инструкциям по делегированию подсети в Azure NetApp Files.

4. Разверните тома Azure NetApp Files, следуя инструкциям по созданию тома NFS для Azure NetApp Files.

   При развертывании томов обязательно выберите версию NFSv4.1. Разверните тома в выделенной подсети Azure NetApp Files. IP-адреса томов Azure NetApp Files назначаются автоматически.

   Ресурсы Azure NetApp Files и виртуальные машины Azure должны находиться в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure. Например, hanadb1-data-mnt00001, hanadb1-log-mnt00001 и т. д. являются именами томов, а nfs://10.3.1.4/hanadb1-data-mnt00001, nfs://10.3.1.4/hanadb1-log-mnt00001 и т. д. пути к файлам томов Azure NetApp Files.

   В hanadb1:

   • Том hanadb1-data-mnt00001 (nfs://10.3.1.4:/hanadb1-data-mnt00001)
   • Том hanadb1-log-mnt00001 (nfs://10.3.1.4:/hanadb1-log-mnt00001)
   • Том hanadb1-shared-mnt00001 (nfs://10.3.1.4:/hanadb1-shared-mnt00001)

   В hanadb2:

   • Том hanadb2-data-mnt00001 (nfs://10.3.1.4:/hanadb2-data-mnt00001)
   • Том hanadb2-log-mnt00001 (nfs://10.3.1.4:/hanadb2-log-mnt00001)
   • Том hanadb2-shared-mnt00001 (nfs://10.3.1.4:/hanadb2-shared-mnt00001)

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

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

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

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

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

Внимание

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

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

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

Портал Azure

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

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

Примечание.

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

Azure CLI

# 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

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

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

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

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

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

Внимание

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

Подключение тома Azure NetApp Files

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

   sudo mkdir -p /hana/data/HN1/mnt00001
   sudo mkdir -p /hana/log/HN1/mnt00001
   sudo mkdir -p /hana/shared/HN1
   

2. [A] Проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, то есть defaultv4iddomain.com, и сопоставление не задано никому.

   sudo cat /etc/idmapd.conf
   

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

   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

   Внимание

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

3. [A] Измените /etc/fstab оба узла, чтобы окончательно подключить тома, относящиеся к каждому узлу. В следующем примере показано, как постоянно подключать тома.

   sudo vi /etc/fstab
   

   Добавьте следующие записи на /etc/fstab обоих узлах.

   Пример для hanadb1:

   10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   

   Пример для hanadb2:

   10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   

   Подключите все тома.

   sudo mount -a
   

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

4. [A] Убедитесь, что все тома HANA подключены с помощью протокола NFS версии NFSv4.

   sudo nfsstat -m
   

   Убедитесь, что флаг vers имеет значение 4.1.

   Пример из hanadb1:

   /hana/log/HN1/mnt00001 from 10.3.1.4:/hanadb1-log-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   /hana/data/HN1/mnt00001 from 10.3.1.4:/hanadb1-data-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   /hana/shared/HN1 from 10.3.1.4:/hanadb1-shared-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   

5. [A] Проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, в которой находится nfs4_disable_idmapping , выполните команду подключения. Вы не сможете вручную создать каталог /sys/modules , так как доступ зарезервирован для ядра или драйверов.

   #Check nfs4_disable_idmapping
   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   
   #If you need to set nfs4_disable_idmapping to Y
   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   
   #Make the configuration permanent
   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

Установка SAP HANA

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

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

   sudo vi /etc/hosts
   

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

   10.3.0.4   hanadb1
   10.3.0.5   hanadb2
   

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

   sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
   

   Добавьте следующие записи в файл конфигурации:

   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
   

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

   sudo vi /etc/sysctl.d/ms-az.conf
   

   Добавьте следующие записи в файл конфигурации:

   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 управлять диапазонами портов. Дополнительные сведения см. в 2382421 заметки SAP.

4. [A] Настройте sunrpc параметры, как рекомендуется в sap Note 3024346 — Параметры ядра Linux для NetApp NFS.

   sudo vi /etc/modprobe.d/sunrpc.conf
   

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

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] Настройка SLES для HANA.

   Настройте SLES, как описано в следующих заметках SAP на основе версии SLES:

   • 2684254 Рекомендации по настройке ОС для SLES 15 / SLES для SAP Applications 15
   • 2205917 Рекомендации по настройке ОС для SLES 12 / SLES для SAP Applications 12
   • 2455582. Linux: запуск приложений SAP, скомпилированных с помощью GCC 6.x
   • 2593824. Linux: запуск приложений SAP, скомпилированных с помощью GCC 7.x
   • 2886607. Linux: запуск приложений SAP, скомпилированных с помощью GCC 9.x

6. [A] Установите SAP HANA.

   Начиная с HANA 2.0 с пакетом обновления 01 (SPS 01), контейнеры многотенантных баз данных (MDC) — это параметр по умолчанию. При установке системы HANA SYSTEMDB и клиента с одинаковым идентификатором безопасности создаются вместе. В некоторых случаях клиент по умолчанию не требуется. Если вы не хотите создать начальный клиент вместе с установкой, следуйте инструкциям в sap Note 2629711.

   1. hdblcm Запустите программу из каталога программного обеспечения установки HANA.

      ./hdblcm
      

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

      • Для выбора установки: введите 1 (для установки).
      • Для выбора дополнительных компонентов для установки: введите 1.
      • Для пути установки введите [/hana/shared]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода имени локального узла [.]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • В разделе "Добавить дополнительные узлы в систему"? (y/n) [n]: выберите n.
      • Для ввода идентификатора системы SAP HANA: введите HN1.
      • Введите номер экземпляра [00]: введите 03.
      • Для выбора режима базы данных / ВВОД индекса [1]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для выбора системного использования и ввода индекса [4]: введите 4 (для пользовательского).
      • Для ввода расположения томов данных [/hana/data]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода расположения томов журнала [/hana/log]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ограничения максимального выделения памяти? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • В поле "Введите имя узла сертификата" для узла "..." [...]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода пароля пользователя агента узла SAP (sapadm): введите пароль пользователя агента узла.
      • Для подтверждения пароля пользователя агента узла SAP (sapadm): снова введите пароль пользователя агента узла, чтобы подтвердить.
      • Для пароля системного администратора (hn1adm): введите пароль системного администратора.
      • Для подтверждения пароля системного администратора (hn1adm): введите пароль системного администратора еще раз, чтобы подтвердить.
      • Для домашнего каталога системного администратора [/usr/sap/HN1/home]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для командной консоли входа системного администратора [/bin/sh]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода идентификатора пользователя системного администратора [1001]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода идентификатора группы пользователей (sapsys) [79]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для пароля пользователя базы данных (SYSTEM): введите пароль пользователя базы данных.
      • Для подтверждения пароля пользователя базы данных (SYSTEM) введите пароль пользователя базы данных еще раз, чтобы подтвердить.
      • Для перезагрузки системы после перезагрузки компьютера? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для чего вы хотите продолжить? (y/n): проверьте сводку. Для продолжения введите y.

7. [A]. Обновите агент узла SAP.

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

   sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
   

Configuring SAP HANA System Replication (Настройка репликации системы SAP HANA)

Выполните действия, описанные в репликации системы SAP HANA, чтобы настроить репликацию системы SAP HANA.

Конфигурация кластера

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

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

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

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

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

Настройка кластерных ресурсов SAP HANA

В этом разделе описаны необходимые действия, необходимые для настройки ресурсов кластера SAP HANA.

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

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

sudo crm_mon -r

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

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

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

Файловая система /hana/shared/SID необходима как для операции HANA, так и для действий мониторинга Pacemaker, определяющих состояние HANA. Реализуйте агенты ресурсов для отслеживания и выполнения действий в случае сбоев. В разделе содержатся два варианта: один для SAPHanaSR и другой.SAPHanaSR-angi

SAPHanaSR

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

1. [A] Создайте структуру каталогов на обоих узлах.

   sudo mkdir -p /hana/shared/HN1/check
   sudo mkdir -p /hana/shared/check
   

2. [1] Настройте кластер для добавления структуры каталогов для мониторинга.

   sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
       device="/hana/shared/HN1/check/" \
       directory="/hana/shared/check/" fstype=nfs  \
       options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
       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
   

3. [1] Клонируйте и проверьте только что настроенный том в кластере.

   sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true
   

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

   sudo crm status
   
   # Cluster Summary:
   # Stack: corosync
   # Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
   # Last updated: Tue Nov  2 17:57:39 2021
   # Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
   # 2 nodes configured
   # 11 resource instances configured
   
   # Node List:
   # Online: [ hanadb1 hanadb2 ]
   
   # Full List of Resources:
   # Clone Set: cln_azure-events [rsc_azure-events]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
   #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
   # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   #  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
   #  Slaves: [ hanadb2 ]
   # Resource Group: g_ip_HN1_HDB03:
   #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
   #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
   # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
   # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   

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

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

SAPHanaSR-angi

При использовании пакета SAPHanaSR-angi и агента ресурсов он добавляет новый агент SAPHanaFilesystem для мониторинга доступа на чтение и запись к /hana/shared/SID. Файловая система /hana/shared уже подключена с записями в /etc/fstab на каждом узле. SAPHanaFilesystem и Pacemaker не подключают файловую систему для HANA и не требуют дополнительного подключения или подкаталога.

1. [1] Настройка агента SAPHanaFilesystem

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

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

Внимание

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

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

В этом разделе описано, как проверить настроенную систему.

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

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

2. Проверьте состояние ресурсов HANA с помощью следующей команды:

   SAPHanaSR-showAttr
   
   # You should see something like below
   # hanadb1:~ SAPHanaSR-showAttr
   # Global cib-time                 maintenance
   # --------------------------------------------
   # global Mon Nov  8 22:50:30 2021 false
   # Sites srHook
   # -------------
   # SITE1 PRIM
   # SITE2 SOK
   # Site2 SOK
   # Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
   # --------------------------------------------------------------------------------------------------------------------------------------------------------------
   # hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
   # hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2
   

3. Проверьте конфигурацию кластера для сценария сбоя при завершении работы узла. В следующем примере показано завершение работы узла 1:

   sudo crm status
   sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
   sudo crm resource cleanup
   

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

   sudo crm status
   
   #Cluster Summary:
   # Stack: corosync
   # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
   # Last updated: Mon Nov  8 23:25:36 2021
   # Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
   # 2 nodes configured
   # 11 resource instances configured
   
   # Node List:
   # Online: [ hanadb1 hanadb2 ]
   # Full List of Resources:
   # Clone Set: cln_azure-events [rsc_azure-events]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   #  Masters: [ hanadb2 ]
   #  Stopped: [ hanadb1 ]
   # Resource Group: g_ip_HN1_HDB03:
   #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
   #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
   # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
   # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   

   Остановите HANA на node1:

   sudo su - hn1adm
   sapcontrol -nr 03 -function StopWait 600 10
   

   Зарегистрируйте узел 1 в качестве вторичного узла и проверьте состояние:

   hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay
   

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

   #adding site ...
   #nameserver hanadb1:30301 not responding.
   #collecting information ...
   #updating local ini files ...
   #done.
   

   sudo crm status
   

   sudo SAPHanaSR-showAttr
   

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

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

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

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

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

   sudo crm  status
   
   #Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Mon Nov  8 23:01:27 2021
    # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
    # 2 nodes configured
    # 11 resource instances configured
   
    #Node List:
    # Online: [ hanadb1 hanadb2 ]
   
    #Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
      # Masters: [ hanadb1 ]
      # Slaves: [ hanadb2 ]
    # Resource Group: g_ip_HN1_HDB03:
      # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
      # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
   

   Вы можете разместить /hana/shared в режиме только для чтения на активном узле кластера с помощью следующей команды:

   sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb
   

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

   sudo crm status
   
   #Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Wed Nov 10 22:00:27 2021
    # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
    # 2 nodes configured
    # 11 resource instances configured
   
    #Node List:
    # Online: [ hanadb1 hanadb2 ]
   
    #Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
      # Masters: [ hanadb2 ]
      # Stopped: [ hanadb1 ]
    # Resource Group: g_ip_HN1_HDB03:
         # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
      # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
   

   Мы рекомендуем тщательно протестировать конфигурацию кластера SAP HANA, выполнив тесты, описанные в репликации системы SAP HANA.

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

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