Возможно, вы ждали, что мы затолкаем этот косяк под ковёр, как и следовало бы сделать обычному хостинг-провайдеру. Но я обещал рассказать подробнее о причинах простоя.
Итак, оператор связи в дата-центре М9 запланировал техработы с 23:00 4 июля до часу ночи 5 июля по Москве. Предварительно — им нужно было обслужить и при необходимости поменять коммутатор уровня ядра плюс провести ещё ряд сопутствующих работ. Обещали до 2 часов без связи. Для нас это считается простоем (несмотря на то, что виртуальные машины работают и некоторые VDS-хостинги не рассматривают ситуацию без отключения сервера как простой) — мы оповестили своих клиентов, чьи ВМ физически были размещены в этом ЦОДе.
Примерно под конец планового времени простоя дата-центр сообщил про продление работ до 06:00 5 июля, то есть ещё на 5 часов. Уведомить об этом продлении в адекватное время мы не успели, потому что в этот момент как раз и закрутилась история.
Что вам надо знать про автономную систему для анонса сети
Фактически оператор связи поменял систему, откуда шёл анонс наших сетей в М9.
За несколько месяцев до этого из-за ужесточения всех регуляторных политик Роскомнадзора и санкционного давления на международного оператора связи (магистрального уровня) они, магистральщики, потребовали от нас заменить систему анонсирования со своей на нашу, чтобы вот эти российские IP-адреса не имели никакого отношения к их оборудованию.
Если что, анонс сетей — это идентификатор, кому принадлежит IP. Что-то вроде ИНН организации, только идентификатор сети. Идентификатор начинается на AS — автономная система, дальше набор цифр. Когда вы вбиваете свой айпишник на сервисе проверки IP и получаете название своего оператора — это как раз по IP устанавливается AS, а из него уже устанавливается, чья это сеть.
До этого времени магистральщики анонсировали сети со своих автономных систем. Если кто-то на что-то жаловался, то абуза просто пересылалась нам, мы реагировали. Физически на администрирование адресов это никак не влияло. После замены автономной системы, условно, был один адрес в реквизитах, стал другой.
Мы зарегистрировали автономную систему, это очень просто, примерно как поцеловать гадюку. Это некая новая сущность, которую надо админить и подавать отчёты в тот же РКН. Но взяли в работу, бесшовно заменили, и никто переключения не заметил — собственно, так и должно быть.
Что важно, в этот момент в RIPE NCC добавляется новая запись, а старая не затирается. Если всё работает хорошо, используется прайм-запись, если прайм не отвечает — используется старая. Далее, когда всё штатно работает, уже убирается старая. В районе марта мы убрали из RIPE старую, и осталась только актуальная (на самом деле не везде: есть 4 сети, где без согласия владельца арендованного IP нельзя удалять AS, только добавлять — но их мы со временем заменим). И всё работало штатно.
Возвращаемся в вечер 4 июля в M9
Итак, меняется железо, откуда физически отправляется анонс сетей. На момент техработ мы уже давно бесшовно сделали смену анонса, и актуальные данные по принадлежности сетей есть в двух базах — государственной РАНР и RIPE, которые совпадают с реальностью. Это важно, потому что для оборудования ТСПУ данные РАНР — основные. Если вдруг анонсы идут не так, как указано в РАНР, налицо подмена сети и трафик в ней блокируется.
Оператор менял коммутационное оборудование и наступил на те же грабли, на которые уже один раз наступали всем Рунетом.
Но детали мы узнали немного позже. Сначала у нас просто всё поднялось и заработало задолго до заявленного конца техработ. Потом, когда техработы закончились, трафик ещё некоторое время лился, чего хватило ровно на то, чтобы отметить, что опасный период пройден. А потом у нас вдруг отвалился трафик с площадки. Точнее, с серверов, расположенных на M9.
На самом деле всё чуть хитрее. Часть трафика отвалилась ещё до конца техработ, ночью. Админы ВМ, то есть наши клиенты, писали про это тикеты, а наши админы поддержки, соответственно, со спокойной душой их закрывали со словами «так техработы у провайдера же». Потом техработы кончились, а проблемы сохранились. Тамошние админы закрыли техработы и пошли спать. К моменту, когда они уснули, мы подняли ещё одну смену и вместе поняли, что работы закрыли как-то криво.
Около 6 утра мы висели на линии с админами ЦОДа и работниками магистральщиков. Но те админы, которые всё сделали, уже спали, следующие нормальные спецы просыпались в 10 утра, а те, что были на месте, имели полномочия только перезагрузить. Причём примерно полчаса ушло на диалоги в духе:
— Алло, пожарная! У нас напротив красный кирпичный дом горит!
— Да? А у нас тоже напротив такой же, и он не горит.
В итоге включили и выключили они несколько раз, это не помогло. В общем, если вам говорят про поддержку 24/7, помните, что иногда тикет начинается с побудки админа, который не 24/7.
Сначала мы грешили на кривой коммутатор. По симптомам это была аппаратная ошибка, и буквально недавно мы с такой же сталкивались. Почему мы так думали — потому что трафик терялся не из всех сетей. 4 подсети работали отлично и как ни в чём не бывало.
Железо включено, всё работает. До серверов можно по iBMC достучаться.
В это же время у нас в телеграм-канале начали появляться комментарии с разными невероятными версиями, которые вывели из себя дежурного админа, и так разогретого беседой со специалистами ЦОДа, и он успел пару раз не очень приятно для нас ответить. Эти комментарии до сих пор под постом, никто ничего не удалял, но объяснить пару вещей пришлось. Если вам хочется ответить резко — лучше разбудить меня или кого-то ещё из бизнеса. Вообще, кстати, меня не будили, считая, что это чисто техническая проблема — и, наверное, зря.
По трассировкам удалось понять, что же именно происходит — оборудование ТСПУ РКН дропало наш трафик. Стали думать, что проблемы там — потому что, повторяю, дропался не весь трафик, 4 сетки ходили без проблем. Но отключить трафик от ТСПУ нельзя, у нас и доступа к нему нет, да и оператор связи не имеет на это права.
Наконец, поняли, что же случилось. В общем, сотрудники оператора сменили старый коммутатор в нашей зоне и накатили не текущие конфиги, а из бекапа примерно полугодовой давности. Почему — это большой вопрос, на который от оператора до сих пор нет ответа. Сказали, человеческий фактор, ошибка админа.
В старом конфиге был старый анонс и старые данные по AS. Дальше оборудование ТСПУ увидело, что трафик автономки не совпадает с их базами, и нам начали резать трафик, потому что явно же какие-то мошенники. По правилам ТСПУ, при таком несоответствии попытка соединения есть, а трафик никуда не идёт, ничего не работает.
Примерно так же было в феврале, только в больших масштабах. До сбоя в Рунете не тот конфиг залили на коммутаторы.
Дальше возник вопрос — что делать быстрее. Можно в RIPE внести старую автономную систему, но растекание до новых анонсов от 2 часов до 2 суток. Либо срочно менять обратно конфиг на новом коммутаторе. В итоге приехал главный инженер этого оператора связи, как только поняли, что случилось, оперативно сделал. От 10 до 30 минут на разных подсетях анонсы разлились на правильную автономку, и всё заработало.
Осталось понять, что же было с теми 4 подсетями, которые работали
Тут сработал другой человеческий фактор.
Как я уже рассказывал, при смене AS при добавлении новой системы она становится прайм, а старая — вторичной. Потом старая удаляется. Так как сети в аренде, какие-то владельцы дают доступ поменять эти данные, какие-то нет и делают это сами. В целом старую можно и оставить, но правило хорошего тона — написать в RIPE и попросить убрать ненужные упоминания автономных систем. На большинстве систем так и было сделано в марте. Так как арендуем мы у разных личностей, где-то изменения идут оперативно, где дают сделать самим, где-то месяцами. На четырех подсетях не убрали старые автономки, то есть ТСПУ видели, что они актуальные, одна из автономок соответствовала. Чтобы вы понимали, почему анонсы не убрали, просто объясню, что конечные владельцы одной из сетей — иностранцы. Они сидят и не хотят менять — работает, не трогайте. У нас они были в плане на замену всех 256 адресов, но заменить не успели.
В итоге вредность владельцев сетей привела к тому, что эта сеть работала и осложнила нам постановку диагноза по другим. В остальных трёх плюс-минус такая же история.
Итого
На ряде машин даунтайм по сети был 7 часов. По тем машинам, где даунтайм вышел за пределы технических работ дата-центра, мы выплатили компенсацию согласно нашему sla.
Интересно, что в ЦОД входит два разных луча только этого провайдера двумя независимыми маршрутами: один из европейской части РФ, второй с восточной части страны. Физически это как будто два разных оператора в одном. Это независимые инфраструктуры в рамках одного глобального оператора. Но ТСПУ у всех операторов связи одинаковые. Через кого пакеты — всё фиолетово. Так что концепция критической инфраструктуры устаревает,
я как раз недавно написал статью в Forbes про то, куда смещается сегодня ландшафт рисков.
На всякий случай, если у вас ценная инфраструктура, берите машины в двух геораспределённых ЦОДах или провайдерах, как советует Амазон. Потому что даже у них регулярно подобное происходит. Может ли такой сбой повториться — да, может, и легко.
С провайдера до сих пор компенсацию мы не получили, хотя заявили сумму ущерба эквивалентную тому, что мы заплатили.
Никто, кроме нас, с тех пор про этот сбой ничего не опубликовал.
ruvds.com/ru-rub
