Кластерный транспорт типа GFS2

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

Работа GFS2-транспорта обеспечивается службами corosync, DLM, SBD, и NTP.

Corosync

Corosync обеспечивает:

• Отслеживание добавления и удаления узлов из кластера.

  Для транспорта GFS2.

• Определение наличия кворума.

  При отсутствии кворума обмен данными с хостом блокируется для предотвращения ситуации "split-brain".

• Надежный и упорядоченный обмен сообщениями между узлами.

  Общение происходит с помощью протокола Totem.

  Большое значение для функционирования Totem имеет токен.

Токен — это маркер (пакет данных), циркулирующий между узлами кластера Corosync. Его отсутствие на узле в течение некоторого времени служит основанием для пересоздания кластера службами Corosync на этом узле.

Возможными причинами этого могут быть, к примеру:

• Нестабильность сети.

• Отказ узла, который принял токен последним.

Перед принятием решения о пересоздании кластера предпринимается несколько попыток повторного отправления токена.

Кворум Corosync достигается при фактическом наличии в кластере узлов с общим числом голосов int((N / 2) + 1) (без дробной части), где N — число голосов, вычисленное из заданной конфигурации кластера.

Узлам типа Node назначается один голос, узлам типа Controller+Node — два.

Кластер SpaceVM и кластер Corosync функционируют параллельно после того, как путем создания или реконфигурации кластерного транспорта GFS2 создается конфигурация Corosync с узлами, входящими в кластер SpaceVM.

Сети, использующие Corosync — это сети, которые заданы при создании или реконфигурации кластерного транспорта.

DLM и SDB

Служба DLM управляет распределенными блокировками при операциях с примонтированными GFS2 файловыми системами. Эта служба связана со службой SBD, которая отвечает за ограждение узлов.

SpaceVM монтирует GFS2 LUN в режиме управляемой dlm-блокировки (lock_dlm), создавая отдельное пространство блокировок (lockspace) для каждой примонтированной ФС GFS2. От состояния этих пространств блокировок на данном узле зависит доступность данных на соответствующих LUN.

Ограждение узлов в кластере GFS2 необходимо при, например, угрозе параллельного доступа узлов к одному и тому же ресурсу, которые не имеют между собой связи. Это возможно при потере связи с узлом, вследствие чего остальной кластер не будет иметь информации о занимаемых данным узлом общих ресурсах (для GFS2 это группы блоков на диске с ФС). При определении такой ситуации узлы, потерявшие кворум, могут быть ограждены самостоятельно посредством WDT (watchdog), который находится в распоряжении службы SBD.

Именно поэтому при ограждении узла в журнале BMC (iDRAC, iLO, IPMI и др.) можно увидеть сообщения о сработавшем WDT.

system watchdog <command>

При определении отказа узла на уровне кластера SpaceVM (ВД) срабатывает выбранный в Web-интерфейсе SpaceVM механизм ограждения.

При ограждении узла прочие узлы отменяют незавершенные изменения, относящиеся к огражденному, при помощи отката журналов GFS2. Этим обеспечивается целостность данных на ФС. Потеря данных в кэше ВМ, располагавшихся на огражденном хосте, считается меньшей проблемой по сравнению с непредсказуемым состоянием кластерного хранилища и потери данных на нем.

NTP

Служба NTP обеспечивает синхронность времени на узлах, что важно для вхождения узлов в кластер Corosync.

node nodes-cli "ntp check"

HOW TO

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

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

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

3. Создать кластерный транспорт gfs2. Для удобства можно выбрать LUN, который будет сразу отформатирован (если он не содержит файловую систему GFS2, иначе его служебная информация модифицируется для работы с текущим кластером, а данные остаются нетронутыми), примонтирован, и на нем будет создан пул данных. В дальнейшем можно отформатировать, примонтировать и создать пул данных на других LUN. При выборе нескольких внешних сетей их приоритет (см. примечание о сетевой конфигурации) убывает по порядку сетей в списке. Сеть mgmt добавляется всегда, но с наименьшим приоритетом. Пример 1: при создании транспорта не указано ни одной внешней сети. Результат: используется только одна сеть mgmt. Пример 2: при создании транспорта указаны внешние сети ext1, ext0 (в таком порядке). Результат: максимальный приоритет у ext1, далее ext0, наименьший приоритет у сети mgmt.

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

1. Отформатировать LUN в файловую систему GFS2. Если LUN уже содержит ФС GFS2, созданную ранее в другом кластере, см. примечание ниже "Смена имени таблицы блокировок при монтировании LUN, где ранее уже был развернут GFS2 в другом кластере"

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

