Развертывание биллинговой системы NetUP UTM5 часть 1

    Под катом будет рассказано о настройке отказоустойчивого кластера, для запуска биллинговой системы NetUР UTM5, настройке шифрования и резервного копирования «ценных» данных.

    Почему именно кластер?
    Надеюсь, что я не открою большой секрет сказав, что биллинг должен быть максимально отказоустойчивым. А как известно основной способ добиться отказоустойчивости — избыточность. Добиваться этого будем посредством Ganeti.
    Ganeti — система управления кластером виртуализации, построенном на основе систем виртуализации Xen или KVM. Использует DRBD для организации отказоустойчивых кластеров.
    Для претворения в жизнь данной идеи нам потребуется 2 сервера, с предустановленным Debian lenny. Фактически на одном «будет запущен биллинг», второй будет находиться в горячем резерве.
    Пускай один из серверов, будет node1, тогда оставшийся будет node2.
    Все ниже перечисленное необходимо проделать на каждой из нод.
    Начнем с разбиения дисков. Предполагается, что у нас в каждом сервер стоит 2 одинаковых жестких диска. При установке я создал программный «зеркальный» рейд размером 2 гб и на него установил базовую систему.
    Выглядит это так.

    node1:~# fdisk -l /dev/hda
    Device Boot Start End Blocks Id System
    /dev/hda1 1 243 1951866 fd Linux raid autodetect
    node1:~# fdisk -l /dev/hdb
    /dev/hdb1 1 243 1951866 fd Linux raid autodetect
    node1:~# cat /proc/mdstat
    Personalities : [raid1]
    md0 : active raid1 hda1[0] hdb1[1]
    1951744 blocks [2/2] [UU]


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

    node1:~# fdisk -l /dev/hda
    /dev/hda1 1 243 1951866 fd Linux raid autodetect
    /dev/hda2 244 865 4996215 83 Linux
    node1:~# fdisk -l /dev/hdb
    /dev/hdb1 1 243 1951866 fd Linux raid autodetect
    /dev/hdb2 244 865 4996215 83 Linux

    Создаем рейд.

    node1:~# mdadm --create /dev/md1 --level 1 --raid-devices=2 /dev/hda2 /dev/hdb2

    Прописываем в автозагрузку.

    node1:~# mdadm --examine --scan|grep -v /dev/md0 >> /etc/mdadm/mdadm.conf

    Добавляем в /etc/hosts описание хостов, нужно для корректной авторизации

    node1:~# mcedit /etc/hosts

    192.168.0.111 node1.name.org node1
    192.168.0.112 node2.name.org node2
    192.168.0.113 cluster1.name.org cluster1
    192.168.0.114 inst1.name.org inst1

    Описание настройки интерфейсов опущу, я верю что вы справитесь с этим самостоятельно.

    Устанавливаем пакет LVM2

    node1:~# apt-get install lvm2
    node1:~# pvcreate /dev/md1
    Physical volume "/dev/md1" successfully created
    node1:~# vgcreate xenvg /dev/md1
    Volume group «xenvg» successfully created

    Ставим ganeti
    node1:~# apt-get install ganeti

    Настраиваем Xen

    node1:~# mcedit /etc/xen/xend-config.sxp

    (xend-relocation-server yes)
    (xend-relocation-port 8002)
    (xend-relocation-address '')
    (network-script network-bridge)
    #(network-script network-dummy)
    (vif-script vif-bridge)
    (dom0-min-mem 0)

    Настраиваем grub

    node1:~# mcedit /boot/grub/menu.lst

    ## Xen hypervisor options to use with the default Xen boot option
    # xenhopt=dom0_mem=256M

    Обновляем загрузчик
    node1:~# /sbin/update-grub

    Перезагружаемся и если все работает приступаем к созданию кластера.
    Устанавливаем DRBD

    node1:~# apt-get install drbd8-modules-2.6.26-2-xen-686 drbd8-utils

    Добавляем в автозагрузку

    node1:~# echo drbd minor_count=64 >> /etc/modules

    Загружаем модуль (конечно, если Вы не перезагрузили ноду)

    node1:~# modprobe drbd minor_count=64

    Настраиваем LVM

    node1:~# mcedit /etc/lvm/lvm.conf

    filter = [ «r|/dev/cdrom|», «r|/dev/drbd[0-9]+|» ]

    Теперь все готово, для инициации кластера. Пускай, владельцем кластера будет node1.
    На первой ноде (node1) выполняем команду

    node1:~# gnt-cluster init -b eth0 -g xenvg --master-netdev eth0 cluster1.name.org

    Добавляем node2 в кластер.

    node1:~# gnt-node add node2.name.org

    Если все прошло успешно, создаем instance (виртуальную машину в которой и будет работать биллинг)

    node1:~# gnt-instance add -t drbd -n node2.name.org:node1.name.org -o debootstrap -s 2g --swap-size 128 -m 256 --kernel /boot/vmlinuz-2.6.26-2-xen-686 --ip 192.168.0.114 inst1.name.org

    И так, что данная команда предполагает.
    1.Мы создаем в кластере новую виртуальную машину именуемую inst1.name.org
    2.Выделив ей 2 гб диска, 128 мб своп файла и 256 мб оперативной памяти.
    3.Дистрибутив для виртуальной машины — Debian(debootstrap), ядро xen
    4.Обязательно прошу обратить внимание опцию -n. Она определяет какая нода будет главной, а какая будет находиться в резерве.
    Так запись node2.name.org:node1.name.org обозначает, что node2 основная, а node1 вспомогательная( в горячем резерве).
    Если владельцем кластера у нас является первая нода (node1), instance предпочтительнее запускать на второй ноде(node2). В случае выхода из строя первой ноды(node1), биллинг будет и дальше работать, как только первая нода(node1) вернется в строй — произойдет синхронизация сетевого рейда и штатная работа кластера будет восстановлена. При выходе из строя второй ноды(node2) мы сохраняем управление кластером и имеем возможность перенести instance на первую ноду(node1) с минимальным простоем, и спокойно вводить в строй вторую не опасаясь «split-brian».

    Для получения доступа к instance проведем несколько манипуляций.

    node1:~# gnt-instance shutdown inst1.name.org
    node1:~# gnt-instance startup --extra «xencons=tty1 console=tty1» inst1.name.org

    Только теперь мы сможем получить полноценный доступ

    node1:~# gnt-instance console inst1.name.org

    Список манипуляций «внутри» instance.(по умолчанию у root`а пустой пароль).
    Настраиваем сеть. (опять же надеюсь на Ваш интеллект, либо упорство)
    Настраиваем apt.
    Устанавливаем openssh-server и udev
    Добавляем в /etc/fstab строчку
    none /dev/pts devpts gid=5,mode=620 0 0

    echo inst1 > /etc/hostname (Настраиваем hostname)
    apt-get install locales (Ставим локали)
    dpkg-reconfigure locales (Конфигурируем локали)
    tasksel install standard (Доустанавливаем пакеты включенные в «стандартную сборку»)

    Первоначальная настройка кластера завершена.
    Рекомендую в обязательном порядке изучить документацию к ganeti. Вам должно быть ясно как переносить instance с ноды на ноду в штатном режиме, как перенести при аварии и т.д. Опять же в обязательном порядке необходимо составить памятку: как действовать в экстренной ситуации, заламинировать и повесить перед глазами, ибо аварии случаются редко, а мозг имеет тенденцию забывать.
    О чем стоит задуматься в первую очередь после запуска кластера? Лично мне кажется, что нужно быть предельно готовым к неожиданному визиту суровых мужчин в масках, которым очень тяжело отказать в чем либо. Готовность будет заключаться в шифровании всех ценных данных и их своевременном резервном копировании.
    Все дальнейшие настройки относятся непосредственно к виртуальной машине (instance).
    Начнем с шифрования. Осуществлять его будем таким образом. При старте instance загружается базовая система, далее система ожидает пасс фразы для монтирования файла с зашифрованным разделом, после чего запускаем базу данных, биллинг и прочие «нужные сервисы».
    Благодаря этому все храниться внутри instance, но для миграции нам необходимо погасить машину(размонтировать шифрованный раздел), иначе данные на зашифрованном разделе не будут полностью синхронизированы.
    Устанавливаем необходимые пакеты.

    inst1:~# apt-get install loop-aes-modules-2.6.26-2-xen
    inst1:~# apt-get install loop-aes-utils

    Выгружаем «старый» модуль(можете перезагрузить instance, что бы уже наверняка)

    inst1:~# modprobe -r loop

    Загружаем обновленный модуль

    inst1:~# insmod /lib/modules/2.6.26-2-xen/updates/loop.ko

    Создаем файл для зашифрованного раздела

    inst1:~# dd if=/dev/zero of=/var/encrypt_file bs=4k count=10000

    Монтируем созданный файл. Рекомендаций по пасс фразе давать не буду, это дело вкуса.

    inst1:~# losetup -e AES256 /dev/loop1 /var/encrypt_file

    Создаем файловую систему, при нашем уровне дублирования ext2 будет достаточно

    inst1:~# mkfs -t ext2 /dev/loop1

    Размонтируем файл

    inst1:~# losetup -d /dev/loop1

    Пример монтирование зашифрованного раздела

    inst1:~# mount volume -o loop=/dev/loop1,encryption=AES256 /var/secure/ -t ext2

    Шифрование swap файла на Ваше усмотрение, но учтите — паранойя заразная штука.

    Как организовать резервное копирование данных? Можно по крону запускать чудесные самописные скрипты бекапа. Либо подойти ответственно и настроить централизованную систему бекапов, например bacula, рекомендации по настройке и примеры можно посмотреть здесь Настройка и понимание Bacula. Бекапы лучше тоже хранить на зашифрованном разделе, а сам сервер с бекапами желательно держать где то далеко, в известном узкому кругу лиц месте, а для надежности можно его обильно присыпать голубиными какашками, что бы даже пнуть мыслей не возникало.
    Для резервного копирования базы данных советую добавить в описание задания (job) строки
    ClientRunBeforeJob = "/usr/local/bin/create_mysql_dump"
    ClientRunAfterJob = "/bin/rm -f /var/lib/bacula/mysql.dump"
    Нужно учитывать, что база данных имеет обыкновение разрастаться в размерах, из-за чего увеличивается время дампа базы. Для избежания данной проблемы можно воспользоваться функцией архивации таблиц, которая была реализована начиная со сборки 006. Логика простая, архивные таблицы храним в отдельной базе, для доступа ядра биллинга к архивным данным создаем представления(view) на архивные таблицы. Бекап делается ощутимо быстрее, так как сохраняется только структура вида, без самих данных. Данные из архивных таблиц можно не резервировать, достаточно хранить только 2 копии на случай пожара.

    Итогом всего вышеперечисленного может стать создание отказоустойчивый кластера, с увеличенной избыточностью дисковой подсистемы, возможностью географического разнесенния нод, шифрованием и резервным копированием ценных данных.
    P.S. Почему выбор пал на NetUР UTM5?
    Когда фирма купила лицензию, я сначала думал, что это из-за подробной документации, которой на момент приобретения (конец 2006 года) оказалось аж целых 260 страниц, правда он была откровенно сырой. Потом думал, что из-за грамотной тех. поддержки. Не спорю, поддержка оказалась на высоком уровне, но была исключительна «недружелюбна», что в купе с сырой документацией омрачало радость от приобретения «продукта» и растянуло переход больше чем на год. В итоге, все оказалось просто, наш директор съездил к своим друзьям, а как известно обезьянка будет с остервенением пожирать красные ягоды, только если она видит, как другие обезьянки делают тоже самое. Вот так вот мы стали гордыми обладателями данного «продукта».
    Если уже быть честным до конца, то «продукт» показал себя крайне капризным, мало документированным, но как оказалось при правильной настройке — весьма стабильным, так настроенная система без особых вмешательств проработала больше года, единственное, пришлось чистить базу.
    Поделиться публикацией

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

      0
      Мне будет очень полезно. Совсем недавно досталось это хозяйство. Самое время начать разбираться. Спасибо за такую подробную статью.
      Сами используем Debian, но не на кластере, а на обычном сервере. Нареканий тоже пока никаких не было. Удручает лишь интерфейс пользователя, написанный на яве.
        0
        Не понял, что именно удручает: интерфейс, или то, на чем он написан?
          0
          Ну, собственно и сам интерфейс и то, на чём он написан. Есть какие-то непонятные или запутанные вещи. Впрочем, это конечно индивидуально. А из-за явы он несколько громоздок и неповоротлив — издержки кроссплотформенности.
          В остальном как часы. Тоже уже больше года работает.
            +1
            У кроссплатформенности кроме издержек есть еще достоинства и они часто перевешивают. Я вообще не большой поклонник явы, но на ней написано множество достойных вещей (к интерфейсу UTM5 это, в общем, не относится) и главное КАК написано. Написать гуано можно на чем угодно.
              0
              Бесспорно) В первую очередь это вопрос прямоты рук или извилин в голове, как угодно.
            0
            Вот меня удручает интерфейс, который выглядит как плохой курсач по программированию. На редкость нелогичный GUI местами.
          0
          Одно но. 2.6.26-2 является не самым лучшим ядром для xen, об этом неоднократно было написано в рассылке xen.

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

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