Эластичная Подсистема балансировки нагрузки для нескольких веб-приложений
Вы могли загрузить esxi от флеш-накопителя и получить доступ к Вашим хранилищам данных, или Вы могли использовать Моа для достижения того же или возможно больше, парень, там очень хорошо.
Если можно загрузить esx на жестком диске, и просто необходимо скопировать vms затем, Вы могли использовать VMexplorer или FastSCP, оба свободны, просты в использовании и достаточно быстры.
Один ELB направляет трафик ровно к одному набору экземпляров и распределяет входящий трафик по всем экземплярам "позади". Он не выполняет выборочную маршрутизацию трафика на основе анализа трафика на уровне 7, например заголовка Host: .
Вам потребуется один ELB для каждого набора ] экземпляров. Как вы это описываете, это один ELB для каждого веб-приложения.
Если ваша основная цель для запуска ELB - разгрузка SSL с использованием подстановочного сертификата (у меня есть одна система, разработанная таким образом, с десятками приложений, живущих во многих разных доменах .my-wildcard-cert-domain.com), то экземпляры "позади" ELB могут запускать обратный прокси, такой как HAProxy (или несколько других альтернатив, как Varnish), что может принимать решения о маршрутизации на уровне 7, а затем перенаправлять трафик на соответствующее подмножество машин позади них, что также обеспечивает более сложную балансировку нагрузки и имеет то преимущество, что предоставляет вам статистику и счетчики трафика. , агрегировать и разделять.
/-- HAProxy \ /----- instances hosting app #1
ELB ---| >> ----- instances hosting app #2
\-- HAProxy / \----- instances hosting app #n
Промежуточные экземпляры ^^^^ могут оценивать заголовки Host: (среди прочего) и даже записывать значение cookie сеанса в свои журналы для анализа.
Эта установка также позволяет мне запускать несколько приложений в перекрывающихся подмножествах экземпляров, где это необходимо, и делать много других вещей, которые сам по себе ELB не поддерживает напрямую. Он также возвращает настраиваемую страницу «503» в случае, если приложение перегружается или становится недоступным по иным причинам, чего не делает ELB самостоятельно. Я' Я изобразил здесь 2 прокси-сервера без какой-либо особой причины, кроме вашего упоминания цифры 2 в вопросе. На самом деле у меня их три, по одному на каждую зону доступности в регионе, где он развернут.
В вашем списке экземпляров ec2 вы видите два экземпляра, верно? Но в каждом случае у вас много веб-приложений? Вы используете виртуальный хост для развертывания каждого из них?
Вам нужен только один ELB, чтобы разделить расходы на ваши хосты. Пример:
External request > ELB (based on CNAME pointer) > EC2 Instance.
Думаю, лучше расскажите мне подробнее о своем сценарии, и, возможно, я смогу вам помочь.
С уважением.
ОБНОВЛЕНИЕ
Если у вас есть разные веб-приложения на экземплярах EC2, вам необходимо иметь два эластичных балансировщика нагрузки (ELB). Каждый по паре экземпляров. Всего четыре экземпляра
По состоянию на август 2016 года Amazon ELB предлагает два различных типа балансировщиков нагрузки:
- Classic Load Balancer маршрутизирует весь трафик к одному набору экземпляров без учета содержимого протокола приложения. Ранее это был единственный доступный тип ELB.
- Балансировщик нагрузки приложений может маршрутизировать трафик к различным целевым группам в соответствии с настраиваемыми правилами, основанными на путях URL. В посте блога New - AWS Application Load Balancer упоминает приложения, состоящие из нескольких микросервисов в качестве основного варианта использования, и дает подробные инструкции по настройке.
Для вашего варианта использования, Balad Load Balancer кажется идеальным. Однако он ограничен 10 правилами, поэтому будет легко работать только в том случае, если ваш N не больше 10.