Pull to refresh

GPFS. Часть 1. Создание GPFS кластера

Reading time 9 min
Views 24K
GPFS (General Parallel File System)

После одной из моих последних статьей на хабре про серверную оптимизацию мне прислали множество вопросов про распределенные файловые системы. И теперь я нашел в себе силы и возможности написать про замечательную кластерную файловую систему GPFS.

Описание тестовой лаборатории:
  • Сервер виртуализации Xen. Dom0 под SLES11
  • 3 Xen DomU виртуальных сервера под quorum-ноды с двумя дополнительно проброшенными блочными устройствами
  • 2 Xen DomU виртуальных сервера под client-ноды

Тестовый стенд, основанный на технологии Xen, крайне удобен, ибо позволяет на ходу подцеплять/отцеплять диски от виртуалок, добавлять в них память и процессоры.



Создание кластера 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 (rpm -ivh)

Тут всё просто. Покупаем, устанавливаем на все ноды, которые планируют использовать 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:

export PATH=$PATH:/usr/lpp/mmfs/bin/

Далее создадим файл с нодами и их ролями:

gpfs00:~ # 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


С форматом:

NodeName:NodeDesignations:AdminNodeName

NodeDesignations:

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

Создаём кластер:

gpfs00:~ # 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

publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.ibm.cluster.gpfs33.basicadm.doc/bl1adm_mmcrcls.html

-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

На основном кластере применяется примерно такой тюнинг для GPFS (подробнее):

mmchconfig maxFilesToCache=1000000,maxMBpS=100000,pagepool=2G,verbsPort=mthca/0,verbsRdma=enable,worker1Threads=400,nsdthreadsperdisk=50

У 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, а они, в свою очередь, применяются на всём кластере):

gpfs00:~ # mmstartup -a

-a — отвечает за поднятие GPFS на всех нодах.


Далее выставляем нодам нужный тип лицензий.

Одна часть у нас будет серверами:

gpfs00:~ # mmchlicense server --accept -N gpfs00.edu.scalaxy.local,gpfs01.edu.scalaxy.local,gpfs02.edu.scalaxy.local

другая клиентами:

gpfs00:~ # mmchlicense client --accept -N gpfs04.edu.scalaxy.local,gpfs03.edu.scalaxy.local

Создание NSD — Network Shared Disk

Теперь создаём файл с описанием дисков и их содержимого:

gpfs00:~ # cat <<EOF >>gpfs.disks
/dev/sdb1:gpfs00.edu.scalaxy.local::dataAndMetadata:1
/dev/sdb1:gpfs01.edu.scalaxy.local::dataAndMetadata:2
/dev/sdb1:gpfs02.edu.scalaxy.local::descOnly:3
EOF


Формат файла таков:

DiskName:ServerList::DiskUsage:FailureGroup:DesiredName:StoragePool

DiskName — для Unix-систем — имя блочного устройства.

ServerList — список серверов, с которых доступен этот диск. Можно указать до восьми серверов, из которых будет выбран первый работоспособный. В нашем случае, где не используется SAN, это всего один сервер — тот, к которому подключён этот диск. Если не указать ничего, то GPFS будет считать, что диск доступен всем нодам кластера.

DiskUsagedataAndMetadata|dataOnly|metadataOnly|descOnly варианты говорят сами за себя, да и в мануале более подробное объяснение, разве что у descOnly, который я описывал выше.

FailureGroup — группа, к которой принадлежит диск. GPFS использует эту информацию, раскладывая данные и метаданные так, чтобы при единичном отказе обе реплики не погибли. То есть, например, диски, подключённые к одному контроллеру, к одному серверу или находящиеся в одном датацентре, принадлежат одной Failure-группе.

DesiredName — имя, которое мы хотим присвоить nsd. Должно попадать под регексп /[A-Za-Z0-9_]+/. По дефолту — gpfsNNnsd, где NN — целое, положительное, уникальное среди других nsd число.

StoragePool — имя Storage Pool'а, которое потом без изменений передаётся на mmcrfs.


Таже рекомендую прочитать более подробно о mmcrnsd

gpfs00:~ # mmcrnsd -F gpfs.disks -v no

-v no — не проверять, является ли диск уже отформатированым NSD (определяется это по второму сектору диска, где обычно хранится NSD volume ID)


Создание FS поверх NSD

После удачного завершения mmcrnsd файл gpfs.disks модифицируется для дальнейшего использования командой mmcrfs:

# /dev/sdb1:gpfs00.edu.scalaxy.local::dataAndMetadata:1
gpfs1nsd:::dataAndMetadata:1::
# /dev/sdb1:gpfs01.edu.scalaxy.local::dataAndMetadata:2
gpfs2nsd:::dataAndMetadata:2::
# /dev/sdb1:gpfs02.edu.scalaxy.local::descOnly:3
gpfs3nsd:::descOnly:3::


Далее идёт команда mmcrfs, к ней нужно отнестись весьма серьёзно, ибо она имеет множество параметров, каждый из которых влияет как на функциональность, так и на производительность GPFS, а после её создания изменить часть из них будет уже нереально.

gpfs00:~ # 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 {yes | no | automount} — автомонтирование 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 {nfs4 | posix} — схема блокировок. Если GPFS планирует отдаваться через nfs4 или samba, то нужно использовать nfs4, если GPFS будет отдаваться по NFS3 или же не будет экспортироваться никак, то лучше использовать posix.

-j {cluster | scatter} — метод выделения блоков для файла. Для больших инсталляций лучше использовать scatter, для маленьких cluster. Подробнее в мануале.

-L — размер логфайла. Варьируется от 256kb до 16MB. Стоит поднимать на высоконагруженых файловых системах и при большом количестве метаданных.

-N NumInodes[:NumInodesToPreallocate] — количество inodes. Поддерживаются суффиксы, i.e. 10M

-r DefaultDataReplicas {1|2} — количество реплик для данных файла по умолчанию. Не может быть больше, чем MaxDataReplicas. По умолчанию значение равно «1».

-R MaxDataReplicas {1|2} — максимальное количество реплик, которое можно задать через 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

gpfs00:~ # mmmount gpfs0 -a

Заключение

Вот, в принципе, и все, что я хотел рассказать о настройке GPFS. На днях я планирую написать продолжение этой статьи, в которой будет рассказано про эксплуатацию GPFS-кластера.

Продолжение
GPFS. Часть 2. Эксплуатация GPFS кластера.
Tags:
Hubs:
+34
Comments 27
Comments Comments 27

Articles