Проверка работоспособности распределенной файловой системы

Question

Мне нужна распределенная файловая система, которая должна масштабироваться до очень больших размеров (около 100 ТБ реалистичного макс). Размер файлов в основном зависит от диапазона 10-1500 КБ, хотя некоторые файлы могут достигать максимума примерно в 250 МБ.

Мне очень нравятся такие системы, как GFS со встроенной избыточностью для резервного копирования, которая бы - статистически - визуализировала потерю файлов в прошлом.

У меня есть несколько требований:

• Открытый исходный код
• Нет SPOFs
• Автоматическое репликации файлов (то есть, нет необходимости в RAID)
• Управляемый доступ клиента
• плоское пространство имен файлов - предпочтительно
• Встраиваемые удаления с удалением
• Проверенные развертывания

Я серьезно смотрел на MogileFS, так как он выполняет большинство требований. У него нет управляемых клиентов, но довольно просто сделать порт клиента Java. Тем не менее, нет встроенных версий. Без управления версиями мне придется делать обычные резервные копии, кроме репликации файлов, встроенных в MogileFS.

В принципе, мне нужна защита от ошибки программирования, которая внезапно очищает много файлов, которые она не должна иметь. В то время как MogileFS защищает меня с диска & машинных ошибок, реплицируя мои файлы по X числу устройств, это не спасает меня, если я делаю необоснованное удаление.

Я хотел бы иметь возможность указать, что операция удаления фактически не вступает в силу только после Y дней. Удаление будет логически выполнено, но я могу восстановить состояние файла в течение Y дней, пока он фактически не исчезнет. Кроме того, MogileFS не имеет возможности проверять повреждение диска во время записи - хотя это также можно добавить.

Поскольку мы являемся магазином Microsoft (Windows, .NET, MSSQL), я бы оптимально использовал основные части, которые будут работать в Windows, для удобства обслуживания, в то время как узлы хранения данных запускают * nix (или комбинацию) из-за лицензирование.

Прежде, чем я даже подумаю о том, чтобы опрокинуться, есть ли у вас какие-либо предложения для меня? Я также проверил HadoopFS, OpenAFS, Luster & GFS - но ни один из них не соответствует моим требованиям.

Answer 1

Нужно ли размещать это на своих серверах? Многое из того, что вам нужно, может быть предоставлено Amazon S3. Функция замедленного удаления может быть реализована путем записи удалений в таблицу SimpleDB и периодического запуска сбора мусора, чтобы удалить файлы, когда это необходимо.

По-прежнему существует одна точка отказа, если вы полагаетесь на одно подключение к Интернету. И, конечно же, вы могли бы считать, что сама Амазонка является точкой отказа, но частота отказов всегда будет намного ниже из-за масштаба.

И, надеюсь, вы осознаете другие преимущества, способность масштабироваться до любой емкости. Не требуется, чтобы ИТ-персонал заменил неисправные диски или системы. Расходы на использование будут постоянно снижаться по мере того, как емкость диска и пропускная способность становятся дешевле (в то время как диски, которые вы покупаете, обесцениваются по стоимости).

Можно также использовать гибридный подход и использовать S3 в качестве защищенного бэкэнд-архива и локально хранить «горячие» данные, а также найти стратегию кэширования, которая наилучшим образом соответствует вашей модели использования. Это может значительно снизить использование полосы пропускания и улучшить ввод-вывод, особенно если данные изменяются нечасто.

Downsides:

• Файлы на S3 являются неизменными, они могут быть заменены только полностью или удалены. Это отлично подходит для кэширования, не так хорош для эффективности, когда делает небольшие изменения в больших файлах.
• Задержка и полоса пропускания - это значение вашего сетевого подключения. Кэширование может помочь улучшить это, но вы никогда не будете получить тот же уровень производительности.

Управление версиями также будет настраиваемым решением, но может быть реализовано с помощью SimpleDB вместе с S3 для отслеживания наборов изменений в файле. На самом деле, это действительно зависит от вашего варианта использования, если это будет хорошо.

Answer 2

Вы можете попробовать запустить систему управления версиями поверх надежной файловой системы. Тогда возникает проблема с тем, как удалить старые проверки после истечения времени ожидания. Вы можете настроить сервер Apache с помощью DAV_SVN и зафиксировать каждое изменение, сделанное с помощью интерфейса DAV. Я не уверен, насколько это масштабируется при больших размерах файлов, которые вы описываете.

Answer 3

@tweakt
Я также рассматривал S3, но я не думаю, что это будет для нас удовлетворительным в долгосрочной перспективе. У нас есть много файлов, которые должны храниться надежно - не через ACL файла, а через наш прикладной уровень. Хотя это также можно сделать через S3, у нас есть один бит меньше контроля над нашим файловым хранилищем. Кроме того, также будет существенный недостаток в формах латентности, когда мы выполняем файловые операции - как начальные сбережения (которые могут выполняться асинхронно), но также когда мы позже читаем файлы и должны выполнять операции над ними.

Что касается SPOF, это не проблема. У нас есть избыточные соединения с нашим центром обработки данных, и, хотя я не хочу никаких SPOF, малое время простоя S3 было приемлемым.

Неограниченная масштабируемость и отсутствие необходимости в обслуживании, безусловно, является преимуществом.

Что касается гибридного подхода. Если мы хотим напрямую подключиться к S3, - если бы мы не захотели хранить все локально в любом случае (и просто использовать S3 в качестве резервной копии), цены на полосу пропускания просто слишком круты, когда мы добавляем S3 + CloudFront (CloudFront будет необходим как у нас есть клиенты со всех сторон). В настоящее время мы размещаем все, начиная от нашего центра обработки данных в Европе, и у нас есть своя собственная установка обратных кальмаров в США для низкобюджетной функциональности CDN.

Несмотря на то, что он очень зависим от доменов, умма не является проблемой для нас. Мы можем заменить файлы (то есть, ключ X получает новый контент), но мы не будем вносить незначительные изменения в файл. Все наши файлы являются блобами.