В продолжение моего предыдущего поста о настройке GPFS-кластера, как и обещал, перехожу к описанию весьма распространённых ситуаций, с которыми можно столкнуться при работе с GPFS.
Изменение параметров GPFS
Представим ситуацию, что нам необходимо сменить точку монтирования для нашей GPFS:
В ответ мы получили ошибку, что FS примонтирована на нескольких нодах.
Попытаемся отмонтировать GPFS на всех машинах:
Обратите внимание, что ошибка приходит от ноды gpfs04, на которой я в данный момент нахожусь в директории /gpfs-storage. Только после выхода из неё можно без проблем отмонтировать на всех нодах и сменить точку монтирования.
Мониторинг GPFS
Давайте теперь примонтируем всё на место и посмотрим, какие есть самые распространённые команды для мониторинга нашей новосозданной GPFS:
Смотрим, какие ноды есть в кластере:
Список NSD в кластере:
Можно посмотреть, сколько осталось места / inode'ов на GPFS:
В документации написано, что mmdf весьма трудоёмка, и её стоит применять только когда система слабо загружена.
Также можно посмотреть информацию по кластеру целиком:
Следующая команда выводит статус нод в кластере:
GPFS state бывают следующие:
Посмотреть какие лицензии установлены и на каких нодах можно следующей командой:
Также можно посмотреть текущую конфигурацию кластера, но так как я на тестовых виртуалках не пользовался командой mmchconfig, то она будет весьма не информативной.
Наполняем GPFS-диск:
Добавление дисков в GPFS
Давайте теперь сделаем ещё пару NSD дисков на gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local.
Процедура уже была описана ранее:
Теперь сама процедура добавления дисков в gpfs0:
Также у mmadddisk есть параметр -r, который перераспределяет файлы по файловой системе с учётом новых дисков. Мы же этот флаг не используем, а в место него будем применять mmrestripefs.
Если теперь посмотреть на вывод команды mmdf:
то видно, что диски заняты неравномерно. Дабы это исправить набираем:
После чего GPFS рестрайпит данные на разделе:
Добавление нод в кластер
Далее «на живую» перетащим дополнительные диски из quorum-виртуалок в nonquourum, и поднимем их статус до quorum.
Для начала удалим дополнительные диски у gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local:
Процесс удаления диска с параметром -b весьма похож на mmrestripefs, так что вывод команды указывать не буду.
В случае какой-либо ошибки mmdeldisk напишет:
Это означает, что диск удалён не был, но файловая система перестала быть сбалансированной, и её требуется «отрестрайпить».
Теперь, используя флаг -F, можно увидеть NSD, которые не присвоены никакой файловой системе:
Удалим эти NSD насовсем:
Далее, в XEN Dom0 нужно перетащить «на живую» блочные устройства с машин gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local на gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local соответственно.
Смотрим id'шники устройств:
Удаляем со старых машин:
Добавляем на новые:
Помните, в первой части я говорил про то, как удобен Xen для тестов? =)
Меняем лицензии двух других машинах на серверные:
Для чистоты эксперимента удаляем всё, что было на gpfs0 и запускаем копирование на GPFS исходников Linux в фоне:
Создаём NSD из свежеподключённых дисков и добавляем эти NSD в gpfs0:
Заметьте, что всё это время у нас производилось копирование файлов на GPFS.
Теперь на любой из нод можем проверить, что все файлы на месте:
Так как мы добавили диски только на середине копирования файлов, а в mmadddisk мы не использовали опцию -r, то в выводе mmdf мы увидим несбалансированность распределения файлов на GPFS. Так что нам потребуется выполнить уже известную процедуру:
Разваливаем GPFS кластер
Каждая единица данных и метаданных в GPFS-кластере хранится в максимум двух экземплярах. Поэтому, чтобы часть данных стала недоступна, нам нужно положить 2 ноды из разных failure-групп. Чтобы развалить кластер нам нужно либо не соблюсти quorum по дискам (более половины дисков down), либо по нодам (более половины нод окажется недоступно, например при net split).
Мы развалим кворум по дискам, положив 2 ноды в разных failure-группах, тем самым нарушив quorum по дискам:
Проверяем, что показывает статус:
Видим, что quorum по нодам соблюдён, однако:
Логи, mmlsdisk и mmlsnsd показывают, что 2 диска отвалились:
Восстановление GPFS кластера после сбоя
Запускаем все остановленные виртуалки с Dom0:
После загрузки машин проверим, поднялся ли GPFS-демон на серверах:
После того, как машины запустились, прилегающие к ним NSD-устройства остаются в состоянии «down» и не поднимаются автоматически. Сделано это из-за того, что причины смерти системы могут быть совершенно разные, и оператор должен сам решить, стоит ли эту систему отправлять обратно в бой или нет. Если же наблюдается серьёзная проблема с системой, то, чтобы подстраховаться от двойного сбоя, лучше выполнить mmrestripefs -m, которая мигрирует данные и метаданные, которые, в свою очередь, после выхода из строя одной машины остались в единичном экземпляре. Однако, данную команду лучше использовать с умом, ибо она потребляет много ресурсов и занимает кучу времени.
Однако, вернувшись к нашему GPFSу: чтобы вернуть в строй диски и собрать заново GPFS, нужно выполнить команду:
Параметр -a запустит все остановленные диски.
В случае, если какой-то диск не поднялся — команда может выдать ошибку:
Команда mmlsdisk пометит этот диск как «unrecovered»:
Но даже с одним мёртвым NSD файловая система будет вполне работоспособна на всех нодах кластера.
В нашем случае, с дисками всё нормально и наш мини-кластер собрался нормально, так что необходимо примонтировать GPFS-раздел на всех нодах командой:
После сборки развалившегося кластера проверим, действительно ли все данные выжили:
Да, все данные оказались нетронутыми даже после полного развала всего кластера.
Теперь можно удалить подключённые для теста диски, с ребалансировкой данных:
Если одновременно с другого узла попытаться удалить ещё один диск, то мы будем ждать пока предыдущая операция освободит Lock:
Если GPFS поймёт, что после удаления диска файлы не влезут на файловую систему, то mmdeldisk выдаст следующую ошибку:
Падение quorum-ноды при копировании файлов
Теперь мы «положим» нашу gpfs00.edu.scalaxy.local во время интенсивной работы с диском другими нодами.
Я проверял бесперебойность работы на команде:
Машину я «прибивал» как shutdown -h now так и xm destroy
Всё прошло успешно — поднятия и остановки gpfs00.edu.scalaxy.local никак не повлияли на скорость копирования.
Что происходит при нехватке inode'ов
Вспомним наш пример с исходниками Linux. При создании файловой системы мы неправильно выбрали размер блока потому, что файлы исходников крайне малы и им никак не подходит размер блока 1M, а соответственно, минимальный размер файла будет равняться 32Kb.
Вот и всё, inode'ы кончились, можем это проверить:
Если посмотреть лог, то будет видно, что на самом деле GPFS предупредил нас об этом заранее, правда мы этого не увидели:
Чтобы решить эту проблему нужно увеличить количество inode'ов:
Также желательно не оставлять на GPFS inode'ов меньше 5%:
Снапшоты в GPFS
Их я опишу совсем вкратце.
Возьмём README файл линукса и скопируем его на GPFS:
Сделаем снапшот файловой системы:
Удаляем файл, который только что скопировали:
И смотрим, остался ли он жив в подпапке .snapshots:
Тесты производительности GPFS
Тесты, скорее всего выложу позже, когда развернём всё это на InfiniBand-ферме, а не на 5-ти виртуалках в одном Dom0.
Тесты производительности, которые обитают в интернете, в основном направлены на сравнении производительности MPI-I/O vs POSIX, threaded I/O, block sizes. Интересные сравнения можно посмотреть тут:
www.nersc.gov/news/reports/technical/seaborg_scaling/io.php
http://arcos.inf.uc3m.es/~dcio/ALEX-gpfs.ppt
Что осталось за кадром?
… а также доверенный доступ GPFS-кластеров друг к другу и внутренний API gpfs, через который можно вытянуть метаданные миллиарда файлов за пару секунд :)
За кадром осталась и замечательная команда, которая может всё-всё-всё =)
Ссылки по теме
Изменение параметров GPFS
Представим ситуацию, что нам необходимо сменить точку монтирования для нашей GPFS:
gpfs00:~ # mmchfs /dev/gpfs0 -T /gpfs-howto
File system /dev/gpfs0 is mounted on nodes:
10.35.2.66 gpfs04 gpfs-cluster.edu.scalaxy.local 11.05 (3.3.0.2)
10.35.2.63 gpfs01 gpfs-cluster.edu.scalaxy.local 11.05 (3.3.0.2)
10.35.2.64 gpfs02 gpfs-cluster.edu.scalaxy.local 11.05 (3.3.0.2)
10.35.2.65 gpfs03 gpfs-cluster.edu.scalaxy.local 11.05 (3.3.0.2)
10.35.2.62 gpfs00 gpfs-cluster.edu.scalaxy.local 11.05 (3.3.0.2)
mmchfs: Command failed. Examine previous error messages to determine cause.
В ответ мы получили ошибку, что FS примонтирована на нескольких нодах.
Попытаемся отмонтировать GPFS на всех машинах:
gpfs00:~ # mmumount gpfs0 -a
gpfs04.edu.scalaxy.local: umount: /gpfs-storage: device is busy.
gpfs04.edu.scalaxy.local: (In some cases useful info about processes that use
gpfs04.edu.scalaxy.local: the device is found by lsof(8) or fuser(1))
Обратите внимание, что ошибка приходит от ноды gpfs04, на которой я в данный момент нахожусь в директории /gpfs-storage. Только после выхода из неё можно без проблем отмонтировать на всех нодах и сменить точку монтирования.
gpfs00:~ # mmchfs /dev/gpfs0 -T /gpfs-howto
Не все параметры заданные на этапе mmcrfs можно изменить командой mmchfs. Подробнее в мануале.
Мониторинг GPFS
Давайте теперь примонтируем всё на место и посмотрим, какие есть самые распространённые команды для мониторинга нашей новосозданной GPFS:
gpfs00:~ # mmmount gpfs0 -a
-a — монтирует все FS на всех нодах кластера
Смотрим, какие ноды есть в кластере:
gpfs00:~ # mmlsnode
GPFS nodeset Node list
------------- -------------------------------------------------------
gpfs-cluster gpfs00 gpfs01 gpfs02 gpfs03 gpfs04
Список NSD в кластере:
gpfs00:~ # mmlsnsd -X
Disk name NSD volume ID Device Devtype Node name Remarks
---------------------------------------------------------------------------------------------------
gpfs1nsd 0A23023E4B5DC633 /dev/sdb1 generic gpfs00.edu.scalaxy.local server node
gpfs2nsd 0A23023F4B5DC633 /dev/sdb1 generic gpfs01.edu.scalaxy.local server node
gpfs3nsd 0A2302404B5DC634 /dev/sdb1 generic gpfs02.edu.scalaxy.local server node
-X — отображает расширенную информацию. Довольно медленная операция, рекомендуется применять только при диагностике неисправностей.
-F — показывает NSD, которые не привязаны к какой-либо FS
Можно посмотреть, сколько осталось места / inode'ов на GPFS:
gpfs00:~ # mmdf gpfs0
disk disk size failure holds holds free KB free KB
name in KB group metadata data in full blocks in fragments
--------------- ------------- -------- -------- ----- -------------------- -------------------
Disks in storage pool: system (Maximum disk size allowed is 125 GB)
gpfs1nsd 2097152 1 yes yes 1934336 ( 92%) 1952 ( 0%)
gpfs2nsd 2097152 2 yes yes 1933312 ( 92%) 2080 ( 0%)
gpfs3nsd 2097152 3 no no 0 ( 0%) 0 ( 0%)
------------- -------------------- -------------------
(pool total) 6291456 3867648 ( 61%) 4032 ( 0%)
============= ==================== ===================
(total) 6291456 3867648 ( 61%) 4032 ( 0%)
Inode Information
-----------------
Number of used inodes: 4071
Number of free inodes: 32793
Number of allocated inodes: 36864
Maximum number of inodes: 36864
В документации написано, что mmdf весьма трудоёмка, и её стоит применять только когда система слабо загружена.
gpfs00:~ # mmlsdisk gpfs0
disk driver sector failure holds holds storage
name type size group metadata data status availability pool
------------ -------- ------ ------- -------- ----- ------------- ------------ ------------
gpfs1nsd nsd 512 1 yes yes ready up system
gpfs2nsd nsd 512 2 yes yes ready up system
gpfs3nsd nsd 512 3 no no ready up system
gpfs00:~ # mmlspool gpfs0
Storage pools in file system at '/gpfs-howto':
Name Id BlkSize Data Meta Total Data KB Free Data KB Total Meta KB Free Meta KB
system 0 1024 KB yes yes 4194304 3867648 ( 92%) 4194304 3870720 ( 92%)
Также можно посмотреть информацию по кластеру целиком:
gpfs00:~ # mmlscluster
GPFS cluster information
========================
GPFS cluster name: gpfs-cluster.edu.scalaxy.local
GPFS cluster id: 730430031139815289
GPFS UID domain: gpfs-cluster.edu.scalaxy.local
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: gpfs00.edu.scalaxy.local
Secondary server: gpfs01.edu.scalaxy.local
Node Daemon node name IP address Admin node name Designation
-----------------------------------------------------------------------------------------------
1 gpfs00.edu.scalaxy.local 10.35.2.62 gpfs00.edu.scalaxy.local quorum-manager
2 gpfs01.edu.scalaxy.local 10.35.2.63 gpfs01.edu.scalaxy.local quorum-manager
3 gpfs02.edu.scalaxy.local 10.35.2.64 gpfs02.edu.scalaxy.local quorum
4 gpfs03.edu.scalaxy.local 10.35.2.65 gpfs03.edu.scalaxy.local
5 gpfs04.edu.scalaxy.local 10.35.2.66 gpfs04.edu.scalaxy.local
Следующая команда выводит статус нод в кластере:
gpfs00:/home/aivanov # mmgetstate -Lsa
Node number Node name Quorum Nodes up Total nodes GPFS state Remarks
------------------------------------------------------------------------------------
1 gpfs00 2 3 5 active quorum node
2 gpfs01 2 3 5 active quorum node
3 gpfs02 2 3 5 active quorum node
4 gpfs03 2 3 5 active
5 gpfs04 2 3 5 active
Summary information
---------------------
Number of nodes defined in the cluster: 5
Number of local nodes active in the cluster: 5
Number of remote nodes joined in this cluster: 0
Number of quorum nodes defined in the cluster: 3
Number of quorum nodes active in the cluster: 3
Quorum = 2, Quorum achieved
-a — для всех нод кластера
-L — отображать кворум, количество поднятых нод, общее количество нод и дополнительную информацию
-s — отображать summary
GPFS state бывают следующие:
active — всё ОК
arbitrating — нода пытается присоединится к кворуму
down — GPFS демон не запущен или перезапускается
unknown — статус машины неизвестен. В большинстве случаев означает, что машина недоступна по сети
Посмотреть какие лицензии установлены и на каких нодах можно следующей командой:
gpfs00:~ # mmlslicense -L
Node name Required license Designated license
-------------------------------------------------------------------
gpfs00.edu.scalaxy.local server server
gpfs01.edu.scalaxy.local server server
gpfs02.edu.scalaxy.local server server
gpfs03.edu.scalaxy.local client client
gpfs04.edu.scalaxy.local client client
Summary information
---------------------
Number of nodes defined in the cluster: 5
Number of nodes with server license designation: 3
Number of nodes with client license designation: 2
Number of nodes still requiring server license designation: 0
Number of nodes still requiring client license designation: 0
-L — детальная информация по лицензиям, а не только summary
Также можно посмотреть текущую конфигурацию кластера, но так как я на тестовых виртуалках не пользовался командой mmchconfig, то она будет весьма не информативной.
gpfs00:~ # mmlsconfig
Configuration data for cluster gpfs-cluster.edu.scalaxy.local:
--------------------------------------------------------------
clusterName gpfs-cluster.edu.scalaxy.local
clusterId 730430031139815289
autoload yes
minReleaseLevel 3.3.0.2
dmapiFileHandleSize 32
[gpfs02]
unmountOnDiskFail yes
[common]
adminMode central
File systems in cluster gpfs-cluster.edu.scalaxy.local:
-------------------------------------------------------
/dev/gpfs0
Манипуляции со структурой GPFS
Наполняем GPFS-диск:
cp -r /usr/src/linux/* /gpfs-howto/
Добавление дисков в GPFS
Давайте теперь сделаем ещё пару NSD дисков на gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local.
Процедура уже была описана ранее:
gpfs00:~ # cat <<EOF >>gpfs.00.disk
/dev/sdb2:gpfs00.edu.scalaxy.local::dataAndMetadata:1
EOF
gpfs00:~ # cat <<EOF >>gpfs.01.disk
/dev/sdb2:gpfs01.edu.scalaxy.local::dataAndMetadata:2
EOF
gpfs00:~ # mmcrnsd -F gpfs.00.disk -v no
gpfs00:~ # mmcrnsd -F gpfs.01.disk -v no
Теперь сама процедура добавления дисков в gpfs0:
gpfs00:~ # mmadddisk gpfs0 -F gpfs.00.disk
The following disks of gpfs0 will be formatted on node gpfs00.edu.scalaxy.local:
gpfs8nsd: size 2097152 KB
Extending Allocation Map
Checking Allocation Map for storage pool 'system'
Completed adding disks to file system gpfs0.
mmadddisk: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
gpfs00:~ # mmadddisk gpfs0 -F gpfs.01.disk
The following disks of gpfs0 will be formatted on node gpfs00.edu.scalaxy.local:
gpfs9nsd: size 2097152 KB
Extending Allocation Map
Checking Allocation Map for storage pool 'system'
Completed adding disks to file system gpfs0.
mmadddisk: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
Также у mmadddisk есть параметр -r, который перераспределяет файлы по файловой системе с учётом новых дисков. Мы же этот флаг не используем, а в место него будем применять mmrestripefs.
Если теперь посмотреть на вывод команды mmdf:
gpfs00:~ # mmdf gpfs0
disk disk size failure holds holds free KB free KB
name in KB group metadata data in full blocks in fragments
--------------- ------------- -------- -------- ----- -------------------- -------------------
Disks in storage pool: system (Maximum disk size allowed is 125 GB)
gpfs1nsd 2097152 1 yes yes 911360 ( 43%) 27712 ( 1%)
gpfs8nsd 2097152 1 yes yes 2094080 (100%) 992 ( 0%)
gpfs9nsd 2097152 2 yes yes 2094080 (100%) 992 ( 0%)
gpfs2nsd 2097152 2 yes yes 904192 ( 43%) 34880 ( 2%)
gpfs3nsd 2097152 3 no no 0 ( 0%) 0 ( 0%)
------------- -------------------- -------------------
(pool total) 10485760 6003712 ( 57%) 64576 ( 1%)
============= ==================== ===================
(total) 10485760 6003712 ( 57%) 64576 ( 1%)
Inode Information
-----------------
Number of used inodes: 31531
Number of free inodes: 5333
Number of allocated inodes: 36864
Maximum number of inodes: 36864
то видно, что диски заняты неравномерно. Дабы это исправить набираем:
gpfs00:~ # mmrestripefs gpfs0 -b
Scanning file system metadata, phase 1 ...
Scan completed successfully.
Scanning file system metadata, phase 2 ...
Scan completed successfully.
Scanning file system metadata, phase 3 ...
Scan completed successfully.
Scanning file system metadata, phase 4 ...
Scan completed successfully.
Scanning user file metadata ...
11.64 % complete on Wed Jan 27 22:45:13 2010 ( 7435 inodes 502 MB)
18.72 % complete on Wed Jan 27 22:45:33 2010 ( 12453 inodes 807 MB)
25.88 % complete on Wed Jan 27 22:45:53 2010 ( 18590 inodes 1116 MB)
33.05 % complete on Wed Jan 27 22:46:13 2010 ( 24020 inodes 1425 MB)
39.77 % complete on Wed Jan 27 22:46:33 2010 ( 28585 inodes 1715 MB)
46.10 % complete on Wed Jan 27 22:46:54 2010 ( 32828 inodes 1988 MB)
100.00 % complete on Wed Jan 27 22:47:06 2010
Scan completed successfully.
После чего GPFS рестрайпит данные на разделе:
gpfs00:~ # mmdf gpfs0
disk disk size failure holds holds free KB free KB
name in KB group metadata data in full blocks in fragments
--------------- ------------- -------- -------- ----- -------------------- -------------------
Disks in storage pool: system (Maximum disk size allowed is 125 GB)
gpfs1nsd 2097152 1 yes yes 635904 ( 30%) 808768 (39%)
gpfs8nsd 2097152 1 yes yes 1421312 ( 68%) 168160 ( 8%)
gpfs9nsd 2097152 2 yes yes 1431552 ( 68%) 166944 ( 8%)
gpfs2nsd 2097152 2 yes yes 615424 ( 29%) 820224 (39%)
gpfs3nsd 2097152 3 no no 0 ( 0%) 0 ( 0%)
------------- -------------------- -------------------
(pool total) 10485760 4104192 ( 39%) 1964096 (19%)
============= ==================== ===================
(total) 10485760 4104192 ( 39%) 1964096 (19%)
Добавление нод в кластер
Далее «на живую» перетащим дополнительные диски из quorum-виртуалок в nonquourum, и поднимем их статус до quorum.
Для начала удалим дополнительные диски у gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local:
gpfs00:~ # mmdeldisk gpfs0 gpfs8nsd -b
gpfs00:~ # mmdeldisk gpfs0 gpfs9nsd -b
-b — говорит mmdeldisk перераспределить данные на файловой системе таким образом, как это сделал бы последующий запуск mmrestripefs
Процесс удаления диска с параметром -b весьма похож на mmrestripefs, так что вывод команды указывать не буду.
В случае какой-либо ошибки mmdeldisk напишет:
Attention: No disks were deleted, but some data was migrated.
The file system may no longer be properly balanced.
Это означает, что диск удалён не был, но файловая система перестала быть сбалансированной, и её требуется «отрестрайпить».
Теперь, используя флаг -F, можно увидеть NSD, которые не присвоены никакой файловой системе:
gpfs00:~ # mmlsnsd -F
File system Disk name NSD servers
---------------------------------------------------------------------------
(free disk) gpfs8nsd gpfs00.edu.scalaxy.local
(free disk) gpfs9nsd gpfs01.edu.scalaxy.local
Удалим эти NSD насовсем:
gpfs00:~ # mmdelnsd gpfs9nsd
gpfs00:~ # mmdelnsd gpfs8nsd
Далее, в XEN Dom0 нужно перетащить «на живую» блочные устройства с машин gpfs00.edu.scalaxy.local и gpfs01.edu.scalaxy.local на gpfs03.edu.scalaxy.local и gpfs04.edu.scalaxy.local соответственно.
Dom0-0212:~ # xm shell
Смотрим id'шники устройств:
xm> xm block-list gpfs00.edu.scalaxy.local
xm> xm block-list gpfs01.edu.scalaxy.local
Удаляем со старых машин:
xm> xm block-detach gpfs00.edu.scalaxy.local 2066
xm> xm block-detach gpfs01.edu.scalaxy.local 2066
Добавляем на новые:
xm> xm block-attach gpfs03.edu.scalaxy.local phy:/dev/user/gpfs00-disk1 sdb1 w
xm> xm block-attach gpfs04.edu.scalaxy.local phy:/dev/user/gpfs01-disk1 sdb1 w
Помните, в первой части я говорил про то, как удобен Xen для тестов? =)
Меняем лицензии двух других машинах на серверные:
gpfs00:~ # mmchlicense server --accept -N gpfs04.edu.scalaxy.local,gpfs03.edu.scalaxy.local
gpfs00:~ # mmlslicense
Summary information
---------------------
Number of nodes defined in the cluster: 5
Number of nodes with server license designation: 5
Number of nodes with client license designation: 0
Number of nodes still requiring server license designation: 0
Number of nodes still requiring client license designation: 0
gpfs00:~ # cat <<EOF >> gpfs.03.disk
/dev/sdb1:gpfs03.edu.scalaxy.local::dataAndMetadata:1
EOF
gpfs00:~ # cat <<EOF >> gpfs.04.disk
/dev/sdb1:gpfs04.edu.scalaxy.local::dataAndMetadata:2
EOF
Для чистоты эксперимента удаляем всё, что было на gpfs0 и запускаем копирование на GPFS исходников Linux в фоне:
gpfs00:~ # cp -r /usr/src/linux/* /gpfs-howto/&
Создаём NSD из свежеподключённых дисков и добавляем эти NSD в gpfs0:
gpfs00:~ # mmcrnsd -F gpfs.03.disk -v no
gpfs00:~ # mmadddisk gpfs0 -F gpfs.03.disk
gpfs00:~ # mmcrnsd -F gpfs.04.disk -v no
gpfs00:~ # mmadddisk gpfs0 -F gpfs.04.disk
Заметьте, что всё это время у нас производилось копирование файлов на GPFS.
Теперь на любой из нод можем проверить, что все файлы на месте:
gpfs02:/gpfs-howto # ls
arch Documentation init lib net REPORTING-BUGS usr
block drivers ipc .mailmap .patches samples virt
COPYING firmware Kbuild MAINTAINERS perfmon scripts
CREDITS fs kdb Makefile README security
crypto include kernel mm README.SUSE sound
Так как мы добавили диски только на середине копирования файлов, а в mmadddisk мы не использовали опцию -r, то в выводе mmdf мы увидим несбалансированность распределения файлов на GPFS. Так что нам потребуется выполнить уже известную процедуру:
gpfs00:~ # mmrestripefs gpfs0 -b
Разваливаем GPFS кластер
Каждая единица данных и метаданных в GPFS-кластере хранится в максимум двух экземплярах. Поэтому, чтобы часть данных стала недоступна, нам нужно положить 2 ноды из разных failure-групп. Чтобы развалить кластер нам нужно либо не соблюсти quorum по дискам (более половины дисков down), либо по нодам (более половины нод окажется недоступно, например при net split).
Мы развалим кворум по дискам, положив 2 ноды в разных failure-группах, тем самым нарушив quorum по дискам:
gpfs03:~ # halt
gpfs04:~ # halt
Проверяем, что показывает статус:
gpfs00:~ # mmgetstate -Lsa
Node number Node name Quorum Nodes up Total nodes GPFS state Remarks
------------------------------------------------------------------------------------
1 gpfs00 2 3 5 active quorum node
2 gpfs01 2 3 5 active quorum node
3 gpfs02 2 3 5 active quorum node
4 gpfs03 0 0 5 unknown
5 gpfs04 0 0 5 unknown
Summary information
---------------------
Number of nodes defined in the cluster: 5
Number of local nodes active in the cluster: 3
Number of remote nodes joined in this cluster: 0
Number of quorum nodes defined in the cluster: 3
Number of quorum nodes active in the cluster: 3
Quorum = 2, Quorum achieved
Видим, что quorum по нодам соблюдён, однако:
gpfs00:~ # ls /gpfs-howto
ls: cannot access /gpfs-howto: Stale NFS file handle
Логи, mmlsdisk и mmlsnsd показывают, что 2 диска отвалились:
gpfs00:~ # grep "mmfs:" /var/log/messages
Jan 28 12:36:14 gpfs00 mmfs: Error=MMFS_DISKFAIL, ID=0x9C6C05FA, Tag=6368843: Disk failure. Volume gpfs0. rc = 5. Physical volume gpfs10nsd
Jan 28 14:43:11 gpfs00 mmfs: Error=MMFS_DISKFAIL, ID=0x9C6C05FA, Tag=6368846: Disk failure. Volume gpfs0. rc = 19. Physical volume gpfs11nsd
gpfs00:~ # less /var/adm/ras/mmfs.log.latest
Thu Jan 28 12:36:14.863 2010: Disk failure from node 10.35.2.64 (gpfs02) Volume
gpfs0. Physical volume gpfs10nsd.
Thu Jan 28 14:43:11.688 2010: Disk failure. Volume gpfs0. rc = 19. Physical vol
ume gpfs11nsd.
gpfs00:~ # mmlsdisk gpfs0 -L
disk driver sector failure holds holds storage
name type size group metadata data status availability disk id pool remarks
------------ -------- ------ ------- -------- ----- ------------- ------------ ------- ------------ ---------
gpfs1nsd nsd 512 1 yes yes ready up 1 system desc
gpfs2nsd nsd 512 2 yes yes ready up 2 system desc
gpfs3nsd nsd 512 3 no no ready up 3 system desc
gpfs10nsd nsd 512 1 yes yes ready down 4 system desc
gpfs11nsd nsd 512 2 yes yes ready down 5 system desc
Number of quorum disks: 5
Read quorum value: 3
Write quorum value: 3
gpfs00:~ # mmlsnsd -X
Disk name NSD volume ID Device Devtype Node name Remarks
---------------------------------------------------------------------------------------------------
gpfs10nsd 0A2302414B6154F4 - - gpfs03.edu.scalaxy.local (not found) server node
gpfs11nsd 0A2302424B6154F8 - - gpfs04.edu.scalaxy.local (not found) server node
gpfs1nsd 0A23023E4B5DC633 /dev/sdb1 generic gpfs00.edu.scalaxy.local server node
gpfs2nsd 0A23023F4B5DC633 /dev/sdb1 generic gpfs01.edu.scalaxy.local server node
gpfs3nsd 0A2302404B5DC634 /dev/sdb1 generic gpfs02.edu.scalaxy.local server node
mmlsnsd: The following nodes could not be reached:
gpfs03.edu.scalaxy.local
gpfs04.edu.scalaxy.local
Восстановление GPFS кластера после сбоя
Запускаем все остановленные виртуалки с Dom0:
Dom0-0212:/etc/xen/vm # for i in gpfs*.edu.scalaxy.local ; do xm create $i; done
После загрузки машин проверим, поднялся ли GPFS-демон на серверах:
gpfs00:~ # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 gpfs00 active
2 gpfs01 active
3 gpfs02 active
4 gpfs03 active
5 gpfs04 active
После того, как машины запустились, прилегающие к ним NSD-устройства остаются в состоянии «down» и не поднимаются автоматически. Сделано это из-за того, что причины смерти системы могут быть совершенно разные, и оператор должен сам решить, стоит ли эту систему отправлять обратно в бой или нет. Если же наблюдается серьёзная проблема с системой, то, чтобы подстраховаться от двойного сбоя, лучше выполнить mmrestripefs -m, которая мигрирует данные и метаданные, которые, в свою очередь, после выхода из строя одной машины остались в единичном экземпляре. Однако, данную команду лучше использовать с умом, ибо она потребляет много ресурсов и занимает кучу времени.
Однако, вернувшись к нашему GPFSу: чтобы вернуть в строй диски и собрать заново GPFS, нужно выполнить команду:
gpfs00:~ # mmchdisk gpfs0 start -a
Scanning file system metadata, phase 1 ...
Scan completed successfully.
Scanning file system metadata, phase 2 ...
Scan completed successfully.
Scanning file system metadata, phase 3 ...
Scan completed successfully.
Scanning file system metadata, phase 4 ...
Scan completed successfully.
Scanning user file metadata ...
100.00 % complete on Thu Jan 28 16:38:47 2010
Scan completed successfully.
Параметр -a запустит все остановленные диски.
В случае, если какой-то диск не поднялся — команда может выдать ошибку:
No such device
Initial disk state was updated successfully, but another error may have changed the state again.
mmchdisk: Command failed. Examine previous error messages to determine cause.
Команда mmlsdisk пометит этот диск как «unrecovered»:
gpfs00:~ # mmlsdisk gpfs0
disk driver sector failure holds holds storage
name type size group metadata data status availability pool
------------ -------- ------ ------- -------- ----- ------------- ------------ ------------
gpfs1nsd nsd 512 1 yes yes ready up system
gpfs2nsd nsd 512 2 yes yes ready up system
gpfs3nsd nsd 512 3 no no ready up system
gpfs10nsd nsd 512 2 yes yes ready up system
gpfs11nsd nsd 512 1 yes yes ready unrecovered system
Но даже с одним мёртвым NSD файловая система будет вполне работоспособна на всех нодах кластера.
В нашем случае, с дисками всё нормально и наш мини-кластер собрался нормально, так что необходимо примонтировать GPFS-раздел на всех нодах командой:
gpfs00:~ # mmmount gpfs0 -a
После сборки развалившегося кластера проверим, действительно ли все данные выжили:
gpfs00:~ # diff -ru /usr/src/linux/ /gpfs-howto/
gpfs00:~ #
Да, все данные оказались нетронутыми даже после полного развала всего кластера.
Теперь можно удалить подключённые для теста диски, с ребалансировкой данных:
gpfs00:~ # mmdeldisk gpfs0 gpfs10nsd -b
Deleting disks ...
Scanning system storage pool
Scanning file system metadata, phase 1 ...
Scan completed successfully.
Scanning file system metadata, phase 2 ...
Scan completed successfully.
Scanning file system metadata, phase 3 ...
Scan completed successfully.
Scanning file system metadata, phase 4 ...
Scan completed successfully.
Scanning user file metadata ...
100.00 % complete on Thu Jan 28 17:18:41 2010
Scan completed successfully.
Checking Allocation Map for storage pool 'system'
tsdeldisk completed.
mmdeldisk: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
Если одновременно с другого узла попытаться удалить ещё один диск, то мы будем ждать пока предыдущая операция освободит Lock:
gpfs01:~ # mmdeldisk gpfs0 gpfs6nsd -b
mmdeldisk: The main GPFS cluster configuration file is locked. Retrying...
mmdeldisk: Lock creation successful.
Если GPFS поймёт, что после удаления диска файлы не влезут на файловую систему, то mmdeldisk выдаст следующую ошибку:
Deleting disks ...
Scanning system storage pool
Scanning file system metadata, phase 1 ...
Error processing inodes.
No space left on device
Attention: No disks were deleted, but some data was migrated.
The file system may no longer be properly balanced.
tsdeldisk completed.
mmdeldisk: tsdeldisk failed.
Verifying file system configuration information ...
mmdeldisk: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
mmdeldisk: Command failed. Examine previous error messages to determine cause.
Падение quorum-ноды при копировании файлов
Теперь мы «положим» нашу gpfs00.edu.scalaxy.local во время интенсивной работы с диском другими нодами.
Я проверял бесперебойность работы на команде:
gpfs03:/gpfs-howto# dd if=/dev/zero bs=1M | pv | dd of=zero03 bs=1M
Обратите внимание, что размер буфера равен страйпу файловой системы, заданному на этапе mmcrfs
Машину я «прибивал» как shutdown -h now так и xm destroy
Всё прошло успешно — поднятия и остановки gpfs00.edu.scalaxy.local никак не повлияли на скорость копирования.
Что происходит при нехватке inode'ов
Вспомним наш пример с исходниками Linux. При создании файловой системы мы неправильно выбрали размер блока потому, что файлы исходников крайне малы и им никак не подходит размер блока 1M, а соответственно, минимальный размер файла будет равняться 32Kb.
gpfs04:/gpfs-howto # make oldconfig
gpfs04:/gpfs-howto # make
.....
.....
fs/dmapi/dmapi_session.c:1824: fatal error: opening dependency file fs/dmapi/.dmapi_session.o.d: No space left on device
Вот и всё, inode'ы кончились, можем это проверить:
gpfs04:/gpfs-howto # mmdf gpfs0 -F
Inode Information
-----------------
Number of used inodes: 36864
Number of free inodes: 0
Number of allocated inodes: 36864
Maximum number of inodes: 36864
Если посмотреть лог, то будет видно, что на самом деле GPFS предупредил нас об этом заранее, правда мы этого не увидели:
gpfs04:/gpfs-howto # grep "mmfs:" /var/log/messages
Jan 25 22:36:31 gpfs01 mmfs: Error=MMFS_SYSTEM_WARNING, ID=0x4DC797C6, Tag=6153238: File system warning. Volume gpfs0. Reason: File system gpfs0 is approaching the limit for the maximum number of inodes/files.
Чтобы решить эту проблему нужно увеличить количество inode'ов:
gpfs00:~ # mmchfs gpfs0 -F 100000
Также желательно не оставлять на GPFS inode'ов меньше 5%:
For file systems that will be creating parallel files, if the total number of free inodes is not greater than 5% of the total number of inodes, file system access might slow down. Take this into consideration when creating your file system
Снапшоты в GPFS
Их я опишу совсем вкратце.
Возьмём README файл линукса и скопируем его на GPFS:
gpfs00:~ # cp /usr/src/linux/README /gpfs-howto/
Сделаем снапшот файловой системы:
gpfs00:~ # mmcrsnapshot gpfs0 gpfs-snapshot-`date +%Y-%m-%d`
Writing dirty data to disk
Quiescing all file system operations
Writing dirty data to disk again
Creating snapshot.
Resuming operations.
Удаляем файл, который только что скопировали:
gpfs00:~ # rm /gpfs-howto/README
И смотрим, остался ли он жив в подпапке .snapshots:
gpfs00:~ # ls -al /gpfs-howto/.snapshots/gpfs-snapshot-2010-01-28/
-rw-r--r-- 1 root root 16930 2010-01-26 19:58 README
Тесты производительности GPFS
Тесты, скорее всего выложу позже, когда развернём всё это на InfiniBand-ферме, а не на 5-ти виртуалках в одном Dom0.
Тесты производительности, которые обитают в интернете, в основном направлены на сравнении производительности MPI-I/O vs POSIX, threaded I/O, block sizes. Интересные сравнения можно посмотреть тут:
www.nersc.gov/news/reports/technical/seaborg_scaling/io.php
http://arcos.inf.uc3m.es/~dcio/ALEX-gpfs.ppt
Что осталось за кадром?
- Квоты
- Политики
- Пулы
- Filesets
- DMAPI
- Windows и AIX специфика GPFS
… а также доверенный доступ GPFS-кластеров друг к другу и внутренний API gpfs, через который можно вытянуть метаданные миллиарда файлов за пару секунд :)
За кадром осталась и замечательная команда, которая может всё-всё-всё =)
gpfs00:~ # mmfsadm
Enter commands (type "help" or "?" for help):
mmfsadm> help
Commands:
dump what Dump data structures and statistics, where 'what' can be:
alloc, alloc all, alloc stats, allocmgr, allocmgr all,
allocmgr stats, allocmgr hint, brt, buffers, cfgmgr,
condvar, config, DACspy, dealloc, dealloc stats,
dealloc all, disk, dmapi, eventsExporter, files, filesets,
filocks, fs, fsck, fsmgr, ialloc, ialloc all, iallocmgr,
iallocmgr all, indblocks, indirect, instance, iocounters,
iohist, kthread, llfile, lock, log, lstat, malloc, mb,
mmap, mutex, mutex all, nsd, pcache, perfmon,
pgalloc, pgalloc all, pit, quorumState, quota, reclock,
reclockSleepers, reclockStats, res, sanergy, sgmgr, stripe,
sxlock, thread, thread all, threadstacks, threadstats,
tmstats, tokenmgr, tokens, tmcomm, updatelogger,
disk, verbs, version, vfsstats, vnodes, waiters, winsec,
or all
saferdump what Like the dump command but with safety locks. (Might hang)
eventsExporter Control event exporter
showCfgValue parm Show the value of the requested parameter
showtrace Show current trace levels and trace flag settings
showprocs Display the process table
vfsstats [keyword] Display vfs statistics. Keywords are enable, disable,
reset, show
verifytrace Verify trace levels and trace flag settings
trace class n Set level for given trace class to n, where "class" can be:
alloc, allocmgr, basic, brl, cleanup, cmd, defrag,
dentryexit, disk, dmapi, ds, errlog, fs, fsck,
kentryexit, io, klockl, ksvfs, lock, log, malloc, mb,
memmgr, mnode, msg, mutex, perfmon, pgalloc, pin, pit,
quota, sp, tasking, thread, tm, ts, user1, user2, vnode,
vnop, block, dentry, ialloc, file, super, shared, nsd,
disklease, smb, eventsExporter, sec, sanergy, kernel,
mmpmon, vdisk, rdma, pcache, vdb, vhosp, or all
shutdown -or- sd Shutdown the system
cleanup Clean up the shared segment, etc.
quorum reset or n Set quorum to value n or reset
tokenmgr Token manager command
recOrient create/{open inodeNum} create/open record oriented file and run debug function
dumpmem addr [len] [width]
Dump memory at address addr (hex) for length len (decimal)
using given word width
test what Invoke test routine in mmfsd. The "what" string is
interpreted by the daemon
errlog on/off Activate or deactivate error logging
errlog query Display error logging info
quiesce Disable new sessions
resume Enable new sessions
nomessages Accept no session messages at all
resume thread Resume the thread with the given address
signalcond cond Signal the condition variable with the given address
sleep n.m Sleep for requested number of seconds (floating point
number, so fractional seconds are allowed.) Sleeps the
mmfsadm command parser, not the daemon.
writecore [type] Write a core dump without terminating the daemon.
graceperiod [t] Start grace period for t seconds.
set t to 0 to get default grace period.
exit, quit -or- q Terminate this program
Ссылки по теме
- GPFS V3.3 Advanced Administration Guide
- GPFS V3.3 Administration and Programming Reference
- GPFS V3.3 Concepts, Planning, and Installation Guide
- GPFS V3.3 Problem Determination Guide
- GPFS V3.3 Data Management API Guide
- Linux Clustering with CSM and GPFS Linux Clustering with CSM and GPFS
- General Parallel File System (GPFS) Forum
- General Parallel File System — Announce (GPFS — Announce) Forum
- Disaster Recovery with General Parallel File System
- Disaster Recovery with General Parallel File System
- GPFS@LOR
- GPFS@Ubuntu
- GPFS@IBM wiki