GPFS. Часть 1. Создание GPFS кластера
После одной из моих последних статьей на хабре про серверную оптимизацию мне прислали множество вопросов про распределенные файловые системы. И теперь я нашел в себе силы и возможности написать про замечательную кластерную файловую систему GPFS.
- Сервер виртуализации Xen. Dom0 под SLES11
- 3 Xen DomU виртуальных сервера под quorum-ноды с двумя дополнительно проброшенными блочными устройствами
- 2 Xen DomU виртуальных сервера под client-ноды
Создание кластера GPFS
Делится на следующие этапы:
Лицензирование GPFS
Лицензирование в GPFS достаточно непростое. В версии 3.3 наконец-то сделали разделение между серверной и клиентской частью, и теперь за «клиента» можно платить меньше. Для клиентской и серверной части назначается разное количество Processor Value Units, и стоят эти PVU для клиентской и серверной частей по-разному. Подсчитать PVU для вашего кластера вы можете здесь. Более подробную информацию и part number gpfs можно получить из следующего документа. Купить GPFS можно у любого авторизованного реселлера IBM.
- Выбор типа дисков (NAS/SAN или Directly Attached)
- Выбор сетевой инфраструктуры (Gigabit Ethernet/Fibre Channel/InfiniBand)
- Также стоит продумать структуру будущего GPFS-кластера
Тут всё просто. Покупаем, устанавливаем на все ноды, которые планируют использовать GPFS.
Создание кластера (mmcrcluster)
Связываем все ноды так, чтобы каждая нода имела беспарольный доступ к любой другой, включая и саму себя :). Далее инициализируем сам кластер.
Тюнинг параметров GPFS (mmchconfig)
Увеличиваем лимиты, включаем использование InfiniBand verbs и т.д. и т.п.
Запуск GPFS (mmstartup)
Благодаря тому, что все ноды имеют доступ на все остальные, большую часть работы они выполняют сами, будь то добавление сервиса в автозагрузку или же настройка fstab’а.
Создание NSD — Network Shared Disk (mmcrnsd)
Так как я использую топологию с Directly Connected дисками, то я не могу использовать tiebreaker-диск. Поэтому просто экспортирую все диски которые есть в системах, разделив их на 3 Failre-группы.
Создание файловой системы поверх NSD (mmcrfs)
При создании файловой системы можно указывать множество различных параметров, которые в дальнейшем будут влиять на быстродействие и отказоустойчивость системы.
Монтирование GPFS (mmmount)
Всё готово, монтируем файловую систему и можно начинать работать.
Структура нашего обучающего миникластера
У нас будет 3 Failover-группы:
1 — DataAndMetadata — Данные и Метаданные (primary):
диски gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local
2 — DataAndMetadata — Данные и Метаданные (backup):
диски gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local
3 — DescOnly — Реплика дескриптора (aka system descriptor) GPFS. Тут не хранятся ни данные, ни метаданные, диск предназначен только для сохранения quorum’а в случае потери основной реплики дескриптора:
диск gpfs02.edu.scalaxy.local
Создание кластера
Начнём с установки переменной окружения $PATH:
Далее создадим файл с нодами и их ролями:
# cat <<EOF >>gpfs.nodes
gpfs00.edu.scalaxy.local:quorum-manager:
gpfs01.edu.scalaxy.local:quorum-manager:
gpfs02.edu.scalaxy.local:quorum-client:
gpfs03.edu.scalaxy.local:client:
gpfs04.edu.scalaxy.local:client:
EOF
manager | client — Indicates whether a node is part of the node pool from which file system managers and token managers can be selected. The default is client.
quorum | nonquorum — Indicates whether a node is counted as a quorum node. The default is nonquorum.
gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local у нас будут участвовать в выборах manager’а (quorum-нод)
gpfs02.edu.scalaxy.local будет хранить реплику дескриптора GPFS
gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local будут клиентами, которые читают/пишут на GPFS
# mmcrcluster -N gpfs.nodes -p gpfs00.edu.scalaxy.local -s gpfs01.edu.scalaxy.local -r /usr/bin/ssh -R /usr/bin/scp -C gpfs-cluster -A
-N gpfs.nodes — имя файла с нодами (также можно передать разделённый запятыми список)
-p gpfs00.edu.scalaxy.local — primary-нода, на которой хранится конфигурация кластера
-s gpfs01.edu.scalaxy.local — secondary-нода, на которой хранится конфигурация кластера
-r /usr/bin/ssh — бинарник для удалённого выполнения команд на удалённом сервере
-R /usr/bin/scp — бинарник для безопасного копирования файлов на удалённый сервер
-C gpfs-cluster — имя для будущего кластера
-A — автоматически запускать на нодах gpfs-демон
Primary / Secondary ноды хорошо описаны в man’е:
It is suggested that you specify a secondary GPFS cluster configuration server to prevent the loss of configuration data in the event your primary GPFS cluster configuration server goes down. When the GPFS daemon starts up, at least one of the two GPFS cluster configuration servers must be accessible.
If your primary GPFS cluster configuration server fails and you have not designated a secondary server, the GPFS cluster configuration files are inaccessible, and any GPFS administration commands that are issued fail. File system mounts or daemon startups also fail if no GPFS cluster configuration server is available.
На основном кластере применяется примерно такой тюнинг для GPFS (подробнее):
У mmchconfig есть опция -I которая говорит ему применить параметры, но не сохранять их на диск. Весьма полезна при тестах, а также рискованных операциях.
maxFilesToCache — количество файлов для кэширования. Лучше выставлять сразу максимальное значение — 1000000.
maxMBpS — ограничение GPFS на ввод-вывод с одной ноды. Лучше выключить, выставив очень большое значение.
pagepool — на нодах с дисками отдается вся память, оставляя
500Mb под систему.
verbsPorts — имя HCA и номер порта для использования verbs — только при наличии InfiniBand. Можно указывать сразу несколько портов через пробел, тогда GPFS создаст несколько RDMA-коннектов.
verbsRdma — enable — только при наличии InfiniBand, иначе disable.
worker1Threads — количество запросов, обслуживаемых одновременно. Максимум 500 для 64 битных систем.
nsdthreadsperdisk — недокументированный параметр, определяет количество потоков, обслуживающих каждый диск.
Менее употребляемые параметры:
cipherList — GPFS может шифровать данные при их передаче и безопасно аутентифицировать ноды.
pagepoolMaxPhysMemPct — максимальный процент памяти который может быть выделен под PagePool.
unmountOnDiskFail — если стоит в no, то в случае смерти диска на ноде GPFS продолжит нормально работать. В no рекомендуют ставить в случае, если используется реплицирование данных и метаданные (-m -M -r -R в mmcrfs). Если выставить в yes, то GPFS-раздел, содержащий этот диск, будет отмонтирован на локальной машине в случае гибели диска. Остальные же ноды продолжат (если смогут) функционировать в штатном режиме. Данный вариант рекомендуется для SAN-стораджей и DescOnly-дисков.
Теперь небольшое лирическое отступление — в GPFS документация делится две части:
Официальная (aka external documented) — это та, что выкладывается в интернете и в man’ах.
Неофициальная (aka internal documented) — та, что написана в комментариях в shell-скриптах mm* (да-да, почти все команды gpfs это shell скрипты. По сути, 99% команд, лишь обертки к низкоуровневым сишным прожкам, которые являются лишь интерфейсом к функциям демона mmfsd. Весь функционал в демоне.)
Про internal документацию написано следующее: configuration parameters to be used only under the direction of IBM service
Но мы не из робких, так что можно смело искать всякие крутилки в /usr/lpp/mmfs/bin/mmchconfig и тестировать их в работе.
Запуск GPFS
Итак, после того как мы создали ноды, можно дистанционно на всех машинах запустить gpfs (заметьте, что большинство команд я выполняю на машине gpfs00, а они, в свою очередь, применяются на всём кластере):
Далее выставляем нодам нужный тип лицензий.
Одна часть у нас будет серверами:
# mmchlicense server —accept -N gpfs00.edu.scalaxy.local,gpfs01.edu.scalaxy.local,gpfs02.edu.scalaxy.local
# mmchlicense client —accept -N gpfs04.edu.scalaxy.local,gpfs03.edu.scalaxy.local
Создание NSD — Network Shared Disk
Теперь создаём файл с описанием дисков и их содержимого:
Формат файла таков:
DiskName — для Unix-систем — имя блочного устройства.
ServerList — список серверов, с которых доступен этот диск. Можно указать до восьми серверов, из которых будет выбран первый работоспособный. В нашем случае, где не используется SAN, это всего один сервер — тот, к которому подключён этот диск. Если не указать ничего, то GPFS будет считать, что диск доступен всем нодам кластера.
DiskUsage — dataAndMetadata|dataOnly|metadataOnly|descOnly варианты говорят сами за себя, да и в мануале более подробное объяснение, разве что у descOnly, который я описывал выше.
FailureGroup — группа, к которой принадлежит диск. GPFS использует эту информацию, раскладывая данные и метаданные так, чтобы при единичном отказе обе реплики не погибли. То есть, например, диски, подключённые к одному контроллеру, к одному серверу или находящиеся в одном датацентре, принадлежат одной Failure-группе.
DesiredName — имя, которое мы хотим присвоить nsd. Должно попадать под регексп /[A-Za-Z0-9_]+/. По дефолту — gpfsNNnsd, где NN — целое, положительное, уникальное среди других nsd число.
StoragePool — имя Storage Pool’а, которое потом без изменений передаётся на mmcrfs.
Таже рекомендую прочитать более подробно о mmcrnsd
# mmcrnsd -F gpfs.disks -v no
Создание FS поверх NSD
После удачного завершения mmcrnsd файл gpfs.disks модифицируется для дальнейшего использования командой mmcrfs:
Далее идёт команда mmcrfs, к ней нужно отнестись весьма серьёзно, ибо она имеет множество параметров, каждый из которых влияет как на функциональность, так и на производительность GPFS, а после её создания изменить часть из них будет уже нереально.
# mmcrfs gpfs0 -F gpfs.disks -A yes -B 1M -E no -S yes -m 2 -M 2 -r 2 -R 2 -T /gpfs-storage
Подробнее о некоторых параметрах mmcrfs:
-A — автомонтирование GPFS при загрузке сервера. automount монтирует GPFS при первом обращении (на Linux, на Windows аналогично yes).
-B — размер блока — это минимальная единица аллокации GPFS. Он может быть равен 16 KB, 64 KB, 128 KB, 256 KB (default), 512 KB, 1 MB, 2 MB или 4 MB. Минимальный размер файла на диске это 1/32 размера блока. Также, размер блока является максимальным размером read/write request’а.
Рекомендуют подстраивать размер блока под размер strip’а на raid’е или же под размеры буферов приложений.
Документация предлагает использовать больший размер блока для увеличения производительности sequential read and write, а маленький для small random read and write и metadata-intensive-сценариев.
В pagepool данные кешируются также блоками, то есть, при увеличении размера блока, желательно также поднять размер пула.
Размер блока не может превышать maxblocksize, который по умолчанию равен 1MB. Изменить maxblocksize можно командой mmchconfig.
-D — схема блокировок. Если GPFS планирует отдаваться через nfs4 или samba, то нужно использовать nfs4, если GPFS будет отдаваться по NFS3 или же не будет экспортироваться никак, то лучше использовать posix.
-j — метод выделения блоков для файла. Для больших инсталляций лучше использовать scatter, для маленьких cluster. Подробнее в мануале.
-L — размер логфайла. Варьируется от 256kb до 16MB. Стоит поднимать на высоконагруженых файловых системах и при большом количестве метаданных.
-N NumInodes[:NumInodesToPreallocate] — количество inodes. Поддерживаются суффиксы, i.e. 10M
-r DefaultDataReplicas — количество реплик для данных файла по умолчанию. Не может быть больше, чем MaxDataReplicas. По умолчанию значение равно «1».
-R MaxDataReplicas — максимальное количество реплик, которое можно задать через mmchattr
-m DefaultMetadataReplicas — аналогично -r
-M MaxMetadataReplicas — аналогично -r
-E no — не выполнять realtime-обновление mtime-файлов (чаще всего это не нужно)
-S yes — запретить обновление atime. При включении функции gpfs_stat(), gpfs_fstat(), stat() и fstat() отдают atime равное ctime.
-T /gpfs-storage — точка монтирования, по-умолчанию DefaultMountDir/Device, DefaultMountDir = /gpfs
Если при создании файловой системы вы не включили автомаунт, то придётся примонтировать его вручную (подробнее).
Монтирование GPFS
# mmmount gpfs0 -a
Вот, в принципе, и все, что я хотел рассказать о настройке GPFS. На днях я планирую написать продолжение этой статьи, в которой будет рассказано про эксплуатацию GPFS-кластера.
Русские Блоги
Первый взгляд на файловую систему GPFS Первый взгляд на файловую систему GPFS
Сначала посмотрите на файловую систему GPFS
Укажите источник!
Во-первых, что такое файловая система GPFS
Общая параллельная файловая система (GPFS) — это высокопроизводительная, масштабируемая параллельная файловая система, созданная на основе технологии виртуальных общих дисков (VSD), используемой в системе IBM SP. Файловая система GPFS гарантирует, что все узлы в группе ресурсов могут получить доступ ко всей файловой системе параллельно, а файлы в файловой системе могут быть распределены на разных физических жестких дисках. Используя технологию «виртуального» общего диска в кластерной системе IBM Linux, несколько приложений, работающих на нескольких узлах, таких как GPFS, могут одновременно читать и записывать один и тот же файл. GPFS также включает в себя технологию IBM Scalable Cluster System Technology (RSCT), которая может автоматически восстанавливать сохраненное содержимое на активном узле.При сбое системы файл журнала может быстро восстановить данные и обеспечить согласованность данных. GPFS предоставляет стандартную файловую систему UNIX для приложений, которые можно запускать напрямую, не изменяя существующий код.
Во-вторых, основная структура файловой системы GPFS
Файловая система GPFS состоит из трех уровней: файлового устройства GPFS, сетевого общего диска (NSD) и диска.
1. Устройство файловой системы GPFS
Файловое устройство GPFS создается NSD, которое может быть подключено несколькими узлами параллельно одновременно.
2. Общий сетевой диск (NSD)
Общий сетевой диск (NSD) — это виртуальное устройство, подключенное к физическому диску, и с этим диском существует взаимно однозначное соответствие. Более того, NSD разделяет виртуальные устройства на разные виды использования в соответствии с разными атрибутами. Виртуальные устройства NSD имеют 4 различных дисковых атрибута:
a, Только Desc: указывает, что на диске хранится информация описания файловой системы GPFS.
б. Только данные: указывает, что на диске хранятся только данные файловой системы GPFS.
c. Только метаданные: указывает, что на диске хранится только информация о структуре каталогов (индексный дескриптор) файловой системы GPFS.
d, Мета и данные: указывает, что на диске хранится вся информация в файловой системе GPFS (по умолчанию)
В-третьих, характеристики файловой системы GPFS
1. Высокая производительность
Поскольку файловая система GPFS позволяет нескольким процессам в одном узле использовать стандартный интерфейс файловой системы UNIX для параллельного доступа к одним и тем же файлам (чтение и запись). Кроме того, операции чтения и записи узлов могут быть распределены по разным физическим дискам, что позволяет избежать чрезмерных операций чтения и записи на определенном диске, увеличить пропускную способность всей системы и улучшить общую производительность системы.
Сама файловая система GPFS может рассматриваться как отдельная система, которая не имеет ничего общего с конкретной системой и может поддерживать несколько операционных систем, таких как AIX, Linux и т. Д., Посредством кластеризации.
3. Обеспечьте согласованность данных.
Файловая система GPFS использует механизм управления сигнализацией для обеспечения согласованности данных. Механизм сигнализации позволяет каждому узлу обращаться к одному и тому же файлу по своему собственному пути. Следовательно, когда определенный путь узла не может нормально работать, файловая система GPFS все еще может быть достигнута через избыточность каналов. А сама GPFS разработана как файловая система журналов, которая создает независимые журналы для разных узлов (сохраняя информацию о распределении метаданных). Следовательно, после сбоя узла информация о распределении метаданных, записанная в журнале, может использоваться для быстрого поиска соответствующих метаданных и последующего восстановления.
GPFS может динамически настраивать системные ресурсы и поддерживает динамическое добавление и удаление жестких дисков при монтировании файловой системы без перезапуска.
5. Удобное управление
Файловая система GPFS может автоматически синхронизировать файлы конфигурации и информацию о файловой системе каждого узла, поэтому GPFS можно управлять на любом узле.
В-четвертых, арбитраж доступного состояния системы
Файловая система GPFS предоставляет три метода арбитража для определения того, является ли текущее состояние системы безопасным и надежным: кворум файловых дескрипторов, кворум узлов и кворум разрешения конфликтов.
1、File Descriptor Quorum：
Когда файловая система GPFS создается на диске, копии информации файловой системы копируются на несколько дисков для достижения избыточности данных. Этот метод поддерживается файловой системой GPFS по умолчанию и не может быть изменен конфигурацией. Кворум дескриптора файла определяет, является ли текущая система нормальной, оценивая оперативный статус диска, содержащего информацию о файловой системе. Когда более половины дисков, содержащих информацию о файловой системе, отключены, файловая система GPFS определит, что система находится в ненормальном состоянии, и файловая система будет автоматически закрыта в это время.
В кластере файловой системы GPFS несколько узлов хоста настроены на узлы кворума.Когда более половины узлов кворума отключаются, файловая система GPFS определяет, что система находится в ненормальном состоянии, и автоматически выключает файловую систему.
В кластере файловой системы GPFS вы можете установить некоторые назначенные физические диски как диски Tiebreaker, и файловая система GPFS будет динамически отслеживать состояние этих дисков. Когда больше, чем обычный Tiebreaker Disk отключается, это означает, что система находится в ненормальном состоянии и файловая система автоматически закрывается. Согласно документу, количество хостов кворума, используемых для мониторинга диска Tiebreaker, может быть сконфигурировано не более двух.При выходе из строя обоих хостов кворума это также указывает на системный сбой, и файловая система также отключается в это время.
Можно выбрать только один из методов арбитража Tibreaker Quorum и Node Quorum, и их нельзя использовать одновременно. Метод арбитража кворума Tibreakder в основном используется в случае относительно небольшого числа узлов.Если во всей системе больше узлов доступа, следует рассмотреть метод арбитража кворума узлов.
Пять, одновременный доступ к файловой системе GPFS
1. Одновременный доступ
Параллельный доступ к файлам файловой системы GPFS реализуется в двух частях: во-первых, несколько узлов GPFS получают доступ к данным на дисковой системе параллельно (может быть несколько процессов) (один и тот же или Другой); Во-вторых, файловая система GPFS распределяет доступ к файлам на разные физические диски для повышения эффективности доступа.
2. Блокировка файла
Файловая система GPFS поддерживает одновременный доступ к файлам, поэтому требуется механизм блокировки для обеспечения правильности данных во время одновременного доступа. Существует два общих механизма управления блокировками: механизм централизованного управления блокировками и механизм распределенного управления блокировками. Среди них, в механизме централизованного управления, один или несколько узлов в кластерной системе будут выделены для управления метаданными (метаданными) файловой системы. Когда нескольким узлам в кластере необходимо получить доступ к одному и тому же блоку данных в одно и то же время, узел сначала должен отправить запрос доступа на сервер управления метаданными. Сервер управления метаданными авторизует операции чтения и записи для узла, и узел может выполнить запрошенный блок данных. Операции чтения и записи. В механизме управления распределенными блокировками нет узла управления, предназначенного для управления метаданными.Метаданные в файловой системе распределены по всем узлам кластера файловой системы. Когда узел обращается к одному и тому же блоку данных в одно и то же время, он найдет узел в кластере, которому принадлежит блокировка блока данных, чтобы отправить запрос через сохраненную информацию метаданных, а затем сможет получить доступ к запрошенному блоку данных после утверждения.
Файловая система GPFS сочетает централизованные и распределенные механизмы управления блокировками для управления одновременным доступом. В файловом кластере GPFS есть сервер, отвечающий за глобальное управление блокировками, и каждый из кластеров Метаданные файловой системы также сохраняются на каждом узле. Сервер управления глобальным поиском координирует доступ к метаданным каждого узла путем выдачи токенов. Когда узлу в системе необходимо прочитать и записать файл, он сначала запрашивает токен у Token Server.Когда токен получен, блокировка файла может быть получена от узла, а затем считывается блок данных.
Gpfs что это такое
GPFS (General Parallel File System) — коммерческая кластерная файловая система с закрытым исходным кодом от голубого гиганта. Широко известна ввиду того, что многие постоянные участники HPC Top500 используют именно её.
Из самых очевидных плюсов хотелось бы отметить
- Возможность страйпа файлов между сетевыми дискам
- Легкое централизованное управление всем кластерным хранилищем с любого из нодов
- Выполнение задач по обслуживанию ФС без времени простоя и необходимости демонтирования ФС
- Технологии внутренней индексации, репликации и проч.
- Закрытость, платность
- Linux. Сборки доступны для RHEL4 и SLES (i386, x86_64)
- AIX 5L
- Microsoft Windows Server 2003 R2 (x86_64)
Содержание
Быстрый старт
1. Скачиваем и ставим установочные пакеты. Они имеют нумерацию версий x.y.0, например 3.2.0.
2. Скачиваем и ставим обновления. В имени пакета присутствует слово update. Версия пакета: x.y.z, z != 0. Апдейты свободно скачиваются с сайта IBM.
3. GPFS портирована с AIX и работает через прослойку mmfs. Нужно вручную собрать этот portability layer.
4. Теперь делаем GPFS-кластер. Здесь описываем ноды, а также основной и вторичный сервер конфигурации кластера
5. Создаем NSDs (Network Shared Disks). Для этого пишем текстовый файл конфигурации вида
К сожалению, команда создания NSD (след.пункт) не отрабатывает разделы и диски с путями сложнее /dev/sd[a-z][0-9]+, выдавая какую-то несуразицу в ответ, поэтому пытаться задавать /dev/disk/by-path/. бесполезно.
6. Скармливаем diskdef.txt команде создания кластера.
- gpfs1 — имя-идентификатор NSD.
- -A yes означает «монтировать автоматом» при /etc/init.d/gpfs start.
- -T /gpfs точка монтирования. Это всё прописывается в том числе и в /etc/fstab.
7. Осталось только примонтировать. Следующая простая команда выполняется на одном из нодов:
- -a означает примонтировать на всех нодах одновременно.
Установили? Идём дальше
Из минималистичного мануала по установке наверное стало предельно понятно, как образовываются названия GPFS-утилит исходя из их назначения. Постоянный префикс mm позволяет легко идентифицировать все утилиты GPFS.
- mmcrЧТОТО и mmaddЧТОТО — создать/добавить ЧТОТО, например кластер (cluster), сетевой диск (nsd), файлуху на диске (fs) и т.д.
- mmdelЧТОТО — удалить созданное.
- mmchЧТОТО — внести коррективы в созданное или в глобальный конфиг (config).
Так же следует отметить команды
- mmshutdown — остановить и выгрузить драйвера gpfs (mmfs и прочие).
- mmstartup — запустить кластер gpfs.
Обе могут выполняться с параметром -a, тем самым выполняясь асинхронно на всех нодах.
Для внесения изменений во что-то как правило необходимо это что-то остановить/отмонтировать/логически отсоеденить. В случае изменения конфига (mmchconfig) необходимо всё полностью остановить вплоть до демона gpfs.
GPFS ARCHITECTURE
GPFS is a kernel module extension (mmfs)
The kernel extension interfaces to the simulated file system (VFS) for file system access.
Applications make file system calls to the operating system, then route them to the GPFS file system kernel extension. GPFS appears to applications as just another file system in this manner. The kernel augmentation will either satisfy these requests using existing system resources or send a message to the daemon to finish the request.
The GPFS daemon (mmfsd)
The GPFS daemon manages all GPFS I/O and buffers, including read-ahead for sequential reads and write-behind for all writes that are not specified as synchronous. Token management protects all I/O and ensures the systems’ data consistency.
The GPFS daemon is a multi-threaded process, with some threads dedicated to specific tasks. This ensures that services that require immediate attention are not hampered because other threads are preoccupied with routine tasks.
The daemon also conveys with the other node cases to coordinate configuration changes, recovery, as well as parallel updates of the same database systems.
The daemon performs the following functions:
- Disk space is allocated to new and recently extended files.
- Directory management includes creating new directories, inserting and removing entries from existing directories, and searching for directories that require I/O.
- Locks are assigned to protect the integrity of data and metadata. Locks on data that can be accessed from multiple nodes necessitate interaction with the token management function.
- Daemon threads initiate disk I/O.
- The daemon also manages security and quotas in collaboration with the File System Manager.
Daemons for RSCT
GPFS makes use of two RSCT daemons to provide topology and group services. They are the daemons hagsd, and hatsd.
The hagsd daemon is associated with the Group Service subsystem. The Group Services subsystem provides distributed coordination, messaging, and synchronization to other subsystems.
The hatsd daemon represents the Topology Service subsystem. The Topology Services subsystem provides network adapter status, node connectivity information, and dependable messaging service to other subsystems.
The daemons are added during the rsct.basic package installation.
Overview Of GPFS Architecture
Nodes are classified into three types: file system, storage, and manager. Any node can carry out one of the functions listed above.
The node of the file system: manages administrative tasks
There is one manager node for each file system. Global lock manager, local lock manager, allocation manager, and so on are examples of manager nodes.
Storage nodes implement shared file access, work with the manager node during recovery, and allow file data and metadata to be striped across multiple storage nodes.
Other auxiliary nodes are as follows:
Metanode: For centralized file metadata management, a node is dynamically selected as a metanode. The token server facilitates metanode selection.
Token Server: A token server keeps track of all tokens distributed to cluster nodes. It uses a token granting algorithm to minimize the expenses of token management.
Special management responsibilities
GPFS performs the same functions on all nodes in general. It handles application requests on the node that contains the application, ensuring that the data is as close to the application as possible.
GPFS file system disc storage and file structure usage
A file system (or stripe group) is a collection of discs that hold file data, file metadata, and supporting entities like quota files and recovery logs.
Memory and GPFS
GPFS uses three types of memory: kernel heap memory, daemon segment memory, and shared memory accessed by both the daemon and the kernel.
Network communication as well as GPFS
You can specify different networks inside the GPFS cluster for GPFS daemon communication and GPFS command usage.
GPFS application but also user interaction
A GPFS file system can be accessed in four ways.
Disk discovery with NSD
When the GPFS daemon starts on a node, it reads a disc descriptor written on each disc operated by GPFS to discover the discs defined as NSDs. This allows the NSDs to be found regardless of the disk’s current operating framework device name.
Processing of failure recovery
GPFS failure recovery is handled automatically. As a result, while not required, some familiarity with its internal functions is useful when observed failures.
Data files for cluster configuration
The configuration and file system information stored by GPFS commands is stored in one or more files known as GPFS cluster configuration data files. These files are not intended to be manually modified.
Backup data for GPFS
During command execution, the GPFS mmbackup command creates several files. Some files are temporary and are deleted at the end of the backup process, and other files remain in the root directory of the fileset or file system and should not be deleted.
Configuration repository clustered
The Clustered Configuration Repository (CCR) is used by GPFS and many other IBM Spectrum Scale components such as the GUI, the CES services, and the monitoring service to store or return requested files and values across the group.