Файловая система распределенного хранилища - какая / есть готовый продукт?

С Hadoop и CouchDB в блогах и связанных новостях, что такое распределенное отказоустойчивое хранилище (механизм), которое на самом деле работает.

• CouchDB на самом деле не имеет встроенных функций распространения, насколько мне известно, клей для автоматического распределения записей или даже целых баз данных просто отсутствует.
• Hadoop, кажется, очень широко используется - по крайней мере, он получает хорошую прессу, но все еще имеет единственную точку отказа: NameNode. Кроме того, он монтируется только через FUSE, я понимаю, что HDFS на самом деле не главная цель Hadoop
• У GlusterFS действительно нет ничего общего, но в последнее время я прочитал несколько постов, которые привели меня к мнению, что он не так стабилен
• У блеска также есть единственная точка отказа, поскольку он использует выделенный сервер метаданных
• Ceph, кажется, является лучшим игроком, но на домашней странице говорится, что он все еще находится в стадии альфа.

Таким образом, вопрос в том, какая распределенная файловая система имеет следующий набор функций (без определенного порядка):

• POSIX-совместимых
• простое добавление / удаление узлов
• Концепция "ничего общего"
• работает на дешевом оборудовании (процессоры класса AMD Geode или VIA Eden)
• встроенная аутентификация / авторизация
• сетевая файловая система (я хотел бы иметь возможность монтировать ее одновременно на разных хостах)

Приятно иметь:

• локально доступные файлы: я могу взять узел, смонтировать раздел со стандартной локальной файловой системой (ext3 / xfs / что угодно ...) и по-прежнему получать доступ к файлам

Я не ищу размещенные приложения, скорее что-то, что позволит мне взять, скажем, 10 ГБ каждого из наших аппаратных блоков и иметь доступное хранилище в нашей сети, легко монтируемое на множестве хостов.

Я думаю, что вам придется отказаться от требования POSIX, очень немногие системы реализуют это - на самом деле даже NFS на самом деле этого не делает (думаю, блокировки и т. Д.), И это не имеет избыточности.

Любая система, которая использует синхронную репликацию, будет ледниково медленной; любая система, имеющая асинхронную репликацию (или «возможную согласованность»), будет нарушать правила POSIX и не вести себя как «обычная» файловая система.

Я не могу говорить с остальными, но вы, кажется, запутались между «распределенным хранилищем» и «распределенной файловой системой». Они не одно и то же, их не следует принимать за одно и то же, и они никогда не будут одинаковыми. Файловая система - это способ отслеживать местонахождение вещей на жестком диске. Механизм хранения, такой как hadoop, является способом отслеживания фрагмента данных, идентифицируемых ключом. Концептуально не большая разница. Проблема в том, что файловая система является зависимостью от механизма хранения ... в конце концов, ей нужен способ записи на блочное устройство, не так ли?

Помимо всего этого, я могу говорить об использовании ocfs2 в качестве распределенной файловой системы в производственной среде. Если вам не нужны мелкие детали, перестаньте читать после этой строки: это круто, но это может означать больше простоев, чем вы думаете.

Последние пару лет мы запускаем ocfs2 в производственной среде. Это нормально, но не подходит для многих приложений. Вы должны действительно посмотреть на свои требования и выяснить, каковы они - вы можете обнаружить, что у вас гораздо больше возможностей для устранения ошибок, чем вы думали.

Например, у ocfs2 есть журнал для каждой машины в кластере, которая собирается смонтировать раздел. Допустим, у вас есть четыре веб-машины, и когда вы создаете этот раздел с помощью mkfs.ocfs2, вы указываете, что всего будет шесть машин, чтобы дать себе возможность расти. Каждый из этих журналов занимает место, что уменьшает объем данных, которые вы можете хранить на дисках. Теперь предположим, что вам нужно масштабировать до семи машин. В этой ситуации вам нужно снять всекластера (т. е. размонтируйте все разделы ocfs2) и используйте утилиту tunefs.ocfs2 для создания дополнительного журнала, если есть свободное место. Тогда и только тогда вы можете добавить седьмую машину в кластер (что требует от вас распространения текстового файла на остальную часть кластера, если вы не используете утилиту), восстановить все, а затем смонтировать раздел на всех семи машины.

