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

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

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

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

Необходимые компоненты

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

• Заметка SAP 1928533, которая имеет следующее:
  • Список размеров виртуальных машин Azure, поддерживаемых для развертывания программного обеспечения SAP.
  • важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
  • Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
  • сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
• примечание к SAP 2015553, в котором описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure;
• Примечания SAP 405827 перечислены рекомендуемые файловые системы для сред HANA.
• примечание к SAP 2002167, содержащее рекомендуемые параметры ОС для Red Hat Enterprise Linux;
• примечание к SAP 2009879, содержащее рекомендации по SAP HANA для Red Hat Enterprise Linux;
• Примечание SAP 3108302 содержит рекомендации ПО SAP HANA для Red Hat Enterprise Linux 9.x.
• примечание к SAP 2178632, содержащее подробные сведения обо всех доступных метриках мониторинга для SAP в Azure;
• примечание к SAP 2191498, содержащее сведения о необходимой версии агента SAP Host Agent для Linux в Azure;
• примечание к SAP 2243692, содержащее сведения о лицензировании SAP в Linux в Azure;
• примечание к SAP 1999351, в котором приведены дополнительные сведения об устранении неполадок, связанных с расширением для расширенного мониторинга Azure для SAP;
• вики-сайт сообщества SAP, где имеются все необходимые примечания к SAP для Linux;
• SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению
• Развертывание программного обеспечения SAP на виртуальных машинах Linux в Azure
• Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
• Репликация системы SAP HANA в кластере Pacemaker
• Общая документация По Red Hat Enterprise Linux (RHEL):
  • Общие сведения о надстройке для обеспечения высокой доступности
  • Администрирование надстройки для обеспечения высокой доступности
  • Справочник по надстройке для обеспечения высокой доступности
  • Настройка репликации системы SAP HANA в масштабировании в кластере Pacemaker, когда файловые системы HANA находятся в общих папках NFS
• Документация по RHEL для конкретной службы Azure:
  • Политики поддержки для кластеров высокой доступности RHEL — виртуальные машины Microsoft Azure как члены кластера
  • Установка и настройка кластера высокой доступности Red Hat Enterprise Linux 7.4 (и более поздних версий) в Microsoft Azure
  • Настройка репликации системы sap HANA в кластере Pacemaker при использовании файловых систем HANA в общих папках NFS
• Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA

Обзор

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

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

.

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

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

• 10.32.2.4:/hanadb1-data-mnt00001 в /hana/data
• 10.32.2.4:/hanadb1-log-mnt00001 в /hana/log
• 10.32.2.4:/hanadb1-shared-mnt00001 в /hana/shared

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

• 10.32.2.4:/hanadb2-data-mnt00001 в /hana/data
• 10.32.2.4:/hanadb2-log-mnt00001 в /hana/log
• 10.32.2.4:/hanadb2-shared-mnt00001 в /hana/shared

Примечание.

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

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

• Интерфейсный IP-адрес: 10.32.0.10 для 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.

Развертывание ресурсов 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.32.2.4/hanadb1-data-mnt00001 nfs://10.32.2.4/hanadb1-log-mnt00001 пути к файлам томов Azure NetApp Files.

   В hanadb1:

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

   В hanadb2:

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

Примечание.

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

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

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

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

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

Развертывание виртуальных машин для SAP HANA. Выберите подходящий образ RHEL, поддерживаемый для системы 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-адреса) в Azure Load Balancer уровня "Стандартный", исходящие подключения к Интернету отсутствуют, если только не выполняется дополнительная настройка, чтобы разрешить маршрутизацию на общедоступные конечные точки. Дополнительные сведения о том, как достичь исходящего подключения, см. в статье "Подключение к общедоступной конечной точке" для виртуальных машин с помощью Azure Load Balancer уровня "Стандартный" в сценариях высокой доступности SAP.

Внимание

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

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

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

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

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

3. [1] Подключите тома, относящиеся к узлу 1 (hanadb1).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
   

4. [2] Подключите тома, относящиеся к узлу, на узле 2 (hanadb2).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
   

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

   sudo nfsstat -m
   

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

   /hana/log from 10.32.2.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.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/data from 10.32.2.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.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/shared from 10.32.2.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.32.0.4,local_lock=none,addr=10.32.2.4
   

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

   Проверьте nfs4_disable_idmapping.

   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Если вам нужно задать следующее:nfs4_disable_idmapping

   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Создание постоянной конфигурации.

   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   Дополнительные сведения об изменении параметра см. в базе знаний nfs_disable_idmapping Red Hat.

