Что бы вы почувствовали, если в один прекрасный летний день дата-центр с вашим оборудованием стал бы выглядеть вот так?



Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». На фотографии один из четырёх дата-центров, где установлено оборудование, обслуживающее наш проект. За этими стенами находится около 4 тыс. единиц техники: серверы, система хранения данных, сетевое оборудование и т.д. — почти ? всего нашего оборудования.
Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.

Отрицание

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

Гнев

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

14:50. Поступила информация, что огонь подбирается к системе охлаждения. Но дойдёт ли? Дежурный системный администратор выводит внешний трафик с фронтов этого дата-центра.

На данный момент фронты всех наших сервисов продублированы в трёх дата-центрах, используется балансировка на уровне DNS, что позволяет убрать адреса одного дата-центра из DNS, оградив тем самым пользователей от потенциальных проблем с доступом к сервисам. В том случае, если проблемы в дата-центре уже произошли, он выходит из ротации автоматически. Подробнее можно почитать тут: Балансировка нагрузки и отказоустойчивость в «Одноклассниках».

На нас пожар пока никак не повлиял — ни пользователи, ни оборудование не пострадали. Авария ли это? Первый раздел документа «План действий при аварии» даёт определение понятию «Авария», а заканчивается раздел так:
«Если есть сомнения, авария или нет, то это авария!»

14:53. Назначается координатор аварии.

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

Торг

15:01. Начинаем отключать сервера, которые не завязаны на продакшен.
15:03. Корректно выключаем все зарезервированные сервисы.
Сюда входят не только фронты (на которые к этому моменту пользователи уже не заходят) и их вспомогательные сервисы (бизнес-логика, кеши и т.д.), но и различные базы данных с replication factor 2 и более (Cassandra, хранилище бинарных данных, холодное хранилище, NewSQL и проч.).
15:06. Поступила информация, что пожар угрожает одному из залов дата-центра. В этом зале у нас нет оборудования, но то, что огонь может перекинуться с крыши, на залы, сильно меняет картину происходящего.
(Позже выяснилось, что физической угрозы для зала не было, так как он герметично изолирован от крыши. Угроза была только для системы охлаждения этого зала.)
15:07. Разрешаем выполнение команд на серверах в ускоренном режиме без дополнительных проверок (без нашего любимого калькулятора).
15:08. Температура в залах в пределах нормы.
15:12. Зафиксировано повышение температуры в залах.
15:13. Больше половины серверов в дата-центре выключены. Продолжаем.
15:16. Принято решение о выключении всего оборудования.
15:21. Начинаем отключать питание на stateless-серверах без корректного выключения приложения и операционки.
15:23. Выделяется группа ответственных за MS SQL (их мало, зависимость сервисов от них не велика, но процедура восстановления работоспособности занимает больше времени и она сложнее чем, например, у Cassandra).

Депрессия

15:25. Поступила информация о выключении питания в четырёх залах из 16 (№6, 7, 8, 9). В 7-м и 8-м залах находится наше оборудование. Ещё о двух наших залах (№1 и 3) информации нет.
Обычно при пожарах электропитание сразу отключают, но в данном случае, благодаря скоординированной работе пожарных и технического персонала дата-центра, его выключали не везде и не сразу, а по необходимости.
(Позже выяснилось, что питание в залах 8 и 9 не отключалось.)
15:28. Начинаем разворачивать базы MS SQL из бекапов в других дата-центрах.
Сколько времени потребуется на это? Хватит ли пропускной способности сети на всём маршруте?
15:37. Зафиксировано отключение некоторых участков сети.
Менеджмент и продакшен-сеть изолированы друг от друга физически. Если продакшен-сеть доступна, то вы можете зайти на сервер, остановить приложение и выключить OS. Если же недоступна, то можно зайти через IPMI, остановить приложение и выключить OS. Если нет ни одной из сетей, то сделать вы ничего не можете. «Спасибо, кэп!», — подумаете вы.
«Да и вообще, как-то много суматохи», — возможно также подумаете вы.
Всё дело в том, что сервера даже без пожара генерируют огромное количество тепла. Точнее, когда есть охлаждение, они генерируют тепло, а когда его нет, то они создают адское пекло, которое в лучшем случае расплавит часть оборудования и отключит другую часть, а в худшем… вызовет пожар внутри зала, который практически гарантированно уничтожит всё.



