Многоуровневое хранилище с BTRFS - как это делается?
NETGEAR использует BTRFS в своей ОС ReadyNAS и реализует многоуровневое хранилище в своих последних версиях. Они начали с уровня «Метаданные» только в ReadyNAS v6.9, а затем добавили «Уровень данных» в v6.10. Система использует твердотельные накопители в качестве уровня 0 для ускорения доступа к более медленным жестким дискам в системе. В описании системы указано, что метаданные будут находиться на твердотельных накопителях в обоих случаях, и что в случае «Уровня данных» вновь записанные данные сначала будут отправляться на твердотельные накопители, а затем будут периодически переноситься на жесткий диск, или когда Уровень SSD заполняется до указанного уровня.
ReadyNAS использует BTRFS поверх жестких дисков с RAID в своих обычных установках - например, в моей системе есть RAID5, состоящий из 4 дисков, которые BTRFS видит / использует как одно устройство.
Глядя на то, как реализовано многоуровневое хранение, похоже, что настройки как «Метаданные», так и «Уровень данных» выполняются путем добавления второго RAID-массива, состоящего только из твердотельных накопителей, к основному RAID-массиву жестких дисков и преобразования исходного одиночного устройства. BTRFS в систему с несколькими устройствами.
Я не могу понять, как выполняется миграция, а также как в случае «Метаданные» удается отделить метаданные от данных, чтобы на SSD попадали только метаданные? Кроме того, как режим «Уровень данных» полностью направляет записи на уровень SSD?
Любые идеи?
Ответы
Хорошо, вот что я обнаружил во время периодической балансировки:
На хосте запускается следующий процесс:
btrfs balance start -dsweep lt:/dev/md127:7 /data LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DBUS_SESSION_BUS_ADDRESS=unix:path=/var/netatalk/spotlight.ipc TRACKER_USE_CONFIG_FILES=1 TRACKER_USE_LOG_FILES=1 XDG_DATA_HOME=/apps/.xdg/local/share XDG_CONFIG_HOME=/apps/.xdg/config XDG_CACHE_HOME=/apps/.xdg/cache
где / data - мой многоуровневый объем данных, / dev / md127 - массив SSD, используемый в качестве буфера / кеша.
Этот процесс продолжается до тех пор, пока данные с уровня SSD не будут почти полностью перемещены на уровень HDD - например, где-то по пути я вижу:
btrfs fi sh /data
Label: '0a44c6bc:data' uuid: ed150b8f-c986-46d0-ada8-45ee219acbac
Total devices 2 FS bytes used 393.14GiB
devid 1 size 7.12TiB used 359.00GiB path /dev/md126
devid 2 size 114.68GiB used 42.06GiB path /dev/md127
а затем он снижается до тех пор, пока использование уровня SSD не упадет почти до нуля. Странно то, что до сих пор мне не удавалось запустить эту команду вручную.
Я до сих пор не могу понять фильтр баланса "развертки".
Вот что показывает -help:
# btrfs balance start --help
usage: btrfs balance start [options] <path>
Balance chunks across the devices
Balance and/or convert (change allocation profile of) chunks that
passed all filters in a comma-separated list of filters for a
particular chunk type. If filter list is not given balance all
chunks of that type. In case none of the -d, -m or -s options is
given balance all chunks in a filesystem. This is potentially
long operation and the user is warned before this start, with
a delay to stop it.
-d[filters] act on data chunks
-m[filters] act on metadata chunks
-s[filters] act on system chunks (only under -f)
-v be verbose
-f force reducing of metadata integrity
--full-balance do not print warning and do not delay start
--background|--bg
run the balance as a background process
но это не объясняет, как он отображается на " lt:/dev/md127:7
" часть команды, которая выполняется периодически:
btrfs balance start -dsweep lt:/dev/md127:7 /data
Что здесь означает: запускать, пока использование данных / dev / md127 не упадет ниже 7%?!?
Это должно быть задание cron, которое выполняется регулярно и выполняет миграцию.
Проверьте /etc/cron.d на наличие записей, которые могли бы это делать.
Вы говорите, что Netgear нашел способ сделать то, что уже позволяет вам делать многоуровневое кэширование MergerFS, в удобной и чрезвычайно простой конфигурации: https://github.com/trapexit/mergerfs#tiered-caching
создайте 2 пула MergerFS A) один со всеми жесткими дисками, включая SSD («POOL», tier0), и установите для записи на устройство с наименьшим свободным пространством (если у него не осталось X свободного места). Б) второй пул («ПУЛ-АРХИВ», уровень 1), содержащий только жесткие диски.
Ваши пользователи и все приложения используют путь только к первому пулу.
Ночной сценарий, который копирует все, что не было затронуто в течение последних X дней, из первого пула во второй (легко, поскольку диски одинаковые, это приведет к копированию данных только на SSD). Это единственный элемент, который использует путь второго пула.
Именно так я настроил свой домашний сервер. Все диски отформатированы в BtrFS. Я не (не могу с этим решением) использовать Raid.
Плюсы:
- Когда диск выходит из строя, вы теряете только данные на нем (и я смягчаю это, используя SnapRAID в качестве первой системы резервного копирования). Вы не потеряете весь пул, как с BtrFS-RAID0.
- Это очень легко настроить. 2 монтирования в вашем / etc / fstab. БАМ, многоуровневое кеширование!
- Вы всегда сначала используете SSD (если только на нем не осталось только X свободного места). Дает вам максимальную скорость.
Минусы:
- Вы не можете использовать вложенные тома BtrFS (охватывающие диски) в своем пуле MergerFS, поскольку MergerFS работает поверх файловых систем в пользовательском пространстве.
- Это также означает, что вы не можете делать снимки подобъемов в своем пуле. Я бы хотел иметь машину времени, например, снимки для папок с пользовательскими данными в моем пуле.
Мне очень нравится MergerFS за его простоту, но con # 2 очень заинтересовал меня тем, как Netgear взломал подобное решение с помощью BTRFS.