Зачем нужно указывать подсети в Application Load Balancer?
Начну с описания архитектуры Application Load Balancer:
У нас есть Application Load Balancer, который содержит список одного или нескольких слушателей. Каждый прослушиватель связан с одним конкретным портом и протоколом, поэтому трафик, поступающий на балансировщик нагрузки с этого порта, будет обрабатываться этим прослушивателем. Затем каждый слушатель содержит список правил. Правило определяет условия и действия — в основном, куда направлять трафик. Слушатель также должен иметь действие по умолчанию, которое будет выполнено, если не будет выполнено никакое другое условие. Обычно это действие заключается в перенаправлении трафика в определенную целевую группу.
Целевая группа — это группа экземпляров EC2, IP-адресов, другого балансировщика нагрузки приложений или функции Lambda.
Кроме того, когда вы создаете Application Load Balancer, он просит вас указать VPC и список из 2 или более зон доступности, а также для каждой указать подсеть.
Теперь мой вопрос: почему AWS просит вас указать это? Насколько я понимаю, целевые группы и зарегистрированные цели — это то, где вы указываете бэкэнд балансировщика нагрузки, так зачем нам указывать подсети в конфигурации ALB?
РЕДАКТИРОВАТЬ
Поэкспериментировав, я обнаружил, что если у меня есть инстанс EC2, на котором запущен веб-сервер, например, в AZ 3, а теперь я создаю балансировщик нагрузки и выбираю AZ 1 и 2, то трафик не будет достигать веб-сервера в AZ 3, пока я не добавьте еще одну АЗ в настройках балансировщика нагрузки.
Итак, если уточнить мой вопрос: если эта настройка зон доступности в настройках балансировщика нагрузки означает: это те АЗ, в которые балансировщик нагрузки будет отправлять трафик, в каком случае я не должен выбирать ВСЕ имеющиеся зоны доступности?
@ Паоло, не совсем, не очень понятно.
Что именно непонятно? Какие вопросы у вас остались?
Это просто очень коротко и не очень понятно. Вы можете расширить его и быть более детальным.
Возьмите ответ Джона Ротенштейна в качестве примера
Что вам еще непонятно?
Ваш вопрос был один, на который я ответил. Похоже, вы либо не поняли, что спросили, либо не поняли мой ответ.
Балансировщик нагрузки может направлять трафик только в выбранные вами зоны доступности, поскольку в каждой из этих зон он создал сетевой интерфейс. Без сетевых интерфейсов балансировщик нагрузки не может работать
Ответы 3
Когда вам нужен ALB, вы должны назначить ему IP-адрес. Подсеть — это не что иное, как диапазон IP-адресов. Размещая ALB внутри подсети, вы определяете, какой диапазон IP-адресов вы хотите назначить этому ресурсу. Более того, эти подсети позволяют настраивать различные уровни безопасности в отношении ресурса внутри подсети для управления трафиком.
Ваша целевая группа находится в другой подсети с другим диапазоном, тогда как вы можете поместить свой ALB в другую подсеть с другим диапазоном.
Я не спрашивал о подсети, в которой находится IP-адрес балансировщика нагрузки, я спрашивал о зонах доступности + подсетях серверной части, к которым он направляется.
Ааа, я думаю, что @john-rotenstein отвечает на вопрос
зачем нам указывать подсети в конфигурации ALB?
Поскольку самому балансировщику нагрузки требуются физические сетевые интерфейсы, которые создаются в указанных вами подсетях (по одному сетевому интерфейсу на подсеть).
Application Load Balancer работает в инфраструктуре Amazon EC2. Думайте об этом как об инстансе Amazon EC2 с предварительно загруженным программным обеспечением, но на самом деле вы не видите инстанс EC2 в своей учетной записи.
Вместо этого вы увидите сетевые интерфейсы, через которые Load Balancer подключается к сети.
Трафик будет поступать в вашу сеть через интернет-шлюз, а затем направляться внутри VPC к балансировщику нагрузки. Затем балансировщик нагрузки определит цель для получения трафика и отправит запрос через сетевой интерфейс на ресурс в VPC.
Когда такой трафик проходит через VPC, на него распространяются обычные группы безопасности и списки контроля доступа к сети (NACL). Частные IP-адреса будут назначены для каждого сетевого интерфейса, используемого балансировщиком нагрузки.
Экземпляр Load Balancer работает в нескольких зонах доступности. Если в одной зоне доступности произошел сбой, экземпляр Load Balancer в остальных зонах доступности продолжит работу. Вот почему балансировщику нагрузки требуется подключение к VPC в нескольких подсетях.
Итог: хотя обычно вы можете думать о балансировщике нагрузки как о «службе черного ящика», это все же просто какое-то программное обеспечение, работающее на виртуальном компьютере, которому требуется логическое подключение к VPC, и оно подчиняется всем правилам сети внутри VPC.
Если я вас правильно понял, вы говорите, что когда я выбираю несколько AZ + подсети, в каждой AZ-подсети будет выделен экземпляр балансировщика нагрузки для обеспечения высокой доступности. Но технически, если я выберу, например, зоны доступности 1 и 2 и свяжу этот балансировщик нагрузки с целевой группой с одной целью в зоне доступности 3, балансировщик нагрузки не будет направлять трафик. Таким образом, выбор зон доступности как-то связан с бэкэнд-целями.
Это кажется правильным. Из Как работает Elastic Load Balancing: «Когда вы включаете зону доступности для балансировщика нагрузки, Elastic Load Balancing создает узел балансировщика нагрузки в зоне доступности. Если вы регистрируете цели в зоне доступности, но не включаете зону доступности , эти зарегистрированные цели не получают трафик."
Однако я не понимаю, почему экземпляр балансировщика нагрузки может направлять трафик только к целям в своей собственной зоне доступности?
@yoavklein, потому что балансировщик нагрузки может маршрутизировать трафик только в зонах доступности, в которых он создал сетевой интерфейс.
Интересно, что Балансировщики сетевой нагрузки, похоже, способны доставлять межзональный трафик: «По умолчанию каждый узел балансировщика нагрузки распределяет трафик между зарегистрированными целями только в своей зоне доступности. Если вы включите балансировку нагрузки между зонами, каждый узел балансировщика нагрузки распределяет трафик между зарегистрированными целями во всех включенных зонах доступности».
@JohnRotenstein, на самом деле кажется, что балансировщики нагрузки приложений имеют межзональную балансировку нагрузки по умолчанию: в балансировщиках нагрузки приложений межзональная балансировка нагрузки всегда включена. При использовании балансировщиков сетевой нагрузки и балансировщиков нагрузки шлюза балансировка нагрузки между зонами отключена по умолчанию. После создания балансировщика нагрузки вы можете в любое время включить или отключить балансировку нагрузки между зонами.
Балансировка нагрузки между зонами позволит направлять трафик в другую зону, но цитата «Как работает эластичная балансировка нагрузки» предполагает, что цели будут получать трафик только в зонах, которые «включены». Я предлагаю вам провести некоторый мониторинг, чтобы убедиться, что все экземпляры получают трафик.
@JohnRotenstein, последний вопрос, если хотите: есть ли у меня причина не включать балансировщик нагрузки во всех зонах доступности? Есть ли какое-то рассмотрение стоимости?
О, интересный вопрос! Цена , похоже, полностью связана с количеством подключений и обработанных байтов. Таким образом, больше AZ, кажется, не стоит больше. Однако вы можете захотеть добавить его только в зоны доступности, где у вас есть цели, потому что балансировщик нагрузки может отправлять трафик в зону доступности, который затем отправляется в цель в другой зоне доступности. За трафик между зонами доступности взимается плата в размере 1 цента/ГБ, поэтому это может стоить денег без особой выгоды. Я не уверен, что балансировщик нагрузки достаточно умен, чтобы избежать такого поведения, но выбор за вами!
Мой ответ сработал для вас?