В нашем блоге мы рассказываем не только о развитии своего продукта — биллинга для операторов связи «Гидра», но и описываем сложности и проблемы, с которыми сталкиваемся на этом пути. Ранее мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему 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 МБ/сек, то с высокой долей вероятности инженерам удалось бы локализовать проблему в апреле. Им не хватило буквально нескольких дней.
Все это подводит к выводу о том, что в том случае, если существуют подозрения на наличие не до конца понятных проблем с работоспособностью систем, а также ожидается всплеск активности, то стоит также быть готовым, что именно в этот момент все пойдет по максимально неблагоприятному сценарию. При наличии таких подозрений необходимо интенсивнее проводить поиск возможных проблем, чтобы успеть разобраться с ними до серьезного повышения нагрузки.
Другие технические статьи от «Латеры»:
- Автоматизируем учет адресов и привязок в IPoE-сетях
- Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели
- DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных
- Архитектура open source-приложений: Как работает nginx
- Как повысить отказоустойчивость биллинга: Опыт «Гидры»
Комментарии (39)
mickvav
14.05.2016 14:55На скольких абонентах оно навернулось?
dkoplovich
14.05.2016 22:32-1Абонентов не очень много, до 100 тыс. Предполагаю, что в описанных условиях оно навернулось бы и на много меньшем числе.
RicoX
14.05.2016 22:50+3Я даже готов спорить что до 10К, нет резервирования, нет мониторинга, нет компетентных собственных админов, дебильная архитектура сети, дебильная привязка к 1 числу — такое раздолбайство могут себе позволить только провайдеры имени одного микрорайона, для которых репутация — это то, что они когда-то слышали, но ни разу не уточняли о чем речь, а SLA — непонятный набор букв.
NorthFighter
16.05.2016 16:25Покажите пальцем у кого по другому? У меня достаточно информации, что тот же МТС хоть и имеет чтото, но работает гораздо хуже при проблемах у пользователя.
Скажу даже больше, как показывает практика, ни у кого из больших операторов в России нет вменяемой техподдержки и правильного отношения к пользователю.RicoX
16.05.2016 18:12У крупных операторов другая специфика, чаще всего их бич первая линия — это абсолютно не компетентные ленивые и глупые работники сидящие на минимальной зп, отсюда и недовольство технической поддержкой крупных операторов, но в техническом плане, поверьте, там все более чем достойно и ситуацию вся сеть лежит пол дня из-за выхода из строя одного узла исключается еще на архитектурном уровне. Если проще, проблемы одного конкретного пользователя там могут тянуться месяцами передаваясь из отдела в отдел, пока дойдут до ответственных или не дойдут, но вот проблемы целостности крупных сегментов отлично мониторятся и исправляются, при этом все сдублировано, прописан жесткий SLA на все и руководители бригад экстренного реагирования не слабо отгребают в случае просрочек.
У совсем маленьких операторов (1К-5К пользователей) другая крайность, они готовы целовать любого пользователя лично между ягодиц и техподдержка за счет своей малочисленности и непосредственного контроля владельцами бизнеса, вежливая и быстрая, но большая часть проблем именно технического плана, т.к. еще нет денег на хорошее железо и специалистов и сеть строится «из говна и палок», вида нафига нам аппаратный BRAS, давайте развернем 10 серверов FreeBSD на неттопах — это же дешевле (реально видел).
Естественно везде бывают исключения, я видел и мелкие сети с очень грамотным проектом и крупные, где все делалось вообще на пофигу и всем было плевать за счет монополии в регионе, но лично я рекомендую пользователю при возможности выбора подключаться к оператору от 5К до 30К, тут чаще всего и техподдержка еще не сильно отдалена от админов и руководства и техническая часть уже имеет резервы, данный разбор полетов скорее исключение из правил, т.к. биллинг Гидра, для тех кто не в курсе, достаточно дорогой и меня удивляет что на него деньги руководство сети нашло, а на одного хорошего админа — нет, чаще бывает наоборот, но если бы было наоборот, то где бы мы прочли эту душещипательную историю.
pod
15.05.2016 10:50Тоже интересует данный вопрос. Пусть не точно, но хоть порядок узнать. Интересно сравнить со нашим самописным биллингом со своими «особенностями»
bigfatbrowncat
14.05.2016 16:13+12(коммент от физика-зануды)
> Кроме того была увеличена частота отправки heartbeat-пакетов — вместо пяти секунд время увеличилось до нескольких минут.
Частота была уменьшена. Увеличен был период
AxVPast
14.05.2016 18:02+6Просто шикарный пример отсутствия системы мониторинга на всех уровнях со сбором исторических данных.
— как Вы обычно мониторите SQL сервер?
— select 1 from dual;
— а что-то еще?
— а нужно?
Обычно правильно настроенная система мониторингда даёт достаточно информации об будущей проблеме задолго до того, как она происходит. Кстати именно этого в выводах и не заметил. Другими словами — друзья, проблема отказа в работе системы (не эта, какая-то другая но с таким-же эффектом, если не круче) однозначно повторится. И у Вас нет ответа когда именно это произойдёт.dkoplovich
14.05.2016 22:37Безусловно, мониторинг нужен и, конечно же, клиенту об этом много раз говорили, писали, умоляли. Наш облачный мониторинг предлагали, но он же денег стоит — 3 тысячи рублей в месяц. И про сервисы говорили, что нужно разносить.
Dreyk
14.05.2016 22:44+2[sarcasm]ну дык 3 тысячи рублей в месяц — это ж целых 3 тысячи в месяц, а так ну подумаешь, один день не было у кого-то интернета, пусть бы сходили к тем, у кого интернет не выключили, хотя должны были[/sarcasm]
pyrk2142
15.05.2016 22:15+2На самом деле, желание не тратить деньги на «ерунду» порой доходит до маразма. Несколько месяцев назад я нашел в одном достаточно крупном сервисе (больше 10 тысяч клиентов) уязвимость, которая позволяла получить доступ ко всем данным всех клиентов. Естественно, я предложил им сотрудничество. Получил чудесный ответ:
— У нас не предусмотрены выплаты за найденные уязвимости.
— Вас не смущает, что у вас могут украсть данные всех пользователей?
— Если не хотите сообщать нам информацию, можете продолжать пользоваться нашим сервисом с уязвимостями.
AxVPast
15.05.2016 00:23+1Тут обычно не «умоляли» а прямо в лоб спрашиваете — Вы готовы что Ваша система не будет работать сутки-двое? Сколько это Вам будет стоить? Обычно письменно, обычно с указанием потерь, обычно с вовлечением топ менеджмента, а не технарей.
AxVPast
14.05.2016 18:07+5Да и тут написано, что используется MongoDB — поздравляю. Можете начинать искать статьи (на хабре) как слезть с MongoDB на Постгресс. После определенных объемов работы MongoDB сама собой перестаёт нормально работать. Впрочем, Вы об этом узнаете в момент когда она просто вырубится (т.к. мониторинга нет) и у Вас будет шикарный повод написать тут статью как вы героически решали эту проблему :).
dkoplovich
14.05.2016 22:47Вот тут https://habrahabr.ru/company/latera/blog/267083/ мы подробнее описывали, что будет происходить с Гидрой при разнообразных отказах, в том числе и когда MongoDB навернется. А здесь — https://habrahabr.ru/company/latera/blog/280196/, почему мы вообще используем Mongo и как оно нам.
Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.
Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.
TimsTims
14.05.2016 23:17-3> размер базы не превышает 1 ГБ,
Простите, но вы там что, картинки с видюшками в базе храните?
Как база совсем нулёвой, пустой системы может весить ~1гб?
zoonman
14.05.2016 22:59После каких объемов?
dkoplovich
14.05.2016 23:19-1Я думаю, пара порядков у нас еще есть в запасе. Выборки из монги делаются очень примитивные, по индексу и с высокой селективностью. Изменения в базе происходят не слишком часто и применяются последовательно.
AxVPast
15.05.2016 00:18Приблизительно от 2ТБ с отказоустойчивостью Мастер-Слейв. Хотя фича грухнуть индекс и пересоздать его снова начала мешать жить намного раньше.
После перехода на постгресс получили объем базы в 300ГБ и полное отсутствие мистических проблем.zoonman
15.05.2016 02:31А какой движок вы использовали для хранения данных? Какого рода нагрузка была и что не так было с индексом, Монга вроде умеет делать их в фоне?
amarao
14.05.2016 18:17+11Мораль: в системе биллинга нормальных провайдеров должен быть рычаг «отключить биллинг», который бы позволял в аварийных условиях продолжить предоставлять доступ всем. Вне зависимости от оплаченности.
Это в условиях «оператор беспокоится о репутации». Если же не беспокоится — тогда да, лучше пусть саппорт отдувается, а «пипл хавает».
weirded
14.05.2016 20:50+5Хаха, у нас в пятом carbon billing еще года полтора назал кнопку «инет всем!» запилили, на случай если в выходные всё взорвалось, а денег на круглосуточный суппорт у провайдера не нашлось сейчас)
freefd
15.05.2016 00:41АСР не надо отключать, она и так уже неработоспособна к тому моменту :)
Следует иметь пару-тройку Emergency RADIUS-серверов (провайдер по своим масштабам сам количество выберет), которые не общаются с АСР, но раздают какой-то один общий для всех ISG/SUBSCRIBER профиль и описаны для всех BNG.
В момент глобальной неработоспособности АСР, в зависимости от реализации, эти RADIUS-серверы или включаются и при этом имеют больший приоритет на BNG, или отключаются все RADIUS-серверы, имеющие интеграцию с АСР.
acmnu
24.05.2016 18:38Хорошо, конечно, но что делать с паролями и аккаунтами? Пропускать всех? Или использовать устаревшую базу? А если телефония, то пропускать всех не стоит. Много вопросов тут.
RicoX
14.05.2016 21:39+5Во время чтения разбора полетов, фейспалм был почти на каждом абзаце. Общее ощущение от заметки выглядит как: «солидная компания возьмет в аренду дырокол». Отсутствие у клиента какой-бы то ни было системы мониторинга, отсутствие резервирования критичных сервисов, отсутствие плана «Б» когда в радиус либо тупо вгружается статический фаил с данными всех клиентов и настройкой пускать всех, на худой конец делается настройка радиуса пускать с любыми учетными данными до восстановления сервиса. Клиент переводящий критичные сервисы на новое железо без его нагрузочного тестирования, я могу продолжать еще долго. И это все на фоне оракла, apacheMQ и прочих плюшек под высокие нагрузки, вот на кой черт они нужны, если инфраструктуру строили ягодицами и системный архитектор профнепригоден? Вроди как не ваша вина, клиент виноват, но действия ваших специалистов вызывают не меньшие недоумения, не разобравшись в причинах и не предложив быстро разрешить любые авторизации, чтоб не пороть горячку, они кидаются добивать полуживые сервисы с надеждой на авось.
getElementById
14.05.2016 22:52-1Абонентам радиус выдает айпи-адреса, какие айпи-адреса вы положите в статический файлик?
RicoX
14.05.2016 22:53Скажу выдавать из динамического пула, либо сгенерю скриптом однострочником из доступных диапазонов, при условии что базе совсем труба и нельзя достать оттуда привязанные адреса вместе с логинами-паролями-портами и прочими данными radius.
getElementById
14.05.2016 22:57Так кем он из пула-то будет выдаваться? Как будет контролироваться отсутствие задвоений? Мне действительно интересно.
RicoX
14.05.2016 23:08Если интересно, то вот варианты:
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) Разворачиваем предварительно подготовленый сервис срочной доступности, тот же пул, но контролируется скриптом, в десяток строк на любом шел языке.
А вообще назовите реальный кейс сбоя с условиями, что живо что недоступно, какая технология ААА для абонентов и чем рулит радиус, подскажу возможные варинты.getElementById
14.05.2016 23:24Согласен, наколхозить несложно. Моя основная обеспокоенность была в том будет ли участвовать база данных в предлагаемых решениях :)
RicoX
14.05.2016 23:34В варианте с пулом база может быть мертвой наглухо, по большому счету нужен будет радиус, поднятый где угодно, с разрешением все-всем и передачей единственного атрибута 88, дальше разрулят брасы. Есть опыт восстановления базы на 60К+ абонов, где база чебурахнулась наглухо без возможности восстановления совсем, а я был с командой, которой поручили поднять максимально работу клиентов и восстановить хоть какую-то работу плюс собрать базу с нуля по ААА данным, которые посылали клиенты. Ничего за 6 часов в незнакомой сети, без документации, без схем, без биллинга и каких-либо бэкапов, на голом железе и привезенном с собой серваке и брасах восстановили 80% работы.
dkoplovich
14.05.2016 23:14Не меньшее количество шлепков ладони по лицу прозвучало и при написании статьи. К сожалению, не у всех компаний есть желание вкладываться в инфраструктуру (и понимание, зачем вообще это делать), так же как ограничены и наши возможности влияния на клиента. Конечно же, хотелось добавить в статью несколько эмоциональных оценок, и первоначально они даже в ней были, но злобное начальство подвергло статью цензуре перед выпуском и предоставило воображению читателю самому додумать, какие монологи и диалоги происходили в процессе решения проблемы.
Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.
Вы скажете: так делайте же время от времени выгрузку всего необходимого в файл и при аварии используйте этот файл. И будете правы, только у каждого клиента этот файл будет свой, то есть нужно делать кастомизацию выгрузки. А будут ли за эту кастомизацию делать (или платить) те, кто мониторинг не хочет настраивать (или покупать)?
Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.RicoX
14.05.2016 23:28Я так понимаю ответ был мне, хоть и не в ветке комментария. Пару ремарок, по поводу выгрузки, радиус передает обычно от 0 до максимум 10 атрибутов, выгружать эти данные простым селектом в фаил раз в час дело не мегасложное и особой кастомизации не требует, зато в случае: «шеф все пропало, за что мы бабки платим, чините все срочноооо», вы просто переводите радиус на данную выгрузку и спокойно под кофе с плюшкой разгребаете проблему. Второе, если сервис дохлый — никогда, вот совсем никогда, нельзя его перегружать если нет его горячей замены и вы не уверены что все заработает, во первых это скроет все следы инцидента и дебаг команда вас возненавидит, во вторых хрен потом с него считаешь данные, если на резерве/бэкапе чего-то не хватает. Мне видится такой сценарий, подымаем пусть даже на своих мощностях новый радиус (думаю есть готовые сборки и займет менее пары минут) пропихиваем актуальные данные на него, переключаем брасы на него, с полудохлого уходит нагрузка и можно его полноценно отдебажить. Самое сложное при факапе не пороть горячку и не делать действий, которые невозможно откатить, в этом я считаю была основная ошибка саппорта в данной ситуации, ну мне с дивана так видно, хотя в защиту дивана скажу, что построил не один десяток провайдеров разных объемов и хорошо знаю кухню изнутри.
dkoplovich
14.05.2016 23:39-1Полностью с вами согласен. Могу только добавить, что как только стало понятно, что ситуация ухудшилась, инженеры имели возможность удалить все, что скопилось во входящих очередях. Прямо сейчас не могу выяснить, что именно они сделали, когда ухудшение стало заметно, но скорее всего так и поступили. То есть это действие было обратимым.
getElementById
14.05.2016 23:48Повторная заливка данных не приводит к отказам в обслуживании уже работающих абонентов, а лишь добавляет задержку для активации существующих. Просто первого числа люди не хотят ждать, когда их включит и звонят с требованием включить услугу, что понятно. Сделать выгрузку из биллинга, скажу честно, суперпросто, потому что данные там хранятся в том виде, в котором они должны оказаться в базе радиуса. Но делать это в момент факапа довольно рискованное занятие. Сам инцидент продлился несколько часов, в течение которых были задержки во включении оплативших абонентов, в остальном все работало, поэтому подвергать риску работающих абонентов все же не стоило. Конечно, если бы сценарий был отработан заранее, то… но здесь мы уже ходим по кругу.
freefd
15.05.2016 01:01DHCP на IPoE инсталляциях должна BNG-коробка, а не RADIUS-сервер. RADIUS должен доставлять профиль и сервисы пользователя: OpenGarden, ночные тарифы, турбо-кнопку, детские интернеты, вот это вот всё.
Равно как давно пора перестать привязывать пользователей по IP к портам, Option 82 в 2001 году придумали. За 15 лет разве что утюги и чайники не имеют его в своей функциональности.
ZurgInq
Сравнимы ли для данного случая apache kafka и apacheMQ? Мне кажется kafka в данном случае по умолчанию не дала бы потерять сообщения. В то время как apacheMQ и rabbitMQ требуют не забыть включить подтверждение доставки.
getElementById
Вряд ли. ActiveMQ выбрана не по причине какой-то особенной любви к ней, а потому что она из коробки работает с ораклом. И производительность ее как брокера гораздо выше, чем у оркала, то есть она не является узким местом. Вопрос подтверждения сообщений — это вопрос используемого протокола, в данном случае это был STOMP. Он, прямо скажем, примитивен, но работает. Даже потеря сообщений не такая большая проблема — всегда можно отправить все их заново, на это всегда был расчет, как на крайний случай, но беда, как уже было сказано, не приходит одна.