Недавно в ZFS появилась новая и очень значимая функциональность RAIDZ expansion. Задача решалась с 2020 года и vStack принимал в ней весомое участие в качестве контрибьютора и спонсора.
RAIDZ Expansion позволяет добавлять в группу RAID-Z один или несколько дисков.
Предыстория создания RAIDZ Expansion
В файловой системе ZFS в контексте zpool существует несколько механизмов резервирования с разными свойствами. Один из них — RAIDZ, по функциональности во многом схожий с RAID 5 и RAID 6, но обладающий одним существенным отличием — все диски внутри группы RAIDZ одинаковы. То есть у всех дисков в группе RAIDZ одинаковый удельный вес и отсутствуют диски с особой ролью (parity, data parity). Такой подход имеет определенные плюсы: размер группы мог быть достаточно большим, а накладные расходы на избыточность ничтожно малыми. Несмотря на то, что в группе RAIDZ, имеющих небольшое количество дисков, накладные расходы на избыточность были бы большими, с увеличением количества дисков накладные расходы на избыточность уменьшались. Например, если создана группа RAIDZ на 10 дисков, то цена избыточности составит всего лишь 10%.
Избыточность
Для понимания проблематики избыточности нужен небольшой экскурс в резервирование и его экономическую составляющую, а именно накладные расходы. Дело в том, что модели резервирования (2N, N+1, N+2, N+3) не существуют в вакууме — они решают определенные задачи, и каждое решение имеет свою цену.
Модель резервирования 2N (два диска вместо одного) — прекрасное решение с точки зрения резервирования, но затратное с точки зрения накладных расходов, ведь цена избыточности равна 100%. Во многих случаях это неприемлемо, особенно там, где во главе угла находится экономическая эффективность. Модели резервирования N+1, N+2, N+3 — экономичнее, у них накладные расходы на избыточность значительно ниже.
Например, у N+1 на группе RAIDZ из 10 дисков избыточность равна 10%, а из 20 — 5%. Это существенно меньше, чем 100% при 2N.
Стоит добавить, что на рынке много хороших технологий с высокими накладными расходами, а с низкими — мало. А если к технологиям с низкими накладными расходами добавить целостность и другую востребованную функциональность, то выбор подходящих решений сжимается до небольшого числа FAANG-технологий.
Проблематика RAIDZ Expansion
С момента выхода ZFS в промышленную эксплуатацию механизм резервирования не подразумевал модификации набора дисков группы RAIDZ. То есть если создана группа из семи дисков в формате N+2, то она всегда останется группой из семи дисков. Можно было создать еще одну отдельную группу, но существующая никуда бы не делась. Это обусловлено тем, что модификация размера группы RAIDZ требовала очень длительной операции по перераспределению существующих данных. До недавнего времени в RAIDZ такую операцию выполнить было невозможно.
В сообществе ZFS, как и в любых других опенсорс-сообществах было большое число участников, обсуждавших эту проблему и способы ее решения. При этом специалисты, предлагавшие свои варианты решения проблемы, по разным причинам не брались за их реализацию. К тому же работа требовала значительных временных и вычислительных ресурсов. Фактически задачей в вялотекущем формате занимался один человек и, как следствие, сообщество было очень далеко до ее завершения.
Важно добавить, что многие сложные задачи, создаваемые внутри современных технологий с открытым кодом невозможно сделать силами одного человека. Серьезные задачи могут быть реализованы только внутри сообщества, где значимое количество участников каждый в мере своих возможностей вносят свою лепту, причем не только на окончательных стадиях, но и даже на начальных. Большее количество глаз сообщества с более высокой вероятностью увидит изъяны, появляющиеся в ходе решения, обратит на это внимание, предложит альтернативные варианты. Это критически важное отличие от разработки в одиночку.
Мы в vStack приняли осознанное решение: подключиться к решению этой сложной задачи. У нашей команды есть практический опыт, и компетенции, необходимые для решения задач подобного масштаба, и вычислительные ресурсы, необходимые для обеспечения этой работы.
В течение трех лет мы двигали задачу вперед. Прогресс в решении сложных задач в opensource-сообществах в такой же степени неравномерный, как и в обычной разработке: возникают и не подтвердившиеся гипотезы, и тупики, и просто заблуждения. Несмотря на все возникавшие трудности, находящиеся на виду у всего сообщества, задача RAIDZ Expansion была решена и одобрена участниками сообщества.
После приема RAIDZ Expansion в основную ветку, значимость вклада vStack была отмечена попаданием в список спонсоров этой работы.
Что дальше
Мы приняли значимое участие в создании новой функциональности в первую очередь для того, чтобы эта возможность появилась в нашем продукте, что позволит потребителям удобнее, комфортнее и более гибко управлять масштабированием нашей гиперконвергентной платформы vStack. Другой не менее важный результат нашей работы — компетенции, появившиеся в ходе решения задачи. Они позволят использовать новую функциональность в нашем продукте в корректном виде, исключающем ошибки.
Полезные ссылки
Ссылка на raidz expansion feature #15022
Подробное описание RAID-Z Expansion
Эта статья поддерживается командой vStack
vStack — гиперконвергентная платформа для построения виртуальной инфраструктуры корпоративного уровня. Продукт входит в реестр российского ПО.
• Наш сайт
• Наш блог про Enterprise IT во всех его проявлениях
Комментарии (6)
13werwolf13
12.12.2023 15:33Любопытно всё же, в чём была такая сложность этой фичи
да как бы в статье вроде бы прямо говорится что дело не в сложности а в том что требует очень долгой и сильно грузящей процессор операции перераспределения:
Это обусловлено тем, что модификация размера группы RAIDZ требовала очень длительной операции по перераспределению существующих данных
ведь по большому счёту даже учитывая непростую математику используемую для работы raidz по большому счёту передвинуть блоки с диска на диск, а потом посчитать блоки чётности и положить рядышком относительно не сложно, но очень затратно по времени. в btrfs два диска на 14тер из mirror в stripe превращались емнип у меня дня 4 с балансировкой, а у некоторых в ведении хранилища объёмы которых измеряются десятками петабайт, так ещё и обслуживание лучше проводить без даунтайма..
Аппаратные RAID-контроллеры, железо которых несопоставимо слабее, чем у серверов, уверенно тянущих ZFS, умеют расширять RAID 5/6 с незапамятных времён
прикол в том что "мозг" аппаратного рейд контроллера только этим и занимается, и тяжёлая операция перераспределения блоков не грузит CPU вашего сервера тем самым напрямую не влияет на его общую производительность, когда же у вас zfs/btrfs перераспределение займёт процессор сильно, и остальным сервисам будет нехватать
а вообще ИМХО хорошо что сделали, в btrfs это возможно давно, более того можно в любой момент превратить raidc3 (аналог raidz) в raid10 и обратно не говоря уж об добавлении или уменьшении кол-ва дисков (с уменьшением кол-ва дисков в zfs кстати тоже всё не очень хорошо), а решение стоит ли грузить этой операцией процессор или нет предоставлено инженеру.
интересно пощупать что там в этом плане у bcachefs конечно..
PwrUsr
12.12.2023 15:33Я так понимаю там проблемма не столько в проц упирается, посчитать что куда, сколько в iops, я даже боюсь представить сколько и как надо перелопатить данные что бы скажем к 7 дискам добавить еще 1
зы. а только Z1 можно или 2й и3й тоже....
Dante4
12.12.2023 15:33Что самое обидное - это отсутствие изменения ширины группы для существующих данных и приличного размера overhead у старых данных, который имеет накопительный эффект :(
aborouhin
Ура, наконец-то. Любопытно всё же, в чём была такая сложность этой фичи, потребовавшая годы на реализацию. Аппаратные RAID-контроллеры, железо которых несопоставимо слабее, чем у серверов, уверенно тянущих ZFS, умеют расширять RAID 5/6 с незапамятных времён.
Ну вообще-то у RAID 5/6 тоже отсутствуют диски с особой ролью, parity блоки равномерно распределены по всем дискам. С особой ролью - это RAID 3 и 4, которые в живой природе встречаются примерно никогда.
mpa4b
Аппаратный контроллер наружу представляется всего лишь блочным устройством. OpenZFS -- это файловая система, которая программно реализует raid, а также контроль целостности и атомарные записи (ну и ещё кучу всего). А ещё там куча legacy кода от легендарного Sun, и не факт что тот код оптимальный или легко модифицируемый (я лишь предполагаю, в глаза тот код не видел и не разбирался). Обеспечивать перестройку RAID надо, не нарушая основной сервис (работу с файлами) и не нарушая существующие гарантии атомарности/крешеустойчивости/etc. Вот и сравните теперь с аппаратными raid-железками, которые к тому же ещё и на батарейку полагаются для гарантий синхронных записей и крешеустойчивости. OpenZFS все эти проблемы решает чисто программно.