3. Создать пул данных GFS2 на этом LUN или отсканировать, если ФС с дата-пулом существовала ранее.

Диагностика GFS2

Для диагностики GFS2 используется отладочный режим.

Его управление осуществляется командами:

• Включение отладочного режима:

  storage gfs2debug enable
  

• Выключение отладочного режима:

  storage gfs2debug disable
  

• Проверка статуса отладочного режима:

  storage gfs2debug status
  

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

Дополнительные сведения

Примеры использования команд

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  timestamp: on
}

nodelist {

  node {
    name: 6cca2ca9-a1ce-47a0-83cd-b501a780955d
    nodeid: 1
    quorum_votes: 2
    ring0_addr: 6cca2ca9-a1ce-47a0-83cd-b501a780955d
    ring1_addr: 6cca2ca9-a1ce-47a0-83cd-b501a780955d-ex1-120
  }

  node {
    name: 6137ca41-6964-4791-b000-98fc84ee0fe3
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 6137ca41-6964-4791-b000-98fc84ee0fe3
    ring1_addr: 6137ca41-6964-4791-b000-98fc84ee0fe3-ex1-121
  }

  node {
    name: e0ec5e71-2f76-4178-aad4-4951b2979b9b
    nodeid: 3
    quorum_votes: 1
    ring0_addr: e0ec5e71-2f76-4178-aad4-4951b2979b9b
    ring1_addr: e0ec5e71-2f76-4178-aad4-4951b2979b9b-ex1-122
  }

}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: 7157ad2f
  config_version: 1778594812838566
  ip_version: ipv4
  secauth: off
  version: 2
  keyfile: /var/lib/ecp-veil/controller/local_data/authkey
  transport: knet
  token: 3000
  join: 60
  threads: 2
  max_messages: 20
  vsftype: none
  window_size: 170
  token_retransmits_before_loss_const: 10
  interface {
    linknumber: 0
    knet_transport: sctp
    knet_link_priority: 1
  }
  interface {
    linknumber: 1
    knet_transport: sctp
    knet_link_priority: 2
  }
}

lm Lockspaces info:
dlm lockspaces
name          a34be778
id            0x66978c01
flags         0x00000000 
change        member 3 joined 1 remove 0 failed 0 seq 3,3
members       1 2 3 
all nodes
nodeid 1 member 1 failed 0 start 1 seq_add 3 seq_rem 0 check none
nodeid 2 member 1 failed 0 start 1 seq_add 1 seq_rem 0 check none
nodeid 3 member 1 failed 0 start 1 seq_add 2 seq_rem 0 check none

name          b846a358
id            0xec09038a
flags         0x00000000 
change        member 3 joined 1 remove 0 failed 0 seq 3,3
members       1 2 3 
all nodes
nodeid 1 member 1 failed 0 start 1 seq_add 1 seq_rem 0 check none
nodeid 2 member 1 failed 0 start 1 seq_add 1 seq_rem 0 check none
nodeid 3 member 1 failed 0 start 1 seq_add 3 seq_rem 2 check none

gfs2_lockcapture info:
List of all the mounted GFS2 filesystems that can have their lockdump data captured:
a20a1521:291e746b-4e9d-478c-aedd-2248f7017e71(id:2)
        a20a1521:a34be778 --> /dev/mapper/36000d31004a4f4000000000000000140 on /storages/gfs2/gfs2_df0a4266 type gfs2 (rw,noatime,nodiratime,debug,x-systemd.automount,_netdev) [a20a1521:a34be778]
        a20a1521:b846a358 --> /dev/mapper/3600143801259dcf30001100000200000 on /storages/gfs2/gfs2_b846a358 type gfs2 (rw,noatime,nodiratime,debug,x-systemd.automount,_netdev) [a20a1521:b846a358]
Mountpoints:
systemd-1 on /storages/gfs2/gfs2_b846a358 type autofs (rw,relatime,fd=63,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=47126)
/dev/mapper/3600143801259dcf30001100000200000 on /storages/gfs2/gfs2_b846a358 type gfs2 (rw,noatime,nodiratime,debug,x-systemd.automount,_netdev)
/dev/mapper/36000d31004a4f4000000000000000140 on /storages/gfs2/gfs2_df0a4266 type gfs2 (rw,noatime,nodiratime,debug,x-systemd.automount,_netdev)
gfs2 lun /dev/mapper/3600143801259dcf30001100000200000 journals info:
  3/3 [fc7745eb] 1/20 (0x1/0x14) +0: File    journal0
  4/4 [8b70757d] 2/32859 (0x2/0x805b) +0: File    journal1
  5/5 [127924c7] 3/65698 (0x3/0x100a2) +0: File    journal2
  6/6 [657e1451] 4/98537 (0x4/0x180e9) +0: File    journal3
  7/7 [fb1a81f2] 5/131376 (0x5/0x20130) +0: File    journal4
  8/8 [8c1db164] 6/164215 (0x6/0x28177) +0: File    journal5
  9/9 [1514e0de] 7/197054 (0x7/0x301be) +0: File    journal6
  10/10 [6213d048] 8/229893 (0x8/0x38205) +0: File    journal7
