Нам нужны более продвинутые функции, чем предоставляет ELB (в основном проверка L7), но не очевидно, как обрабатывать такие вещи, как сердцебиение и высокая доступность, с помощью чего-то вроде haproxy с использованием EC2. Существует высокая вероятность того, что нам понадобится 3 или более узлов haproxy в кластере, поэтому простое сердцебиение между двумя узлами не сработает.
Похоже, что наличие уровня сердцебиения перед узлами haproxy было бы подходящим вариантом, возможно, с использованием IPVS, но обработка изменений конфигурации по мере изменения кластера EC2 (либо посредством преднамеренных изменений, таких как расширение, либо непреднамеренных, например, потеря Узел EC2) кажется нетривиальным.
Желательно, чтобы решение охватило как минимум две зоны доступности.
Отвечая на вопрос: Нет, сеансы не липкие. И да, нам понадобится SSL, но теоретически это можно полностью решить с помощью другой настройки - мы можем направлять SSL-трафик в другое место, а не в другой.
Хорошо, я сам никогда не создавал решения для балансировки нагрузки AWS с трафиком на уровне SmugMug, но просто подумав о теории и сервисах AWS, мне в голову приходит пара идей.
В исходном вопросе не хватает нескольких вещей, которые могут повлиять на схему балансировки нагрузки:
Я отвечаю с точки зрения того, как сохранить сам уровень балансировки нагрузки высокая доступность. Поддержание высокой доступности серверов приложений просто выполняется с помощью проверок работоспособности, встроенных в ваши балансировщики нагрузки L7.
Хорошо, пара идей, которые должны сработать:
1) «Путь AWS»:
Преимущества / идея: Балансировщики нагрузки L7 могут быть довольно простыми AMI EC2, все клонированные из одного AMI и использующие одну и ту же конфигурацию. Таким образом, инструменты Amazon могут удовлетворить все потребности в высокой доступности: ELB контролирует балансировщики нагрузки L7. Если L7 LB умирает или перестает отвечать, ELB и Cloudwatch вместе автоматически создают новый экземпляр и помещают его в пул ELB.
2) «Циклический перебор DNS с возможностью мониторинга:»
Преимущества / идея: Совместимые пользовательские агенты должны автоматически переключаться на другой IP-адрес, если один из них перестает отвечать. Таким образом, в случае сбоя только 1/3 ваших пользователей должна быть затронута, и большинство из них не должны ничего замечать, поскольку их UA незаметно переключается на другой IP-адрес. И ваш внешний модуль мониторинга заметит, что EIP не отвечает, и исправит ситуацию в течение нескольких минут.
3) DNS RR для пар серверов HA:
По сути, это собственное предложение Дона о простой тактовой передаче между парой серверов, но упрощенной для нескольких IP-адресов.
Преимущества / идея: В полностью виртуализированной среде AWS на самом деле не так просто рассуждать о сервисах L4 и режимах аварийного переключения. Упрощение до одной пары идентичных серверов, поддерживающих только 1 IP-адрес, упрощает рассуждение и тестирование.
Вывод: Опять же, я на самом деле не пробовал ничего из этого в производстве. Исходя из моего внутреннего ощущения, вариант один с ELB в режиме L4 и самоуправляемыми инстансами EC2 в качестве L7 LB кажется наиболее соответствующим духу платформы AWS и куда Amazon, скорее всего, будет инвестировать и расширяться в будущем. Вероятно, это был бы мой первый выбор.
Если вы не выполняете липкие сеансы или используете стиль tomcat / apache (добавляйте идентификатор узла к идентификатору сеанса, а не сохраняете состояние в LB), тогда я бы использовал ELB перед группой haproxies. ELB имеет встроенную проверку работоспособности, поэтому вы можете контролировать хапрокси и удалять любые сбойные из пула. Намного меньше настраивать, чем аварийное переключение.
Что касается распространения изменений, у меня нет отличного ответа. Puppet отлично подходит для начальной настройки и внесения изменений, но для добавления / удаления узлов вам, как правило, требуется более быстрый ответ, чем его 30-минутный интервал опроса.
Я сам не использовал его, но я видел, как многие люди упоминали об использовании марионетки для решения подобных проблем на EC2.