Описание текущей ситуации со стабильностью работы:
За последние полгода у нас было, как многие заметили, несколько коротких даунтаймов и один длинный (больше 1 часа), которые приводили к недоступности нашего дата-центра.
Всего было 3 разных причины, которые приводили к даунтаймам. Опишу по порядку сами причины и найденные нами решения, которые не позволят в будущем повториться данным проблемам.
Введение: что такое Juniper и с чем его едят.
1. Самая затяжная проблема, которая и повторялась в течение полугода, возникла на нашем основном магистральном маршрутизаторе Juniper MX960, через который проходит весь трафик нашего ДЦ и всей нашей сети. Сама железка является крайне надёжной, с точки зрения аппаратной части. Он имеет 4 независимых блока питания, две продублированные управляющие платы. Данная модель маршрутизатора является рабочей лошадкой для большинства мировых операторов связи, но в силу специфики и ограниченного количества покупателей в мире выпускается исключительно под заказ. То есть вы не можете просто прийти в магазин и в тот же день забрать данный агрегат. Ожидание поставки подобных устройств может занимать от 2-х до 4-х месяцев после оплаты. То есть, компания Juniper не начнёт производство такого маршрутизатора, пока не получит за него деньги. Стоит такая железка от нескольких миллионов до нескольких десятков миллионов рублей, в зависимости от комплектации.
Приведённое мной описание предназначено в основном для непрофессионалов в сетевых технологиях, чтобы было понимание, что это не просто дешёвая глючная железка, которую мы купили по случаю на барахолке, лишь бы сэкономить на оборудовании (а такие комменты мелькали). Да, этот девайc сродни вашим домашним WiFi-роутерам, только во много раз мощнее, надёжнее и функциональней. Для примера, данный роутер может прокачивать более 10 терабит информации в секунду, в полной комплектации. Ваши домашние WiFi-роутеры будут расщеплены на атомы сразу после подачи такого потока информации (шутка, у самого дома такой же «Зухель» стоит).
Но даже в таких сверхнадёжных девайсах бывают ошибки в программном обеспечении, на одну из которых мы и натолкнулись.
Начало. И начались «Дудосы»!
Все началось с того, что мы стали разрабатывать свою систему защиты от DDoS-атак и фильтрации паразитного трафика. Кто с нами уже давно, тот помнит, сколько проблем было в начале 2016 года, связанных с большим количеством атак, как на наши собственные (привет, недоброжелательные конкуренты ) так и на ресурсы наших клиентов. И вопрос наличия качественной защиты встал ребром.
Здесь я позволю сделать себе еще одно отступление от основной темы, но оно позволит понять цепочку событий, которые привели к возникновению проблемы и пониманию, почему мы двинулись именно в эту сторону.
Существует всего два способа организации DDoS-защиты для хостера:
- Использовать внешнюю защиту от какого либо поставщика услуг.
- Организовать собственный программно-аппаратный комплекс защиты.
Первый вариант быстр и не требует капитальных вложений, но обладает рядом существенных минусов: значительно поднимает для конечного клиента стоимость услуги, поскольку защита становится ежемесячными операционными расходами в бюджет хостера, и весьма не маленькими. Также, при использовании внешней защиты, невозможно иметь резервный канал связи, поскольку сама парадигма работы систем защиты от атак сильно завязана на сессии, а при наличии двух каналов связи ситуация, при которой входящий трафик приходит через одного провайдера, а исходящий уходит через другого является обычным явлением. Входящий провайдер ничего не знает о том, что была открыта TCP-сессия, ответ по которой ушел через другого оператора. В таких случаях система защиты будет считать весь входящий трафик паразитным и, фактически, происходит полная блокировка защищаемого сервера. Если кто помнит, то мы через это проходили в 2016 году. Из данной проблемы вытекают сразу две: первая, что мы всецело должны зависеть от пиринговой политики «Анти-ддосера» и вторая, очень важная, мы должны отказаться от резерва. Казалось бы, у крупных и уважаемых компаний такая проблема должна быть сведена к минимуму. Увы, это оказалось не так. Опять же, вспоминаем, весну-лето 2016 года. Сначала мы были под защитой DDoS Guard, за неделю словили 4 даунтайма по их вине, вместе со всей их сетью и другими клиентами. На четвёртый раз они позвонили и деликатно попросили нас снять все наши анонсы с них, т.к. они не выдерживают объём нашего трафика и летящих на нас атак. Вывод – данный вариант подойдет не очень крупным хостерам, с чётко понятной спецификой трафика. С 2016 года наш трафик вырос в несколько раз (уже пробивали планку исходящего трафика в 80 Гбит/с). Слышал, что они с тех пор расширили свои мощности, но мы решились только прикрывать ими свои сайты, и только на время настройки собственного решения.
Далее был Ростелеком с его Arbor-ом. Сразу скажу, что связанность РТ существенно хуже нашей. Их пиринговая политика приводит к тому, что с большинством российских операторов они предпочитают общаться через заграничные стыки. Также, за 2 месяца сидения под защитой РТ мы словили 2 даунтайма по их вине, один из которых был очень серьёзным, в тот раз они положили половину своей сети. При звонке в их саппорт нам даже сказали, что тикет зарегистрировать не могут, поскольку у них у самих всё лежит. Далее – скорость реагирования на атаки у Ростелекома крайне не высока, по большинству атак нам приходилось писать письма, потом звонить и «пинать» их спецов, чтобы они руками накладывали нужные фильтры на свой Arbor. Причём в настройке постоянных фильтров нам было отказано, в силу очень большого объёма нашего трафика и большого количества подсетей.
Итог – может мы такие везучие, но скорее всего это говорит о том, что строить свою сеть на моно-связанности и зависеть от одного поставщика услуг для нас неприемлемо, поскольку проблемы возникают у любых компаний, вне зависимости от их размера и значимости. Итак, для нас остался только один доступный вариант – «пилить» своё решение.
Против лома нет приёма, если нет другого лома!
Ну а теперь ближе к делу. Для организации базовой защиты от DDoS-атак, нами было принято решение использовать возможности имеющегося у нас Juniper MX960. Для получения нужного функционала для фильтрации трафика нами была выбрана одна из стабильных прошивок (на тот момент времени) — 14.2R3. Обновление прошивки было произведено в начале осени 2016 года. В то же время мы существенно расширили каналы связи до нашего ДЦ – 160 Гбит/с. Как раз с того момента многие наши клиенты обратили внимание на существенно возросшую стабильность сети. Благодаря более широким каналам и грамотной настройки фильтров на обновлённом Джунипере, нашим сетевикам удалось добиться существенного повышения доступности нашего ДЦ. В течение этого времени фильтры постоянно улучшались, было произведено несколько минорных обновлений прошивок, для улучшения стабильности и расширения функционала. Хочу заметить, что некоторые из наших клиентов кто разбирается в Джуниперах, активно помогали нам с настройкой фильтров и давали полезные рекомендации для защиты тех или иных протоколов и приложений, за это им наше огромное спасибо. И до весны этого года практически не возникало серьезных проблем связанных с сетевой инфраструктурой. Сеть работала стабильно, фильтры постепенно совершенствовались. Но…
…Песец (маленький пушной зверёк ) подкрался незаметно…
Начиная, где-то с конца весны 2017 года, начали происходить спонтанные перезагрузки линейных карт (это те самые платы, куда втыкаются провода из мира и провода из ЦОДа и через них проходит весь трафик). Эти перезагрузки и выражались в 15-минутном даунтайме ДЦ. Перезагрузка плат как раз занимает эти самые 15 минут, в течение которых и не может передаваться через неё трафик. Природа данного поведения была не ясна, из логов самого джунипера толковой информации получить не удавалось. Мы рассматривали все варианты, от скачков напряжения (но откуда они на чистом питании?) до глюков железа и софта. Поначалу они были редки и спонтанны. С каждым разом Джунипер обвешивался дополнительными мониторингами, наши сетевики днями и ночами перерывали Интеренет и закрытый портал Джунипера в поисках решения данной проблемы. В течение всего лета мы поменяли много прошивок, откатывались на более ранние и ставили самые последние (от части отсюда и частые сетевые работы, которые мы объявляли), но проблема возникала вновь и вновь. И чем дальше, тем чаще она возникала. В итоге, ближе к концу лета, при очередном падении было замечено, что непосредственно перед перезагрузкой линейной карты на ней не было свободно ОЗУ. Это и вызывало автоматический ребут карты. Как раз в тоже время ребята наткнулись на описание исправления подобной проблемы в одном из последних багфиксов прошивки 14 версии. Проблема имеет номер PR1287192 (у кого есть вход на закрытый портал Juniper, может с ней ознакомиться). В этом релизе указано, что ошибка с утечкой памяти исправлена в прошивке 14.2R7-S8. Конечно же, мы сразу обновились до этой прошивки и… в сентябре она произошла снова! Причем последний сбой произошёл неприлично быстро после предпоследнего (пардон, за тавтологию %)). Последний раз это произошло вечером 26 сентября. В это время я только уехал на встречу, на которой собирался продуктивно обсудить «протекание вселенских потоков космических энергий под сводами Большого театра», а вместо этого, в течение часа, координировал действия всех сотрудников в связи со сложившейся ситуацией. После ряда звонков и оперативных совещаний было выработано совместное решение на экстренное обновление нашего любимого Джунипера до самой свежей стабильной прошивки 17 версии, которая вышла за два дня до этого. В ночь 27 сентября мы объявили экстренные сетевые работы, потому как тенденция показывала, что если ничего не предпринимать, то следующий даунтайм может произойти в любую минуту. Итак, обновление прошло успешно и…
Свершилось чудо! Друг спас жизнь друга!
Как показала статистика загрузки ОЗУ линейных карт на Джунипере, начиная с 27 числа, утечка памяти исчезла! И в текущей конфигурации Джунипер показал стабильную работу. Виват! Хэпи энд! Поднимаем бокалы с.., кому с чем нравится, и пьём за долгую и стабильную работу нашего любимого МХ-ика. Но…
Маленькие пушные зверьки любят ходить парами…
2. Теперь переходим ко второму эпичному случаю, который произошел в прошлую пятницу, вечером, 30 сентября.
Если я вас уже утомил своим длинным рассказом, то спешу заверить, что описание второй проблемы будет существенно короче.
В то же самое время у нас подходил к финальной стадии проект, связанный с выведением в отдельный сетевой контур части выделенных серверов клиентов. Необходимость в этом возникла в связи с быстрым ростом объёма серверов в нашем ДЦ, количество которых скоро перевалит за тысячу и необходимостью плавного перераспределения трафика на второй маршрутизатор (тоже Джунипер, но поменьше, MX80). Для плавного переброса трафика была разработана целая схема, с кучей настроек. Поскольку дедлайн по проекту был установлен на конец сентября, но в силу некоторых причин проект был затянут, это привело к тому, что финальные настройки выполнялись в пятницу вечером. И тут сошлось несколько факторов: со стороны руководства компании (в том числе и с моей, непосредственно) было сильное давление на админов о необходимости закончить проект в срок. В итоге сетевой инженер делал финальные настройки из офиса, потому как в этот день у него была необходимость работать в непосредственном контакте с программистами, которые также участвовали в этом проекте. На текущий момент времени наш офис и ЦОД расположены на некотором удалении друг от друга.
И вот сижу я дома, опускаю пакетик чая в чашку с кипятком, наслаждаюсь пятничным вечером… и тут, снова ложится ЦОД… Ну вот уже совсем не смешно становится! Только сказали, что всё исправлено, а тут снова! Что делать, несколько коротких звонков, сообщений в чаты компании. Выясняю, что квалификации дежурного инженера не хватает для перезагрузки Джунипера (ситуация крайне редкая, и дежурные инженера к нему почти никогда не подходят). Бросаю чай, прыгаю в машину, давлю тапочку в пол, мчусь к офису, забираю сетевика, снова давлю тапочку, летим в ЦОД, хорошо, что еще время ночное и пробок нет. В общем вы понимаете, что из одного часа и 20 минут, которые длился даунтайм, координация действий и дорога до ДЦ заняла порядка 40-50 минут.
Всё остальное многие и вас уже видели своими глазами, а кто не видел, может посмотреть запись прямого эфира в нашей группе в ВК (https://vk.com/ihor_hosting?w=wall-40099160_6364). Ну и дабы не скучать, мне пришла в голову идея сделать вам обзорную экскурсию по нашему ДЦ, а то на фотографиях на сайте показано далеко не всё и они уже старые. Да и некоторые товарищи ворчат, что мол фотки не наши, а ДЦ у нас в подвале, в размере полутора стоек, с освещением в виде одной лампочки Ильича и одним ИБП Ippon на 400 Вт (да и тот, наверно, с дохлыми батареями), а счётчики активных услуг на главной странице сайта – это фэйк, сделанный исключительно для красоты и обмана посетителей. А так, вы воочию смогли увидеть всё наше хозяйство и мы даже вместе покрутили дизель, спалив при этом литров 5 солярки. Хотел ещё показать вам, как красиво моргает наша тысяча серверов при полностью выключенном освещении, да телефон сел, ну и все устали уже. Главное, что всё закончилось хорошо…
А чай, таки, остыл…
В последующие дни мы провели полное расследование данного инцидента, в ходе которого было выяснено, что ошибок в конфигурации Джуника, сделанных нашим сетевиком, не было. Однако проведённое изменение конфигурации привело к спонтанному падению процесса, отвечающего за BGP-маршрутизацию. Это и привело к недоступности ДЦ. Такие ситуации и наводят на мысль, что пушные зверьки ходят парами, и судя по всему, мы наткнулись на очередную редко-воспроизводимую ошибку в прошивке, но уже самой последней версии. В связи с этим было принято решение свернуть данный проект, во избежание повторения ситуации. Сетевым инженерам сделано строгое предписание, все серьёзные работы с магистральным оборудованием производить только в непосредственной близости от самого оборудования. Дальнейшие изменения конфигурации Джунипера – свести к минимуму.
В общем – выводы сделаны, головы полетели, компенсации розданы…
И маленькая серая мышка пробежала вслед за песцами…
3. Ну и третий, позавчерашний недодаунтайм, как я писал постом выше, нередкая на наших московских просторах ситуация – обрыв оптики. Но благодаря наличию второго независимого оптического кабеля, который никак не пересекается с первым, простоя работы не было. К сожалению, опять же, как я писал выше, в таких случаях протокол BGP не умеет перестраиваться мгновенно. Интернет пока ещё не настолько совершенен, чтобы в нём не было «ни единого разрыва».
И немного позитива, в качестве эпилога.
Чтобы у вас не складывалось впечатление, что у нас только пушные зверьки по ЦОДу бегают, небольшой список того, что нам удалось добиться за последнее время.
- Решена проблема со спонтанной перезагрузкой нод из-за нехватки памяти (ситуация возникала далеко не на всех нодах, но некоторые наши клиенты столкнулись с этим). Нашим админам удалось подружить технологию KSM c панелями VMmanager, от компании ISPsystem. Это дало гарантированный резерв по ОЗУ для всех VDS на ноде.
- Опять же, админы отловили странный баг в сетевом драйвере, который проявлялся только на серверах марки ASUS и выражался в коротких разрывах сетевого соединения на VDS, которые находились на этих серверах.
- Наверно самая главная новость сентября. Мы, наконец-то, ввели в коммерческую эксплуатацию комплекс AntiDDoS S8080 от компании Huawei! Да! Да! Эпопея, которая длилась целых полтора года, увенчалась успехом. Весь сентябрь и по сей день ребята продолжают накачивать его защитными фильтрами. В течение сентября нами уже было отбито более 3700 атак на ресурсы наших клиентов! Большая часть атак отбивается в автоматическом режиме. При отсутствии атаки трафик проходит напрямую и не подвергается никакой фильтрации. В случае начала атаки, происходит автоматический переброс трафика под защиту Huawei. Фактически, мы являемся самым первым Российским хостером (ну или одним из первых, вдруг, кого-то пропустил ) который обладает полностью своей защитой от DDoS-атак, которая расположена в нашем собственном ДЦ.
- Написание собственной панели управления сдвинулось с мёртвой точки и скоро мы откроем доступ в нее для всех клиентов. Сейчас это, конечно, некая инфраструктурная основа, которая теперь будет постепенно наполняться разными инструментами. Со временем вся работа с нашими ресурсами будет переведена в неё. Первые два инструмента, которые станут доступны нашим пользователям, это удобный агрегатор аккаунтов BILLmanager. Это будет удобно для вебмастеров, которые обслуживают много клиентов и вынуждены часто переключаться между аккаунтами путём выхода из биллинга. Также, данный инструмент будет доступен для панелей VMmanager, если у вас много VDS на разных кластерах, то вы сможете легко открывать нужную панель без ввода логина и пароля.
Второй инструмент, над которым завершают работу наши доблестные программисты, будет полезен пользователям услуг выделенных серверов, он позволит контролировать расход трафика (который у нас получился, наверное, самым дешёвым в России и конкурирует по цене с зарубежными ДЦ) и просматривать графики загрузки канала сервера, обновляемые раз в 5 минут. А в последствии и в реальном времени.
Дальше – больше!
Мы работаем для вас, и каждый день стараемся сделать наш сервис лучше!
Всегда Ваш,
Генеральный директор
ООО «ТК МАРОСНЕТ» и Айхор Хостинг
Иван Лунгов
