Комментарии 63
Сравнимы ли для данного случая apache kafka и apacheMQ? Мне кажется kafka в данном случае по умолчанию не дала бы потерять сообщения. В то время как apacheMQ и rabbitMQ требуют не забыть включить подтверждение доставки.
Вряд ли. ActiveMQ выбрана не по причине какой-то особенной любви к ней, а потому что она из коробки работает с ораклом. И производительность ее как брокера гораздо выше, чем у оркала, то есть она не является узким местом. Вопрос подтверждения сообщений — это вопрос используемого протокола, в данном случае это был STOMP. Он, прямо скажем, примитивен, но работает. Даже потеря сообщений не такая большая проблема — всегда можно отправить все их заново, на это всегда был расчет, как на крайний случай, но беда, как уже было сказано, не приходит одна.
На скольких абонентах оно навернулось?
Абонентов не очень много, до 100 тыс. Предполагаю, что в описанных условиях оно навернулось бы и на много меньшем числе.
Я даже готов спорить что до 10К, нет резервирования, нет мониторинга, нет компетентных собственных админов, дебильная архитектура сети, дебильная привязка к 1 числу — такое раздолбайство могут себе позволить только провайдеры имени одного микрорайона, для которых репутация — это то, что они когда-то слышали, но ни разу не уточняли о чем речь, а SLA — непонятный набор букв.
Покажите пальцем у кого по другому? У меня достаточно информации, что тот же МТС хоть и имеет чтото, но работает гораздо хуже при проблемах у пользователя.
Скажу даже больше, как показывает практика, ни у кого из больших операторов в России нет вменяемой техподдержки и правильного отношения к пользователю.
Скажу даже больше, как показывает практика, ни у кого из больших операторов в России нет вменяемой техподдержки и правильного отношения к пользователю.
У крупных операторов другая специфика, чаще всего их бич первая линия — это абсолютно не компетентные ленивые и глупые работники сидящие на минимальной зп, отсюда и недовольство технической поддержкой крупных операторов, но в техническом плане, поверьте, там все более чем достойно и ситуацию вся сеть лежит пол дня из-за выхода из строя одного узла исключается еще на архитектурном уровне. Если проще, проблемы одного конкретного пользователя там могут тянуться месяцами передаваясь из отдела в отдел, пока дойдут до ответственных или не дойдут, но вот проблемы целостности крупных сегментов отлично мониторятся и исправляются, при этом все сдублировано, прописан жесткий SLA на все и руководители бригад экстренного реагирования не слабо отгребают в случае просрочек.
У совсем маленьких операторов (1К-5К пользователей) другая крайность, они готовы целовать любого пользователя лично между ягодиц и техподдержка за счет своей малочисленности и непосредственного контроля владельцами бизнеса, вежливая и быстрая, но большая часть проблем именно технического плана, т.к. еще нет денег на хорошее железо и специалистов и сеть строится «из говна и палок», вида нафига нам аппаратный BRAS, давайте развернем 10 серверов FreeBSD на неттопах — это же дешевле (реально видел).
Естественно везде бывают исключения, я видел и мелкие сети с очень грамотным проектом и крупные, где все делалось вообще на пофигу и всем было плевать за счет монополии в регионе, но лично я рекомендую пользователю при возможности выбора подключаться к оператору от 5К до 30К, тут чаще всего и техподдержка еще не сильно отдалена от админов и руководства и техническая часть уже имеет резервы, данный разбор полетов скорее исключение из правил, т.к. биллинг Гидра, для тех кто не в курсе, достаточно дорогой и меня удивляет что на него деньги руководство сети нашло, а на одного хорошего админа — нет, чаще бывает наоборот, но если бы было наоборот, то где бы мы прочли эту душещипательную историю.
У совсем маленьких операторов (1К-5К пользователей) другая крайность, они готовы целовать любого пользователя лично между ягодиц и техподдержка за счет своей малочисленности и непосредственного контроля владельцами бизнеса, вежливая и быстрая, но большая часть проблем именно технического плана, т.к. еще нет денег на хорошее железо и специалистов и сеть строится «из говна и палок», вида нафига нам аппаратный BRAS, давайте развернем 10 серверов FreeBSD на неттопах — это же дешевле (реально видел).
Естественно везде бывают исключения, я видел и мелкие сети с очень грамотным проектом и крупные, где все делалось вообще на пофигу и всем было плевать за счет монополии в регионе, но лично я рекомендую пользователю при возможности выбора подключаться к оператору от 5К до 30К, тут чаще всего и техподдержка еще не сильно отдалена от админов и руководства и техническая часть уже имеет резервы, данный разбор полетов скорее исключение из правил, т.к. биллинг Гидра, для тех кто не в курсе, достаточно дорогой и меня удивляет что на него деньги руководство сети нашло, а на одного хорошего админа — нет, чаще бывает наоборот, но если бы было наоборот, то где бы мы прочли эту душещипательную историю.
Тоже интересует данный вопрос. Пусть не точно, но хоть порядок узнать. Интересно сравнить со нашим самописным биллингом со своими «особенностями»
(коммент от физика-зануды)
> Кроме того была увеличена частота отправки heartbeat-пакетов — вместо пяти секунд время увеличилось до нескольких минут.
Частота была уменьшена. Увеличен был период
> Кроме того была увеличена частота отправки heartbeat-пакетов — вместо пяти секунд время увеличилось до нескольких минут.
Частота была уменьшена. Увеличен был период
НЛО прилетело и опубликовало эту надпись здесь
Безусловно, мониторинг нужен и, конечно же, клиенту об этом много раз говорили, писали, умоляли. Наш облачный мониторинг предлагали, но он же денег стоит — 3 тысячи рублей в месяц. И про сервисы говорили, что нужно разносить.
[sarcasm]ну дык 3 тысячи рублей в месяц — это ж целых 3 тысячи в месяц, а так ну подумаешь, один день не было у кого-то интернета, пусть бы сходили к тем, у кого интернет не выключили, хотя должны были[/sarcasm]
На самом деле, желание не тратить деньги на «ерунду» порой доходит до маразма. Несколько месяцев назад я нашел в одном достаточно крупном сервисе (больше 10 тысяч клиентов) уязвимость, которая позволяла получить доступ ко всем данным всех клиентов. Естественно, я предложил им сотрудничество. Получил чудесный ответ:
— У нас не предусмотрены выплаты за найденные уязвимости.
— Вас не смущает, что у вас могут украсть данные всех пользователей?
— Если не хотите сообщать нам информацию, можете продолжать пользоваться нашим сервисом с уязвимостями.
— У нас не предусмотрены выплаты за найденные уязвимости.
— Вас не смущает, что у вас могут украсть данные всех пользователей?
— Если не хотите сообщать нам информацию, можете продолжать пользоваться нашим сервисом с уязвимостями.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вот тут https://habrahabr.ru/company/latera/blog/267083/ мы подробнее описывали, что будет происходить с Гидрой при разнообразных отказах, в том числе и когда MongoDB навернется. А здесь — https://habrahabr.ru/company/latera/blog/280196/, почему мы вообще используем Mongo и как оно нам.
Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.
Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.
Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.
Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.
После каких объемов?
Мораль: в системе биллинга нормальных провайдеров должен быть рычаг «отключить биллинг», который бы позволял в аварийных условиях продолжить предоставлять доступ всем. Вне зависимости от оплаченности.
Это в условиях «оператор беспокоится о репутации». Если же не беспокоится — тогда да, лучше пусть саппорт отдувается, а «пипл хавает».
Это в условиях «оператор беспокоится о репутации». Если же не беспокоится — тогда да, лучше пусть саппорт отдувается, а «пипл хавает».
Хаха, у нас в пятом carbon billing еще года полтора назал кнопку «инет всем!» запилили, на случай если в выходные всё взорвалось, а денег на круглосуточный суппорт у провайдера не нашлось сейчас)
НЛО прилетело и опубликовало эту надпись здесь
Хорошо, конечно, но что делать с паролями и аккаунтами? Пропускать всех? Или использовать устаревшую базу? А если телефония, то пропускать всех не стоит. Много вопросов тут.
НЛО прилетело и опубликовало эту надпись здесь
JFYI аутентификация как раз велась через такой слепок. Проблема в том, что слепок перестал обновляться корректно, а это затронуло большое количество пользователей, потому что первого числа отрубает от трети до половины, они потом платят в течение дня и ждут интернета.
Те, кто заплатил вовремя, не пострадали :)
Те, кто заплатил вовремя, не пострадали :)
НЛО прилетело и опубликовало эту надпись здесь
Это не про провайдеров. Удивительно, но там даже админов на билинге может не быть. Т.е. просто нет человека, который поддерживает машину и все. Только менеджеры, которые, когда припечет, пойдут по офису и выдернут кого-нибудь занимающегося сетевыми вопросами, чтоб он попробовал реанимировать машину с Linux и Oracle.
Как раз слепок и был кривой, судя по статье. Вообще вопрос быстрой доставки статуса на авторизующие сервера (которые ещё обычно шардятся и реплицируются в хороших биллингах) это один из самых горячих вопросов последних лет, но мой взгяд. Конкуренция провайдеров усилилась и если раньше абонент не растраивался, когда интернет у него после оплаты появлялся минут через 10 (а то и через час), то нынче это считается уже как-то не современно. Абонент ожидает, что он махнул карточкой на сайте провайдера и интернет в тот же момент появился. Отсюда, наверное, использование диспетчера очередей в Гидре.
Хотя многие по-прежнему делают синхронизацию с ядром по расписанию. И типичный шаг там 5-10 минут.
Хотя многие по-прежнему делают синхронизацию с ядром по расписанию. И типичный шаг там 5-10 минут.
Синхронизация по расписанию в большинстве биллингов благополучно померла еще лет 5 назад, сейчас radius напрямую запрашивает атрибуты из базы при авторизации, если ее как таковой нет (IPoE), то при возникновении события шлется CoA на текущую сессию на брасе — это даже не секунды, а сотые доли. Жирные очереди в биллингах обычно возникают, если врубить детальную статистику клиентских сессий или еще какой дебаг режим, в остальных случаях авторизационная часть (radius + кеш базы с авторизационными данными) на 100К абонентов может крутится на хиленькой виртуалке не испытывая особых сложностей, тут скорее вопрос каким местом строится архитектура.
Я имел ввиду синхронизацию внутри биллинга, когда данные синхронизируются между центральным ядром и базами над которыми крутится радиус сервер. А у вас тут похоже очереди, что несколько быстрее, чем синк по расписанию.
Да очереди, от ядра к ААА сервисам и обратно, но там всего пара сотен событий в секунду в пиках при более чем 100К абонентов, далеко не самая нагруженная часть биллинга. Больше всего в биллинге ресурсы жрет формирование отчетов и различная аналитика с жирными запросами к базе, часть отвечающая за ААА это по сути одна сводная таблица и все этой части работает очень быстро, оплаты проходят мгновенно через платежные API, за исключением одного говнобанка, который API не умеет, а выписки по транзакциям скидывают раз в сутки на почту в excel, а там уже костыль их парсит, но это скорее исключение.
> но там всего пара сотен событий в секунду в пиках при более чем 100К абонентов, далеко не самая нагруженная часть биллинга.
В этом и приемущество: задержки минимальны. При синхронизации у вас происходят тяжелые выборки на обоих концах, а разница реплицируется. Это опять таки приводит к необходимости держать именно sql базу под радиусом (поскольку так удобнее).
Но я так понимаю, что все таки полная синхронизация у вас есть? На случай потери консистетности этого ААА сервиса из-за не дошедших, ошбочных событий, должна быть.
А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
В этом и приемущество: задержки минимальны. При синхронизации у вас происходят тяжелые выборки на обоих концах, а разница реплицируется. Это опять таки приводит к необходимости держать именно sql базу под радиусом (поскольку так удобнее).
Но я так понимаю, что все таки полная синхронизация у вас есть? На случай потери консистетности этого ААА сервиса из-за не дошедших, ошбочных событий, должна быть.
А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
Полная синхронизация конечно есть, на случай нарушения целостности очередей, но это не штатная ситуация и необходимость возникает достаточно редко. Так я как раз за очереди а не синку по крону.
Логи собираются централизованно на отдельный сервер логов, там же парсятся и настроены события для системы мониторинга. Статусы сессий в разных проектах по разному, есть где используется radius-proxy, есть где плотная связка реализована прямо с BRAS и он сам отдает статистику по сессиям, флоу — чаще всего отдельный сервер на зеркале трафика, на этом же зеркале висит DPI, одной из функций которого является агрегация и предфильтрация флоу, к тому же фильтры DPI позволяют получить более осмысленную картину с привязкой к сигнатуре трафика и сервисам, а не банально к портам, как в обычном варианте. Есть проекты где флоу не нужен вовсе, достаточно Interim-Update пакетов от радиуса, например когда в сети нету NAT, все тарифы безлимитны и нужны данные только по приблизительным объемам потребляемого трафика для аналитики, тогда полный флоу включается в сети только при каком-то серьезном дебаге, с биллингом не связан и в штатном режиме потушен вовсе.
А статистику вы как обратно в ядро загоняете? Например логи радиус сервера, статусы сессий, флоу. Или это отдельный сервис?
Логи собираются централизованно на отдельный сервер логов, там же парсятся и настроены события для системы мониторинга. Статусы сессий в разных проектах по разному, есть где используется radius-proxy, есть где плотная связка реализована прямо с BRAS и он сам отдает статистику по сессиям, флоу — чаще всего отдельный сервер на зеркале трафика, на этом же зеркале висит DPI, одной из функций которого является агрегация и предфильтрация флоу, к тому же фильтры DPI позволяют получить более осмысленную картину с привязкой к сигнатуре трафика и сервисам, а не банально к портам, как в обычном варианте. Есть проекты где флоу не нужен вовсе, достаточно Interim-Update пакетов от радиуса, например когда в сети нету NAT, все тарифы безлимитны и нужны данные только по приблизительным объемам потребляемого трафика для аналитики, тогда полный флоу включается в сети только при каком-то серьезном дебаге, с биллингом не связан и в штатном режиме потушен вовсе.
> Статусы сессий в разных проектах по разному, есть где используется radius-proxy, есть где плотная связка реализована прямо с BRAS и он сам отдает статистику по сессиям,
Любопытно. Обычно в биллингах можно посмотреть статус сесси в базе биллинга, а тут вы смотрите прямо в BRAS. Я такое тоже видел, но редко.
Любопытно. Обычно в биллингах можно посмотреть статус сесси в базе биллинга, а тут вы смотрите прямо в BRAS. Я такое тоже видел, но редко.
Из крупных, на сколько помню есть в Billmaster из коробки, из мелких кажется MikBill подобный функционал реализовывал ограниченно и UTM5, но только для Cisco ISG (могу ошибаться может еще к чему допилили с этим биллингом мало работал), если дать денег за доработку под железо оператора и в другие вкорячить можно, все равно у любого более менее крупного оператора биллинг даже если использован готовый все равно серьезно допилен под компанию. Из плюсов данные всегда актуальны и если сессия померла, то для оператора это видно сразу в админке, хранить в базе эти данные тоже надо, но скорее для отчетов и истории и эта часть синкается по крону, но у оператора всегда данные актуальны на момент открытия карточки абонента.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется очень сильно зависит от сложившихся традиций в регионе и к стабильности как таковой не имеет отношения вовсе. Я чаще всего встречаю что провайдеры региона используют примерно одни и те же решения в части инфраструктуры, т.к. и специалиста найти проще на обслуживание да и собственные админы сидят в «тусовке» и выбирают схожие пути решения одних и тех же задач. Так например сложилось что в GB популярный 802.1x, а на территории бывшего СССР прочно прижился PPPoE, причем KZ и AZ предпочитают так называемый Russian PPPoE, но это лирика, если говорить о стабильности, то плюс очередей именно в моментальности наступления события, что разгружает ТП от кучи бессмысленных звонков вида: «У меня отключился интернет, я заплатил, а он не включается — мне работать надо, срочно....», при этом в чем вы видите не надежность очередей, локальный BNG получает изменения не по крону, а онлайн при их наступлении, что во первых сглаживает нагрузку на синхронизацию и она ровная в отличие от варианта с синкой, где каждые 5-10 минут возникает всплеск, потом спад, во вторых, как уже говорилось выше, более удобная абоненту, в третьих проще дебажится, так как меньше событий в единицу времени и можно «на лету» дампить данные и смотреть что «пошло не так». По СХД, та же ситуация, практически у всех есть FC/FCoE полки, но и другие реализации хранилищ встречаются часто, кроме упомянутых вами еще различные реализации кластер ФС, которые по high availability уделывают классические полки в ряде сценариев. Я бы сказал так, где архитектор был адекватен, мы получим свои пять девяток на куче разных вариантов реализации, а где профнепригоден, как в статье, то при выборе любых самых навороченных решений общая стабильность будет желать лучшего, чего туда не напихай, т.к. стабильность она для сервиса в целом важна, а не только для конкретных отдельных компонентов.
НЛО прилетело и опубликовало эту надпись здесь
Капитальные затраты и риски мы получаем только при условии что нам ради «этой фишки» надо перейти с биллинга А, на биллинг Б, тогда полностью согласен с вами, но есть ситуация когда функционал добавляется в рамках планомерного развития текущего биллинга, используемого у оператора, тогда ни каких особых дополнительных затрат это не несет. Все операторы привязаны к своему выбранному биллингу, крупные естественно сильнее — это очевидно, но не все системы идут от онимы и имеют такую же архитектуру и идеологию. Например в одном гостелекоме регионального масштаба прекрасно работают очереди никак не сказываясь на стабильности.
Ладно предлагаю заканчивать флудить ветку, а то скатились уже от обсуждения факапа до особенностей биллинга региональных операторов, а то так скоро за NDA вылезать придется и мерятся абонентскими базами, а оно нам надо.
Ладно предлагаю заканчивать флудить ветку, а то скатились уже от обсуждения факапа до особенностей биллинга региональных операторов, а то так скоро за NDA вылезать придется и мерятся абонентскими базами, а оно нам надо.
Походу я знаю какой у вас биллинг стоит.
Во время чтения разбора полетов, фейспалм был почти на каждом абзаце. Общее ощущение от заметки выглядит как: «солидная компания возьмет в аренду дырокол». Отсутствие у клиента какой-бы то ни было системы мониторинга, отсутствие резервирования критичных сервисов, отсутствие плана «Б» когда в радиус либо тупо вгружается статический фаил с данными всех клиентов и настройкой пускать всех, на худой конец делается настройка радиуса пускать с любыми учетными данными до восстановления сервиса. Клиент переводящий критичные сервисы на новое железо без его нагрузочного тестирования, я могу продолжать еще долго. И это все на фоне оракла, apacheMQ и прочих плюшек под высокие нагрузки, вот на кой черт они нужны, если инфраструктуру строили ягодицами и системный архитектор профнепригоден? Вроди как не ваша вина, клиент виноват, но действия ваших специалистов вызывают не меньшие недоумения, не разобравшись в причинах и не предложив быстро разрешить любые авторизации, чтоб не пороть горячку, они кидаются добивать полуживые сервисы с надеждой на авось.
Абонентам радиус выдает айпи-адреса, какие айпи-адреса вы положите в статический файлик?
Скажу выдавать из динамического пула, либо сгенерю скриптом однострочником из доступных диапазонов, при условии что базе совсем труба и нельзя достать оттуда привязанные адреса вместе с логинами-паролями-портами и прочими данными radius.
Так кем он из пула-то будет выдаваться? Как будет контролироваться отсутствие задвоений? Мне действительно интересно.
Если интересно, то вот варианты:
1) Пул переносим на BRAS он же контролирует отсутствие задвоений, для juniper MX например будет выглядить так:
В самом radius передаем для всех абонентов просто имя пула в атрибуте 88
Для цисок аналогично, даже бомж-вариант программного браса accel-ppp умеет.
2) Передаем сгенерированые из диапазона значения, тоже повторений не будет.
3) Разворачиваем предварительно подготовленый сервис срочной доступности, тот же пул, но контролируется скриптом, в десяток строк на любом шел языке.
А вообще назовите реальный кейс сбоя с условиями, что живо что недоступно, какая технология ААА для абонентов и чем рулит радиус, подскажу возможные варинты.
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) Разворачиваем предварительно подготовленый сервис срочной доступности, тот же пул, но контролируется скриптом, в десяток строк на любом шел языке.
А вообще назовите реальный кейс сбоя с условиями, что живо что недоступно, какая технология ААА для абонентов и чем рулит радиус, подскажу возможные варинты.
Согласен, наколхозить несложно. Моя основная обеспокоенность была в том будет ли участвовать база данных в предлагаемых решениях :)
В варианте с пулом база может быть мертвой наглухо, по большому счету нужен будет радиус, поднятый где угодно, с разрешением все-всем и передачей единственного атрибута 88, дальше разрулят брасы. Есть опыт восстановления базы на 60К+ абонов, где база чебурахнулась наглухо без возможности восстановления совсем, а я был с командой, которой поручили поднять максимально работу клиентов и восстановить хоть какую-то работу плюс собрать базу с нуля по ААА данным, которые посылали клиенты. Ничего за 6 часов в незнакомой сети, без документации, без схем, без биллинга и каких-либо бэкапов, на голом железе и привезенном с собой серваке и брасах восстановили 80% работы.
Не меньшее количество шлепков ладони по лицу прозвучало и при написании статьи. К сожалению, не у всех компаний есть желание вкладываться в инфраструктуру (и понимание, зачем вообще это делать), так же как ограничены и наши возможности влияния на клиента. Конечно же, хотелось добавить в статью несколько эмоциональных оценок, и первоначально они даже в ней были, но злобное начальство подвергло статью цензуре перед выпуском и предоставило воображению читателю самому додумать, какие монологи и диалоги происходили в процессе решения проблемы.
Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.
Вы скажете: так делайте же время от времени выгрузку всего необходимого в файл и при аварии используйте этот файл. И будете правы, только у каждого клиента этот файл будет свой, то есть нужно делать кастомизацию выгрузки. А будут ли за эту кастомизацию делать (или платить) те, кто мониторинг не хочет настраивать (или покупать)?
Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.
Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.
Вы скажете: так делайте же время от времени выгрузку всего необходимого в файл и при аварии используйте этот файл. И будете правы, только у каждого клиента этот файл будет свой, то есть нужно делать кастомизацию выгрузки. А будут ли за эту кастомизацию делать (или платить) те, кто мониторинг не хочет настраивать (или покупать)?
Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.
Я так понимаю ответ был мне, хоть и не в ветке комментария. Пару ремарок, по поводу выгрузки, радиус передает обычно от 0 до максимум 10 атрибутов, выгружать эти данные простым селектом в фаил раз в час дело не мегасложное и особой кастомизации не требует, зато в случае: «шеф все пропало, за что мы бабки платим, чините все срочноооо», вы просто переводите радиус на данную выгрузку и спокойно под кофе с плюшкой разгребаете проблему. Второе, если сервис дохлый — никогда, вот совсем никогда, нельзя его перегружать если нет его горячей замены и вы не уверены что все заработает, во первых это скроет все следы инцидента и дебаг команда вас возненавидит, во вторых хрен потом с него считаешь данные, если на резерве/бэкапе чего-то не хватает. Мне видится такой сценарий, подымаем пусть даже на своих мощностях новый радиус (думаю есть готовые сборки и займет менее пары минут) пропихиваем актуальные данные на него, переключаем брасы на него, с полудохлого уходит нагрузка и можно его полноценно отдебажить. Самое сложное при факапе не пороть горячку и не делать действий, которые невозможно откатить, в этом я считаю была основная ошибка саппорта в данной ситуации, ну мне с дивана так видно, хотя в защиту дивана скажу, что построил не один десяток провайдеров разных объемов и хорошо знаю кухню изнутри.
Полностью с вами согласен. Могу только добавить, что как только стало понятно, что ситуация ухудшилась, инженеры имели возможность удалить все, что скопилось во входящих очередях. Прямо сейчас не могу выяснить, что именно они сделали, когда ухудшение стало заметно, но скорее всего так и поступили. То есть это действие было обратимым.
Повторная заливка данных не приводит к отказам в обслуживании уже работающих абонентов, а лишь добавляет задержку для активации существующих. Просто первого числа люди не хотят ждать, когда их включит и звонят с требованием включить услугу, что понятно. Сделать выгрузку из биллинга, скажу честно, суперпросто, потому что данные там хранятся в том виде, в котором они должны оказаться в базе радиуса. Но делать это в момент факапа довольно рискованное занятие. Сам инцидент продлился несколько часов, в течение которых были задержки во включении оплативших абонентов, в остальном все работало, поэтому подвергать риску работающих абонентов все же не стоило. Конечно, если бы сценарий был отработан заранее, то… но здесь мы уже ходим по кругу.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Судный день: К чему приводят скрытые ошибки асинхронной обработки данных при росте нагрузки