USD 102.34
ЕВРО 106.54
Детальный анализ ситуации показал следующее:
Проблема, которая повлекла за собой сбой в работе клиентов эластичного
облака (EC2) неделю назад в первую очередь затронула часть хранилищ
Amazon Elastic Block Store (“EBS”) в единой Availability Zone внутри
региона US East Region, что привело к неспособности сервиса производить
операции чтения и записи. В этом документе мы назовем из «зависшими» томами.
Это, в свою очередь привело к тому, что объекты, которые пытались
задействовать эти тома, тоже «зависли» при попытке прочитать или записать
информацию. Чтобы восстановить тома и стабилизировать кластер EBS в
Availability Zone, мы отключили все контрольные API (т.е. Create Volume, Attach
Volume, Detach Volume, и Create Snapshot) для EBS в пострадавшей Availability
Zone почти на все время событий. Дважды в первый проблемный день сбойный
кластер EBS повлиял на EBS API и привел к большому числу ошибок и потерь
запросов EBS к этим API по всему региону US East Region. Как и любая
сложная операционная проблема, эта стала следствием взаимовлияния нескольких
ключевых проблем, поэтому дает нам возможности защитить сервис от повторения
подобных событий.
Эта дискуссия техно-гиков означает на обычном человеческом языке следующее:
системы Amazon испытали локальную перегрузку, что привело к потере контроля и
проблеме с доступностью. Более того — Amazon даже потерял данные клиентов.
С точки зрения CIOнужно иметь в виду следующее:
1. Небо не упало на землю и облака остаются на месте
Это событие может ненадолго замедлить внедрение облаков. По мнению делового
журнала The Economist, такие неполадки ставят вопрос, может ли
клиент полностью доверять базовой идее облаков – возможности купить сервис у
провайдера, также, как газ и воду у ЖКХ.
Однако, CIO считают, что значение облачных сервисов и SaaS увеличивается.
Недавнее исследование
Computer Economics проливает свет на рост инвестиций в
SaaS, показанном на рис:
2. Облачные сервисы могут быть как помощниками, так и
врагами
Централизованные средства обслуживания являются ядром облачных вычислений и
SaaS. Облачные вендоры, такие как Amazon, сдают свою инфраструктуру множеству
клиентов на условиях аренды. Эта разделенная инфраструктура создает экономию на
масштабировании и помогает сделать облачные вычисления финансово
привлекательными.
Тем не менее, централизация также имеет и минусы — негативный эффект
умножается, когда из строя выходят централизованные средства обслуживания.
Раньше каждая большая организация поддерживала собственную инфраструктуру, что
сокращало риск вероятности одновременного отключения нескольких компаний в
связи с какой-то одной проблемой. Хотя традиционная инфраструктура довольно
дорога, неэффективна и избыточна, облако создает вероятность большого объема
неполадок, если события пойдут по негативному сценарию.
Тем не менее, для большинства организаций облако и SaaS предлагают множество
экономических преимуществ. В другой своей статье журнал The Economist
пишет:
«Многие компании поняли, что преимущества получения услуг по интернету
перевешивают риски во много раз».
Более мудрые компании понимают риски, появляющиеся вследствие централизации
ключевых компонентов системы, и планируют свою деятельность соответственно.
Аналитик Gartner Лидия Лионг говорит по этому поводу:
Внутри облачной IaaS [Infrastructure as a Service] множество переменных.
Выход из строя любой из них может повлечь за собой отключение всего
сайта/приложения. Ваша реальная проблема это правильное снижение рисков – риск
простоя и связанные с ним потери против сложностей и технических проблем, а так
же стоимостью избыточной инфраструктуры.
3. Облако продолжает расти и развиваться
С точки зрения как бизнеса, так и технологий мир облака меняется, постепенно
развиваясь. Сам Amazon все еще учится лучшему планированию и созданию
надежной системы.
Исполнительный консультант по аутсорсингу Садагопан Синэм говорит:
«Несколько странно видеть, что когда возникла проблема недоступности узлов,
Amazon почти начал попадать в ситуацию атак отказа в обслуживании внутри своей
среды. Сейчас они утверждают, что все исправили, но следует подождать
следующего инцидента, чтобы посмотреть, что еще может произойти.
Нужно отметить, что облачный сервис Amazon уже имел подобный
инцидент в 2008 году – и тогда все произошло по подобной же схеме.
Конечно, системы должны работать по-разному в разных обстоятельствах – для
узлов естественно множить проблемы с доступом к хранилищу данных (while it’s
normal for nodes to keep replicating on storage/access concerns), но система
при этом должна показывать разное поведение с разными причинами кризиса.
Поскольку применение публичного облачного сервиса все увеличивается,
естественно, объем, сложность и диапазон нагрузок также увеличивается. Нужно
тестировать поведение системы в разных обстоятельствах на доступность и
надежность. Все бизнес и ИТ пользователи будут икать ответ на этот вопрос во
время размышления о переносе своей рабочей системы в облака».
4. Уверенность в своих силах и надлежащее планирование являются
решающими факторами
Аутсорсинг не освобождает покупателя услуг от ответственности за судьбу
собственных сервисов. Для облачных сервисов это означает, что предприятие
должно создавать приложения, учитывая их отказоустойчивость для
планирования катастрофоустойчивости и восстановлении системы.
CTO, занимающийся автоматизацией облачных сервисов, Джордж Риз предлагает
концепцию «дизайн для будущего», когда приложения должны иметь степень
свободы от сбоев в работе дата центров:
«Модель спроектированная с учетом возможных сбоев, включающая комбинацию ПО
и инструментов управления, примет на себя ответственность за доступность
приложения. На самом деле доступность инфраструктуры не связана с доступностью
приложения. Стопроцентную доступность следует обеспечивать даже при масштабных
неполадках в дата-центре провайдера облачных сервисов.
Преимущества традиционной модели в том, что любое приложение можно в ней
развернуть и установить уровень избыточности, необходимый для его
функционирования. Минус традиционной модели в том, что она привязана к
расположению предприятия. Она не поможет вам пережить неполадки такого уровня у
вашего провайдера (частного или публичного).
Преимущество модели «дизайна для сбоев» в том, что разработчик приложения
может контролировать доступность данных только благодаря их модели данных
и наложения географических ограничений. Минусы модели «дизайна для сбоев» в
том, что он должен быть спроектирован заранее».
Восстанавливаемость системы становится важной темой, когда происходят
подобные инциденты – в облаке или нет. Многие организации несерьезно относятся
к восстановлению системы и не тестируют ее до того, как случается инцидент.
Технолог –ветеран, Боб Варфилд предлагает внедрить план восстанавливаемости
прямо в облачную среду:
«Компаниям нужен облачный эквивалент удаленного бэкапа. Как минимум вы
должны быть уверены в возможности доступа к копии инфраструктуры – всем AMI и
данным для рестарта. Системы хранения данных дешевеют. Если вы совсем параноик,
переверните все с ног на голову – забэкапьте облако в собственном дата-центре,
который будет состоять только из бэкапа инфраструктуры. По крайней мере, у вас
всегда будут нужные данные под руками. Да, данные не поднимутся да две минуты.
Но посмотрите – сколько времени сервис был недоступен? А представляете, если бы
вы потеряли два часа? Да, это плохо, но если бы у вас был выбор потерять только
два часа или все 24, что бы вы выбрали?»
Это плюсы и минусы, которые нужно принимать во внимание при планировании
катастрофоустойчивости. Обеспечение устойчивости системы требует работы, но,
конечно, можно сложить руки и жаловаться на собственную беспомощность во время
инцидентов.
5. Изучайте успешный опыт
Некоторые клиенты Amazon пережили данный инцидент почти без потерь. Изучите
их урок, он поможет вам лучше подготовиться в следующий раз.
В видео на сайте компании-дистрибутора
Netflix говорится:
«Почему некоторые сайты оказались незатронутым, а какие-то пострадали? Если
кратко, наша система была специально создана для подобных инцидентов. Когда мы
перепроектировали ее для облачного сервиса, сопротивление подобным инцидентам
было как раз то, чего мы хотели достичь. Наша архитектура не использует EBS как
основной сервис хранения данных, а сервисы SimpleDB, S3 и Cassandra, на которые
мы опираемся в нашей работе, не были задеты «зависанием».
Точно также другой сервис – вендор, разрабатывающий системы геолокации
SimpleGeo, оказался не затронут. В своем блоге они
рассказали философию, что лежит в основе архитектуры их компании:
В SimpleGeo такие инциденты – это наша тема. Мы много это обсуждаем и это
влияет на наши операционные процессы. Мы думаем об этом, когда пишем код и
шутим об этом в обед. Это – главное в понимании механизмов отказа системы, и их
обсуждение – первый шаг на пути к работе с ними. Прежде чем мы предлагаем
внедрение нового компонента в нашу инфраструктуру, мы смотрим, как он поведет
себя при сбоях».
Совет CIO
Для многих организаций перенос как минимум некоторых приложений и систем в
SaaS и облака – неизбежен. Вопрос в том, какие приложения перенести и когда,
как провести миграцию и выработать новые навыки внутри предприятия.
Ситуация с Amazon показывает, что миграция в облака – это не предложение
вида «или-или» В данном случае организации, лучше подготовленные к
подобным ситуациям остались работоспособными, а те, кто не подготовился – не
смогли работать. Нельзя переоценить технические знания специалистов. CIO должен
принять решение о том, где компания займет свое место на кривой инвестиции в
облака/ связанные с эти риски . Как в любом бизнесе, вложение в надежность
системы может сократить операционные риски, но и будет стоить дополнительно.
Каждому CIO нужно оценить собственную организацию, чтобы понять оправданность
вложений в техническое развитие и уровень рисков.
Источник: www.zdnet.com
