ELB кросс-AZ балансировки разрешения DNS с сессией

Question

Я готовлюсь к сертификации AWS и натолкнулся на вопрос об ELB с включенной липкой сессией для экземпляров в 2 AZ.Проблема в том, что запросы от программного тестера нагрузки в одной из АЗ заканчиваются в тех случаях, когда только АЗ, а не распределяются по АЗ.В то же время регулярные запросы клиентов равномерно распределяются по АЗ.Правильные ответы для решения проблемы нагрузочного тестера:

• Принудительный программный тестер нагрузки повторно разрешает DNS перед каждым запросом;
• Используйте стороннюю службу нагрузочного тестирования дляотправлять запросы от глобально распределенных клиентов.

Я не уверен, что могу понять этот сценарий.Каково поведение по умолчанию маршрута 53, когда дело доходит до разрешения IP ELB?В любом случае, эти записи DNS имеют TTL 60 секунд.Разве это не избыточно для повторного разрешения DNS при каждом запросе?Кроме того, разрешение DNS является обязанностью самой службы DNS, а не программного обеспечения для нагрузочного тестирования, не так ли?Я могу понять, что запросы из того же экземпляра с программным обеспечением для нагрузочного тестирования будут отправляться на тот же LBed EC2, но почему это должен быть экземпляр в том же AZ?Этого можно достичь только с помощью маршрутизации на основе геолокации или задержки, но я не могу найти в спецификации ничего, являются ли они стандартными.

Answer 1

Когда ELB находится в нескольких зонах доступности, у него всегда есть несколько общедоступных IP-адресов - по крайней мере, один на зону.

Когда вы запрашиваете эти записи в поиске DNS, вы получаете всеиз этих записей (при условии, что их не очень много) или их подмножество (если их много, как в активном кластере со значительным трафиком), но они неупорядочены.

Еслипрограммное обеспечение для нагрузочного тестирования разрешает IP-адрес конечной точки и удерживает ровно один из IP-адресов - поскольку это вероятный результат - тогда весь трафик пойдет на один узел балансировщика, который находится в одной зоне, и будетотправьте трафик экземплярам в этой зоне.

А как насчет ...

Межзональная балансировка нагрузки

Узлы для вашегоРаспределитель нагрузки распределяет запросы от клиентов к зарегистрированным целям.Когда балансировка нагрузки между зонами включена, каждый узел балансировки нагрузки распределяет трафик по зарегистрированным целям во всех включенных зонах доступности.Когда межзонная балансировка нагрузки отключена, каждый узел балансировки нагрузки распределяет трафик по зарегистрированным целям только в своей зоне доступности.

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

Если настроена привязка, эти сеансыпервоначально приземлится в одном AZ, а затем будет придерживаться этого AZ, потому что они придерживаются первоначального экземпляра, в котором они приземлилисьЕсли кросс-зона включена, результат не совсем ясен, но либо узлы балансировщика могут предпочесть экземпляры в их собственной зоне в этом сценарии (при первом установлении липкости), либо это не было вопросом вопроса.Липкость требует координации, и трафик между AZ занимает ненулевое количество времени из-за расстояния (обычно <10 мс), но для балансировщика имеет смысл выбрать экземпляры своей локальной зоны для сеансов без установленного сходства. </p>

На самом деле, настройка программного обеспечения для нагрузочного теста для повторного разрешения конечной точки для каждого запроса на самом деле не является целью решения - важно убедиться, что (1) нагрузочное тестированиепрограммное обеспечение использует их все и не привязывается к одному и (2) что, если из-за масштабирования балансировщика под нагрузкой становится доступным больше адресов, программное обеспечение для нагрузочного тестирования расширяет свой пул целей.

В любом случае, эти записи DNS имеют TTL 60 секунд.Разве не является избыточным повторное разрешение DNS при каждом запросе?

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

Кроме того, разрешение DNS является обязанностью самой службы DNS, а не программного обеспечения для нагрузочного тестирования, не так ли?

