Уважаемое сообщество Serverfault,
После исследования ряда распределенных файловых систем для развертывания в производственной среде с основной целью выполнения как пакетных распределенных вычислений, так и распределенных вычислений в реальном времени, я определил следующий список в качестве потенциальных кандидатов, в основном по зрелости, лицензии и поддержке:
Ключевые свойства, которые должна проявлять наша система:
Были выявлены следующие уязвимые места, по результатам которых были заданы следующие вопросы:
С нетерпением жду ваших ответов. Заранее спасибо! :)
С наилучшими пожеланиями,
Тим ван Элтерен
Похоже, вы уже проделали здесь большую работу. Что касается ваших ключевых требований, все файловые системы, которые вы определили, в некоторой степени им соответствуют. Это то, что делают распределенные файловые системы в силу будучи распределенные файловые системы.
Единственное требование, заслуживающее дальнейшего обсуждения, - это лицензирование - по-видимому, это бизнес внимание к вашей компании, и служит для исключения других подходящих кандидатов, которые не желательны для бизнес причины. Это набор вариантов, который вам необходимо сделать внутри компании, проконсультировавшись с остальной частью вашей компании, и похоже, что вы уже знаете, чего хотите.
На самом деле мы не можем сказать вам, какую файловую систему использовать (вам нужно будет провести дополнительные исследования, и определенно было бы целесообразно провести некоторое лабораторное тестирование / моделирование - воспользуйтесь преимуществами виртуализации и множества бесплатных гипервизоров!), Но я могу дать вы немного понимаете свои точки чувствительности "
Прозрачность для уровня обработки / приложения в отношении местоположения данных, например знать, где данные физически расположены на уровне сервера, в основном для распределения ресурсов и быстрой обработки, высокой производительности, как это можно сделать? Знаете ли вы по опыту, какие решения обеспечивают эту прозрачность и в какой степени?
Распределенные файловые системы, как правило, прозрачны для остальной части ОС (выше уровня файловой системы). Файловая система обрабатывает распределение данных по различным узлам, реплицирует их для обеспечения отказоустойчивости и перемещает их на / с клиентских машин - ваша операционная система просто обрабатывает их как любую другую файловую систему.
Любая распределенная файловая система, которая не На мой взгляд, предоставление такого уровня абстракции - не лучший вариант: клиентские системы не должны необходимость чтобы знать, как распределенная ФС работает под капотом, не больше, чем им нужно знать локальную дисковую организацию сервера NFS.
Вопросы производительности - это отдельный вопрос - каждую файловую систему, о которой вы упомянули выше, можно до некоторой степени настроить. Лучший совет здесь - «Делайте собственные тесты на основе вашей рабочей нагрузки»., но вы также можете посмотреть опубликованные тесты, чтобы получить приблизительное представление о том, чего ожидать.
Соответствие POSIX упоминается на вики-страницах большинства перечисленных выше решений. Вопрос здесь в основном в том, насколько актуальна поддержка стандарта POSIX?
Только вы можете ответить на вопрос актуальности (исходя из ваших требований), но, как сторонник Unix старой школы, я могу сказать вам, что ожидаю, что файловые системы на хосте Unix / Linux будут соответствовать спецификации POSIX, особенно в наиболее заметных областях. области (ограничения файлов, разрешения, списки контроля доступа).
Принцип наименьшего удивления также диктует, что в системе Unix или Linux ваши файловые системы должны соответствовать стандарту POSIX и предоставлять разрешения и списки ACL с помощью стандартных инструментов операционной системы, поэтому я считаю, что решительное голосование за использование распределенной файловой системы с POSIX-совместимым интерфейс.
А как насчет разницы между синхронной и асинхронной работой распределенной файловой системы? Хотя предпочтение отдается синхронной распределенной файловой системе из-за надежности, она также накладывает определенные ограничения в отношении масштабируемости. Каким будет способ, исходя из вашего опыта?
Опять только ТЫ жестяная банка предотвращать лесные пожары сделать этот звонок.
Как вы правильно заметили, у синхронных распределенных файловых систем есть некоторые проблемы с масштабируемостью (в основном в отношении записывать производительность). У них также есть преимущество сильной консистенции.
Асинхронные распределенные файловые системы почти всегда имеют лучшую производительность, но сопряжены с внутренним уровнем риска - обычно с большей вероятностью несогласованности данных в кластере или потери данных из-за временных единичных точек отказа во время синхронизации данных. / реплицирован.
С моей точки зрения (будучи сторонником старой школы Unix) согласованность и стабильность важнее производительности. В лекции МакКьюсика по истории FFS похоронена замечательная цитата. что-то вроде «Файловые системы должны делать это правильно, потому что пользователи очень расстраиваются, когда вы теряете их данные». Следствием в мире бизнес / производственной среды является то, что системных администраторов увольняют, когда они теряют данные на миллионы долларов. , поэтому дополнительные несколько миллисекунд, чтобы гарантировать правильную репликацию данных через распределенную файловую систему, имеют для меня большой смысл, и я бы предпочел использовать синхронную DFS, если не было очень хорошая причина не делать этого.
Как быстро вам нужно читать? И насколько важна глобальная масштабируемость?
Я сразу понял, что Lustre может быть быстрым, но это единственная его функция из вашего списка.
Я знаю, что есть две вещи, которые соответствуют вашим требованиям.
Xrootd - глобальный HA только для чтения, широко используемый в научном сообществе.
http://xrootd.slac.stanford.edu/
OpenAFS - существует очень давно и широко используется в высшем образовании.
Ни один из них не будет иметь скорости чтения правильно настроенной системы Lustre, но оба могут масштабироваться для развертывания по всему миру. Что мне известно об остальном программном обеспечении в вашем списке, так это то, что оно больше подходит для доступа в одном центре обработки данных.