Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

Как повысить отказоустойчивость биллинга: Опыт «Гидры»

Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».

Компоненты биллинга: где надежность важнее всего

Биллинг — это система, которая должна работать в режиме 24x7 все 365 дней в году. Поэтому резервирование всех его компонентов просто необходимо. Повнимательнее рассмотрим, из чего состоит система биллинга.

Данные

Информация о потребленных абонентами услугах, балансы лицевых счетов, детализация платежей и списаний. Это самая ценная информация бизнеса, а значит, спасать ее нужно в первую очередь. 


Ядро

Ядро — часть системы, в которой ведутся все операции с данными. В «Гидре» оно интегрировано с данными — бизнес-логика находится прямо в СУБД в виде хранимых процедур. Модифицировать данные напрямую внешним приложениям запрещено, это можно делать только через API. Поэтому чтобы данные были доступны, ядро должно сохранять работоспособность.

ААА-сервер (Authentication, Autorization, Accounting)

Элемент, который отвечает за аутентификацию, авторизацию и учет важной информации о потребленных абонентами услугах. Сетевое оборудование взаимодействует с AAA-сервером (сервером предоставления доступа к услугам). В случае отказа ААА-сервера, как правило, абоненты сталкиваются с невозможностью открытия новых сессий, подключения новых услуг и отключения старых. 

Кроме того, в таких ситуациях может теряться информация об уже оказанных услугах — это не только приводит к неудобствам для клиентов, но и чревато «бесплатным» оказанием услуг во время сбоя биллинга. Таким образом, ААА-сервер — это один из наиболее чувствительных компонентов всей системы.

Платежный шлюз

Принимает информацию о проведенных платежах из различных платежных систем. Отказ шлюза приводит к задержкам в прохождении информации об оплатах, совершенных клиентами на свои лицевые счета в биллинге.

В некоторых случаях это может негативно сказываться на качестве обслуживания — например, если у всех абонентов расчетный день наступает первого числа месяца, и сбой случился именно в этот день. Отказ платежного шлюза в это время приводит к тому, что абоненты не могут пополнить свой лицевой счет и восстановить доступ к услугам, если их отключило за неуплату. 

Работоспособность платежного шлюза зависит от работоспособности ядра, поскольку в случае недоступности ядра он не сможет сообщить остальным компонентам биллинга о поступлении средств на счет. Однако даже несколько часов простоя вряд ли приведут к серьезным проблемам, поскольку практически все платежные системы автоматически проводят платежи повторно, если предыдущие запросы получали в ответ ошибку, и предпринимать что-либо помимо восстановления самого сервиса не требуется.

Личный кабинет абонента и веб-панель управления

При «падении» панели управления биллингом и личного кабинета пользователей сам биллинг сохраняет работоспособность, однако сотрудники компании и ее клиенты временно теряют возможность работы с системой.

Что и как резервировать?

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

Начнем с описания общих подходов. Компоненты биллинга делятся на две большие категории: те, что хранят состояние и те, что не хранят. Состояние традиционно хранится в базе данных, их у нас две, при этом в нормальном режиме работы они активно обмениваются данными.

Резервирование основной БД

Основная база хранит данные и ядро системы. Мы используем вырожденную трехуровневую архитектуру — бизнес-логика (хранимые процедуры и функции в Oracle) и данные (таблицы) тесно интегрированы в СУБД, в качестве клиента выступает браузер («тонкий клиент»), а веб-интерфейс служит программной оболочкой к ядру. Так как в качестве РСУБД используется Oracle Database, то подходы к резервированию основной БД мы используем рекомендованные производителем:

1. Периодическое снятие резервной комии. Самых простой путь, который, тем не менее, сопряжен с определенными сложностями — восстановление данных при его использовании может занимать длительное время, а по завершении этого процесса информация будет неактуальной. Для снятия резервных копий в Oracle возможно использование утилит expdp — для небольших инсталляций (они просты в использовании, данные восстанавливаются долго), и универсального менеджера RMAN, который позоволяет снимать полные и инкрементальные бэкапы по расписанию и разархивировать их.

