> А про сравнить с люстрой кто-то что-то сказать может?Это не аналог люстры и не предназначено для больших кластеров. Это объектный сторейдж. Есть у вас до фига каких-то данных в виде множества мелких сущностей и ваши приложения с этим работают. Вы хотите их хранить распределенно, чтобы отказоустойчиво и быстро, при этом по возможности подешевле - вот это то, что нужно. А если ваш софт уже умеет 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 - вот тут не могу сказать, но это очень новый продукт, что (лично для меня) сразу огромный минус. По фичам и планам там все весьма интересно. Если созреет, будет очень хорошей альтернативой.