Видишь, о чем я? Предполагается, что это высокая доступность, что должно означать «всегда в сети», но тут у вас куча простоев ... и не дай бог, вам не хватает места на диске. Вы не хотите видеть, что происходит, когда вы толпитесь ocfs2.

Имейте в виду, что evms, который раньше был «предпочтительным» способом управления кластерами ocfs2, пошел по пути птицы додо в пользу clvmd и lvm2. (И хорошее избавление от evms.) Кроме того, heartbeat быстро превратится в проект зомби в пользу стека openais / кардиостимулятора. (Помимо: при выполнении начальной конфигурации кластера для ocfs2 вы можете указать «pcmk» в качестве механизма кластера, а не пульса. Нет, это не задокументировано.)

Что бы это ни стоило, мы вернулись к NFS, управляемой кардиостимулятором, потому что несколько секунд простоя или несколько отброшенных tcp-пакетов, когда кардиостимулятор мигрирует общий ресурс NFS на другую машину, тривиальны по сравнению с тем временем простоя, которое мы наблюдали для основных операции с общим хранилищем, такие как добавление машин при использовании ocfs2.

Возможно, я неправильно понимаю ваши требования, но вы смотрели на http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Просто добавьте мои 0,02 евро сюда: не может ли OpenAFS делать то, что вы хотите?

Взгляните на щебетание http://www.cse.nd.edu/~ccl/software/chirp/ и попугай http://www.cse.nd.edu/~ccl/software/parrot/

Как насчет Xtreemfs ? Версия 1.4 (ноябрь 2012) считается качеством продукции.

Он совместим с POSIX и обладает выдающейся автоматической отказоустойчивостью.

Блеск допускает несколько хранилищ метаданных в активной / пассивной конфигурации для избыточности, поэтому нет единой точки отказа.

OCFS2 также стоит посмотреть.

Обратите внимание, что исключение требования для множественного одновременного доступа к сети позволяет переключаться на что-то вроде iSCSI или даже cifs или nfs. Недостатком является то, что вы должны «вырезать» куски вашего uberArray на куски для каждого сервера, которому нужно место.

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

Комментарий, задающий вопрос, действительно ли вам нужна семантика POSIX, является хорошим началом. Семантика «файловой системы», отличная от POSIX, может быть гораздо более гибкой, что приводит к гораздо более надежным системам.

Если это устаревшее приложение, я действительно задаюсь вопросом, почему современная распределенная файловая система может считаться лучшим решением.

Не поймите меня неправильно - это удивительно забавные игрушки. Я просто не хотел бы нести ответственность за сложное взаимозависимое решение, которое обычно не используется и было бы очень трудно исправить, когда оно вылетает.

Вы действительно, абсолютно положительно нуждаетесь в семантике POSIX? Жизнь становится намного проще, если вы можете использовать пользовательское хранилище данных. У нас есть внутренне записанное хранилище данных, которое представляет собой очень большое распределенное хранилище значений ключей. Вы сохраняете в нем файл и получаете токен обратно. Если вы хотите вернуть файл, дайте ему токен, который вы получили ранее. Он распространяется, ничего не передается, данные реплицируются три раза, узлы могут быть добавлены и удалены по желанию, как серверов хранения, так и управляющих серверов.

У блеска также есть единственная точка отказа, поскольку он использует выделенный сервер метаданных

Lustre предназначен для поддержки восстановления после отказа, а MDS / MDT / OSS может иметь несколько адресов, по которым с ним можно связаться, сердцебиение можно использовать для переноса службы вокруг.

Имейте в виду, что в некоторых последних версиях возникали проблемы, при которых размонтирование работает, но на диске все еще есть данные, однако защита с двойным креплением должна была помочь (кроме интересных проблем, которые возникали) ....

Я рекомендую вам использовать MooseFS (отказоустойчивая, масштабируемая, сетевая распределенная файловая система). Он совместим с POSIX и, начиная с версии 1.6, MooseFS предлагает простую NFS-подобную аутентификацию / авторизацию. Смотрите также требования к оборудованию .