Прежде всего, мы хотим принести официальные извинения за самый большой даунтайм в истории Селектела. Ниже мы постараемся подробно восстановить хронологию событий, рассказать о том, что сделано для предотвращения таких ситуаций в будущем, а также о компенсациях для клиентов, пострадавших в результате этих неполадок.
Первый сбой
Проблемы начались вечером в понедельник 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.
При том, что формально даунтайм сервисов был меньше указанного в таблице (связность иногда появлялась и исчезала), было принято решение округлить даунтайм в большую сторону.
| Услуга | Время простоя | Компенсация |
|---|---|---|
| Виртуальный выделенный сервер | 11 часов | 30% |
| Выделенный сервер/сервер произвольной конфигурации | 11 часов | 30% |
| Размещение оборудования | 11 часов | 30% |
| Хостинг CMS | 11 часов | 30% |
| Облачные серверы | 24 часа | 50% |
| Облачное хранилище | 11 часов | 50% |
Еще раз приносим извинения всем, кого задело это происшествие. Мы отлично понимаем, насколько негативно сказывается сетевая недоступность для клиентов, но как-то ускорить решение проблем не могли по причине того, что ситуация сложилась нестандартная. Мы предприняли все возможные действия для максимально быстрого устранения проблем, но к сожалению, установить точную проблему аналитическим путем не удавалось и пришлось искать её перебором всех возможных вариантов, что в свою очередь заняло много времени.
