Самый большой даунтайм в истории Селектела.



В период с 24 по 25 сентября наблюдалась потеря связности сегмента сети дата-центра Цветочная, которую долгое время не удавалось локализовать. Также 25 сентября был зафиксирован обрыв кабеля между разными сегментами сети (в следствии стрельбы по оптическому кабелю из пневматического оружия) что повлекло за собой обрыв связи в облаке между хост-машинами и СХД (система хранения данных).
Прежде всего, сеть дата-центров Селектел приносит официальные извинения за доставленные неудобства.Ниже мы постараемся подробно восстановить хронологию событий, рассказать о том, что сделано для предотвращения таких ситуаций в будущем, а также о компенсациях для клиентов, пострадавших в результате этих неполадок.

Первый сбой

Проблемы начались вечером в понедельник 24 сентября (даунтайм 22:00 — 23:10). Со стороны это выглядело как потеря связности с петербургским сегментом сети. Данный сбой повлек за собой проблемы во всех наших интернет-сервисах в Санкт-Петербурге; московский сегмент сети, а также локальные порты серверов продолжали работать. Также были недоступны DNS (ns1.selectel.org и ns2.selectel.org), которые находятся в Санкт-Петербурге, московский DNS (ns3.selectel.org) данный сбой не задел. Из-за отсутствия связности пропал доступ к сайту и панели управления, на телефонию пришлась основная нагрузка, в связи с чем многие клиенты могли не дождаться ответа.

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

Sep 24 22:02:02  chassism[903]: CM_TSUNAMI: i2c read on register (56) failed
Sep 24 22:02:02  chassism[903]: cm_read_i2c errno:16, device:292

По факту, перестали работать все оптические 10G Ethernet-порты на шасси коммутаторов уровня агрегации.

Sep 24 22:01:49  chassisd[952]: CHASSISD_IFDEV_DETACH_PIC: ifdev_detach_pic(0/3)
Sep 24 22:01:49  craftd[954]:  Minor alarm set, FPC 0 PEM 0 Removed
Sep 24 22:01:49  craftd[954]:  Minor alarm set, FPC 0 PEM 1 Removed

После перезагрузки всё заработало стабильно. Так как конфигурация сети до этого долгое время не менялась, и никаких работ до аварии не проводилось, то мы посчитали, что это разовая проблема. К сожалению, всего через 45 минут эти же коммутаторы снова перестали отвечать, и были еще раз перезагружены (23:55 — 00:05).

Понижение приоритета коммутатора в виртуальном шасси

Так как в обоих случаях первым выходил из строя один из двух коммутаторов в виртуальном шасси, и только следом за ним переставал работать второй, было сделано предположение, что проблема именно в нем. Виртуальное шасси было переконфигурировано таким образом, что основным стал второй коммутатор, а другой остался только в качестве резерва. В перерывах между выполнением операций коммутаторы еще раз были перезагружены (00:40 — 00:55)

Разобрано виртуальное шасси, все линки перенесены на один коммутатор

Спустя примерно час очередной сбой показал, что выполненных действий оказалось недостаточно. После освобождения и уплотнения части портовой емкости, нами было принято решение полностью отключить сбойное устройство от виртуального шасси и все линки перевести на “здоровый” коммутатор. Примерно к 4:30 ночи это было сделано (02:28 — 03:01, 03:51 — 04:30).

Замена коммутатора на запасной

Однако через час перестал работать и этот коммутатор. За время пока он еще работал из резерва был взят точно такой же полностью новый коммутатор, установлен и настроен. Весь трафик был переведен на него. Связность появилась — сеть заработала (05:30 — 06:05)

Обновление JunOS

Спустя 3 часа, около 9 утра, всё повторилось вновь. Мы решили установить другую версию операционной системы (JunOS) на коммутаторе. После обновления всё заработало (08:44 — 09:01)

Обрыв волокон между дата-центрами

Ближе к 12:00 были запущены все облачные сервера. Но в 12:45 произошло повреждение оптического сигнала в кабеле, который объединял сегменты сети в разных дата-центрах. К этому моменту из-за вывода из работы одного из двух опорных коммутаторов сеть работала только по одному основному маршруту, резервный был отключен. Это привело к потере связности в облаке между хост-машинами и СХД (сеть хранения данных), а также к недоступности серверов, размещенных в одном из петербургских дата-центров.

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



Нашим очевидным действием стало переключение на второй канал, не дожидаясь восстановления волокон по первому каналу. Это удалось сделать достаточно быстро, но только-только всё заработало, как снова зависание коммутатора. (12:45 — 13:05)

Оптические SFP+ трансиверы

В этот раз в новой версии JunOS в логах появились внятные сообщения и удалось найти жалобу на невозможность прочитать служебную информацию одного из SFP+ модулей,

Sep 25 13:01:06  chassism[903]: CM_TSUNAMI [FPC:0 PIC:0 Port:18]: Failed to read SFP+ ID EEPROM
Sep 25 13:01:06  chassism[903]: xcvr_cache_eeprom: xcvr_read_eeprom failed - link:18 pic_slot:0

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

Однако спустя 3 часа ситуация снова повторилась. В этот раз в сообщениях не было указания на сбойный модуль, мы сразу решили заменить все трансверы на новые из резерва, но и это не помогло. Начали смотреть все трансиверы по очереди, вытаскивая по одному, был найден еще один проблемный трансивер уже из новой партии. Убедившись в том, что проблема с коммутаторами решена, мы провели перекроссировку внутрисетевых подключений для перехода на основную схему работы (16:07 — 16:31, 17:39 — 18:04, 18:22 — 18:27)

Восстановление работы облачных серверов

Поскольку масштаб проблемы изначально был не ясен, мы несколько раз пытались поднять облачные серверы. Машины, расположенные на новом хранилище (начало uuid’ов для SR: d7e… и e9f...) первые аварии пережили только как недоступность интернета. Облачные сервера на старых хранилищах, увы, получили I/O Error для дисков. При этом совсем старые виртуальные машины перешли в режим read only. Машины более нового поколения при этом имеют настройку error=panic в fstab, которая завершает машину в случае ошибки. После нескольких перезапусков, к сожалению, сложилась ситуация, когда подготовка хостов к запуску VM занимала непозволительно много времени (массовые IO error для LVM довольно неприятны; в некоторых случаях умирающая виртуальная машина превращается в зомби, а их отлов и завершение требует каждый раз ручной работы). Было принято решение перезагрузить хосты по питанию. Это вызвало ребут для виртуальных машин с новых хранилищ, чего мы очень не хотели делать, но позволило значительно (минимум в три раза) сократить время запуска всех остальных. Сами хранилища при этом стояли без сетевой активности и с нетронутыми данными.

Предпринятые меры

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

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


Компенсации

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

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



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