Pull to refresh

У Selectel авария

Reading time 5 min
Views 5K

03 марта около 22:50 по Москве перестала отвечать машина в новом облаке.

Успел посмотреть график загрузки — на нем последние 15 минут была нулевая активность процессора.

Произвел 2 попытки перезагрузки и 2 принудительных выключения — неудачно.
Сейчас управление облаком отключено вообще.

На тикет ответил системный инженер:
Здравствуйте. Действительно, в работе нескольких серверов нашего облака прозошёл сбой. Наши специалисты работают над этой проблемой.
Приносим вам свои извинения.

Топик создаю, чтобы уведомить сообщество и немного снизить нагрузку на техподдержку.

К сожалению, авария оказалась значительно серьезнее.


Хронология


22:50 Начались проблемы. Нулевая активность на сервере, управление не работает.
01:25 Машины начали подниматься.
02:05 Похоже, обратно упало — машина точно так же перестала отзываться. Рано радовались.
04:00 amarao:
Виноваты. Данные сохранили без повреждений, а вот связь между СХД и хостами, да, поломалась, причём дважды.
Сейчас починили, пострадавшие машины запустили.

05:10 Dlussky обнаружил, что «ничего не работает», судя по графикам машина вырубилась около 4х
05:25 Dlussky выключили панель управления облаком, в поддержке говорят о сроках восстановления 0.5-3 часа
07:08 amarao:
Всё ещё боремся с проблемой и думаем о методах решения. Любая сравнительно высокая активность на диске приводит к параличу IO

10:00 Без изменений. Хотя нет, карму слили. Если опустится до 8 — убираю топик в черновики.
11:12 dyadyavasya:
Только что ответили на тикет:
«По предварительным оценкам специалистов, работы будут окончены в течении двух часов.»

14:00 Особых изменений ситуации нет. Зато карма вернулась в норму, спасибо добрым людям!
14:15 Сообщение в панели управления:
Стартуем машины.
Моя поднялась и работает, но пока подожду радоваться.
15:00 Мой сервер типа работает, график потребления ресурсов обычный, пингуется, но не работает ни один сайт ни доступ по ssh. Либо работы еще не окончены, либо там все умерло. Был запущен fsck. Сервер ожил.
15:04 amarao:
Последние следы аварии устранили.

Извините, люди.

Компенсация будет, завтра буду воевать за размер. Сейчас сделали так, чтобы ситуация не воспроизвелась. Решать по сути будем с максимальным приоритетом.

Ещё раз извините.


Официальное объяснение ситуации от amarao


Итак, что произошло.

Если в кратце — по-очереди (с интервалом в 10 минут) остановились raid10 массивы на обоих серверах, обеспечивающих кластер хранилища. Поверх этих массивов у нас находится flashcache (кеширующий слой) и drbd, работающий по протоколу С (синхронный режим записи).

Система была настроена по следующему алгоритму: если падает одно из хранилищ, второе продолжает работать. Какое из хранилищ живо, какое нет, определяется с помощью multipathd на хостах виртуализации.

Базовые тесты, которые мы прогоняли перед запуском включали в себя: падение одного из узлов (crash), потерю питания, вынимание (смерть) большего числа дисков, чем может пережить raid10, смерть рейда кеширующих ssd (тоже raid10), случайный админ, набравший 'reboot', вынимание сетевого кабеля и его «тыкание» туда/обратно (защита от split brain). Все эти тесты прошли и у (меня) была уверенность, что система достаточно живучая для наших нужд.

В эту ночь запустился обычный raid checking. Невинный процесс, который в фоновом режиме проверяет целостность рейдов. Хранилища в первом пуле и сейчас продолжают потихоньку этот процесс (около 2-5мб/с). Модуль ядра, выполняющий проверку, следит, чтобы latency не сильно возрастало, так что клиенты в нормальном режиме этого процесса замечать не должны.

Однако, возникла проблема (наша текущая гипотеза — баг в модуле ядра) — и наличие агрессивного IO (около 25 IOPS на каждый диск массива) одновременно с процессом проверки привело к остановке IO на массиве. Полностью. Настолько, что dd if=/dev/md10 of=/dev/null bs=512 count=1 просто «зависал». При этом со всех нижележащих дисков чтение напрямую было успешным и происходило на нормальной скорости. Это привело к тому, что iscsi target (а вслед за ними все остальные в цепочке) на io не получали ни успеха, ни ответа. Дополнительно ситуация осложнялась тем, что обычный «проверяльщик» multipath проверяет первые 512 байт диска на читаемость. Догадайтесь, были ли эти 512 байт кешированы в flashcache или нет… Ещё ситуацию запутывало то, что часть запросов (тех, кто был в ssd-кеше) обслуживалась нормально, и некоторое время запросы на запись тоже приходили без проблем. В какой-то момент кеш ssd переполнялся и возникала проблема с его скидыванием. Из-за синхронного режима drbd остановка (не ошибка, а именно остановка) привела к остановке обоих пиров. В теории проблему можно было решить всего лишь отключив «больного» пира (что мы и сделали в начале). Это помогло ненадолго, после чего проблема повторилась на втором (что ещё раз говорит о проблеме в модуле ядра, а не в железе). Именно в этот момент большинство клиентов заметило проблему. Поскольку запись была полностью парализована, мы не могли вернуть на место предыдущий пир, который поднялся к этому времени (и продолжил проверять диск как ни в чём ни бывало). Произошёл первый «глобальный ребут». У нас примерная скорость подъёма машин составляет примерно 2-3с на машину (машина стартует дольше, операция старта идёт в параллель). Где-то на 300 машинах скорость синхронизации начала стремительно падать (на самом деле она уже была 0, а «уменьшение среднего» было лишь случайным эффектом). Почти синхронно проблема повторилась на втором пире (который к этому времени тоже был перезагружен). Было принято решение попробовать обновить ядро, ситуацию это не исправило. Начали рисоваться планы «ручного восстановления». В это время мой помощник предложил «дать доребилдиться». Дали (350 минут). За это время я успел даже чуть вздремнуть (т.к. время уже подползло к 7 утра). На всякий случай — речь идёт не про «ребилд» в случае выхода диска из строя, а «ежемесячной» проверке живости всех дисков массива. Этот процесс шёл на всех 10ых рейдах, из которых собрано хранилище (на обоих хранилищах сразу) со скоростью примерно 200-250Мб/с.

К часу дня процесс закончился, ещё 10 минут занял ручной подъём обвязки кластера, ещё 5 минут перезагрузка пула (поскольку пострадали все машины во втором пуле, то не было смысла вручную исправлять и разбираться с мнением multipathd о том, кто жив, кто нет). Начался запуск. К 2 часам дня старт закончился и начался ручной разбор разного рода fsck, просящих нажать кнопочку на экране.

Выводы и принятые меры.
1) Как локальное решение «на ближайшие дни» — запрещён запуск resync рейдов.
2) В ближайшее время будет предусмотрен сценарий «не работает, но не сообщает об ошибке» для raid'а (и других блочных устройств в стеке — flashcache, lvm, drbd и т.д.)
3) Параллельно будет построен эквивалентный (дисков будет меньше и без SSD) стенд, где мы попытаемся воспроизвести ситуацию и заняться поиском конфигурации, в которой она не проявляется. Текущее наше предположение, raid0 поверх raid1 не должен себя так вести.
4) Заслать багрепорт (если п.3 будет успешным).

Извинения:

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

Компенсации:

В качестве компенсации принято решение вернуть 100% средств, потраченных на пострадавшие виртуальные машины.
Tags:
Hubs:
+42
Comments 159
Comments Comments 159

Articles