2. Копирование redo-логов СУБД на standby-сервер. Этот метод позволяет организовать «горячее» резервирование, при котором изменения с рабочей БД применяются на standby-сервере. В случае сбоя рабочего сервера обслуживание автоматически или вручную переводится на резервный сервер с актуальными данными.

Для ускорения переключения на резервный сервер мы используем небольшую хитрость. У основного и резервного серверов есть свои IP-адреса. Над ними есть IP-алиас, который в нормальном режиме «висит» на основном сервере. В случае его отказа этот алиас можно быстро «перевесить» на резервный сервер — пользователи не заметят разницы.

Резервирование приложений

Все приложения, за исключением AAA-сервера (о нем речь пойдет позже), хранят состояние в основной БД, поэтому на резервном сервере нужно держать только сами приложения нужных версий, их конфигурационные файлы, а также скрипты запуска.

Приложения настроены на работу с резервной БД и в любой момент готовы принять входящий запрос, который будет обработан после перевода резервной базы данных в активный режим.

Резервирование ААА-сервера

AAA-сервер — наиболее чувствительный к перебоям компонент системы. Строго говоря он не относится к биллингу, а работает с ним в связке. Как только сервер доступа оказывается недоступен, абоненты замечают это незамедлительно. Допустимое время простоя — несколько минут, иначе абоненты «завалят» звонками колл-центр любого размера.

Как правило, AAA-сервер размещается на отдельной физической машине поближе к абонентам, чтобы не зависеть от доступности сервера с основной БД. Это очень полезно для территориально распределенных сетей, в которых риски перерыва связи ААА-сервера с ядром высоки.

Сам сервер доступа резвервируется в двух режимах: автоматическом и ручном. Для автоматического резервирования необходимо иметь минимум три физических сервера (для решения проблемы разрыва сети, netsplit). Для ручного режима достаточно двух серверов, но в таком случае решение о переключении нагрузки необходимо принимать дежурному сотруднику.

Расмотрим пример инсталляции с автоматическим переключением (automatic failover):

Каждый AAA-сервер состоит из трех компонентов: 

1. База данных с профилями абонентов и данными о потребленных услугах.
2. Наше приложение под кодовым названием HARD. Оно отвечает на HTTP-запросы, которые идут от следующего компонента.
3. FreeRADIUS — непосредственно сервер, реализующий стандартный ААА-протокол — RADIUS. Он непосредственно общается с абонентской сетью и переводит запросы из бинарного формата в обычный HTTP+JSON для HARD.

Базы данных всех AAA-серверов (это MongoDB) объединены в группу с одним основным узлом (master) и двумя подчиненными (slave). Все запросы из абонентской сети идут на один AAA-сервер, при этом необязательно и даже нежелательно, чтобы им был сервер с основной БД.

Посмотрим, что случится, если что-то пойдет не так, и один из компонентов откажет:

- Если пропадает связь с ядром биллинга, то в БД сервера доступа перестают поступать обновления, однако все параметры аутентификации и авторизации для абонентов остаются доступны серверу. Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.

- Если откажет AAA-сервер под номером 1, то сеть начнет обращаться к следующему по порядку серверу. Это стандартная схема поддержки отказоустойчивости для современных BRAS.

- Если откажет сервер 2, то перестанет быть доступен основной узел с базой данных. В этом случае через некоторое время (порядка одной минуты) среди оставшихся будет выбран новый основной узел. После этого ядро биллинга будет общаться именно с этим сервером.

- Отказ третьего сервера не вызовет никаких дополнительных действий.

Таким образом, любые неглобальные сбои не приведут к потере доступа абонетов к услугам. Что бы ни произошло, пользователи, скорее всего, ничего не заметят.

Заключение

Наш проект развивается уже 8 лет, и за это время мы поучаствовали более чем в 80 проектах внедрения. Мы постоянно работаем над тем, чтобы сделать систему более надежной и удобной для клиентов. 

В следующих постах мы продолжим рассказывать об архитектуре «Гидры», технологиях и подходах, которые используются при ее разработке.

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

17.09.2015

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.