FreeBSD virtual environment management and repository

Пример использования CBSD с использованием DFS (Distributed File System)

Общая информация

Одной из отличительных особенностей CBSD от остальных современных оберток по управлению jail и bhyve на платформе FreeBSD является отсутствие жесткой привязки к файловой системе ZFS, что влечет определенный оверхед с точки зрения кода когда вы используете только ZFS, но делает CBSD более универсальным инструментом, который вы можете использовать в более широких ситуациях.

Одна из таких ситуаций - использование различных embedded платформ с очень небольшим количеством ресурсов где файловая система ZFS является избыточной и прожорливой, что делает ее малоэффективной на различных Raspberry PI и аналогичных решений. С противоположной стороны минимализма находятся большие и масштабные гиперконвергентные инсталляции с применением NAS/SAN и распределенных систем хранения данных,с использованием внешних хранилищ, подключаемых как общее хранилище по протоколу NFS или такие распределенные системы хранения данных как ClusterFS и Ceph.

Здесь будут освещены вопросы использования CBSD в подобных инсталляциях и описаны Howto-style записи по применению.

Общее требование при использовании CBSD на DFS, характерное для любых реализаций, это выключение zfsfeat и hammerfeat опции в 'cbsd initenv-tui' и необходимость выносить на общее хранилище следующих каталогов:

  • ~cbsd/jails-data: каталог с данными контейнера или виртуальной машины
  • ~cbsd/jails-system: системный каталог с дополнительной системной информацией, относящейся к контейнеру или виртуальной машине
  • ~cbsd/jails-rcconf: каталог используется, когда окружение переходит в режим unregister

Если рабочий каталог (workdir) проинициализирован в /usr/jails это, соответственно, каталоги:

/usr/jails/jails-data
/usr/jails/jails-system
/usr/jails/jails-rcconf

Это все. Остальные каталоги, такие как bases вы также можете поместить на общее хранилище чтобы сэкономить место. Однако, гораздо более эффективно базовые файлы контейнера хранить локально, что с параметром baserw=0 по отношению к контейнерам гарантирует работу базовых утилит и библиотек со скоростью локального диска и отсутствием возможных сетевых проблем.

Общие хранилища дают легкий способ миграции окружений с нулевым копированием. Так, вы можете перевести контейнера в состояние unregister на одной ноде:

node1:

% cbsd junregister jname='*'

И зарегистрировав, без какого-либо копирования начать использовать на другой:

node2:

% cbsd jregister jname='*'

Known issues.

На некоторых DFS, таких как NFS и GlusterFS, требуется дополнительная настройка в pkg.conf для корректной работы локинга:

 % echo "NFS_WITH_PROPER_LOCKING = true;" >> /usr/local/etc/pkg.conf

CBSD и NFS

Использование CBSD с NFS ( вариант, когда в качестве NFS выступает не выделенный NAS, а одна из трех CBSD нод )

Через различные механизмы отказоустойчивости, такие как carp(4), pacemaker/corosync, keepalive, sentinel/consul, вы можете создать полностью автоматический фейловер, когда при выходе NFS-сервера, в качестве хранилища выбирается любая другая нода, а остальные переконфигурируются на нее. Однако подобные настройки выходят за рамки данной статьи, призванной дать поверхносные данные о DFS.

Итак, на первом из трех сервере, выбранным нами в качестве NFS-сервера, настроем файл >/etc/exports, перечисляя IP или подсети NFS-слиентов. Мы предполагаем, что сервера полностью под нашим контролем и находятся под полным доверием, поскольку будем давать экспортировать все каталоги.

Например, наши три CBSD ноды имеют адреса: 192.168.10.201 192.168.10.202 192.168.10.203 и рабочий каталог workdir везде проинициализирован в /usr/jails.

Добавим в /etc/exports соответствующую NFSv4 строчку:

V4: / 192.168.10.201 192.168.10.202 192.168.10.203

Если ваши сервера проинсталлированы на ZFS файловой системе, не забудьте включить sharenfs опцию на необходимых или на корневом датасете на NFS-сервере. Например, если корневая система ZFS это zroot/ROOT/default, то экспорт NFS включается через следующую команду:

% zfs set sharenfs=on zroot/ROOT/default

В /etc/rc.conf добавим необходимые для запуска NFS-сервера службы, выполнив команды:

sysrc -q nfs_client_enable="YES"
sysrc -q nfs_server_enable="YES"
sysrc -q nfsv4_server_enable="YES"
sysrc -q nfscbd_enable="YES"
sysrc -q nfsuserd_enable="YES"
sysrc -q rpcbind_enable="YES"
sysrc -q mountd_enable="YES"
sysrc -q nfsuserd_enable="YES"
sysrc -q rpc_lockd_enable="YES"

Если вы планируете делать фейловер и таким образом, NFS-сервером может стать любой элемент кластера, поэтому продублируем эти параметры на все остальные CBSD ноды, тем более, что часть из них необходима для NFS клиента. После перезагрузки серверов или служб, NFS готова к работе.

Конфигурирование клиентов. В нашем случае, NFS-сервер имеет IP адрес 192.168.10.201, соотв. замените этот адрес на тот, который соответствует вашему серверу. Подмонтировать в ручном режиме каталоги можно через команды:

% mount_nfs -o vers=4 192.168.10.201:/usr/jails/jails-data /usr/jails/jails-data
% mount_nfs -o vers=4 192.168.10.201:/usr/jails/jails-system /usr/jails/jails-system
% mount_nfs -o vers=4 192.168.10.201:/usr/jails/jails-rcconf /usr/jails/jails-rcconf

Вы можете использовать файл /etc/fstab с опцией 'late' для монтирования каталогов при старте ноды, либо использовать automount ( autofs(5) )

Теперь вы можете создавать ваши контейнера на любой из нод и через миграцию или последовательность команд:

node1 % cbsd junregister jname='jail*'     // на ноде, где зарегистрированы jail
node2 % cbsd jregister jname='jail*'       // на другой ноде

И мигрировать ваши окружения, распределяя и маcштабируя нагрузку на ваш кластер более ровно.

CBSD и GlusterFS


WIP. Короткий HowTo доступен здесь: CBSD и GlusterFS


CBSD и CEPH


WIP/