Как я могу развернуть масштабируемый надежный кластер haproxy на Amazon EC2?

Нам нужны более продвинутые функциональные возможности, чем обеспечивает ELB (в основном проверка L7), но не совсем очевидно, как справиться с такими вещами, как сердцебиение и высокая доступность с чем-то вроде haproxy с использованием EC2. Существует высокая вероятность того, что нам потребуется 3 или более узлов haproxy в кластере, поэтому простое сердцебиение между двумя узлами не сработает.

Похоже, что наличие слоя «heartbeat'd» перед узлами haproxy было бы правильным путем, возможно, с использованием IPVS, но обработкой изменений конфигурации при изменении кластера EC2 (либо путем преднамеренных изменений, таких как расширение, либо непреднамеренных, например, потеря Узел EC2) кажется нетривиальным.

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

В ответ на вопрос: Нет, сессии не липкие. И да, нам понадобится SSL, но теоретически это может быть полностью обработано другой установкой - мы можем направлять трафик SSL в другое место, чем трафик не-SSL.

Хорошо, я никогда не создавал решение для балансировки нагрузки AWS с трафиком на уровнях SmugMug, а просто подумав о теории и услугах AWS, пришла пара идей.

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

1. Липкие сеансы или нет? Очень предпочтительно не использовать липкий сеанс, а просто позволить всем балансировщикам нагрузки (LB) использовать циклический выбор (RR) или случайный выбор бэкэнда. Выбор RR или случайный внутренний интерфейс прост, масштабируем и обеспечивает равномерное распределение нагрузки при любых обстоятельствах.
2. SSL или нет? Независимо от того, используется ли SSL или какой процент запросов обычно влияет на распределение нагрузки. Часто предпочтительнее прекратить SSL как можно раньше, чтобы упростить обработку сертификатов и сохранить загрузку ЦП SSL от серверов веб-приложений.

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

Хорошо, пара идей, которые должны работать:

1) «Путь AWS»:

• Первый уровень, в самом начале, использует ELB в режиме L4 (TCP / IP).
• Второй уровень, используйте экземпляры EC2 с вашим балансировщиком нагрузки L7 (nginx, HAProxy, Apache и т. Д.).

Преимущества / идея: Балансировщики нагрузки L7 могут быть довольно простыми AMI EC2, все они клонированы из одного AMI и используют одну и ту же конфигурацию. Таким образом, инструменты Amazon могут удовлетворить все потребности HA: ELB контролирует балансировщики нагрузки L7. Если L7 LB умирает или перестает отвечать, ELB и Cloudwatch вместе порождают новый экземпляр автоматически и переносят его в пул ELB.

2) «DNS круговой прием с отслеживанием пути:»

• Используйте базовый циклический перебор DNS, чтобы получить грубое распределение нагрузки по паре IP-адресов. Скажем так, вы публикуете 3 IP-адреса для вашего сайта.
• Каждый из этих трех IP-адресов представляет собой эластичный IP-адрес AWS (EIA), связанный с экземпляром EC2, с балансировщиком нагрузки L7 по вашему выбору.
• Если L2 EC2 LB умирает, совместимый пользовательский агент (браузер) должен просто использовать вместо этого один из других IP-адресов .
• Настройте внешний сервер мониторинга. Контролируйте каждый из 3 EIP. Если пользователь перестает отвечать на запросы, используйте инструменты командной строки AWS и некоторые сценарии, чтобы перенести EIP в другой экземпляр EC2.

Преимущества / идея: Совместимые пользовательские агенты должны автоматически переключаться на другой IP-адрес, если он перестает отвечать на запросы. Таким образом, в случае сбоя это может повлиять только на 1/3 ваших пользователей, и большинство из них не должны ничего замечать, так как их UA молча переключается на другой IP. А ваш внешний блок мониторинга заметит, что EIP не отвечает, и исправит ситуацию в течение пары минут.

3) DNS RR для пар серверов HA:

По сути, это предложение самого Дона о простом биении между парой серверов, но упрощенном для нескольких IP-адресов.

• Используя DNS RR, опубликуйте несколько IP-адресов для службы. Следуя приведенному выше примеру, скажем, вы публикуете 3 IP-адреса.
• Каждый из этих IP-адресов направляется на пару серверов EC2, всего 6 экземпляров EC2.
• Каждая из этих пар использует Heartbeat или другое решение HA вместе с инструментами AWS, чтобы поддерживать активный IP-адрес в активной / пассивной конфигурации.
• В каждом экземпляре EC2 установлен балансировщик нагрузки L7.

Преимущества / идея. В полностью виртуализированной среде AWS на самом деле не так просто рассуждать о сервисах L4 и режимах отработки отказа. Упрощая одну пару идентичных серверов, сохраняя всего 1 IP-адрес, становится проще рассуждать и тестировать.

Вывод: опять же, я на самом деле не пробовал ничего этого в производстве. По моему интуитивному ощущению, вариант с ELB в режиме L4 и саморегулируемые экземпляры EC2 в качестве L7 LB, кажется, наиболее соответствуют духу платформы AWS, и где Amazon, скорее всего, будет инвестировать и расширяться в дальнейшем. Это, вероятно, будет моим первым выбором.

Если вы не выполняете липкие сеансы или используете стиль tomcat / apache (добавьте идентификатор узла к sessionid, а не сохраняйте состояние в LB), то я бы использовал ELB перед группой гапрокси. В ELB встроена проверка работоспособности, так что вы можете контролировать хакрокси и выводить любые из них из пула. Гораздо меньше для настройки, чем отказ от сердцебиения.

Что касается распространения изменений, у меня нет отличного ответа. Puppet отлично подходит для начальной конфигурации и внесения изменений, но для добавления / удаления узлов вам требуется более быстрый отклик, чем 30-минутный интервал опроса.

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