Общая схема
Наше решение будет напоминать стандартную схему репликации какой-нибудь базы данных.
- У нас есть три ноды
- На каждой ноде распределенное drbd-устройство.
- На устройстве обычная файловая система (ext4)
- Только один сервер может быть мастером
- На мастере запущен NFS-сервер в LXC-контейнере.
- Все ноды обращаются к устройству строго через NFS
- При необходимости мастер может переехать на другую ноду, вместе с NFS-сервером
DRBD9 имеет одну очень крутую функцию которая сильно все упрощает:
drbd-устройство автоматически становиться Primary в тот момент когда оно монтируется на какой-нибудь ноде. В случае если устройство помечено как Primary, любая попытка смонтировать его на другой ноде приведет к ошибке доступа. Таким образом обеспечивается блокировка и гарантированная защита от одновременного доступа к устройству.
Почему это все сильно упрощает? Потому что при запуске контейрнера Proxmox автоматически монтирует это устройство и оно становится Primary на этой ноде, а при остановке контейнера наоборот размонтирует и устройство становится опять Secondary.
Таким образом нам больше не нужно беспокоиться о переключении Primary/Secondary устройств, Proxmox будет делать это автоматически, УРА!
Отказоустойчивый NFS-сервер
К сожалению на момент написания статьи Linstor имеет готовую интеграцию только с Kubernetes. Но в конце года ожидаются драйверы и для остальных систем Proxmox, OpenNebula, OpenStack.
Но пока готового решения нет, а старое нам так или иначе не нравится. Попробуем использовать DRBD9 по старинке для организации NFS-доступа на общий раздел.
Тем не менее данное решение так-же окажется не без плюсов, ведь NFS-сервер позволит вам организовать конкурентный доступ к файловой системе хранилища с нескольких серверов без необходимости использования сложных кластерных файловых систем с DLM, таких как OCFS и GFS2.
При этом вы получите возможность переключать роли Primary/Secondary нод просто мигрируя контейнер с NFS-сервером в интерфейсе Proxmox.
Вы так же сможете хранить любые файлы внутри этой файловой системы, так же как виртуальные диски и бэкапы.
В случае если вы используете Kubernetes вы сможете организовать ReadWriteMany доступ для ваших PersistentVolumes.
Как установить OpenMediaVault на Proxmox
Установка Proxmox
Вам понадобится установочный диск, взять его можно на официальном сайте:
Установка проста и интуитивно понятна, так что думаю, не вызовет у вас лишних вопросов.
Скажу только что желательно иметь отдельный физический диск под систему, чтобы в случае чего её всегда можно было бы безболезненно переустановить, не затрагивая при этом диски с данными.
При установке Proxmox можно так же выбрать файловую систему ZFS или даже настроить програмный RAID.
После установки, не забудьте прописать для репозитория Proxmox, чтобы иметь возможность устанавливать из него пакеты.
Установка OpenMediaVault
Установим репозитроий OpenMediaVault 3.0 Erasmus:
Как я говорил ранее, пакет имеет некоторые неразрешимые зависимости с компонентами Proxmox, в часности это качается пакета , который в Proxmox начиная с версии 4.0 является fencing-демоном по умолчанию. В нашем случае он установлен по умолчанию как зависимость от , но мы его не используем т.к. не используем кластеризацию.
В любом случае эти зависимости нам нужно как-то разрешить, и поэтому мы пересоберем deb-пакет для .
Подготовим окружение для сборки:
Скачаем исходники OpenMediaVault 3.0 Erasmus, и перейдем в директорию для сборки:
Эта команда покажет нам необходимые зависимости, которые мы должны установить в системе перед сборкой пакета:
Исходя из вывода предыдущей команды установим необходимые пакеты:
Теперь нам нужно удалить из зависимостей, для этого отредактируем и удалим оттуда .
Также необходимо удалить требование версии для :
Проверим зависимости для сборки еще раз:
И запустим саму сборку:
После сборки вы получите готовый deb-пакет, который мы и установим в систему:
Теперь установим остальные зависимости, для этого запустим:
Теперь можно запустить скрипт для начальной конфигурации, поменять пароль администратора / порт веб-сервера и что-нибудь еще:
Установка плагина ZFS:
Плагин устанавливается отдельно от OpenMediaVault и так как он тоже имеет неразрешимые зависимости мы тоже соберем его вручную:
Скачаем исходники, и перейдем в директорию для сборки:
Подправим зависимости, удалим так-как в Proxmox начиная с версии 4.0, ZFS уже идет в комплекте с ядром, до кучи за ненадобностью удалим так же / :
Проверим зависимости для сборки:
Запустим сборку:
После сборки установим полученный пакет и зависимости для него:
Если возникнут трудности со сброкой пакетов, в документации Debian есть неплохая статья на русском языке:
На этом пожалуй все, теперь вы имеете Proxmox и OpenMediaVault установленные на одной системе, самое время перейти в GUI создать и настроить пулы ZFS и подключить их в Proxmox.
Как это сделать я описывать не буду, об этом и так полно информации в интернете.
Настройка LXC-контейнера
Как я говорил раньше наш NFS-сервер будет работать в LXC-контейнере. Сам контейнер мы будем держать на устройстве , которое мы только что создали.
Сначала нам нужно создать файловую систему на нем:
Proxmox по умолчанию включает multimount protection на уровне файловой системы, в принципе мы можем обойтись и без нее, т.к
DRBD по умолчанию имеет собственную защиту, он просто запретит второй Primary для устройства, но осторожность нам не повредит
Теперь скачаем шаблон Ubuntu:
И создадим из него наш контейнер:
В данной команде мы указываем что корневая система нашего контейнера будет находиться на устройстве и добавим параметр что бы разрешить миграцию контейнера между нодами.
Если что-то пошло не так, вы всегда можете поправить это через интерфейс Proxmox или в конфиге контейнера
Proxmox распакует шаблон и подготовит корневую систему контейнера для нас. После этого мы можем запустить наш контейнер:
Настройка DRBD
Ну хорошо, с идеей разобрались теперь перейдем к реализации.
По умолчанию в комплекте с ядром Linux поставляется модуль восьмой версии drbd, к сожалению он нам не подходит и нам необходимо установить модуль девятой версии.
Подключим репозиторий LINBIT и установим все необходимое:
- — заголовки ядра необходимые для сборки модуля
- — модуль ядра в формате DKMS
- — основные утилиты для управления DRBD
- — интерактивный инструмент, как top только для DRBD
После установки модуля проверим, все ли в порядке с ним:
Если вы увидите в выводе команды восьмую версию значит что-то пошло не так и загружен in-tree модуль ядра. Проверьте что-бы разобраться в чем причина.
Каждая нода у нас будет иметь одно и тоже drbd-устройство запущенное поверх обычных разделов. Для начала нам нужно подготовить этот раздел под drbd на каждой ноде.
В качестве такого раздела может выступать любое блочное устройство, это может быть lvm, zvol, раздел диска или весь диск целиком. В этой статье я буду использовать отдельный nvme диск с разделом под drbd:
Стоит заметить, что имена устройств имеют свойство иногда меняться, так что лучше сразу взять за привычку использовать постоянный симлинк на устройство.
Найти такой симлинк для можно таким образом:
Опишем наш ресурс на всех трех нодах:
Желательно для синхронизации drbd использовать отдельную сеть.
Теперь создадим метаданные для drbd и запустим его:
Повторим эти действия на всех трех нодах и проверим состояние:
Сейчас наш диск Inconsistent на всех трех нодах, это потому, что drbd не знает какой диск должен быть взят в качестве оригинала. Мы должны пометить один из них как Primary, что бы его состояние синхронизировалось на остальные ноды:
Сразу после этого начнется синхронизация:
Нам не обязательно дожидаться ее окончания и мы можем параллельно выполнять дальнейшие шаги. Их можно выполнять на любой ноде, вне зависимости от ее текущего состояния локального диска в DRBD. Все запросы будут автоматически перенаправлены на устройство с UpToDate состоянием.
Стоит не забыть активировать автозапуск drbd-сервиса на нодах:
Proxmox и LXC-контейнеры
Теперь вопрос: почему Proxmox?
В принципе для построения подобной схемы мы могли бы использовать и Kubernetes так и обычную схему с кластер-менеджером. Но Proxmox предоставляет готовый, очень многофункциональный и в тоже время простой и интуитивно понятный интерфес практически для всего что нужно. Он из коробки умеет кластеризацию и поддерживает механизм fencing основанный на softdog. А при использовании LXC-контейнеров позволяет добиться минимальных таймаутов при переключении.
Полученное решение не будет иметь единой точки отказа.
По сути мы будем использовать Proxmox преимущественно как cluster-manager, где мы сможем рассматривать отдельный LXC-контейнер как сервис запущенный в классическом HA-кластере, лишь с тем отличием, что с контейнером в комплекте идет так же и его корневая система. То есть у вас нет необходимости устанавливать несколько экземаляров сервиса на каждом сервере отдельно, вы можете сделать это только один раз внутри контейнера.
Если вы когда-нибудь работали с cluster-manager software и обеспечением HA для приложений вы поймете что я имею ввиду.
Общая схема
Наше решение будет напоминать стандартную схему репликации какой-нибудь базы данных.
- У нас есть три ноды
- На каждой ноде распределенное drbd-устройство.
- На устройстве обычная файловая система (ext4)
- Только один сервер может быть мастером
- На мастере запущен NFS-сервер в LXC-контейнере.
- Все ноды обращаются к устройству строго через NFS
- При необходимости мастер может переехать на другую ноду, вместе с NFS-сервером
DRBD9 имеет одну очень крутую функцию которая сильно все упрощает:
drbd-устройство автоматически становиться Primary в тот момент когда оно монтируется на какой-нибудь ноде. В случае если устройство помечено как Primary, любая попытка смонтировать его на другой ноде приведет к ошибке доступа. Таким образом обеспечивается блокировка и гарантированная защита от одновременного доступа к устройству.
Почему это все сильно упрощает? Потому что при запуске контейрнера Proxmox автоматически монтирует это устройство и оно становится Primary на этой ноде, а при остановке контейнера наоборот размонтирует и устройство становится опять Secondary.
Таким образом нам больше не нужно беспокоиться о переключении Primary/Secondary устройств, Proxmox будет делать это автоматически, УРА!
Использование
Proxmox
Полученный iSCSI-таргет можно сразу-же подключить в Proxmox, не забыв снять галочку с Use LUN Directly.
Сразу после этого станет возможным создание LVM поверх него, не забудьте поставить галочку напротив shared:
Другие среды
Если вы планируете использовать это решение в другой среде возможно вам потребуется установить кластерное расширение для LVM на данный момент из существует две реализации. CLVM и lvmlockd.
Настройка CLVM не совесм тривиальна и требует работающего кластер менеджера.
Куда как второй метод lvmlockd — еще не до конца протестирован и только-только начинает появляться в стабильных репозиториях.
Рекомендую к прочтению отличную статью о блокировах в LVM
