Управление кластерным хранилищем с помощью LINSTOR

Электронное хранилище

LINSTOR​​ ​  - это инструмент для автоматизированного управления кластерами, который позволяет упростить управление DRBD​ и предлагает широкий спектр функций, включая резервирование и моментальные снимки.

LINSTOR​​  - это программное обеспечение с открытым исходным кодом, предназначенное для управления блочными устройствами хранения в больших кластерах Linux серверов. Оно упрощает развертывание хранилища высокой доступности с помощью распределенного реплицированного блочного устройства версии 9 (DRBD​ 9), динамически резервирует хранилище и упрощает управление посредством интеграции с Kubernetes, Docker, OpenStack, OpenNebula, OpenShift и т.д. Кроме того, LINSTOR​ может обеспечивать высокую доступность с помощью DRBD​. В этой статье я рассмотрю настройку и работу этого инструмента.

На первый взгляд, автоматизация хранения данных не кажется сложной задачей: уже давно изучены этапы создания, расширения и удаления томов, а хранилища не ограничиваются объемом отдельных устройств хранения или объемом и положением слоев или разделов. Такие технологии, как диспетчер логических томов (LVM) или файловая система Zetabyte (ZFS), уже давно позволяют управлять пулами хранения, в которых можно легко создавать или удалять практически неограниченное количество томов хранилища любых размеров.

Что трудного в том, чтобы автоматизировать такие рутинные задачи с помощью нескольких скриптов? Но дело в том, что при автоматизации необходимо уделять внимание мельчайшим деталям, поскольку этот процесс содержит много потенциальных ловушек для администратора. Какие-то мелкие моменты, которые могут быть не заметны при ручном администрировании, легко могут привести к проблемам в автоматизации – например, когда файлы устройств еще не существуют в файловой системе /dev, хотя соответствующая команда для создания тома уже сообщила о завершении, или если вы хотите удалить не смонтированные тома, которые используются подсистемой udev. Если дополнительно требуется централизованное управление целым кластером, а не только одной системой, становится ясно, что несколько готовых скриптов не справляются с этой задачей.

Три компонента

В таких случаях поможет LINSTOR​ [1] от LINBIT​. Это пакет программного обеспечения с открытым исходным кодом, состоящий из нескольких компонентов для управления кластерным хранилищем. Он позволяет не только создавать, масштабировать и удалять отдельные простые тома на одном из узлов кластерного хранилища, но и выполнять репликацию отдельных томов или согласованных групп из нескольких томов между несколькими узлами кластера. За выполнение этого процесса отвечает технология репликации DRBD​. LINSTOR​ также можно использовать для настройки дополнительных функций томов, например, шифрование или дедупликация данных. С помощью более сложных технологий хранения данных, например, DRBD​, программа в автоматическом режиме управляет различными системными ресурсами, включая обязательные номера TCP/IP портов для ссылок репликации или "имена устройств" для дисков в файловой системе /dev. Расчет диского пространства для метаданных DRBD​ также автоматизирован.

LINSTOR​, по сути, состоит из трёх компонентов:

1. Контроллер (controller) LINSTOR​​ управляет конфигурацией всего кластера и должен быть установлен хотя бы на одном из узлов кластера. В связи с необходимостью в высокой доступности контроллер обычно устанавливается на нескольких узлах.

2. Спутник (satellite) LINSTOR​​ работает на каждом узле кластерного хранилища, где он выполняет действия, необходимые для автоматического управления пространством хранения данных.

3. Завершают набор пакетов - клиенты (client) LINSTOR​​. С одной стороны, это может быть просто приложение командной строки, которое может использоваться для работы LINSTOR​​ как вручную, так и с помощью скриптов. С другой стороны, это может быть драйвер, обеспечивающий интеграцию с системой управления хранилищем других продуктов, например сред виртуализации типа OpenStack, OpenNebula или Proxmox, или технологий контейнеризации, таких как Kubernetes.

Все эти компоненты являются прозрачным для сети, это означает, например, что клиенту не обязательно быть на одном узле с контроллером, с которым он взаимодействует.

Установка

Чтобы установить LINSTOR​​, вам нужна как минимум 8-я версия среды выполнения Java (JRE), которая обычно устанавливается как зависимость при установке дистрибутивов. Это может быть OpenJDK, Oracle HotSpot VM или IBM Java VM, неважно.

