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



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

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

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


    Биллинг — это система, которая должна работать в режиме 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 проектах внедрения. Мы постоянно работаем над тем, чтобы сделать систему более надежной и удобной для клиентов.

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

    Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!
    Метки:
    Латера Софтвер 49,82
    Компания
    Поделиться публикацией
    Комментарии 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-логов.

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

    Самое читаемое