The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0, opennews (??), 29-Мрт-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


71. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"  –2 +/
Сообщение от kvaps (ok), 30-Мрт-18, 22:43 
> Это не аналог люстры и не предназначено для больших кластеров.

Можно поподробнее, почему нет?
Насколько возможна расширяемость LeoFS и во что можно упереться при использовании ее в больших кластерах?

> до фига каких-то данных в виде множества мелких сущностей
> хранить распределенно, чтобы отказоустойчиво и быстро

Как раз это больше всего и привлекает. В статье заявлена поддержка nfs - возможно ли и насколько резонно использование LeoFS в качестве классической POSIX-совместимой файловой системы?

> у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС

Как в этом случае поступает LeoFS?

Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли?

PS: Большое спасибо за ваши ответы :)

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

72. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"  –1 +/
Сообщение от RomanCh (ok), 30-Мрт-18, 23:02 
> Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь для больших кластеров и предназначен. Не так ли?

Не так. Ceph замечательно работает например на 3х нодах ProxMox, который хранит в нём диски виртуалок тем самым организуя отказоустойчивость и прозрачную миграцию виртуалки с ноды на ноду - никакие данные носить не нужно, всё уже есть. Другое дело что Ceph может работать на кластерах с заметным объёмом показывая в целом неплохой результат.

За LeoFS ничего не скажу, потому что ничего не знаю, и в отличии от автора того камента со "сравнениями" не буду обсуждать то в чём совсем не разбираюсь.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"  +1 +/
Сообщение от Stax (ok), 31-Мрт-18, 11:20 
> Можно поподробнее, почему нет?
> Насколько возможна расширяемость LeoFS и во что можно упереться при использовании ее
> в больших кластерах?

Например, система репликации построена так, что другие серверы знают (помнят), где чего при попытке записи не записалось. Что, с одной стороны, позволяет очень быстро сделать все данные на сервере, который вновь включился в строй корректными, но с другой может дать оверхед при слишком большом даунтайме. Большой кластер - больший риск даунтайма.

Есть еще разные ограничения, которые в принципе планируется снять, но в данный момент это не так приоритетно т.к. под большие кластеры никто не затачивает. Например, невозможность одновременного восстановления двух потерявших данные узлов, только последовательно. Также тестовые конфигурации разработчиков не покрывают большие кластеры, а там могут быть свои засады. И т.п.

Вообще говоря о больших кластерах, лучше оперировать не числом узлов, а конкретными цифрами, сколько объектов хочется хранить, какой средний размер, какое распределение по размеру (совсем грубо хотя бы), какую нагрузку R и W требуется держать. И спросить разработчиков, оперируя этими цифрами. Какие у вас задачи-то?

>> до фига каких-то данных в виде множества мелких сущностей
>> хранить распределенно, чтобы отказоустойчиво и быстро
> Как раз это больше всего и привлекает. В статье заявлена поддержка nfs
> - возможно ли и насколько резонно использование LeoFS в качестве классической
> POSIX-совместимой файловой системы?

Там есть множество ограничений как серьезных, которые вряд ли будут в ближайшее время менять - нет поддержки блокировок, нет поддержки прав, не знаю как (возможно, никак?) работает rewrite части объекта и т.п. Так и менее серьезных, которые поправят, но которые могут отравить жизнь на текущем этапе - не выйдет сделать листинг каталога с тысячами (и больше) файлов, могут быть отвалы коннекта определенных проблемах, падение скорости при записи больших (сотни МБ) файлов и т.п.

Принципиально NFS поверх object storage хорошо сделать сложно. Разработчики пытаются, не готов сказать, получится ли. Хотелось бы. В некоторых режимах, например простые open/read конкрентых файлов по NFS в принципе все работать нормально; видимо, под это в первую очередь и писалось.

Можете попробовать еще s3fs-fuse. Но по хорошему, я настоятельно рекомендую S3 API. И фич до фига сразу будет, и работает все отлично.

>> у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС
> Как в этом случае поступает LeoFS?

Append-only файл формата заголовок-данные-заголовок-данные и т.п., где в заголовке неизменяемая часть, и отдельно небольшая LevelDB, хранящая смещение каждого объекта, индексы для префиксного поиска, статус объекта (актуален/удален) и т.п.

> Вы так же сравниваете LeoFS с Ceph но Ceph в первую очередь
> для больших кластеров и предназначен. Не так ли?

Про Ceph тут рядом другой товарищ может отписать лучше :)

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

76. "Выпуск распределённого отказоустойчивого хранилища LeoFS 1.4.0"  –1 +/
Сообщение от kvaps (ok), 31-Мрт-18, 11:28 
Благодарю, очень исчерпывающе!
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру