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

Даже у таких монстров облачной индустрии, как Amazon случаются проблемы с оборудованием. В связи с недавними перебоями в работе US East-1 датацентра, данная статья может быть полезной.

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

Отказоустойчивость является одной из основных характеристик для всех облачных систем. Каждый день множество приложений проектируются и разворачиваются на AWS без учета этой характеристики. Причины данного поведения могут варьироваться от технической неосведомленности в том, как правильно спроектировать отказоустойчивую систему до высокой стоимости создания полноценной высокодоступной системы в рамках сервисов AWS. В данной статье освещается несколько решений, которые помогут преодолеть перебои в работе оборудования провайдеров и создать более подходящее решение в рамках AWS инфраструктуры.
Структура типичного Интернет приложения состоит из следующих уровней: DNS, Load Balancer, веб сервер, сервер приложения, база данных, кэш. Давайте возьмем этот стек и подробно рассмотрим основные моменты, которые необходимо учитывать при построении высокодоступной системы:
  • Построение высокодоступной системы в AWS
  • Высокая доступность на уровне веб сервера / сервера приложения
  • Высокая доступность на уровне балансировки нагрузки / DNS
  • Высокая доступность на уровне базы данных
  • Построение высокодоступной системы между зонами доступности AWS
  • Построение высокодоступной системы между регионами AWS
  • Построение высокодоступной системы между различными облачными и хостинг провайдерами

Часть 2

Высокая доступность на уровне веб сервера / сервера приложения

Для того чтобы исключить компонент наличие единой точки отказа (SPOF — Single Point of Failure), обычной практикой является запуск веб приложения на двух и более экземплярах виртуальных серверов EC2. Такое решение позволяет обеспечить более высокую отказоустойчивость по сравнению с использованием одного сервера. Сервера приложений и веб сервера могут быть настроены как с использованием проверки состояния, так и без неё. Ниже изображены самые часто встречающиеся архитектурные решения для высокодоступных систем с использованием проверки состояния:

image


Ключевые моменты, на которые нужно обратить внимание при построении такой системы:

  • Так как текущая инфраструктура AWS не поддерживает Multicast протокол на уровне приложения данные необходимо синхронизировать, используя обычный Unicast TCP. Например, для Java приложений можно использовать JGroups, Terracotta NAM или подобное программное обеспечение для синхронизации данных между серверами. В простейшем случае можно использовать одностороннюю синхронизацию при помощи rsync, более универсальным и надежным решением является использование сетевых распределенных файловых систем таких, как GlusterFS.
  • Для хранения пользовательских данных и информации о сессиях можно использовать Memcached EC2, ElastiCache или Amazon DynamoDB. Для большей надежности можно развернуть ElastiCache кластер в различных зонах доступности AWS.
  • Использование ElasticIP для переключения между серверами, не рекомендуется для высоко критичных систем, так как этот процесс может занимать до двух минут.
  • Пользовательские данные и сессии могут храниться в базе данных. Использовать данный механизм нужно с осторожностью, необходимо оценить возможные задержки при операциях чтения/записи в базу.
  • Загружаемые пользователями файлы и документы должны храниться на сетевых файловых системах, таких как NFS, Gluster Storage Pool или Amazon S3.
  • Должна быть включена политика фиксации сессий на уровне Amazon ELB или реверсного прокси, если сессии не синхронизируются посредством единого хранилища, базы данных или другого подобного механизма. Этот подход обеспечивает высокую доступность, но не обеспечивает отказоустойчивость на уровне приложения.


Высокая доступность на уровне балансировки нагрузки / DNS

Уровень DNS/Load Balancing является главной точкой входа для веб приложения. Нет смысла в построении сложных кластеров, тяжелых реплицируемых веб ферм на уровне приложения и базы данных без построения высоко доступной системы на уровне DNS/LB. Если балансировщик нагрузки является единой точкой отказа, то его выход из строя сделает недоступной всю систему. Ниже приведены самые распространенные решения для обеспечения высокой доступности на уровне балансировщика нагрузки:

image

