Есть так много вариантов, что трудно понять, с чего начать. Мои требования таковы:
Кроме того, я ищу эти качества, хотя они и не являются «требованиями»:
Я хотел бы получить информацию о том, какая файловая система лучше всего подходит для данных требований. Некоторые люди в моей организации склоняются к MogileFS, но я не уверен в стабильности и динамике этого проекта. GlusterFS и Lustre, судя по моему ограниченному исследованию, лучше поддерживаются ...
Мысли?
На самом деле, я не думаю, что существует много реальных вариантов. В порядке предпочтения я бы выбрал:
Распределенная файловая система Hadoop (HDFS) не будет соответствовать вашим требованиям IMHO. HDFS прекрасна, но ее подход, подобный bigtable, означает, что она менее доступна, чем файловые системы выше. Конечно, если вы действительно ищете масштабируемость и долгосрочную перспективу, то HDFS может быть правильным решением - Yahoo, Facebook и другие инвестировали в рост Hadoop.
Один комментарий, большинство вышеперечисленных систем копируют весь файл на 2-3 узла для достижения избыточности. Это занимает гораздо больше места, чем схемы кодирования с четностью / RAID, но это управляемо в масштабе, и, похоже, это решение, которое все приняли. Таким образом, вы не получите упомянутой эффективности 75% ...
Если бы это был я, я бы использовал GlusterFS. Текущая версия довольно надежна, и я знаю людей на некоторых очень крупных установках как в области высокопроизводительных вычислений, так и в Интернете, которые полагаются на нее в своих производственных системах. Вы можете адаптировать его к своим потребностям, расположив компоненты по мере необходимости. В отличие от Lustre, здесь нет выделенных серверов метаданных, поэтому количество центральных точек сбоя сводится к минимуму, а настройку легче масштабировать.
К сожалению, я не думаю, что есть простой способ удовлетворить ваши 75% -ные критерии без потери производительности.
Он действительно работает на стандартном оборудовании, однако при использовании межсоединения Infiniband производительность действительно повышается. К счастью, в наши дни цена IB действительно довольно низкая.
Вы могли бы проверить ребят в Масштабируемая информатика и их продукты Jackrabbit в качестве решения. Они поддерживают GlusterFS на своем оборудовании, и цена их решения, безусловно, соперничает со стоимостью создания чего-то с нуля.
Возможно, он не отвечает всем вашим требованиям, особенно к экономии места (по умолчанию он разбивает каждый блок на 10 долей, любые 3 из которых могут обеспечить восстановление (хотя это можно изменить)), но вы все равно можете взглянуть на Тахо-ЛАФС.
Он в первую очередь предназначен для резервного копирования, но люди создали (и все еще создают) множество очень интересных приложений без резервного копирования на его основе. Например, один из разработчиков ведет на нем свой блог.
GPL, написанная на Python. Он уже включен в Ubuntu, IIRC.
Файловая система Moose похоже, соответствует вашим требованиям. Он работает на Linux (например, Ubuntu или Debian) и на обычном оборудовании. Хранилище может иметь размер до 16 эксабайт (~ 16000 петабайт). Более того, это зрелая (выпущена в 2008 году) отказоустойчивая распределенная файловая система с большой поддержкой.
Дополняя ответ Камила, вы можете принудительно выполнить репликацию данных в GlusterFS после сбоя узла хранения, пытаясь прочитать из каждого файла в GFS - AFAIK нет более простого способа определить, какие файлы требуют репликации.
Следующая команда может помочь - она по сути вызывает head -c1 для каждого файла и регистрирует успехи / неудачи в /tmp/gfs-check.log
find /mnt/gfs ! -type d \( \( -exec head -qc1 '{}' + \
-fprintf /tmp/gfs-check.log "%p OK\n" \) -o \
-fprintf /tmp/gfs-check.log "%p ERROR\n" \) > /dev/null