LizardFS — краткий обзор кластерной файловой системы

Интересная кластерная файловая система. На одном не очень большом проекте мы ее внедрили и работает она лучше популярных решений GlusterFS или NFS. Использует FUSE при подключении на стороне клиента. Мы думали, что будет это работать не лучше чем другие кластерные ФС, но в реальности оказалось все очень даже позитивно.

К достоинствам LizardFS:

Очень быстрая работа в режиме чтения маленьких файлов. Многие кто использовал GlusterFS встречались с проблемой через чур медленной работы, если кластерная ФС используется под отдачу данных сайтов.

Скорость чтения больших файлов на очень хорошем уровне.

Скорость записи больших файлов мало чем отличается от нативных файловых систем, особенно если снизу SSD диски и между серверами в кластере 1-10 Gbit связь.

Операции chown / ls -la — медленнее, чем в случае нативной ФС, но не настолько медленно
как в случае GlusterFS.

Операции рекурсивного удаления — очень быстро.

Очень гибкие опции подключения в утилите mfsmount.

Дублирование мета данных настраивается легко и просто, можно одновременно иметь страховочный shadow мастер сервер и metalogger серверы.

Мета данные хранятся в оперативной памяти.

Очень здорово LizardFS может предпочитать брать данные с локального сервера. На примере 2-х реплик для ускорения чтения, LizardFS клиент будет автоматически брать файлы с локального сервера, а не тянуть по сети со 2-го сервера.

Возможность на под.папки устанавливать любые goal(количество реплик), то есть можно указать LizardFS /var/lizardfs/important делать 3 реплики, а /var/lizardfs/not_important вообще без реплик и всё в рамках одной ФС. Все зависит от количества chunk серверов и выполнения требуемых задач, можно даже использовать несколько раздельных дисков под каждый chunk сервер.

Поддерживает различные режимы репликации данных, в том числе EC — Erasure Coding.
Скорость чтения в таком режиме не на много меньше.

Все работает в LXC контейнерах, кроме монтирования клиентом самой файловой системы. Решается монтированием на хостовой машине и пробросом mount point в LXC контейнер.
Можно потренироваться.

Автоматический ребаланс при добавлении новых нод.
Довольно простое удаление выпавших или ненужных нод.

К недостаткам LizardFS:

Скорость записи большого потока маленьких файлов очень низкая. Rsync хорошо это показывает.

В случае с движками сайтов, которые генерируют большое количества кеш файлов на ФС,
кеш надо выносить за пределы кластерной файловой системы. Для движков, в которых это сделать проблемно, но можно поверх примонтированной LizardFS замонтировать в ее под.папки локальные папки, или же использовать символические ссылки.

Пример:

mount --bind /data/nativefs/cache /var/lizardfs/cache

Рабочий мастер сервер мета данных может одновременно работать только 1, но параллельно может работать дублер в режиме shadow. High Availability можно реализовать как с помощью платного компонента LizardFS, так и с помощью своих скриптов + uCarp/keepalived/PaceMaker и тому подобного ПО. В нашем случае нам это не требуется, достаточно ручного управления.

К сожалению всё автоматически, как в GlusterFS из коробки, такого тут нет. Плюсы и гибкость перевешивают минусы.

Предоставлю кратенький мануал, как быстро запустить LizardFS на Debian 9.

Предположим у нас есть 4 сервера с установленным Debian 9, 8-ой по умолчанию не содержит готовых пакетов lizardfs.

Распределим роли:

172.24.1.1 (master metadata / chunk) — master мета данных / chunk хранилище
172.24.1.2 (shadow metadata / chunk) — shadow master мета данных / chunk хранилище
172.24.1.3 (metalogger / chunk) — бэкап мета данных / chunk хранилище
172.24.1.4 (metalogger / chunk) — бэкап мета данных / chunk хранилище

Строго говоря, metalogger может работать и на master и shadow параллельно, тем более ресурсы там копеечные требуются. Это фактически отложенный бекап мета данных, точно таких же как и на master / shadow серверах. И любой metalogger, в случае, если на основных серверах побились мета данные можно превратить в master сервер.

То есть например такой вариант у меня используется тоже:

172.24.1.1 (master metadata / metalogger / chunk)
172.24.1.2 (shadow metadata / metalogger / chunk)

Продолжим далее в статье в варианте из 4 серверов.

Пункты 1-3 — выполняются на всех 4-х серверах.

1. Устанавливаем на всех серверах полный набор из всех сервисов, кроме клиента если у Вас LXC контейнеры. Ставим все сервисы, потому что они все равно отключены в Debian в автозагрузке в /etc/default/… А если вдруг придется metalogger превратить в master, то все уже будет установлено заранее.

