В этой части будут рассмотрены следующие варианты построения высокодоступных систем на базе AWS:
Построение высокодоступной системы между зонами доступности AWS.
Зоны досутности в Amazon это отдельные независимые, изолированые друг от друга датацентры в рамках одного региона. Зоны доступности имеют стабильное сетевое соединение между собой, но построены таким образом, что проблемы в одной зоне не влияют на доступность других зон (они имеют независимое электропитание, охлаждение и системы безопасности). Диаграмма ниже отображает существующее распределение зон доступности (обозначены фиолетовым цветом) в рамках регионов (обозначеные синим цветом).
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/a04/fa0/b25/a04fa0b25e43c76597b6189723f5d47e.jpg)
Большинство высокоуровневых сервисов 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, ее нужно спроектировать так, чтобы приложение работало в нескольких зонах доступности. Зоны доступности находятся в различных географических областях, поэтому использование нескольких зон может обезопасить приложение от проблем в конкретной области. Следующая диаграмма показывает различные уровни (с примерами программного обеспечения), которые должны быть спроектированы с использованием нескольких зон доступности.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/ddc/ea5/542/ddcea55425daa1b748ddef66561a753a.jpg)
Для того, чтобы в случае неработоспобности одной зоны приложение продолжало работать без сбоев и потери данных в другой зоне, важно иметь независимые друг от друга программные стеки приложения в разных зонах (как в пределах одного региона так и в в разных регионах). На этапе проектирования системы нужно хорошо понимать какие части приложения привязаны к зоне.
Пример:
Типичное Web приложение состоит из таких уровней, как DNS, Load Balancer, Web сервер, сервер приложения, кеш, база данных. Все эти уровни могут быть распределены и развернуты в двух и более зонах доступонсти, так как описано ниже.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/d72/1d0/f51/d721d0f51a3b4da43e9e04879fe3fdc3.jpg)
Также большинство встроеных блоков AWS изначально спроектированы с поддержкой доступности в нескольких зонах. Архитекторы и разработчики, работающие с блоками AWS на этапе проектирования приложения, могут использовать встроенные возможности для обеспечения высокой доступности.
Проектирование высокодоступной системы используя встроенные блоки AWS:
Эти блоки могут использоваться, как Web сервисы. Эти блоки изначально являются высокодоступными, надежными и масштабируемыми. Они имеют встроенную совместимость и возможность работы в нескольких зонах доступности. Например, S3 спроектирован для обеспечения 99.999999999% сохранности и 99.99% доступности обьектов в год. Со этими блоками можно работать через API при помощи простых вызовов. Все они имеют свои преимущества и недостатки, которые нужно учитывать при построении и работы системы. Правильное использование данных блоков может резко сократить затраты на разработку и создание сложной инфраструктуры и помогут команде сосредоточиться на продукте, а не на создании и поддержке инфраструктуры.
Построение высокодоступной системы между регионами AWS
На данный момент существует 7 регионов AWS по всему миру, и их инфраструктура увеличивается каждый день. Следующая диаграмма отображает текущую инфраструктуру регионов:
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/eb4/cfb/1f0/eb4cfb1f0372a9219dfcf5d77128f3d8.jpg)
Использование AWS в нескольких регионах можно разделить на следующие категории: Cold, Warm, Hot Standby и Hot Active.
Cold и Warm больше относятся к аварийному восстановлению, в то время как Hot Stanby и Hot Active могут рассматриваться для проектирования высокодоступной системы между различными регионами. При проектировании высокодоступной системы между различными регионами необходимо учесть следующие проблемы:
Следующая диаграмма иллюстрирует простую высокодоступную систему в рамках нескольких регионов.
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/838/123/9dd/8381239dd36a63448679a76a94a927f0.jpg)
Теперь рассмотрим как решить эти проблемы:
Миграция приложения. Образы AMI, как S3, так и EBS, доступны только в пределах одного региона, соответственно все необходимые идентичные образы должны быть созданы во всех регионах, которые планируется использовать. Каждый раз при обновлении кода приложения соответсвующие обновления и изменения должны быть выполнены во всех регионах на всех образах. Для этого можно использовать автоматизационные скрипты, но лучше воспользоваться такими системами авто-конфигурирования как Puppet или Chef, это может сократить и упростить затраты на разворачивание приложений. Стоит отметить, что помимо AMI образов, существует такой сервис, как Amazon Elastic IP, который тоже работает только в пределах одного региона.
Миграция данных. Каждая сложная система содержит данные, распределенные между различными источниками данных, такими как реляционные базы данных, нереляционные базы данных, кеши и файловые хранилища. Ниже приведены некоторые технологии, рекомендуемые для использования при работе с неколькими регионами:
Так как все вышеописаные технологии являются асинхронными репликациями, нужно опасаться потери данных и не забывать о значениях RPO (допустимая точка восстановления) и RTO (допустимое время восстановления) для обеспечения высокой доступности.
Сетевой поток: возможность обеспечения потока сетевого трафика между различными регионами. Рассмотрим ключеывые моменты, которые нужно учесть при работе с сетевым потоком:
Построение высокодоступной системы между различными облачными и хостинг провайдерами
Многие говорят о построении высокодоступной системы с использованием нескольких Cloud и хостинг провайдеров. Можно назвать следующие причины, по которым компании хотят использовать эти сложные с точки зрения артектуры системы:
![image](https://habrastorage.org/r/w780q1/getpro/habr/post_images/08f/add/f2a/08faddf2a24ca45c2bee98655fbfc9e7.jpg)
Большинство решений описаных в разделе для нескольких регионов AWS подходят и для данного случая.
При проектировании высокодоступных систем между разными Cloud провайдерами или разными датацентрами нужно тщательно определиться со следующими ключевыми моментами:
Синхронизация данных. Обычно это шаг не является большой проблемой, если хранилища данных могут быть установлены, развернуты у каждого из используемых Cloud провайдеров. Совместимость программного обеспечения для баз данных, инструментария и утилит для работы с базами, при условии, что они могут быть легко установлены, поможет решить проблемы с синхронизацией данных между разными провайдерами.
Сетевой поток.
Миграция рабочей нагрузки:
Образы Amazon AMI не могут быть доступны для других Cloud провайдеров. Новые образы для виртуальных машин должны быть созданы для каждого датацентра или провайдера, что может быть причиной дополнительных временных и денежных затрат.
Сложные скрипты для автоматизации, использующие Amazon API, должны быть переписаны для каждого Cloud провайдера с использованием соответствующего API. Некоторые Cloud провайдеры даже не предоставляют своего API для управления инфраструктурой. Это может привести к усложнению обслуживания.
Типы операционных систем, программное обеспечение, аппаратная совместимость, все это должно быть проанализировано и учтено при проектировании.
Унифицированное управление инфраструктурой может стать большой проблемой при использовании разных провайдеров, если для этого не используются такие инструменты, как RightScale.
Оригинал статьи: harish11g.blogspot.in/2012/06/aws-high-availability-outage.html
Автор: Harish Ganesan
- Построение высокодоступной системы между зонами доступности AWS
- Построение высокодоступной системы между регионами AWS
- Построение высокодоступной системы между различными облачными и хостинг провайдерами
Построение высокодоступной системы между зонами доступности AWS.
Зоны досутности в Amazon это отдельные независимые, изолированые друг от друга датацентры в рамках одного региона. Зоны доступности имеют стабильное сетевое соединение между собой, но построены таким образом, что проблемы в одной зоне не влияют на доступность других зон (они имеют независимое электропитание, охлаждение и системы безопасности). Диаграмма ниже отображает существующее распределение зон доступности (обозначены фиолетовым цветом) в рамках регионов (обозначеные синим цветом).
![image](https://habrastorage.org/getpro/habr/post_images/a04/fa0/b25/a04fa0b25e43c76597b6189723f5d47e.jpg)
Большинство высокоуровневых сервисов 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, ее нужно спроектировать так, чтобы приложение работало в нескольких зонах доступности. Зоны доступности находятся в различных географических областях, поэтому использование нескольких зон может обезопасить приложение от проблем в конкретной области. Следующая диаграмма показывает различные уровни (с примерами программного обеспечения), которые должны быть спроектированы с использованием нескольких зон доступности.
![image](https://habrastorage.org/getpro/habr/post_images/ddc/ea5/542/ddcea55425daa1b748ddef66561a753a.jpg)
Для того, чтобы в случае неработоспобности одной зоны приложение продолжало работать без сбоев и потери данных в другой зоне, важно иметь независимые друг от друга программные стеки приложения в разных зонах (как в пределах одного региона так и в в разных регионах). На этапе проектирования системы нужно хорошо понимать какие части приложения привязаны к зоне.
Пример:
Типичное Web приложение состоит из таких уровней, как DNS, Load Balancer, Web сервер, сервер приложения, кеш, база данных. Все эти уровни могут быть распределены и развернуты в двух и более зонах доступонсти, так как описано ниже.
![image](https://habrastorage.org/getpro/habr/post_images/d72/1d0/f51/d721d0f51a3b4da43e9e04879fe3fdc3.jpg)
Также большинство встроеных блоков 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 по всему миру, и их инфраструктура увеличивается каждый день. Следующая диаграмма отображает текущую инфраструктуру регионов:
![image](https://habrastorage.org/getpro/habr/post_images/eb4/cfb/1f0/eb4cfb1f0372a9219dfcf5d77128f3d8.jpg)
Использование AWS в нескольких регионах можно разделить на следующие категории: Cold, Warm, Hot Standby и Hot Active.
Cold и Warm больше относятся к аварийному восстановлению, в то время как Hot Stanby и Hot Active могут рассматриваться для проектирования высокодоступной системы между различными регионами. При проектировании высокодоступной системы между различными регионами необходимо учесть следующие проблемы:
- Миграция приложения — возможность мигрирования окружения для приложения между регионами AWS
- Синхронизация данных — возможность мигрирования данных в реальном времени между двумя или более регионами
- Сетевой трафик — возможность управления потоком сетевого трафика между регионами
Следующая диаграмма иллюстрирует простую высокодоступную систему в рамках нескольких регионов.
![image](https://habrastorage.org/getpro/habr/post_images/838/123/9dd/8381239dd36a63448679a76a94a927f0.jpg)
Теперь рассмотрим как решить эти проблемы:
Миграция приложения. Образы 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 адресов; это ключевой момент, который должен быть учтен при использовании нескольких регионов
Построение высокодоступной системы между различными облачными и хостинг провайдерами
Многие говорят о построении высокодоступной системы с использованием нескольких Cloud и хостинг провайдеров. Можно назвать следующие причины, по которым компании хотят использовать эти сложные с точки зрения артектуры системы:
- Большие предприятия, которые уже вложили основную часть средств в построение своих собственных датацентров или в аренду физического оборудования в датацентрах провайдеров, хотят использовать AWS для аварийного восстановления (Disaster recovery) в случае проблем с основным датацентром. Предприятия, которые уже имеют свои частные облака на базе Eucalyptus, Open Stack, Cloud Stack или vCloud, установленные в их собственных датацентрах и также хотят использовать AWS для аварийного восстановления. Eucalyptus обладает максимальной совместимостью с AWS, так как имеет совместимость на уровне API. Большинство рабочей нагрузки может быть интегрировано между AWS и Eucalyptus. Например, представим, что у предприятия есть набор разработаных скриптов для Amazon EC2 используюющих AWS API в приватном облаке Eucalyptus, это облако может легко мигрировать на AWS в случае необходимости отказоустойчивости. Если же предприятие использует OpenStack или другого провайдера приватного облака, скрипты прийдется переписать, адаптировать для возможности работы в новой среде. Это может быть экономически невыгодно для сложных систем.
- Компании, которые считают свою инфраструктуру н подходящей для масштабируемости или высокой доступности, могут использовать AWS как основную площадку, а свои датацентры, как второстепенные на случай аварийного восстановления.
- Компании, которые не удовлетворены стабильностью и надежностью их текущих публичных Cloud провайдеров, могут захотеть использовать много облачную структуру. Этот случай является самым редким сейчас, но может стать основным в будущем.
![image](https://habrastorage.org/getpro/habr/post_images/08f/add/f2a/08faddf2a24ca45c2bee98655fbfc9e7.jpg)
Большинство решений описаных в разделе для нескольких регионов AWS подходят и для данного случая.
При проектировании высокодоступных систем между разными Cloud провайдерами или разными датацентрами нужно тщательно определиться со следующими ключевыми моментами:
Синхронизация данных. Обычно это шаг не является большой проблемой, если хранилища данных могут быть установлены, развернуты у каждого из используемых Cloud провайдеров. Совместимость программного обеспечения для баз данных, инструментария и утилит для работы с базами, при условии, что они могут быть легко установлены, поможет решить проблемы с синхронизацией данных между разными провайдерами.
Сетевой поток.
- Переключение между несколькими провайдерами может быть обеспечено использованием на уровне управляемых DNS сервисов, таких как Akamai, Route53, UltraDNS. Так как эти решения независимы от Cloud провайдеров, регионов и зон доступности, они эффективно могут использоваться для переключения сетевого трафика между датацентрами и провайдерами для обеспечения высокой доступности.
- Фиксированный IP адрес может быть предоставлен датацентром или хостинг провайдером, в то время как некоторые 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
Автор: Harish Ganesan