Латера Софтвер
Компания
51,84
рейтинг
17 сентября 2015 в 16:40

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



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

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

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


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

Данные


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



Ядро


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

AAA-сервер (Authentication, Authorization, Accounting)


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

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

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


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

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

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

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


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

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


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

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

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


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

  1. Периодическое снятие резервной копии. Самый простой путь, который, тем не менее, сопряжен с определенными сложностями — восстановление данных при его использовании может занимать длительное время, а по завершении этого процесса информация будет неактуальной. Для снятия резервных копий в Oracle возможно использование утилит expdp — для небольших инсталляций (они просты в использовании, данные восстанавливаются долго), и универсального менеджера RMAN, который позволяет снимать полные и инкрементальные бэкапы по расписанию и разархивировать их.
  2. Копирование redo-логов СУБД на standby-сервер. Этот метод позволяет организовать «горячее» резервирование, при котором изменения с рабочей БД применяются на standby-сервере. В случае сбоя рабочего сервера обслуживание автоматически или вручную переводится на резервный сервер с актуальными данными.

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

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


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

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

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


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

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

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

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


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

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

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

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

  • Если пропадает связь с ядром биллинга, то в БД сервера доступа перестают поступать обновления, однако все параметры аутентификации и авторизации для абонентов остаются доступны серверу. Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.
  • Если откажет AAA-сервер под номером 1, то сеть начнет обращаться к следующему по порядку серверу. Это стандартная схема поддержки отказоустойчивости для современных BRAS.
  • Если откажет сервер 2, то перестанет быть доступен основной узел с базой данных. В этом случае через некоторое время (порядка одной минуты) среди оставшихся будет выбран новый основной узел. После этого ядро биллинга будет общаться именно с этим сервером.
  • Отказ третьего сервера не вызовет никаких дополнительных действий.

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

Заключение


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

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

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!
Автор: @BillingMan
Латера Софтвер
рейтинг 51,84
Компания прекратила активность на сайте

Комментарии (15)

  • 0
    А что делает HARD?
    Почему был выбран вариант с HTTP\JSON, a допустим, не реализацией модуля FreeRADIUS?
    Спасибо
    • 0
      В hard содержится вся бизнес-логика аутентификации, авторизации и аккаунтинга. Плюс он взаимодействует с БД профилей и данных по аккаунтингу. FreeRADIUS в этой схеме используется в «тупом» варианте, фактически для того, чтобы декодировать бинарный протокол RADIUS в текстовый формат и наоборот.

      Модуль FR делать не стали, потому что нужно было программировать на C, а делать это очень не хотелось. Использовали rlm_perl.
      • 0
        Ясно.
        А CDR там же предобрабатываются, или нужно что-то еще дорисовать на картинках?
        • 0
          Если речь о RADIUS-аккаунтинге, то предобработка делается в hard. Если же о телефонных CDR, то нужно дорисовывать, в этом смысле схема упрощена.
          • 0
            Именно о CDR. А можете наложить структурную схему на домены mediation, rating, invoicing?

            А сервер очередей для AAA и платежей один? Внешний или oracle queues, почему? )

            >Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.

            Значит ли это, что ААА для инициации сессии всегда обращается в основную БД? Или какой-то provisioning есть, и AAA сможет самостоятельно принять решение во время инициации абонента?

            Статья больше вопросов вызывает если честно…

            • 0
              Rating и Invoicing — темы за рамками этой статьи. Она про отказоустойчивость.

              Очереди для AAA используются внешние, ActiveMQ. Очереди AQ применяются внутри ядра, но об этом, опять же, в другой раз.

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

              Задавайте вопросы про отказоустойчивость :).
              • 0
                Так для доменов разные требования по отказоустойчивости, например invoicing можно и положить на пару часов…

                Очереди — тоже одна из популярных точек отказа…

                Из статьи не очевидно наличия provisioning в сторону ААА, я конечно подозревал что все по канонам, но…

                А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )
                • +1
                  Посмотрите на стрелочки между ядром и БД харда, у них там двусторонний обмен. Если очередь отвалится, то ничего страшного, как поднимут, так и хорошо, ее просто нужно мониторить. Своего состояния у нее не много, в любой момент можно отправить данные заново, даже если она все потеряет.
                  • 0
                    Да это то понятно, вопрос скорее во времени восстановления работы и влиянии на трафик, тут то данные критичны ко времени обработки… Не выгрузили аккаунтинг, бизнес-логика не получила данные, провиженинг не заблокировал вовремя абонента ну итд… Вот не видел в биллингах идентичных реализаций очередей, везде нюансы были )
                    • 0
                      Там все хитро. AAA-сервер может пустить абонента по старым данным. Как только соединение с основной БД восстановится, то в момент загрузки сессий будет сгенерирована команда на терминацию запрещенной сессии. Даже если сессия по какой-то причине загрузилась из-за гонки, то периодическое задание прибьет ее.
                      • 0
                        Да это тоже очевидно
                        Как только связь с БД восстановится, ААА начнет выгружать аккаунтинг, пока он прогрузится, пока сработает бизнес-логика, пока провиженинг сработает в сторону ААА. Да, все в конечном итоге нормализуется, состояния синхронизируются, но за какое время? А то в промежутке абонент тариф поменяет, какие-нибудь услуги не окажутся в нужном объеме и качестве, пересчитывать придется и претензии разбирать, а это деньги и немаленькие.
                        В разных системах принимают разные меры для оптимизации этого процесса.
                        • 0
                          Ну все перерасчеты и прочее — больше организационный вопрос. А что касается скорости, то это секунды после восстановления связи, там очереди сообщений.
                • 0
                  А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )


                  Битые реду-логи оракл не применяет. Мониторим отставание текущего номера SCN на резервной базе от SCN основной. Если оно становится слишком большим — выдаем алерт, принимаем меры.
  • 0
    в случае с базой, я так понимаю у вас не RAC кластер? для чего эти «ручные» манипуляции с копированием redo-логов и shared IP?
    • 0
      RAC требует более дорогой лицензии.
      RAC более требователен к железу. Нужна хорошая корзина с резервированием.
      RAC дороже в администрировании.

      Поэтому RAC нужно использовать только там, где без него не обойтись никак. Для всего остального есть мастеркард, то есть копирование redo-логов.

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

Самое читаемое Разработка