Перейти к содержанию

Кластерные транспорты

Кластерные транспорты

Кластерные транспорты — это общее название для кластерных (GFS2, OCFS2) и распределённых (Gluster) транспортов. Фактически транспорт - это набор сервисов на всех серверах кластера, имеющих сетевую связность друг с другом, поддерживающих постоянное общение друг с другом и кворум для реализации блокировок на файловые системы. Для GFS2 это связка сервисов watchdog, corosync, dlm. Для OCFS2 это связка сервисов o2cb и порождаемых им. Для Gluster это связка сервисов glusterd и порождаемых им. В одном транспорте можно использовать несколько однотипных файловых систем, например, у одного транспорта Gluster можно создать несколько томов и пулов данных на последних, у одного транспорта GFS2/OCFS2 можно использовать несколько LUN и пулов данных на последних. Именно поэтому логично выделить кластерный транспорт в отдельную сущность (например, VMFS у Vmware, - это тоже одновременно кластерный транспорт и файловая система).

Создание

Для создания кластерного транспорта необходимо перейти в раздел Хранилища - Кластерные хранилища - Кластерные транспорты основного меню и нажать кнопку Создать. В открывшемся окне необходимо заполнить следующие поля:

  • название (если не указано, то автоматически сгенерируется уникальное имя);

  • описание;

  • кластер, на узлах которого будет разворачиваться кворум (выбор из раскрывающегося списка);

  • тип транспорта (выбор из раскрывающегося списка);

  • внешняя сеть, физическая сеть которой будет использована для обмена данными между участниками кворума (выбор из раскрывающегося списка);

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

HOWTO создать общий(е) для кластера пул(ы) данных GFS2 на LUN(s)

  1. Создать сетевой блочное iscsi или fc хранилище. Проверить, что оно доступно на всех узлах кластера. Проверить, что его LUN(s) видны на всех узлах кластера. Подробности смотрите в блочных хранилищах.

  2. Настроить IPMI. Перед созданием GFS2 транспорта убедитесь в наличии IPMI настроек ВСЕХ серверов кластера. Через IPMI будет вестись ограждение узлов кворумом. При отсутствии IPMI настроек хотя бы одного сервера кворум будет вести ограждение только через контроллер, и нельзя будет на 100% быть уверенным в отсутствии Split Brain при всех возможных ситуациях потери связи с узлами.

  3. Создать внешнюю сеть (необязательный шаг). Трафик между узлами для типа GFS2 крайне мал, так как они в рамках кворума обмениваются лишь heartbeat, то есть использование внешней сети рекомендуется, но не является критическим условиям устойчивой работы.

  4. Создать кластерный транспорт gfs2. Для удобства можно выбрать LUN, который будет сразу отформатирован, примонтирован, и на нём будет создан пул данных. В дальнейшем можно отформатировать, примонтировать и создать пул данных на других LUN.

Пример создания кластерного транспорта gfs2 с выбором внешней сети и LUN: image

HOWTO создать общий(е) для кластера пул(ы) данных GFS2 на LUN(s), если уже есть кластерный транспорт gfs2

  1. Отформатировать LUN в файловую систему gfs2.

  2. Примонтировать LUN (он должен примонтироваться на всех узлах кластера с транспортом).

  3. Создать пул данных gfs2 на этом LUN.

Описание работы GFS2 транспорта

Watchdog

При наличии платы watchdog в ВМС сервер будет следить за своим состоянием через него. При отсутствии платы при включении сервера будет активирован программный watchdog (softdog). Просмотр и управление watchdog происходит через CLI командами system watchdog *.

В работе gfs2 участвует большое количество сервисов на каждом узле:

  • watchdog. Описание есть отдельно ниже.

  • corosync. Зависит от watchdog. Отвечает за общение серверов друг с другом по сети. При создании или реконфигурировании кластерного транспорта обновляется конфигурационный файл corosync по пути /etc/corosync/corosync.conf и рестартуется этот сервис. Для узлов типа Node назначается одна квота, для узлов типа Controller+Node 2 квоты. ТО есть, например, если кластер состоит из 20 узлов без контроллеров, то будет всего 20 квот. Если, например, кластер состоит из 2 узлов, один из которых контроллер, а другой узел, то всего будет 3 квоты. Для кворума необходимо минимально (общее количество квот / 2 + 1). Если будет меньше, то кворум прекратит работу и будет ожидать, когда количество квот достигнет минимально нужного.

