Как испоганилось айти, если это -- лучший  доклад. Это бред сумасшедшего, а не доклад. "Все дерьмо, я мы дартаньяны, несмотря на то, что много лет доим заказчика и за его счёт играемся с тем, о чём понятия не имеем". Тьфу. Басни про хетцнер это про танцора, у которого сплошные проблемы в жизни.

Вместо очевидных действий занимались какой-то фигней (нанимали переводчика, серьезно?? пусть английский разработчиков не идеален, но они на нем ведут и разработку, и рассылку и всегда готовы ответить) и ждали, пока все навернется. Ну-ну.

PS эксплуатирую LeoFS в продакшене и *крайне* доволен простотой, надежностью и производительностью. Хотя по результатам тестирования и внедрения пришлось написать несколько багрепортов, чтобы лучше автоматически разруливались некоторые нестандартные ситуации. Все критичное разработчики поправили достаточно оперативно. С ними очень легко общаться, хоть большинство и японцы.

Это пост рекламы своей неинтересной статьи или ненужной компании?

Спасибо.

Хмммм... Как-то это странно. Такое может быть в какой-нибудь пре-альфа версии, но чтобы японцы выкатили такое в продакшон - не могу в это поверить.  

Это не аналог люстры и не предназначено для больших кластеров. Это объектный сторейдж. Есть у вас до фига каких-то данных в виде множества мелких сущностей и ваши приложения с этим работают. Вы хотите их хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле - вот это то, что нужно. А если ваш софт уже умеет S3 (многое из коробки умеет; если это что-то свое, то дописать совсем несложно, благо реализации S3 есть почти для всего и они достаточно удобные в использовании), то обойдетесь минимум изменений.

Альтернативный вариант: вы уже используете S3 в амазоне, храните до фига, вам стало дорого. Хотите локально хранить и обрабатывать, и чтобы вышло дешевле.

Из плюсов: оно достаточно просто (но логично) устроено и из-за этого надежно. Данные хранятся в append-only файлах, которые не побьются логически при проблемах с питанием, старые данные не перезапишутся от проблем файловой системы и т.п. Формат там элементарный, любой программист за несколько часов напишет утилиту, которая делает дамп этого файла, получая исходные объекты. Т.е. данные вы не потеряете, в худшем случае хоть руками по нужному смещению возьмете объект (хотя если он будет большой, то только 5 МБ кусок, и придется сделать это несколько раз, а потом сделать им всем cat). Это я к тому, что принцип "простота = надежность" тут актуален в полной мере.

Метаданные хранятся рядышком в LevelDB базе, что позволяет использовать огромные винчестеры, пихать туда кучу мелких объектов и сохранять высокую скорость. В особо запущенных ситуациях можно хранить метаданные на SSD, тогда будет совсем шоколадно.

Аналоги тут - Ceph, Swift, Riak CS, Minio. Совсем на пальцах могу сравнить. +/- тут по сравнению с LeoFS.

+ Ceph - за ним стоит редхат. У Ceph есть другие режимы работы, помимо объектного сторейджа, например RDB. У Ceph больше коммьюнити, есть заявленная коммерческая поддержка.
- Ceph - устроен значительно сложнее, чем LeoFS. Если у вас будут проблемы с данными.. вам сильно не повезло. Восстанавливать вручную сложно, долго, дорого. Можно за деньги, дорого. Также есть сильное подозрение (частично подтвержденное небольшим опытом эксплуатации), что все режимы Ceph, кроме того же объектного сторейджа это не очень надежно. Проблема не в них как таковых, а в том, что когда вы сделаете виртуальный RDB, а потом попытатесь сделать вид, что это-таки настоящий block device, то те, кто работают с этим потом в случае минорных проблем сети (моргнуло питание, перегрузились свитчи, зависла железка и т.п.) несколько не ожидают особенностей поведения виртуального block device, что приводит к серьезным последствиям.
- Ceph - нет multi-DC репликации. Режим совместимости с S3 - это не приоритетный, по уровню поддержки уступает LeoFS.

