Год через призму даунтаймов — топ-10 перебоев в работе дата-центров за 2012 год

20 декабря 2012

Последствия урагана «Сэнди» ощутили на себе обитатели огромного региона. Природный катаклизм обернулся беспрецедентными проблемами для отрасли центров обработки данных, а также потрепал другую инфраструктуру региона.

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

Наглядный пример: 2012 год был годом отключений облачных сервисов. Несколько ведущих облачных платформ некоторое время простаивали. Больше всего досталось Amazon Web Services. Инциденты вызвали вопросы о надежности ведущих поставщиков облачных сервисов, но они также обернулись повышенным вниманием в адрес параллельного проектирования облачных приложений в разрезе множества зон и локаций для большей устойчивости. Между тем, «разбор полетов» по итогам урагана «Сэнди» только начался и будет продолжаться на отраслевых конференциях в 2013 году. Оцените на наш список Топ-10 даунтаймов 2012 года:

1. Ураган «Сэнди» (29-30 октября).

Дата-центры по всему Нью-Йорку и Нью-Джерси ощутили на себе мощь «Сэнди». Последствия варьировались в самых широких пределах: начиная с затопления и простоя некоторых объектов в Нижнем Манхэттене до многодневных марафонов на генераторах в ЦОДах по всему региону. «Сэнди» стал событием, которое выходит за рамки одного сбоя. Он стал отличным стресс-тестом беспрецедентных масштабов для гибкости и решимости отрасли дата-центров. Одним из пострадавших провайдеров, пожелавших поделиться своими историями, стала компания Datagram. Ее генеральный директор Алекс Реппен описал битву техников компании за восстановление системы после «апокалиптического» наводнения, которое обернулось выключением насосов, перекачивающих дизтопливо. Действительно, солярка стала краеугольным камнем работы по восстановлению ЦОДов: резервные системы электроснабжения взяли на себя ИТ-нагрузки в регионе, а это зачастую заставляло инженеров идти на подчас чрезвычайные меры, чтобы обеспечить непрерывное функционирование генераторов. Работа по восстановлению  непосредственно после природного катаклизма уже позади, поэтому внимание постепенно смещается в сторону продолжительной дискуссии о восстановлении в аварийных ситуациях, а также об устранении последствий подобных событий для самого здания и инженерной инфраструктуры – и эта дискуссия будет продолжаться в течение многих месяцев, если не лет.

2. Отказ DNS-серверов Go Daddy (10 сентября).

Крупнейший в мире регистратор доменных имен Go Daddy является одним из самых главных провайдеров DNS-сервисов, на его серверах находится 5 миллионов веб-сайтов, компания управляет более чем 50 миллионами доменных имен. Вот почему отключение 10 сентября было одним из самых разрушительных инцидентов 2012 года. На волне твитов росли всевозможные слухи и предположения. В результате некоторые пользователи пришли к мысли о том, что шестичасовой инцидент был результатом DDoS-атаки, но позже представители Go Daddy сообщили, что все было вызвано повреждением таблицах с данными маршрутизаторов. «Простой сервиса был вызван не внешними воздействиями,» сказал Скотт Вагнер, исполняющий обязанности генеральный директор Go Daddy. «Речь идет не о хакерской атаке и не об атаке типа «отказ в обслуживании» (DoS-атака; DDoS). Мы определили, что перерыв в обслуживании был связан с рядом происшествий во внутренней сети, которые привели к повреждению таблиц с данными маршрутизатора «.

3. Отказ сервисов Amazon (29-30 июня).

Сервис облачных вычислений Amazon EC2 поддерживает работоспособность ряда очень популярных сайтов, включая Netflix, Heroku, Pinterest, Quora, Hootsuite и Instagram. У этого успеха имеется и обратная сторона: когда в дата-центрах Amazon начались перебои с электроснабжением, «рябь» отключений пронеслась по всему интернету. 29 июня группа необычайно сильных штормов, известная как «Дерешо», прокатилась по северной части штата Вирджиния. Когда дата-центр Amazon в регионе лишился канала энергоснабжения от сети, генераторы не смогли работать должным образом, истощая запас энергии в источниках бесперебойного питания (ИБП). Представители Amazon заявили, что отключение дата-центра затронуло лишь небольшую часть оперативной деятельности, но ситуация усугубилась проблемами с системами, которые позволяют клиентам распределять рабочие нагрузки между несколькими дата-центрами. Инцидент имел место спустя всего две недели после другого сбоя в том же регионе. Еще один облачный сервис Amazon упал в конце октября.

4. Калгари — пожар в ЦОДе (11 июля).

