Мы уже писали о том, какие проблемы могут возникнуть у компании при самостоятельной разработке сложных систем. В комментариях читатели просили нас подробнее рассказать о технической составляющей нашего проекта — биллинга для операторов связи «ОМГ».Выполняя эту просьбу, сегодня мы расскажем о том, как работали над повышением отказоустойчивости системы.Компоненты биллинга: где надежность важнее всего
Биллинг — это система, которая должна работать в режиме 24x7 все 365 дней в году. Поэтому резервирование всех его компонентов просто необходимо. Повнимательнее рассмотрим, из чего состоит система биллинга.Данные
Информация о потребленных абонентами услугах, балансы лицевых счетов, детализация платежей и списаний. Это самая ценная информация бизнеса, а значит, спасать ее нужно в первую очередь.Ядро
Ядро — часть системы, в которой ведутся все операции с данными. В «Гидре» оно интегрировано с данными — бизнес-логика находится прямо в СУБД в виде хранимых процедур. Модифицировать данные напрямую внешним приложениям запрещено, это можно делать только через API. Поэтому чтобы данные были доступны, ядро должно сохранять работоспособность.AAA-сервер (Authentication, Authorization, Accounting)
Элемент, который отвечает за аутентификацию, авторизацию и учет важной информации о потребленных абонентами услугах. Сетевое оборудование взаимодействует с AAA-сервером (сервером предоставления доступа к услугам). В случае отказа ААА-сервера, как правило, абоненты сталкиваются с невозможностью открытия новых сессий, подключения новых услуг и отключения старых.Кроме того, в таких ситуациях может теряться информация об уже оказанных услугах — это не только приводит к неудобствам для клиентов, но и чревато «бесплатным» оказанием услуг во время сбоя биллинга. Таким образом, ААА-сервер — это один из наиболее чувствительных компонентов всей системы.Платежный шлюз
Принимает информацию о проведенных платежах из различных платежных систем. Отказ шлюза приводит к задержкам в прохождении информации об оплатах, совершенных клиентами на свои лицевые счета в биллинге.В некоторых случаях это может негативно сказываться на качестве обслуживания — например, если у всех абонентов расчетный день наступает первого числа месяца, и сбой случился именно в этот день. Отказ платежного шлюза в это время приводит к тому, что абоненты не могут пополнить свой лицевой счет и восстановить доступ к услугам, если их отключило за неуплату.Работоспособность платежного шлюза зависит от работоспособности ядра, поскольку в случае недоступности ядра он не сможет сообщить остальным компонентам биллинга о поступлении средств на счет. Однако даже несколько часов простоя вряд ли приведут к серьезным проблемам, поскольку практически все платежные системы автоматически проводят платежи повторно, если предыдущие запросы получали в ответ ошибку, и предпринимать что-либо помимо восстановления самого сервиса не требуется.Личный кабинет абонента и веб-панель управления
При «падении» панели управления биллингом и личного кабинета пользователей сам биллинг сохраняет работоспособность, однако сотрудники компании и ее клиенты временно теряют возможность работы с системой.Что и как резервировать?
Выше мы рассмотрели основные компоненты биллинга и их важность с точки зрения обеспечения отказоустойчивости. Теперь поговорим о шагах, которые мы предприняли для повышения надежности работы системы.Начнем с описания общих подходов. Компоненты биллинга делятся на две большие категории: те, что хранят состояние и те, что не хранят. Состояние традиционно хранится в базе данных, их у нас две, при этом в нормальном режиме работы они активно обмениваются данными.Резервирование основной БД
Основная база хранит данные и ядро системы. Мы используем вырожденную трехуровневую архитектуру — бизнес-логика (хранимые процедуры и функции в Oracle) и данные (таблицы) тесно интегрированы в СУБД, в качестве клиента выступает браузер («тонкий клиент»), а веб-интерфейс служит программной оболочкой к ядру. Так как в качестве РСУБД используется Oracle Database, то подходы к резервированию основной БД мы используем рекомендованные производителем:Периодическое снятие резервной копии. Самый простой путь, который, тем не менее, сопряжен с определенными сложностями — восстановление данных при его использовании может занимать длительное время, а по завершении этого процесса информация будет неактуальной. Для снятия резервных копий в Oracle возможно использование утилит expdp — для небольших инсталляций (они просты в использовании, данные восстанавливаются долго), и универсального менеджера RMAN, который позволяет снимать полные и инкрементальные бэкапы по расписанию и разархивировать их.Копирование redo-логов СУБД на standby-сервер. Этот метод позволяет организовать «горячее» резервирование, при котором изменения с рабочей БД применяются на standby-сервере. В случае сбоя рабочего сервера обслуживание автоматически или вручную переводится на резервный сервер с актуальными данными.
Для ускорения переключения на резервный сервер мы используем небольшую хитрость. У основного и резервного серверов есть свои IP-адреса. Над ними есть IP-алиас, который в нормальном режиме «висит» на основном сервере. В случае его отказа этот алиас можно быстро «перевесить» на резервный сервер — пользователи не заметят разницы.Резервирование приложений
Все приложения, за исключением AAA-сервера (о нем речь пойдет позже), хранят состояние в основной БД, поэтому на резервном сервере нужно держать только сами приложения нужных версий, их конфигурационные файлы, а также скрипты запуска.Приложения настроены на работу с резервной БД и в любой момент готовы принять входящий запрос, который будет обработан после перевода резервной базы данных в активный режим.Резервирование AAA-сервера
AAA-сервер — наиболее чувствительный к перебоям компонент системы. Строго говоря он не относится к биллингу, а работает с ним в связке. Как только сервер доступа оказывается недоступен, абоненты замечают это незамедлительно. Допустимое время простоя — несколько минут, иначе абоненты «завалят» звонками колл-центр любого размера.Как правило, AAA-сервер размещается на отдельной физической машине поближе к абонентам, чтобы не зависеть от доступности сервера с основной БД. Это очень полезно для территориально распределенных сетей, в которых риски перерыва связи ААА-сервера с ядром высоки.Сам сервер доступа резвервируется в двух режимах: автоматическом и ручном. Для автоматического резервирования необходимо иметь минимум три физических сервера (для решения проблемы разрыва сети, netsplit). Для ручного режима достаточно двух серверов, но в таком случае решение о переключении нагрузки необходимо принимать дежурному сотруднику.Расмотрим пример инсталляции с автоматическим переключением (automatic failover):
Каждый AAA-сервер состоит из трех компонентов:База данных с профилями абонентов и данными о потребленных услугах.Наше приложение под кодовым названием HARD. Оно отвечает на HTTP-запросы, которые идут от следующего компонента.FreeRADIUS — непосредственно сервер, реализующий стандартный AAA-протокол — RADIUS. Он непосредственно общается с абонентской сетью и переводит запросы из бинарного формата в обычный HTTP+JSON для HARD.
Базы данных всех AAA-серверов (это MongoDB) объединены в группу с одним основным узлом (master) и двумя подчиненными (slave). Все запросы из абонентской сети идут на один AAA-сервер, при этом необязательно и даже нежелательно, чтобы им был сервер с основной БД.Посмотрим, что случится, если что-то пойдет не так, и один из компонентов откажет:Если пропадает связь с ядром биллинга, то в БД сервера доступа перестают поступать обновления, однако все параметры аутентификации и авторизации для абонентов остаются доступны серверу. Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.Если откажет AAA-сервер под номером 1, то сеть начнет обращаться к следующему по порядку серверу. Это стандартная схема поддержки отказоустойчивости для современных BRAS.Если откажет сервер 2, то перестанет быть доступен основной узел с базой данных. В этом случае через некоторое время (порядка одной минуты) среди оставшихся будет выбран новый основной узел. После этого ядро биллинга будет общаться именно с этим сервером.Отказ третьего сервера не вызовет никаких дополнительных действий.
Таким образом, любые неглобальные сбои не приведут к потере доступа абонетов к услугам. Что бы ни произошло, пользователи, скорее всего, ничего не заметят.Заключение
Наш проект развивается уже 8 лет, и за это время мы поучаствовали более чем в 80 проектах внедрения. Мы постоянно работаем над тем, чтобы сделать систему более надежной и удобной для клиентов.В следующих постах мы продолжим рассказывать об архитектуре «Гидры», технологиях и подходах, которые используются при ее разработке.Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!
Качество: 5
Доставка: 5
Сервис: 4
