Распределенные файловые системы: GridFS против GlusterFS vs Ceph vs HekaFS Benchmarks
В настоящее время я ищу хорошую распределенную файловую систему.
Он должен:
- быть открытым исходным кодом
- быть масштабируемым по горизонтали (репликация и очертание)
- не имеют единой точки отказа
- имеют относительно небольшой размер
Вот четыре самых перспективных кандидата на мой взгляд:
Файловая система будет использоваться в основном для мультимедийных файлов (изображений и аудио). Есть очень маленькие, а также файлы среднего размера (1 КБ - 10 МБ). Количество файлов должно быть около нескольких миллионов.
Существуют ли тесты производительности производительности, загрузки процессора, памяти и . Каковы ваши опыты с использованием этих или других распределенных файловых систем?
Ответы
Ответ 1
Я не уверен, что ваш список совершенно правильный. Это зависит от того, что вы подразумеваете под файловой системой.
Если вы имеете в виду файловую систему, которая монтируется в операционной системе и может использоваться любым приложением, которое считывает и записывает файлы с использованием вызовов POSIX, то GridFS действительно не подходит. Именно так MongoDB хранит объекты в формате BSON. Это Система объектов, а не файловая система.
Существует проект, чтобы сделать GridFS mountable, но это немного странно, потому что GridFS не имеет понятий для таких вещей, как иерархические каталоги, хотя допускаются пути. Кроме того, я не уверен, как распределенные записи на gridfs-fuse будут.
GlusterFS и Ceph сопоставимы и распределены, реплицируемые монтируемые файловые системы. Вы можете прочитать сравнение между ними здесь (и последующее обновление сравнение), хотя имейте в виду, что контрольные показатели выполняются кем-то, кто немного предвзято. Вы также можете посмотреть эту дискуссию по теме.
Как и в HekaFS, GlusterFS настроен для облачных вычислений, добавляет шифрование и многопоточность, а также административный интерфейс.
Ответ 2
После работы с Ceph в течение 11 месяцев я пришел к выводу, что это ужасно, поэтому я предлагаю избегать этого. Я пробовал XtreemFS, RozoFS и QuantcastFS, но также нашел их недостаточно хорошими.
Я искренне рекомендую LizardFS, которая является ответвлением проприетарного MooseFS. LizardFS обеспечивает целостность данных, мониторинг и превосходную производительность с очень небольшим количеством зависимостей.
Обновление 2019: ситуация изменилась, и LizardFS больше не поддерживается.
MooseFS сильнее, чем когда-либо, и свободен от большинства ошибок LizardFS. MooseFS в хорошем состоянии и работает быстрее, чем LizardFS.
RozoFS повзрослела и, возможно, стоит попробовать.
У GfarmFS есть своя ниша, но сегодня я бы выбрал MooseFS для большинства приложений.
Ответ 3
OrangeFS, кто-нибудь?
Я ищу HPC DFS и нашел здесь эту дискуссию:
http://forums.gentoo.org/viewtopic-t-901744-start-0.html
Много хороших данных и сравнений:)
После некоторого разговора OP решил использовать OrangeFS, процитировав:
"OrangeFS. Он не поддерживает квоты и блокировки файлов (хотя все операции ввода/вывода являются атомарными, и это
согласованность пути сохраняется без блокировок). Но он работает, работает хорошо и стабильно. Кроме того, это
а не общей файловой системы, ориентированной на хранилище данных, но выделенной HPC, ориентированной на параллельный ввод-вывод, включая
Поддержка ROMIO. Все тесты проводились для распределения данных по полосе.
a) Нет квот - к черным квотам. Я все равно отказался от них, даже glusterfs не поддерживает
uid/gid, но ограничения по размеру каталога больше похожи на LVM.
b) Поддерживаются и стабильны несколько активных серверов метаданных. По сравнению с выделенными метаданными
(одиночный node), это дает + 50% производительности на небольших файлах и не имеет существенной разницы в
большие.
c) Отличная производительность при больших объемах данных (dd bs = 1M). Он ограничен суммой локального жесткого диска
(не забывайте, что каждый node участвует также в качестве сервера данных), скорость и доступную пропускную способность сети.
Потребление процессора на такой нагрузке является приличным и составляет около 50% одного ядра на клиенте node и примерно
10% процентов друг от друга на узлах сервера данных.
d) Яркая производительность на больших наборах небольших файлов. Для теста я запустил linux kernel 3.1. Потребовалось 5 минут
через OrangeFS (с настроенными параметрами) и почти 2 минуты по сравнению с NFSv4 (настроенный также) для сравнения.
Нагрузка процессора составляет около 50% от одного ядра (разумеется, фактически распределена между ядрами) на клиенте и
около нескольких процентов на каждом node.
e) Поддержка API ввода-вывода ROMIO MPI. Это приятный вкус для приложений с поддержкой MPI, что позволяет использовать
Функции параллельного ввода-вывода PVFS2/OrangeFS непосредственно из приложений.
f) Нет поддержки специальных файлов (сокетов, fifo, блочных устройств). Таким образом, нельзя использовать как /home, и я использую
NFSv4 для этой задачи, предоставляющей пользователям ограниченное количество квот. Хотя большинство
файловые системы в любом случае не поддерживают специальные файлы. "
Ответ 4
Я не знаю о других системах, которые вы опубликовали, но я сделал сравнение 3 PHP CMS/Frameworks на локальном хранилище против GlusterFS, чтобы убедиться, что он лучше работает на реальных тестах мира, чем на исходных тестах. К сожалению нет.
http://blog.lavoie.sl/2013/12/glusterfs-performance-on-different-frameworks.html