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

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 для использования виртуального IP-адреса необходима подсистема балансировки нагрузки Azure . Это обусловлено требованиями HADR для IBM Db2.

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

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

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

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

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

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

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

Развертывание в Red Hat Enterprise Linux

Агент ресурсов для IBM Db2 LUW входит в состав надстройки HA для Red Hat Enterprise Linux Server. Для конфигурации, описанной в этом документе, следует использовать Red Hat Enterprise Linux для SAP. В Azure Marketplace доступен образ Red Hat Enterprise Linux 7.4 для SAP или более поздней версии, который можно использовать для развертывания новых виртуальных машин Azure. При выборе образа виртуальной машины в Azure Marketplace следует учитывать различные модели поддержки или служб, предлагаемые Red Hat в Azure Marketplace.

Узлы: обновления DNS

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

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

Убедитесь, что выбранная ОС поддерживается IBM и SAP для развертывания IBM Db2 LUW. Список поддерживаемых версий ОС для виртуальных машин Azure и выпусков Db2 доступен в примечании SAP 1928533. Список выпусков ОС для отдельных версий Db2 доступен в матрице доступности продуктов SAP. Мы настоятельно рекомендуем использовать как минимум Red Hat Enterprise Linux 7.4 для SAP ввиду улучшений производительности для операций Azure, реализованных в этой и более поздних версиях Red Hat Enterprise Linux.

1. Создайте или выберите группу ресурсов.
2. Создайте или выберите виртуальную сеть и подсеть.
3. Выберите подходящий тип развертывания для виртуальных машин SAP. Обычно масштабируемый набор виртуальных машин с гибкой оркестрацией.
4. Создайте виртуальную машину 1.
   1. Используйте образ Red Hat Enterprise Linux для SAP из Azure Marketplace.
   2. Выберите масштабируемый набор, зону доступности или группу доступности, созданную на шаге 3.
5. Создайте виртуальную машину 2.
   1. Используйте образ Red Hat Enterprise Linux для SAP из Azure Marketplace.
   2. Выберите масштабируемый набор, зону доступности или группу доступности, созданную на шаге 3 (не ту же зону, что и на шаге 4).
6. Добавьте диски данных в виртуальные машины, а затем сверьтесь с рекомендациями по установке файловой системы в статье Развертывание СУБД IBM DB2 на виртуальных машинах Azure для рабочей нагрузки SAP.

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

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

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

Ссылки на эту документацию приведены во вводном разделе этой статьи.

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

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

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

Правила брандмауэра Red Hat

По умолчанию в Red Hat Enterprise Linux включен брандмауэр.

#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp

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

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

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

Параметры IBM Db2 HADR для Azure

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

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

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

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

1. Выберите параметр System copy (Копирование системы)>Target systems (Целевые системы)>Distributed (Распределенные)>Database instance (Экземпляр базы данных).
2. В качестве метода копирования выберите Homogeneous System (Однородная система), чтобы можно было использовать резервное копирование для восстановления резервной копии на резервном экземпляре сервера.
3. Когда вы дойдете до завершающего шага — восстановления базы данных — при копировании однородной системы, выйдите из установщика. Восстановите базу данных из резервной копии основного узла. Все последующие этапы установки уже выполнены на сервере базы данных-источника.

Правила брандмауэра Red Hat для DB2 с HADR

Добавьте правила брандмауэра, чтобы разрешить передачу трафика в DB2 и между экземплярами DB2. Это необходимо для работы HADR.

• Порт связи базы данных. Если используются секции, укажите также и их порты.
• Порт HADR (значение параметра DB2 HADR_LOCAL_SVC).
• Порт пробы Azure.

sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload

Проверка IBM Db2 HADR

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

Когда после настройки функции HADR она перейдет в состояния "PEER" (Пиринг) и "CONNECTED" (Подключено) на основном и резервном узлах, выполните следующую проверку:

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

#Primary output:
Database Member 0 -- Database ID2 -- Active -- Up 1 days 15:45:23 -- Date 2019-06-25-10.55.25.349375

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.076494 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 5
                   HEARTBEAT_EXPECTED = 52
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 5
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 132242668
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 300
                      PEER_WINDOW_END = 06/25/2019 11:12:03.000000 (1561461123)
             READS_ON_STANDBY_ENABLED = N


#Secondary output:
Database Member 0 -- Database ID2 -- Standby -- Up 1 days 15:45:18 -- Date 2019-06-25-10.56.19.820474

                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.078116 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 10
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 1
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 1000
                      PEER_WINDOW_END = 06/25/2019 11:12:59.000000 (1561461179)
             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

[A]: добавьте правило брандмауэра для порта пробы:

sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload

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

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

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

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

Ниже описаны префиксы этапов настройки и их значение:

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

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

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

• Измените среду оболочки для пользователя db2<sid> на /bin/ksh.

  # Install korn shell:
  sudo yum install ksh
  # Change users shell:
  sudo usermod -s /bin/ksh db2<sid>
  

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

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

   # Put Pacemaker into maintenance mode
   sudo pcs property set maintenance-mode=true
   

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

   При создании кластера на RHEL 7.x обязательно обновите агенты ресурсов пакета до версии resource-agents-4.1.1-61.el7_9.15 или более поздней версии. Чтобы создать ресурсы кластера, используйте следующие команды:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' master meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-master meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-master
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-master then g_ipnc_db2id2_ID2
   

   При создании кластера на RHEL 8.x обязательно обновите агенты ресурсов пакета до версии resource-agents-4.1.1-93.el8 или более поздней версии. Дополнительные сведения см. в статье о ресурсе Red Hat KBA db2 с сбоем HADR с PRIMARY/REMOTE_CATCHUP_PENDING/CONNECTEDсостоянием. Чтобы создать ресурсы кластера, используйте следующие команды:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' promotable meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-clone meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-clone
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-clone then g_ipnc_db2id2_ID2
   

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

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

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

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

   sudo pcs status
   2 nodes configured
   5 resources configured
   
   Online: [ az-idb01 az-idb02 ]
   
   Full list of resources:
   
   rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
   Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
        Masters: [ az-idb01 ]
        Slaves: [ az-idb02 ]
   Resource Group: g_ipnc_db2id2_ID2
        vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
        nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled
   

Внесение изменений в профили 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 или GlusterFS для записи журналов из обоих узлов. Общая папка NFS или GlusterFS должна быть высокодоступной.

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

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

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

В этом разделе описано, как можно проверить конфигурацию Db2 с HADR. В каждом тесте предполагается, что сервер-источник IBM Db2 работает на виртуальной машине az-idb01. Необходимо использовать пользователя с привилегиями sudo или root (не рекомендуется).

Начальное состояние всех тестовых случаев описано ниже (crm_mon -r или pcs status):

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

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

Тестирование перенаправления IBM Db2

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

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

При переносе ресурсов с помощью команды pcs resource move создаются ограничения расположения. В данном случае они препятствуют запуску экземпляра IBM Db2 на виртуальной машине az-idb01. Если ограничения расположения не удаляются, ресурс не может вернуться.

Удалите расположение, ограничивающее и резервный узел, будут запущены в az-idb01.

# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone

И состояние кластера изменится на:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

 rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
 Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
 Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master az-idb01
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
sudo pcs resource clear Db2_HADR_ID2-clone

• В RHEL 7.x — pcs resource move <resource_name> <host>создает ограничения расположения и может вызвать проблемы с переходом
• В RHEL 8.x — pcs resource move <resource_name> --masterсоздает ограничения расположения и может вызвать проблемы с переходом
• pcs resource clear <resource_name>: очищает ограничения расположения
• pcs resource cleanup <resource_name>: очищает все ошибки ресурса

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

Можно проверить перенаправление вручную, остановив службу Pacemaker на узле az-idb01.

systemctl stop pacemaker

Состояние az-ibdb02:

2 nodes configured
5 resources configured

Node az-idb01: pending
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

После отработки отказа можно снова запустить эту службу на узле az-idb01.

systemctl start  pacemaker

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

#Kill main db2 process - db2sysc
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 34598

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=49, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 09:57:35 2019', queued=0ms, exec=362ms

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

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

[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2id2    23144  23142  2 09:53 ?        00:00:13 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 23144

Узел попадает в неудалось указанного состояния и сообщалось об ошибке.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Failed Actions:
* Db2_HADR_ID2_monitor_20000 on az-idb02 'not running' (7): call=144, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 10:02:09 2019', queued=0ms, exec=0ms

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

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

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

az-idb01:db2ptr> db2stop force

Обнаруживается сбой:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Slaves: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Stopped
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Stopped

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

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

#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger

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

2 nodes configured
5 resources configured

Node az-idb01: UNCLEAN (online)
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

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

2 nodes configured
5 resources configured

Online: [ az-idb02 ]
OFFLINE: [ az-idb01 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

В случае паники ядра сбой узла будет перезапущен агентом ограждения. После восстановления работоспособности неисправного узла необходимо запустить кластер Pacemaker:

sudo pcs cluster start

Он запустит экземпляр Db2 в дополнительной роли.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

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