Pull to refresh

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

System administration *
Под катом будет рассказано о настройке отказоустойчивого кластера, для запуска биллинговой системы 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 страниц, правда он была откровенно сырой. Потом думал, что из-за грамотной тех. поддержки. Не спорю, поддержка оказалась на высоком уровне, но была исключительна «недружелюбна», что в купе с сырой документацией омрачало радость от приобретения «продукта» и растянуло переход больше чем на год. В итоге, все оказалось просто, наш директор съездил к своим друзьям, а как известно обезьянка будет с остервенением пожирать красные ягоды, только если она видит, как другие обезьянки делают тоже самое. Вот так вот мы стали гордыми обладателями данного «продукта».
Если уже быть честным до конца, то «продукт» показал себя крайне капризным, мало документированным, но как оказалось при правильной настройке — весьма стабильным, так настроенная система без особых вмешательств проработала больше года, единственное, пришлось чистить базу.
Tags:
Hubs:
Total votes 10: ↑6 and ↓4 +2
Views 9.2K
Comments Comments 7