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

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

Примечание

В этой статье упоминаются термины slave (ведомый) и master (главный) , которые больше не используются Майкрософт. Когда эти термины будут удалены из программных продуктов, мы удалим их и из этой статьи.

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

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

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

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

Примечание SAP Описание
1928533 Приложения SAP в Azure: поддерживаемые продукты и типы виртуальных машин Azure
2015553 SAP в Azure: необходимые компоненты
2178632 Ключевые метрики мониторинга для SAP в Azure
2191498 SAP на платформе Linux в Azure: расширенный мониторинг
2243692 Виртуальная машина Linux в Azure (IaaS): проблемы с лицензированием SAP
1984787 SUSE Linux Enterprise Server 12 Замечания по установке
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
Рекомендации по SUSE Linux Enterprise Server для приложений SAP версии 12 с пакетом обновления 4 (SP4)
Расширение для обеспечения высокого уровня доступности SUSE Linux Enterprise версии 12 с пакетом обновления 4 (SP4)
Развертывание СУБД IBM DB2 на Виртуальных машинах Azure для рабочей нагрузки SAP
IBM Db2 HADR 11.1
IBM Db2 HADR R 10.5

Обзор

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

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

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

Обзор высокого уровня доступности IBM Db2

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

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

Обзор полной высокодоступной среды IBM Db2

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

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

  • Спланируйте свою среду.
  • Разверните виртуальные машины.
  • Обновите SUSE Linux и настройте файловые системы.
  • Установите и настройте Pacemaker.
  • Установите NFS с высокой доступностью.
  • Установите 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 или ограждение SBD (настоятельно рекомендуется). Это способ избежать ситуаций разделения вычислительных мощностей.
Виртуальная машина SBD Размер виртуальной машины, хранилище, сеть.
Azure Load Balancer Использование уровня "Базовый" или "Стандартный" (рекомендуется), порт пробы для базы данных Db2 (наша рекомендация 62500) порт пробы.
Разрешение имен Как работает разрешение имен в среде. Настоятельно рекомендуется использовать службу DNS. Можно использовать локальный файл hosts.

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти руководства можно найти на справочном портале SAP с помощью средства поиска руководств по установке SAP.

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

  • "I want to" (Мне нужно): "Install a new system" (Установить новую систему);
  • "My Database" (Моя база данных): "IBM Db2 for Linux, Unix, and Windows" (IBM Db2 для Linux, Unix и Windows);
  • дополнительные фильтры для версий SAP NetWeaver, конфигурации стека или операционной системы.

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

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

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

Важно!

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

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

  1. Выберите параметр System copy (Копирование системы)>Target systems (Целевые системы)>Distributed (Распределенные)>Database instance (Экземпляр базы данных).

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

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

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

    Примечание

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

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

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

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

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

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

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

Важно!

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

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

Проверка IBM Db2 HADR

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


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

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

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

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

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

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

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

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

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

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

Важно!

В ходе последних тестов были выявлены ситуации, когда netcat перестает отвечать на запросы из-за невыполненной работы и ограничения на обработку только одного подключения. Ресурс netcat прекращает прослушивать запросы Azure Load Balancer, и плавающий IP-адрес становится недоступным.
Для существующих кластеров Pacemaker ранее рекомендовалось заменять netcat на socat. Сейчас мы рекомендуем использовать агент ресурса azure-lb, который входит в состав пакета resource-agents со следующими требованиями к версии пакета:

  • Минимальная версия для SLES 12 с пактом обновления 4 или 5 (SP4/SP5) — resource-agents-4.3.018.a7fb5035-3.30.1.
  • Минимальная версия для SLES 15/15 с пакетом обновления 1 (SP1) — resource-agents-4.3.0184.6ee15eb2-4.13.1.

Обратите внимание, что для этого изменения потребуется незначительное время простоя.
Если конфигурация существующих кластеров Pacemaker уже была изменена для использования socat, как описано в этой статье, немедленно переключаться на агент ресурса azure-lb не нужно.

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

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

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

# Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.

sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \
        params instance="db2ptr" dblist="PTR" \
        op start interval="0" timeout="130" \
        op stop interval="0" timeout="120" \
        op promote interval="0" timeout="120" \
        op demote interval="0" timeout="120" \
        op monitor interval="30" timeout="60" \
        op monitor interval="31" role="Master" timeout="60"

# Configure virtual IP - same as Azure Load Balancer IP
sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \
        op monitor interval="10s" timeout="20s" \
        params ip="10.100.0.10"

# Configure probe port for Azure load Balancer
sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500

sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR

sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \
        meta target-role="Started" notify="true"

sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master

sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

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

  • Переведите Pacemaker в режим обслуживания.
# Put Pacemaker out of maintenance-mode - that start IBM Db2
sudo crm configure property maintenance-mode=false

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

sudo crm status

# 2 nodes configured
# 5 resources configured

# Online: [ azibmdb01 azibmdb02 ]

# Full list of resources:

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

Важно!

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

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

Чтобы настроить Azure Load Balancer, рекомендуется использовать номер SKU Azure Load Balancer (цен. категория "Стандартный"), а затем выполнить указанные ниже действия.

Примечание

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

Важно!

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

  1. Создайте пул внешних IP-адресов:

    а. На портале Azure откройте Azure Load Balancer, выберите Пул интерфейсных IP-адресов и нажмите кнопку Добавить.

    b. Введите имя нового пула внешних IP-адресов (например, Db2-connection).

    c. Задайте для параметра Назначение значение Статический и введите IP-адрес Virtual-IP, определенный ранее.

    d. Щелкните ОК.

    д) Когда пул интерфейсных IP-адресов будет создан, запишите его IP-адрес.

  2. Создайте серверный пул:

    а. На портале Azure откройте Azure Load Balancer, выберите Серверные пулы и нажмите кнопку Добавить.

    b. Введите имя нового серверного пула (например, Db2-backend).

    c. Щелкните Добавить виртуальную машину.

    d. Выберите группу доступности или виртуальные машины, на которых размещена база данных IBM Db2, созданная на предыдущем шаге.

    д) Выберите виртуальные машины кластера IBM Db2.

    е) Щелкните ОК.

  3. Создайте пробу работоспособности:

    а. На портале Azure откройте Azure Load Balancer, выберите Пробы работоспособности и нажмите кнопку Добавить.

    b. Введите имя новой пробы работоспособности (например, Db2-hp).

    c. Выберите протокол TCP и порт 62500. Оставьте значение 5 для параметра Интервал и значение 2 для параметра Порог состояния неработоспособности.

    d. Щелкните ОК.

  4. Создайте правила балансировки нагрузки:

    а. На портале Azure откройте Azure Load Balancer, выберите Правила балансировки нагрузки и нажмите кнопку Добавить.

    b. Введите имя нового правила Load Balancer (например, Db2-SID).

    c. Выберите внешний IP-адрес, серверный пул и пробу работоспособности, которые вы создали ранее (например, Db2-frontend).

    d. Для параметра Протокол оставьте значение TCP и введите порт связи базы данных.

    д) Увеличьте время ожидания до 30 минут.

    е) Не забудьте включить плавающий IP-адрес.

    ж. Щелкните ОК.

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

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

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

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

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

  • crm status — создание моментального снимка состояния Pacemaker во время выполнения;
  • crm_mon- r — непрерывный вывод состояния Pacemaker.
2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

DBA Cockpit: подготовка к переносу

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

Важно!

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

  • в Pacemaker нет действий с ошибками (crm status);
  • отсутствуют ограничения расположения (после теста переноса);
  • синхронизация IBM Db2 HADR работает. Проверка с помощью пользователя db2<sid>
    db2pd -hadr -db <DBSID>

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

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

DBA Cockpit: действия после переноса

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

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

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

Проверка агента ограждения

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


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

azibmdb01:~ # kill -9 2374

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

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

sudo service pacemaker start

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

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

service pacemaker stop

статус на azibmdb02


2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

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

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

service pacemaker start

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

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

azibmdb01:~ # kill -9 34598

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


2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

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

azibmdb02:~ # kill -9

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

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

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

 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

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

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

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

2 nodes configured
5 resources configured

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

Full list of resources:

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

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

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

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

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

Дальнейшие действия