Пример расширенных сведений кластерного транспорта gfs2 (здесь как раз показан статус кворума corosync, видно, что 5 узлов, 5 квот, минимум для работы 3): image

Пример команды storage gfs2 в CLI кластерного транспорта gfs2 (здесь показан статус corosync, dlm, точек монтирования): image

Пример команды вывода конфигурации corosync storage corosync_conf в CLI (здесь видно, что узлов всего 2, но один из них контроллер, так как у него 2 квоты): image

  • dlm. Занимается блокировками файловой системы и запуском ограждения узлов. Зависит от corosync. Ограждение узлов ведется 2 способами:
    • Ограждение через api контроллера.
    • Ограждение через IPMI узла.

То есть сервис dlm, если видит, что узел выпал из кворума, пытается его оградить. Для этого он делает api запросы попыток ограждения на VeiL контроллер, а при наличии IPMI пытается перезагрузить узел.

Пример команды storage dlm_conf в CLI (здесь видно, что узлов всего 5, и для каждого по 2 метода ограждения, один через контроллер, а второй по IPMI): image

Пример команды storage gfs2 в CLI (здесь видно, что кворум ожидает завершения ограждения узла, рекомендуется проверить, почему узел не ограждается и при неолбходимости попытаться завершить ограждение командой dlm_tool fence_ack {nodeid}): image

Gluster транспорт

Минимальное количество узлов

В кластере для создания транспорта должно быть не менее 2 узлов. При создании транспорта типа Gluster на 2 узлах надо осознавать, что такая конфигурация влечёт за собой теоретическую возможность ситуации, когда узлы не могут определить мастера при потере сетевой связности (split-brain), а значит - могут писать различающиеся данные в одно место. При создании транспорта типа OCFS2 и GFS2 на 2 узлах надо осознавать, что такая конфигурация влечёт за собой теоретическую возможность ситуации, когда оба узла будут ограждены.

Выбор внешней сети

Рекомендуется использовать отдельную от сети управления внешнюю сеть! После создания транспорта без использования внешней сети убедитесь с помощью кнопки Получение расширенных сведений о транспорте, что связь узлов идёт через UUID узлов, а с использованием внешней сети через UUID узлов плюс имя внутреннего интерфейса. С помощью команды hosts на любом узле можно удостовериться, что UUID узла плюс имя внутреннего интерфейса соответствует IPv4-адресу интерфейса.

Устройство томов Gluster и манипуляции с ними описаны в пункте Gluster тома.

Добавление узлов к существующему кластерному транспорту Gluster:
  • Введите узлы в кластер VeiL.
  • При функционировании существующего кластерного транспорта через внешнюю сеть подключите узлы к этой внешней сети.
  • В окне существующего кластерного транспорта нажмите кнопку "Переконфигурирование". При этом вновь добавленные к кластеру узлы будут присоединены к существующему кластерному транспорту.
  • При наличии пулов данных типа Gluster в меню "Хранилища - Пулы данных" на вновь подключённых узлах нажмите "Сканировать". Пулы данных станут доступны на этих узлах.
Удаление узлов из кластерного транспорта Gluster (например, перед выводом из кластера)
  • Остановите или выключите ВМ, чьи диски находятся на томах Gluster в данном кластерном транспорте. На время удаления не проводите операций загрузки файлов на пулы данных типа Gluster в данном кластере.
  • Удалите или замените разделы томов Gluster, находящиеся на узлах, которые подлежат удалению.
  • Отмонтируйте тома Gluster от соответствующих узлов.
  • В меню кластерного транспорта нажмите кнопки отключения нужных узлов от транспорта.

OCFS2 транспорт (Deprecated)

Трафик между узлами для типа OCFS2 крайне мал, так как они в рамках кворума обмениваются лишь heartbeat, то есть использование внешней сети рекомендуется, но не является критическим условиям устойчивой работы.

OCFS2 Best Practices Guide

Frequently Asked Questions

Ограждение кворумом

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

Окно состояния транспорта

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

  • информация;

  • события;

  • теги.

