Pull to refresh

Кластерное хранилище в Proxmox. Часть вторая. Запуск

«Alawar Entertainment» corporate blog
Здравствуйте!

Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.

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

  1. У нас есть блочное устройство, отдаваемое по сети, к которому будут иметь доступ несколько хостов одновременно. Для того, чтобы эти хосты не подрались за место на устройстве, нам нужен CLVMClustered Logical Volume Manager. Это то же самое, что LVM, только Clustered. Благодаря CLVM каждый хост имеет актуальную информацию (и может ее безопасно изменять, без риска нарушить целостность) о состоянии LVM-томов на Shared Storage. Логические тома в CLVM живут точно так же, как в обычном LVM. В логических томах находятся либо KVM-образы, либо кластерная FS.
  2. В случае с OpenVZ у нас есть логический том, на котором расположена файловая система. Одновременная работа нескольких машин с некластерной файловой системой ведет к неминуемым ошибкам в работе всего — это лебедь, рак и щука, только хуже. Файловая система обязательно должна знать о том, что она живет на общем ресурсе, и уметь работать в таком режиме.

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

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

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

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

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

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


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

Желательно настроить jumbo frames.

Для работы с несколькими сетевыми интерфейсами хранилища настраиваем 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 (см. предыдущую статью), получим ошибку:

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 mklabel gpt
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-таргетов система не может перезагрузиться, а umountiscsi не может отмонтировать все 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, и выставить флажок "общедоступно". Все созданные на этом хранилище OpenVZ-контейнеры смогут спокойно мигрировать между нодами.

О проблемах


После нескольких месяцев тестирования мы пару раз словили 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.

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

Tags: proxmoxclusteropenvzgfs2iscsi
Hubs: «Alawar Entertainment» corporate blog
Total votes 13: ↑11 and ↓2 +9
Comments 29
Comments Comments 29

Top of the last 24 hours

Information

Founded
Location
Россия
Website
company.alawar.ru
Employees
201–500 employees
Registered