Создание политики отказоустойчивости облака

Политика обеспечения отказоустойчивости с особыми "облачными" условиями, детализирующими компоненты и задачи

В ближайшие годы большинство организаций и учреждений перенесет часть своих данных в облако или же будет находиться в процессе такого перехода или планирования того или иного вида использования облаков — при этом двумя главными проблемами будут оставаться надежность и безопасность. Что касается надежности, то организациям по-прежнему требуется обеспечить время безотказной работы минимум в 99,5%. К сожалению, в аварийной ситуации многие организации все еще используют «реактивный» подход, вместо того, чтобы предпринимать более разумные превентивные шаги: создать политику отказоустойчивости облака с особыми условиями, в которых детализируются компоненты и задачи. Автор предлагает план такой политики и иллюстрирует особые условия и сценарии профилактических мер, которые нужно принять в случае отказа.

Джудит Майерсон, инженер, разработчик архитектуры систем, консультант

Джудит М. Майерсон (Judith M. Myerson) - разработчик архитектуры систем, инженер, писатель. В сферу ее интересов входят технологии промежуточного программного обеспечения, системы масштаба предприятия, технологии баз данных, разработка приложений, управление сетями, распределенные системы, технологии на основе компонентов и управление проектами. С ней можно связаться по электронной почте: jmyerson@bellatlantic.net



09.11.2012

Цель политики отказоустойчивости облака — обеспечить, по крайней мере, 99,5%-е время непрерывной работы облачного сервиса. Она должна быть направлена на то, чтобы перенести виртуальные машины, решающие в облачной среде задачи типа "приложение как сервис" (SaaS), "платформа как сервис" (PaaS) или "инфраструктура как сервис" (IaaS), из отказавшего ЦОД в действующий, обеспечив почти бесперебойное обслуживание клиентов облака.

Пользователям облака нужно избежать катастрофических отказов облачной службы, таких как сбой сети, который, по крайней мере, дважды выводил из строя региональную службу Amazon в США (Северная Вирджиния):

  • в 2007 году пострадал сервис Amazon Elastic Compute Cloud (EC2);
  • а в 2011 году были поражены решение PaaS Amazon Cloud Computing, EC2 и сервис реляционных баз данных.

При этом другие два региональных ЦОД Amazon в США продолжали функционировать нормально.

В регионе Северной Виржинии тома хранения данных, которые использует сервис Amazon EC2, автоматически создавали свои резервные копии, заполняя емкость системы хранения данных. Когда эти автоматические резервные копии превысили максимальный предел емкости системы, она встала. Просто не осталось места для новых копий.

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

Особые условия для SaaS

Ниже приведены примеры компонентов и задач, которые следует включить в особые условия политики обеспечения отказоустойчивости облака, относящиеся к SaaS.

Компоненты

Ввиду ограниченного контроля, которым обладает пользователь SaaS, особые условия для SaaS содержат как минимум три компонента:

  • средства правления пользователей;
  • пользовательская лицензия;
  • план отработки отказа.

Единственное средство управления, которое имеется в распоряжении пользователя SaaS, это доступ к SaaS-приложениям с целью выполнения бизнес-функций. Компонент пользовательской лицензии, согласованный с поставщиком, должен указывать максимальное количество:

  • доступных SaaS-приложений;
  • пользователей, одновременно работающих с приложением;
  • запросов, выделенных каждому пользователю.

Компонент пользовательской лицензии должен определять типы SaaS-приложений, к которым пользователь может обращаться, такие как финансовые приложения, система управления проектами, система взаимоотношений с клиентами, система управления розничной торговлей и даже сканер уязвимостей на базе IBM Rational AppScan.

Компонент плана отработки отказа должен устанавливать количество экземпляров SaaS-приложения, которым разрешено переходить из одного ЦОД в другой. Следует указать поставщика услуг резервного копирования и соглашения об уровне обслуживания (SLA) с соблюдением законов о конфиденциальности, таких как Федеральный закон о конфиденциальности и Закон об электронных документах.

Задачи

У пользователей SaaS как минимум должна быть возможность:

  • обращаться к SaaS-приложению в пределах максимально допустимого числа обращений на пользователя;
  • редактировать записи в зависимости от роли, назначенной пользователю;
  • получать предупреждения системы безопасности.

Поставщик может:

  • приобретать лицензию на обновление программного обеспечения;
  • управлять исправлениями для SaaS-приложений;
  • обращаться к системным приложениям и виртуальным машинам;
  • обращаться к традиционной вычислительной инфраструктуре, на которой установлены виртуальные машины.

