Географическая избыточность в облачных сервисах

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

Теперь перейдем к обсуждению целевого времени восстановления (Recovery Time Objective, RTO), показателя, для обеспечения которого ключевую роль играет избыточность инфраструктуры. Если вы можете обеспечить географическую избыточность, то вы сможете пережить почти любую катастрофу, которая может случиться. Для физической инфраструктуры обеспечение географической избыточности обходится очень дорого. В отличие от этой ситуации, в облачной среде эта мера относительно дешева.

Вам нет необходимости обеспечивать активную работу вашего приложения во всех географических точках, но вы должны иметь возможность быстро развернуть ваше приложение с резервной копии, соответствующей вашим требованиям к показателю  целевой  точки  восстановления  (RPO)  в  дополнительном  подразделении, соблюдая временные рамки, устанавливаемые вашим показателем целевого времени восстановления (Recovery Time Objective, RTO). Например, представьте себе, что ваш показатель RTO составляет 2 часа, а RPO — 24 часа. В этом случае географическая избыточность подразумевает, что у вас имеется замещающий "филиал", в котором вы через 2 часа восстановите свою рабочую среду с резервной копии, "возраст" которой составляет не более 24 часов. При этом вы потеряете только те данные, которые были наработаны за прошедшие с момента катастрофы 24 часа. Amazon предоставляет встроенную географическую избыточность за счет регионов (regions) и зон доступности (availability zones). Если ваши экземпляры работают в одной зоне доступности, вы сможете без особых усилий заново запустить их в другой зоне доступности того же самого региона. Если вы обязаны соблюдать специфические требования, касающиеся географической избыточности1, то зоны доступности, предоставляемые Amazon, могут оказаться недостаточной мерой. В этом случае вам потребуется пересекать границы регионов.

1 Некоторые правительственные агентства и другие специфические организации требуют, чтобы замещающие инфраструктуры отстояли не менее чем на 50 миль от основной.

Пересечение границ зон доступности

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

На рис. 6.1 представлена производственная среда, которая с легкостью переживет потерю целой зоны доступности.

Рис. 6.1. Географическую избыточность в облачной среде можно обеспечить за счет пересечения границ зон доступности

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

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

Соглашение об уровне обслуживания Amazon (Amazon SLA) гарантирует доступность на уровне 99,95 % как минимум для двух зон доступности в пределах каждого региона. Если вы можете себе позволить пересекать границы нескольких зон доступности, вы можете даже превысить этот уровень для тех регионов, в которых существует более двух зон доступности. Например, на восточном побережье США есть три зоны доступности1. В результате вероятность полного отказа при использовании двух зон доступности составляет только 33 %.

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

Пересечение границ регионов

На тот момент, когда я начинал написание этой главы, компания Amazon поддерживала два региона2: us-east-1 (восточное побережье США) и eu-west-1 (Западная Европа). Эти регионы не разделяют никакой осмысленной инфраструктуры. Преимущество этой структуры заключается в том, что если вы можете себе позволить пересекать границы регионов, то ваше приложение фактически может пережить даже ядерную атаку на США, Евросоюз или Азиатско-Тихоокеанский регион (но не все регионы!). С другой стороны, отсутствие общей инфраструктуры усложняет задачу репликации вашей производственной среды через границы регионов.

1 В Европейском регионе имеются две зоны доступности. Как результат, в этом регионе вам гарантируется доступность на уровне 99,95 %.

2  На момент подготовки русского издания Amazon поддерживает уже четыре региона: US East (Северная Вирджиния), US West (Северная Калифорния), EU (Ирландия) и Asia Pacific (Сингапур), см.

http://aws.amazon.com/ec2/. — Прим. перев.

В каждом регионе EC2 имеется ассоциированный регион Amazon S3. При этом вы не можете запускать экземпляры EC2 в ЕС, используя AMI из США, и не можете использовать в США IP-адреса, которые ранее были ассоциированы с балансировщиком нагрузки из Евросоюза.

ПРИМЕЧАНИЕ

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

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

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

± Управление DNS. Чтобы обойти тот факт, что перенос IP-адресов через границы регионов невозможен, вы можете использовать круговую систему DNS (round- robin DNS)1, но в конечном итоге вы придете к тому, что будете посылать посетителей из Европы в США и, соответственно, наоборот (крайне неэффективный подход к управлению сетевым трафиком) и потеряете половину вашего трафика, когда окажется потерянным один из регионов. Лучше применить динамическую систему DNS, например такую, как UltraDNS (http://www.ultradns.com/), которая предложит вам правильное разрешение имен DNS на основании источника и доступности.

1 Круговая система DNS (Round-robin DNS) — это один из методов распределения нагрузки и обеспечения отказоустойчивости за счет избыточности количества серверов с помощью управления ответами DNS-сервера. Обычно применяется к Web-серверам, FTP-серверам и т. п. В простейшем случае круговая система DNS (Round robin DNS) работает, отвечая на запросы не одним IP-адресом, а списком из нескольких адресов серверов, предоставляющих идентичный сервис. Порядок, в котором возвращаются IP-адреса из списка, основан на алгоритме кругового  обслуживания  (round-robin algorithm). С каждым ответом последовательность IP-адресов меняется. Как правило, простые клиенты пытаются устанавливать соединения с первым адресом из списка, таким образом разным клиентам будут выданы адреса разных серверов, что распределит общую нагрузку между серверами. Например, на DNS-сервере создается несколько записей типа Host(A) c одинаковым именем (например, terminal.domain.local) и разными IP-адресами. Устанавливая соединение, клиенты обращаются к terminal.domain.local, а DNS-сервер на первый запрос выдает IP-адрес первого сервера, на второй — второго и так далее по кругу.

Подробнее см. https://secure.wikimedia.org/wikipedia/en/wiki/Round_robin_DNS, http://www.wisegeek.com/what-is-round-robin-dns.htm. — Прим. перев.

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

± Вопросы нормативно-правового регулирования.  Законодательство Евросоюза не разрешает хранить данные определенных типов за пределами Евросоюза. В результате этого законодательные ограничения могут помешать вам пересекать границы регионов, какие бы грамотные технические решения вы бы ни предлагали. В реальности подход к избыточности за счет использования комбинации облачных провайдеров например Amazon+GoGrid, или Amazon+Rackspace, может оказаться более эффективным, чем использование услуг только Amazon с пересечением границ регионов.

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

Организационная избыточность

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

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

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

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

ВНИМАНИЕ!

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

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

± Хранение переносимых (portable) резервных копий на хостинге другого облачного провайдера.

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

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

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

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