1) Использование Amazon Elastic Load Balancer в качестве балансировщика нагрузки для обеспечения высокой доступности. Amazon ELB автоматически распределяет нагрузку приложения между несколькими EC2 серверами. Этот сервис дает возможность достичь большего чем обычная отказоустойчивость приложения, это дает возможность плавного увеличения ресурсов между которыми распределяется нагрузка в зависимости от интенсивности входящего трафика. Это позволяет обеспечить обслуживание нескольких тысяч одновременных подключений и при этом может гибко расширятся, при возрастании нагрузки. ELB по своей сути является отказоустойчивым блоком, который может самостоятельно исправить сбои в своей работе. Когда нагрузка увеличивается, то на уровне ELB автоматически добавляются дополнительные виртуальные машины ELB EC2. Это автоматически исключает наличие единой точки отказа и весь механизм распределения нагрузки продолжает работать, даже если некоторые виртуальные машины ELB EC2 выходят из строя. Так же Amazon ELB автоматически определяет доступность сервисов, между которыми необходимо распределять нагрузку и в случае проблем автоматически направляет запросы на доступные сервера. Amazon ELB может быть настроен как для распределения нагрузки с использованием случайного распределения Round Robin, без проверки состояния сервисов, так и с использованием механизма закрепления сессий и проверкой состояния. Если же синхронизация сессий не реализована, то даже использование закрепления сессий не может обеспечить отсутствия появления ошибок приложения при отказе одного из серверов и перенаправлении пользователей на доступный сервер.

2) Иногда приложения требуют:
— Сложного балансирования нагрузки с возможностью кэширования (Varnish)
— Использования алгоритмов распределения нагрузки:
— Минимум соединений (least connection) – сервера с меньшим количеством активных подключений получают больше запросов
— Минимум соединений с весовыми коэффициентами (Weighted Least-Connections) -сервера с меньшим количеством активных соединений и большей мощностью получают больше запросов
— Распределение по источнику (Destination Hash Scheduling)
— Распределение по получателю (Source Hash Scheduling)
— Распределение, основанное на размещении и минимуме соединений (Locality-Based Least-Connection Scheduling) — Больше запросов будут получать сервера с меньшим количеством активных подключений с учётом IP-адресов получателей
— Обеспечить работу при больших краткосрочных всплесках нагрузки
— Наличие фиксированного IP адреса у балансировщика нагрузки

Во всех вышеперечисленных случаях использование Amazom ELB не подходит. Лучше использовать сторонние балансировщики или реверсные прокси, такие как: Nginx, Zeus, HAproxy, Varnish. Но при этом нужно обеспечить отсутствие единой точки отказа, самое простое решение данной проблемы использовать несколько балансировщиков. Реверсный прокси Zeus уже имеет встроенную функциональность для работы в кластере, для других сервисов необходимо использовать циклическое распределение DNS Round Robin. Давайте рассмотрим этот механизм подробнее, но для начала определим несколько ключевых моментов, которые нужно учесть при построении надежной системы распределения нагрузки в рамках AWS:

  • Несколько Nginx или HAproxy сервисов могут быть сконфигурированы для обеспечения высокой доступности в AWS, эти сервисы могут определять доступность сервиса и распределять запросы между доступными серверами
  • Nginx или HAproxy могут быть настроены для циклического распределения нагрузки, в случае если приложение не поддерживает проверку доступности состояния. Так же эти сервисы поддерживают работу с использованием механизма закрепления сессий, но если синхронизация сессий не обеспечена должным образом это не гарантирует отсутствие появления ошибок на уровне приложения при выходе одного сервера из строя
  • Горизонтальное масштабирование балансировщиков нагрузки вертикального масштабирования. Горизонтальное масштабирование увеличивает количество отдельных машин выполняющих функцию балансировки, исключая наличие единой точки отказа. Для масштабирования таких балансировщиков нагрузки как Nginx и HAproxy необходима разработка своих скриптов и образов системы, использование для масштабирования Amazon AutoScaling не рекомендуется в данном случае.
  • Для определения доступности серверов балансировщика можно использовать систему мониторинга Amazon CloudWatch или сторонние сервисы мониторинга, такие как Nagios, Zabbix, Icinga и в случае недоступности одного из серверов при помощи скриптов и утилит командной строки для управления EC2 запускать новый экземпляр сервера для балансировщика в течение нескольких минут.


