В статье описывается использование облачной среды для создания надежного метода прерывания связей (tie-breaking) с целью предотвращения сценария потери связанности (split brain). Эта процедура использует двухузловой кластер, выполняющий IBM® DB2® for Linux®, UNIX® and Windows® (LUW) и интегрированную инфраструктуру высокой готовности (HA). Узнайте, как автоматизировать любое переключение на резерв в двухузловой конфигурации DB2 LUW 10.1 и выше.
Обзор
Эта статья знакомит с новым типом прерывателя связей кластера, появившимся в DB2 for Linux, UNIX and Windows (LUW) Version 10.1. Решение DB2 for LUW предоставляет интегрированную отказоустойчивую кластеризацию высокой готовности начиная с DB2 Version 9.5.
Новый тип прерывателя связей можно использовать для автоматизации переключения на резерв DB2 LUW в двухузловом кластере, а также для автоматизации любой топологии DB2 LUW, охватывающей два кластеризованных узла. Примерами топологий двухузлового кластера являются DB2 с одним разделом, репликация DB2 (HADR), секционированная DB2 (DPF) и DB2 pureScale. Данная статья посвящена использованию облачного прерывателя связей для надежной автоматизации переключения на резерв DB2 LUW HADR. В ней также обсуждаются действия по восстановлению.
Основные концепции кластеров
Кластер представляет собой набор слабо связанных взаимодействующих вычислительных узлов. На практике связь между вычислительными узлами осуществляется по стандартным каналам связи.
Все узлы кластера взаимодействуют друг с другом. Внутренний механизм пульсации постоянно посылает всем узлам кластера сообщения для определения активных членов кластера. При сбоях связи кластер может разделиться на несколько подкластеров, которые полностью или частично не знают друг о друге, т.е. не могут взаимодействовать друг с другом. Один из подкластеров может быть назначен первичным подкластером. Условием формирования первичного подкластера является наличие кворума.
Кворум
Под кворумом подразумевается набор активных узлов кластера, которые в состоянии взаимодействовать между собой. Наличие кворума означает, что набор способных к взаимодействию узлов может продолжить выполнение операций.
Программное обеспечение использует два основных метода определения кворума. Первый метод применим к любому кластеру, состоящему из нечетного числа узлов. В таком кластере используется алгоритм определения кворума под названием Majority Node Set (MNS). MNS гарантирует, что в случае события разделения сети (в результате которого полное взаимодействие между всеми членами кластера становится невозможным) первичный подкластер остается активным, а все более мелкие подкластеры завершаются. Эти узлы автоматически отключаются программным обеспечением кластеризации.
В кластерах, состоящих из четного числа узлов, необходим дополнительный объект для арбитража в случаях, когда событие разделения сети приводит к возникновению двух или более подкластеров одинакового размера. Этот дополнительный объект "нарушает связь" и соответственно называется прерывателем связей. Типичным примером является двухузловой кластер. Если в таком кластере два узла не могут взаимодействовать друг с другом из-за события разделения сети, они обращаются к прерывателю связей. Результат этого обращения определяет, какой из двух узлов будет работать как основной подкластер и соответственно поддерживать ресурсы кластера.
Требования к прерывателю связей
- Прерыватель связей должен быть доступен для любого узла кластера.
- При разделении сети к прерывателю связей обращаются все выжившие узлы для определения подкластера-победителя.
- Узел, который способен обратиться к прерывателю связей, рассматривается как часть подкластера-победителя.
- Узел, который не способен обратиться к прерывателю связей, рассматривается как часть проигравшего подкластера и отключается.
- Идеальный прерыватель связей сохраняет состояние в том смысле, что к нему одновременно может обратиться только один узел.
- Обращение к идеальному прерывателю связей должно быть быстрой и надежной операцией.
Поддерживаемые прерыватели связей
DB2 LUW поддерживает несколько типов прерывателей связей. Детали их реализации разнятся, но общим принципом является то, что все они используются в случае, когда не работает половина узлов кластера.
Чаще всего в DB2 LUW используются дисковый и сетевой прерыватели связей.
Дисковый прерыватель связей
В дисковом прерывателе связей один физический сегмент диска совместно используется группами машин в кластере (мы без потери общности рассмотрим чаще всего встречающийся вариант двухузлового кластера). В случае события разделения сети каждый узел пытается получить блокировку этой области диска. Если оба узла активны, получить блокировку может только один узел. Узел, который не в состоянии получить блокировку, не включается в кворум, а узел, который получает блокировку, включается кворум и, следовательно, становится выжившим подкластером.
Итак, каждый узел имеет доступ к общему диску. Каждый узел пытается блокировать диск. Если узлу отказано в блокировке, значит, он не принадлежит к кворуму.
Сетевой прерыватель связей
Сетевой прерыватель связей - это популярный вариант конфигурации, простой в настройке и использовании. Он полезен в случаях большого числа резервных сетевых путей в двухузловых кластерах. Дополнительные резервные сетевые пути рекомендуется иметь на случай отключения сети. В случае разрыва всех каналов связи между двумя узлами предпринимается попытка захвата сетевого прерывателя связей. Увеличение числа независимых сетей между двумя машинами увеличивает вероятность того, что полное отсутствие связи между узлами будет означать отказ узла, а не разделение сети.
Сетевой прерыватель связей указывается с помощью IP-адреса, который должен пинговаться (откликаться на запрос) с любого узла кластера. Для сетевого прерывателя связей рекомендуется использовать шлюз маршрутизатора по умолчанию. В случае отключения или разделения кластера каждый узел пингует указанный IP-адрес. Если IP-адрес пингуется, данный узел определяется как выживший подкластер. Если узел работоспособен, но IP-адрес не пингуется, значит, узел не входит в кворум.
Для сетевого прерывателя связей ключевым предположением является то, что, если оба узла могут связаться со шлюзом по умолчанию, то они могут связаться и друг с другом. Если это не так (например, сеть позволяет узлам пинговать общий шлюз или устройство, но не друг друга), то сетевой прерыватель связей использовать нельзя.
Пинг IP-адреса прерывателя связей не сохраняет состояние. Он может быть успешным, но по месту нахождения IP-адреса ни одно состояние не сохраняется, что позволяет другим клиентам (узлам) пинговать (запрашивать) прерыватель связей. Чтобы существенно уменьшить вероятность одновременного двойного запроса, рекомендуется иметь между узлами много резервных сетевых путей.
Облачный прерыватель связей
Относительно новый облачный прерыватель связей появился в DB2 LUW v10.1. Для прерывателя связей этого типа используется удаленное облачное хранилище, позволяющее сохранять состояние прерывателя и обеспечивающее ряд преимуществ дискового прерывателя (гарантия от потери связанности). Кроме того, облачный прерыватель связей сочетает в себе простоту использования облака и удобство виртуализации прерывателя сетевого типа.
Облачный прерыватель связей задается парой ключей доступа к облачному хранилищу. Сервис облачного прерывателя связей должен быть доступен для каждого узла кластера.
Обратите внимание, что облачный прерыватель связей поддерживается только в двухузловом кластере.
С точки зрения внутренней реализации сервис хранилища облачного прерывателя связей состоит из контейнеров и содержащихся в них объектов. Пространство имен контейнеров совместно используется всеми пользователями сервиса хранилища, поэтому имена контейнеров должны быть уникальными. Имя созданного контейнера нельзя использовать при создании другого контейнера до тех пор, пока этот контейнер не будет удален. Контейнеры имеют списки управления доступом. Контейнер в облачном сервисе обладает свойством уникальности - его использование гарантирует, что только один узел двухузлового кластера может захватить прерыватель связей. Это позволяет исключить возникновение любой ситуации потери связанности. Пример показан на рисунке 1.
Рисунок 1. Сервис хранилища облачного прерывателя связей
В последующих разделах описываются установка и использование прерывателя связей облачного типа.
Настройка базового db2haicu для автоматизации HADR (без выбора прерывателя связей)
Давайте создадим двухузловой кластер для автоматизации переключения на резерв HADR с помощью интегрированного в DB2 HA-механизма, который иногда называют db2haicu. Для создания двухузлового автоматизированного HADR-кластера обратитесь к документу Конфигурация и топология системы DB2 для мультисайтовой автоматизации HA и DR.
В примере среды, рассматриваемом в статье, используется конфигурация, основанная на DB2 LUW 10.5 FP3. В остальном конфигурация аналогична приведенному выше документу. Для обеспечения надежного межсайтового переключения на резерв необходимо организовать на третьем сайте сохраняющий состояние прерыватель связей. В этом документе описаны два варианта устройства сохраняющего состояние прерывателя связей:
- Третий узел (узел арбитра), добавленный в кластер RSCT.
- Общий дисковый прерыватель связей.
В обоих случаях для размещения общего устройства необходим третий сайт.
Однако в нашем случае будет реализован третий вариант - использование облачного прерывателя связей. Облачный прерыватель связей имеет преимущество перед описанными выше прерывателями, поскольку он сохраняет состояние и ему не нужен третий центр данных или третий сайт для размещения устройства прерывателя.
Конфигурация соответствует приведенному выше документу до раздела "Initial configuration - common to both topologies" ("Первоначальная настройка - общее для обеих топологий") включительно.
Ниже приведена информация о созданном кластере (результат выполнения команды db2pd -ha от имени владельца экземпляра):
Осталось определить облачный прерыватель связей для кластера.
В случае возникновения трудностей обратитесь к статьям в разделе Ресурсы.
Требования к установке
На каждом узле кластера должны быть установлены Perl 5.4 (или выше) и модули HMAC Perl. Установка Perl и его модулей зависит от операционной системы.
Для дистрибутивов Linux, в которых используется менеджер пакетов yum, установка необходимых кода и модулей Perl выполняется с помощью следующих команд:
Для дистрибутивов Linux, в которых в качестве менеджера пакетов используется инфраструктура apt-get, установка необходимых кода и модулей Perl выполняется с помощью следующих команд:
Для остальных дистрибутивов Linux (например, SLES и его варианты) и других поддерживаемых не-Linux систем без готовых пакетов получение необходимого модуля Perl HMAC осуществляется с помощью следующей команды CPAN:
Создание двух учетных записей AWS S3
Создайте две разные учетные записи в облачном хранилище (или получите к ним доступ). Например, можно зарегистрироваться в сервисе AWS S3 (Amazon web services Simple Storage Service).
Каждый узел использует отдельную учетную запись AWS для доступа к (общему) облачному хранилищу. На Web-сайте сервиса облачного хранилища получите ключи Access Key и Secret Key для обеих учетных записей.
Поместите информацию ключей на каждую машину, как описано ниже.
Установка ключей Access Key
Каждая учетная запись имеет связанные с ней ключи Access Key и Secret Key. Ключи Access Key и Secret Key необходимо поместить в доступные только пользователю root файлы на обеих машинах.
Ниже приведен формат именования этих файлов. Содержимое файлов напрямую соответствует их именам.
В нашем примере двухузлового кластера файлы именуются следующим образом:
Убедитесь, что на каждом из двух узлов кластера присутствуют и доступны для root все четыре файла.
Проверка среды
С помощью Perl и ключей, установленных на каждом узле, проверьте конфигурацию облачного прерывателя связей. От имени root выполните на первом узле следующую команду:
Появление ошибок означает невыполнение требований. Исправьте ошибки и повторите описанные выше действия. Добейтесь полного отсутствия ошибок.
При отсутствии ошибок выполните ту же команду на другом узле. Появление ошибок означает невыполнение требований или неправильную настройку среды. Добейтесь полного отсутствия ошибок.
Установка прерывателя связей кластера в облаке
Мы убедились, что облачный прерыватель связей в каждом узле двухузлового кластера настроен правильно. Чтобы выполнить приведенную ниже последовательность трех команд, войдите в любой узел двухузлового кластера.
Примечание. Эту последовательность команд необходимо выполнить на любом из узлов двухузлового кластера только один раз.
Выполните следующую команду:
Для создания объекта прерывателя связей с именем CloudTB1 выполните следующую команду от имени root:
Чтобы сделать активным только что созданный объект прерывателя связей CloudTB1, выполните следующую команду:
Если эти три команды выполнились без ошибок, значит, двухузловой кластер имеет прерыватель связей облачного типа. Для проверки результата исследуйте состояние кворума кластера с помощью следующей команды, выполненной любым владельцем экземпляра db2:
Выходная информация должна иметь приблизительно такой вид:
Она показывает, что только что созданный прерыватель связей активен. В следующем разделе будут рассмотрены тесты для проверки конфигурации.
Примеры сценариев и вариантов использования
Для проверки работоспособности кластера можно выполнить несколько тестов на отказ. Помимо приведенного ниже базового сценария тестирования можно выполнить тесты из достаточно полного списка, который содержится в документах Установка управляемой конфигурации HADR кластера с помощью утилиты db2haicu (раздел 6) и Конфигурация и топология системы DB2 для мультисайтовой автоматизации HA и DR (приложение F).
Сценарий: отказ nodeha01 вследствие перезагрузки машины
Если nodeha01 теряет связь по причине перезагрузки, nodeha02 обращается к облачному прерывателю связей и получает кворум (см. рисунок 2). На уровне базы данных в узле nodeha02 база данных HADR становится первичной. После перезапуска nodeha01 опять подключается к двухузловому кластеру, а на nodeha01 запускается резервная база данных HADR.
Рисунок 2. Отказ nodeha1 и автоматический захват прерывателя связей узлом nodeha02
Ниже приведена выходная информация команды lssam, показывающая состояние сразу после успешного HADR-переключения на резервный узел nodeha02:
Определение и анализ проблем
Облачный прерыватель связей вносит в системный журнал SYSLOG записи со следующей меткой:
Например, если на конкретной машине данные SYSLOG хранятся в файле /var/log/messages, все записи облачного прерывателя связей можно увидеть, выполнив следующую команду:
Наибольший интерес представляют записи, демонстрирующие достижение кворума. Вы должны увидеть сообщения, аналогичные приведенным ниже в SYSLOG, особенно в тех случаях, когда облачный прерыватель связей может захватить устройство кворума.
Заключение
В данной статье вы познакомились с использованием облачного прерывателя связей в автоматизированной двухузловой топологии DB2 LUW HADR. Облачный прерыватель связей можно использовать для автоматизации любого двухузлового переключения на резерв DB2 LUW 10.1 или выше. Его также можно использовать при расположении узлов как на одном, так и на разных сайтах.