GFS2 - GFS2

В вычислении , то Global File System 2 или GFS2 является файловой системой разделяемого диска для Linux компьютерных кластеров. GFS2 позволяет всем членам кластера иметь прямой одновременный доступ к одному и тому же общему хранилищу блоков , в отличие от распределенных файловых систем, которые распределяют данные по кластеру. GFS2 также можно использовать как локальную файловую систему на одном компьютере.

GFS2 не имеет автономного режима работы, а также ролей клиента или сервера. Все узлы в кластере GFS2 работают как одноранговые. Для использования GFS2 в кластере требуется оборудование, чтобы разрешить доступ к общему хранилищу, и диспетчер блокировок для управления доступом к хранилищу. Диспетчер блокировок работает как отдельный модуль: таким образом, GFS2 может использовать диспетчер распределенных блокировок (DLM) для конфигураций кластера и диспетчер блокировок «nolock» для локальных файловых систем. Более старые версии GFS также поддерживают GULM, серверный диспетчер блокировок, который реализует избыточность через аварийное переключение.

GFS и GFS2 - бесплатное программное обеспечение , распространяемое на условиях Стандартной общественной лицензии GNU .

История

Разработка GFS началась в 1995 году и изначально была разработана профессором Миннесотского университета Мэтью О'Киф и группой студентов. Первоначально она была написана для SGI «s IRIX операционной системы, но в 1998 году она была портирована на Linux , так как открытый источник кода обеспечивает более удобную платформу для разработки. В конце 1999 - начале 2000 года он попал в Sistina Software , где какое-то время жил как проект с открытым исходным кодом . В 2001 году Sistina сделала выбор в пользу собственного продукта GFS.

Разработчики разделили OpenGFS из последнего общедоступного выпуска GFS, а затем улучшили его, включив обновления, позволяющие работать с OpenDLM. Но OpenGFS и OpenDLM перестали существовать, поскольку Red Hat приобрела Sistina в декабре 2003 года и выпустила GFS и многие компоненты кластерной инфраструктуры под лицензией GPL в конце июня 2004 года.

Впоследствии Red Hat профинансировала дальнейшую разработку, направленную на исправление ошибок и стабилизацию. Дальнейшее развитие GFS2 является производным от GFS и было включено вместе с его распределенным менеджером блокировок (совместно используемым с GFS) в Linux 2.6.19. Red Hat Enterprise Linux 5.2 включила GFS2 в качестве модуля ядра для ознакомительных целей. С обновлением 5.3 GFS2 стал частью пакета ядра.

GFS2 входит в состав Fedora , Red Hat Enterprise Linux и связанных дистрибутивов CentOS Linux. Пользователи могут приобрести коммерческую поддержку для запуска GFS2, полностью поддерживаемого поверх Red Hat Enterprise Linux . Начиная с Red Hat Enterprise Linux 8.3, GFS2 поддерживается в средах облачных вычислений, в которых доступны общие устройства хранения.

В следующем списке перечислены некоторые номера версий и основные представленные функции:

• v1.0 (1996) только SGI IRIX
• v3.0 порт Linux
• v4 ведение журнала
• v5 диспетчер резервных блокировок
• v6.1 (2005) Диспетчер распределенных блокировок
• Linux 2.6.19 - GFS2 и DLM объединены в ядро ​​Linux
• Red Hat Enterprise Linux 5.3 выпускает первую полностью поддерживаемую GFS2

Аппаратное обеспечение

Конструкция GFS и GFS2 ориентирована на среды, подобные SAN . Хотя их можно использовать как файловую систему с одним узлом, для полного набора функций требуется SAN. Это может быть iSCSI , FibreChannel , AoE или любое другое устройство, которое может быть представлено в Linux как блочное устройство, совместно используемое несколькими узлами, например устройство DRBD .

DLM требует IP - сетей на основе которой через связь. Обычно это просто Ethernet , но, опять же, есть много других возможных решений. В зависимости от выбора SAN это можно комбинировать, но обычная практика предполагает использование отдельных сетей для DLM и хранилища.