Пакет обычно устанавливается в виде дерева каталогов для соответствующих типов файлов или папок, поэтому данные конфигурации попадают в каталог /etc, переменные данные, такие как журналы и отчеты - в каталог /var/log, а программные библиотеки - в каталог /usr/share/LINSTOR​-server/lib. Также компоненты можно устанавливать в другие каталоги с помощью параметров командной строки или записей в файле конфигурации LINSTOR​​.

По умолчанию контроллер LINSTOR​​ опирается на интегрированную базу данных, которая автоматически инициализируется при первом запуске контроллера. В случае более масштабных систем вы можете настроить контроллер на использование централизованной базы данных SQL, такой как PostgreSQL, MariaDB или DB2.

После установки из дистрибутива запустите модули, установленные на соответствующем узле, с помощью подсистемы systemd:

systemctl start linstor controller
systemctl start linstor satellite

Здесь я привожу настройки конфигурации LINSTOR​​ по умолчанию для сетевого соединения отдельных компонентов, используемых пулов ресурсов, диапазонов портов TCP/IP, диапазонов номеров устройств, одноранговых слотов DRBD​ и тому подобного. Кроме того, я не буду использовать соединения с SSL-шифрованием, поскольку описание этапов настройки, необходимых для настройки всех параметров, не входят в тему этой статьи.

Настройка кластера

Прежде чем приступить к созданию конфигурации кластера и пулов хранения в LINSTOR​​, важно знать ряд основных понятий, в том числе ряд объектов и логические зависимости между ними. Наиболее важными объектами являются: узел (node), сетевой интерфейс (interface), определение пула хранения (storage pool definition) и пул хранения (storage pool), определение ресурса (resource definition) и ресурс (resource), а также определение тома (volume definition) и том (volume). Каждый соответствующий объект определения управляет информацией, идентичной для всех объектов соответствующей категории определения во всем кластере (т. е. на всех узлах кластера). Например, определение тома содержит данные, идентичные на всех узлах кластера, такие как размер реплики тома на нескольких узлах кластера. На основе этого принципа возникают зависимости между этими объектами. Чтобы создать начальный том, сначала необходимо создать необходимые объекты в такой последовательности, которая отражает зависимости.

Для первоначальной настройки вы можете использовать клиент LINSTOR​​ для управления контроллером вручную. Чтобы взаимодействовать с активным контроллером клиенту требуется имя хоста или IP-адрес узлов кластера, на которых может запускаться контроллер. Установите переменную среды LS_CONTROLLERS перед запуском клиента LINSTOR​. Если вы не зададите дополнительных параметров, клиент запустится в интерактивном режиме:

export LS_CONTROLLERS=192.168.133.11
linstor

Как правило, процесс настройки начинается с объектов узел (node), представляющих отдельные узлы кластера хранения данных. При создании узла на контроллере, вы определяете IP-адрес (и порт, если необходимо), который контроллер использует для связи с компонентом-спутником на соответствующем узле кластера. Вы также можете определить, работает ли узел кластера с контроллером, спутником или обоими компонентами - это особенно полезно для обеспечения большей прозрачности в кластере.  Также требуется ввести имя, под которым узел кластера зарегистрирован на контроллере. В идеале это имя должно совпадать с именем соответствующего узла кластера. Вы можете узнать это имя с помощью команды uname -n. Домен вводить не обязательно, если нет необходимости различать отдельные узлы:

node create --node-type Combined romulus 192.168.133.11
node create --node-type satellite remus 192.168.133.12
node create --node-type satellite vulcan 192.168.133.13
node create --node-type satellite kronos 192.168.133.14

В дополнение к обязательнному сетевому интерфейсу, который вы определили при создании узла, вы теперь можете настроить дополнительные сетевые интерфейсы (рисунок 1). Например, если вы хотите использовать DRBD​​, вы можете задать дополнительные сетевые интерфейсы для репликации различных ресурсов DRBD​​ на этих интерфейсах:

node interface create romulus drbd 192.168.144.11
node interface create remus drbd 192.168.144.12
node interface create vulcan drbd 192.168.144.13
node interface create kronos drbd 192.168.144.14

Рисунок 1: Просмотр всех созданных узлов и сетевых интерфейсов.

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

Когда вы определяете пул хранения, вы указываете, к какому типу он принадлежит (например, LVM Volume Group или  ZFS zpool) и используется ли толстое или тонкое резервирование. В зависимости от типа пула вы указываете имя группы томов, тонкий пул LVM или пул ZFS в качестве параметра драйвера пула хранения LINSTOR​​. Естественно, объект пула хранения также имеет уникальное имя, которое вы можете свободно выбирать, соблюдая ограничения по типу и количеству символов.

