Компания Versity объявила (http://www.versity.com/blog/versity-open-sources-scoutfs) об открытии исходных текстов специализированной файловой системы ScoutFS (https://www.scoutfs.org/), оптимизированной для хранения архивных данных. Утверждается, что ScoutFS стала первой открытой файловой системой для архивирования, нацеленной на предоставление промышленного уровня надёжности и масштабирования при хранении огромных массивов накопленной архивной информации. Код опубликован под свободной (https://github.com/versity/scoutfs-kmod-dev) лицензией GPLv2, что позволяет со временем включить его в основной состав ядра Linux. В настоящее время ScoutFS распространяется в виде внешнего модуля для ядра Linux из состава RHEL/CentOS 7.x.ScoutFS относится к категории кластерных систем, организующих доступ группы серверов к совместному хранилищу данных. В ScoutFS встроены сервисы для хранения метаданных, механизм индексации и средства для контроля целостности хранимой информации. Важная особенность ScoutFS в отсутствии отдельного централизованного сервера обработки метаданных, так как вся функциональность реализуется на конечных узлах и метаданные обрабатываются на всех узлах или отдельной группе узлов в кластере.
ScoutFS существенно расширяет возможности традиционных ФС по числу хранимых файлов в одном пространстве имён, позволяя хранить в одной ФС до триллиона файлов. ФС также рассчитана на высокую интенсивность поступления данных и может обрабатывать большое число одновременных запросов на создание файлов. Работа с ScoutFS напоминает традиционные ФС - семантика соответствует требованиям POSIX, а хранилище разворачивается поверх общего для всех узлов блочного устройства, на котором создаётся ФС и монтируется на всех узлах кластера.
Ключевые особенности ScoutFS:
- Интегрированный движок индексации данных, ускоряющий операции обслуживания архива. Индексация позволяет сразу отслеживать все изменения данных и атрибутов файлов. Для обращения к индексу предоставляется специальный интерфейс для формирования запросов AQI (Accelerated Query Interface);- Применение совместно используемого на разных узлах индекса. Индекс построен на базе LSM-дерева (https://ru.wikipedia.org/wiki/LSM-%D0%B4%D0&#... (Log-structured merge-tree), обеспечивающего высокую производительность в условиях интенсивного добавления новых данных;
- Благодаря индексации время поиска файлов практически не зависит от числа файлов в ФС. Сравнение ScoutFS и XFS:
- Сокращение конкурирующих операций, благодаря отделению логических блокировок от операций сериализированной записи на устройство;
- Поддержка различных ресурсов для конечного хранения данных, включая ленточные накопители, диски, хранилища объектов и облачные системы;
- Обеспечение отказоустойчивости: узлы могут на лету отключаться и подключаться без нарушения работы ФС и потери сохраняемых данных;- Полное соответствие единой семантике POSIX на разных узлах;
- Контроль целостности метаданных и ссылок на данные;
- Автоматические транзакции для поддержания согласованности постоянных структур;
- Реализация в виде оптимизированного модуля ядра, обеспечивающего минимальные задержки и высокую производительность.URL: http://www.versity.com/blog/versity-open-sources-scoutfs
Новость: https://www.opennet.ru/opennews/art.shtml?num=49290
хм... а уже появились какие-то вменяемые методы сделать верифицируемый бекап со всех распространённых ФС и с БД внутри, который можно в случае смерти быстро поднять прям как снапшот?
Снапшот ФС с любой ФС?LVM.
> и с БД внутри
Никак.
Flush tables with read lock; внутри ВМ. Потом LVM снапшот.
Ну ему же хочется просто снапшот, без смыва, я так понял.
Почему никак? Зависит от рук и БД.
Написано что можно тут:
https://www.postgresql.org/docs/9.0/static/backup-file.htmlТипичная процедура заключается в создании «замороженного моментального снимка» тома, содержащего базу данных, затем скопируйте весь каталог данных (а не только части, см. Выше) из моментального снимка на устройство резервного копирования, а затем отпустите замороженный снимок. Это будет работать даже во время работы сервера базы данных. Однако созданная таким образом резервная копия сохраняет файлы базы данных в состоянии, как если бы сервер базы данных не был должным образом отключен; поэтому при запуске сервера базы данных на резервных данных он будет считать, что предыдущий экземпляр сервера разбился и будет воспроизводить журнал WAL. Это не проблема; просто имейте в виду (и обязательно включайте файлы WAL в свою резервную копию).
теперь в качестве движка хранения для этой штуки нужно прикрутить другую распределенную фси будет "мы сделали вам распределенную фс, хранящую данные на распределенной фс, чтобы вы могли пользоваться распределенной фс, пока пользуетесь распределенной фс"
> Утверждается, что ScoutFS стала первой открытой файловой системой для архивирования, нацеленной на предоставление промышленного уровня надёжности и масштабирования при хранении огромного числа файлов.Сетевые FS не в счет?.. а то вот есть под боком одна файловая система - 15P.. и что-то там в районе 150G файлов..
> Компания Versity объявила об открытии исходных текстов специализированной файловой системы ScoutFS, оптимизированной для хранения архивных данных.Не умеет OFED - совсем. LOCKING сделал per inode, паралельные чтения еще возможны - запись - нет.
Судя по всему - операции синхронны, - быстрый пробег не показал какого-то кода похожего на recovery after fail.
Промышленной говорите?
> *XXX Need to figure out how to resolve multiple items created by
> concurrent writers.
> ScoutFS относится к категории кластерных систем, организующих доступ группы серверов к совместному хранилищу данных.
> Важная особенность ScoutFS в отсутствии отдельного централизованного сервера обработки метаданных, так как вся функциональность реализуется на конечных узлах и метаданные обрабатываются на всех узлах или отдельной группе узлов в кластере. Непосредственно данные хранятся на внешнем общем хранилище, а не распределены по узлам. На узлах лишь поддерживается общий синхронизированный индекс метаданных.Что не так с ocfs2 и gfs2?
> ScoutFS существенно расширяет возможности традиционных ФС по числу хранимых файлов в одном пространстве имён, позволяя хранить в одной ФС до триллиона файлов.
А, вот что. Ну допустим... А сколько будет стоить хранилище под такую задачу? Думаю, потому и выбросили проект на мороз, что для хранения "триллиона файлов" теперь дешевле и эффективнее использовать распределённые ФС, вроде ceph или lustre.
> Что не так с ocfs2 и gfs2?OCFS2 научилось маштабироваться выше 256 узлов ? правда уже при этом были дикие тормоза из-за локинга на каждый блок.
В OCFS2 угрёбищно сделано квотирование, пишет один длиннющий псевдофайл, верификация которого занимает херову тучу времени + квотирование лочится на каждый чих. Без квотирования нормально, но не на 256 узлов конечно, оно для этого уже не предназначено.
А для чего? я грешным думал что что бы раздавать большие объемы.PS. в OCFS2 - лимит на 256 нод - прошит в протокол.
/* this limits us to 256 nodes
#define OCFS2_NODE_MAP_MAX_NODES 256и насколько я знаю - далеко не просто так. Даже без проблем с квотой.
Чтобы раздавать большие объёмы - лучше что-то с шардингом посмотреть. OCFS2 - более-менее shared FS общего назначения. Применимо для HA, для compute cluster, и для раздачи тоже, но не silver bullet.
а что в compute cluster еще делают? раздают большие объемы. Если посмотреть на физику/биологию/метеорологию - там объемы 1 файла даже не мегабайты - а гигабайт и выше.Опять же - при ограничении в протоколе - 256 нод - это будет - очень маленький кластер.
Шардинг отменили?
В compute cluster - считают, объёмы при этом могут быть разными.
С GFS2 не так кластерный стек, увы, только для сферического кластера в вакууме, где всё остальное (сеть, железо) надёжнее самого кластера.С OCFS2 для именно кластерных применений (а не горизонтального масштабирования в небеса на сотни узлов) - всё в порядке, да )
Хотя, для compute cluster без HA GFS2 тоже заруливает, да.
https://en.wikipedia.org/wiki/OpenAFS
Тёплое vs мягкое> ScoutFS относится к категории кластерных систем, организующих доступ группы серверов к совместному хранилищу данных.
> Реализация в виде оптимизированного модуля ядра, обеспечивающего минимальные задержки и высокую производительность.А OFED не знает.. или хотя бы AF_RDS
Это конкурент ceph?
нет, это перпендикулярный проект - ceph когда надо быстро и данные под рукой, но ограниченное количество и с разумным количеством узлов.а тут идея что оно будет расти пока не заполнит весь глобус, и при этом, по крайней мере в теории, до файлов все еще можно будет добраться - может не мгновенно, но и не навечно увязнуть в индексах и локах. Но, как обычно, толком не доделанное, и непонятно, доделает ли кто-то хоть когда-то.
> оно будет расти пока не заполнит весь глобусКуда, нафиг, оно будет расти?
> Непосредственно данные хранятся на внешнем общем хранилище, а не распределены по узлам.
Это про FC/iSCSI
Пейсмакер с коросинком не дадут заполнить глобус уже при 3-5 мс latency.
уп-с...да ну, нафиг, 5ms, не может быть? Может все же 50?
Увы, может. 5 нод с latency около ms благополучно флапали коросинк, а в случаях развала кольца - убивали кластер. Пришлось тюнить, потом, когда наполучался удовольствия - выкинуть.
Current StatusInitial Alpha Open Source Release
scoutfs is under heavy active development. We're releasing before it's completely polished to give the community an opportunity to affect the design and implementation. Nothing is cast in stone.
сетевая фс в ядре = бекдорведь в любой достаточно сложной программе есть уязвимости
сетевой <placeholder> в ядре = бекдорне показатель.
Сеть - вообще бэкдор. Выдерните кабели, выломайте антенны и прочие приёмники/передатчики.
"Семантика соответствует требованиям POSIX" - обычно звездёжь. Как у неё с POSIX locking?
Ну вот код, разбирайтесь: https://github.com/versity/scoutfs-kmod-dev/blob/7d1ea197c29...А вообще, конечно, семантика posix locks крайне неудачная для сетевых ФС.
DLM, то есть пейсмакер с коросинком. Всё веселье в одном флаконе.
// встроенный DLM с выносным кластерным стеком, которых на деле 1 штука.В той же OCFS2 оракл сделала собственный кластерный стек с кворумом на сторейдже, чтобы уйти от угрёбища под названием pcs+corosync с необходимостью жёсткого и быстрого STONITH, вотчдогов, от кривых кворумных демонов и иже с ними. Надо сказать, по сравнению с GFS2 на pcs+corosync, работает замечательно.
вы путаете. это поделие использует тот же DLM что и OCFS2.
Это вы путаете. DLM да, кластерный стек - нет. У OCFS2 есть свой кластерный стек, O2CB, у которого кворум на сторейдже, который mesh, который не требует железного STONITH, и который менее чувствителен к пертурбациям.Да, оно может работать с угрёбищной парой pcs+corosync, но только в идеальных для таковой условиях - желательно вообще в одной стойке (кольцевая топология corosync очень чувствительна к задержкам, увы), с железным отрубанием нод и т.п. Как и всё остальное.
DLM и кластерный стек это вещи разные - от слова совсем.
так же как и STONITH - никак не связан с DLM.задача DLM (как ее понимает wikipedia и большинство FS - https://en.wikipedia.org/wiki/Distributed_lock_manager) - обеспечить не противоречивость кэшей на клиенте. Вопрос STONITH это вопрос HA стека - который обеспечивает работу отдельных нод кластера, и к кэшу клиентов отношения не имеет.
Теперь понятно ?
Хосспаде, ну запусти мне "родной" DLM в Linux без кластерного стека или его подобия.
Легко. Для монтирования руками различных нод кластера - ума много не надо.
При этом DLM будет работать и обеспечивать непротиворечивость кэшей клиентов.К слову - стоит разобраться "что такое родной DLM" для Linux.
В ядре существует миниум 2 - а местами было 3 и больше реализаций.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
у smb / nfs - есть тоже свой DLM, базирующийся на LEASE locking.какой из этих "родной" DLM для linux и какой надо поднимать ?
еще один.. не путайте требования POSIX и POSIX LOCKs.
первое включает очень большой перечень требований - в частности когенетность кешей клиентов.
Второе.. второе не включает в себя ничего.Код этого поделия мягко скажем странный - самопальный interval tree (есть в ядре готовый), на какой-то черт точность лока 1 байт, хотя ядро не выделит меньше страницы и тп.
формально есть DLM, есть какие-то события. быть святее папы римского и оптимизироваться по паралельный доступ - не собираются. По сему примерно так же как в pohmelFS. один глобально-фиртуальный i_mutex на файл и в перед.
>Непосредственно данные хранятся на внешнем общем хранилище, а не распределены по узлам.Ну тогда ничего для себя интересного не вижу.
Зачем ядру иметь в себе структуры, существенно зависящие от внешних обстоятельств? Чем userspace здесь не угодил?
Модули в помощь. Не надо - не грузишь. А кому-то эти "внешние обстоятельства" приемлемы.
Причем тут модули?Речь о том, что для ядра взаимодействие с внешними системами (через подсистемы ядра же)
происходит за неизвестно-какое-время с неизвестно-каким-результатом. И, собственно, почему эта логика (обеспечение гарантий целостности, непротиворечивости, ...) должна быть в ядре, а не в userspace?
Потому что делать десяток контекст свитчей на каждую блочную операцию могут только фанаты фс на питоне.
Т е по вашей логике разница между ядром и юзерспейсом в том что в ядре должен быть сложный код, а в юзерспейсе простой?
Простой должен быть в обоих, но вам как сложному не понять.