.jpg)
«Любые системы дают сбои, никуда от этого не деться», — утверждает директор по технологиям Amazon.com Вернер Фогельс. В апреле прошлого года платформа Amazon Web Services прервала обслуживание на четыре дня, о чем написали многие СМИ, а еще один сбой произошел в августе. В 2011 году не раз выходили из строя облачные сервисы и других операторов. В конце февраля этого года облако Microsoft Windows Azure остановилось из-за ошибки программистов, которые не учли существование високосной даты — 29 февраля. Несмотря на меры, которые принимают провайдеры, в облачных сервисах неизбежно будут происходить все новые перебои.
Предлагаем вашему вниманию несколько шагов, которые, по мнению экспертов, следует предпринять ИТ-отделам, чтобы перебои в работе облаков не застали их врасплох.
Пользуйтесь несколькими «зонами готовности» в AWS.
В Amazon Web Services есть так называемые «зоны готовности» (availability zones) в каждом географическом регионе и для каждого сервиса. Как утверждают в компании, каждая зона работает на отдельной физической инфраструктуре. Зоны разделены географически, поэтому даже крупные бедствия, вроде пожара, торнадо или наводнения, в большинстве случаев затронут только одну зону. В ходе прошлогоднего весеннего сбоя пострадали примерно 45% абонентов Relational Dababase Services, которые пользовались только одной зоной, тогда как среди пользователей нескольких зон пострадавших оказалось менее 3%, утверждается в послеаварийном докладе AWS. После апрельского сбоя в компании упростили одновременное использование нескольких зон, реализовав универсальный механизм распределения экземпляров среди зон и обеспечив ту же возможность в API.
Пользуйтесь несколькими регионами в AWS.
AWS располагает сетями в восьми регионах: восток США (Северная Вирджиния), запад США (Орегон и Северная Калифорния), Евросоюз (Ирландия), Азиатско-Тихоокеанский регион (Сингапур и Токио), Южная Америка (Сан-Паулу) и AWS GovCloud. Для дополнительной надежности и защиты, помимо применения мультизонного принципа, пользователи могут разместить рабочие нагрузки в нескольких регионах. Правда, это будет сложнее, чем распределить задачи по группе зон, так как для разных регионов понадобятся различные вызовы API.
Пользуйтесь услугами нескольких облачных провайдеров.
Если вы не чувствуете себя защищенными даже с применением мультизонного и мультирегионального подходов, пользуйтесь услугами нескольких провайдеров, советует аналитик Gartner Дрю Ривз. Здесь тоже не обойдется без подводных камней, так как некоторые провайдеры делят одни и те же центры обработки данных. Ривз рекомендует выяснять у самих провайдеров, делят ли они ЦОД с другими, чьими услугами пользуется заказчик.
Регламентируйте уровень готовности с помощью SLA.
Помимо технических мер можно принять и нетехнические, например заключить с провайдером облачного сервиса соглашение об уровне обслуживания, в котором будут предусмотрены штрафы за прерывания работы. Если заказчик пользуется услугами провайдера для нужд восстановления после катастроф, в SLA допустимо требовать уровня готовности до 99,999%.
Не можешь — не делай.
Если пользователь предъявляет чересчур высокие требования к доступности данных и приложений в облаке, возможно, публичные облачные сервисы просто ему еще не подходят, считает аналитик IDC Стив Хендрик. По его мнению, задача в данном случае решается просто: чем более важны для пользователя данные и вычислительные ресурсы, тем больше средств обеспечения отказоустойчивой работы и высокой готовности следует применять.