> Можно поподробнее, почему нет?
> Насколько возможна расширяемость 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 тут рядом другой товарищ может отписать лучше :)
