Обеспечение высокого уровня доступности 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:

Примечание SAP Description
1928533 Приложения SAP в Azure: поддерживаемые продукты и типы виртуальных машин Azure
2015553 SAP в Azure: необходимые компоненты
2178632 Ключевые метрики мониторинга для SAP в Azure
2191498 SAP в Linux с помощью Azure: расширенный мониторинг
2243692 Виртуальная машина Linux в Azure (IaaS): проблемы с лицензированием SAP
2002167 Red Hat Enterprise Linux 7.x: установка и обновление
2694118 Надстройка HA для Red Hat Enterprise Linux в Azure.
1999351 Устранение неполадок, связанных с расширенным мониторингом Azure для SAP
2233094 DB6: приложения SAP в Azure, использующие IBM Db2 для Linux, Unix и Windows (дополнительные сведения)
1612105 DB6: вопросы и ответы о Db2 с HADR
Документация
Вики-сайт сообщества SAP со всеми необходимыми примечаниями SAP для Linux
Руководство по планированию и внедрению SAP в Linux на виртуальных машинах Azure
Развертывание виртуальных машин Azure для SAP в Linux (данная статья)
Руководство по развертыванию СУБД на виртуальных машинах Azure для SAP в Linux
Рабочая нагрузка SAP в списке проверка планирования и развертывания Azure
Общие сведения о надстройке High Availability для Red Hat Enterprise Linux 7
Администрирование надстройки для обеспечения высокой доступности
Справочник по надстройке для обеспечения высокой доступности
Политики поддержки для кластеров высокой доступности RHEL — виртуальные машины Microsoft Azure как члены кластера
Установка и настройка кластера высокой доступности Red Hat Enterprise Linux 7.4 (и более поздних версий) в Microsoft Azure
Развертывание СУБД IBM Db2 в Azure Виртуальные машины для рабочей нагрузки SAP
IBM Db2 HADR 11.1
IBM Db2 HADR 10.5
Политика поддержки высокодоступных кластеров RHEL: управление IBM Db2 для Linux, Unix и Windows в кластере

Обзор

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

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

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

IBM Db2 high availability overview

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

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

IBM DB2 high availability full environment overview

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

Чтобы развернуть конфигурацию 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), перечислены в таблице ниже.

Раздел Краткое описание
Определение групп ресурсов Azure Группы ресурсов, в которых развертывается виртуальная машина, виртуальная сеть, Azure Load Balancer и другие ресурсы. Можно выбрать имеющиеся или создать новые.
Определение виртуальной сети и подсети В них развертываются виртуальные машины для IBM Db2 и Azure Load Balancer. Можно выбрать имеющиеся или создать новые.
Виртуальные машины для размещения IBM Db2 LUW Размер виртуальной машины, хранилище, сеть, IP-адрес.
Имя виртуального узла и виртуальный IP-адрес для базы данных IBM Db2 Имя виртуального IP-адреса или узла используется для подключения серверов приложений SAP. db-virt-hostname, db-virt-ip.
Ограждение Azure Способ избежать ситуаций разделения вычислительных мощностей.
Azure Load Balancer Использование стандартного порта (рекомендуется), порта пробы для базы данных Db2 (наша рекомендация 62500) пробного порта.
Разрешение имен Как работает разрешение имен в среде. Настоятельно рекомендуется использовать службу DNS. Можно использовать локальный файл hosts.

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

Внимание

Для Db2 версий 11.5.6 и более поздних настоятельно рекомендуется использовать интегрированное решение с применением Pacemaker от IBM.

Развертывание в 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 и экземпляр базы данных.
  • Создайте резервную копию установленной базы данных.

Внимание

Запишите порт связи базы данных, заданный во время установки. Для обоих экземпляров базы данных должен использоваться один и тот же номер порта. SAP SWPM Port Definition

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

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

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

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

Примечание.

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

Примечание.

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

  • не выбирайте IBM Db2 pureScale;
  • не выбирайте Install IBM Tivoli System Automation for Multiplatforms (Установить службу автоматизации системы IBM Tivoli для мультиплатформ);
  • не выбирайте Generate cluster configuration files (Создать файлы конфигурации кластера). SAP SWPM - DB2 HA options

Чтобы настроить резервный сервер базы данных с помощью процедуры копирования однородных систем 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.

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

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

Примечание.

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

Внимание

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

Примечание.

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

Внимание

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

[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 КБ A 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

Внимание

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

Внесение изменений в профили 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 для каталога транспорта или каталога профиля. Дополнительные сведения см. в разделе:

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

В этом разделе описано, как можно проверить конфигурацию 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" > "Конфигурация" > "Обзор", как показано на следующем рисунке:

DBACockpit - Pre Migration

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

Внимание

Перед началом тестирования убедитесь, что:

  • в Pacemaker нет действий с ошибками (pcs status);

  • Ограничения расположения отсутствуют (оставшиеся части теста миграции).

  • синхронизация IBM Db2 HADR работает. Проверьте идентификатор пользователя db2<.>

    db2pd -hadr -db <DBSID>

Перенесите узел, на котором выполняется база данных-источник 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" > "Конфигурация" > "Обзор", как показано на следующем рисунке:

DBACockpit - Post Migration

При переносе ресурсов с помощью команды 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

DBACockpit - Removed location constrain

Перенесите ресурс обратно на виртуальную машину 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

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