СХадупиCouchDBповсюду в блогах и связанных новостях о том, что такое распределенное отказоустойчивое хранилище (движок), которое действительно работает.
- На самом деле CouchDB не имеет встроенных функций распространения, насколько мне известно, связующее звено для автоматического распространения записей или даже целых баз данных просто отсутствует.
- Hadoop, похоже, очень широко используется - по крайней мере, он получает хорошие отзывы, но все еще имеет одну точку отказа: NameNode. Плюс, он монтируется только через FUSE, я понимаю, что HDFS на самом деле не является главной целью Hadoop
- GlusterFSимеет концепцию общего ничего, но в последнее время я прочитал несколько постов, которые привели меня к мнению, что она не совсем так стабильна
- Блесктакже имеет единую точку отказа, поскольку использует выделенный сервер метаданных
- Цефпохоже, это плеер по выбору, но на домашней странице указано, что он все еще находится на стадии альфа-тестирования.
Итак, вопрос в том, какая распределенная файловая система имеет следующий набор функций (без определенного порядка):
- POSIX-совместимый
- простое добавление/удаление узлов
- концепция «ничего общего»
- работает на дешевом оборудовании (процессоры класса AMD Geode или VIA Eden)
- встроенная аутентификация/авторизация
- сетевая файловая система (я хотел бы иметь возможность монтировать ее одновременно на разных хостах)
Приятно иметь:
- локально доступные файлы: я могу отключить узел, смонтировать раздел со стандартной локальной файловой системой (ext3/xfs/какая-либо еще...) и по-прежнему иметь доступ к файлам
Янетищу размещаемые приложения, а не что-то, что позволит мне взять, скажем, 10 ГБ с каждого из наших аппаратных блоков и сделать это хранилище доступным в нашей сети, с возможностью легкого подключения к множеству хостов.
решение1
Я думаю, вам придется отказаться от требования POSIX, очень немногие системы его реализуют - на самом деле даже NFS этого не делает (вроде блокировок и т.п.), а в этом нет избыточности.
Любая система, использующая синхронную репликацию, будет невероятно медленной; любая система, использующая асинхронную репликацию (или «окончательную согласованность»), будет нарушать правила POSIX и вести себя не как «обычная» файловая система.
решение2
Я не могу говорить с остальными, но вы, кажется, путаете «распределенный механизм хранения» и «распределенную файловую систему». Это не одно и то же, их не следует путать с одним и тем же, и они никогда не будут одним и тем же. Файловая система — это способ отслеживать, где что-то находится на жестком диске. Механизм хранения, такой как hadoop, — это способ отслеживать фрагмент данных, идентифицированный ключом. Концептуально, особой разницы нет. Проблема в том, что файловая система — это зависимость механизма хранения... в конце концов, ему нужен способ записи на блочное устройство, не так ли?
Помимо всего этого, яможетрасскажите об использовании ocfs2 как распределенной файловой системы в производственной среде. Если вы не хотите суровых подробностей, прекратите читать после этой строки: Это довольно круто, но это может означать больше простоя, чем вы думаете.
Мы используем ocfs2 в производственной среде последние пару лет. Это нормально, но не очень хорошо для многих приложений. Вам действительно следует взглянуть на свои требования и выяснить, каковы они — вы можете обнаружить, что у вас гораздо больше свободы для ошибок, чем вы думали.
Например, ocfs2 имеет журнал для каждой машины в кластере, которая будет монтировать раздел. Допустим, у вас есть четыре веб-машины, и когда вы создаете этот раздел с помощью mkfs.ocfs2, вы указываете, что всего будет шесть машин, чтобы дать себе немного места для роста. Каждый из этих журналов занимает место, что уменьшает объем данных, которые вы можете хранить на дисках. Теперь, предположим, вам нужно масштабироваться до семи машин. В этой ситуации вам нужно отключитьвеськластер (т. е. размонтируйте все разделы ocfs2) и используйте утилиту tunefs.ocfs2 для создания дополнительного журнала, при условии, что есть свободное место. Тогда и только тогда вы можете добавить седьмую машину в кластер (что требует распространения текстового файла по остальной части кластера, если вы не используете утилиту), восстановить все и затем смонтировать раздел на всех семи машинах.
Видите, о чем я? Он должен быть высокодоступным, что должно означать «всегда в сети», но тут же вы получаете кучу простоев... и не дай бог вам перегрузить дисковое пространство. Вы НЕ хотите видеть, что произойдет, если вы переполните ocfs2.
Имейте в виду, что evms, который раньше был «предпочтительным» способом управления кластерами ocfs2, пошел по пути птицы додо в пользу clvmd и lvm2. (И скатертью дорога evms.) Кроме того, heartbeat быстро превратится в зомби-проект в пользу стека openais/pacemaker. (Отступление: при выполнении начальной конфигурации кластера для ocfs2 вы можете указать «pcmk» в качестве кластерного движка вместо heartbeat. Нет, это не задокументировано.)
Как бы то ни было, мы вернулись к NFS, управляемой Pacemaker, поскольку несколько секунд простоя или несколько потерянных пакетов TCP, пока Pacemaker переносит общий ресурс NFS на другую машину, незначительны по сравнению с количеством простоев, которые мы наблюдали при выполнении базовых операций с общим хранилищем, таких как добавление машин при использовании ocfs2.
решение3
Я могу неправильно понимать ваши требования, но вы смотрели наhttp://en.wikipedia.org/wiki/Список_файловых_систем#Распределенные_файловые_системы
решение4
Взгляните на чириканьеhttp://www.cse.nd.edu/~ccl/software/chirp/и попугайhttp://www.cse.nd.edu/~ccl/software/parrot/