2022-11-12 - Методы объединения дисков разного объема в один массив

В лабораторный сервер я вставил все диски которые попались под руку и в связи с этим назрел вопрос: “Какие файловые системы или системы хранения данных умеют работать с дисками разного объема в едином пуле и какая из них самая оптимальная”.

По мотивам недавней статьи про BTRFS я начал тестирование с этой системы, так как среди немногих она поддерживает защиту данных на уровне блоков а не дисков, что позволяет объединять диски различного объема и количества в требуемые уровни RAID. Среди Enterprise систем хранения данных такие методы управления дисковой емкостью можно встретить например на HP EVA, HPE 3par, Primera, Huawei OC, Dorado и других. Ничего фантастического в данной технологии нет. Диск разделяется на блоки (чанки) определенной длинны и RAID собирается из чанков а не из дисков целиком. Это привносит следующие преимущества:

• Восстановление много-ко-многим;
• Отвязанный уровень RAID от количества дисков, например мы можем создать RAID1 на трех дисках и использовать весь объем или RAID 4+2 на 7,8,9 и так далее дисках;
• Распределенная область горячей замены;

BTRFS обладает собственными недостатками и не полной реализацией некоторых преимуществ, об этом я упомянул в статье о дистрибутиве Rockstor.

Файловая система BTRFS была грубо протестирована с использованием скрипта на базе fio, который прогоняет все блоки на все типы нагрузки и позволяет в nmon построить красивые графики.

Результат выложен на странице с остальными файлами.

Следующей тестируемой файловой системой будет ZFS. Я не буду пытаться строить raidz потому что для такой конфигурации из разнородных дисков это непозволительная роскошь:

• Это сложно посчитать;
• У BRFS RAID5 пока не стабилен и сравнить результаты не удастся;
• Производительность скорее всего будет катастрофически низкой;

Чтобы объединить свои диски я прибегнул к такому методу, который периодически эксплуатирую: Разделить все диски на равные куски, равные объему самого маленького диска и собрать из этих кусков RAID.

Сводная таблица по имеющимся дискам ниже:

Цветом выделены разделы дисков которые будут объединены в один vdisk.

Предварительно я разделил диски на разделы с использованием gdisk. Вот пример вывода команды для самого большого накопителя на 1ТБ:

Disk /dev/sda: 1951170560 sectors, 930.4 GiB
Model: SMC2108
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6A752F75-CFFE-495A-9474-8CA6E2BA4B17
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1951170526
Partitions will be aligned on 2048-sector boundaries
Total free space is 4032 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       487792127   232.6 GiB   8300  Linux filesystem
   2       487792640       975584766   232.6 GiB   8300  Linux filesystem
   3       975585280      1463377406   232.6 GiB   8300  Linux filesystem
   4      1463377920      1951170046   232.6 GiB   8300  Linux filesystem

Команда создания пула выглядит следующим образом:

zpool create tank 
			mirror /dev/sda1 /dev/sdc1 \
			mirror /dev/sda2 /dev/sdd1 \
			mirror /dev/sda3 /dev/sde1 \
			mirror /dev/sda4 /dev/sdh1 \
			mirror /dev/sdc2 /dev/sdd2 \
			mirror /dev/sde2 /dev/sdh2 \
			mirror /dev/sdg1 /dev/sdb1		

Результат на снимке экрана ниже:

При разворачивании шаблона заметно что запись идет на все диски. Возможно даже чересчур на все.

Результат достаточно сложно интерпретировать из-за нестабильности показаний. Я полностью отрезал последовательное чтение, так как это не показательное значение для данного теста. Грубо говоря производительность сравнимая, но в случае с ZFS достигаются более стабильные показатели. Например в btrfs полностью отсутствует какая-либо вменяемая скорость на всех нагрузках, связанных с записью. Графики ZFS больше походят на то, что я обычно вижу в этом тесте а с btrfs что-то явно не так.