Разъем для балансировки нагрузки

У меня вопрос о том, как загрузить балансировочные сокеты.

У меня есть сервер, который поддерживает сетевые сокеты. Браузеры подключаются к моему сайту, и каждый открывает веб-сокет на www.mydomain.com. Таким образом, мое приложение в социальной сети может отправлять сообщения клиентам.

Традиционно, используя только HTTP-запросы, я бы увеличил добавление второго сервера и балансировки нагрузки перед двумя веб-серверами.

С веб-сокетами соединение должно быть напрямую с веб-сервером, а не с балансировщиками нагрузки, потому что, если у машины есть физический предел, скажем, 64k открытых портов, и клиенты подключаются к балансировщику нагрузки, тогда я мог бы 't поддерживает более 64 тыс. одновременных пользователей.

Итак, как я -

заставить клиента подключаться непосредственно к веб-серверу (а не к балансировщику нагрузки) при загрузке страницы? Я просто загружаю JavaScript из node, а балансировки нагрузки (или что-то другое) случайным образом изменяет URL-адрес для script, каждый раз, когда страница изначально запрашивается?
обрабатывать старт пульсации? Браузер заметит, что соединение закрывается, когда веб-сервер отключается. Я могу написать код JavaScript, чтобы попытаться повторно открыть соединение, но node исчезнет некоторое время. Поэтому, я думаю, мне нужно будет вернуться к балансировщику нагрузки, чтобы запросить адрес следующего node для использования?
Я действительно задавался вопросом о балансировщиках нагрузки, отправляющих перенаправление по первоначальному запросу, так что браузер первоначально запрашивает www.mydomain.com и перенаправляется на www34.mydomain.com. Это работает очень хорошо, пока не будет node, и сайты, подобные Facebook, этого не делают. Как они это делают?

Ответ 1

Поместите балансировщик нагрузки L3, который распределяет IP-пакеты на основе хеша источника-IP-порта для вашей фермы серверов WebSocket. Поскольку балансировщик L3 не поддерживает состояние (используя хешированный источник-IP-порт), он будет масштабироваться до скорости передачи на низкоуровневом оборудовании (например, 10GbE). Поскольку распределение детерминировано (с использованием хэшированного источника-IP-порта), он будет работать с TCP (и, следовательно, с WebSocket).

Также обратите внимание, что жесткий предел 64k применяется только к исходящему TCP/IP для заданного (исходного) IP-адреса. Он не применяется к входящему TCP/IP. Мы протестировали Autobahn (высокопроизводительный сервер WebSocket) с активными соединениями 200k на 2-х ядерном RAM объемом 4 ГБ.

Также обратите внимание, что вы можете выполнять балансировку нагрузки L7 по пути HTTP, объявленному во время первоначального подтверждения WebSocket. В этом случае балансировщик нагрузки должен поддерживать состояние (какая пара IP-порта источника идет на бэкэнд node). Вероятно, он будет масштабироваться до миллионов подключений, несмотря на приличную настройку.

Отказ от ответственности: я являюсь оригинальным автором Autobahn и работаю в Tavendo.

Ответ 2

Существуют также альтернативные подходы, такие как балансировка нагрузки на основе DNS или использование сервера оркестровки на основе http. Я попытался суммировать верхние и нижние стороны каждого подхода на https://deepstream.io/blog/load-balancing-websocket-connections/

Ответ 3

Вы также можете добиться балансировки нагрузки уровня 7 с помощью проверки и "функции маршрутизации"

См. "Как проверять и балансировать трафик WebSockets трафика с помощью Stingray Traffic Manager и, при необходимости, управлять WebSockets и HTTP-трафиком, полученным на одном и том же IP-адресе и порту". https://splash.riverbed.com/docs/DOC-1451

Ответ 4

Обратите внимание, что если ваша логика сервера websocket работает на nodejs с socket.io, вы можете сказать, что socket.io использует общий ключ для ключей/значений для синхронизации. Таким образом, вам даже не нужно заботиться о балансировщике нагрузки, события будут распространяться среди экземпляров сервера.

var io = require('socket.io')(3000);
var redis = require('socket.io-redis'); 
io.adapter(redis({ host: 'localhost', port: 6379 }));

Смотрите: http://socket.io/docs/using-multiple-nodes/

Но в какой-то момент я думаю, что redis может стать узким местом...