Здравствуйте!
Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.
В начале хочу привести выдержку из прошлой статьи, чтобы никто не забыл, зачем нам весь огород с кластером:
В качестве кластерной файловой системы мы используем 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 попадают блочные устройства, которые должны быть исключены из обработки (локальные диски). В нашем случае это cciss-устройства, представляющие собой тома HP Smart Array контроллера, обслуживаемого модулем ядра cciss.
Параметр "user_friendly_names" позволяет создавать user-friendly устройства в /dev/mapper вида "mpath0-part1".
Устанавливаем недостающие пакеты:
Установленный multipath сразу взлетает и радостно подхватывает конфиг.
Подготавливаем open-iscsi-демон. Нам надо автоматически подключать доступные таргеты при старте системы. Правим файл /etc/iscsi/iscsid.conf. В нем меняем строку:
на
Настраиваем LVM. Переключаем способ блокировки с файловой на кластерную:
Разрешаем старт CLVM. Файл /etc/default/clvm:
Стартуем CLVM. Если у нас не настроен fenced (см. предыдущую статью), получим ошибку:
CLVM не работает, если наша нода не принадлежит к fence-домену.
Подключаем хранилище к кластеру.
В админке говорим "Добавить iSCSI-target". После этого все ноды кластера должны увидеть несколько (в нашем случае — два) блочных устройств, а multipath должен сделать из них одно, и положить в каталог /dev/mapper.
Убеждаемся, что multipath-устройство /dev/mapper/mpath0 — это нужный нам iSCSI-том.
На одной из машин размечаем хранилище:
В приведенном примере том разбит на два раздела: один раздел объемом 512G, и второй, занимающий оставшееся место на томе.
Том kvm01 нам понадобится в дальнейшем, когда займемся настройкой хранилища для KVM.
Рестартуем multipath-демон:
На той же машине создаем две кластерные группы томов:
Параметр "-c" указывает на то, что группа томов — кластерная.
В принципе, можно было создать всего одну группу томов, и держать в ней и разделы для KVM-машин, и GFS2-раздел. Здесь дело вкуса.
В группе CLUSTER01 создаем Logical Volume:
На всех нодах кластера этот Logical Volume должен быть виден:
Говорим CLVM, какие Volume Groups надо активировать / деактивировать при запуске / остановке:
Файл /etc/default/clvm:
Все готово к созданию кластерной файловой системы. Смотрим, какое имя у нашего кластера:
Имя кластера необходимо указать при создании FS.
На одной из нод кластера форматируем FS:
Здесь:
Смотрим UUID нашей FS:
На каждой ноде создаем запись в fstab для монтирования FS:
Создаем каталог /mnt/cluster/storage01, монтируем в него FS:
Здесь есть один момент. При выключении системы, в процессе остановки 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".
Было:
Стало:
Теперь система будет складываться правильно. Правда, при одном условии — на момент остановки в системе не должно быть примонтированных по 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.
Здесь все много проще. Группа томов у нас уже создана, осталось натравить на нее Proxmox. В админке создаем хранилище типа "LVM Group", в поле "основное хранилище" указываем "существующие группы разделов", в поле "группа разделов" выбираем KVM01, и выставляем флажок "общедоступно". Для KVM-машин в этом разделе система будет автоматически создавать логические тома.
Пожалуй, стоит закругляться. В следующей части я расскажу о том, как можно пытаться в OpenVZ жить на сетевом хранилище без кластерной FS, о некоторых нюансах в работе с сетевыми хранилищами, плюс некоторые решения по автоматизации и оптимизации жизни в OpenVZ.
Спасибо за внимание!
Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.
В начале хочу привести выдержку из прошлой статьи, чтобы никто не забыл, зачем нам весь огород с кластером:
В нашем случае проблема организации общего хранилища сводится к двум аспектам:
- У нас есть блочное устройство, отдаваемое по сети, к которому будут иметь доступ несколько хостов одновременно. Для того, чтобы эти хосты не подрались за место на устройстве, нам нужен CLVM — Clustered Logical Volume Manager. Это то же самое, что LVM, только Clustered. Благодаря CLVM каждый хост имеет актуальную информацию (и может ее безопасно изменять, без риска нарушить целостность) о состоянии LVM-томов на Shared Storage. Логические тома в CLVM живут точно так же, как в обычном LVM. В логических томах находятся либо KVM-образы, либо кластерная FS.
- В случае с 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.
Спасибо за внимание!
- Кластерное хранилище в Proxmox. Часть первая. Fencing
- Кластерное хранилище в Proxmox. Часть вторая. Запуск
- Кластерное хранилище в Proxmox. Часть третья. Нюансы