Установка SAP HANA

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

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

   sudo vi /etc/hosts
   

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

   10.32.0.4   hanadb1
   10.32.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] Выполните конфигурацию ОС RHEL для HANA.

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

   • 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (Примечание по поддержке SAP № 2292690. База данных SAP HANA: рекомендуемые параметры операционной системы для RHEL 7).
   • 2777782. SAP HANA DB: рекомендуемые параметры ОС для RHEL 8;
   • 2455582. Linux: запуск приложений SAP, скомпилированных с помощью GCC 6.x;
   • 2593824. Linux: запуск приложений SAP, скомпилированных с помощью GCC 7.x;
   • 2886607. Linux: запуск приложений SAP, скомпилированных с помощью GCC 9.x.

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

   Начиная с HANA 2.0 SPS 01, по умолчанию используется MDC. При установке системы HANA SYSTEMDB и клиента с одинаковым идентификатором безопасности создаются вместе. В некоторых случаях клиент по умолчанию не требуется. Если вы не хотите создать начальный клиент вместе с установкой, вы можете следовать за заметками SAP 2629711.

   Запустите программу hdblcm с DVD-диска HANA. Введите следующие значения на запрос в командной строке:

   1. Выберите установку: введите 1 (для установки).
   2. Выберите дополнительные компоненты для установки: введите 1.
   3. Введите путь установки [/hana/shared]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   4. Введите имя локального узла [..]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию. "Do you want to add additional hosts to the system? (y/n)" (y/n) [n]: n.
   5. Введите идентификатор системы SAP HANA: введите HN1.
   6. Введите номер экземпляра [00]: введите 03.
   7. Выберите режим базы данных / Введите индекс [1]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   8. Выберите системное использование и введите индекс [4]: введите 4 (для пользовательского).
   9. Введите расположение томов данных [/hana/data]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   10. Введите расположение томов журналов [/hana/log]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   11. Restrict maximum memory allocation? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   12. Введите имя узла сертификата "..." [...]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   13. Введите пароль пользователя агента узла SAP (sapadm): введите пароль пользователя агента узла.
   14. Подтвердите пароль пользователя агента узла SAP (sapadm): снова введите пароль пользователя агента узла, чтобы подтвердить.
   15. Введите пароль системного администратора (hn1adm): введите пароль системного администратора.
   16. Подтвердите пароль системного администратора (hn1adm): введите пароль системного администратора еще раз, чтобы подтвердить.
   17. Введите домашний каталог системного администратора [/usr/sap/HN1/home]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   18. Введите оболочку входа системного администратора [/bin/sh]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   19. Введите идентификатор пользователя системного администратора [1001]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   20. Введите идентификатор группы пользователей (sapsys) [79]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   21. Введите пароль пользователя базы данных (SYSTEM): введите пароль пользователя базы данных.
   22. Подтвердите пароль пользователя базы данных (SYSTEM): снова введите пароль пользователя базы данных, чтобы подтвердить.
   23. Restart system after machine reboot? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
   24. Вы действительно хотите продолжить? (y/n): проверьте сводку. Для продолжения введите y.

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

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

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

8. [A] Настройка брандмауэра.

   Создайте правило брандмауэра для порта пробы Azure Load Balancer.

   sudo firewall-cmd --zone=public --add-port=62503/tcp
   sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
   

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

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

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

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

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

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

Внимание

Благодаря системной платформе SAP Startup Framework экземпляры SAP HANA теперь могут управляться системой. Минимальная требуемая версия Red Hat Enterprise Linux (RHEL) — RHEL 8 для SAP. Как описано в примечании к SAP 3189534, все новые установки SAP HANA SPS07 версии 70 или более поздней версии или обновления систем HANA до версии HANA 2.0 SPS07 версии 70 или более поздней версии, платформа запуска SAP будет автоматически зарегистрирована в системном режиме.

При использовании решений высокого уровня доступности для управления репликацией системы SAP HANA в сочетании с экземплярами SAP HANA с поддержкой системы (см. примечание SAP 3189534), необходимо выполнить дополнительные действия, чтобы кластер высокого уровня доступности может управлять экземпляром SAP без системного вмешательства. Поэтому для системы SAP HANA, интегрированной с системой, необходимо выполнить дополнительные шаги, описанные в Red Hat KBA 7029705 на всех узлах кластера.

Внедрение перехватчика репликации системы Python для SAPHanaSR

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

Настройка ресурсов файловой системы

В этом примере каждый узел кластера имеет собственные файловые системы /hana/shared/hana/dataHANA NFS и /hana/log.

1. [1] Переключите кластер в режим обслуживания.

   sudo pcs property set maintenance-mode=true
   

2. [1] Создайте ресурсы файловой системы для подключений hanadb1 .

   sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   

3. [2] Создайте ресурсы файловой системы для подключений hanadb2 .

   sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   

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

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

   Когда ресурс SAPHana зависит от неисправного ресурса, такое поведение не только занимает много времени, но также может привести к общему сбою. Ресурс SAPHana не может успешно остановиться, если сервер NFS, содержащий исполняемые файлы HANA, недоступен.

   Предлагаемые значения времени ожидания позволяют ресурсам кластера противостоять приостановке, связанной с возобновлением аренды NFSv4.1. Дополнительные сведения см. в статье NFS в netApp Best practices. Время ожидания в предыдущей конфигурации может потребоваться адаптировать к определенной настройке SAP.

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

