Обеспечение высокого уровня доступности IBM DB2 LUW на виртуальных машинах Azure в SUSE Linux Enterprise Server с использованием Pacemaker

IBM Db2 для Linux, Unix и Windows (LUW) в конфигурации высокой доступности и аварийного восстановления (HADR) содержит один узел, на котором выполняется экземпляр базы данных-источника, и по крайней мере один узел, на котором выполняется экземпляр базы данных-получателя. Изменения в основном экземпляре базы данных реплицируются во вторичный экземпляр базы данных синхронно или асинхронно в зависимости от конфигурации.

В этой статье описывается, как развернуть и настроить виртуальные машины Azure, установить платформу кластера и конфигурацию IBM Db2 LUW с HADR.

В ней не рассматривается установка и настройка IBM Db2 LUW с установкой программного обеспечения HADR или SAP. Чтобы помочь вам в выполнении этих задач, мы предоставляем ссылки на руководства по установке SAP и IBM. В этой статье рассматриваются элементы, относящиеся к среде Azure.

Поддерживаемые версии IBM Db2 — 10.5 и более поздние версии, как описано в заметке SAP 1928533.

Перед началом установки ознакомьтесь со следующими заметками и документацией ПО SAP:

Обзор

Чтобы обеспечить высокий уровень доступности, IBM Db2 LUW с HADR устанавливается по крайней мере на двух виртуальных машинах Azure. Эти виртуальные машины развертываются в масштабируемом наборе виртуальных машин с гибкой оркестрацией между зонами доступности или в группе доступности.

На рисунках ниже показано, как настроить две виртуальные машины Azure сервера базы данных. У обеих виртуальных машин Azure для сервера базы данных есть собственное хранилище, и они работают. В HADR один экземпляр базы данных на одной из виртуальных машин Azure выполняет роль экземпляра-источника. Все клиенты подключены к этому основному экземпляру. Все изменения в транзакциях базы данных сохраняются локально в журнале транзакций Db2. Так как записи журнала транзакций сохраняются локально, записи передаются через TCP/IP в экземпляр базы данных на втором сервере базы данных. Передача записей может осуществляться на резервном сервере или резервном экземпляре. Резервный экземпляр обновляет локальную базу данных, выполняя накат переданных записей журнала транзакций. Таким образом резервный сервер остается синхронизированным с сервером-источником.

HADR является исключительно функцией репликации. Эта система не имеет функции обнаружения сбоев и не поддерживает автоматическое переключение или восстановление после отказа. Для перехода на резервный сервер требуется запуск вручную администратором базы данных. Чтобы обеспечить автоматическое перенаправление и обнаружение сбоев, можно использовать функцию кластеризации Pacemaker в Linux. Pacemaker отслеживает два экземпляра сервера базы данных. При сбое основного экземпляра сервера базы данных Pacemaker инициирует автоматическое перенаправление HADR на резервный сервер. Pacemaker также гарантирует, что виртуальный IP-адрес будет назначен новому серверу-источнику.

Чтобы серверы приложений SAP подключались к базе данных-источнику, требуется имя виртуального узла и виртуальный IP-адрес. После переключения на резервный узел серверы приложений SAP подключаются к новому основному экземпляру базы данных. В среде Azure подсистема балансировки нагрузки Azure требуется для использования виртуального IP-адреса, как это требуется для HADR IBM Db2.

Чтобы понять, как IBM Db2 LUW с HADR и Pacemaker вписывается в высокодоступную настройку системы SAP, см. следующий образ. В нем представлен обзор высокодоступной системы SAP на основе базы данных IBM Db2. В этой статье рассматривается только IBM Db2, но приведены ссылки на статьи о настройке других компонентов системы SAP.

Общий обзор необходимых действий

Чтобы развернуть конфигурацию IBM Db2, необходимо выполнить указанные ниже действия.

