СГФ2
| Разработчик(и) | Красная шляпа |
|---|---|
| Полное имя | Глобальная файловая система 2 |
| Представлено | 2005 г. с Linux 2.6.19 |
| Структуры | |
| Содержимое каталога | Хешированные (небольшие каталоги, помещенные в индексный дескриптор) |
| Распределение файлов | растровое изображение (группы ресурсов) |
| Плохие блоки | Нет |
| Пределы | |
| Макс нет. файлов | Переменная |
| Максимальная длина имени файла | 255 байт |
| Разрешенное имя файла персонажи | Все, кроме NUL |
| Функции | |
| Даты записи | модификация атрибута (ctime), модификация (mtime), доступ (atime) |
| Разрешение даты | наносекунда |
| Атрибуты | Нет времени, журналируемые данные (только обычные файлы), наследование журналируемых данных (только каталоги), синхронная запись, только добавление, неизменяемые, exhash (только каталоги, только чтение) |
| Файловая система разрешения | Разрешения Unix, списки ACL и произвольные атрибуты безопасности |
| Прозрачный сжатие | Нет |
| Прозрачный шифрование | Нет |
| Дедупликация данных | только между узлами |
| Другой | |
| Поддерживается операционные системы | Линукс |
| Разработчик(и) | Red Hat (ранее Sistina Software ) |
|---|---|
| Полное имя | Глобальная файловая система |
| Представлено | 1996 г. с IRIX (1996 г.), Linux (1997 г.) |
| Структуры | |
| Содержимое каталога | Хешированные (небольшие каталоги, помещенные в индексный дескриптор) |
| Распределение файлов | растровое изображение (группы ресурсов) |
| Плохие блоки | Нет |
| Пределы | |
| Макс нет. файлов | Переменная |
| Максимальная длина имени файла | 255 байт |
| Разрешенное имя файла персонажи | Все, кроме NUL |
| Функции | |
| Даты записи | модификация атрибута (ctime), модификация (mtime), доступ (atime) |
| Разрешение даты | 1 с |
| Атрибуты | Нет времени, журналируемые данные (только обычные файлы), наследование журналируемых данных (только каталоги), синхронная запись, только добавление, неизменяемые, exhash (только каталоги, только чтение) |
| Файловая система разрешения | Разрешения Unix, ACL |
| Прозрачный сжатие | Нет |
| Прозрачный шифрование | Нет |
| Дедупликация данных | только между узлами |
| Другой | |
| Поддерживается операционные системы | IRIX (устарело), FreeBSD (устарело), Linux |
В вычислительной технике Глобальная файловая система 2 или GFS2 представляет собой файловую систему с общим диском для Linux компьютерных кластеров . GFS2 позволяет всем членам кластера иметь прямой одновременный доступ к одному и тому же общему блочному хранилищу , в отличие от распределенных файловых систем , которые распределяют данные по всему кластеру. GFS2 также можно использовать в качестве локальной файловой системы на одном компьютере.
GFS2 не имеет отключенного режима работы и ролей клиента или сервера. Все узлы в кластере GFS2 функционируют как одноранговые. Для использования GFS2 в кластере требуется оборудование , обеспечивающее доступ к общему хранилищу, а также диспетчер блокировок для управления доступом к хранилищу.Менеджер блокировок работает как отдельный модуль: таким образом, GFS2 может использовать диспетчер распределенных блокировок (DLM) для конфигураций кластера и менеджер блокировок «nolock» для локальных файловых систем. Более старые версии GFS также поддерживают GULM, серверный менеджер блокировок, который реализует избыточность посредством аварийного переключения.
GFS и GFS2 являются бесплатными программами , распространяемыми на условиях GNU General Public License . [1] [2]
История
[ редактировать ]Разработка GFS началась в 1995 году и первоначально была разработана профессором Университета Миннесоты Мэтью О'Кифом и группой студентов. [3] Первоначально он был написан для SGI от операционной системы IRIX , но в 1998 году был портирован на Linux (2.4). [4] поскольку открытый исходный код обеспечивает более удобную платформу для разработки. В конце 1999 — начале 2000 года он попал в Sistina Software , где какое-то время существовал как проект с открытым исходным кодом . В 2001 году Sistina приняла решение сделать GFS запатентованным продуктом.
Разработчики создали ответвление OpenGFS из последней общедоступной версии GFS, а затем усовершенствовали ее, включив обновления, позволяющие работать с OpenDLM. Но OpenGFS и OpenDLM перестали существовать, поскольку Red Hat приобрела Sistina в декабре 2003 года и выпустила GFS и многие части кластерной инфраструктуры под лицензией GPL в конце июня 2004 года.
Впоследствии Red Hat профинансировала дальнейшую разработку, направленную на исправление ошибок и стабилизацию. Дальнейшее развитие, GFS2 [5] [6] происходит от 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 поддерживается в средах облачных вычислений , в которых доступны общие устройства хранения. [7]
В следующем списке приведены некоторые номера версий и основные представленные функции:
- v1.0 (1996) SGI IRIX только
- Linux-порт v3.0
- 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/GFS2, но оно необходимо для всех многоузловых кластеров. Обычные варианты включают выключатели питания и контроллеры удаленного доступа (например, DRAC , IPMI или ILO ). Также можно использовать механизмы ограждения на основе виртуальных и гипервизоров. Ограждение используется для того, чтобы гарантировать, что узел, который, по мнению кластера, вышел из строя, не сможет внезапно возобновить работу, пока другой узел восстанавливает журнал для вышедшего из строя узла. Он также может автоматически перезапустить вышедший из строя узел после завершения восстановления.
Отличия от локальной файловой системы
[ редактировать ]Хотя разработчики GFS/GFS2 стремились максимально точно имитировать локальную файловую систему, существует ряд отличий, о которых следует знать. Некоторые из них связаны с тем, что существующие интерфейсы файловой системы не позволяют передавать информацию, относящуюся к кластеру. Некоторые из них связаны с трудностью эффективной реализации этих функций в кластерном порядке. Например:
- Системный вызов flock () в GFS/GFS2 не прерывается сигналами .
- Системный вызов fcntl () F_GETLK возвращает PID любой блокирующей блокировки. Поскольку это кластерная файловая система, этот PID может относиться к процессу на любом из узлов, на которых смонтирована файловая система. Поскольку цель этого интерфейса — разрешить отправку сигнала процессу блокировки, это больше невозможно.
- Аренда не поддерживается модулем блокировки lock_dlm (кластер), но поддерживается при использовании в качестве локальной файловой системы.
- dnotify будет работать на «том же узле», но его использование с GFS/GFS2 не рекомендуется.
- inotify также будет работать на основе «того же узла» и не рекомендуется (но может поддерживаться в будущем)
- сращивание поддерживается только в GFS2.
Другое основное отличие, которое характерно для всех подобных кластерных файловых систем, заключается в том, что механизм управления кэшем, известный как Glocks (произносится как Gee-locks) для GFS/GFS2, действует на весь кластер. С каждым индексным дескриптором файловой системы связаны два глока. Один (называемый iopen glock) отслеживает, у каких процессов открыт индексный дескриптор. Другой (блок индексного дескриптора) управляет кэшем, относящимся к этому индексному дескриптору. Глок имеет четыре состояния: UN (разблокирован), SH (общий — блокировка чтения), DF (отложенный — блокировка чтения, несовместимая с SH) и EX (эксклюзивный). Каждый из четырех режимов напрямую соответствует режиму блокировки DLM .
В режиме EX индексному дескриптору разрешено кэшировать данные и метаданные (которые могут быть «грязными», т. е. ожидать обратной записи в файловую систему). В режиме SH индексный дескриптор может кэшировать данные и метаданные, но он не должен быть «грязным». В режиме DF индексному дескриптору разрешено кэшировать только метаданные, и он также не должен быть «грязным». Режим DF используется только для прямого ввода-вывода. В режиме UN индексный дескриптор не должен кэшировать метаданные.
Чтобы операции, изменяющие данные или метаданные индексного дескриптора, не мешали друг другу, используется блокировка EX. Это означает, что некоторые операции, такие как создание/отключение файлов из одного и того же каталога и запись в один и тот же файл, обычно должны быть ограничены одним узлом в кластере. Конечно, выполнение этих операций с нескольких узлов будет работать, как и ожидалось, но из-за необходимости частой очистки кэшей это будет не очень эффективно.
Единственный наиболее часто задаваемый вопрос о производительности GFS/GFS2 — почему производительность почтовых серверов может быть низкой. Решение состоит в том, чтобы разбить почтовую очередь на отдельные каталоги и попытаться сохранить (насколько это возможно) чтение и запись каждого узла в частный набор каталогов.
Ведение журнала
[ редактировать ]GFS и GFS2 являются журналируемыми файловыми системами ; и GFS2 поддерживает тот же набор режимов журналирования, что и ext3 . В режиме data=writeback регистрируются только метаданные. Это единственный режим, поддерживаемый GFS, однако можно включить ведение журнала для отдельных файлов данных, но только если они имеют нулевой размер. Журналируемые файлы в GFS имеют ряд ограничений, таких какнет поддержки системных вызовов mmap или sendfile, они также используют формат диска, отличный от обычных файлов. Существует также атрибут «inherit-journal», который при установке в каталоге приводит к тому, что для всех файлов (и подкаталогов), созданных в этом каталоге, будет установлен флаг журнала (или inherit-journal соответственно). Это можно использовать вместо data=journal опции монтирования , которую поддерживает ext3 (а GFS/GFS2 — нет).
GFS2 также поддерживает режим data=ordered , который аналогичен data=writeback, за исключением того, что «грязные» данные синхронизируются перед завершением каждого обновления журнала. Это гарантирует, что блоки, добавленные в индексный дескриптор, будут синхронизировать свое содержимое обратно на диск до того, как метаданные будут обновлены для записи нового размера, и, таким образом, предотвращает появление неинициализированных блоков в файле в условиях сбоя узла. Режим ведения журнала по умолчанию — data=ordered , что соответствует режиму ext3 по умолчанию.
По состоянию на 2010 год [update], GFS2 пока не поддерживает режим data=journal , но он (в отличие от GFS) использует один и тот же дисковый формат как для обычных, так и для журналируемых файлов, а также поддерживает одни и те же атрибуты журналируемого и наследуемого журнала. GFS2 также ослабляет ограничения на то, когда журналируемый атрибут файла может быть изменен на любое время, когда файл не открыт (также аналогично ext3 ).
По соображениям производительности каждый узел в GFS и GFS2 имеет собственный журнал. В GFS журналы представляют собой дисковые экстенты, в GFS2 журналы представляют собой обычные файлы. Количество узлов, которые могут одновременно монтировать файловую систему, ограничено количеством доступных журналов.
Особенности GFS2 по сравнению с GFS
[ редактировать ]В GFS2 добавлен ряд новых функций, которых нет в GFS. Вот краткое изложение тех функций, которые еще не упомянуты в полях справа на этой странице:
- Файловая система метаданных (на самом деле другой корень) — см. «Совместимость и файловая система метаданных GFS2» ниже.
- Особые точки трассировки GFS2 доступны начиная с ядра 2.6.32.
- Интерфейс квот в стиле XFS доступен в GFS2 начиная с ядра 2.6.33.
- Списки ACL кэширования доступны в GFS2 с версии 2.6.33.
- GFS2 поддерживает генерацию запросов на «отбрасывание» для запросов «тонкого обеспечения»/SCSI TRIM.
- GFS2 поддерживает барьеры ввода-вывода (по умолчанию включено, если базовое устройство его поддерживает. Настраивается начиная с ядра 2.6.33 и выше)
- FIEMAP ioctl (для запроса сопоставлений индексных дескрипторов на диске)
- сплайсинга (системного вызова) Поддержка
- поддержка mmap/splice для журналируемых файлов (включается при использовании того же формата диска, что и для обычных файлов)
- Гораздо меньше настроек (что делает настройку менее сложной)
- Режим упорядоченной записи (согласно ext3, GFS имеет только режим обратной записи)
Совместимость и метафайловая система GFS2.
[ редактировать ]GFS2 был разработан таким образом, чтобы обновление GFS было простой процедурой. С этой целью большая часть структуры на диске осталась такой же, как в GFS, включая обратный порядок байтов. Однако есть несколько отличий:
- GFS2 имеет «мета-файловую систему», через которую процессы получают доступ к системным файлам.
- GFS2 использует тот же дисковый формат для журналируемых файлов, что и для обычных файлов.
- GFS2 использует обычные (системные) файлы для журналов, тогда как GFS использует специальные экстенты.
- В GFS2 есть некоторые другие " per_node " системные файлы
- Расположение индексного дескриптора (очень немного) отличается
- Компоновка косвенных блоков немного отличается
Системы журналирования GFS и GFS2 несовместимы друг с другом. Обновление возможно с помощью инструмента ( gfs2_convert ), который запускается в автономном режиме файловой системы для обновления метаданных. Некоторые запасные блоки в журналах GFS используются для создания (очень маленьких) файлы per_node, необходимые GFS2 в процессе обновления. Большая часть данных остается на месте.
«Метафайловая система» GFS2 сама по себе не является файловой системой, а представляет собой альтернативный корень основной файловой системы. Хотя она ведет себя как «обычная» файловая система, ее содержимым являются различные системные файлы, используемые GFS2, и обычно пользователям не нужно ее просматривать. Утилиты GFS2 монтируют незаметно и размонтируют метафайловую систему.
См. также
[ редактировать ]
- Сравнение файловых систем
- GPFS , ZFS , VxFS
- Блеск
- ГлюстерФС
- Список файловых систем
- OCFS2
- КФС
- файловая система SAN
- Фехтование
- Открытый общий корень
- Цеф (программное обеспечение)
Ссылки
[ редактировать ]- ^ Тейгланд, Дэвид (29 июня 2004 г.). «Симметричная кластерная архитектура и технические характеристики компонентов» (PDF) . Компания Red Hat Inc. Проверено 3 августа 2007 г.
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ Солтис, Стивен Р.; Эриксон, Грант М.; Преслан, Кеннет В. (1997). «Глобальная файловая система: файловая система для общего дискового хранилища» (PDF) . Транзакции IEEE в параллельных и распределенных системах . Архивировано из оригинала (PDF) 15 апреля 2004 г.
- ^ Совместное использование данных OpenGFS с кластером хранения GFS.
- ^ Дэниел Роббинс (1 сентября 2001 г.). «Общие темы: Руководство по внедрению расширенной файловой системы, часть 3» . IBM DeveloperWorks . Архивировано из оригинала 3 февраля 2012 г. Проверено 15 февраля 2013 г.
- ^ Уайтхаус, Стивен (27–30 июня 2007 г.). «Файловая система GFS2» (PDF) . Материалы симпозиума Linux 2007 . Оттава, Онтарио , Канада. стр. 253–259.
- ^ Уайтхаус, Стивен (13–17 июля 2009 г.). «Тестирование и проверка кластерных файловых систем» (PDF) . Материалы симпозиума Linux 2009 . Монреаль, Квебек , Канада. стр. 311–317.
- ^ «Перенос отказоустойчивого хранилища Red Hat в общедоступное облако» . www.redhat.com . Проверено 19 февраля 2021 г.