Многоуровневое хранилище с BTRFS - как это делается?

Dec 08 2020

NETGEAR использует BTRFS в своей ОС ReadyNAS и реализует многоуровневое хранилище в своих последних версиях. Они начали с уровня «Метаданные» только в ReadyNAS v6.9, а затем добавили «Уровень данных» в v6.10. Система использует твердотельные накопители в качестве уровня 0 для ускорения доступа к более медленным жестким дискам в системе. В описании системы указано, что метаданные будут находиться на твердотельных накопителях в обоих случаях, и что в случае «Уровня данных» вновь записанные данные сначала будут отправляться на твердотельные накопители, а затем будут периодически переноситься на жесткий диск, или когда Уровень SSD заполняется до указанного уровня.

ReadyNAS использует BTRFS поверх жестких дисков с RAID в своих обычных установках - например, в моей системе есть RAID5, состоящий из 4 дисков, которые BTRFS видит / использует как одно устройство.

Глядя на то, как реализовано многоуровневое хранение, похоже, что настройки как «Метаданные», так и «Уровень данных» выполняются путем добавления второго RAID-массива, состоящего только из твердотельных накопителей, к основному RAID-массиву жестких дисков и преобразования исходного одиночного устройства. BTRFS в систему с несколькими устройствами.

Я не могу понять, как выполняется миграция, а также как в случае «Метаданные» удается отделить метаданные от данных, чтобы на SSD попадали только метаданные? Кроме того, как режим «Уровень данных» полностью направляет записи на уровень SSD?

Любые идеи?

Ответы

2 StefanPiperov Dec 13 2020 at 09:30

Хорошо, вот что я обнаружил во время периодической балансировки:

На хосте запускается следующий процесс:

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%?!?

1 Blitzer Dec 09 2020 at 08:13

Это должно быть задание cron, которое выполняется регулярно и выполняет миграцию.

Проверьте /etc/cron.d на наличие записей, которые могли бы это делать.

1 zilexa Dec 31 2020 at 08:19

Вы говорите, что Netgear нашел способ сделать то, что уже позволяет вам делать многоуровневое кэширование MergerFS, в удобной и чрезвычайно простой конфигурации: https://github.com/trapexit/mergerfs#tiered-caching

  1. создайте 2 пула MergerFS A) один со всеми жесткими дисками, включая SSD («POOL», tier0), и установите для записи на устройство с наименьшим свободным пространством (если у него не осталось X свободного места). Б) второй пул («ПУЛ-АРХИВ», уровень 1), содержащий только жесткие диски.

  2. Ваши пользователи и все приложения используют путь только к первому пулу.

  3. Ночной сценарий, который копирует все, что не было затронуто в течение последних X дней, из первого пула во второй (легко, поскольку диски одинаковые, это приведет к копированию данных только на SSD). Это единственный элемент, который использует путь второго пула.

Именно так я настроил свой домашний сервер. Все диски отформатированы в BtrFS. Я не (не могу с этим решением) использовать Raid.

Плюсы:

  1. Когда диск выходит из строя, вы теряете только данные на нем (и я смягчаю это, используя SnapRAID в качестве первой системы резервного копирования). Вы не потеряете весь пул, как с BtrFS-RAID0.
  2. Это очень легко настроить. 2 монтирования в вашем / etc / fstab. БАМ, многоуровневое кеширование!
  3. Вы всегда сначала используете SSD (если только на нем не осталось только X свободного места). Дает вам максимальную скорость.

Минусы:

  1. Вы не можете использовать вложенные тома BtrFS (охватывающие диски) в своем пуле MergerFS, поскольку MergerFS работает поверх файловых систем в пользовательском пространстве.
  2. Это также означает, что вы не можете делать снимки подобъемов в своем пуле. Я бы хотел иметь машину времени, например, снимки для папок с пользовательскими данными в моем пуле.

Мне очень нравится MergerFS за его простоту, но con # 2 очень заинтересовал меня тем, как Netgear взломал подобное решение с помощью BTRFS.