Как стать автором
Обновить

Гиперконвергентная система АЭРОДИСК vAIR v2. Часть 2. Файловая система ARDFS и её функциональность

Блог компании АЭРОДИСКСистемное администрированиеIT-инфраструктураВиртуализацияХранение данных
Всего голосов 4: ↑3 и ↓1 +2
Просмотры1.7K
Комментарии 2

Комментарии 2

Давайте спрошу, что все хотят узнать, но боятся спросить… насколько ваши технологии созданы вами, а не взяты за основу как форк Ceph и т.п. Есть мнение, причем людей, которые в теме и произносят слово Аэродиск, что это все допилы, запилы под определенное железо существующих продуктов OSS. Поделитесь развернуто пожалуйста)

Здравствуйте, Иван. Очень правильный комментарий, и, в целом, я рад, что подняли эту тему. Попробую максимально развернуто вам ответить.


Пару лет назад был подобный вопрос к нашему посту на Хабре, но только не про гиперконвергент, а про СХД (Engine), по прошествии двух лет в общем-то мало что изменилось.


Разделю ответ на две части. Про технику и про закон.


Техника. Итак, в целом, о нашем подходе. Безусловно, мы, как и практически все отечественные и иностранные разработчики продуктов в области ИТ-инфраструктуры применяем open source в своих решениях, этого мы никогда не отрицали и не собираемся. Гиперконвергентная система vAIR и используемая в ней файловая система ARDFS не является исключением. Перед стартом разработки продукта несколько лет назад мы изучили то, что есть на рынке проприетарных и открытых решений, позволяющих создавать распределенные системы хранения для размещения и выполнения виртуальных машин. В рамках данного исследования мы изучили Lustre, Ceph, Gluster, SheepDog + различную обвязку к ним. Также мы разобрали несколько проприетарных решений популярных производителей, названия которых мы, по понятным причинам, не будем оглашать.


В результате нашего исследования open source-решений, а также изучения конкурентных проприетарных систем, мы сделали прототип из связки: Sheepdog+xfs+Zookeeper+Cassandra. Сама по себе эта связка как продуктивная система абсолютно бесполезна и малофункциональна, но для начала работы над своим решением она была более чем подходящая. С этой базой мы решили начать.
В скором времени от Cassandra и Zookeper пришлось отказаться по ряду причин, и их мы заменили на решения, написанные собственноручно, исходя из наших потребностей. Также по ходу пьесы пришлось разобрать sheepdog, выбросить оттуда часть его нестабильного функционала и заменить своим кодом. Так прошло 2 года работы.


В итоге в данный момент, если смотреть на продукт в целом в строках кода, то соотношение нашего кода и заимствованного примерно 70/30 в нашу пользу. Является ли это нашим решением, которому мы дали название ARDFS, или же «это все допилы, запилы под определенное железо существующих продуктов OSS», решать уже не нам. Наше дело сделать свой, с одной стороны надёжный и удобный для заказчика, а с другой стороны – легкотиражируемый и поддерживаемый для нас продукт, который можно монетизировать законными способами в России и в перспективе в других странах.


Закон. А теперь расскажу «о втором дне кроличьей норы», правовую основу всего этого. С точки зрения соблюдений правил open source-сообщества все более-менее понятно, мы в силу своих возможностей выкладываем свои доработки в апстрим (не только по указанным выше продуктам, но и смежным) и в будущем планируем сделать community версию vAIR (хотели в этом году, но пока не хватает на это ресурсов, будем целиться в следующий год).


А вот с российским законодательством все не так просто. Скажу лаконично, open source-а в российском правовом поле по сути не существует. Что это значит для разработчиков коммерческих продуктов, в которых используется опенсорс? А то, что, если разработчик по-честному на уровне формальных документов распишет весь используемый опенсорс внутри своих продуктов и направит заявку в реестр отечественного ПО Минцифры, он не него не попадет по формальному признаку (права по всему миру не полностью принадлежат ему). В последней версии проекта по обновлению требований к реестру Минцифры были попытки внести поправку о необходимости доказывать «существенную доработку» опенсорса, и тогда доработанный опенсорс может быть признан российским продуктом, но эту поправку отклонили.


Причина банальна. Кто будет проверять «существенную доработку?». В Минцифре есть департамент или управление, которое состоит из опытных инженеров и разработчиков, которые осилят такую проверку? Нет. Сколько времени будет занимать такая проверка, учитывая количество заявок? Непонятно, но точно не быстро.


Соответственно, получается временный тупик, с которым разработчики (в первую очередь отечественных дистрибутивов Линукса) уже не первый год борются. С одной стороны, опенсорса нет в реестре, с другой – все прекрасно понимают, что есть. При этом все стороны хотят это узаконить, но нет соответствующего бюрократического аппарата (проверяющие инженеры при министерстве), а создавать его не очень понято как (чиновников-технарей у нас ещё не научились выращивать) и не понятно, за чей счет.


В общем 30 лет восхода солнца на Западе даром не прошли. Теперь разгребаем.


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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.