Является ли ELB дренирующим tcp?

Question

У меня возникла интересная проблема. Мы запускаем приложение на основе HTTPS, основанное на состоянии. Состояние поддерживается на основе cookie сеанса. Приложение спроектировано таким образом, что если сеанс прерывается, приложение возвращается на главный экран, все потерянные данные теряются. Поэтому для нас очень важно поддерживать сеанс.

В прошлом было принято решение использовать службы AWS для этой цели, а в текущей архитектуре есть ELB, который балансирует нагрузку до группы автоматического масштабирования. В первой используемой архитектуре был включен личный сеанс на основе HTTP. Во время тестирования выясняется, что при уменьшении существующих сеансов немедленно закрываются и перенаправляются в доступные экземпляры. Это происходит даже после включения слива (время из 5 минут), которое в соответствии с документами должно помешать этому. Может кто-нибудь, пожалуйста, скажите мне, что мы делаем неправильно, и так оно и должно работать?

Мой второй вопрос: мы выяснили, что это не тот случай, когда использование ELB используется для балансировки нагрузки на основе соединений tcp. В этом случае, когда мы масштабируем старые tcp-соединения, поддерживаются до тех пор, пока они не будут закрыты или не будут отключены, а новые соединения будут перенаправлены в другие экземпляры. Это текущая настройка, которую мы используем. Поэтому мой вопрос заключается в том, почему ELB ведет себя по-разному в обоих случаях и есть ли способ сделать ELB использовать HTTP-липкую сессию и утечку на основе tcp-соединения?

Если у вас есть ответ, поделитесь информацией о конфигурации. Благодарю.

Answer 1

Относительно вопроса №1 - это ожидаемое поведение слива соединения ELB.

Из документа: «Соединительный слив заставляет балансировку нагрузки ELB прекратить отправку новых запросов на экземпляр отмены регистрации или нездоровый экземпляр при сохранении существующих соединений. Это позволяет балансировщику нагрузки выполнять запросы на рейс, сделанные для отмену регистрации или нездоровые случаи ». http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#conn-drain

ELB не знает о вашем состоянии сеанса, так как это управляется вашим приложением. Соединение сливается только на уровне сети. Если нет открытого подключения к вашему экземпляру, ELB может выбрать ваш экземпляр для отмены регистрации из AutoScaling (и автоматическое масштабирование позже прекратит его)

Вопрос №2: При использовании режима TCP на балансировщике нагрузки, понять содержимое HTTP (например, cookie) и с радостью отправить что-либо полученное от клиента на серверы. Поведение, которое вы экспериментируете, может быть связано с тем, как браузер клиента управляет соединениями (т. Е. Поддерживает открытое соединение). Это необходимо проверить с помощью инструмента веб-разработки.

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

Подробная информация доступна здесь http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingGroupLifecycle.html http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/lifecycle-hook-considerations.html