Теперь давайте обсудим уровень, который стоит над балансировщиком – DNS. Amazon Route 53 является высоко доступным, надежным и масштабируемым сервисом DNS. Этот сервис может эффективно распределять пользовательские запросы ко всем сервисам Amazon, таким как EC2, S3, ELB, а так же за пределы AWS инфраструктуры. Route 53 по сути является отказоучтойчивым управляемым DNS сервером и может быть сконфигурирован, как через интерфейс командной строки, так и через веб консоль. Сервис поддерживает как циклическое, так и весовое распределение нагрузки и может распределять запросы как между отдельными EC2 серверами, входящими в балансировщик, так и для Amazon ELB. При использовании циклического распределения проверка доступности сервиса и переключения запросов на доступные сервера не работает и должна быть вынесена на уровень приложения.

Высокая доступность на уровне базы данных

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

image

1) Использование репликации Master-Slave.
Мы можем использовать один EC2 сервер в качестве основного (master) и один или более в качестве второстепенных серверов (slave). Если эти сервера находятся в публичном облаке необходимо использовать ElastcIP, если же используется приватное облако (VPC) доступ между серверами может быть осуществлен через приватные IP адреса. В таком режиме сервера базаы данных могут использовать асинхронную репликацию. Когда основной сервер баз данных выходит из строя, мы можем переключить второстепенный сервер в режим Master, используя свои скрипты, тем обеспечив высокую доступность. Мы можем запустить репликацию между серверами в режиме Active-to-Active или в режиме Active-to-Passive. В первом случае операции записи, операции промежуточной записи и чтения должны выполняться на основном сервере, а операции чтения должны выполняться на второстепенном сервере. Во втором случае все операции чтения и записи должны выполняться только на основном сервере, а на второстепенный сервер только в случае недоступности основного сервера после того как второстепенный сервер переключается в режим Master. Рекомендуется использовать EBS образы для EC2 серверов баз данных для обеспечения надежности и стабильности на уровне работы с диском. Для обеспечения дополнительной производительности и целостности данных можно настроить EC2 сервер баз данных с различными вариантами RAID массивов в рамках AWS.

2) MySQL NDBCluster
Мы можем настроить два или более MySQL EC2 серверов в качестве SQLD и узлов данных, для хранения данных и один управляющий MySQL сервер для создания кластера. Все узлы данных в кластере могут использовать асинхронную репликацию для синхронизации данных между собой. Операции чтения и записи могут быть одновременно распределены между всеми узлами хранения данных. Когда один из узлов хранения данных в кластере отказывает, другой становится активным и обрабатывает все поступающие запросы. Если используется публичное облако, необходимы ElasticIP адреса для каждого сервера в кластере, если же используется приватное облако можно использовать внутренние IP адреса. Рекомендуется использовать EBS образы для EC2 серверов баз данных для обеспечения надежности и стабильности на уровне работы с диском. Для обеспечения дополнительной производительности и целостности данных можно настроить EC2 сервер баз данных с различными вариантами RAID массивов в рамках AWS.

3) Использование зон доступности совместно с RDS
Если мы используем Amazon RDS MySQL на уровне базы данных, мы можем создать один Master сервер в одной зоне доступности и один Hot Standby сервер в другой зоне доступности. Дополнительно мы модем иметь несколько второстепенных Read Replica серверов в нескольких зонах доступности. Основной и второстепенный узлы RDS могут использовать синхронную репликацию данных между собой, Read Replica сервер использует асинхронную репликацию. Когда Master RDS серве недоступен, Hot Standby становится автоматически доступен по тому же адресу в течение нескольких минут. Все операции записи, промежуточного чтения и записи должны быть выполнены на Master сервере, операции чтения могут быть выполнены на Read Replica серверах. Все RDS сервисы используют EBS образы. Так же сервис RDS предоставляет автоматическое создание резервных копий и с его помощью можно восстановить данные с определенной точки, так же RDS может работать в рамках приватного облака.

Остальные пункты будут рассмотрены во второй части:
  • Построение высокодоступной системы между зонами доступности AWS
  • Построение высокодоступной системы между регионами AWS
  • Построение высокодоступной системы между различными облачными и хостинг провайдерами


