Опубликован релиз кластерной файловой системы Lustre 2.17, используемой в большей части крупнейших Linux-кластеров, содержащих десятки тысяч узлов. Ключевыми компонентами Lustre являются серверы обработки и хранения метаданных (MDS), управляющие серверы (MGS), серверы хранения объектов (OSS), хранилище объектов (OST, поддерживается работа поверх ext4 и ZFS) и клиенты. Код проекта распространяется под лицензией GPLv2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64533
Непонятно, это лучше BTRFS, или нет?
Это другое. Она надстройка над обычными ФС.
Это что-то типа NFS, только круче.
Человек попытался объяснить незнайке простыми словами, а другой незнайка обиделся на человека.
ZFS Ван лав
Архаика...
Непонятно а как это на локалхосте поднять...
Если непонятно, значит не нужно
Наделать кучу виртуалок и над ними поднять.
и что будет, если одна, или несколько виртуалок будут загашены\выйдут из строя?
Итог будет зависеть от того, как Вы настроите репликацию в Lustre.
Может быть это нужно только если у тебя в квартире много компьютеров и ты что-то считаешь на них.
Например облачный кластер на балконе и несколько оптических проводочков идёт к ним.
Хранители рутрекера и держатели кластеров редких торрентами поддерживают.
>Непонятно а как это на локалхосте поднять...Это имеет смысл только если тебе надо слить в один накопитель несколько накопителей на разных хостах и их так много что тебе их никак не собрать на одном сервере.
Какой к хренам раст, lustre fs уже работала когда раста даже в планах не было....Какой нафиг btrfs, это кластерная система заточенная под грид вычисления, там где нужна низкая латентность...
Легко, но нафиг не надо.
По сути штука специфичная но для тех целей для которых она разрабатывалась весьма не плоха. Лет 20 назад использовал, петабайтов не было, но грузовик жестких дисков был заюзан.
Lustre еще используется на суперкомпьютерах.
Все кому нужно распределенное хранилище с действительно важными данными не используют опенсорсное без гарантии. Они используют решения на ос RAIDIX.
какая глупая реклама
Как будто неопенсорсное даёт какие-то гарантии...
Ты просто не понимаешь что такое коммерческая поддержка.
Какие гарантии даёт поддержка?
Если тебе проприетарная поддержка скажет УПС... то в отличии от СПО ты даже помыслить о том чтоб за кучу денег нанять спасательную команду не сможешь.
Архитектурно выглядит очень похоже на ceph, но в чём преимущества? Я так понял блочное хранилище внутреннее нельзя использовать отдельно от FS, в то время как в ceph cephfs это лишь надстройка
Поддерживаю этого оратора, тоже хотелось бы понять +- в чем разница и почему бы на кластерах ceph не юзать.
Короткий ответ: Ceph не для этого был придуман.Заранее извинияюсь за сильное упрощение и прошу умных людей не сильно пинать меня за упущения.
Длинный ответ требует постановку задачи, для чего придумывали кластерные файловые системы:
Вот, например, у вас есть небольшой вычислительный кластер, скажем, узлов (серверов) на 200-300. Занимаетесь вы обработкой данных физических экспериментов или какой-нибудь сейсморазведкой. Т.е. у вас не модельные данные, а вполне себе зарегистрированные цифровые результаты каких-то физических процессов. Их тоже не очень много, ну, скажем, примерно петабайт. Из которых 4/5 - это результаты предыдущих обсчётов, а 200T - это тот датасет, с которым сейчас _активно_ работает кластер. Софт, с которым вы работаете, написан не вами, а какой-то другой группой разработчиков, которые собаку съели на физике и оптимизировали некие "решатели" под разные архитектуры CPU/GPU. Софт работает с обычной файловой структурой, создаёт кучу индексов, поддерживает собственный внутренний формат БД для работы с данными, читает данные, визуализирует их, пишет логи и результаты параллельно со всех серверов в одном дереве файлов. Данные терять нельзя, производительность _имеет значение_, как по задержкам, так и по пропускной способности. Дополнительное требование: в следующем году расширить систему хранения на 30%.
И вот, вооружившись собственным мозгом и интернетом, вы начинаете изучать вопрос: а как "большие дяди" решают такие задачки. На выбор: Lustre, BeeGFS, pNFS (Panasas или NetApp), вычёркиваете Intel DAOS, т.к. она блочная, вычёркиваете Exellero, по той же причиние, смотрите в сторону VAST Data и прикидываете в уме ценник на коробочное решения.
Если вы решите выбрать Ceph, то вам никто не может запретить, но между "бакетами ceph" и файловой структурой будет стоять RadosGW, после чего вам понадобится один или несколько NFS Ganesha, который работает в пространстве пользователя, со всеми вытекающими накладными расходами и вносимыми задержками.
Давайте, грубо, посмотрим на цепочку открытия некоторого файла с данными, в качестве примера:
В случае Ceph:
- Приложение хочет открыть некий файл (/distributed/data/path/to/file) и дёргает ядро.
- Ядро смотрит, что за этот кусок отвечает NFS клиент.
- NFS клиент в составе ядра обращается к одному из серверов NFS Ganesha
- Запрос пошёл по сети.
- ядро на NFS сервере (который Ganesha), перебросило данные из пространства ядра в процесс Ganesha.
- NFS Ganesha запрос получил.
- Дёрнул RadosGW (для простоты они на одной машине)
- RadosGW дёрнул сервер метаданных Ceph.
- В этот момент опять произошло переключение контекста.
- Запрос пошёл по сети.
- Сервер метаданных ответил какие бакеты Ceph надо забрать из OST, в которых будут метаданные файлов.
- RadosGW отправляет запрос/запросы по сети на полученные OST. Опять с переключением контекста.
- запросы пошли по сети, ждём приезда данных (бакеты фиксиорованно размера, какого, кстати?)
- Ждём, когда все данные приедут и мы отдадим их Ganesha. Ещё одно переключение контекста.
- Данные приехали и Ganesha мысленно поставил себе галочку, что с данным файлом работают. Проверяет какие у него права доступа, заблокирован ли он кем-то ещё и если всё в порядке, то возвращает клиенту некий дескриптор открытого файла.
- Клиент NFS радостно рапортует, что файл открыт.Дальше мы хотим прочитать кусок данных из файла. Вся цепочка повторяется, но с удлиннением, вместо метаданных файла, мы будем получать некоторую кучку бакетов, которые потом будем через NFS передавать клиенту, запоминая по дороге, где находится текущий указатель на чтение.
Как это будет происходить в Luste/BeeGFS:
- Приложение хотет открыть файл и дёргает ядро.
- Ядро понимает, что за этот путь в виртуальной файловой системе отвечает клиент Lustre (который тоже в составе ядра) и сразу дёргает его.
- Клиент Lustre не покидая пространства ядра, делает запрос к серверу метаданных
- Запрос уходит по сети сразу из ядра.
- Получает ответ, что файл открыт, если права пользователей позволяют, т.к. сервер метаданных хранит не только карту блоков содержимого файлов, но и права доступа, владельца и все остальные атрибуты.
- Клиент Lustre сообщает ядру, что файл открыт.
- Ядро возвращает приложению: файл открыт.В случае чтения какого-то блока из файла:
- Клиент просит сместиться внутри файла на 100Gb и прочитать блок данных размером 10M.
- Ядро дёргает клиента Lustre (который всё тот же модуль ядра).
- Клиент Lustre запрашивает у сервера метаданных какие сервера OST отвечают за этот диапазон.
- Запрос уходит в сеть из ядра (нет переключения контекста).
- Сервер метаданных проверяет блокировки этого диапазона и, если противопоказаний нет, то возвращает список и номера блоков.
- Клиент Lustre (не покидая пространства ядра) параллельно запрашивает нужные блоки у серверов OST.
- Запросы уходят по сети (кстати, это может быть Infiniband с RDMA, что ещё немного сокращает задержки)
- Получив данные он либо оставляет их в кэше и делает memory map для приложения, либо копирует данные в пространство приложения (тут происходит переключение контекста), в зависимости от того, как именно приложение просило открыть себе файл и как читает данные.Ну и напоследок. Наступает новый финансовый год. Планов - громадьё. Руководство, в своей бесконечной мудрости, решает, что надо бы расширить кластер и увеличить объём хранения данных процентов эдак на 30%. Закупает железо. А все проекты идут и активно работают. Как ребалансировка Ceph повлияет на производительность? Вы готовы ждать пока она закончится?
Рассказывать про запись данных на ceph не буду, но там появятся такие милые сердцу ожидания, пока данные лягут в две из трёх реплик (мы же помним, что терять данные нельзя и храним 3 реплики).Вот кстати, отдельная задачка - посчитать стоимость хранения за минимальный "строительный блок" для расширения на 100Tb, с учётом всех OST, RadosGW, серверов NFS и тремя репликами данных.