• Спланируйте свою среду.
• Разверните виртуальные машины.
• Обновите ОС Linux SUSE и настройте файловые системы.
• Установите и настройте Pacemaker.
• Установите высокодоступный сетевой файловый ресурс (NFS).
• Установите ASCS/ERS в отдельном кластере.
• Установите базу данных IBM Db2 с параметром распределенной или высокой доступности (диспетчер подготовки программного обеспечения (SWPM)).
• Установите и создайте вторичный узел и экземпляр базы данных, и настройте HADR.
• Убедитесь, что HADR работает.
• Примените конфигурацию Pacemaker для управления IBM Db2.
• Настройте Azure Load Balancer.
• Установите основные и диалоговые серверы приложений.
• Проверьте и адаптируйте конфигурацию серверов приложений SAP.
• Выполните тестирование отработки отказа и захвата управления.

Планирование инфраструктуры Azure для размещения IBM Db2 LUW с HADR

Завершите планирование, прежде чем выполнять развертывание. Планирование обеспечит основу для развертывания конфигурации Db2 с HADR в Azure. Ключевые элементы, которые должны быть частью планирования ДЛЯ IBM Db2 LUW (часть базы данных среды SAP), перечислены в следующей таблице:

Дополнительные сведения о Pacemaker для Linux в Azure см. в статье Настройка Pacemaker в SUSE Linux Enterprise Server в Azure.

Развертывание в SUSE Linux

Агент ресурсов для IBM Db2 LUW включен в состав SUSE Linux Enterprise Server для приложений SAP. Для установки, описанной в этом документе, необходимо использовать SUSE Linux Server для приложений SAP. Azure Marketplace содержит образ SUSE Enterprise Server для приложений SAP 12, который можно использовать для развертывания новых виртуальных машин Azure. Ознакомьтесь с предложениями SUSE для поддержки и служб в Azure Marketplace перед выбором образа виртуальной машины.

Хосты: обновления DNS

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

Ручное развертывание

Убедитесь, что выбранная ОС для IBM/SAP для IBM Db2 LUW поддерживается. Список поддерживаемых версий ОС для виртуальных машин Azure и выпусков Db2 доступен в sap Note 1928533. Список выпусков ОС для отдельных версий Db2 доступен в матрице доступности продуктов SAP. Мы настоятельно рекомендуем использовать как минимум SLES 12 SP4 ввиду улучшений производительности для операций Azure, реализованных в этой и более поздних версиях SUSE Linux.

1. Создайте или выберите группу ресурсов.
2. Создайте или выберите виртуальную сеть и подсеть.
3. Выберите подходящий тип развертывания для виртуальных машин SAP. Обычно это масштабируемый набор виртуальных машин с гибкой оркестрацией.
4. Создайте виртуальную машину 1.
   1. Используйте SLES для образа SAP в Azure Marketplace.
   2. Выберите масштабируемый набор, зону доступности или группу доступности, созданную на шаге 3.
5. Создайте виртуальную машину 2.
   1. Используйте SLES для образа SAP в Azure Marketplace.
   2. Выберите набор для масштабирования, зону доступности или группу доступности, созданный на шаге 3 (не ту же зону, что и на шаге 4).
6. Добавьте диски данных на виртуальные машины. Ознакомьтесь с рекомендацией по настройке файловой системы в статье о развертывании СУБД ВИРТУАЛЬНЫх машин Azure IBM Db2 для рабочей нагрузки SAP.

Установка IBM Db2 LUW и среды SAP

Прежде чем начинать установку среды SAP на основе IBM Db2 LUW, ознакомьтесь со следующей документацией:

• Документация по Azure
• документация SAP;
• документация IBM.

Ссылки на эту документацию приведены во вводном разделе этой статьи. Ознакомьтесь с руководствами по установке SAP, в которых описывается установка приложений на основе NetWeaver в IBM Db2 LUW. Эти руководства можно найти на справочном портале SAP с помощью средства поиска руководств по установке SAP.

Количество руководств, отображаемых на портале, можно уменьшить, установив следующие фильтры:

• Я хочу установить новую систему.
• "My Database" (Моя база данных): "IBM Db2 for Linux, Unix, and Windows" (IBM Db2 для Linux, Unix и Windows);
• Другие фильтры для версий SAP NetWeaver, конфигурации стека или операционной системы

Указания по установке IBM Db2 LUW с HADR