4. [1] Настройте ограничения расположения.

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

   sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
   sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
   

   Параметр resource-discovery=never задается потому, что уникальные подключения для каждой общей папки узла имеют одну и ту же точку подключения. Например, hana_data1 использует точку подключения /hana/data, и hana_data2 тоже использует точку подключения /hana/data. Совместное использование той же точки подключения может привести к ложноположительным срабатыванию операции пробы, когда состояние ресурса проверяется при запуске кластера, и в свою очередь может привести к ненужному поведению восстановления. Чтобы избежать этого сценария, установите для resource-discovery=neverэтого параметра.

5. [1] Настройка ресурсов атрибутов.

   Настройте ресурсы атрибутов. Эти атрибуты имеют значение true, если подключены все подключения NFS узла (/hana/data, /hana/logи /hana/data) . В противном случае для них задано значение false.

   sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
   sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
   

6. [1] Настройте ограничения расположения.

   Настройте ограничения расположения, чтобы гарантировать, что ресурс атрибута hanadb1 никогда не выполняется в hanadb2 и наоборот.

   sudo pcs constraint location hana_nfs1_active avoids hanadb2
   sudo pcs constraint location hana_nfs2_active avoids hanadb1
   

7. [1] Создание ограничений упорядочивания.

   Настройте ограничения упорядочивания, чтобы запускать ресурсы атрибутов узла только после подключения всех подключений NFS узла.

   sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
   sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
   

   Совет

   Если конфигурация включает в себя файловые системы, вне группы hanadb1_nfs или hanadb2_nfsвключите sequential=false параметр, чтобы между файловыми системами не было упорядочения зависимостей. Все файловые системы должны начинаться раньше hana_nfs1_active, но они не должны запускаться в любом порядке относительно друг друга. Дополнительные сведения см. в статье Разделы справки настройка репликации системы SAP HANA в масштабируемом кластере Pacemaker при использовании файловых систем HANA в общих папках NFS

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

1. Выполните действия, описанные в разделе "Создание ресурсов кластера SAP HANA", чтобы создать ресурсы SAP HANA в кластере. После создания ресурсов SAP HANA необходимо создать ограничение правила расположения между ресурсами SAP HANA и файловыми системами (подключения NFS).

2. [1] Настройте ограничения между ресурсами SAP HANA и подключениями NFS.

   Ограничения правил расположения задаются таким образом, чтобы ресурсы SAP HANA могли выполняться на узле, только если подключены все подключения NFS узла.

   sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   В RHEL 7.x:

   sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   В RHEL 8.x/9.x:

   sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

3. [1] Настройте ограничения упорядочивания, чтобы ресурсы SAP на узле остановились перед остановкой для любого из подключений NFS.

   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
   

   В RHEL 7.x:

   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
   

   В RHEL 8.x/9.x:

   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
   

   Вывести кластер из режима обслуживания.

   sudo pcs property set maintenance-mode=false
   

   Проверьте состояние кластера и всех ресурсов.

   Примечание.

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

   sudo pcs status
   

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

   Online: [ hanadb1 hanadb2 ]
   
   Full list of resources:
   
   rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1
   
   Resource Group: hanadb1_nfs
   hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
   hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
   hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1
   
   Resource Group: hanadb2_nfs
   hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
   hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
   hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2
   
   hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
   hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2
   
   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
   Started: [ hanadb1 hanadb2 ]
   
   Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
   Masters: [ hanadb1 ]
   Slaves: [ hanadb2 ]
   
   Resource Group: g_ip_HN1_03
   nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
   vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1
   

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

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

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

Дополнительная конфигурация, которая требуется для управления HANA активной и считываемой системной репликации в кластере Red Hat HA со вторым виртуальным IP-адресом, описана в разделе "Настройка репликации системы с поддержкой HANA Active/Read-Enabled" в кластере Pacemaker.

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

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

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

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

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

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

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

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

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

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

   sudo pcs status
   

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

   Full list of resources:
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1
   
   Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb1 hanadb2 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb1 ]
        Slaves: [ hanadb2 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1
   

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

   sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   

   hanadb перезагрузится или выключится на основе действия, установленного stonith (pcs property show stonith-action). После того как сервер (hanadb1) будет отключен, ресурс HANA переходит в hanadb2. Вы можете проверить состояние кластера.hanadb2

   sudo pcs status
   

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

   Full list of resources:
   
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Stopped
        hana_log1  (ocf::heartbeat:Filesystem):    Stopped
        hana_shared1       (ocf::heartbeat:Filesystem):    Stopped
   
    Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2
   

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

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

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