Имя DfltStorPool (Default Storage Pool) является специализированным, поскольку контроллер автоматически выбирает этот пул, если вы не указываете пул хранения в различных объектах определения или в объекте ресурса или тома при последующем создании ресурсов хранения данных.

Команда

storage-pool create lvmthin romulus thinpool drbdpool/thinpool

создает пул хранения с именем thinpool с драйвером LVM (рисунок 2).

Рисунок 2: Список созданных пулов хранения данных.

Работа с LINSTOR​​

Выполнив хотя бы минимальную конфигурацию LINSTOR​​, вы можете определить исходные ресурсы и их объемы и сгенерировать их на одном или нескольких узлах кластера. Разумно начать с простой конфигурации, чтобы сначала убедиться, что все компоненты работают правильно. Поэтому в первом примере создается только один локальный том LVM. В первую очередь необходимо создать определение для ресурсов, тома которых используют только уровень хранения, и выбрать LocalData в качестве имени для определения ресурса, а, следовательно, и для их ресурсов:

resource-definition create --layer-list storage LocalData

Теперь добавьте один том объемом 150 МБ в определение ресурса с именем LocalData:

volume-definition create SharedData 150m

Наконец, в узлах кластера vulcan и kronos создайте ресурс, связанный с этими определениями, имеющий пул хранения thinpool для тома соответствующего ресурса:

resource create --storage-pool thinpool vulcan kronos LocalData

Если эти действия выполнены без ошибок, то список логических томов LVM на узлах кластера vulcan и kronos должен содержать запись тома с именем LocalData_00000 (Листинг 1). Затем вы можете отформатировать и смонтировать этот логический том LVM обычным способом.

Листинг 1

Логические тома LVM

vulcan ~ # lvs drbdpool
  LV               VG        Attr        LSize    Pool      Origin Data%  Meta%  Move
  LocalData_00000  drbdpool  Vwi-a-tz--  152.00m  thinpool  0.04
  thinpool         drbdpool  twi-aotz--  300.00m            0.02          10.94

Следующий пример применения будет немного сложнее: на этот раз у нас будет ресурс с томом, который реплицируется с тройной избыточностью на трех узлах кластера с DRBD​​. Поэтому при создании определения ресурса в списке слоев выбираются слои DRBD​​ и storage, а ресурсу присваивается имя SharedData, соответствующее репликации тома:

resource-definition create --layer-list drbd,storage SharedData

Снова добавьте к этому ресурсу один том объемом 150 МБ:

volume-definition create SharedData 150m

На этот раз предоставьте выбор узлов кластера контроллеру LINSTOR​​, указав только требуемую избыточность для параметра --auto-place:

resource create --storage-pool thinpool --auto-place 3 SharedData

В списке ресурсов и томов показано, какие узлы контроллер выбрал для репликации ресурса DRBD​​ и какие ресурсы автоматически доступны для него. В этом случае были автоматически выбраны узлы кластера kronos, remus и romulus для обеспечения тройной избыточности тома, реплицируемого устройством DRBD​​. Порт TCP/IP 7000 зарезервирован для сетевой связи ресурсом DRBD​​, а тому был присвоен номер устройства 1000 (рисунок 3). Том можно найти как запись DRBD​1000 в каталоге /dev. Фактическое пространство для хранения данных снова предоставлено логическим томом LVM, который отображается по команде lvs drbdpool как SharedData_00000.

Рисунок 3: Списки ресурсов и томов.

Теперь, когда управление хранилищем автоматизировано, очень просто выполнять обратную модификацию существующих ресурсов хранения данных. Например, вы можете легко перенести одну из существующих реплик на другой узел кластера, добавив сначала четвертую реплику, а затем удалив одну из исходных реплик. Если дождаться повторной синхронизации DRBD​​, тройная избыточность тома будет поддерживаться всегда.

В качестве примера, перенесите реплику DRBD​-Resource между узлами кластера kronos и vulcan. Сначала добавьте реплику к узлу vulcan, назначив ему ресурс LINSTOR:

resource create vulcan SharedData -s thinpool

После того как DRBD​​ завершит повторную синхронизацию, вы можете удалить реплику на kronos:

resource delete kronos SharedData

Чтобы навсегда удалить ресурс из всех узлов кластера, вы также можете непосредственно удалить определение ресурса для этого ресурса, то есть сначала ресурс удаляется из всех узлов кластера, на которых он был создан:

resource-definition delete LocalData

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

Работа с мгновенными снимками