15:39. Фиксируем проблемы с базой conf.

База conf является бекендом для одноимённого сервиса, который используется всеми приложениями продакшена для оперативного изменения настроек. Без этой базы мы не можем управлять работой портала, но сам портал при этом работать может.

15:41. Температурные датчики на Core сетевом оборудованим фиксируют показания близкие к предельно допустимым. Это коробочка, занимающая целую стойку и обеспечивающая работу всех сетей внутри дата-центра.



15:42. Issue tracker и wiki недоступны, переключаемся на standby.
Это не продакшен, но при аварии доступность любого knowledge base может быть критичной.
15:50. Отключилась одна из систем мониторинга.
Их несколько, и они отвечают за разные аспекты работы сервисов. Часть из них настроены на автономную работу внутри каждого дата-центра (то есть они мониторят только свой дата-центр), другие состоят из распределённых компонентов, прозрачно переживающих потерю любого дата-центра.
В данном случае перестала работать система обнаружения аномалий показателей бизнес-логики, которая работает в режиме master-standby. Переключились на standby.

Принятие

15:51. Через IPMI выключили без корректного завершения работы все сервера, кроме MS SQL.
Готовы ли вы к массовому управлению серверами через IPMI в случае необходимости?

---

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

---

16:13. Поступила информация о том, что на крыше лопнули фреоновые трубки от кондиционеров — это отложит запуск дата-центра после устранения пожара.
16:19. По данным, полученным от технического персонала дата-центра, прекратилось повышение температуры в залах.
17:10. Восстановили работу базы conf. Теперь можем поменять настройки приложений.
Почему это так важно, если всё отказоустойчиво и работает даже без одного дата-центра?
Во-первых, отказоустойчиво не всё. Есть различные второстепенные сервисы, которые пока недостаточно хорошо переживают отказ дата-центра, и есть базы в режиме master-standby. Возможность управлять настройками позволяет сделать всё необходимое, чтобы даже в сложных условиях минимизировать влияние последствий аварии на пользователей.
Во-вторых, стало понятно, что в ближайшие часы работа дата-центра полностью не восстановится, поэтому необходимо было принять меры, чтобы долговременная недоступность реплик не привела к дополнительным неприятностям вроде переполнения дисков в оставшихся дата-центрах.
17:29. Время пиццы! У нас работают люди, а не роботы.

Реабилитация

18:02. В залах №№8 (наш), 9, 10 и 11 стабилизировалась температура. В одном из тех, что остаются отключенными (№7), находится наше оборудование, и температура там продолжает расти.
18:31. Дали добро на запуск оборудования в залах №№1 и 3 — эти залы пожар не затронул.

---

На текущий момент проводится запуск серверов в залах №№1, 3, 8, начиная с самых критичных. Проверяется корректность работы всех запущенных сервисов. По-прежнему есть проблемы с залом №7.

---

18:44. Технический персонал дата-центра обнаружил, что в зале №7 (где стоит только наше оборудование) многие серверы не выключены. По нашим данным, там остаются включенными 26 серверов. После повторной проверки обнаруживаем 58 серверов.
20:18. Технический персонал дата-центра продувает воздух в зале без кондиционеров через мобильные воздуховоды, проложенные через коридоры.
23:08. Отпустили первого админа домой. Кто-то должен ночью поспать, чтобы завтра продолжить работы. Далее отпускаем ещё часть админов и разработчиков.
02:56. Запустили всё, что можно было запустить. Делаем большую проверку всех сервисов автотестами.



03:02. Кондиционирование в последнем, 7-м зале восстановлено.
03:36. Завели фронты в дата-центре в ротацию в DNS. С этого момента начинает приходить пользовательский трафик.
Распускаем большую часть команды администраторов по домам. Но несколько человек оставляем.

Небольшой FAQ:
Q: Что происходило с 18:31 до 02:56?
A: Следуя «Плану действий при аварии», мы запускаем все сервисы, начиная с самых важных. При этом координатор в чате выдаёт сервис свободному администратору, который проверяет, запустились ли OS и приложение, нет ли ошибок, в норме ли показатели. После завершения запуска он сообщает в чат, что свободен, и получает от координатора новый сервис.
Процесс дополнительно тормозится отказавшим железом. Даже если остановка OS и выключение серверов прошли корректно, часть серверов не возвращается из-за внезапно отказавших дисков, памяти, шасси. При потере электропитания процент отказов увеличивается.
Q: Почему нельзя просто запустить всё разом, а потом чинить то, что вылезет в мониторинге?
A: Все надо делать постепенно, потому что между сервисами есть зависимости. А проверять всё следует сразу, не дожидаясь мониторинга — потому что с проблемами лучше разобраться сразу, не ждать их усугубления.

7:40. Последний админ (координатор) ушёл спать. Работы первого дня завершены.
8:09. Первые разработчики, инженеры в дата-центрах и администраторы (включая нового координатора) приступили к восстановительным работам.
09:37. Приступили к поднятию зала №7 (последнего).
Параллельно продолжаем восстанавливать то, что не дочинили в других залах: замена дисков/памяти/серверов, починка всего, что «горит» в мониторинге, обратное переключение ролей в схемах master-standby и прочие мелочи, которых тем не менее достаточно много.
17:08. Разрешаем все штатные работы с продакшеном.
21:45. Работы второго дня завершены.
09:45. Сегодня пятница. В мониторинге по-прежнему довольно много мелких проблем. Впереди выходные, всем хочется отдохнуть. Продолжаем массово чинить всё, что можно. Штатные админские задачи, которые можно было отложить, отложены. Координатор новый.
15:40. Внезапно рестартанулась половина стека Core сетевого оборудования в ДРУГОМ дата-центре. Вывели из ротации фронты для минимизации рисков. Эффекта для пользователей нет. Позже выяснилось, что это было сбойное шасси. Координатор работает с починкой сразу двух аварий.
17:17. Работа сети в другом дата-центре восстановлена, всё проверено. Дата-центр заведён в ротацию.
18:29. Работы третьего дня и в целом восстановление после аварии завершено.

Послесловие

04.04.2013 г., в день 404-й ошибки, «Одноклассники» пережили крупнейшую аварию —в течение трёх суток портал полностью или частично был недоступен. На протяжении всего этого времени более 100 человек из разных городов, из разных компаний (ещё раз большое спасибо!), удалённо и непосредственно в дата-центрах, в ручном режиме и в автоматическом чинили тысячи серверов.
Мы сделали выводы. Чтобы подобное не повторилось, мы провели и продолжаем проводить по сей день обширные работы.

В чём основные отличия нынешней аварии от 404?

• У нас появился «План действий при аварии». Раз в квартал мы проводим учения — разыгрываем аварийную ситуацию, которую группа администраторов (все по очереди) должна устранить, используя «План действий при аварии». Ведущие системные администраторы по очереди отрабатывают роль координатора.
• Ежеквартально в тестовом режиме изолируем дата-центры (все по очереди) по сети LAN и WAN, что позволяет своевременно выявлять узкие места.
• Меньше битых дисков, потому что мы ужесточили нормативы: меньше наработка часов, строже пороговые значения для S.M.A.R.T.,
• Полностью отказались от BerkeleyDB — старой и нестабильной базы данных, требовавшей много времени на восстановление после рестарта сервера.
• Сократили количество серверов с MS SQL и уменьшили зависимость от оставшихся.
• У нас появилось своё облако — one-cloud, куда мы уже в течение двух лет активно мигрируем все сервисы. Облако значительно упрощает весь цикл работы с приложением, а в случае аварии даёт такие уникальные инструменты, как:
  
  • корректная остановка всех приложений в один клик;
  • простая миграция приложений со сбойных серверов;
  • автоматический ранжированный (в порядке приоритета сервисов) запуск целого дата-центра.

Авария, описанная в данной статье, стала крупнейшей со дня 404-й. Конечно, не всё шло гладко. Например, во время недоступности дата-центра-погорельца в другом дата-центре вылетел диск на одном из серверов, то есть осталась доступна только одна из трёх реплик в Cassandra-кластере, из-за чего 4,2% пользователей мобильных приложений не могли залогиниться. При этом уже подключенные пользователи продолжали работать. Всего по результатам аварии выявлено более 30 проблем — от банальных багов до недостатков архитектуры сервисов.

Но самое главное отличие нынешней аварии от 404-й в том, что пока мы устраняли последствия пожара, пользователи по-прежнему переписывались и делали видеозвонки в Tamtam, играли в игры, слушали музыку, дарили друг другу подарочки, смотрели видео, сериалы и телеканалы в ОК, а также стримили в OK Live.

А как проходят ваши аварии?