Аварии ЦОД: новости от Zoom, Telstra, Spotify, Equinix, Google, Microsoft, James Hay и Cloudflare

Дата-центр — это сложная система с множеством движущихся частей и критически важных элементов: электропитание, охлаждение, стойки, IT-оборудование, кабели и многое другое. Обычно все эти части и элементы проектируются и изготавливаются независимо друг от друга, а затем собираются в одну рабочую систему. По сути, это означает, что после развертывания оборудования операторы ЦОД щелкают выключателем и надеются, что все заработает. Однако часто сделать все идеально с первого раза не удается.

Когда проблемы решены, и ЦОД функционирует, возникает не менее сложная задача: необходимо сохранить его работоспособность. И, к сожалению, добиться этого также удается далеко не всегда, о чем свидетельствуют свежие новости об авариях в ЦОД и их последствиях от Zoom, Telstra, Spotify, Equinix, Google, Microsoft, James Hay и Cloudflare.

Авария в ЦОД James Hay Partnership вывела из строя сайт и службу поддержки компании

Британская инвестиционная компания James Hay Partnership сообщила о сбое в работе центра обработки данных, в результате которого 28 августа вышли из строя ее веб-сайт и служба телефонной поддержки клиентов. Компания разослала сообщения, информирующие клиентов об инциденте через Twitter и по электронной почте.

Примерно через сутки после инцидента сайт James Hay Partnership снова заработал. Пока не совсем ясно, что именно произошло в корпоративном ЦОД британская инвестиционная компании, и о каком именно дата-центре идет речь.

Неисправный ИБП вызвал пожар в лондонском дата-центре Telstra

Утром 27 августа экстренные службы были вызваны для тушения пожара в центре обработки данных телекоммуникационной компании Telstra, расположенном на территории района Айл-оф-Догс на востоке столицы Великобритании. Представители компании сообщили, что из-за пожара пришлось обесточить часть помещений ЦОД, внутри которых находилось в общей сложности 1800 серверных стоек. Инцидент затронул пространство площадью около 11 тыс. квадратных метров.

На место возгорания были отправлены четыре пожарные машины и 25 членов экипажа. По неподтвержденным сообщениям, возгорание было вызвано неисправным источником бесперебойного питания (ИБП). Судя по всему, в результате инцидента была повреждена лишь небольшая часть складского помещения. О каких-либо травмах персонала не сообщалось.

В дата-центре Equinix LD8 произошел серьезный сбой

Утром 18 августа в дата-центре Equinix IBX LD8, который также находится в Лондоне, Великобритания, произошел серьезный сбой. Отказ ИБП, случившийся после отключения подачи электроэнергии из центральной сети, вызывал серьезные проблемы с сетью, решить которые удалось лишь к вечеру того же дня.

Авария случилась в ЦОД на территории лондонского района Доклендс. Инженеры Equinix диагностировали основную причину даунтайма практически сразу же. Проблемы возникли из-за неисправной системы ИБП, авария которой, согласно отчетам Equinix, вызвала пожарную тревогу в центре обработки данных.

В одной из монтажных стоек, электропитание которой прекратилось после отключения центральной сети и ИБП, находился основной кластер маршрутизаторов Juniper MX и Cisco LNS. Причем отмечается, что маршрутизатор Juniper MX — это основное устройство, которое необходимо для работы всего оборудования в дата-центре LD8.

Многочисленные клиенты Equinix, включая Epsilon, SiPalto, EX Networks, Fast2Host, ICUK.net и Evoke Telecom и некоторые другие компании, использовали социальные сети, чтобы извиниться перед своими партнерами за отключение сервисов. Авария в Equinix IBX LD8 вызвала проблемы и в других центрах обработки данных, где наблюдались признаки периодической потери пакетов / увеличения задержек.

Глобальный сбой в работе платформы Zoom мог произойти по вине Amazon

24 августа пользователи Zoom по всему миру стали сообщать о перебоях в работе этой платформы для организации видеоконференций. Проблемы продолжались около четырех часов. Никакой официальной информации о причинах глобального сбоя представители Zoom в последующем не публиковали.

