Ожидаемая доступность в облачной среде

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

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

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

± балансировщик нагрузки: 99,999 %

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

± сервер приложений:

(8760 – ((30 % × (242)) / 8760)) / 8760 = 99,999 %;

± сервер базы данных:

(8760 – (24 × 30 %)) / 8760 = 99,92 %;

± система в целом:

(8760  –  ((24 × 30 %)  +  (24 × (((30 % × (242)) / 8760))  +  (24 × 30 %))) / 8760  =

= 99,84 %.

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

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

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

ЧТО В ДЕЙСТВИТЕЛЬНОСТИ ОЗНАЧАЮТ ЭТИ ЦИФРЫ?

Рассудительные пользователи могут не согласиться с цифрами, приведенными мною в этой главе, и обязательно это сделают. Цель приведенных примеров вычислений не заключается в заявлении, что традиционный центр обработки данных обеспечит для описываемой архитектуры доступность 99,84 %, а облачная среда — 99,994 %. Если вы, прочитав этот раздел, запомните эти цифры и будете повсюду повторять, что такую вещь сказал вам я, то знайте, что вы меня неправильно поняли!

А в чем тогда цель приведенных вычислений? Просто в том, чтобы вы поняли сам подход к обеспечению уровня доступности и поняли, насколько понятие стабильности в облачной среде отличается от понятия стабильности в физической инфраструктуре. Вот эти отличия:

    экземпляры EC2 намного менее стабильны, чем физические серверы;

    использование нескольких зон доступности может существенно смягчить проблему стабильности экземпляров EC2;

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

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

± балансировщик нагрузки:

(8760 – (0,17 × 80 %)) / 8760 = 99,998 %;

± сервер приложений:

(8760 – (17 % × (0,172 / 8760))) / 8760 = 99,9999 %;

± сервер базы данных:

(8760 – (0,5 × 80 %)) / 8760 = 99,995 %;

± система в целом:

(8760 – ((0,17 × 80 %) + (17 %×(0,172 / 8760)) + (0,5 × 80 %))) / 8760 = 99,994 %.

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

1 Я не учитываю влияние потери отдельного узла на производительность и основное внимание уделяю именно доступности. Если ваши избыточные серверы приложений работают на полную мощность, то потеря одного из них может привести к снижению производительности или даже потере доступности.

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100