vStack стал спонсором и контрибьютором новой значимой функциональности ZFS: RAIDZ Expansion

Недавно в ZFS появилась новая и очень значимая функциональность RAIDZ expansion. Задача решалась с 2020 года и vStack принимал в ней весомое участие в качестве контрибьютора и спонсора.

RAIDZ Expansion позволяет добавлять в группу RAID-Z один или несколько дисков.

В файловой системе 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-технологий.

С момента выхода ZFS в промышленную эксплуатацию механизм резервирования не подразумевал модификации набора дисков группы RAIDZ. То есть если создана группа из семи дисков в формате N+2, то она всегда останется группой из семи дисков. Можно было создать еще одну отдельную группу, но существующая никуда бы не делась. Это обусловлено тем, что модификация размера группы RAIDZ требовала очень длительной операции по перераспределению существующих данных. До недавнего времени в RAIDZ такую операцию выполнить было невозможно.

В сообществе ZFS, как и в любых других опенсорс-сообществах было большое число участников, обсуждавших эту проблему и способы ее решения. При этом специалисты, предлагавшие свои варианты решения проблемы, по разным причинам не брались за их реализацию. К тому же работа требовала значительных временных и вычислительных ресурсов. Фактически задачей в вялотекущем формате занимался один человек и, как следствие, сообщество было очень далеко до ее завершения.

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

Мы в vStack приняли осознанное решение: подключиться к решению этой сложной задачи. У нашей команды есть практический опыт, и компетенции, необходимые для решения задач подобного масштаба, и вычислительные ресурсы, необходимые для обеспечения этой работы.

В течение трех лет мы двигали задачу вперед. Прогресс в решении сложных задач в opensource-сообществах в такой же степени неравномерный, как и в обычной разработке: возникают и не подтвердившиеся гипотезы, и тупики, и просто заблуждения. Несмотря на все возникавшие трудности, находящиеся на виду у всего сообщества, задача RAIDZ Expansion была решена и одобрена участниками сообщества.

После приема RAIDZ Expansion в основную ветку, значимость вклада vStack была отмечена попаданием в список спонсоров этой работы.

Мы приняли значимое участие в создании новой функциональности в первую очередь для того, чтобы эта возможность появилась в нашем продукте, что позволит потребителям удобнее, комфортнее и более гибко управлять масштабированием нашей гиперконвергентной платформы vStack. Другой не менее важный результат нашей работы — компетенции, появившиеся в ходе решения задачи. Они позволят использовать новую функциональность в нашем продукте в корректном виде, исключающем ошибки.