Чтобы настроить основной экземпляр базы данных IBM Db2 LUW, выполните указанные ниже действия.

• Выберите высокодоступную или распределенную конфигурацию.
• Установите SAP ASCS/ERS и экземпляр базы данных.
• Создайте резервную копию установленной базы данных.

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

1. Выберите параметр Копирование системы>Целевые системы>Распределенные>Экземпляр базы данных.

2. В качестве метода копирования выберите Homogeneous System (Однородная система), чтобы можно было использовать резервное копирование для восстановления резервной копии на резервном экземпляре сервера.

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

4. Настройте HADR для IBM DB2.

   Примечание.

   Для установки и настройки, специфичных для Azure и Pacemaker, во время процедуры установки с помощью SAP Software Provisioning Manager будет задан явный вопрос о высокой доступности для IBM Db2 LUW.

   • Не выбирайте IBM Db2 pureScale.
   • Не выбирайте установку IBM Tivoli System Automation для мультиплатформ.
   • Не нажимайте кнопку "Создать файлы конфигурации кластера".

При использовании устройства SBD для Linux Pacemaker задайте следующие параметры HADR для Db2:

• длительность окна пиринга HADR (в секундах) (HADR_PEER_WINDOW) = 300;
• значение времени ожидания HADR (HADR_TIMEOUT) = 60.

При использовании агента ограждения Azure Pacemaker задайте следующие параметры:

• длительность окна пиринга HADR (в секундах) (HADR_PEER_WINDOW) = 900;
• значение времени ожидания HADR (HADR_TIMEOUT) = 60.

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

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

Проверка IBM Db2 HADR

После настройки HADR и отображения состояния PEER и CONNECTED на основных и резервных узлах выполните следующую проверку:

Execute command as db2<sid> db2pd -hadr -db <SID>

# Primary output:
# Database Member 0 -- Database PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
#
#                             HADR_ROLE = PRIMARY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 1
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6137
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 13
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#        STANDBY_RECV_REPLAY_GAP(bytes) = 0
#                      PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#                      STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
#              READS_ON_STANDBY_ENABLED = N

# Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
#
#                             HADR_ROLE = STANDBY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 0
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6186
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 5
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#        STANDBY_RECV_REPLAY_GAP(bytes) = 155
#                      PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#                      STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
#              READS_ON_STANDBY_ENABLED = N

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

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

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

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

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

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

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

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

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

Чтобы создать базовый кластер Pacemaker для этого сервера IBM Db2, см. статью Настройка Pacemaker на SUSE Linux Enterprise Server в Azure.

Конфигурация Pacemaker для Db2

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

Ниже перечислены элементы, которые имеют префиксы:

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

[A] Необходимые условия для настройки Pacemaker:

• Завершите работу обоих серверов базы данных от имени пользователя db2<sid>, выполнив команду db2stop.
• Измените среду оболочки для пользователя db2<sid> на /bin/ksh. Рекомендуется использовать средство YaST.

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

1. [1]: конфигурация Pacemaker для IBM Db2 HADR:

   # Put Pacemaker into maintenance mode
   sudo crm configure property maintenance-mode=true
   

2. [1]: создайте ресурсы IBM Db2:

   # Replace (" ") with your values for the instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   
   sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \
           params instance="db2ptr" dblist="PTR" \
           op start interval="0" timeout="130" \
           op stop interval="0" timeout="120" \
           op promote interval="0" timeout="120" \
           op demote interval="0" timeout="120" \
           op monitor interval="30" timeout="60" \
           op monitor interval="31" role="Master" timeout="60"
   
   # Configure virtual IP - same as Azure Load Balancer IP
   
   sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \
           op monitor interval="10s" timeout="20s" \
           params ip="10.100.0.10"
   
   # Configure probe port for Azure load Balancer
   
   sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \
           op monitor timeout=20s interval=10
   
   sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR
   
   sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \
           meta target-role="Started" notify="true"
   
   sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master
   
   sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start
   
   sudo crm configure rsc_defaults resource-stickiness=1000
   sudo crm configure rsc_defaults migration-threshold=5000
   