gfs2 lun /dev/mapper/36000d31004a4f4000000000000000140 journals info:
  3/3 [fc7745eb] 1/131 (0x1/0x83) +0: File    journal0
  4/4 [8b70757d] 2/33155 (0x2/0x8183) +0: File    journal1
  5/5 [127924c7] 3/66179 (0x3/0x10283) +0: File    journal2
  6/6 [657e1451] 4/99203 (0x4/0x18383) +0: File    journal3

Watchdog

Для работы кластерных транспортов GFS2 требуется наличие устройства /dev/watchdog. Появление этого устройства в системе зависит от того, загружен ли правильный модуль ядра для разных возможных плат BMC.

SpaceVM автоматически при загрузке, раз в сутки или по требованию администратора, проверяет наличие устройства, и при его отсутствии пытается последовательно загрузить модули ipmi-watchdog, iTCO_wdt, softdog. После каждой попытки проверяется наличие устройства. Если оно есть, дальнейшие попытки не предпринимаются.

Управление watchdog производится в CLI командами:

system watchdog <command>

Добавление узлов в КТ

• Добавить узел в выбранный кластер.

• Нажать кнопку Реконфигурировать у кластерного транспорта.

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

1. Возьмутся все активные узлы кластера.

2. На всех активных узлах пропишется новая конфигурация corosync и dlm.

3. На всех активных узлах сервисы corosync повторно "прочитается" конфигурацию.

Удаление узла из КТ

• Перевести узел в сервисный режим.

• Все виртуальные машины необходимо переместить на другие узлы.

• Отключить узел от блочного хранилища (Хранилища - Сетевые хранилища - Блочные - <Хранилище> - удалить узел).

• Если узел исправен: Открыть CLI удаляемого узла и выполнить команду storage gfs2-remove.

• Удалить узел форсированно (удаление сервера в сервисном режиме).

• Нажать кнопку Реконфигурировать у кластерного транспорта.

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

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

Следует зайти в 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

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

Журналы ФС и их добавление

При форматировании LUN в файловую систему GFS2 необходимо выбрать опцию Максимальное количество узлов в кластере (по умолчанию 16, максимум 64). Это необходимо для создания на LUN отдельных файлов журналов (по умолчанию размер журналов вычисляется в пределах от 8 до 1024 МБ, это зависит от размера файловой системы) на каждый узел в составе кластера.

Если требуется превысить текущее количество узлов, использующих данный LUN, необходимо увеличить количество журналов. Для этого: - в свойствах LUN нажать кнопку Журналы GFS2; - в открывшемся окне указать желаемое число журналов GFS2 на LUN.

Узнать число журналов на LUN с GFS2 можно двумя способами: - в Web-интерфейсе: в свойствах LUN (при наличии файловой системы GFS2) нажать кнопку Детальная информация ФС; - в CLI: выполнить команду storage gfs2. В данном случае информация о журналах отображается только для примонтированных LUN.

Расширение ФС

Действия при отключении питания блочного хранилища со всех узлов во время работы GFS2

Действия:

• Необходимо остановить или перенести все ВМ и виртуальные диски, расположенные на данном хранилище, если сбой коснулся не всех узлов (не вызван отключением iSCSI-сервера).

• Поочередно на каждом из узлов:

  • Остановить или перенести все ВМ и виртуальные диски, задействованные на узле на другие совместные пулы данных.

  • Удалить запись монтирования поврежденной ФС из /etc/fstab на узле.

  • Размонтировать ФС на узле (не допускается использование кнопки Размонтировать).

  • В случае, если ограждение узла не произошло, необходимо произвести перезагрузку.

• После перезагрузки всех узлов необходимо запустить команду для исправления ФС, используя команду shell любого из узлов:

  fsck.gfs2 -y <lun_path>
  

  Пример ввода fsck.gfs2 -y

  fsck.gfs2 -y /dev/mapper/3600143801259dcf30000b00000220000
  

• После завершения исправления ФС необходимо поочередно примонтировать ФС на узлах, используя кнопки управления, расположенные напротив серверов в разделе основного меню Хранилища - LUNs - <LUN ФС GFS2&gt>.