Варианты построения высокодоступных систем в AWS. Преодоление перебоев в работе. Часть 2

В этой части будут рассмотрены следующие варианты построения высокодоступных систем на базе AWS:

• Построение высокодоступной системы между зонами доступности AWS
• Построение высокодоступной системы между регионами AWS
• Построение высокодоступной системы между различными облачными и хостинг ^[1] провайдерами

Первая часть здесь ^[2].

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

Большинство высокоуровневых сервисов Amazon, такие как Amazon Simple Storage Service (S3), Amazon SimpleDB, Amazon Simple Queue Service (SQS), and Amazon Elastic Load Balancing (ELB) имеют встроенные механизмы для обеспечениея отказоусточивости и высокой доступности. Сервисы, относящиеся к базовой инфраструктуре, например, Amazon Simple Storage Service (S3), Amazon SimpleDB, Amazon Simple Queue Service (SQS), and Amazon Elastic Load Balancing (ELB), предоставляют такие возможности как Elastic IP, снимки образов и зоны доступности. Каждая отказоустойчивая и высокодоступная система обязана использовать эти возможности и использовать их правильно. Для того, чтобы система была надежной и доступной недостаточно просто развернуть ее в облаке AWS, ее нужно спроектировать так, чтобы приложение работало в нескольких зонах доступности. Зоны доступности находятся в различных географических областях, поэтому использование нескольких зон может обезопасить приложение от проблем в конкретной области. Следующая диаграмма показывает различные уровни (с примерами программного обеспечения), которые должны быть спроектированы с использованием нескольких зон доступности.

Для того, чтобы в случае неработоспобности одной зоны приложение продолжало работать без сбоев и потери данных в другой зоне, важно иметь независимые друг от друга программные стеки приложения в разных зонах (как в пределах одного региона так и в в разных регионах). На этапе проектирования системы нужно хорошо понимать какие части приложения привязаны к зоне.
Пример:
Типичное Web приложение состоит из таких уровней, как DNS, Load Balancer, Web сервер, сервер приложения, кеш, база данных. Все эти уровни могут быть распределены и развернуты в двух и более зонах доступонсти, так как описано ниже.

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

Проектирование высокодоступной системы используя встроенные блоки AWS:

• Amazon S3 для хранилище обьектов и файлов
• Amazon CloudFront для система доставки контента
• Amazon ELB для балансировки нагрузки
• Amazon AutoScaling для автоматического масштабирования EC2
• Amazon CloudWatch для мониторинга
• Amazon SNS и SQS для сервиса сообщений

Эти блоки могут использоваться, как Web сервисы. Эти блоки изначально являются высокодоступными, надежными и масштабируемыми. Они имеют встроенную совместимость и возможность работы в нескольких зонах доступности. Например, S3 спроектирован для обеспечения 99.999999999% сохранности и 99.99% доступности обьектов в год. Со этими блоками можно работать через API при помощи простых вызовов. Все они имеют свои преимущества и недостатки, которые нужно учитывать при построении и работы системы. Правильное использование данных блоков может резко сократить затраты на разработку и создание сложной инфраструктуры и помогут команде сосредоточиться на продукте, а не на создании и поддержке инфраструктуры.

Построение высокодоступной системы между регионами AWS
На данный момент существует 7 регионов AWS по всему миру, и их инфраструктура увеличивается каждый день. Следующая диаграмма отображает текущую инфраструктуру регионов:

Использование AWS в нескольких регионах можно разделить на следующие категории: Cold, Warm, Hot Standby и Hot Active.
Cold и Warm больше относятся к аварийному восстановлению, в то время как Hot Stanby и Hot Active могут рассматриваться для проектирования высокодоступной системы между различными регионами. При проектировании высокодоступной системы между различными регионами необходимо учесть следующие проблемы:

• Миграция приложения — возможность мигрирования окружения для приложения между регионами AWS
• Синхронизация данных — возможность мигрирования данных в реальном времени между двумя или более регионами
• Сетевой трафик — возможность управления потоком сетевого трафика между регионами

Следующая диаграмма иллюстрирует простую высокодоступную систему в рамках нескольких регионов.

Теперь рассмотрим как решить эти проблемы:
Миграция приложения. Образы AMI, как S3, так и EBS, доступны только в пределах одного региона, соответственно все необходимые идентичные образы должны быть созданы во всех регионах, которые планируется использовать. Каждый раз при обновлении кода приложения соответсвующие обновления и изменения должны быть выполнены во всех регионах на всех образах. Для этого можно использовать автоматизационные скрипты, но лучше воспользоваться такими системами авто-конфигурирования как Puppet или Chef, это может сократить и упростить затраты на разворачивание приложений. Стоит отметить, что помимо AMI образов, существует такой сервис, как Amazon Elastic IP, который тоже работает только в пределах одного региона.
Миграция данных. Каждая сложная система содержит данные, распределенные между различными источниками данных, такими как реляционные базы данных, нереляционные базы данных, кеши и файловые хранилища. Ниже приведены некоторые технологии, рекомендуемые для использования при работе с неколькими регионами:

• Базы данных: репликации MySQL Master-Slave, SQL Server 2012 HADR, SQL Server 2008, Programmatic RDS
• Файловое хранилище: распределенная сетевая файловя система GlusterFS, репликации на уровне S3
• Кеш: так как репликации для кеша между регионами дорогостоящая в большинстве случаев, рекомендуется держать отдельный разогретый кеш в каждом регионе.
• Для скоростной передачи файлов рекомендуется использоваться сервисы, такие как Aspera.

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

• В данный момент встроенный балансировщик нагрузки ELB не поддерживает распределение нагрузки между регионами, так что он не подходит для распределения трафика между регионами
• Для этой цели подходят реверсные прокси и балансировщики нагрузки (такие как HAProxy, Nginx). Однако в случае если весь регион недоступен, то и сервера, распределяющие нагрузку, могут быть недоступны или могут не видеть сервера, находящиеся в других регионах, что может привести ошибки приложения.
• Распространенной практикой является использование управления распределением на уровне DNS. Используя такие сервисы как UltraDNS, Akamai или Route53 LBR (маршрутизация
• основанная на времени отклика) можно перераспределять трафик между регионами
• Используя Amazon Route53 LBR можно переключать трафик между разными регионами и перенапрвлять запросы пользователей в регион с меньшим временем отклика. В качестве конечной точки для route53 может быть использован публичный IP адрес сервера, Elastic IP, ELB IP.
• Amazon Elastic IP не умеет переключаться между разными регионами. Такие сервисы, FTP и другие IP ориентированые сервисы, предназначеные для коммуникации между приложениями, должны быть перенастроены на использование доменных имен вместо IP адресов; это ключевой момент, который должен быть учтен при использовании нескольких регионов

Построение высокодоступной системы между различными облачными и хостинг ^[1] провайдерами

Многие говорят о построении высокодоступной системы с использованием нескольких Cloud и хостинг ^[1] провайдеров. Можно назвать следующие причины, по которым компании хотят использовать эти сложные с точки зрения артектуры системы:

• Большие предприятия, которые уже вложили основную часть средств в построение своих собственных датацентров или в аренду физического оборудования в датацентрах провайдеров, хотят использовать AWS для аварийного восстановления (Disaster recovery) в случае проблем с основным датацентром. Предприятия, которые уже имеют свои частные облака на базе Eucalyptus, Open Stack, Cloud Stack или vCloud, установленные в их собственных датацентрах и также хотят использовать AWS для аварийного восстановления. Eucalyptus обладает максимальной совместимостью с AWS, так как имеет совместимость на уровне API. Большинство рабочей нагрузки может быть интегрировано между AWS и Eucalyptus. Например, представим, что у предприятия есть набор разработаных скриптов для Amazon EC2 используюющих AWS API в приватном облаке Eucalyptus, это облако может легко мигрировать на AWS в случае необходимости отказоустойчивости. Если же предприятие использует OpenStack или другого провайдера приватного облака, скрипты прийдется переписать, адаптировать для возможности работы в новой среде. Это может быть экономически невыгодно для сложных систем.
• Компании, которые считают свою инфраструктуру н подходящей для масштабируемости или высокой доступности, могут использовать AWS как основную площадку, а свои датацентры, как второстепенные на случай аварийного восстановления.
• Компании, которые не удовлетворены стабильностью и надежностью их текущих публичных Cloud провайдеров, могут захотеть использовать много облачную структуру. Этот случай является самым редким сейчас, но может стать основным в будущем.

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

• Переключение между несколькими провайдерами может быть обеспечено использованием на уровне управляемых DNS сервисов, таких как Akamai, Route53, UltraDNS. Так как эти решения независимы от Cloud провайдеров, регионов и зон доступности, они эффективно могут использоваться для переключения сетевого трафика между датацентрами и провайдерами для обеспечения высокой доступности.
• Фиксированный IP адрес может быть предоставлен датацентром или хостинг ^[1] провайдером, в то время как некоторые Cloud провайдеры в данный момент не могут обеспечить фиксированный IP для виртуальных машин. Это может быть узким местом при обеспечении высокой доступности между Cloud провайдерами.
• Очень часто возникает потребность в установлении VPN соединения между датацентром, Cloud провайдером для миграции конфиденциальны данных между облаками. Может возникнуть проблема с настройкой, внедрением и поддержкой этого сервиса у некоторых Cloud провайдеров. Этот момент должен быть учтен при проектировании.

Миграция рабочей нагрузки:
Образы Amazon AMI не могут быть доступны для других Cloud провайдеров. Новые образы для виртуальных машин должны быть созданы для каждого датацентра или провайдера, что может быть причиной дополнительных временных и денежных затрат.
Сложные скрипты для автоматизации, использующие Amazon API, должны быть переписаны для каждого Cloud провайдера с использованием соответствующего API. Некоторые Cloud провайдеры даже не предоставляют своего API для управления инфраструктурой. Это может привести к усложнению обслуживания.
Типы операционных систем, программное обеспечение, аппаратная совместимость, все это должно быть проанализировано и учтено при проектировании.
Унифицированное управление инфраструктурой может стать большой проблемой при использовании разных провайдеров, если для этого не используются такие инструменты, как RightScale.

Оригинал статьи: harish11g.blogspot.in/2012/06/aws-high-availability-outage.html ^[3]
Автор: Harish Ganesan

Автор: helldesigner