Здравствуйте!

Это вторая часть статьи о работе c кластерным хранилищем в Proxmox (первую можно найти тут ^[1]). Сегодня поговорим о подключении хранилища к кластеру.

В качестве кластерной системы мы используем Global File System 2 ^[2].

GFS2 в Proxmox функциональна, но разработчики Proxmox официально не поддерживают ее. Однако ядро Proxmox основано на RedHat-ядре RHEL6x ^[3]-ветки. То есть поддержка GFS2 в ядре весьма зрелая. Обвязка тоже ведет себя вполне стабильно, за исключением нескольких нюансов, о которых я расскажу позже. Сам пакет gfs2-utils представляет собой практически не измененную (есть лишь патчи ^[4] в стартовых скриптах на предмет подгона под дебиановскую специфику) стабильную редхатовскую версию gfs2-utils-3.1.3 ^[5]

Пакет gfs2-utils появился в Proxmox в феврале 2012 года ^[6]. Родной же дебиановский пакет gfs2-tools дико конфликтует (что неудивительно) со всем RedHat-кластером из Proxmox, поэтому до Proxmox версии 2.0 из коробки GFS2 была совершенно неюзабельна ^[7].

Итак, огромным плюсом является то, что фундамент для взведения GFS2 в Proxmox уже выстроен.

В качестве iSCSI-хранилища мы используем HP MSA 2012i ^[8]. Эта машина представляет собой отказоустойчивое решение, основанное на использовании массива жестких дисков, подключенного к двум независимым raid-контроллерам. Каждый raid-контроллер имеет два интерфейса для передачи данных, в рамках данной статьи это интересно тем, что контроллер не умеет эти интерфейсы объединять ^[9]. Для загрузки обоих интерфейсов контроллера мы будем использовать multipath ^[10]. Создание томов я описывать не буду. Тома создаются без какой-либо авторизации (об особенностях авторизованного подключения из Proxmox к iSCSI я расскажу позже).

Порядок действий

Следующие действия производятся на каждой ноде кластера.

Желательно настроить jumbo frames ^[11].

Для работы с несколькими сетевыми интерфейсами хранилища настраиваем multipath. Создаем файл /etc/multipath.conf следующего содержания:

blacklist {
devnode "cciss"
}

defaults {
user_friendly_names yes
}

В blacklist попадают блочные устройства, которые должны быть исключены из обработки (локальные диски). В нашем случае это cciss-устройства, представляющие собой тома HP Smart Array контроллера, обслуживаемого модулем ядра cciss.

Параметр "user_friendly_names" позволяет создавать user-friendly устройства в /dev/mapper вида "mpath0-part1".

Устанавливаем недостающие пакеты:

root@pve03:~# apt-get install multipath-tools gfs2-utils open-iscsi parted

Установленный multipath сразу взлетает и радостно подхватывает конфиг.

Подготавливаем open-iscsi-демон. Нам надо автоматически подключать доступные таргеты при старте системы. Правим файл /etc/iscsi/iscsid.conf. В нем меняем строку:

node.startup = manual

на

node.startup = automatic

Настраиваем LVM. Переключаем способ блокировки с файловой на кластерную.

root@pve03:~# lvmconf --enable-cluster

Разрешаем старт CLVM. Файл /etc/default/clvm:

START_CLVM=yes

Стартуем CLVM. Если у нас не настроен fenced (см. предыдущую статью ^[1]), получим ошибку:

root@pve03:~# service clvm start
Starting Cluster LVM Daemon: clvmclvmd could not connect to cluster manager
Consult syslog for more information
 failed!

CLVM не работает, если наша нода не принадлежит к fence-домену.

Подключаем хранилище к кластеру.

В админке говорим "Добавить iSCSI-target". После этого все ноды кластера должны увидеть несколько (в нашем случае — два) блочных устройств, а multipath должен сделать из них одно, и положить в каталог /dev/mapper.

Убеждаемся, что multipath-устройство /dev/mapper/mpath0 — это нужный нам iSCSI-том.

На одной из машин размечаем хранилище:

root@pve03:~# parted /dev/mapper/mpath0 mkpart cluster01 0% 512G
root@pve03:~# parted /dev/mapper/mpath0 mkpart kvm01 512G 100%

В приведенном примере том разбит на два раздела: один раздел объемом 512G, и второй, занимающий оставшееся место на томе.

Том kvm01 нам понадобится в дальнейшем, когда займемся настройкой хранилища для KVM.

Рестартуем multipath-демон:

root@pve03:~# service multipath-tools restart

На той же машине создаем две кластерные группы томов:

root@pve03:~# vgcreate -c y CLUSTER01 /dev/mapper/mpath0-part1
root@pve03:~# vgcreate -c y KVM01 /dev/mapper/mpath0-part2

Параметр "-c" указывает на то, что группа томов — кластерная.

В принципе, можно было создать всего одну группу томов, и держать в ней и разделы для KVM-машин, и GFS2-раздел. Здесь дело вкуса.

В группе CLUSTER01 создаем Logical Volume:

root@pve03:~# lvcreate -n STORAGE -l +100%Free CLUSTER01

На всех нодах кластера этот Logical Volume должен быть виден:

root@srv-01:~# lvscan
  ACTIVE            '/dev/CLUSTER01/STORAGE' [976.56 GiB] inherit
  ACTIVE            '/dev/pve/swap' [4.00 GiB] inherit
  ACTIVE            '/dev/pve/root' [16.75 GiB] inherit
  ACTIVE            '/dev/pve/data' [38.21 GiB] inherit

Говорим CLVM, какие Volume Groups надо активировать / деактивировать при запуске / остановке:

Файл /etc/default/clvm:

LVM_VGS="CLUSTER01 KVM01"

Все готово к созданию кластерной файловой системы. Смотрим, какое имя у нашего кластера:

root@srv-01:~# pvecm status | grep "Cluster Name"
Cluster Name: alapve
root@srv-01:~# 

Имя кластера необходимо указать при создании FS.

На одной из нод кластера форматируем FS:

root@pve03:~# mkfs.gfs2 -t alapve:storage01 -j 3 /dev/mapper/CLUSTER01-STORAGE

Здесь:

• "-t alapve:storage01" — имя таблицы блокировок.
  • alapve — имя кластера,
  • storage01 — уникальное название файловой системы.
• "-j 3" — количество журналов, которые необходимо создать при создании FS. Обычно равно количеству нод в кластере. Для каждого хоста, монтирующего FS, необходим свой журнал.

Смотрим UUID нашей FS:

root@srv-01:~# blkid /dev/CLUSTER01/STORAGE
/dev/CLUSTER01/STORAGE: LABEL="alapve:storage01" UUID="8b3f1110-8a30-3f2d-6486-a3728baae57d" TYPE="gfs2" 

На каждой ноде создаем запись в fstab для монтирования FS:

root@srv-01:~# echo "UUID=8b3f1110-8a30-3f2d-6486-a3728baae57d /mnt/cluster/storage01 gfs2 noatime,_netdev 0 0" >> /etc/fstab

Создаем каталог /mnt/cluster/storage01, монтируем в него FS:

root@srv-01:~# mount /mnt/cluster/storage01

Здесь есть один момент. При выключении системы, в процессе остановки open-iscsi-демона в Proxmox вызывается скрипт /etc/init.d/umountiscsi.sh. Он занимается тем, что отключает примонтированные по iSCSI файловые системы. Для поиска таких систем он использует довольно сложную логику, которая иногда дает сбой, из-за чего происходит попытка отмонтировать больше, чем надо, либо наоборот — не отмонтируется нужное. Например, мы сталкивались с попытками отмонтирования корневой файловой системы. Разумеется, у него это сделать не получалось, после чего OS входила в состояние перманентного ожидания: без остановки iSCSI-таргетов система не может перезагрузиться, а umouniscsi не может отмонтировать все iSCSI-FS из-за того, что причисляет к их списку корень.

Мы не стали глубоко копаться в логике umountiscsi.sh. Было решено, что полагаться на umountiscsi.sh не стоит, примонтированными по iSCSI томами мы будем управлять сами, а роль umountiscsi.sh будет сводиться к бравому рапортированию о том, что "Все системы отмонтированы, мой генерал!".

Итак, в /etc/init.d/umountiscsi.sh меняем секцию "stop". Было:

    stop|"")
        do_stop
	;;

Стало:

    stop|"")
        #do_stop
        exit 0
	;;

Теперь система будет складываться правильно. Правда, при одном условии — на момент остановки в системе не должно быть примонтированных по iSCSI файловых систем. Если не хочется отключать FS вручную, то, например, ее можно отмонтировать в /etc/init.d/clvm перед вызовом "stop". К этому моменту все виртуальные машины уже (должны быть) погашены. Мы у себя не надеемся на это, и перед рестартом отмонтируем FS вручную.

Нам осталось только в админке Proxmox создать общее хранилище типа "Directory", указать ему путь к каталогу с подмонтированной FS, и выставить флажок "общедоступно". Все созданные на этом хранилище контейнеры смогут спокойно мигрировать между нодами.

О проблемах

После нескольких месяцев тестирования мы пару раз словили kernel panic в gfs2-модуле. Fencing работает отлично, поэтому сначала мы даже не поняли, что происходит, просто несколько раз перезагрузились ноды. После перехода на новую версию ядра (2.6.32-17-pve) пока зависаний не было. Новое ядро основано на 2.6.32-279.14.1.el6-ядре из RHEL6. Там есть кое-какие правки, касающиеся gfs2.

Перейдем к KVM

Здесь все много проще. Группа томов у нас уже создана, сталось натравить на нее Proxmox. В админке создаем хранилище типа "LVM Group", в поле "основное хранилище" указываем "существующие группы разделов", в поле "группа разделов" выбираем KVM01, и выставляем флажок "общедоступно". Для KVM-машин в этом разделе система будет автоматически создавать логические тома.

Пожалуй, стоит закругляться. В следующей части я расскажу о том, как можно пытаться в OpenVZ жить на сетевом хранилище без кластерной FS, о некоторых нюансах в работе с сетевыми хранилищами, плюс некоторые решения по автоматизации и оптимизации жизни в OpenVZ.

Спасибо за внимание!

Автор: winduzoid

Источник ^[12]