Серверы в ЦОД всегда включены, за исключением периодов планового обслуживания и неплановых даунтаймов, которых операторы дата-центров всячески стремятся избежать. Но не всем это удается. Время от времени в офлайн уходят серверы как небольших фирм, так и крупных корпораций. В качестве примера можно привести свежие инциденты, затронувшие таких гигантов как UKFast и Google, а также относительно небольшую компанию Davao Light and Power. Изучив их печальный опыт, вы сможете при необходимости устранить соответствующие уязвимости инфраструктуры своих собственных ЦОД, не допуская даунтаймов в будущем.
Дата-центр Davao Light and Power на территории Филиппин ушел в офлайн из-за пожара
В начале месяца в ЦОД коммунальной компании Davao Light and Power, базирующейся на острове Минднао на территории Филиппин вспыхнул пожар. Коммунальщики уведомили об инциденте службы экстренной помощи в 9 утра по местному времени в воскресенье 7 января. Пожар продолжался полтора часа, после чего бригада огнеборцев успешно его локализовала. К счастью, филиппинцам удалось избежать жертв.
Пока неизвестно, что именно вызвало пожар. Эксперты не исключают, что возгорание произошло в результате неисправности электрического оборудования. Подобные инциденты случаются в дата-центрах относительно часто.
Вследствие инцидента сотрудники Davao Light и Power были вынуждены временно обрабатывать платежи по счетам, жалобы и заявки вручную в главном здании, которое не было затронуто огнем. Им придется делать это в обозримом будущем, пока работоспособность дата-центра не будет полностью восстановлена.
ЦОД UKFast ушел офлайн после того, как рабочий задел киркой силовой кабель
12 декабря 2017 года в офлайн ушел ЦОД британской хостинговой компании и поставщика облачных услуг UKFast. Авария произошла в дата-центре компании под названием MANOC5. Он располагается в Манчестере (Великобритания). ЦОД ушел в офлайн, когда рабочие случайно перерубил силовой кабель, подключенный к объекту. Специалисты компания каждые полчаса через социальные сети информировали клиентов об успехах в устранении проблемы.
Впоследствии выяснилось, что ЦОД ушел в офлайн из-за нестабильности в работе электросети, возникшей в результате того, что подрядчик, занимавшийся гражданским строительством и действовавший не по поручению UKFast, перерубил кабель на расстоянии в 0,75 км от ЦОД.
Система ИБП дата-центра поддерживала нагрузку в течение расчетного времени, после чего начали работу генераторы. Однако из-за физического повреждения силового кабеля электроснабжение дата-центра было неустойчивым и прерывистым. В результате генераторные установки не смогли синхронизироваться и взять на себя обслуживание нагрузки.
Представители компании заявили о том, что после полного возобновления работы ЦОД начнется изучение возможностей внесения изменений в инфраструктуры, для того чтобы избежать повторения подобной ситуации.
Ошибка в системе отказоустойчивости дата-центра Google отключила два облачных сервиса
Один из облачных сервисов Google ушел в офлайн почти на два часа в понедельник 6 ноября 2017 года, в результате чего еще один сервис также оказался полностью недоступен, а другой стал работать с ошибками и показывать более высокие задержки. По иронии судьбы, причиной была проблема в системе, предназначенной для предотвращения даунтаймов облака.
Речь о системе Memcache, которая является частью платформы Google App Engine. Система Memcache ускоряет ответы на запросы к хранилищу данных, кэшируя их в памяти. Например, ответы на самые популярные запросы на веб-сайте могут быть отправлены прямо из памяти вместо получения ответа от базы данных или какого-либо другого типа хранилища данных, что обычно занимает больше времени.
Автоматической системе отказоустойчивости, созданной Google для Memcache, требуется доступ к информации о ресурсах центра обработки данных, обслуживающего каждое приложение. Таким образом, когда есть проблема с одним дата-центром, система может плавно переключать нагрузку на другой. Инцидент произошел, когда база данных, в которой хранятся данные конфигурации ЦОД, стала недоступна для чтения и записи после обновления конфигурации инфраструктуры этой серверной фермы. К счастью, проблему удалось решить в тот же день.
