Высокий уровень доступности 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:

Overview

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

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

HADR — это только функция репликации. Он не поддерживает обнаружение сбоев и автоматическое переключение или восстановление при отказе. Для перехода на резервный сервер требуется запуск вручную администратором базы данных. Чтобы добиться автоматического захвата и обнаружения сбоев, можно использовать функцию кластеризации Linux Pacemaker. 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, выполните следующие действия.

• Планирование среды.
• Разверните виртуальные машины.
• Обновите ОС RHEL Linux и настройте файловые системы.
• Установите и настройте Pacemaker.
• Настройка кластера GlusterFS или Azure NetApp Files (ANF.)
• Установите 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), перечислены в следующей таблице:

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

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

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

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

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

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

Убедитесь, что выбранная ОС для IBM/SAP для IBM Db2 LUW поддерживается. Список поддерживаемых версий ОС для виртуальных машин Azure и выпусков Db2 доступен в sap Note 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. Добавьте диски данных на виртуальные машины. Ознакомьтесь с рекомендацией по настройке файловой системы в статье о развертывании СУБД ВИРТУАЛЬНЫх машин Azure IBM Db2 для рабочей нагрузки 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. Выберите параметр Копирование системы>Целевые системы>Распределенная>База данных.
2. В качестве метода копирования выберите однородную систему , чтобы использовать резервную копию для восстановления резервной копии на резервном экземпляре сервера.
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

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

После настройки 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".

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

При использовании 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] Конфигурация IBM Db2 HADR для Pacemaker:

   # 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 (" ") with your values for 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 resource
   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 (" ") with your values for 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 resource
   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 из режима обслуживания с помощью следующей команды:

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

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

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

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

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

• pcs status — это моментальный снимок состояния 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 задокументировано в разделе Обзор конфигурации Transaction 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 выглядят следующим образом:

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 задокументировано в разделе Обзор конфигурации Transaction 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

#Linux kernel panic - halts OS
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