Падение VK. Современные проблемы дата-центров

Падение VK 16 февраля 2018 г. стало знаковым явлением в современной индустрии построения и развития дата-центров и ЦОД. И даже не потому, что Вконтакте стал частью нашей обыденной жизни, и это явление было очень заметным для всех пользователей. Скорее наоборот, по отзывам многих недоступность серверов Вконтакте прошла почти безболезненно с учетом наличия альтернативы от стороны различных мессенджеров типа WhatsApp и Telegram. Скорее это обозначило тот факт, что высокая степень развития IT технологий, построение современных дата-центров, применения новейших технологий все еще не означает готовность отечественной инфраструктуры ЦОД к огромным масштабным проектам, требующим 100% отказоусточивость.

Причины

Проблема была у ДЦ XelentПервопричиной сбоя стало отключение напряжения в сети «Ленэнерго»ПС-97 110 кВ. Оно якобы произошло в 15.50. После этого включилось резервное энергоснабжение, но на работе сетевого оборудования перепад всё равно отразился. Его пришлось перезагружать, что заняло некоторое время.
«В момент переключения нагрузки произошло кратковременное прерывание синусоиды, которое длилось 24 мс, в результате чего перезагрузилось чувствительное сетевое оборудование некоторых телеком-операторов и сетевое оборудование Vkontakte», – говорится в сообщении Xelent.

 

Отмечу, что ДЦ Xelent новый (ему 4 года, до 2017 года он назывался SDN) и самый крупный в СЗФО. Находится он в пос. Парголово Ленинградской области. ЦОД рассчитан на 1476 стоек высотой 48U (это 9 серверных модулей по 164 ячейки в каждом, 6 из которых уже введены в эксплаутацию). Общая площадь модульного дата-центра составила 6 500 м2. Это современнейший дата-центр, предлагающий помимо традиционных сервисов колокейшена и VDS/VPS, еще и услуги SaaS (VDI – виртуальные рабочие столы) и IaaS (Infrastructure as a Service), включающия в себя VDC – виртуальный дата-центр; cloud storage – облачное хранилище.  Применяет решение Stack.КУБ, обеспечивающее 100% резервирование систем охлаждения и питания.

Подача электричества в дата-центры Москвы и Санкт-Петербурга осуществляется посредством динамических источников бесперебойного питания (ДИБП). Они объединены в группы 3+1. Одна установка является запасной, в то время как мощность между оставшимися 3 источниками распределяется динамически. Всего имеется 8 ДИБП с прямой дизельной поддержкой по 1600 кВА. Суммарная мощность системы бесперебойного питания для ИТ-нагрузки — 7,6 МВт. Используемая в Xelent система электроснабжения обладает следующими преимуществами:

Сама по себе система Stack.КУБ добавляет следующие возможности:

Услугами этого дата-центра пользуются на данный момент примерно 350 компаний, включая Вконтакте, крупного Питерского хостинг-провайдера Spaceweb, Петроэлектросбыт и Мираж-Синема. До этого момента этот ДЦ обеспечивал 100% uptime, и казалось, что там будет всегда. Но нет.

Даунтайм сервисом VK составил около 2 часов, в то время как для Spaceweb около 8 часов. На 3 часа ночи у Spaceweb восстановлена Почта, часть сайтов клиентов и исходящий трафик. По моим подсчётам у них крутится около 20000 сайтов клиентов, в частности сайты отелей и кинотеатров, для которых доступность в выходные критична для букинга. Панели управления сайтами, биллинг и сайт самого хостера все ещё не работают. Хорошие будут потери. 

Последствия

Что они столько долго делали, если переключение на UPS якобы заняло 24 мс? Ну во-первых, очевидно, что паспортное время переключения на резервный источник в 24 мс в нагрузке таким не был. Обычно блоки питания сетевого оборудования нивелируют провалы до 50 мс. Собственно это и заставило свитчи перезагрузиться. Но если бы они просто перезагрузились, то через пару минут все бы заработало. По сообщения, их же пришлось перезагружать вручную. Очевидно, что было потеряно удаленное управление. То есть инженеры ДЦ побежали работать ногами. Благо у ВК есть свои дежурные инженеры, которые смогли сделать это оперативно.

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

Почему же когда VK стал доступен, часть сервисов его не работала? Это уже не связано напрямую с аварией ДЦ. Дело в том, что различные сервисы и модули у Вконтакте раскиданы по разным дата-центрам. Скажем, фото и видео хранятся в Московском дата-центре, а часть базы реплицируется с базами во втором ДЦ в Ленобласти, который находится в Невской Дубровке.

Возможно, именно репликация БД и вызвала частичную недоступность сервисов ВК после её поднятия. Мы видим, что пинги достигали 21000 мс! Это возможно при условии перегруженности канала и 100% загрузке серверов (обычно нагрузка не превышает 20%).

 
 

Второй вопрос — почему сервисы Spaceweb оставались столько долго недоступными. Понятно, что ресурсы поддержки ДЦ были брошены на поднятие сетевого оборудования VK, неужели не занимались другими? нет, не совсем так. Дело в том, что опять же перезагрузкой свитчей дело не кончилось.

После поднятия сети серверы Spaceweb продолжали быть недоступными. Соответственно, инженерам опять же пришлось работать ногами. Судя по всему, по очереди поднимали отдельные серверы, сначала клиентские VIP dedicated серверы, затем почтовые демоны, и только потом уже виртуальный хостинг. Сайт sweb.ru самого хостера поднялся одним из последних. 

Это говорит о том, что сервисы стали работать при отсутствии сети стали работать некорретно. Большой повод задуматься как администраторам Spaceweb, так и её клиентам. Кстати, я сам когда-то был их клиентом, хорошо, что я давно перевез свои сайты в дата-центр Leaseweb в Германии!

Выводы из power outage

А выводы напрашиваются неутешительные:

  1. используются несовершенные UPS и системы резервирования питания, раз свитчи ребутнулись после переключения;
  2. реальное время переключения питания на резервный источник значительно больше паспортного;
  3. почему свитчи пришлось перезагружать вручную? Почему они не перезагрузились автоматически? И это потребовало до двух часов? Или неверно настроены таски на самих свитчах, котоыре должны были обеспечивать корректную перезагрузку, или же проблема с операционкой самих сетевых девайсов. Надо работать с техподдержкой вендоров, чтобы избежать подобного в дальнейшем;
  4. power outage — это весьма стандартная заложенная возможная неисправность. Её надо не только предусмотреть, но и отрабатывать DRP (disaster recovery plan), чтобы убедиться, что переключение на резервные схемы работает. Судя по всему DRP здесь никто никогда не тестировал;
  5. квалификация инженеров даже крупных хостеров типа Spaceweb недостаточно для оперативного восстановления сервисов.

В России строят мощнейшие современные ДЦ, но со нестабильностью питания так и не научились бороться.

Популярность: 1%

Поделиться в соц. сетях

Share to Google Plus
Share to MyWorld
Share to Yandex

Понравилась публикация? Почему нет? Оставь коммент ниже или подпишись на feed и получай список новых статей автоматически через feeder.

Комментарии

Комментов еще нет.

Оставьте коммент

(обязательно)

(обязательно)