Опубликован выпуск 1.5.0 программной системы хранения данных Vitastor с поддержкой кластерной файловой системы (VitastorFS). Vitastor - распределённая блочная программная система хранения данных, то есть, хранилище образов виртуальных машин или дисков контейнеров, развиваемая автором с 2019 года. Начиная с выпуска 1.5.0, это также и кластерная файловая система. VitastorFS монтируется по протоколу NFS 3.0 с локально или удалённо запускаемого сервера/серверов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60835
Не могу понять как файловая система может называться кластерной если "File locking is not supported". Расходимся.
С локами был бы дольше доступ
Жиденькое оправдание. У NFS сетевой лок отключается опцией монтирования.
Что интересно, это что как раз автор и сказал, что существующие проекты не подошли ему тем, что не по настоящему FS у них были
Если вчитаться, то там много файлов тоже нельзя хранить пока. Оно сделано в основном чтобы подключить VMWare с большими image файлами
Ну вот с этой версии как раз можно не только к VMware подключать, но и просто к хостам как CephFS
но... э.. у вмвари собственная sds. И - что характерно - не экспериментальная и работает.
> но... э.. у вмвари собственная sds. И - что характерно - не
> экспериментальная и работает.и стоит мешок бабла
Те кто купили вмварь с extended support - даже и не заметят этот "мешок" (к тому же на фоне железа опять же - ни о чем)А покупка непонятного нечта от непонятных васянов всегда оборачивается в десятки раз дороже.
"Basically, you can't use the software in a proprietary environment to provide its functionality to users without opensourcing all intermediary components standing between the user and Vitastor or purchasing a commercial license from the author 😀."
Зачот. Все бы так делали.
Basically, you can't use the software in a proprietary environment.Вот тут надо было и остановиться. Суть не изменилась, и меньше писанины.
То есть вариант purchasing a commercial license from the author товарищЪ Н.И. Щук принципиально не рассматривает?
Ну да, куда ж ему.
Конечно нет - кому нужна коммерческая лицензия на неведомое г-но, используемое непонятными дол..е..ми?Ну ждите, ждите, к вам бегом в очередь побегут с мешками денег. (нет)
> Конечно нет - кому нужна коммерческая лицензия на неведомое г-но, используемое непонятными дол..е..ми?История продаж компании Microsoft говорит, что много кому.
> История продажИменно что история. Как у этого продукта с историей? Есть чем похвастаться? Может быть, какие-то клиенты большие есть? Большие деплои? Нет? Ну тогда за свои деньги я лучше у Майкрософта куплю.
> Как у этого продукта с историей? Есть чем похвастаться? Может быть, какие-то клиенты большие есть? Большие деплои?У мелкософта всё это есть, но стали ли от этого его продукты менее г?
То-то и оно.
>> История продаж
> Именно что история.А если это не для продаж, а для личного развития.
Ты действительно думаешь, что кому-то кроме тебя интересен твой локалхост? Тут у каждого дюжина своих имеется. Но локалхост на то и локал, что на нём любая дичь сносно работает. Ребятки себя, вижу, позиционируют как нефигово энтерпрайзный опенсорс (с типичным МГИМО ФИНИШЕД в лицензии). Ну вот пусть и рассказывают, чем они лучше того же Майкрософта.
Достаточно много внедрений.
Просто СХД — самая консервативная область в ИТ инфраструктуре, там не меняют архитектуру хранилища только потому, что у менеджера левая пятка зачесалась.
Поэтому никому в голову не приходит бодро рапортовать.
Гениально. Вот бы Линус Торвальдс так запретил использовать ядро Linux в свое время...
возможно тогда я бы сейчас не писал с нота под линухой, а жрал бы какую-нибудь вендузятину
Не, ну ноут-то с 6ешплатное-взять-взять ты бы мог использовать (насчет стабильности работы правда... ну вон некоторые пользуются даже openbsd, как-то оно работает)А я вот точно админил бы винду и винду. Ну может реееедко какой солярис или даже может быть выжила бы SCO. Но там желающих было бы в сто раз больше чем вакансий (как оно и было в 90е) да и тем бы приходилось периодически ковыряться в IIS.
> Вот бы Линус Торвальдс так запретил использовать ядро Linux в свое время...Он ярый противник GPL3 и предпочитает GPL2
Не надо перевирать. Линукс не ярый противник GPL3. Ему говорили: "Переведи ядро на GPL3". Он отвечал типа, "Отстань, замолкни, остановись. Да, есть проблема тивоизации, но всё же нет ничего лучше GPL2". Его слова свидетельствуют. что он не ярый противник, просто он хочет чтобы его не доставали с вопросами о лицензии.
Самая главная проблема там, это то, что ядро под GPLv2 без плюса. А это значит, что обязаны получить согласие ото всех, чьи патчи когда-либо были приняты в ядро. Что, по понятным причинам, нереально.
>Самая главная проблема там, это то, что ядро под GPLv2 без плюса.И без передачи прав дяде.
И это единственное почему толстячки ваш линукс никак не могут выкупить, но вон анонишка от этого имеет анальную боль.А CPL c плюсом ... уже забыли как мозолееда выпнули на роль вахтера с его же фонда? :)
А потом ВНЕЗАПНА!(C) GPL4 окажется буква в букву равна MS EULA ... что скажете фантастика? А вы посмотрите чего делалось за последние лет 20 - и не такое оказалось вполне себе возможным. За 100% прибыли нет такого преступления (С)
Просто он понимает, что не надо пилить сук на котором сидишь.
Он просто занет что с ними делать (С) Порудчик
есть примеры продуктива?
Облако МТС =)
Там была варя :-). А вот если бы был витастор!..
таки пример продуктива то есть?
есть, как раз у автора оператора например :)
Указанный в статье оператор с прошлого лета не подаёт признаков жизни.
ответить на скрытый коммент не могу. в общем, оператор используется в проде, возможно код на гитхабе не обновлён, но он используется. по поводу оператора залетайте в тг чатик @vitastor и тыкайте @antillles-а, он и обновит
автора оператора
ничо не понял
автор k8s-оператора (Antilles который)
> Идея VNPL - расширение действия копилефта не только на модули, явным образом связываемые с кодом, а также на взаимодействующие с Vitastor по сети сервисы, специально созданные для негоВ переводе на общепонятный: если ты - маленький стартап, вся ценность которого в оригинальном коде, то ты должен бесплатно отдать его корпам.
Есть и вторая опция :-)
нету.Очередь желающих занести вам мешок денег за вторую опцию уже выстроилась? Вот и не ждите.
Мелкий стартап выберет ceph просто потому что там не надо никому заносить мешками. К тому же это давно и хорошо известная технология и на рынке не то чтобы легко, но можно найти специалистов, хорошо понимающих что там можно а что нельзя.
А у вас полный пролет по всем направлениям - неведомая нёх, специалистов нет, разработчик - неведомые васяны, качество его поддержки будет довольно предсказуемо, и нет ни малейшей гарантии что через неделю не присядут за госизмену всем подвалом из трех человек или не сбегут в парагвай с твоими деньгами.
А вторым ceph вы не станете вот именно из-за лицензии, как бы ни было все хорошо и замечательно технически. Сами себе отстрелили яйца, чтоб не дай б-г не размножиться.
Поражаюсь идиoтизму.
Ну выберут и выберут, можно подумать с GPL встали бы в очередь)Завоевать популярность в любом случае дело небыстрое, зато не придется потом, как Redis, лицензию менять, провоцируя негатив и форки
В очередь нет, на покрутить-поиграться - взяли бы, наверное (черная метка "русские делали" никуда не пропадет). Потом бы все равно поставили ceph, но так, глядишь, потихоньку сдвинулось бы с нулевой точки.> зато не придется потом, как Redis, лицензию менять, провоцируя негатив и форки
нет ножек, нет варенья. Теперь точно не придется. Паре госзаказчиков может и удастся впихнуть в рамках "импортозамещения", но они и так бы купили - из-за поддержки и необходимости страховать свои риски.
редис поменял лицензию потому что полез не в свое поле деятельности - сам решил поторговать услугой а не поддержкой (которая нахрен никому в их случае была не нужна, а для кластерной фс это маловероятно следующие лет десять минимум) и проиграл (потому что и как услуга нахрен никому не нужны отдельно от амазона) Ну может теперь на перепродаже фантиков заработает, у монги же получилось.
А тут - сплошные минусы. Денег именно из-за лицензии этот проект получит ровно ноль.
Те кто заплатят - не будут помогать писать код, они уже купили, программировывай!Зачем было вообще его публиковать таким образом - загадка природы.
И да, опыт поляков видимо никого ничему не научил.
разработчик - неведомые васяныне васяны, а виталики :-)
ценности этот пучок скриптов для корпов не представляет никакой. Но он ценность для хакеров, желающих тебя поломать, и для конкурентов, потому что из этих скриптов легко извлекается понимание, какие юз-паттерны успешны, как устроена твоя внутренняя инфра и много чего еще.Короче, пользователей на этих условиях будет вот ровно ноль.
Написано на C++, уважуха.
Если нет поддержки блокировок - это всё.
Для реального кластера - OCFS2, других вариантов не особо.
В пределах одной стойки ещё GFS2 можно пробовать.
> Если нет поддержки блокировок - это всё.это еще не все, напоминаю - https://lizardfs.com/wp-content/uploads/Cases/Tinkoff_case_s... - как думаешь, им нужны блокировки? И ниче, купили. (но не ту поделку) Правда, им и на latency наплевать.
Поделка сразу после покупки, кстати, склеила ласты. Видимо парни неплохо отоварились деньгами тогда еще не внесенного в SDN банчка, и разбежались кто куда.
И да, заметь - они - gpl. (но не совсем) Много форков видишь?
> Если нет поддержки блокировок - это всё.Вернее: если не предусмотрено место, в которое можно добавить код нужной функциональности. (Сырцы не читал, не знаю.)
извините, пройдите на-йникто за авторов не будет ничего добавлять. Потому что есть-то за себя они собираются - сами.
Тут всё гораздо хуже: если нет блокировок, значит необходимая для них синхронизация отсутствует. Естественно при этом latency никакая, но и синхронизироваться нечем, и кеш не когерентный, и вообще смысла нет, потому что в т.н. "кластерной" FS в файл можно при этом можно писать только с одной ноды, причём очень аккуратно - чтобы никто ещё в этот момент не читал и не писал. По сути в такой конфигурации с каждым отдельным файлом можно либо "только на чтение" со всех нод, либо только "всё с одной", и такой кластер - мертворождённый труп.Чтобы её нагородить - надо очень сильно об угол стукнуться, в общем случае придётся делать свой DLM или интегрироваться в существующий кластерный стек. Первое - очень непросто, второе ставит крест на latency и простоте использования, ещё и STONITH понадобится.
Там смотрю оно через NFS вывернуто. То есть в качестве обеспечения когерентности выбран сброс кеша при открытии и проверку атрибутов? Если так - то даже блокировки уже не помогут.
Хм, ну да, единственный трабл это page cache конечно. Ну типа если писать-читать из NFS с O_DIRECT, то когерентность будет. А там случайно нет в линуксовом NFS опции чтобы принудительно всем direct включить?.. :-)
И даже с O_DIRECT может не быть когерентности, потому что кто-то решил почитать после записи с другой ноды, но запись ещё не долетела и другие ноды о записи не проинформированы. Будет stale read. Всё это придётся синхронизировать, в т.ч. информировать ноды о записи.
- Нода A прочитала блок, он попал в кеш
- Нода Б отправила блок на запись, он попал в буфер и ждёт пока его реально пропишут в сторейдж
- Нода A снова читает блок - УПС
Не, если пишут и читают с O_DIRECT, то всё железобетонно синхронно будет, по крайней мере если кэш дисков отключён (immediate_commit=all). Т.к. любая завершённая запись уже точно будет на всех OSD, и любое последующее чтение пойдёт на эти же OSD и оттуда данные прочитает"попала в буфер" - что за буфер, у меня нет никакого такого буфера. А на дисках предполагается по дефолту отрубать кэш и юзать ssd с конденсаторами
С O_DIRECT блок в теории должен уйти сразу в сторейдж, но тут будут нюансы с задержками для пересылки на OSD, если в этот момент кто-то решит почитать - он с OSD получит всё такой же старый лежалый блок.Т.е. синхронизировать ноды надо в момент появления записи.
> он с OSD получит всё такой же старый лежалый блок.Не получит. У меня синхронная репликация абсолютно всегда.
До неё ещё даже дело не дойдёт.
Ну и да, я вот тут расписал немножко - оно может из собственного кеша получить.
Тогда надо O_DIRECT брать и тем, кто читает - да, решение, но блин O_DIRECT на чтение? Системный кеш мимо?
Если так сделать - то при рандомных мелких чтениях будет полный трындец.
> Если так сделать - то при рандомных мелких чтениях будет полный трындец.Да нормально всё будет, у меня же везде оптимизация под задержку, на чистой блочке даже в один поток задержка чтения на нормальном кластере ~0.1 мс. Т.е. сравнимо со скоростью локального ссд. Ну с NFS добавится ещё один раундтрип до NFS сервера (т.е. клиент -> vitastor-nfs -> OSD). Но если vitastor-nfs запущен локально, то этот раундтрип будет через локальный loopback, т.е. добавит какие-нибудь 20 микросекунд. Ну будет в конце концов 0.15 мс скажем, нормально.
Собственно а как ещё-то делать, если у тебя сетевая ФС и тебе нужна когерентность? Если ты юзаешь кэш клиента, понятно что из него могут данные отдаться. Если нужна когерентность только и остаётся на сервер ходить.
Теоретически если бы был собственный модуль ядра с реализацией ФС, можно было бы наверное сделать оптимальнее, либо какие-то уведомления от сервера, либо как у меня в vitastor-kv перепроверки номера версии, но это же пипец, модуль ядра свой пилить)
NFS-серверов сколько может быть? Их тоже придётся синхронизировать.
Если один, единый SPOF - это очень плохо.> Собственно а как ещё-то делать, если у тебя сетевая ФС и тебе нужна когерентность?
В OCFS2 сделано очень хитро и более-менее правильно, можно посмотреть.
Можно сколько угодно делать, они стейтлесс, их синхронизировать не надоМожно вообще NFS сервер запускать локально, как FUSE, там даже есть команда vitastor-nfs mount - сразу запускает и монтирует сервер на локалхосте на случайном порту
Случайно запускает и случайно монтирует, понятное дело.
Проблема в том, что в случае множественного монтирования без блокировок не выжить.Даже если вы и найдёте юзкейс, при котором можно, и далеко их не один - всё равно это уже не ФС общего назначения, и подойдёт только под такие вот неслучайные юзкейсы.
Да чо ты троллишь :-) там специально сделано так что всё стейтлесс. Я даже БД специальную накурил на основе оптимистичного Б-дерева, допускающую параллельный доступ с разных нод. :-) на основе CAS-"транзакций".Без блокировок вполне можно выжить, выше же обсудили про O_DIRECT, а вообще и проще, простой close-to-open сработает всегда, даже с пейдж кэшем
Ну и да, какой ещё O_DIRECT в NFS?Синхронизация "в лоб" выглядит следующим образом (есть более хитрые способы):
- Все ноды обмениваются информацие об открытиях файлов
- Видим запись на одной из нод, видим, что файл открыт ещё где-то
- Информируем все остальные ноды, открывшие файл (если первый пункт пропустить - вообще все ноды, а это тормоза), о том, что блок X файла Y взят на запись нодой N
- В этот момент - кто не спрятался, я не виноват, ноды могут ещё прочесть старое, разрешено, стрижка только начата - вот тут как раз и нужны блокировки
- Все проинформированные ноды при прочих попытках чтения этого блока встают колом и ждут продолжения банкета
- Новые ноды, открывающие файлы, принимаются, но информируются об in-flight записи блока
- Производим запись
- Уведомляем писавшего об успехе
- Информируем все участвовавшие в трындеце ноды и новые появившиеся о том, что запись блока завершена
- Проинформированные ноды сбрасывают кеш блока, те, что пытались его читать - выдыхают, и начинают читатьКак быть с блокировками, и чем они страшны
- Если взята эксклюзивная блокировка файла на запись, к счастью, никто читать блок не попытается, но механизм выше всё равно должен быть, так как блокировки банально нестрогие, и у нас могут быть ноды, которые всё равно попытаются читать. Но наличие таких можно отследить по запросам на блокировку - те, что встали колом на попытке взять прочую блокировку - можно проинформировать только о конце записи, чтобы кеш сбросили, можно даже оптом по всем блокам после снятия эксклюзива - тут как раз целое поле непаханое для оптимизации
O_DIRECT с NFS пашет, я проверял. Причём что забавно - даже с невыровненными блоками :-).А с блокировками - насколько я понял из man 5 nfs, там сам NFS-клиент кэш сбросит за тебя, если ты блокировки юзаешь. Но там же и написано про O_DIRECT:
If absolute cache coherence among clients is required, applications should use file locking. Alternatively, applications can also open their files with the O_DIRECT flag to disable data caching entirely.
> If absolute cache coherence among clients is required, applications should use file locking.Именно так оно в идеальном случае и работает, ну, вот потому, о чём я писал.
Возможность отхватить stale read без блокировок есть - в NFS не стали заморачиваться.
Поэтому на кластерах, увы и ах :), только OCFS2/GFS2.
Да запилю я эти блокировки, фиг ли там делать :) - etcd же есть под рукойПросто мне не казалось что это первый приоритет честно говоря
В кластерной FS блокировки не приоритет?
Офигенный кластер, синхронизироваться-то как?
С навесу?
Вот когда все блокировки добавятся - вот тогда можно и latency померить.
Особенно на те самые блокировки.
Что ты собрался синхронизировать локами? Назови практическое применение. Что это за приложение? Мне из практики только dovecot maildir в голову приходит.Типичному HPC софту, например, нужна ReadWriteMany ФС, но синхронизация там в 99% случаев своя, через какую-то стороннюю БД. Что там реально нужно от ФС - это чтобы изменения, внесённые в файл одной нодой, СРАЗУ после этого были видны другой ноде. Т.е. strong consistency при монтировании на нескольких нодах. Это у меня есть. *единственно прочитал коммент выше про когерентность кэша в NFS - да, наверное, на файлах, открытых без O_DIRECT, она будет только через перепроверку mtime/сtime, т.е. на уровне порядка 1 секундной задержки при изменении.
Когерентность без локов оптимизировать очень сложно.
Это надо либо всем слать всё чтение и запись в обход кеша, либо придётся вообще все ноды информировать при каждой записи, даже те, что вообще файл читать не собираются. Либо держать и синхронизировать список открывших, но и там возможны нюансы. Вот хочет нода читать и ждёт shared, а писатель взял exclusive. Сразу понятно, кому и что вещать насчёт сброса кеша.
dovecot - это одно из самых страшных применений блокировок кстати, малейший продолб при параллелизме, и всё, его сторейдж будет так или иначе порушен, что maildir, что mdbox
То же самое с когерентностью, оно очень любит писать в индексы.
Вообще в любом нормальном кластере приоритет - именно сихронизация.
Но раз не первый, так не первый, лучше не трогать.
> VNPL - "сетевой копилефт", собственная свободная копилефт-лицензия Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с дополнительным условием "Сетевого взаимодействия", требующим распространять все программы, специально разработанные для использования вместе с Vitastor и взаимодействующие с ним по сети, под лицензией VNPL или под любой другой свободной лицензией.При всём уважении к автору, это "не айс" - точно не поспособствует развитию экосистемы.
Открою ужасную правду, - когда не хочется сдавать(ся) хранилище в облако, используют Minio. Тут такое API есть ?
> Открою ужасную правду, - когда не хочется сдавать(ся) хранилище в облако, используют Minio. Тут такое API есть ?Вы только Minio из S3-совместимых хранилок знаете? :-) так-то это самая слабая реализация из всех доступных
Ну расскажи тогда про самую сильную.
Я бы сказал, в тезх компаниях где я работал/работаю - используется S3-совместимое Minio, когда нужно похранить файлы.Другие решения, не смотря на то, что они существуют в природе - не используются.
На самом деле я не делал S3 в начале тоже ровно потому, что нормальные S3-хранилки есть и без меня. Ceph, SeaweedFS как минимум, а кому-то и Minio действительно достаточно.А вот хороших БЛОЧНЫХ хранилок не было. У всех латенси на уровне 1-2 мс т.е. при записи с глубиной очереди 1 (например при записи WAL СУБД) это всего 500-1000 операций в секунду.
Поэтому в первую очередь на блочке и сосредоточился.
В качестве второго приоритета взял ФС, т.к. кластерных ФС нормальных тоже считай нет. Самое лучшее что было это пожалуй CephFS, но и у неё много проблем, начиная с очень большого оверхеда и отсутствия горизонтального масштабирования MDS. Ну и в HPC популярна люстра, но с ней задолбаешься и отказоустойчивость там специфическая я так понимаю.
Это офигенная идея, которая тоже всё. Равно как и отсутствие блокировок.
Поделка ради поделки.
Виталий, успехов в этом непростом деле
> Виталий, успехов в этом непростом делеСпасибо :-)
А что все так сагрились на отсутствие блокировок? ФС явно предназначена для замены iSCSI в тех конфигурациях, когда среда виртуализации не имеет коннектора к хранилке для создания/удаления/снапшота lun-ов и view. Упростит ли она жизнь в таком варианте? Безусловно. Насколько реально оправдано существование подобного комбайна? Ну а вдруг оно кому-то надо ;)
То, что автор явно поторопился назвать свежий релиз полноценной кластерной ФС - ну так может ему контракт какой подписать надо. Добрее надо быть к людям )
Не, там 2 фс, одна псевдо, реально замена айсказей, вторая нормальная, в которую можно файлопомойку пихать