Когда происходит сбой SaaS-приложения, поставщик должен указать, каким образом его можно в кратчайшие сроки (не более пяти минут) перенести из отказавшего ЦОД в действующий, а затем, когда проблема будет решена, восстановить на прежнем месте.

Для иллюстрации рассмотрим сценарий отказа SaaS.


Сценарий отказа SaaS

Локальные приложения CRM компании были успешно перенесены как SaaS-приложения в мультитенантную среду внешнего поставщика, региональный ЦОД которого находится в США. Когда сбой сети одного из ЦОД вывел систему из строя на пару дней — из-за того, что система автоматической архивации данных заполнила всю емкость и оставила сеть без места для хранения 200 млн транзакций во всем мире, — нахлынул вал жалоб (как и следовало ожидать):

  • продавцы взвыли;
  • телефоны в call-центрах раскалились;
  • поставщик стонал (когда обнаружилось, что он не может вернуть SaaS-приложение CRM к работе в течение двух минут после аварии, как прописано в SLA, заключенном с пользователями SaaS).

Лихорадочно придумывая быстрое решение, поставщик вывесил на своем Web-сайте объявление: «подождите, пожалуйста... мы скоро запустим систему». Скоро не получилось.

Чтобы SaaS-приложение заработало, поставщику потребовалось два дня. Он не смог обеспечить эффективный переход на резервный ресурс. Ниже приведены профилактические меры, которые мог принять этот поставщик, чтобы ограничить ущерб, решить проблемы, восстановить систему и уведомить клиентов.

Ограничение ущерба

Чтобы ограничить ущерб, запланируйте подготовку SaaS-приложений в виде экземпляров для автоматического переноса на другой ресурс. Должно иметь место SLA, согласованное между абонентом SaaS и поставщиком. Когда производительность падает значительно ниже гарантированного уровня готовности сервиса (99,9%), поставщик должен получать уведомление. Упавшую производительность можно почти немедленно вернуть к гарантированному уровню в зависимости от трафика в сети.

Тем временем клиенты SaaS получают уведомление о том, что пока поставщик решает проблемы, сервис продолжает работать в другом ЦОД. Он даст им знать, как только сервис будет восстановлен в первоначальном ЦОД.

(Обратите внимание, что во всех превентивных мерах этой политики присутствует важный элемент уведомления: когда заинтересованные стороны знают, что происходит, это оставляет вам больше времени на решение проблемы; сокрытие от клиента истинной ситуации всегда работает против вас).

Решение проблемы

Поставщик может заранее спланировать переход и подготовить политику отказоустойчивости в облаке:

  • установить экземпляры SaaS-приложения, чтобы обеспечить возможность перехода из одного ЦОД в другой;
  • периодически проверять, правильно ли работают НМЛ резервного копирования и нет ли в них дефектов;
  • проверить, может ли сетевое программное обеспечение решить эту задачу должным образом.

Восстановление системы

Следующий шаг ― приступить к восстановлению системы в исходном ЦОД. Поставщик устанавливает среду тестирования для проверки устойчивости восстановленной системы, чтобы гарантировать относительно гладкий переход из другого ЦОД. Например, поставщик произвольно "убивает" ресурсы и сервисы, фиксируя результаты.

По завершении тестирования поставщик создает резервную копию восстановленной системы, прежде чем переместить ее в производственную среду.

Уведомление клиентов

Как только SaaS-приложения восстановлены в исходном ЦОД, поставщик уведомляет своих клиентов, что восстановление завершено и условия SLA (бесплатный кредит, компенсации, возможность прекращения договора) будут выполнены.


Особые условия для PaaS

Какие компоненты и задачи должны быть прописаны в особых условиях для PaaS, чтобы обеспечить политику отказоустойчивости в облаке?

Компоненты

У разработчиков PaaS больше средств контроля, так что особые условия для PaaS должны содержать как минимум на один компонент больше, чем для SaaS — возможность разработки приложений (компоненты для разработчика PaaS – это средства управления пользователя, лицензия разработчика, разработка приложений (которая недоступна пользователям SaaS) и план перехода на другой ресурс).

Разработчик PaaS управляет разработкой SaaS-приложений и всеми приложениями, которые встречаются на протяжении всего жизненного цикла предприятия, такими как электронные таблицы, текстовые процессоры и системы резервного копирования.

Компонент лицензии разработчика, согласованный с поставщиком, должен определять максимальное количество:

  • разрабатываемых приложений;
  • приложений, которые разрешено разрабатывать одновременно;
  • пользователей SaaS, которые могут обращаются к приложению на PaaS.

Компонент разработки приложения должен определять типы разрабатываемых приложений:

  • SaaS-приложения;
  • Web-сайты;
  • CRM-приложения;
  • мобильные приложения;
  • приложения для выставления счетов и начисления заработной платы;
  • приложения для доставки услуг (такие как мобильное ТВ);
  • приложения для управления доставкой контента.

Компонент плана отработки отказа должен указывать количество экземпляров PaaS-приложений, которые разрешено переносить из одного хостируемого центра в другой. Этот компонент должен определять, должен ли разработчик PaaS использовать свое собственное приложение для отработки отказов или приложение поставщика, и может ли он использовать сторонние инструменты для решения таких задач, как выравнивание нагрузки. План должен также определять, предлагает ли поставщик резервное копирование сервисов и SLA и соблюдает ли он законы о конфиденциальности данных.

Задачи

Разработчикам PaaS разрешается:

  • создавать, развертывать и исполнять приложения;
  • управлять исправлениями и обновлениями;
  • определять, какие пользователи SaaS могут получать доступ к SaaS-приложениям, сосуществующим на PaaS;
  • гибко настраивать свою платформу в соответствии условиями местного рынка.

Они также могут:

  • проверять приложения на наличие уязвимостей;
  • настраивать межсетевые экраны приложений;
  • создавать и контролировать оповещения системы безопасности;
  • выполнять операции резервного копирования.

Только поставщик может как минимум:

  • исполнять системные приложения;
  • создавать виртуальные машины;
  • обращаться к традиционной вычислительной инфраструктуре, на которой установлены виртуальные машины.

Для иллюстрации рассмотрим сценарий отказа PaaS.


Сценарий отказа PaaS

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

Ниже описаны профилактические меры, которые поставщик может предпринять, согласовав с поставщиком особые требования по PaaS об ограничении ущерба, решении проблем, восстановлении системы и уведомлении клиентов.

Ограничение ущерба

Чтобы ограничить ущерб, разработчик PaaS, вместо нескольких зависимых хостов, создает простые сервисы, состоящие из одного хоста. Это позволяет ему создавать реплицированные экземпляры служб, способные выдержать сбои хоста.

Решение проблемы

В случае сбоя программное обеспечение должно быстро выявить его и начать процесс отработки.

Предположим, что у разработчика есть приложение биллинга, состоящее из компонентов бизнес-логики ... A, B, C… и он может составить следующую группу услуг:

(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)

где n — номер типа компонентов, соответствующий номеру категории группы услуг.

        Для услуг категории 1: 
                А1 - это логика поиска кода услуг;
                B1 - логика внесения категории услуг в счет;
                C1 - логика проверки правильности почтовых индексов.

        Для услуг категории 2: 
                A2 - это логика поиска кода услуг;
                B2 - логика внесения категории услуг в счет;
                C2- логика проверки правильности почтовых индексов.

        Для услуг категории n: 
                An - это логика поиска кода услуг;
                Bn - логика внесения категории услуг в счет;
                Cn - логика проверки правильности почтовых индексов.

Отказ виртуальной машины, исполняющей PaaS, приводит к потере всей группы систем. Это означает, что если в одной группе систем отказал компонент A1, то откажут и два других компонента,B1 и C1. При наличии нескольких групп сервисов отказывает вся система.

Чтобы решить эту проблему, разработчик разлагает компоненты на независимые пулы:

(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn)

Это позволяет создавать резервные копии сервисов в действующих ЦОД. Тогда, если компонент A1 откажет или замедлит работу, это не отразится на остальных компонентах A2... An в том же независимом пуле. Второй независимый пул компонентов B1, B2...Bn и третий пул компонентов C1, C2, ...Cn продолжают работать.

Пока происходит перенос всех пулов сервисов приложения биллинга, разработчик использует короткие паузы и восстанавливает медленные сервисы. Разработчику нужно определить, когда выполнять останов и восстановление, чтобы избежать зависания системы из-за потребления всех ресурсов в ожидании медленного или отказавшего сервиса.

Восстановление системы

Следующий шаг ― приступить к восстановлению платформы PaaS в первоначальном ЦОД, где произошел отказ. В среде тестирования поставщик случайным образом останавливает ресурсы и сервисы, поверх которых работает PaaS. Разработчик проверяет приложения при различных условиях для тестирования устойчивости PaaS. По завершении тестирования поставщик создает резервную копию восстановленной системы, прежде чем переместить ее в производственную среду.

Уведомление клиентов

Как только PaaS-приложения заработали в восстановленном ЦОД, поставщик уведомляет разработчиков PaaS о восстановлении системы и выполнении условий SLA.


Особые требования для IaaS

Наконец, какие компоненты и задачи должны быть включены особые требования политики отказоустойчивости в облаке для IaaS?

Компоненты

Поскольку IaaS служит основой уровня PaaS, особые требования для IaaS должны содержать другой набор компонентов. Кроме средств управления пользователя, корпоративной лицензии и плана перехода на резервный ресурс, нужен компонент для виртуальных машин.

Специалист по IaaS управляет виртуальными машинами; разработчики PaaS и пользователи SaaS ― нет.

В корпоративной лицензии должно быть указано максимальное количество:

  • виртуальных машин для целей разработки, исполнения и поддержки;
  • специалистов по IaaS, имеющих одновременный доступ к виртуальным машинам;
  • разработчиков PaaS, работающих с виртуальными машинами IaaS.

План перехода на резервный ресурс должен обеспечить перевод виртуальных машин IaaS из одного центра хостинга в другой. Он должен позволять специалистам по инфраструктуре IaaS и сети сотрудничать с разработчиками PaaS над организацией перевода виртуальных машин.

Задачи

Специалист по IaaS может:

  • осуществлять разработку, управление и доступ к виртуальным машинам;
  • разрешать разработчикам PaaS создавать приложения на виртуальных машинах;
  • использовать сторонние инструменты для повышения производительности (например, балансировщик нагрузки) и защиты данных системы;
  • проверять виртуальные машины на уязвимость.

Этим специалистам также разрешено:

  • настраивать межсетевые экраны виртуальных машин;
  • создавать и контролировать оповещения системы безопасности;
  • создавать резервные копии виртуальных машин.

Доступ к традиционной инфраструктуре вычислительных ресурсов, на которой создаются виртуальные машины, есть только у поставщика. У специалиста по IaaS его нет.

Для иллюстрации рассмотрим сценарий отказа IaaS.


Сценарий отказа IaaS

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

Поставщик может принять следующие профилактические меры.

Ограничение ущерба

Чтобы ограничить ущерб, спланируйте, сколько необходимо ресурсов для запуска виртуальных машин в точках высокой интенсивности ввода-вывода. Это можно сделать, например, с помощью планирования емкости и политики определения порога производительности. (Вопросы политики ограничения и планирования емкости рассматриваются в других, более подробных статьях, указанных в разделе Ресурсы).

Решение проблемы

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

А также запланируйте быстрое выявление отказа и перевод поставщиком экземпляров виртуальных машин на основе IaaS в другой ЦОД.

Восстановление системы

Следующий шаг ― приступить к восстановлению платформы IaaS в первоначальном ЦОД, где произошел отказ. В среде тестирования поставщик может случайным образом останавливать ресурсы и сервисы, поверх которых работает IaaS. По завершении тестирования поставщик создает резервную копию восстановленной системы, а затем переносит ее в производственную среду.

Уведомите клиентов

Как только виртуальные машины в восстановленном ЦОД заработали, поставщик уведомляет специалистов по IaaS о полном восстановлении виртуальных машин в центре обработки данных.


Заключение

Анатомия эффективной политики обеспечения отказоустойчивости облака требует превентивного планирования:

  • для определения причины отказа облака;
  • выявления таких отказов;
  • внесения в политику особых условий, связанных с облаком, с целью превентивного противодействия причинам этих отказов.

Политику и особые условия должна совместно составить группа разработчиков, пользователей и поставщиков. Ответив на вопросы о том, какие элементы, компоненты и задачи следует включать, эта группа значительно упростит себе задачу по разработке политики.

В этой статье описаны основные компоненты и задачи, которые следует рассмотреть в рамках политики отработки отказов для каждой модели облачных вычислений — SaaS, PaaS и IaaS. Для каждой модели предложены методы, которые поставщик может применять для ограничения ущерба, решения проблемы, восстановления системы и, конечно, уведомления клиентов.

Другие статьи (см. раздел "Ресурсы") углубляются в определение элементов политики ― цели, области применения, контекст, мероприятия и ограничения, ― которые помогут создать политику облачных вычислений для работы с триггерами порогов, выравнивания нагрузки, обеспечения общей безопасности, организации мобильного доступа, миграции приложений, управления рисками, измерения производительности и многого другого. В всех инструкциях по созданию политики, которые я предлагаю, в качестве ключевых факторов, на которые опираются остальные компоненты, всегда фигурируют надежность и безопасность.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, SOA и web-сервисы
ArticleID=845120
ArticleTitle=Создание политики отказоустойчивости облака
publish-date=11092012