Для GFS требуется какой-то механизм ограждения . Это требование инфраструктуры кластера, а не самой GFS / GFS2, но оно требуется для всех многоузловых кластеров. Обычные варианты включают выключатели питания и контроллеры удаленного доступа (например, DRAC , IPMI или ILO ). Также могут использоваться виртуальные механизмы ограждения и механизмы ограждения на основе гипервизора. Ограждение используется, чтобы гарантировать, что узел, который, по мнению кластера, отказал, не может внезапно снова начать работать, пока другой узел восстанавливает журнал для отказавшего узла. При необходимости он также может автоматически перезапустить отказавший узел после завершения восстановления.

Отличия от локальной файловой системы

Хотя разработчики GFS / GFS2 стремились максимально точно имитировать локальную файловую систему, существует ряд различий, о которых следует помнить. Некоторые из них связаны с существующими интерфейсами файловой системы, не позволяющими передавать информацию, относящуюся к кластеру. Некоторые из них связаны со сложностью эффективной реализации этих функций в кластерной манере. Например:

• Флок () Системный вызов на СГФ / GFS2 не прерывается с помощью сигналов .
• Fcntl () система F_GETLK вызов возвращает PID любого блокирующего замка. Поскольку это файловая система кластера, этот PID может относиться к процессу на любом из узлов, на которых смонтирована файловая система. Поскольку цель этого интерфейса - разрешить отправку сигнала процессу блокировки, это больше невозможно.
• Аренда не поддерживается модулем блокировки lock_dlm (кластер), но они поддерживаются при использовании в качестве локальной файловой системы.
• dnotify будет работать на основе «того же узла», но его использование с GFS / GFS2 не рекомендуется.
• inotify также будет работать на основе «того же узла» и также не рекомендуется (но в будущем может стать поддерживаться)
• сварка поддерживается только на GFS2

Другое главное отличие, которое разделяют все аналогичные файловые системы кластера, заключается в том, что механизм управления кешем, известный как glocks (произносится как Gee-locks) для GFS / GFS2, оказывает влияние на весь кластер. Каждый индексный дескриптор файловой системы имеет два связанных с ним глока. Один (называемый iopen glock) отслеживает, в каких процессах открыт индексный дескриптор. Другой (глок inode) управляет кешем, относящимся к этому inode. Глок имеет четыре состояния: UN (разблокирован), SH (общий - блокировка чтения), DF (отложенный - блокировка чтения несовместима с SH) и EX (исключительная). Каждый из четырех режимов напрямую соответствует режиму блокировки DLM .

В режиме EX индексному дескриптору разрешено кэшировать данные и метаданные (которые могут быть «грязными», т. Е. Ожидающими обратной записи в файловую систему). В режиме SH индексный дескриптор может кэшировать данные и метаданные, но он не должен быть грязным. В режиме DF индексному дескриптору разрешено кэшировать только метаданные, и, опять же, он не должен быть грязным. Режим DF используется только для прямого ввода / вывода. В режиме UN индексный дескриптор не должен кэшировать какие-либо метаданные.

Чтобы операции, которые изменяют данные или метаданные inode, не мешали друг другу, используется блокировка EX. Это означает, что определенные операции, такие как создание / отключение файлов из одного каталога и запись в один и тот же файл, должны быть, как правило, ограничены одним узлом в кластере. Конечно, выполнение этих операций с нескольких узлов будет работать должным образом, но из-за необходимости частой очистки кешей это будет не очень эффективно.

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

Ведение журнала

GFS и GFS2 являются файловыми системами с журналированием ; GFS2 поддерживает тот же набор режимов журналирования, что и ext3 . В режиме data = writeback в журнал записываются только метаданные. Это единственный режим, поддерживаемый GFS, однако можно включить ведение журнала для отдельных файлов данных, но только когда они имеют нулевой размер. Журналируемые файлы в GFS имеют ряд ограничений, наложенных на них, таких как отсутствие поддержки системных вызовов mmap или sendfile, они также используют дисковый формат, отличный от обычных файлов. Существует также атрибут "наследование журнала", который при установке в каталоге заставляет все файлы (и подкаталоги), созданные в этом каталоге, иметь установленный флаг журнала (или наследования журнала, соответственно). Его можно использовать вместо параметра монтирования data = journal, который поддерживает ext3 (а GFS / GFS2 нет).