apt-get -y install lizardfs-common lizardfs-master lizardfs-chunkserver lizardfs-metalogger lizardfs-client

cp /etc/lizardfs/mfsmaster.cfg.dist /etc/lizardfs/mfsmaster.cfg
cp /etc/lizardfs/mfsmetalogger.cfg.dist /etc/lizardfs/mfsmetalogger.cfg
cp /etc/lizardfs/mfsgoals.cfg.dist /etc/lizardfs/mfsgoals.cfg
cp /etc/lizardfs/mfschunkserver.cfg.dist /etc/lizardfs/mfschunkserver.cfg
cp /etc/lizardfs/mfshdd.cfg.dist /etc/lizardfs/mfshdd.cfg

Или, так как в Debian в родных пакетах приводится вариант выше, то если установить из исходников или собрать свои пакеты, то директория будет другой:

cp /etc/mfs/mfsmaster.cfg.dist /etc/mfs/mfsmaster.cfg
cp /etc/mfs/mfsmetalogger.cfg.dist /etc/mfs/mfsmetalogger.cfg
cp /etc/mfs/mfsgoals.cfg.dist /etc/mfs/mfsgoals.cfg
cp /etc/mfs/mfschunkserver.cfg.dist /etc/mfs/mfschunkserver.cfg
cp /etc/mfs/mfshdd.cfg.dist /etc/mfs/mfshdd.cfg

2. Добавляем в /etc/hosts дефолтную запись для LizardFS.

echo "172.24.1.1 mfsmaster" >> /etc/hosts

3. Выбираем для хранения данных папку или отдельный раздел даже или хоть 2 раздела и больше. Рассмотрим просто 1 папку в текущей ФС на каждом сервере: /data/lizardfs-chunk

mkdir -p /var/www (сюда будем монтировать наш кластер)
mkdir -p  /data/lizardfs-chunk (сюда LizardFS будет складировать данные в своем формате)

echo "/data/lizardfs-chunk" > /etc/lizardfs/mfshdd.cfg

Или

echo "/data/lizardfs-chunk" > /etc/mfs/mfshdd.cfg

4. Указываем, кто будет master, а кто shadow

На 172.24.1.1 укажем PERSONALITY=master в конфиге mfsmaster.cfg
На 172.24.1.2 укажем PERSONALITY=shadow в конфиге mfsmaster.cfg

5. Включаем нужные сервисы:

172.24.1.1:

echo "LIZARDFSMASTER_ENABLE=true" > /etc/default/lizardfs-master
echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver

systemctl start lizardfs-master
systemctl start lizardfs-chunkserver

172.24.1.2:

echo "LIZARDFSMASTER_ENABLE=true" > /etc/default/lizardfs-master
echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver

systemctl start lizardfs-master
systemctl start lizardfs-chunkserver

172.24.1.3:

echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver
echo "LIZARDFSMETALOGGER_ENABLE=true" >  /etc/default/lizardfs-metalogger

systemctl start lizardfs-metalogger
systemctl start lizardfs-chunkserver

172.24.1.4:

echo "LIZARDFSCHUNKSERVER_ENABLE=true" > /etc/default/lizardfs-chunkserver
echo "LIZARDFSMETALOGGER_ENABLE=true" >  /etc/default/lizardfs-metalogger

systemctl start lizardfs-metalogger
systemctl start lizardfs-chunkserver

Далее монтируем клиентом, есть разные варианты, опций очень много:

mfsmount -o big_writes,nosuid,nodev,noatime,allow_other /var/www

mfsmount -o big_writes,nosuid,nodev,noatime,allow_other -o cacheexpirationtime=500 -o readaheadmaxwindowsize=4096 /var/www

Поддерживаемые опции зависят от версии LizardFS, во втором варианте скорость чтения заметно выше. mfsmount по умолчанию берет IP мастера из /etc/hosts, но подключается ко всем chunk серверам параллельно.

Доступные варианты реплик прописываются в mfsgoals.cfg

Затем указываем, сколько реплик данных нам надо:

mfssetgoal -r 2 /var/www
mfsgetgoal /var/www

Ну, а потом начинаем пользоваться в /var/www

В общем-то мне хватило и 1-го полного дня, чтобы достаточно разобраться с этой кластерной ФС. Да оно немного сложнее GlusterFS, но плюсы перевешивают. Быстрое чтение кучи маленьких файлов — это прекрасно.

→ Документация ^[1]

Автор: sysadmlinux

Источник ^[2]