Для томов, расположенных в пуле хранения thin provisioning (т. е. в настоящее время это пулы хранения с драйверами lvmthin и zfsthin), LINSTOR​​ также предлагает функцию моментальных снимков по всему кластеру, причем это касается не только локальных томов хранения, но и томов хранения, реплицированных DRBD​.

Чтобы создать моментальные снимки реплицированных томов, идентичных на всех затронутых узлах кластера, LINSTOR​​ останавливает операции ввода-вывода на данном ресурсе на уровне DRBD​​. В результате остановки данные на томе внутреннего хранилища, которые используется DRBD​​, не меняются, и разные узлы кластера могут создавать моментальный снимок в разное время. Операции ввода-вывода на уровне DRBD​​ не возобновляются до тех пор, пока моментальный снимок не будет создан на всех узлах кластера.

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

snapshot create romulus remus SharedData Snap1

Моментальный снимок можно использовать либо для создания нового ресурса на основе массива данных моментального снимка (snapshot resource restore), либо для отката ресурса к состоянию, когда был сделан моментальный снимок (snapshot rollback).

Оба действия могут выполняться только на узлах кластера, на которых доступен моментальный снимок. Проще восстановить моментальный снимок в новом ресурсе. Для этого сначала создайте "пустое" определение ресурса (без определений томов) для нового ресурса:

resource-definition create SharedData_Restore
volume-definition create SharedData_Restore 150m

Затем вы можете восстановить моментальный снимок в новом ресурсе:

snapshot resource restore --from-resource SharedData --from-snapshot Snap1 --to-resource SharedData_Restore romulus remus

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

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

resource delete vulcan SharedData

LINSTOR​​ позволяет оставить ресурс в качестве клиентского ресурса без внутреннего хранилища в качестве ресурса для кворума - tiebreaker, если эта функция включена. Тем не менее, ресурс tiebreaker также может помешать сбросу массива данных. Вы можете отключить функцию tiebreaker для этого ресурса, удалив его вручную. В этом случае просто повторите команду resource delete. Далее ресурс сбрасывается до версии на моментальном снимке с помощью команды:

snapshot rollback SharedData Snap1

Естественно, после сброса массива данных дальнейшие реплики реплицированного ресурса можно добавлять в кластер путем повторного создания соответствующего ресурса на дополнительных узлах кластера, что, само собой, требует повторной синхронизации набора данных:

resource create vulcan kronos SharedData --storage-pool thinpool

Моментальные снимки сохраняются, даже если удален исходный ресурс, из которого они были созданы. В иерархии объектов LINSTOR​​ моментальные снимки связаны с определением ресурса (рисунок 4). Поэтому вы не можете удалить их, пока не удалите все моментальные снимки.

Рисунок 4: Состояние ресурсов после восстановления из моментального снимка и повторной синхронизации.

Интеграция с платформами виртуализации и контейнеризации

С точки зрения автоматизации хранилища интеграция с различными платформами, которые автоматически предоставляют томы хранения, является более предпочтительной, чем ручное управление кластерным хранилищем с клиента LINSTOR​​. К таким платформам относятся как популярные платформы виртуализации, например, OpenStack, OpenNebula или Proxmox, так и контейнерные платформы, например, Kubernetes.

LINSTOR​​ можно интегрировать в эти платформы с помощью соответствующих драйверов, и, например, при создании новой виртуальной машины (VM) в OpenNebula виртуальный системный диск для этой виртуальной машины автоматически создается в соответствии с профилем, подготовленным в LINSTOR​​. Эти профили называются группами ресурсов (resource groups)  и могут использоваться для указания определенных свойств, включая используемый пул хранения, количество реплик для репликации с помощью DRBD​​ или интеграцию уровня дедупликации данных.

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

Драйверы для соответствующих платформ доступны в отдельных проектах GitHub [2]. Их названия обычно начинаются с префикса LINSTOR​- (например, linstor​-proxmox и linstor​-docker-volume).

Выводы

LINSTOR​​ - это бесплатный пакет, предоставляющий администраторам инструменты для автоматизации управления кластерами. Он позволяет упростить управление DRBD​​ и предлагает широкий спектр функций, включая резервирование и моментальные снимки. Драйверы уже доступны для интеграции в существующие облачные фреймворки, например, Kubernetes, OpenNebula и OpenStack. Возникающие проблемы поможет решить активное сообщество [3] и коммерческая поддержка поставщиков.

Дополнительные материалы

1.     LINSTOR​

2.     Драйверы платформы

3.     Поддержка сообщества

Все торговые марки LINBIT защищены авторским правом.