3. [1]: запустите ресурсы IBM Db2:

   Переведите Pacemaker из режима обслуживания.

   # Put Pacemaker out of maintenance-mode - that start IBM Db2
   sudo crm configure property maintenance-mode=false
   

4. [1]: убедитесь, что кластер находится в состоянии "ОК" и все ресурсы запущены. При этом не имеет значения, на каком узле выполняются ресурсы.

   sudo crm status
   
   # 2 nodes configured
   # 5 resources configured
   
   # Online: [ azibmdb01 azibmdb02 ]
   
   # Full list of resources:
   
   # stonith-sbd    (stonith:external/sbd): Started azibmdb02
   # Resource Group: g_ip_db2ptr_PTR
   #      rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
   #      rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
   # Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
   #      Masters: [ azibmdb02 ]
   #      Slaves: [ azibmdb01 ]
   

Внесение изменений в профили SAP для использования виртуального IP-адреса для подключения

Чтобы подключиться к основному экземпляру конфигурации HADR, прикладной уровень SAP должен использовать виртуальный IP-адрес, который вы определили и настроили для Azure Load Balancer. Требуются следующие изменения:

/sapmnt/<SID>/profile/DEFAULT.PFL

SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname

/sapmnt/<SID>/global/db6/db2cli.ini

Hostname=db-virt-hostname

Установка сервера-источника и диалоговых серверов приложений

При установке основных и диалоговых серверов приложений для конфигурации DB2 HADR используйте имя виртуального узла, выбранное для конфигурации.

Если вы выполнили установку до того, как создали конфигурацию Db2 HADR, внесите изменения, описанные в предыдущем разделе, а также изменения, касающиеся стеков SAP Java.

Проверка URL-адреса JDBC для систем на стеке ABAP+Java или Java

Используйте инструмент настройки J2EE для проверки или обновления URL-адреса JDBC. Так как инструмент настройки J2EE использует графический интерфейс, необходимо установить X-сервер:

1. Войдите на основной сервер приложений экземпляра J2EE и выполните:

   sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh
   

2. В левой области выберите security store (Хранилище безопасности).

3. В правой области выберите ключ jdbc/pool/<SAPSID>/url.

4. Измените имя узла в URL-адресе JDBC на имя виртуального узла.

   jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0
   

5. Выберите Добавить.

6. Чтобы сохранить изменения, щелкните значок диска в левом верхнем углу.

7. Закройте инструмент настройки.

8. Перезапустите экземпляр Java.

Настройка архивации журналов для конфигурации HADR

Чтобы настроить архивацию журналов Db2 для конфигурации HADR, рекомендуется настроить базу данных-источник и резервную базу данных для автоматического получения журналов из всех расположений архивов журналов. Обе, основная и резервная, базы данных должны иметь возможность получать файлы архивов журналов из всех расположений архивов журналов, в которые любой из экземпляров базы данных может архивировать файлы журнала.

База данных-источник является единственной, которая выполняет архивацию журналов. При изменении ролей HADR серверов базы данных или при возникновении сбоя за архивирование журналов отвечает новая база данных-источник. Если настроено несколько расположений архива журналов, журналы могут быть архивироваться дважды. Если требуется локальная или удаленная синхронизация, вам также может понадобиться вручную скопировать архивные журналы со старого основного сервера в расположение активных журналов нового основного сервера.

Настоятельно рекомендуется настроить общее хранилище NFS для записи журналов с обоих узлов. Общий ресурс NFS должен быть высокодоступным.

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

• Высокий уровень доступности для NFS на виртуальных машинах Azure на SUSE Linux Enterprise Server.
• Высокая доступность для SAP NetWeaver на виртуальных машинах Azure на SUSE Linux Enterprise Server с Azure NetApp Files для приложений SAP.
• Azure NetApp Files (для создания общих папок NFS).

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

В этом разделе описано, как можно проверить конфигурацию Db2 с HADR. Каждый тест предполагает, что вы вошли в систему в качестве корневого пользователя , а основной сервер IBM Db2 выполняется на виртуальной машине azibmdb01 .

Начальное состояние для всех тестовых случаев объясняется здесь: (crm_mon -r или crm status)

