Балансировщик нагрузки Aws для событий, отправленных сервером, или веб-сокетов
Я пытаюсь сбалансировать нагрузку на бэкэнд события, отправленного сервером nodejs, и мне нужно знать, есть ли способ распределить новые подключения к экземплярам с наименее подключенными клиентами. Проблема, с которой я сталкиваюсь, заключается в том, что при масштабировании маршрутизация продолжает отправлять новые соединения к уже насыщенному экземпляру, и, поскольку соединения существуют долго, это просто не сработает.
Какие варианты у меня есть для горизонтального масштабирования долгоживущих соединений?
Ответы 2
Поскольку вы используете AWS, я бы рекомендовал Эластичный бобовый стебель для развертывания вашего приложения Node.js. Официальная документация содержит хорошие примеры, такие как Вот этот. Обратите внимание, что Beanstalk будет автоматически создать Elastic Load Balancer для вас, что вам и нужно.
By default, Elastic Beanstalk creates an Application Load Balancer for your environment when you enable load balancing with the Elastic Beanstalk console or the EB CLI. It configures the load balancer to listen for HTTP traffic on port 80 and forward this traffic to instances on the same port.
[...]
Note: Your environment must be in a VPC with subnets in at least two Availability Zones to create an Application Load Balancer. All new AWS accounts include default VPCs that meet this requirement. If your environment is in a VPC with subnets in only one Availability Zone, it defaults to a Classic Load Balancer. If you don't have any subnets, you can't enable load balancing.
Обратите внимание, что настройка правильного пути проверки работоспособности является ключом к правильной балансировке запросов, как вы упомянули в своем вопросе.
In a load balanced environment, Elastic Load Balancing sends a request to each instance in an environment every 10 seconds to confirm that instances are healthy. By default, the load balancer is configured to open a TCP connection on port 80. If the instance acknowledges the connection, it is considered healthy.
You can choose to override this setting by specifying an existing resource in your application. If you specify a path, such as /health, the health check URL is set to HTTP:80/health. The health check URL should be set to a path that is always served by your application. If it is set to a static page that is served or cached by the web server in front of your application, health checks will not reveal issues with the application server or web container.
Обновлено: Если вы ищете липкие сеансы, как я описал в комментариях, выполните шаги, указанные в это руководство:
To enable sticky sessions using the console
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under LOAD BALANCING, choose Target Groups.
Select the target group.
On the Description tab, choose Edit attributes.
On the Edit attributes page, do the following:
a. Select Enable load balancer generated cookie stickiness.
b. For Stickiness duration, specify a value between 1 second and 7 days.
c. Choose Save.
Вы ищете механизм «липких сессий»? В идеале для лучшей масштабируемости следует отказаться от сохранения состояния.
Похоже, вам нужен балансировщик нагрузки, который может предоставлять как «закрепленные сеансы», так и использовать «наименьшее количество подключений» вместо политики «циклического перебора». К сожалению, NGINX не может этого обеспечить.
HAProxy (High Availability Proxy) позволяет это:
backend bk_myapp
cookie MyAPP insert indirect nocache
balance leastconn
server srv1 10.0.0.1:80 check cookie srv1
server srv2 10.0.0.2:80 check cookie srv2
Если вам нужна функциональность ELB и вы хотите накатить все это вручную, взгляните на этот руководство.
Вы также можете убедиться, что классическая «закрепленная сессия» AWS ELB конфигурация или более новая опция ALB "липкая сессия" не соответствуют вашим потребностям. ELB обычно отправляет соединение на вышестоящий сервер с наименьшей «нагрузкой», и в сочетании с липкими сессиями может быть достаточно.
Да я посмотрю на это. Прилепленные сеансы работают нормально, и я использую Redis для обмена состоянием между узлами. Статья о конфигурации посвящена классическому балансировщику нагрузки, который я собирался удалить из aws.
Это работает с классическим балансировщиком нагрузки, однако теперь события закрытия от клиента не доходят до серверной части.
Я использую Beanstalk. Мой вопрос заключается в том, как настроить маршрутизацию к экземплярам, чтобы они не перегружали один экземпляр. Соединения сохраняются и могут длиться часами. В настоящее время он использует циклический перебор для распределения новых запросов, и это не сработает.