С участием Hadoop и CouchDB повсюду в блогах и связанных новостях, что такое распределенное отказоустойчивое хранилище (движок), которое на самом деле работает.
Итак, вопрос в том, какая распределенная файловая система имеет следующий набор функций (без определенного порядка):
Хорошо бы иметь:
я не ищу размещенные приложения, скорее то, что позволит мне занять, скажем, 10 ГБ каждого из наших аппаратных боксов и иметь это хранилище в нашей сети, легко монтируемое на множестве хостов.
Я не могу говорить с остальными, но вы, кажется, запутались между «механизмом распределенного хранения» и «распределенной файловой системой». Это не одно и то же, их не следует принимать за одно и то же, и они никогда не будут одинаковыми. Файловая система - это способ отслеживать, где что-то находится на жестком диске. Механизм хранения, такой как hadoop, - это способ отслеживать порцию данных, идентифицированную ключом. Концептуально особой разницы. Проблема в том, что файловая система - это зависимость механизма хранения ... в конце концов, ей нужен способ записи на блочное устройство, не так ли?
Все это в стороне, я жестяная банка поговорим об использовании ocfs2 в качестве распределенной файловой системы в производственной среде. Если вам не нужны подробные детали, прекратите читать после этой строки: это круто, но это может означать большее время простоя, чем вы думаете.
Мы использовали ocfs2 в производственной среде последние пару лет. Это нормально, но для многих приложений это плохо. Вам действительно стоит взглянуть на свои требования и выяснить, что они из себя представляют - вы можете обнаружить, что у вас гораздо больше возможностей для устранения неисправностей, чем вы думали.
Например, ocfs2 ведет журнал для каждой машины в кластере, которая будет монтировать раздел. Допустим, у вас есть четыре веб-машины, и когда вы создаете этот раздел с помощью mkfs.ocfs2, вы указываете, что всего будет шесть машин, чтобы дать себе некоторое пространство для роста. Каждый из этих журналов занимает место, что уменьшает объем данных, которые вы можете хранить на дисках. Теперь предположим, что вам нужно масштабировать до семи машин. В этой ситуации вам нужно снять весь cluster (т. е. отключите все разделы ocfs2) и используйте утилиту tunefs.ocfs2 для создания дополнительного журнала при наличии свободного места. Тогда и только тогда вы можете добавить седьмую машину в кластер (что требует, чтобы вы распространили текстовый файл на остальную часть кластера, если вы не используете утилиту), восстановить все резервные копии, а затем смонтировать раздел на всех семи машины.
Понимаете, что я имею в виду? Предполагается, что это будет высокая доступность, что означает «всегда в сети», но тут у вас куча простоев ... и не дай бог вам переполнено дисковым пространством. Вы НЕ хотите видеть, что происходит, когда вы набираете ocfs2.
Имейте в виду, что evms, который раньше был «предпочтительным» способом управления кластерами ocfs2, пошел по пути додо в пользу clvmd и lvm2. (И избавление от evms.) Кроме того, Heartbeat быстро превратится в зомби-проект в пользу стека openais / pacemaker. (Кроме того: при первоначальной настройке кластера для ocfs2 вы можете указать pcmk в качестве механизма кластера, а не тактового импульса. Нет, это не задокументировано.)
Как бы то ни было, мы вернулись к nfs, управляемым с помощью кардиостимулятора, потому что несколько секунд простоя или несколько сброшенных пакетов tcp, когда кардиостимулятор переносит общий ресурс nfs на другую машину, тривиально по сравнению с количеством простоев, которые мы наблюдали для базового операции с общим хранилищем, такие как добавление машин при использовании ocfs2.
Я думаю, вам придется отказаться от требования POSIX, очень немногие системы реализуют это - на самом деле даже NFS на самом деле этого не делает (думаю, блокировки и т.д.), и это не имеет избыточности.
Любая система, использующая синхронную репликацию, будет очень медленной; любая система, имеющая асинхронную репликацию (или «возможную согласованность»), будет нарушать правила POSIX и не вести себя как «обычная» файловая система.
Возможно, я неправильно понимаю ваши требования, но вы смотрели 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 и обладает выдающейся автоматической отказоустойчивостью.
Lustre позволяет использовать несколько хранилищ метаданных в активной / пассивной конфигурации для избыточности, поэтому нет единой точки отказа.
Также стоит взглянуть на OCFS2.
Обратите внимание, что устранение требования о множественном одновременном доступе к сети позволяет переключиться на что-то вроде iSCSI или даже cifs или nfs. Обратной стороной является то, что вам нужно «вырезать» части вашего uberArray на кусочки для каждого сервера, которому требуется место.
За исключением академических целей / целей развития, к подобным вещам следует подходить, начиная с общих требований к проекту. Большинство распределенных файловых систем не достаточно зрелы для серьезного развертывания - например, что делать, если все выходит из строя. Если это для академических целей / целей развития, то это на самом деле хорошо, так как вы можете многому научиться и исправить множество ошибок.
Комментарий с вопросом, действительно ли вам нужна семантика POSIX, - хорошее начало. Семантика "файловой системы", не относящаяся к POSIX, может быть гораздо более гибкой, что ведет к созданию гораздо более надежных систем.
Если это устаревшее приложение, мне действительно интересно, почему современная распределенная файловая система может считаться лучшим решением.
Не поймите меня неправильно - это потрясающе веселые игрушки. Я просто не хотел бы нести ответственность за сложное взаимозависимое решение, которое обычно не используется и которое будет очень сложно исправить, когда оно выйдет из строя.
Вам действительно нужна семантика POSIX? Жизнь станет намного проще, если вы сможете использовать собственное хранилище данных. У нас есть внутреннее хранилище данных, которое фактически представляет собой очень большое распределенное хранилище значений ключей. Вы сохраняете в нем файл и получаете обратно токен. Если вы хотите вернуть файл, отдайте ему токен, который вы получили ранее. Он распределен, не используется совместно, данные реплицируются трижды, узлы могут быть добавлены и удалены по желанию, как серверы хранения, так и управляющие серверы.
У Lustre также есть единственная точка отказа, поскольку он использует выделенный сервер метаданных.
Lustre разработан для поддержки аварийного переключения, и MDS / MDT / OSS может иметь несколько адресов, по которым с ним можно связаться, для миграции службы можно использовать контрольный сигнал.
Имейте в виду, что в некоторых последних версиях были проблемы, при которых размонтирование работало, но на диске все еще хранятся данные, однако защита от двойного монтирования должна была помочь (помимо интересных проблем, которые были) ....
Я рекомендую вам использовать MooseFS (Отказоустойчивая, масштабируемая, сетевая распределенная файловая система). Он совместим с POSIX, и начиная с версии 1.6 MooseFS предлагает простую, похожую на NFS, аутентификацию / авторизацию. Смотрите также требования к оборудованию.