Оригинал статьи: harish11g.blogspot.in/2012/06/aws-high-availability-outage.html
Автор: Harish Ganesan
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 18

    +1
    Для масштабирования таких балансировщиков нагрузки как Nginx и HAproxy необходима разработка своих скриптов и образов системы

    nginx.org/en/docs/howto_setup_development_environment_on_ec2.html
      +1
      Спасибо за информацию.
      0
      Хотелось бы подробнее узнать за счёт чего обеспечивается отказоустойчивость ELB. Ведь эта подсистема является узким местом для всей вышеописанной мощности Amazon. Используются ли географически распределённые дата-центры для одного моего конкретного IP, anycast, что-то ещё?

      Имея среднестатистическое веб-приложение, у нас есть DNS -> «nginx/elb» -> «приложение».
      — Если что-то случится с «приложением», то мы практически моментально можем переключиться на резервный дата-центр дёрнув «nginx/elb».
      — Если умер «nginx/elb», то дело плохо ведь быстро переключить DNS невозможно. Он кешируется везде где только можно, причём указанный TTL не всегда соблюдается. Любой DNS. Даже тот, что под брендом Amazon.
      — Если умер DNS… Ну и пусть, у нас ведь nx-серверов больше одного прописано.

      Сейчас использую связку DNS (5 nx-серверов) + nginx (балансировщик + failover ip на другой ДЦ) + приложение (там все серьёзно в плане масштабирования и отказоустойчивости).

      И, собственно, вопрос: Чем отказоустойчивее Amazon по сравнению с моей системой?
        0
        — ELB не использует один фиксированный IP, он использует пул адресов и DNS CNAME. И для работы с ним используется соответственно не IP, а доменное имя.
        — ELB может работать между зонами доступности Amazon, но только в пределах одного региона

        Route 53 работает между регионами, имеет встроенную проверку состояния и работает, так же как и ваши 5 DNS серверов. А проблема кэширования на уровне DNS клиента, особенно в Windows, может быть в любом случае.

        Amazon, конечно, не является единственно правильным вариантом, и имеет свои недостатки. Самому свою систему можно настроить более гибко и более точно для своих конкретных целей. Все дело в сроках реализации конкретной схемы и в стоимости. На Amazon это всё можно внедрить быстрее и это может обойтись дешевле, чем использование своих датацентров или аренда серверов.
          0
          То есть отказоустойчивость каждого конкретного ip-адреса ELB обеспечивается за счёт аналога DNS Round Robin на уровне Route 53? Правильно понимаю?
            +1
            Там на самом деле всё немного сложнее. По умолчанию пул ELB IP адресов содержит только один IP на каждую зону доступности, для которой он сконфигурирован. При увеличении сетевой нагрузки в пул добавляются дополнительные IP для обеспечения необходимой пропускной способности. IP в пуле не фиксированы и могут меняться. При DNS запросе выдается IP из пула, скорее всего по Round Robin и в соответствии доступностью зон. Сам Amazon рекомендует использовать Route 53 над ELB для устранения проблемы с изменением IP в пуле и уменьшения TTL.

            А что на самом деле стоит за каждым IP адресом ELB они не раскрывают, во всяком случае, я такой информации пока не нашел.
              0
              Я то же не смог докопаться до истины. Но есть подозрение, что ничего особого за IP адресом ELB не стоит. Иначе бы они трубили об этом, так как это весомое конкурентное преимущество. Эх, скорее бы уже времена ipv6 anycast. Больно дорог он для ipv4 получается. Кроме корневых DNS ещё не видел что бы кто-то использовал эту фишку. А ведь вот она — реально отказоустойчивая точка входа в проект.

              Посматриваю на Amazon ELB и Route 53 как замену вышеописанной моей схеме. Поэтому такой интерес к данной теме. Интерес немного подрывается недавними сбоями в Amazon, которые не переживали даже очень крупные проекты. То ли их админы неправильно Amazon использовали, то ли сам Amazon в действительности, не может гарантировать отказоустойчивости даже на распределённом географически кластере.
        0
        То есть отказоустойчивость каждого конкретного ip-адреса ELB обеспечивается за счёт аналога DNS Round Robin на уровне Route 53? Правильно понимаю?
          0
          Прошу прощения, это был ответ для habrahabr.ru/post/147390/#comment_4971093. Перепутал ссылочку «ответить» с «написать комментарий».
          0
          Буду ждать второй части статьи. Очень уж интересует вариант высокодоступной системы в разных ДЦ, а, конкретно, некий сервис, где можно купить за недорого на быстром канале failover IP, направлять который можно будет куда душе угодно.
            0
            Насколько я знаю, ELB не может направлять наружу. Поправьте меня, если я ошибаюсь, но у меня получалось балансировать только сервера внутри Amazon. То есть минимальная схема использования их отказоустойчивости — Route 53 + ELB + 2xEC2 Instances. На инстансы ставится nginx или альтернативы и уже с них запросы направляются наружу.

            Практика показывает, что задержки не в разы, но возрастают. Поэтому стоит хорошенько взвесить все за и против такой схемы.

            Плюсом, не забываем что творилось с достаточно большими сервисами во время недавних проблем Amazon.
              +1
              Да, ELB не работат неружу, только внутри Amazon. Route 53 может работать с внешними сервисами.
            0
            Еще одним моментом отказоустойчивости, не указанный в данном переводе по понятным причинам, является использование простых и общедоступных технологий. В этот список входят все перки Amazon: ELB, Route53, EBS, SQS и прочая, прочая, прочая. Имея собственные методы скейлинга и распределения нагрузки, деплой во множественных регионах с GeoDNS и системами leader election (например Zookeeper) можно использовать только процессорные мощности клауда, причем не только Amazon.

            Помните прошлогоднее падение EBS? Ну и что вы будете делать если инстанс грузится с EBS?
            А что делать если ELB неожиданно перестал добавлять сервера в пул и убирать мертвые? Сам видел не раз.
            Видели как ЧУЖОЙ ELB заруливает 4K req/sec трафика к вам на сервера? А я видел.
            ELB вообще не гарантирует работу с вебсерверами кроме Apache2, nginx, IIS. Так что только reverse proxy, а это еще задержки и еще одно звено к поломке.
            А бесконечные «connectivity issues in region»?

            Все эти замечательные технологии замечательны при 2-х условиях: пока они работают без сбоев, и пока вам не надо переезжать куда-то еще. Ничто так не опасно как видимость безопасности.

            На своем более чем 3-х летнем опыте построения мультирегиональных высоконагруженных и высокодоступных систем в клаудах, я бы посоветовал строить простые системы с наименьшим количеством звеньев и как можно меньшим числом проприетарных технологий.
              0
              Да, вы конечно правы, с сервисами Amazon часто случаются какие-то проблемы. Последние события, произошедшие 29-го июня сильно повлияли на один проект, к которому я имел отношение. Проблемы на Amazon совпали с нагрузочным тестированием и подбором оптимальных настроек для авто-масштабирования. Весь рабочий день был потрачен зря.

              Довольно много популярных высоконагруженных приложений хосятся на Amazon.

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

              Но данные сервисы популярны у клиентов и привлекают их своей ценой и видимой простотой настройки, по сравнению с созданием инфраструктуры в реальном датацентре. Если клиент за это хочет платить, то нужно научиться создавать как можно стабильные системы на основе того, что предлагается.
                0
                не поймите меня неправильно, мы живем в Амазоне, но используем его более как computational power. Это позволяет в любой момент сказать «Давай, до свидания!» или же иметь дополнительную зону в другом клауде, например RackSpace.
                  0
                  Я с ReckSpace тесно пока не работал, как он себя ведет в отношении стабильности работы?
                    0
                    Там свои прибамбасы, но в целом стабильно. Инстансы пошустрее чем у Амазона, быстрее I/O дисков, меньше шума от соседей, больше перков. У Амазона намного лучше API.

                    Единственное, что меня раздражает, так это политика компании. Могут позвонить и сказать: «Мы вас выключаем потому, что вы генерируете большую нагрузку. Как починим – вернем.» А все почему? Да потому, что основная масса там – обычные сайты, и дабы не гневить народ, вырубают выборочно. А причина обычно в железе, которое установили или еще что-то они там делают. С этой точки зрения Амазон намного круче для бизнеса, вот и при первом же таком заявлении, мы сказали Рэкспейсу «Bye-bye.»
                    Тут-то, к слову, при переезде поняли, что не стоит опираться на фичи клауда.
                  0

                  Посоветуйте, пожалуйста, что-нибудь почитать по теме. Спасибо.

              Only users with full accounts can post comments. Log in, please.