Поделиться через

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

  • Статья

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

Примечание.

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

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

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

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

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

Примечание SAP Description
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 сервера базы данных подключено собственное хранилище, которое активно. В 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. Выберите подходящий тип развертывания для виртуальных машин SAP. Обычно масштабируемый набор виртуальных машин с гибкой оркестрацией.
  4. Создайте виртуальную машину 1.
    1. Используйте образ SLES для SAP из Azure Marketplace.
    2. Выберите масштабируемый набор, зону доступности или группу доступности, созданную на шаге 3.
  5. Создайте виртуальную машину 2.
    1. Используйте образ SLES для 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.

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

  • "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 Software Provisioning Manager отображается явный вопрос об обеспечении высокого уровня доступности для 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

Настройка 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 уровня "Стандартный", исходящее подключение к Интернету не выполняется, если не выполняется дополнительная настройка, чтобы разрешить маршрутизацию на общедоступные конечные точки. Дополнительные сведения о том, как обеспечить исходящее подключение, см. в статье "Подключение к общедоступной конечной точке для виртуальных машин" с помощью Azure Load Balancer (цен. категория в сценариях высокой доступности SAP.

Внимание

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

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

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

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

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

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

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

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

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

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

Внимание

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

  • Минимальная версия для SLES 12 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. [1]: конфигурация Pacemaker для IBM Db2 HADR:

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

  2. [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 \
        op monitor timeout=20s interval=10

sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR

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

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

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

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

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

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

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

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

    sudo crm status

# 2 nodes configured
# 5 resources configured

# Online: [ azibmdb01 azibmdb02 ]

# Full list of resources:

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

Внимание

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

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

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

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

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

  • состояние crm — это моментальный снимок состояния 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

В этом случае мы протестируем ограждение 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 ]

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