АСР NetUP UTM 5+
Конвергентная биллинговая система для операторов связи и корпоративного сектора.
Более 4000 инсталляций по всему миру. Сертификат ССС.
Доступ в интернет
Помегабайтно и безлимитно. Шейпирование, блокировки.
Телефония
Классическая и VoIP. Межоператорские взаиморасчеты.
HOTSPOT
Публичный доступ к сети. Wi-Fi по паспорту. Captive-портал.
Телевидение
Пакетирование каналов. Интеграция с Middleware, CAS. Агентские схемы.
Внешние коллекторы
Учет трафика в распределеных сетях.
Прием платежей
От кассира до интернет-эквайринга.
Премущества
Надежность
Более 10 000 000 абонентов обсчитываются системами UTM5 и UTM 5+
Универсальность
UTM 5+ использует стандартные протоколы и может эксплуатироваться с оборудованием любых производителей
Открытость
REST API для реализации дополнительного функционала силами клиента, автоматизации и интеграции со сторонними системами
Многофилиальность
Возможность изолирования абонентов различных подразделений при сохранении единой базы абонентов
Один ко многим
Каждый абонент может иметь несколько лицевых счетов, к каждому из которых может быть подключено несколько услуг
Безопасность
Создание системных пользователей с ограниченными правами для предотвращения ошибок или злоупотреблений
Особый подход
Индивидуальные условия работы для каждого абонента
Разнообразие услуг
Периодические, например, софт по подписке, хостинг, аренда оборудования. И разовые — турбокнопка, выезд к клиенту.
Личный кабинет абонента
А также tray-приложение с полной информацией о состоянии счета, возможностях пополнения и добавления услуг.
Развертывание биллинговой системы NetUP UTM5 часть 1
Под катом будет рассказано о настройке отказоустойчивого кластера, для запуска биллинговой системы NetUР UTM5, настройке шифрования и резервного копирования «ценных» данных.
Почему именно кластер?
Надеюсь, что я не открою большой секрет сказав, что биллинг должен быть максимально отказоустойчивым. А как известно основной способ добиться отказоустойчивости — избыточность. Добиваться этого будем посредством Ganeti.
Ganeti — система управления кластером виртуализации, построенном на основе систем виртуализации Xen или KVM. Использует DRBD для организации отказоустойчивых кластеров.
Для претворения в жизнь данной идеи нам потребуется 2 сервера, с предустановленным Debian lenny. Фактически на одном «будет запущен биллинг», второй будет находиться в горячем резерве.
Пускай один из серверов, будет node1, тогда оставшийся будет node2.
Все ниже перечисленное необходимо проделать на каждой из нод.
Начнем с разбиения дисков. Предполагается, что у нас в каждом сервер стоит 2 одинаковых жестких диска. При установке я создал программный «зеркальный» рейд размером 2 гб и на него установил базовую систему.
Выглядит это так.
# 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 гб, размеры создаваемого массива но обеих нодах должны обязательно совпадать.
# 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
# mdadm —create /dev/md1 —level 1 —raid-devices=2 /dev/hda2 /dev/hdb2
Прописываем в автозагрузку.
# mdadm —examine —scan|grep -v /dev/md0 >> /etc/mdadm/mdadm.conf
Добавляем в /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
# 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
(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)
## Xen hypervisor options to use with the default Xen boot option
# xenhopt=dom0_mem=256M
Обновляем загрузчик
node1:
Перезагружаемся и если все работает приступаем к созданию кластера.
Устанавливаем DRBD
# apt-get install drbd8-modules-2.6.26-2-xen-686 drbd8-utils
Добавляем в автозагрузку
# echo drbd minor_count=64 >> /etc/modules
Загружаем модуль (конечно, если Вы не перезагрузили ноду)
# modprobe drbd minor_count=64
filter = [ «r|/dev/cdrom|», «r|/dev/drbd5+|» ]
Теперь все готово, для инициации кластера. Пускай, владельцем кластера будет node1.
На первой ноде (node1) выполняем команду
# gnt-cluster init -b eth0 -g xenvg —master-netdev eth0 cluster1.name.org
Добавляем node2 в кластер.
# gnt-node add node2.name.org
Если все прошло успешно, создаем instance (виртуальную машину в которой и будет работать биллинг)
# 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 проведем несколько манипуляций.
# gnt-instance shutdown inst1.name.org
node1:
# gnt-instance startup —extra «xencons=tty1 console=tty1» inst1.name.org
Только теперь мы сможем получить полноценный доступ
# 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, но для миграции нам необходимо погасить машину(размонтировать шифрованный раздел), иначе данные на зашифрованном разделе не будут полностью синхронизированы.
Устанавливаем необходимые пакеты.
# apt-get install loop-aes-modules-2.6.26-2-xen
inst1:
# apt-get install loop-aes-utils
Выгружаем «старый» модуль(можете перезагрузить instance, что бы уже наверняка)
Загружаем обновленный модуль
Создаем файл для зашифрованного раздела
# dd if=/dev/zero of=/var/encrypt_file bs=4k count=10000
Монтируем созданный файл. Рекомендаций по пасс фразе давать не буду, это дело вкуса.
# losetup -e AES256 /dev/loop1 /var/encrypt_file
Создаем файловую систему, при нашем уровне дублирования ext2 будет достаточно
# mkfs -t ext2 /dev/loop1
# losetup -d /dev/loop1
Пример монтирование зашифрованного раздела
# mount volume -o loop=/dev/loop1,encryption=AES256 /var/secure/ -t ext2
Шифрование swap файла на Ваше усмотрение, но учтите — паранойя заразная штука.