Известно, что Zoom работает по большей части на базе облака AWS, которое, в свою очередь, обслуживают дата-центра Amazon. Сервис начал испытывать беспрецедентный уровень нагрузки после того, как пандемия заставила офисный персонал перейти на работу из дома.

Сервис Spotify вышел из строя по всему миру

Сервис потоковой передачи медиа-контента Spotify редко выходит из строя. Но 19 августа произошло именно это. Причем авария затронула пользователей во всем мире. Во многих случаях пользователям удавалось воспроизвести лишь только несколько секунд песни, после чего они чем получали сообщение об ошибке. Проблема не коснулась тех людей, которые загружали песни на свои устройства.

Перебои в работе сервиса, затронувшие около трехсот миллионов пользователей Spotify по всему миру, продолжались полтора часа, после чего ошибка была исправлена. Выяснилось, что команда Spotify забыл обновить свой сертификат TLS. Инженеры Cloudflare заметили, что срок действия важного сертификата Spotify истек, и сервис восстановил работоспособность через несколько минут после того, как этот сертификат был снова продлен.

До того как была обнаружена реальная причина сбоя в работе сервиса, некоторые эксперты предполагали, что причиной является авария ЦОД. В феврале 2016 года сервис Spotify переместил свою внутреннюю инфраструктуру на облачную платформу Google после нескольких лет использования собственного центра обработки данных.

Сбой в системе электропитания ЦОД вызвал ошибки в работе сетевой инфраструктуры и хранилищ данных Google Cloud

29 июня сразу в двух регионах облачной платформы Google Cloud возникли проблемы после отключения подачи электроэнергии в ЦОД по неустановленной причине. Проблемы затронули пользователей из Северной Америки. Ошибки, влияющие на инструменты Cloud Networking и Persistent Disk, а также на другие службы, которые на них полагались, возникли в регионах us-east1-c и us-east1-d.

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

Облако Microsoft Azure начало сбоить в Азиатско-Тихоокеанском регионе

Пользователи облака Microsoft Azure из Азиатско-Тихоокеанского региона 14 июня начали сообщать о сложностях при получении доступа к ряду услуг. Перебои наблюдались в течение 2 часов и 40 минут. В Microsoft признали проблему и подтвердили, что у части клиентов, использующих Azure Active Directory, возникали сложности с аутентификацией при доступе к ресурсам.

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

Сбой в сетевой системе ЦОД нарушил работу инфраструктуры Cloudflare

17 июля операторы центров обработки данных Cloudflare столкнулись с перегрузками, которые привели к отключению части интернета. Примерно на час сотни тысяч сайтов, использующих веб-сервис Cloudflare, стали недоступны. Это произошло из-за первой глобальной аварии за всю историю данной компании, которая предоставляет целый ряд критически важных услуг вроде защиты от DDoS-атак и кражи личных данных, а также распределенных DNS.

В число крупных сайтов, которые работают на Cloudflare и оказались затронутыми инцидентом, входят Discord, Netflix, Feedly Politico, Shopify, League of Legends, Gitlab, Patreon, Medium и, как ни парадоксально это звучит, даже Downdetector.

Магистраль Cloudflare соединяет ряд серверных ферм по всему миру через частные каналы передачи данных. Это помогает поддерживать более быструю загрузку клиентских веб-сайтов. Недавнее отключение сайтов вызвал широко используемый DNS 1.1.1.1.

После расследования представители компании отметили, что отключение произошло во время работы над несвязанной проблемой, касавшейся сегмента магистрали от Ньюарка до Чикаго. Группа инженеров обновила конфигурацию на маршрутизаторе в Атланте, чтобы уменьшить перегрузку. Эта конфигурация содержала ошибку, из-за которой весь трафик через магистраль стал перенаправляться в Атланту. Это быстро перегрузило маршрутизатор в местном ЦОД и привело к отказу сетевых узлов Cloudflare, подключенных к магистрали.