Из чего складывается доступность?

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

± Какие функциональные возможности должны быть доступны потребителю, чтобы ваша система воспринималась как доступная? Например, ранее в этой главе мы рассматривали пример с поисковой системой Google — до тех пор, пока пользователи могут выполнять поиск и получать результаты, Google можно считать доступным, вне зависимости от того, каков на данный момент статус поискового робота Google (Google spider).

± Следует ли вам включить в анализ периоды планового простоя? Включение планового простоя в чем-то противоречиво, но оно может вам потребоваться для некоторых видов управления доступностью. Например, возможна такая ситуация, когда архитектура вашей системы позволяет вам обеспечить доступность 99,999 %, но вы, тем не менее, предпочитаете запланировать для своей системы 1 час простоя в неделю для проведения плановых профилактических работ (вследствие повышенных требований к безопасности или любого другого критерия, который не имеет отношения к теоретической оценке доступности системы как таковой). Если вы производите оценку для внутренних целей, вы можете считать, что оценка 99,999 % объективна. Но если вы пытаетесь рекламировать систему для конечных пользователей и сообщаете им, какого уровня доступности им следует ожидать, то оценка 99,999 % введет их в заблуждение.

± В течение какого процента времени ваша среда должна быть доступна? Например, для Web-сайта можно задать требование, в соответствии с которым доступность его домашней и всех дочерних страниц из-за пределов корпоративной сети должна составлять 99,999 % ежедневно от 07:00 до 21:00.

Доступность облачных сервисов

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

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

Например, экземпляр EC2 считается абсолютно ненадежным по сравнению с ожидаемой доступностью обычного сервера с избыточными компонентами. Такие события, как утрата физического сервера без всяких предупреждений, случаются крайне редко. Напротив, когда один из компонентов отказывает (или выдает предупреждение о высокой вероятности отказа), он замещается избыточным компонентом, что позволяет вам избежать простоя системы. Во многих облачных системах, например Rackspace и GoGrid, вы также можете ожидать аналогичных уровней надежности. Но вот в облаке Amazon ваши экземпляры периодически будут отказывать без всяких предупреждений, и это можно утверждать с полной стопроцентной гарантией.

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

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 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