Судный день: К чему приводят скрытые ошибки асинхронной обработки данных при росте нагрузки



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

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

    Все пропало


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

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

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

    Горячий день


    Зайдя на биллинговый сервер, инженеры техподдержки первым делом обнаружили, что полтора часа назад закончилось место в основном табличном пространстве рабочей БД. В результате этого остановилось несколько системных процессов биллинга — в частности, обновление профилей в модуле provisioning (отвечает за управление доступов абонентов к услугам). Техподдержка выдохнула и, предвкушая скорый обед, быстро увеличила табличное пространство и запустила процессы.

    Это не помогло — абонентам легче не стало. Клиент тем временем начал паниковать: поток возмущенных звонков «я заплатил, но ничего не работает» начал заваливать его колл-центр. Разбирательство продолжилось.

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

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

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

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

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

    Лирическое отступление: Когда город засыпает


    Итак, в ночь на 1 апреля биллинг начал генерировать новые данные для абонентских профилей на замену старым — если абонент не оплатил услугу, то нужно было отобрать у него доступ к ней. На этом шаге модуль provisioning сгенерировал большое количество новых профилей и асинхронно отправил их во внутреннюю очередь сообщений Oracle. Поскольку напрямую с очередями Oracle работать извне с нашим стеком технологий неудобно, для их дальнейшей передачи используется «прослойка» в виде брокера сообщений Apache ActiveMQ, к которому подключается RADIUS-сервер, записывающий данные в MongoDB.

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

    Приходит понимание


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

    Ранее иногда случались случаи потери связи RADIUS-сервера с ActiveMQ — на такой случай мы предусмотрели функциональность восстановления соединений. Для детектирования случаев потери связи был реализован специальный механизм, использующий протокол STOMP — в нем есть настройка передачи heartbeat-пакетов. Если такой сигнал не получен, то соединение считается утерянным и принудительно переустанавливается.

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

    Сообщения из ActiveMQ всегда извлекаются в том же потоке исполнения, который записывает данные в профили абонентов. Извлечение и запись — то, что он делает по порядку, и если запись задержалась, то поток не может «достать» следующий пакет. И если в нем содержался heartbeat, то он не будет получен — и другой поток, который проверяет наличие таких пакетов, будет считать соединение потерянным и попытается его переустановить.

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

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

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

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

    Поиск причин


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

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

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

    Поскольку такие проверки баланса у этого клиента происходят одномоментно в начале нового месяца, то первого числа каждого месяца нагрузка на систему всегда возрастает. Этому способствует не только необходимость проанализировать всех клиентов и отключить неплательщиков — тех из них, кто сразу же решит оплатить услуги, нужно быстро «допустить» к услугам снова и корректно этот факт учесть.

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

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

    Важное замечание: очевидно, что подобное желание видеть все деньги от всех абонентов в один день не способствует равномерному распределению нагрузки на систему. Напротив, в ходе «судного дня» для абонентов она вырастает в разы — причем, как на биллинг, так и на сервисы приема платежей. Кроме того, такая конфигурация способствует увеличению оттока пользователей (о том, как с ним бороться, мы рассказывали здесь и здесь).

    Вторая причина — желание сэкономить на инфраструктуре и отказ от разумного разнесения сервисов. Для биллинга был закуплен менее мощный сервер, чем было необходимо. Четыре года он отработал без проблем, однако объём данных в БД рос, кроме того, на сервер постепенно «навешивались» требовательные к ресурсам дополнительные сервисы (внешняя отчетная система на Java-машине, новый модуль provisioning также с использованием Java-машины и т.д.), а рекомендации инженеров, говоривших о необходимости разнесения сервисов, откладывались в долгий ящик с аргументом «работает же».

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

    Незадолго до 1 апреля наконец удалось получить отдельный сервер для авторизационной БД с профилями абонентов. Как выяснилось позже, RAID-массив на этом сервере оказался дефектным, и на нем авторизация при определенном уровне нагрузки тормозила еще сильнее, чем на старом «железе». Ни на одной из более чем 100 других инсталляций «Гидры» эта ошибка не проявлялась из-за того, что в нормальных условиях сервис авторизации работает быстро и ресурсов хватает с большим запасом.

    Непосредственным триггером аварии, вероятно, следует считать закончившееся место в табличном пространстве, которое привело к тому, что начали накапливаться изменения профилей. Как только свободное место вновь появилось, все эти изменения были обработаны и в дефектный RADIUS-сервер через системные очереди устремился поток репликационных сообщений, которые не смогли примениться.

    Определенные подозрения о возможном баге возникали и до описываемой ситуации — периодически у некоторых единичных абонентов в базе сохранялись неправильные профили. Однако вычислить проблему до первого числа нового месяца не удалось — событие было очень редким и расширенное логирование не помогло вовремя «отловить» ошибку (в том числе по причине переезда на новый сервер).

    Предотвращение проблем в будущем


    Устранив сбой и разобравшись в его причинах, уже в спокойной обстановке мы внесли корректировки, призванные исключить повторение ситуации в будущем. Вот, что мы сделали:
    • Прежде всего, в ActiveMQ была добавлена функциональность требования подтверждения доставки отправленных данных. При этом подобное подтверждение работает в кумулятивном режиме — сервер подтверждает получение не каждого сообщения, а некоторой их пачки (раз в пять секунд). Логика обработки сообщений поддерживает повторную обработку очереди начиная с определенного момента, даже если какие-то из данных уже попали в БД.
    • Кроме того был увеличен период отправки heartbeat-пакетов — вместо пяти секунд до нескольких минут. В дополнение к механизму heartbeat соединение к брокеру сообщений стало устанавливаться с опцией keepalive с небольшими интервалами проверки активности соединения (несколько десятков секунд против пары часов, устанавливаемой операционной системой по умолчанию).
    • Также производились тесты, в ходе которых при отправке сообщений случайным образом перезапускались разные модули системы. В ходе одного из таких тестов какая-то часть данных все равно оказывалась потерянной. Тогда был заменен сам «движок» базы данных MongoDB — перешли на использование WiredTiger. Мы планировали сделать это раньше, но по случаю тестов решили совместить переезд.

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

    Кроме того, по рекомендациям инженеров техподдержки «Латеры» сервисы системы были разнесены на разные серверы (деньги на них быстро нашлись). Это удалось успеть сделать до 1 мая — следующего дня массовых биллинговых операций.

    Главный урок


    Тревожные «звоночки», сигнализирующие о возможных проблемах, звучали и в марте, но выявить их до наступления планового всплеска активности не удалось. Если бы этого всплеска не было, или он произошел бы в другом месте — не на «тормозящем» RADIUS-сервере с максимальной скоростью последовательной записи 5 МБ/сек, то с высокой долей вероятности инженерам удалось бы локализовать проблему в апреле. Им не хватило буквально нескольких дней.

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

    Другие технические статьи от «Латеры»:


    Латера Софтвер
    52.00
    Company
    Share post

    Comments 63

      0
      Сравнимы ли для данного случая apache kafka и apacheMQ? Мне кажется kafka в данном случае по умолчанию не дала бы потерять сообщения. В то время как apacheMQ и rabbitMQ требуют не забыть включить подтверждение доставки.
        0
        Вряд ли. ActiveMQ выбрана не по причине какой-то особенной любви к ней, а потому что она из коробки работает с ораклом. И производительность ее как брокера гораздо выше, чем у оркала, то есть она не является узким местом. Вопрос подтверждения сообщений — это вопрос используемого протокола, в данном случае это был STOMP. Он, прямо скажем, примитивен, но работает. Даже потеря сообщений не такая большая проблема — всегда можно отправить все их заново, на это всегда был расчет, как на крайний случай, но беда, как уже было сказано, не приходит одна.
        0
        На скольких абонентах оно навернулось?
          –1
          Абонентов не очень много, до 100 тыс. Предполагаю, что в описанных условиях оно навернулось бы и на много меньшем числе.
            +3
            Я даже готов спорить что до 10К, нет резервирования, нет мониторинга, нет компетентных собственных админов, дебильная архитектура сети, дебильная привязка к 1 числу — такое раздолбайство могут себе позволить только провайдеры имени одного микрорайона, для которых репутация — это то, что они когда-то слышали, но ни разу не уточняли о чем речь, а SLA — непонятный набор букв.
              0
              Покажите пальцем у кого по другому? У меня достаточно информации, что тот же МТС хоть и имеет чтото, но работает гораздо хуже при проблемах у пользователя.

              Скажу даже больше, как показывает практика, ни у кого из больших операторов в России нет вменяемой техподдержки и правильного отношения к пользователю.
                0
                У крупных операторов другая специфика, чаще всего их бич первая линия — это абсолютно не компетентные ленивые и глупые работники сидящие на минимальной зп, отсюда и недовольство технической поддержкой крупных операторов, но в техническом плане, поверьте, там все более чем достойно и ситуацию вся сеть лежит пол дня из-за выхода из строя одного узла исключается еще на архитектурном уровне. Если проще, проблемы одного конкретного пользователя там могут тянуться месяцами передаваясь из отдела в отдел, пока дойдут до ответственных или не дойдут, но вот проблемы целостности крупных сегментов отлично мониторятся и исправляются, при этом все сдублировано, прописан жесткий SLA на все и руководители бригад экстренного реагирования не слабо отгребают в случае просрочек.
                У совсем маленьких операторов (1К-5К пользователей) другая крайность, они готовы целовать любого пользователя лично между ягодиц и техподдержка за счет своей малочисленности и непосредственного контроля владельцами бизнеса, вежливая и быстрая, но большая часть проблем именно технического плана, т.к. еще нет денег на хорошее железо и специалистов и сеть строится «из говна и палок», вида нафига нам аппаратный BRAS, давайте развернем 10 серверов FreeBSD на неттопах — это же дешевле (реально видел).
                Естественно везде бывают исключения, я видел и мелкие сети с очень грамотным проектом и крупные, где все делалось вообще на пофигу и всем было плевать за счет монополии в регионе, но лично я рекомендую пользователю при возможности выбора подключаться к оператору от 5К до 30К, тут чаще всего и техподдержка еще не сильно отдалена от админов и руководства и техническая часть уже имеет резервы, данный разбор полетов скорее исключение из правил, т.к. биллинг Гидра, для тех кто не в курсе, достаточно дорогой и меня удивляет что на него деньги руководство сети нашло, а на одного хорошего админа — нет, чаще бывает наоборот, но если бы было наоборот, то где бы мы прочли эту душещипательную историю.
            0
            Тоже интересует данный вопрос. Пусть не точно, но хоть порядок узнать. Интересно сравнить со нашим самописным биллингом со своими «особенностями»
              0
              Выше написали, до 100К
            +12
            (коммент от физика-зануды)

            > Кроме того была увеличена частота отправки heartbeat-пакетов — вместо пяти секунд время увеличилось до нескольких минут.

            Частота была уменьшена. Увеличен был период
            • UFO just landed and posted this here
                0
                Безусловно, мониторинг нужен и, конечно же, клиенту об этом много раз говорили, писали, умоляли. Наш облачный мониторинг предлагали, но он же денег стоит — 3 тысячи рублей в месяц. И про сервисы говорили, что нужно разносить.
                  +2

                  [sarcasm]ну дык 3 тысячи рублей в месяц — это ж целых 3 тысячи в месяц, а так ну подумаешь, один день не было у кого-то интернета, пусть бы сходили к тем, у кого интернет не выключили, хотя должны были[/sarcasm]

                    +2
                    На самом деле, желание не тратить деньги на «ерунду» порой доходит до маразма. Несколько месяцев назад я нашел в одном достаточно крупном сервисе (больше 10 тысяч клиентов) уязвимость, которая позволяла получить доступ ко всем данным всех клиентов. Естественно, я предложил им сотрудничество. Получил чудесный ответ:

                    — У нас не предусмотрены выплаты за найденные уязвимости.
                    — Вас не смущает, что у вас могут украсть данные всех пользователей?
                    — Если не хотите сообщать нам информацию, можете продолжать пользоваться нашим сервисом с уязвимостями.
                  • UFO just landed and posted this here
                • UFO just landed and posted this here
                    0
                    Вот тут https://habrahabr.ru/company/latera/blog/267083/ мы подробнее описывали, что будет происходить с Гидрой при разнообразных отказах, в том числе и когда MongoDB навернется. А здесь — https://habrahabr.ru/company/latera/blog/280196/, почему мы вообще используем Mongo и как оно нам.

                    Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.

                    Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.
                      –3
                      > размер базы не превышает 1 ГБ,
                      Простите, но вы там что, картинки с видюшками в базе храните?
                      Как база совсем нулёвой, пустой системы может весить ~1гб?
                        +4
                        Типовая не значит нулевая. Типовая — средний клиент.
                      0
                      После каких объемов?
                        –1
                        Я думаю, пара порядков у нас еще есть в запасе. Выборки из монги делаются очень примитивные, по индексу и с высокой селективностью. Изменения в базе происходят не слишком часто и применяются последовательно.
                        • UFO just landed and posted this here
                            0
                            А какой движок вы использовали для хранения данных? Какого рода нагрузка была и что не так было с индексом, Монга вроде умеет делать их в фоне?
                        +11
                        Мораль: в системе биллинга нормальных провайдеров должен быть рычаг «отключить биллинг», который бы позволял в аварийных условиях продолжить предоставлять доступ всем. Вне зависимости от оплаченности.

                        Это в условиях «оператор беспокоится о репутации». Если же не беспокоится — тогда да, лучше пусть саппорт отдувается, а «пипл хавает».
                          +5
                          Хаха, у нас в пятом carbon billing еще года полтора назал кнопку «инет всем!» запилили, на случай если в выходные всё взорвалось, а денег на круглосуточный суппорт у провайдера не нашлось сейчас)
                            0
                            АСР не надо отключать, она и так уже неработоспособна к тому моменту :)

                            Следует иметь пару-тройку Emergency RADIUS-серверов (провайдер по своим масштабам сам количество выберет), которые не общаются с АСР, но раздают какой-то один общий для всех ISG/SUBSCRIBER профиль и описаны для всех BNG.

                            В момент глобальной неработоспособности АСР, в зависимости от реализации, эти RADIUS-серверы или включаются и при этом имеют больший приоритет на BNG, или отключаются все RADIUS-серверы, имеющие интеграцию с АСР.
                              0
                              Хорошо, конечно, но что делать с паролями и аккаунтами? Пропускать всех? Или использовать устаревшую базу? А если телефония, то пропускать всех не стоит. Много вопросов тут.
                                0
                                Пропускать всех с одним сервисом средних параметров, если аутентифицирует пользователей сразу ядро АСР.

                                В целом же, если у АСР правильная архитектура, то точки аутентификации будут хранить некий слепок базы. И пользователи будут штатно аутентифицироваться, пока ядро АСР недоступно.

                                С точки зрения SBC, идентично — локальная база на точке аутентификации. Или не пускать никого во избежании fraud'а, поставив заглушку про технические проблемы (ну а как иначе?).

                                P.S. Паролей и аккаунтов у ШПД пользователей быть не должно, Option 82. А PPTP и PPPoE давно пора закопать в пользу IPoE, пускай даже если с CG-NAT.
                                  0
                                  JFYI аутентификация как раз велась через такой слепок. Проблема в том, что слепок перестал обновляться корректно, а это затронуло большое количество пользователей, потому что первого числа отрубает от трети до половины, они потом платят в течение дня и ждут интернета.

                                  Те, кто заплатил вовремя, не пострадали :)
                                    0
                                    Я читал статью.

                                    Тем не менее. Мониторинг, мониторинг, мониторинг, мониторинг, мониторинг, мониторинг, мониторинг, мониторинг.
                                      0
                                      Это не про провайдеров. Удивительно, но там даже админов на билинге может не быть. Т.е. просто нет человека, который поддерживает машину и все. Только менеджеры, которые, когда припечет, пойдут по офису и выдернут кого-нибудь занимающегося сетевыми вопросами, чтоб он попробовал реанимировать машину с Linux и Oracle.
                                    0
                                    Как раз слепок и был кривой, судя по статье. Вообще вопрос быстрой доставки статуса на авторизующие сервера (которые ещё обычно шардятся и реплицируются в хороших биллингах) это один из самых горячих вопросов последних лет, но мой взгяд. Конкуренция провайдеров усилилась и если раньше абонент не растраивался, когда интернет у него после оплаты появлялся минут через 10 (а то и через час), то нынче это считается уже как-то не современно. Абонент ожидает, что он махнул карточкой на сайте провайдера и интернет в тот же момент появился. Отсюда, наверное, использование диспетчера очередей в Гидре.

                                    Хотя многие по-прежнему делают синхронизацию с ядром по расписанию. И типичный шаг там 5-10 минут.
                                      0
                                      Синхронизация по расписанию в большинстве биллингов благополучно померла еще лет 5 назад, сейчас radius напрямую запрашивает атрибуты из базы при авторизации, если ее как таковой нет (IPoE), то при возникновении события шлется CoA на текущую сессию на брасе — это даже не секунды, а сотые доли. Жирные очереди в биллингах обычно возникают, если врубить детальную статистику клиентских сессий или еще какой дебаг режим, в остальных случаях авторизационная часть (radius + кеш базы с авторизационными данными) на 100К абонентов может крутится на хиленькой виртуалке не испытывая особых сложностей, тут скорее вопрос каким местом строится архитектура.
                                        0
                                        Я имел ввиду синхронизацию внутри биллинга, когда данные синхронизируются между центральным ядром и базами над которыми крутится радиус сервер. А у вас тут похоже очереди, что несколько быстрее, чем синк по расписанию.
                                          0
                                          Да очереди, от ядра к ААА сервисам и обратно, но там всего пара сотен событий в секунду в пиках при более чем 100К абонентов, далеко не самая нагруженная часть биллинга. Больше всего в биллинге ресурсы жрет формирование отчетов и различная аналитика с жирными запросами к базе, часть отвечающая за ААА это по сути одна сводная таблица и все этой части работает очень быстро, оплаты проходят мгновенно через платежные API, за исключением одного говнобанка, который API не умеет, а выписки по транзакциям скидывают раз в сутки на почту в excel, а там уже костыль их парсит, но это скорее исключение.
                                            0
                                            > но там всего пара сотен событий в секунду в пиках при более чем 100К абонентов, далеко не самая нагруженная часть биллинга.

                                            В этом и приемущество: задержки минимальны. При синхронизации у вас происходят тяжелые выборки на обоих концах, а разница реплицируется. Это опять таки приводит к необходимости держать именно sql базу под радиусом (поскольку так удобнее).

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

                                            А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
                                              0
                                              Полная синхронизация конечно есть, на случай нарушения целостности очередей, но это не штатная ситуация и необходимость возникает достаточно редко. Так я как раз за очереди а не синку по крону.

                                              А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?

                                              Логи собираются централизованно на отдельный сервер логов, там же парсятся и настроены события для системы мониторинга. Статусы сессий в разных проектах по разному, есть где используется radius-proxy, есть где плотная связка реализована прямо с BRAS и он сам отдает статистику по сессиям, флоу — чаще всего отдельный сервер на зеркале трафика, на этом же зеркале висит DPI, одной из функций которого является агрегация и предфильтрация флоу, к тому же фильтры DPI позволяют получить более осмысленную картину с привязкой к сигнатуре трафика и сервисам, а не банально к портам, как в обычном варианте. Есть проекты где флоу не нужен вовсе, достаточно Interim-Update пакетов от радиуса, например когда в сети нету NAT, все тарифы безлимитны и нужны данные только по приблизительным объемам потребляемого трафика для аналитики, тогда полный флоу включается в сети только при каком-то серьезном дебаге, с биллингом не связан и в штатном режиме потушен вовсе.
                                                0
                                                > Статусы сессий в разных проектах по разному, есть где используется radius-proxy, есть где плотная связка реализована прямо с BRAS и он сам отдает статистику по сессиям,

                                                Любопытно. Обычно в биллингах можно посмотреть статус сесси в базе биллинга, а тут вы смотрите прямо в BRAS. Я такое тоже видел, но редко.
                                                  0
                                                  Из крупных, на сколько помню есть в Billmaster из коробки, из мелких кажется MikBill подобный функционал реализовывал ограниченно и UTM5, но только для Cisco ISG (могу ошибаться может еще к чему допилили с этим биллингом мало работал), если дать денег за доработку под железо оператора и в другие вкорячить можно, все равно у любого более менее крупного оператора биллинг даже если использован готовый все равно серьезно допилен под компанию. Из плюсов данные всегда актуальны и если сессия померла, то для оператора это видно сразу в админке, хранить в базе эти данные тоже надо, но скорее для отчетов и истории и эта часть синкается по крону, но у оператора всегда данные актуальны на момент открытия карточки абонента.
                                          0
                                          Синхронизация жива и распевает оду стабильности. Мы — федеральный телеком, от Калининграда до Находки. АСР здравствует на базе Oracle, синхронизация тоже Oracle, локальные точки аутентификации хранят актуальные слепки. Синхронизация для каждой точки аутентификации инициируется ядром АСР.

                                          Задачи ядра — внесение изменений в карточку абонента, заведение их, родимых, получение начислений от контрагентов, отчёты и прочее, прочее, что не имеет отношения к функциональности работы с BNG. Ну а пользователь всегда готов подождать 5-10 минут до синхронизации изменений его лицевого счёта.

                                          Мы растём с помощью M&A, за крайние 10 лет интеграций других телекомов мы видели очень много вариантов АСР, написанных на коленке, написанных вендорами. У нас ни разу не дрогнула рука заменить выбранное решение на какие-то из этих альтернатив, потому что надёжно и очень, очень легко масштабируемо горизонтально.

                                          Очереди — это модно, стильно, молодёжно. Но бизнес выбирает проверенные и стабильные решения. Примерено по той же причине, почему бизнес до сих пор выбирает СХД c FibreChannel для АСР, а не модные, стильные и молодёжные NetApp с NFS, или всяческие реализации VSAN.
                                            0
                                            Мне кажется очень сильно зависит от сложившихся традиций в регионе и к стабильности как таковой не имеет отношения вовсе. Я чаще всего встречаю что провайдеры региона используют примерно одни и те же решения в части инфраструктуры, т.к. и специалиста найти проще на обслуживание да и собственные админы сидят в «тусовке» и выбирают схожие пути решения одних и тех же задач. Так например сложилось что в GB популярный 802.1x, а на территории бывшего СССР прочно прижился PPPoE, причем KZ и AZ предпочитают так называемый Russian PPPoE, но это лирика, если говорить о стабильности, то плюс очередей именно в моментальности наступления события, что разгружает ТП от кучи бессмысленных звонков вида: «У меня отключился интернет, я заплатил, а он не включается — мне работать надо, срочно....», при этом в чем вы видите не надежность очередей, локальный BNG получает изменения не по крону, а онлайн при их наступлении, что во первых сглаживает нагрузку на синхронизацию и она ровная в отличие от варианта с синкой, где каждые 5-10 минут возникает всплеск, потом спад, во вторых, как уже говорилось выше, более удобная абоненту, в третьих проще дебажится, так как меньше событий в единицу времени и можно «на лету» дампить данные и смотреть что «пошло не так». По СХД, та же ситуация, практически у всех есть FC/FCoE полки, но и другие реализации хранилищ встречаются часто, кроме упомянутых вами еще различные реализации кластер ФС, которые по high availability уделывают классические полки в ряде сценариев. Я бы сказал так, где архитектор был адекватен, мы получим свои пять девяток на куче разных вариантов реализации, а где профнепригоден, как в статье, то при выборе любых самых навороченных решений общая стабильность будет желать лучшего, чего туда не напихай, т.к. стабильность она для сервиса в целом важна, а не только для конкретных отдельных компонентов.
                                              0
                                              Коллега, наше с Вами видение ситуации отличается подходом к решению задач. Вы, очевидно, рассматриваете возможность имплементации «здесь и сейчас любыми усилиями», мы же рассматриваем решение через призму «экономим на CAPEX в разрезе 5 лет, не теряя в надёжности решения». Особенно, когда у телекома пользовательская база перешагнула масштабы миллионов.

                                              Про 802.1x, PPPoE, PPTP — это лишь транспорт, он не имеет отношения к аутентификации пользователя на BNG, вопрос скорости доставки изменений в сервисы пользователя на BNG остро не стоит совершенно, поэтому временной промежуток в 5-15 минут для классического физического лица в виде пользователя ШПД не критичен. Для юридических лиц используются совершенно другие подходы, равно как и BNG у них «свои».

                                              В целом, все телекомы на просторах СНГ можно разделить на 3 крупных группы:
                                              Чердак-телеком — родился из пыли и пережёванных желудей, не изменяется в качестве решений во времени, работает на местечковом рынке. С радостью продаст свои активы, если кто-то согласится купить.
                                              Стартап — быстро построился по решениям интеграторов, вложил большой CAPEX и OPEX на старте, пытается захватить значимую долю рынка в регионе, а после выгодно продаться, если кто-то согласится выгодно купить.
                                              Успевший из 2000-х — большинство федеральных телекомов современности СНГ, выросли из чердак-телекомов, успев наработать компетенцию и занять значимую долю рынка в регионе, а после и по стране. Продолжают M&A первых двух групп.

                                              Модные, стильные, молодёжные решения могут позволить себе первые две группы. Потому что маркетинг и дёшево.
                                              После поглощения третьей группой (во славу глобализации, конечно!), их абонентскую базу смигрируют в уже имеющееся у федерального телекома проверенное решение. А модные, стильные и молодежные будут выключены на помойку истории.
                                              Это классический цикл и изменить в нём мало что возможно.

                                              К слову, этот путь развития касается не только телекомов, но и большинства IT-компаний. Достаточно вспомнить господина Грефа и «провал проекта по переходу банка на новую IT-инфраструктуру, на внедрение которой было выделено более миллиарда долларов». Этот случай наглядно показывает эффект от принятия больших рисков в бизнесе. Ну и не будем разбирать здесь сторону «потратить бюджеты» и прочую диванную аналитику.
                                                0
                                                Капитальные затраты и риски мы получаем только при условии что нам ради «этой фишки» надо перейти с биллинга А, на биллинг Б, тогда полностью согласен с вами, но есть ситуация когда функционал добавляется в рамках планомерного развития текущего биллинга, используемого у оператора, тогда ни каких особых дополнительных затрат это не несет. Все операторы привязаны к своему выбранному биллингу, крупные естественно сильнее — это очевидно, но не все системы идут от онимы и имеют такую же архитектуру и идеологию. Например в одном гостелекоме регионального масштаба прекрасно работают очереди никак не сказываясь на стабильности.
                                                Ладно предлагаю заканчивать флудить ветку, а то скатились уже от обсуждения факапа до особенностей биллинга региональных операторов, а то так скоро за NDA вылезать придется и мерятся абонентскими базами, а оно нам надо.
                                                  0
                                                  Помимо того биллинга, который нельзя называть из-за NDA, в одном из регионов у нас живёт такой дикий, «планомерно развивающий функциональность». Кстати, родился он именно в этом телекоме, а после уже ушёл в свободное плавание самостоятельным продуктом (примерно как было с Orange Equipment Manager у Корбины/Вымпелком).

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

                                                  Обсуждения на специализированных ресурсах тем и прекрасны, можно послушать и, быть может, услышать чужую точку зрения. Но, давайте закончим, да. Спасибо за диспут.
                                                    0
                                                    Коллеги, было очень познавательно вашу дискуссию прочитать, спасибо. Приятно видеть настолько компетентных людей.
                                              0
                                              Походу я знаю какой у вас биллинг стоит.
                                                0
                                                Например? :)
                                                  0
                                                  Ну самый старый биллинг (из местных и по-прежнему живых), у которого все эту фишку с синхронизацией и AP переняли это Onyma. Там это есть с начала века, а позже все остальные подхватили. Кроме Гидры, которая, как я погляжу, пошла другим путем.
                                                    +1
                                                    Мой NDA не позволяет напрямую согласиться в Вашим утверждением про используемую нами биллинговую систему.
                                                    Ну Вы поняли, да.
                                                      0
                                                      Мой NDA и обязательства переед клиентами не позволяют мне подтвердить, что я догадался.
                                                        +1
                                                        Ну достаньте уже свой NDA и померяйтесь :)
                                  +5
                                  Во время чтения разбора полетов, фейспалм был почти на каждом абзаце. Общее ощущение от заметки выглядит как: «солидная компания возьмет в аренду дырокол». Отсутствие у клиента какой-бы то ни было системы мониторинга, отсутствие резервирования критичных сервисов, отсутствие плана «Б» когда в радиус либо тупо вгружается статический фаил с данными всех клиентов и настройкой пускать всех, на худой конец делается настройка радиуса пускать с любыми учетными данными до восстановления сервиса. Клиент переводящий критичные сервисы на новое железо без его нагрузочного тестирования, я могу продолжать еще долго. И это все на фоне оракла, apacheMQ и прочих плюшек под высокие нагрузки, вот на кой черт они нужны, если инфраструктуру строили ягодицами и системный архитектор профнепригоден? Вроди как не ваша вина, клиент виноват, но действия ваших специалистов вызывают не меньшие недоумения, не разобравшись в причинах и не предложив быстро разрешить любые авторизации, чтоб не пороть горячку, они кидаются добивать полуживые сервисы с надеждой на авось.
                                    –1
                                    Абонентам радиус выдает айпи-адреса, какие айпи-адреса вы положите в статический файлик?
                                      0
                                      Скажу выдавать из динамического пула, либо сгенерю скриптом однострочником из доступных диапазонов, при условии что базе совсем труба и нельзя достать оттуда привязанные адреса вместе с логинами-паролями-портами и прочими данными radius.
                                        0
                                        Так кем он из пула-то будет выдаваться? Как будет контролироваться отсутствие задвоений? Мне действительно интересно.
                                          0
                                          Если интересно, то вот варианты:
                                          1) Пул переносим на BRAS он же контролирует отсутствие задвоений, для juniper MX например будет выглядить так:
                                          run show configuration access address-assignment pool POOL1
                                          link POOL2;
                                          family inet {
                                              network ХХ.ХХ.ХХ.0/18;
                                              range 1st {
                                                  low ХХ.ХХ.ХХ.0;
                                                  high ХХ.ХХ.ХХ.255;
                                              }
                                              dhcp-attributes {
                                                  maximum-lease-time 300;
                                                  inactive: grace-period 300;
                                                  router {
                                                      ХХ.ХХ.ХХ.128;
                                                  }
                                              }
                                              xauth-attributes {
                                                  primary-dns ХХ.ХХ.ХХ.ХХ/32;
                                                  secondary-dns ХХ.ХХ.ХХ.ХХ/32;
                                              }
                                          }
                                          

                                          В самом radius передаем для всех абонентов просто имя пула в атрибуте 88
                                          Для цисок аналогично, даже бомж-вариант программного браса accel-ppp умеет.
                                          2) Передаем сгенерированые из диапазона значения, тоже повторений не будет.
                                          3) Разворачиваем предварительно подготовленый сервис срочной доступности, тот же пул, но контролируется скриптом, в десяток строк на любом шел языке.

                                          А вообще назовите реальный кейс сбоя с условиями, что живо что недоступно, какая технология ААА для абонентов и чем рулит радиус, подскажу возможные варинты.
                                            0
                                            Согласен, наколхозить несложно. Моя основная обеспокоенность была в том будет ли участвовать база данных в предлагаемых решениях :)
                                              0
                                              В варианте с пулом база может быть мертвой наглухо, по большому счету нужен будет радиус, поднятый где угодно, с разрешением все-всем и передачей единственного атрибута 88, дальше разрулят брасы. Есть опыт восстановления базы на 60К+ абонов, где база чебурахнулась наглухо без возможности восстановления совсем, а я был с командой, которой поручили поднять максимально работу клиентов и восстановить хоть какую-то работу плюс собрать базу с нуля по ААА данным, которые посылали клиенты. Ничего за 6 часов в незнакомой сети, без документации, без схем, без биллинга и каких-либо бэкапов, на голом железе и привезенном с собой серваке и брасах восстановили 80% работы.
                                      0
                                      Не меньшее количество шлепков ладони по лицу прозвучало и при написании статьи. К сожалению, не у всех компаний есть желание вкладываться в инфраструктуру (и понимание, зачем вообще это делать), так же как ограничены и наши возможности влияния на клиента. Конечно же, хотелось добавить в статью несколько эмоциональных оценок, и первоначально они даже в ней были, но злобное начальство подвергло статью цензуре перед выпуском и предоставило воображению читателю самому додумать, какие монологи и диалоги происходили в процессе решения проблемы.

                                      Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.

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

                                      Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.
                                        0
                                        Я так понимаю ответ был мне, хоть и не в ветке комментария. Пару ремарок, по поводу выгрузки, радиус передает обычно от 0 до максимум 10 атрибутов, выгружать эти данные простым селектом в фаил раз в час дело не мегасложное и особой кастомизации не требует, зато в случае: «шеф все пропало, за что мы бабки платим, чините все срочноооо», вы просто переводите радиус на данную выгрузку и спокойно под кофе с плюшкой разгребаете проблему. Второе, если сервис дохлый — никогда, вот совсем никогда, нельзя его перегружать если нет его горячей замены и вы не уверены что все заработает, во первых это скроет все следы инцидента и дебаг команда вас возненавидит, во вторых хрен потом с него считаешь данные, если на резерве/бэкапе чего-то не хватает. Мне видится такой сценарий, подымаем пусть даже на своих мощностях новый радиус (думаю есть готовые сборки и займет менее пары минут) пропихиваем актуальные данные на него, переключаем брасы на него, с полудохлого уходит нагрузка и можно его полноценно отдебажить. Самое сложное при факапе не пороть горячку и не делать действий, которые невозможно откатить, в этом я считаю была основная ошибка саппорта в данной ситуации, ну мне с дивана так видно, хотя в защиту дивана скажу, что построил не один десяток провайдеров разных объемов и хорошо знаю кухню изнутри.
                                          –1
                                          Полностью с вами согласен. Могу только добавить, что как только стало понятно, что ситуация ухудшилась, инженеры имели возможность удалить все, что скопилось во входящих очередях. Прямо сейчас не могу выяснить, что именно они сделали, когда ухудшение стало заметно, но скорее всего так и поступили. То есть это действие было обратимым.
                                            0
                                            Повторная заливка данных не приводит к отказам в обслуживании уже работающих абонентов, а лишь добавляет задержку для активации существующих. Просто первого числа люди не хотят ждать, когда их включит и звонят с требованием включить услугу, что понятно. Сделать выгрузку из биллинга, скажу честно, суперпросто, потому что данные там хранятся в том виде, в котором они должны оказаться в базе радиуса. Но делать это в момент факапа довольно рискованное занятие. Сам инцидент продлился несколько часов, в течение которых были задержки во включении оплативших абонентов, в остальном все работало, поэтому подвергать риску работающих абонентов все же не стоило. Конечно, если бы сценарий был отработан заранее, то… но здесь мы уже ходим по кругу.
                                            0
                                            DHCP на IPoE инсталляциях должна BNG-коробка, а не RADIUS-сервер. RADIUS должен доставлять профиль и сервисы пользователя: OpenGarden, ночные тарифы, турбо-кнопку, детские интернеты, вот это вот всё.

                                            Равно как давно пора перестать привязывать пользователей по IP к портам, Option 82 в 2001 году придумали. За 15 лет разве что утюги и чайники не имеют его в своей функциональности.

                                        Only users with full accounts can post comments. Log in, please.