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


Обеспечение высокого уровня доступности 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 Описание
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 Размер виртуальной машины SBD, хранилище, сеть.
Балансировщик нагрузки Azure Использование стандартного (рекомендуемого) пробного порта для базы данных 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.

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

  • Я хочу установить новую систему.
  • "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. Выберите параметр Копирование системы>Целевые системы>Распределенные>Экземпляр базы данных.

  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<>.
      • Интервал. Введите 5.
      • Пороговое значение пробы: введите 2.
    • Время ожидания простоя (минуты): введите 30.
    • Включите плавающий IP-адрес: выберите этот параметр.

Примечание.

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

Примечание.

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

Внимание

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

Создание кластера 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.

Конфигурация кардиостимулятора

Внимание

В ходе последних тестов были выявлены ситуации, когда 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 Load-Balancer Detection Hardening, нет необходимости немедленно переключаться на агент ресурса 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).

  • Ограничений по расположению нет (остатки теста миграции).

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

DBACockpit - после миграции

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

В случае халтинга узла, неисправный узел необходимо перезапустить с помощью средств управления 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 ]

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