+ Swift - если у вас OpenStack, то берите и не сомневайтесь. Неплохой уровень поддержки S3 и совместимости с разным софтом, практически на уровне LeoFS.
- Swift - если у вас НЕ OpenStack, то Swift для вас это будет пачка лишних сервисов и сущностей. Также у Swift серьезные проблемы с мелкими объектами: он хранит все в виде отдельных файлов на ФС, в результате если у вас будет до фига (например, 100 миллионов) объектов на узел, у вас с производительностью будет жопа. Потому что ФС будет хранить кучу мелких файлов, размазывая информацию (каталоги и inode) по всему диску, во-первых сильно тормозя, во-вторых большой объем тонко размазанных метаданных не получается кэшировать, т.к. кэширование этого дает огромный оверхед. В LeoFS отдельно лежащие метаданные во-первых работают очень быстро и на ЖД, во-вторых легко кэшируются в памяти, ну и в случае чего можно на SSD.
- / + Swift - там совершенно иной принцип репликации, но это тема для отдельных разговоров. Совсем на пальцах: Swift нуждается в постоянной рассылке данных для репликации. После даунтайма узла на него "пропущенные" объекты сами не придут, пока не пройдет очередная волна репликации, рассылающая все данные всем, кому требуется. LeoFS не нуждается в постоянных фоновых репликациях и не потребляет сетевого трафика на повторные репликации тех же данных, за исключением ситуации, когда потерялись данные на узле (умер узел или вылетел диск), тогда шлют данные только на этот узел. При временном же выключении узла остальные узлы ведут список объектов, которые должны были попасть на него, и практически сразу же после возвращения узла в строй перешлют на него эти объекты. Т.е. не нужно ждать репликации всей системы, чтобы вернуть узел в 100% консистентное состояние. Разумеется, есть и минусы, при очень больших даунтаймах сохранение списка дает некоторую нагрузку.

+ RiakCS - хороший уровень функциональности, была коммерческая поддержка. В некотором роде устроен проще LeoFS т.к. фактически просто хранит объекты поверх RiakKV, базы ключ:значение. Т.е. фактически крупные объекты разбиваются на куски, распределяются по серверам и там записываются в большую пачку LevelDB баз.
- RiakCS - разделение на свободную и коммерческую версию, и вообще компания Basho разорилась :(. Также значительно медленнее, чем LeoFS при использовании жестких дисков, т.к. хранить в LevelDB и данные, и метаданные не очень хорошо по производительности по сравнению с подходом LeoFS, когда там только метаданные, а данные в append-only файле.
- RiakCS - поддержка multi-DC была только в коммерческой версии, не в свободной(а они разорились). В LeoFS multi-DC бесплатно.

Minio - вот тут не могу сказать, но это очень новый продукт, что (лично для меня) сразу огромный минус. По фичам и планам там все весьма интересно. Если созреет, будет очень хорошей альтернативой.

Подробно описал выше. Пробовал Ceph. В итоге (без боли!) выбрал LeoFS.

Если совсем упрощенно: у вас достаточно много денег, вам нужен коммерческий контракт - берите Ceph.
У вас не так много денег, вы хотите что-то, что устроено максимально просто, но при этом достаточно быстро, и даже если вы (вдруг) вообще все на хрен там разломаете, чтобы ваши данные были легко доступны - берите LeoFS. За счет простоты он надежнее, вполне приятно ставится и обслуживается (особенно последние версии).

Также, если вам позарзез нужна расширенная функциональность Ceph - берете, разумеется, Ceph. Но не стоит забывать, что там могут быть свои проблемы по сравнению с использованием в режиме обычного Object Storage.
Если вам нужна хорошая совместимость с S3 из коробки, которую разработчики ставят в приоритет - лучше взять LeoFS (но это немного субъективно). Если вам нужна multi-DC репликация - точно берете LeoFS. (но это вообще сложная тема и там могут быть свои проблемы в любом случае).

Оно вполне подходит для небольшой компании, которой нужно хранить например несколько ТБ данных с требованием отказоустойчивости (т.е. не хотим полагаться на RAID, хотим, чтобы при вылете сервера данные не потерялись и продолжало работать). Способно жить на совершенно консьюмерском железе (т.е что-нибудь типа Xeon E3, 32 гига и 4 диска - вполне себе ок для узлов хранения, если нет больших нагрузок). При не очень большом объеме данных и не слишком большом числе узлов отлично будет жить на гигабитной сети, упираясь в нее в какой-то степени только при восстановлении утерянного узла.

Минимальный надежный продакшен-кластер я бы собирал минимум на 6 узлах конфигурации как выше (имхо, с фактором репликации 3 иметь меньше 6 узлов несколько странно), пару шлюзов кинуть на имеющиеся серверы, где собственно будут обрабатываться данные (им, кроме некоторого количества проца - пропорционального количеству запросов - ничего не требуется. Памяти гиг за глаза, хотя можно больше под кэш). Два управляюших узла запустить в виртуалках, контейнерах или прямо на хосте на имеющихся серверах инфраструктуры. Они не потребляют ресурсов, от них требуется только доступность - чтобы не выключались оба сразу, хоть один работал (если недоступны оба, нагрузку PUT/GET кластер продолжит держать, но нельзя будет перезапускать другие узлы и делать некоторые другие операции).

На ЕЩЕ меньших масштабах лучше, вероятно, не думать о распределенных системах вообще.

Для тестирования все узлы можно без проблем запускать на одной машине. Еще есть Project FiFo, где LeoFS работает в солярисовских (точнее, SmartOS) зонах.