Управление работой транспорта происходит в окне состояния, где доступны следующие операции:

  • удаление;

  • переконфигурирование (добавление новых серверов кластера);

  • получение расширенных сведений о транспорте.

Вкладка Информация содержит следующие сведения о транспорте:

  • название (редактируемый параметр);

  • описание (редактируемый параметр);

  • кластер;

  • тип;

  • статус;

  • даты создания;

  • дата обновления;

  • серверы со статусами (раскрывающийся список).

Пример информации кластерного транспорта gfs2: image

События

Вкладка События содержит сообщения о работе транспорта с возможностью их сортировки по признакам - «По всем типам», «Ошибки», «Предупреждения», «Информационные». Также имеется возможность отображения только непрочитанных сообщений.

Теги

Вкладка Теги содержит список присвоенных транспорту меток. Также имеется возможность обновления, создания и применения тега.

Watchdog

Для работы кластерных транспортов ocfs и gfs2 требуется наличие устройства /dev/watchdog. Появление сего устройства в системе зависит от того, загружен ли правильный один из множества вариантов модуль ядра для разных возможных плат bmc. ECP VeiL автоматически при загрузке, раз в сутки или по требованию администратора проверяет наличие устройства, и при его отсутствии пытается последовательно загрузить модули ipmi-watchdog, iTCO_wdt, softdog. После каждой попытки проверяется наличие устройства, если оно есть, дальше попытки не ведутся. Указанные выше порядок с нашей точки зрения являются наиболее универсальным для тех серверов, что подвергались тестированию. При необходимости стоит выбирать подходящий для своего сервера модуль.

Управлять watchdog можно в CLI командами system watchdog *.

Добавление/Удаление узлов от кластерного транспорта gfs2

  • Если узел, который нужно удалить, активен, то необходимо перевести его в сервисный режим.
  • Нажать кнопку "Реконфигурировать" у кластерного транспорта.

Что произойдет:

  1. Возьмутся все активные узлы кластера
  2. На всех активных узлах пропишется новая конфигурация corosync и dlm
  3. На всех активных узлах сервисы corosync перепрочитают конфигурацию

Смена имени таблицы блокировок при монтировании LUN, где ранее уже был развернут gfs2 в другом кластере

Пример ошибки монтирования gfs2: image

Следует зайти в CLI любого сервера в составе кластера с gfs2 и выполнить команду tunegfs2 -L {cluster_id}:{lun_id} {lun_device}.

Пример смены имени таблицы блокировок

tunegfs2 -L 22c7867a:5aa6f80f /dev/mapper/3600143801259dcf30000b00000220000

Переменные:

  • cluster_id - первые 8 символов id кластера (если id кластера 22c7867a-f705-46f1-a01d-d215f4f6b388, то нам нужны 22c7867a)

  • lun_id - первые 8 символов id LUN (если id LUN 5aa6f80f-4c8c-4c84-8037-c29800b93f92, то нам нужны 5aa6f80f)

  • lun_device - Путь LUN, например /dev/mapper/3600143801259dcf30000b00000220000

id сущности

Его можно посмотреть и скопировать в буфер кнопкой в левом верхнем углу вкладки сущности.

После этого можно снова попробовать примонтировать LUN к серверам кластера.

Добавление журналов к файловой системе gfs2

Пример ошибки монтирования gfs2: image

Максимальное количество узлов gfs2

При форматировании LUN в gfs2 из Web-интерфейса выбирается максимальное количество узлов в кластере (по умолчанию 16, максимум 64).

  • Посмотреть текущие журналы и их количество можно в CLI любого сервера в составе кластера с gfs2, выполнив команду: gfs2_edit -p jindex {lun path} | grep journal.

    Пример команды

    gfs2_edit -p jindex /dev/mapper/3600143801259dcf30000b00000220000 | grep journal

  • Добавить журналы можно в CLI любого сервера (предварительно обязательно смонтировав на узле это LUN) в составе кластера с gfs2 , выполнив команду: gfs2_jadd -j {journal_count} {lun path}.

    Пример команды

    gfs2_jadd -j 2 /dev/mapper/3600143801259dcf30000b00000220000

Пример добавление журналов gfs2

image

Back to top