GFS2 также поддерживает режим « данные = упорядоченный », который аналогичен режиму « данные = обратная запись», за исключением того, что «грязные» данные синхронизируются перед завершением каждой очистки журнала. Это гарантирует, что содержимое блоков, которые были добавлены в индексный дескриптор, будет синхронизировано с диском до того, как метаданные будут обновлены для записи нового размера, и, таким образом, предотвращает появление неинициализированных блоков в файле в условиях сбоя узла. Режим ведения журнала по умолчанию - данные = упорядоченный , что соответствует режиму по умолчанию ext3 .

По состоянию на 2010 год GFS2 еще не поддерживает режим data = journal , но он (в отличие от GFS) использует один и тот же дисковый формат как для обычных, так и для журналируемых файлов, а также поддерживает те же атрибуты журналируемого и наследуемого журнала. GFS2 также ослабляет ограничения на то, когда для файла может быть изменен свой журнал регистрации в любое время, когда файл не открыт (также то же, что и ext3 ).

По соображениям производительности каждый узел в GFS и GFS2 имеет свой собственный журнал. В GFS журналы - это размеры диска, в GFS2 журналы - это просто обычные файлы. Количество узлов, которые могут монтировать файловую систему в любой момент времени, ограничено количеством доступных журналов.

Особенности GFS2 по сравнению с GFS

GFS2 добавляет ряд новых функций, которых нет в GFS. Вот краткое изложение тех функций, которые еще не упоминались в полях справа на этой странице:

• Файловая система метаданных (на самом деле другой корень) - см. Совместимость и метафайловая система GFS2 ниже
• Специфические точки трассировки GFS2 доступны начиная с ядра 2.6.32.
• Интерфейс квот в стиле XFS доступен в GFS2, начиная с ядра 2.6.33.
• Кэширующие списки управления доступом доступны в GFS2 с версии 2.6.33.
• GFS2 поддерживает создание запросов на сброс для запросов Thin Provisioning / SCSI TRIM.
• GFS2 поддерживает барьеры ввода-вывода (по умолчанию включены, если их поддерживает базовое устройство. Настраивается начиная с ядра 2.6.33 и выше).
• FIEMAP ioctl (для запроса сопоставлений inode на диске)
• Поддержка Splice (системный вызов)
• Поддержка mmap / splice для журналируемых файлов (включается при использовании того же формата на диске, что и для обычных файлов)
• Гораздо меньше настроек (упрощая настройку)
• Упорядоченный режим записи (согласно ext3, GFS имеет только режим обратной записи)

Совместимость и метафайловая система GFS2

GFS2 был разработан таким образом, чтобы обновление с GFS было простой процедурой. С этой целью большая часть структуры на диске осталась такой же, как GFS, включая порядок байтов с прямым порядком байтов. Однако есть несколько отличий:

• GFS2 имеет «метафайловую систему», через которую процессы обращаются к системным файлам.
• GFS2 использует тот же дисковый формат для журналируемых файлов, что и для обычных файлов.
• GFS2 использует обычные (системные) файлы для журналов, тогда как GFS использует специальные экстенты.
• В GFS2 есть и другие системные файлы " per_node "
• Макет inode (очень немного) отличается
• Компоновка непрямых блоков немного отличается

Системы журналирования GFS и GFS2 несовместимы друг с другом. Обновление возможно с помощью инструмента ( gfs2_convert ), который запускается с файловой системой в автономном режиме для обновления метаданных. Некоторые запасные блоки в журналах GFS используются для создания (очень маленьких) файлов per_node, необходимых GFS2 в процессе обновления. Большая часть данных остается на месте.

«Мета-файловая система» GFS2 - это не файловая система сама по себе, а альтернативный корень основной файловой системы. Хотя она ведет себя как «обычная» файловая система, ее содержимым являются различные системные файлы, используемые GFS2, и обычно пользователям не нужно даже смотреть на нее. Утилиты GFS2 монтируют и размонтируют метафайловую систему по мере необходимости за кулисами.

Смотрите также

• Сравнение файловых систем
• GPFS , ZFS , VxFS
• Блеск
• GlusterFS
• Список файловых систем
• OCFS2
• QFS
• Файловая система SAN
• Фехтование
• Открытый общий корень
• Ceph (программное обеспечение)

использованная литература

внешние ссылки

• Red Hat Red Hat Enterprise Linux 6 - Глобальная файловая система 2
• Страница документации Red Hat Cluster Suite и GFS
• Страница проекта GFS
• Страница проекта OpenGFS (устарело)
• Дерево git разработки GFS2
• Дерево git разработки утилит GFS2