Параметры файловой системы Linux для общего хранилища iSCSI
Я пытаюсь определить свой "лучший выбор" для файловой системы, которая будет использоваться для совместно используемого устройства хранения, которое будет монтироваться через iSCSI на неопределенное количество серверов.
Настроить:
- Массив Synology RS2212+ 27 ТБ, iSCSI LUN/target, позволяющий проводить несколько сеансов
- Linux-боксы на базе 10-20 CentOS, прежде всего веб-серверы
- В общем хранилище будет размещаться статический веб-контент (медиа, в основном изображения)
По сути, мне нужно иметь возможность монтировать этот большой общий том на многие веб-серверы, и, надеюсь, со временем их число будет расти. В прошлом мы использовали NFS, но проблемы с производительностью заставляют нас искать другие методы. (читай: настройка NFS иногда кажется чёрной магией, особенно при работе с миллионами маленьких изображений).
Как правило, не должно быть проблем с конфликтами записи на устройстве, так как есть только несколько центральных машин, которые могут изменять содержимое, но я знаю, что если мы монтируем их как таковые, нам нужен какой-то метод для заблокируйте файл, пока кто-то с ним работает, чтобы не допустить повреждения. В прошлом мы полагались на NFS, чтобы справиться с этим. Так что теперь я смотрю на файловые системы с поддержкой кластеров (если я что-то упустил, отсюда и этот пост).
До сих пор я нашел 2 основных варианта для этого, но я не уверен, что они идеально подходят:
RHEL Clustering и GFS2 - кажется естественным приспособлением для моей среды, но это заставляет меня немного опасаться чувствовать себя таким образом "запертым" в дистрибутиве. Вынудил бы меня придумать другие варианты в будущем, если мне нужно добавить серверы с другим вкусом. Не шоу-стоппер, но на мой взгляд. Наибольшую озабоченность вызывает повторное чтение из документов RHEL того, что их кластер поддерживает только 16 узлов. Если это так, то это определенно не будет достаточно хорошо масштабироваться для меня. Это верно, или я читаю это неправильно?
OCFS - Кластерная файловая система Oracle также привлекает большое внимание, когда я работаю в Google, но я мало что знаю об этом. Самым неприятным аспектом этого является то, что мне придется запустить их Unbreakable Enterprise Kernel, что приведет к серьезным сбоям при перемещении всех моих серверов к этому. Опять же, не ограничитель показа, но мне нужны убедительные доказательства, чтобы пойти по этому пути, особенно при испытании этой методологии.
Я что-то пропустил? Есть ли лучший подход, который я должен использовать? Я даже подумал о том, чтобы полностью изменить архитектуру, чтобы несколько "интерфейсных" серверов могли смонтировать раздел iSCSI, а затем по мере необходимости делиться с ними NFS и / или использовать обратный прокси-сервер nginx для передачи мультимедиа веб-серверам.,
Есть какие-нибудь умные идеи, которым вы доверяете, используя этот сценарий?
2 ответа
Для вашего случая я бы все еще придерживался сетевой файловой системы. Вы уже столкнулись с проблемами масштабирования с NFS, поэтому пришло время взглянуть на что-то еще. Есть несколько хороших вариантов:
- Гластер Это RH-проект, поэтому он очень хорошо поддерживается в CentOS и масштабируется до "большого количества". Сотни / тысячи клиентов вполне выполнимы, особенно в среде с интенсивным чтением, в которой вы, похоже, находитесь. В настоящее время я использую его с Ubuntu, поэтому поддержка в debian-land есть.
- Ceph. Как и Gluster, это сетевая файловая система следующего поколения, которая также обеспечивает возможность прямого монтирования. Также предназначен для масштабирования "way lot". Он не привязан к Red Hat, как Gluster.
Оба в настоящее время используются в облачной инфраструктуре.
Файловые системы прямого монтирования, такие как gfs2 и ocfs, действительно, действительно имеют узкие места для масштабирования. Проблема межсистемной блокировки файлов, не говоря уже о межсистемной когерентности кэша, довольно сложна для решения и является основной проблемой масштабирования. Другие кластерные файловые системы, такие как VMFS VMware, также имеют максимальные ограничения на монтирование по "маленькой десятке" по той же причине.
Сетевые файловые системы, которые не являются NFS, были разработаны для масштабирования до очень большого числа параллелизмов. Варианты, о которых я упомянул выше, имеют дублирование и даже поддержку распределенных томов, чтобы помочь предотвратить одиночные точки отказа.
Вы можете использовать гибкое и надежное решение, которое поддерживает кластеризацию, многолучевое распространение, мультиплексирование и кэш, например VXFS (Veritas Storage Fundation) с SF-CACHE. Если вы улучшите запись коллизий или повреждение fs, можно перестроить файловую систему с помощью редологов VXFS, а также возможно перестроить поцарапанную дисковую группу, если возникнут некоторые аппаратные ошибки.
PS: + OCFS предназначена для базы данных Oracle Cluster, а не для веб-приложений!