Чтобы "разрешить DNS" в этом контексте простоозначает выполнить поиск DNS, что бы это ни значило в конкретном случае, будь то использование DNS-преобразователя ОС или прямой запрос к рекурсивному DNS-серверу.Когда программное обеспечение устанавливает соединение с именем хоста, оно "разрешает" (ищет) соответствующий IP-адрес.

Другое решение, ", использует стороннюю службу тестирования нагрузки для отправки запросов от глобально распределенных клиентов., " решает проблему случайно, поскольку распределенные клиенты - даже если они придерживаются первого увиденного ими адреса - с большей вероятностью увидят все доступные адреса.«Глобальный» аспект распределения отвлекает.

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

Answer 2

Только что нашел другое доказательство того, что Route 53 возвращает несколько IP-адресов и поворачивает их для сценариев масштабирования ELB:

По умолчанию Elastic Load Balancing возвращает несколько IP-адресов, когда клиенты выполняют разрешение DNS,с записями в случайном порядке по каждому запросу разрешения DNS.При изменении профиля трафика служба контроллера будет масштабировать балансировщики нагрузки для обработки большего количества запросов, масштабируя одинаково во всех зонах доступности.

А затем:

Чтобы гарантировать, чтоклиенты используют преимущества увеличенной емкости, Elastic Load Balancing использует настройку TTL для записи DNS в течение 60 секунд.Очень важно, чтобы вы включили эту изменяющуюся запись DNS в свои тесты.Если вы не гарантируете, что DNS будет повторно разрешен, или используете несколько тестовых клиентов для моделирования повышенной нагрузки, тест может продолжить попадание на один IP-адрес, когда Elastic Load Balancing фактически выделил намного больше IP-адресов.

Поначалу я не осознавал, что даже если регулярный трафик распределяется равномерно по AZ, это не означает, что межзональная балансировка нагрузки включена.Как отметил Майкл, регулярное движение будет проходить через различные места и заканчиваться в разных зонах.И поскольку это не было явно упомянуто в тесте, балансировка Cross-AZ, возможно, не была на месте.

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/

Answer 3

Проблема связана с проблемой, см. Здесь: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Балансировщик нагрузки использует специальный файл cookie, чтобы связать сеанс с экземпляром, который обработал первоначальный запрос, но следует за временем жизниcookie-файл приложения, указанный в конфигурации политики.Балансировщик нагрузки вставляет новый cookie-файл привязанности только в том случае, если ответ приложения включает новый cookie-файл приложения.Файл cookie балансировки нагрузки не обновляется при каждом запросе.Если cookie-файл приложения явно удаляется или срок его действия истекает, сеанс перестает быть липким до тех пор, пока не будет выпущен новый cookie-файл приложения.

Первое решение для повторного разрешения DNS создаст новые сеансы и при этом прерветсялипкость ELB.Второе решение заключается в использовании нескольких клиентов, прилипание не является проблемой, если количество глобально распределенных клиентов велико.

ЧАСТЬ 2: не удалось добавить в качестве комментария, является длинным:

Да, мой ответ был простым и неполным.

Мы знаем, что ELB составляет 2 AZ и будет иметь 2 узла с разными IP.Не ясно, сколько IP, зависит от количества запросов и количества серверов на каждом AZ.Маршрут 53 вращает IP для каждого нового запроса, первый раз в NodeA-IP, NodeB-IP, второй раз - NodeB-IP, NodeA-IP.Приложение нагрузочного тестирования будет принимать с каждым новым запросом первый IP-адрес, балансируя между 2 AZ.Поскольку узел может маршрутизировать только внутри своего AZ, если липкий файл cookie предназначен для NodeA и запрос поступает в NodeB, NodeB отправит его на один из своих серверов в AZ2, игнорируя файл cookie для сервера в AZ 1.

Мне нужно выполнить несколько тестов, быстро протестированных с Route53 с классическим ELB и 2 AZ, и каждый раз вращается IP.То, что я хочу проверить, если у меня есть липкий файл cookie для AZ 1, и я достигаю Узла 2, не переадресует меня в Узел 1 (В случае отсутствия доступных серверов, в документации описан этот интересный поток).Надеюсь иметь обновления в короткие сроки.