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

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

    Это вторая часть статьи о работе 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.

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

    Alawar Entertainment
    53,00
    Компания
    Поделиться публикацией

    Комментарии 29

      –1
      Странно, в моих инсталляциях PVE, включая ядро почему-то на Debian'е основан.
        +2
        Ядро PVE основано на ядре проекта OpenVZ, которое, в свою очередь, основано на RedHat-ядре.

        root@srv01-vmx:~# zless /usr/share/doc/pve-kernel-`uname -r`/changelog.Debian.gz
        

        А основа системы — да, Debian.
          0
          А по моему у них чистое RH ядро, когда были проблемы с bouding на серверах после обновления ядра, косяк оказался в патчи от RH. Хотя я тут не эксперт, просто на форуме как раз проблему обсуждали и как то врезалось в память.
            +3
            Они используют ядро от OpenVZ, которое слегка патчат.
            OpenVZ берут RedHat-ядро, которое серьезно патчат :)

            В /usr/share/doc/pve-kernel-`uname -r`/changelog.Debian.gz все написано.
              0
              winduzoid, не только вам, но и остальным собравшимся.
              Ядро с дистрибутивом не путаете?
              Из первых уст: «ядро RH cлишком глючное, чтобы его использовать в Proxmox, но допилить его было проще. Как только появится время, поделки RedHat будут полностью исключены». «Проще» исходит из того, что KVM под крылом RedHat, не более
                +2
                Я вас не понял :)
                Ядро с дистрибутивом не путаю.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Вот разработчики что говорят на самом деле.
            0
            Скажите, я вот немного не понял. Зачем вам GFS?
            Так же не понятно с multipath. У нас проавда не iscsi а fiberchannel и много машин.
            Все машинны видят массив общий с FB, а уже при создании самих виртуальных машин используется LVM Group.

            Руки добраться до GlusterFS и Ceph, так и не дошли :)
              0
              Все машинны видят массив общий с FB, а уже при создании самих виртуальных машин используется LVM Group.

              Кластерная файловая система обычно нужна для того, чтобы можно было диспетчеризовать записи на общее хранилище. Иначе как все доступающиеся к данныи на общем сторадже системы узнают, что одна из них изменила байт в совместно используемых данных?
                0
                GFS2. Потому что он работает. И потом, при наличии под рукой работающего RedHat-кластера самое логичное — задействовать их же файловую систему :)

                Что вас смутило в multipath? Если у нас есть один и тот же iSCSI-таргет, приходящий по двум разным интерфейсам — грех не задействовать их оба :) Да, без multipath можно было бы обойтись. Но реализация была бы сложнее. Для балансировки нагрузки на хранилище часть машин пришлось бы цеплять на один интерфейс, часть — на другой. К тому же, хранилище умеет при выходе из строя одного из контроллеров переключать его нагрузку на выживший контроллер. В этом случае multipath сильно поможет не упасть всему кластеру.
                  0
                  Я как то проще сделал.

                  У нас MSA 2000, FB, Куча машин подключенных к ним. Каждый кластера видит все разделы на MSA — присоединим его LVM GROUP, и уже раздел задействуем для виртуальных машин.

                  Зачем надо и самое главное ГДЕ? использовать GFS2 я ка кто не могу понять.
                  storage с тестовой машины.
                    0
                    Вы используете OpenVZ в вашем окружении?
                      0
                      нет. Хотя у меня только мысль сейчас проскользнула, что наверно для openvz :)
                        0
                        Именно :)
                          0
                          Да я как всегда по диагонали :)

                          И как GFS2? Просто года 2 назад, мы отказались от нее в пользу ocfs2. Было с gfs2 очень много проблем, в частности с журналом.
                            0
                            Нам нравится. Проблем с журналом не наблюдали. Ну и за два года очень много всего изменилось. GFS2 сейчас признана стабильной RedHat-ом. Они декларируют ее поддержку в RHEL.

                            ocfs2 мы пока не трогали. В Proxmox ее нет, а пересобирать ядро специально для нее пока не хочется. Но пробовать будем.
                              0
                              Думаю не надо. У OCFS для RH все осталось как и два года назад. :)
                              oss.oracle.com/projects/ocfs2/files/RedHat/RHEL5/x86_64/1.4.9-1/

                              Такой подход мне не очень нравится.

                              Я вот думаю все же осилить и сделать ceph (proxmox его официально планирует поддерживать) и glusterfs — его можно попробовать с proxmox связать через nfs :)
                                0
                                Ну мы начали с gfs2 потому что она единственная, по сути, без бубна поддерживает работу со standalone-хранилищем. Для всего остального нужны более сложные схемы (серверы журналов, полноценные ОС на стораджах и пр.).

                                Мы сейчас начинаем раздумывать над реплицируемым между датацентрами хранилищем. Ну и параллельно еще копаем в стороны. :)
                                  0
                                  И я думаю правильно сделали. Хотя с OCFS2 кроме как смена ядра, проблем особых не было.

                                  Ну самый лучший способ репликации, это средствами самого MSA. Правда насколько я помню, MSA не умеет делать snapshot куда то во вне, для этого лучше подходит EVA. Eva вообще вкусная штука.

                                  Еще как вариант у GFS есть возможность делать репликации между ЦОД, умеет ли ceph не знаю.
                                  Если работаете в основном с OpenVZ, то у них есть своя ФС для контейнеров. В последних версиях они научились мигрировать состояние сетевых сокетов итд итп. В общем очень много плюшек.
                                    –1
                                    > Eva вообще вкусная штука.
                                    Это если не пробовать ничего слаще морковки :)
                                    0
                                    Вот еще один довыд не использовать ocfs2 :)

                                    forum.proxmox.com/threads/7247-New-2.6.32-Kernel-%28pvetest%29?p=41283#post41283

                                    Может конечно что то поменялось, но лучше побродить по форуму.
                                      0
                                      Да, мы поэтому пока на ocfs2 и не смотрели. Там все так же до сих пор, мне кажется.
                                        0
                                        Мне кажется для такого проекта как Proxmox освоить технологию «ocfs2» всё же нужно.
                                        Ведь потенциального пользователя proxmox может устраивать всё, кроме работы с дисковыми хранилищами.

                                        Ещё вопрос в тему: Скажите, а поддержка DRBD есть? Если есть и она работает нормально, то где можно почитать о том, как всё это работает вместе с «fenceing» и как настроена защита от SplitBrain. Спасибо.
                                          0
                                          Там проблема в том, что Оракл перестал поддерживать RedHat-ядра. Из-за этого работа в Proxmox с ocfs2 затруднена.

                                          Поддержка DRBD есть. Мы не пробовали.
                                          Вот здесь написано про fencing в связке c DRBD: pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
                    0
                    Или вы спрашиваете, зачем нам вообще кластерная FS?
                    0
                    Они вообще все такое кластерное и не только выпилили из ядра, оставили только GFS2, модифицированные corosync, cman и drbd.
                    На все вопросы на форуме отвечают: «извините, у нас другая концепция, мы будем ее придерживаться, и этот модуль мы включать не будем».
                    Так что если у вас proxmox, ничего другого и не выйдет ))

                    ploop очень радует, не пробовали его? Его бы еще запилить для ceph, было бы счастье. Для kvm ceph неплохо уже работает.

                      0
                      Нет, ploop пока не пробовали. Но в ближайших планах есть.
                        0
                        Ну так проблема в том, что они используют ядро от openvz, а они от RH. Почти, что игла.

                        Сейчас на сайте openvz — proxmox ставится как bare metal решение openvz.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое