Работа приложений в облаке. Надёжность и доступность.

Идея написания этой статьи пришла после общения с одним из крупных заказчиков — коллега поведал историю выбора для своей компании провайдера облачных услуг IaaS.

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

Владимир Курилов, компания «Онланта».

Так разговор дошёл до показателей надёжности. И вёлся он вокруг сравнения уровней доступности ЦОДов, в которых располагались облака. Достаточно быстро выяснилось, что только двое кандидатов располагают ЦОДами с уровнем доступности 99,98%. Выбор был сделан в пользу зарубежного провайдера облачных услуг — победила цена. Коллега объяснил всё просто, — «Какой смысл платить больше за те же самые показатели надёжности?»

Учитывая существование различных вариантов, давайте определимся с трактованием термина «Доступность» в рамках данной статьи. Определим доступность как время работоспособности системы в определённом интервале времени, выраженное в процентах к этому интервалу. Или в классическом виде: «Свойство объекта выполнять требуемую функцию при заданных условиях в течение заданного интервала времени». Что, в общем, ближе к уже достаточно устоявшемуся понятию «Готовность» системы.

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

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

Ответы на эти вопросы я и попробую сформулировать далее.

Надёжность приложения — из чего она складывается в облаке

Надёжность сервиса приложения

Если попробовать сформулировать определение надёжности работы приложения, то оно будет звучать так: «Надёжность — это свойство приложения сохранять во времени работоспособность со всей функциональностью в него заложенной».

От чего зависит работоспособность приложения и, как надёжность приложения связана с доступностью ЦОДа?

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

Рис. Упрощённый пример расчёта доступности Сервиса Приложения

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

Доступность такой системы (As) определяется как произведение показателей доступности всех элементов:

Где: A_s – Суммарная доступность, доступность всей системы,
A_i – доступность каждого последовательно соединённого компонента.
A_s = 0,99995 0,99995 0,993 0998 ≈ 0,99091 или 99,091

Как видим, доступность Сервиса Приложения имеет значение, далёкое от доступности инженерной платформы ЦОДа. Можно пересчитать цифры доступности в значения простоя системы. Получается, несмотря на допустимый годовой простой инженерной платформы, в 1 час. 45 мин., для сервиса приложения годовой простой составит 86 ч. 22 мин.

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

Надёжность сетевого приложения

Следовательно, при выборе сервис-провайдеров правильно было бы ориентироваться на совокупную доступность сервисов приложений? К сожалению, тут не всё так просто.

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

Один из вариантов реализации применения специализированных библиотек компанией Microsoft — Transient Fault Handling Application Block (см. http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx).

Надёжность программной платформы

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

Я говорю о «гигиенических» средствах безопасности. В первую очередь, о сервисе обновления системного программного обеспечения. Он должен быть в портфеле услуг сервис-провайдера, а ещё лучше — учтён в цене услуги «по умолчанию». Во вторую очередь, это сервис антивирусной защиты с возможностью выбора антивирусных программ. И, в третьих, резервное копирование виртуальных серверов заказчика. Это не всё, но самые важные способы, позволяющие повысить доступность вашего Сервиса Приложения.

Надёжность инфраструктурной платформы

Эта составляющая надёжности полностью зависит от сервис-провайдера и должна оцениваться Вами наравне с доступностью инженерной платформы ЦОДа. Необходимо запросить этот параметр у провайдера, поскольку как правило он не указывается в маркетинговых материалах. При этом необходимо получить разъяснения — как этот параметр рассчитывался.

Хотя надо иметь в виду, что такие данные не все сервис-провайдеры захотят представить, поскольку из расчёта становится понятна структурная схема инфраструктурного решения и используемое оборудование — а это определённое ноу-хау.

Тем не менее:

Теперь у Вас есть возможность максимально достоверно определить доступность Вашего сервиса приложения. 90% СП в России, исходя из нашего опыта, имеют суммарную доступность не выше 99%. А это риск простоев до 87 часов в год. Это нормальные показатели доступности, если у Вас нет критических для бизнеса приложений, часовой простой которых приносит Вам миллионные убытки. А если часовая остановка сродни катастрофе для Вашего бизнеса, то для Вас есть оставшиеся 10%, СП, предоставляющие сервис корпоративного уровня с доступностью Сервиса приложения на уровне 99,99%. О том, какими способами это достигается в следующем разделе.

Решения, обеспечивающие высокую доступность сервиса приложения

Заказчику в итоге неважно как соблюдается SLA по инженерным системам, ему важно какова доступность сервиса его приложений, т.е. — гарантированное время восстановления работоспособности приложения.

Системы, которые мы ранее обсуждали, имели последовательную структуру. Доступность, которую мы посчитали выше как произведение отдельных элементов — это технический предел, обеспечиваемый подобными системами. На деле в силу появления различных дополнительных факторов доступность ещё ниже. Помните вначале статьи рассказ про секундное отключение электричества и пять часов простоя?

Есть ли возможность повысить доступность приложения, если параметры доступности конкретного ЦОДа заданы и изменить их нельзя?

Ответ — можно.

Вот, например, два подхода, которые позволяют это сделать:

Рис. Структурная схема географически распределённого кластера высокой доступности

Рис. Структурная схема для восстановления обработки в географически удалённом резервном центре обработки данных

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

В обоих случаях необходимо говорить о географической удалённости ЦОДов, чтобы максимально избежать возможности взаимосвязанных ресурсов. Например, использования одних и тех же подстанций, обеспечивающих электропитание ЦОДов. Можно вспомнить отключение электричества на юго-востоке г. Москва в мае 2008 года из-за пожара на Чагинской подстанции, New York 2003 год. Поэтому резервный ЦОД должен располагаться подальше от основного.

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

Принципиальное отличие параллельной системы в том, что надёжность растёт с увеличением параллельных элементов системы. Расчёт доступности системы, состоящей из параллельных элементов, можно производить по формуле:

Где: A_s – Суммарная доступность, доступность всей системы,
A_i – доступность каждого параллельно соединённого компонента.

Для примера, рассчитаем систему географически распределённого кластера высокой доступности из двух ЦОДов с доступностью = 99%, каждый.

A_s = 1-(1-0,99)*(1-0,99)= 0,9999 или 99,99

Т.е., два не самых надёжных ЦОДа могут обеспечить доступность на уровне mission-critical систем.

Определить доступность сервиса приложения в варианте восстановления обработки в географически удалённом резервном центре обработки данных с 15 минутным интервалом синхронизации для случая единичного сбоя рассчитывается так: надо запросить время восстановления сервиса приложения, гарантируемое СП; далее считаем процент от годового интервала — и результат вычитаем из единицы. Получаем доступность после первого сбоя. Например, для системы с 15 минутным интервалом синхронизации:

Общее количество часов в году 365*24=8760
Гарантированное время простоя = Время максимального простоя
15 минут или 0,25 часа, что составляет ≈ 0,003 от годового времени

Т.е. каждый сбой будет иметь вес в 0,003%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,997%, после второго сбоя 99,994%. Посчитаем тоже самое для системы с часовым интервалом синхронизации:

Гарантированное время восстановления = Время максимального простоя = 1 час, что составляет ≈ 0,01 от годового времени

Каждый сбой будет иметь вес в 0,01%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,99%, после второго сбоя 99,98%. Дальше, приверженцы теории вероятности могут поупражняться в оценке вероятности наступления первого, второго, третьего сбоев. Результат убедит, что влияние этого фактора ничтожно мало на получаемые результаты. Это позволяет мне рекомендовать предложенную методику для оценки доступности сервисов для Ваших приложений в облаке.

Резюмируя вышесказанное...

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

Ссылка на источник www.computerra.ru/cio/2485