• crm status — это моментальный снимок состояния Pacemaker во время выполнения.
• crm_mon -r — непрерывный вывод состояния Pacemaker.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   Promoting azibmdb01
     Slaves: [ azibmdb02 ]

Исходное состояние в системе SAP описано в разделе "Транзакция DBACOCKPIT" > "Конфигурация" > "Обзор", как показано на следующем рисунке:

Тестирование захвата IBM Db2

Перенесите узел, на котором выполняется база данных-источник Db2, выполнив следующую команду:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

После завершения переноса выходные данные команды crm status должны выглядеть следующим образом:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

Исходное состояние в системе SAP описано в разделе "Транзакция DBACOCKPIT" > "Конфигурация" > "Обзор", как показано на следующем рисунке:

При переносе ресурсов с помощью команды crm resource migrate создаются ограничения расположения. Ограничения расположения должны быть удалены. Если ограничения по расположению не удаляются, ресурс не может вернуться к исходному состоянию после сбоя или могут произойти нежелательные переключения на другой ресурс.

Перенесите ресурс обратно на виртуальную машину azibmdb01 и очистите ограничения расположения.

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR

• crm resource migrate <res_name> <host>: создает ограничения расположения и может вызвать проблемы с переходом
• crm resource clear <res_name>: очищает ограничения расположения
• crm resource cleanup <res_name>: очищает все ошибки ресурса

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

В этом случае мы протестируем ограждение SBD (это рекомендуется делать при использовании SUSE Linux).

azibmdb01:~ # ps -ef|grep sbd
root       2374      1  0 Feb05 ?        00:00:17 sbd: inquisitor
root       2378   2374  0 Feb05 ?        00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root       2379   2374  0 Feb05 ?        00:01:51 sbd: watcher: Pacemaker
root       2380   2374  0 Feb05 ?        00:00:18 sbd: watcher: Cluster

azibmdb01:~ # kill -9 2374

Узел кластера azibmdb01 должен перезагрузиться. Роль первичного HADR для IBM Db2 будет перемещена на azibmdb02. Когда azibmdb01 восстановит подключение, экземпляр Db2 будет переведен в роль вторичного экземпляра базы данных.

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

sudo service pacemaker start

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

Вы можете протестировать переход вручную, остановив службу Pacemaker на узле azibmdb01 :

service pacemaker stop

Ниже приведен пример состояния для azibmdb02:

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

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

service pacemaker start

Завершение процесса Db2 на узле, на котором выполняется база данных-источник HADR

#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0

azibmdb01:~ # kill -9 34598

Экземпляр Db2 выйдет из строя, и Pacemaker представляет следующий отчёт о состоянии:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Slaves: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

Завершите процесс Db2 на узле, где выполняется вторичный экземпляр базы данных.

azibmdb02:~ # ps -ef|grep db2s
db2ptr    65250  65248  0 Feb11 ?        00:09:27 db2sysc 0

azibmdb02:~ # kill -9

Узел переходит в неработоспособное состояние, и сообщается об ошибке.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb02
     Masters: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

Экземпляр Db2 перезагружается в вторичной роли, назначаемой ранее.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

Остановка базы данных с помощью команды db2stop force на узле, на котором выполняется экземпляр базы данных-источника HADR

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Когда пользователь db2<sid> выполняет командуdb2stop force:

azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force

Обнаружен сбой:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb01
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms

Экземпляр базы данных-получателя Db2 HADR был повышен до основной роли:

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms

Симулированный сбой первичного узла виртуальной машины с автоматической перезагрузкой в HADR.

#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger

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

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Сбой основного узла виртуальной машины без перезагрузки ("сценарий остановки") в HADR

#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger

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

2 nodes configured
5 resources configured

Node azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

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

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Если на узле происходит событие "остановки", неработающий узел необходимо перезапустить с помощью средств управления Azure (на портале Azure, PowerShell или Azure CLI). После восстановления подключения неисправного узла он запускает экземпляр Db2 во второстепенной роли.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
 Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
 Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

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

• Архитектура и сценарии высокой доступности для SAP NetWeaver
• Настройте Pacemaker на SUSE Linux Enterprise Server на платформе Azure