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.
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% средств, потраченных на пострадавшие виртуальные машины.