Возгорание в дата-центре Shaw Communications в Калгари, провинция Альберта (Канада) обернулось перебоями в работе городских служб и задержкой сотен операций в местных больницах. Инцидент вызвал отказ основных и резервных систем, которые поддерживают ключевые общественные услуги. Государственные учреждения в свою очередь получили тревожный «звоночек». Теперь чиновникам предстоит убедиться, что во всех дата-центрах, которые управляют работой аварийно-спасательных служб, есть системы восстановления и переключения при отказе, способные сохранять работоспособность в крайне неблагоприятной среде — «идеальный шторм невозможных событий», которые совместно способны доказать несостоятельность плана борьбы со стихийными бедствиями.

5. Хаос в австралийском аэропорту (1 июля).

«Ошибка корректировочной секунды» — одна-единственная секунда была добавлена во все атомные часы мира — стала причиной появления множества новостей датированных первым июля. Изменение вызвало проблемы с компьютерами в системе бронирования билетов авиакомпании Amadeus, что обернулось длинными очередями и задержками путешественников в аэропортах по всей Австралии. Приостановки работы систем  стали причиной хаоса в системах регистрации, которые используются Qantas и Virgin Australia.

6. Отключение облачного сервиса Windows Azure (29 февраля).

Тут свою роль сыграла «Ошибка високосного года», согласно которой связанный с датой баг сертификата безопасности был спровоцирован наступлением 29 февраля (високосный день) – эта дата появляется в календаре раз в четыре года. Из-за данного инцидента клиенты Azure были лишены возможности управлять своими приложениями в течение 8 часов, при этом ряд сервисов Azure оказался недоступен для некоторых пользователей из североамериканского региона. «Эта проблема, как представляется, связана с механизмом расчета времени, который показал свою некорректность в разрезе високосного года», сказал Билл Лэйнг из Microsoft. Позже редмондовцы списали часть абонентской платы клиентов за сервисы, как того требует соглашение об уровне обслуживания (SLA).

7. Перебои в работе сайта Salesforce.com (10 июля).

Июнь и июль, как правило, являются самыми сложными месяцами в плане обеспечения бесперебойной работы ЦОДов. Справедливость этого утверждения ощутили на себе администраторы ресурса Salesforce.com, который периодически простаивал в течение обоих месяцев. Наиболее значительный из этих двух инцидентов произошел 10 июля. Он был вызван кратковременным перебоем в подаче электроэнергии от сети в дата-центре Equinix, расположенном в Силиконовой долине. Как это часто бывает, подача электроэнергии в дата-центр была восстановлена довольно оперативно, но за ней последовал длительный период восстановления для клиентов, которые работают с базами данных и приложениями. Equinix восстановила электроснабжение в течение одной минуты, но перебои в работе ресурса Salesforce.com имели место на протяжение более чем 9 часов.

8. Отключение Сирии от интернета (29 ноября).

За два минувших года мы узнали, что даунтайм может нести политическую составляющую. Это продемонстрировали «отключения» интернета в Египте и Ливии, а совсем недавно и в Сирии. 29 ноября представители сервиса интернет-мониторинга сообщили, что все 84 блока IP-адресов, относящиеся к Сирии, оказались недоступны. То есть страна была изолирована от остальной части интернета. Эксперты сервиса мониторинга CloudFlare предположили, что утверждения правительства о том, что кабели повредили террористы, не заслуживают доверия.

«Систематический характер отключения маршрутов (роутов) предполагает, что это было сделано через обновления в конфигурациях маршрутизатора, а не из-за физического отказа или повреждения кабеля,» говорится в сообщении CloudFlare.

9. «Предохранительный клапан» отправил Azure в нокаут (28 июля).

Иногда системы, созданные для защиты вашей сети, могут случайно стать врагом. 28 июля при отключении платформы облачных вычислений Windows Azure функция «предохранительный клапан», предназначенная для прерывания соединений во время пиков трафика, не была должным образом настроена, чтобы справиться с апгрейдом пропускной способности в рамках западноевропейского суб-региона. Это обернулось огромным потоком сообщений от системы управления сетью, что истощило ресурсы Azure. Результат – сервис был недоступен в течение 2 часов 24 минут для пользователей из Западной Европы.

10. Перебои в работе Hosting.com (28 июля).

Человеческие ошибки очень часто лидируют в списке первопричин перебоев в работе дата-центров. Пример подобной ситуации имел место в июле, когда 1100 клиентов Hosting.com не могли воспользоваться сервисом. Отказ произошел, когда специалисты компании проводили профилактическое обслуживание системы ИБП дата-центра в Ньюарке, штат Делавэр (США). «Ошибка при определении очередности работы с выключателями, которую совершила обслуживающая компания, вызвала отказ системы ИБП, что привело к потере критической мощности одной из подсистем ЦОД на объекте», сказал генеральный директор Hosting.com, Арт Зейл. «Не было отказа какой-либо критически важной системы электроснабжения или системы резервного питания – это целиком и полностью результат человеческой ошибки».

по материалам: datacenterknowledge.com

Всего комментариев: 0

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *