Назад | Перейти на главную страницу

Параметры файловой системы Linux для общего хранилища iSCSI

Я пытаюсь определить свой «лучший выбор» для файловой системы, которая будет использоваться для общего запоминающего устройства, которое будет монтироваться через iSCSI на неопределенном количестве серверов.

Настроить:

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

Обычно проблем с коллизиями записи на устройстве быть не должно, так как есть только несколько центральных машин, которые могут изменять контент, но я знаю, что если мы монтируем их как таковые, нам нужен какой-то метод для заблокируйте файл во время работы с ним, чтобы не повредить его. В прошлом мы полагались на NFS, чтобы справиться с этим. Итак, теперь я смотрю на файловые системы с поддержкой кластеров (если я чего-то не упускаю, отсюда и этот пост).

Пока что я нашел 2 основных варианта для этого, но я не уверен, что они подходят:

Кластеризация RHEL и GFS2 - кажется естественным, подходящим для моего окружения, но меня немного настораживает, когда я чувствую себя «привязанным» к дистрибутиву таким образом. Это заставит меня придумать другие варианты в будущем, если мне нужно добавить серверы с другим вкусом. Не шоу-стоп, но на мой взгляд. Наибольшее беспокойство вызывает неоднократное чтение документации RHEL о том, что их кластер поддерживает только 16 узлов. Если это так, то для меня он определенно недостаточно хорошо масштабируется. Это верно или я неправильно читаю?

OCFS - кластерная файловая система Oracle также привлекает много внимания, когда я гуглил, но я мало что знаю об этом. Самым неприятным аспектом этого является то, что мне пришлось бы запустить их Unbreakable Enterprise Kernel, что привело бы к большим сбоям при перемещении на него всех моих серверов. Опять же, это не препятствие, но мне нужны неопровержимые доказательства, чтобы пойти по этому пути, особенно при испытании этой методологии.

Я что-то упускаю? Есть ли лучший подход, который я должен использовать? Я даже подумал о полном изменении архитектуры, чтобы позволить нескольким "интерфейсным" серверам смонтировать раздел iSCSI, а затем при необходимости использовать NFS для совместного использования с ними и / или использовать обратный прокси-сервер nginx для передачи носителя веб-серверам. .

Есть какие-нибудь умные идеи, которые ВЫ бы доверили использовать в этом сценарии?

В вашем случае я бы по-прежнему придерживался сетевой файловой системы. Вы уже столкнулись с проблемами масштабирования в NFS, так что пора взглянуть на кое-что еще. Есть несколько хороших вариантов:

  • Gluster. Это проект RH, поэтому он очень хорошо поддерживается в CentOS и масштабируется до "очень большого количества". Сотни / тысячи клиентов вполне выполнимы, особенно в среде с тяжелым чтением, в которой вы, кажется, находитесь. В настоящее время я использую его с Ubuntu, поэтому есть поддержка в debian-land.
  • Ceph. Как и Gluster, это сетевая файловая система нового поколения, которая также обеспечивает возможность прямого монтирования. Также разработан для масштабирования "участков дороги". Он не привязан к Red Hat, как Gluster.

Оба в настоящее время используются в инфраструктуре облачного масштаба.

Файловые системы с прямым монтированием, такие как gfs2 и ocfs, действительно имеют узкие места при масштабировании. Проблема межсистемной блокировки файлов, не говоря уже о когерентности кэша между хостами, довольно сложно решить и является основной проблемой масштабирования. Другие кластерные файловые системы, такие как VMware VMFS, также имеют ограничения по максимальному монтированию "малых десятков" по той же причине.

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

Вы можете использовать гибкое и надежное решение, которое поддерживает кластеризацию, многопутевость, мультиплексирование и кэширование, например VXFS (Veritas Storage Fundation) с SF-CACHE. Если вы улучшите коллизии записи или повреждение файловой системы, можно перестроить файловую систему с помощью повторных журналов VXFS, а также можно восстановить поцарапанную дисковую группу, если есть некоторые аппаратные ошибки lun.

PS: + OCFS разработан для Oracle Cluster DATABASE, а не для веб-приложений!