Веб-розетки для збалансування навантаження

У мене питання про те, як завантажити балансові веб-розетки.

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

Традиційно, використовуючи лише запити HTTP, я би змістив масштаб, додавши другий сервер і балансир завантаження перед двома веб-серверами.

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

То як мені -

1. змусити клієнта підключитися безпосередньо до веб-сервера (а не балансира завантаження), коли сторінка завантажується? Чи просто я завантажую JavaScript з вузла, і балансири навантажень (чи що завгодно) довільно змінюють URL-адресу для сценарію кожного разу, коли сторінка спочатку запитується?

2. справлятися з пульсацією старту? Веб-браузер помітить, що з'єднання закрите, коли веб-сервер відключається. Я можу написати JavaScript-код, щоб спробувати відновити з'єднання, але вузол на деякий час не буде. Тож я думаю, мені доведеться повернутися до балансира навантаження, щоб запитати адресу наступного вузла, який потрібно використовувати?

3. Мені було цікаво, як балансири навантажень надсилають перенаправлення на початковий запит, так що браузер спочатку запитує www.mydomain.comі перенаправляється на www34.mydomain.com. Це працює досить добре, поки вузол не впаде - і такі сайти, як Facebook, не роблять цього. Як вони це роблять?

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

Також зауважте, що жорсткий обмеження 64k застосовується лише до вихідних TCP / IP для заданої (вихідної) IP-адреси. Це не стосується вхідних TCP / IP. Ми протестували Autobahn (високоефективний сервер WebSocket) з 200-ти активним підключенням на двох ядрах, 4 ГБ оперативної пам’яті.

Також зауважте, що ви можете виконати балансування навантаження L7 на шляху HTTP, оголошеному під час початкового рукостискання WebSocket. У такому випадку балансир завантаження повинен підтримувати стан (яке джерело IP-портової пари збирається до якого резервного вузла). Це, ймовірно, масштабує мільйони підключень, але при гідному налаштуванні.

Відмова: Я є оригінальним автором Autobahn і працюю в Tavendo.

Зауважте, що якщо ваша логіка сервера веб-сокет працює на 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/

Але в певний момент я думаю, що редис може стати вузьким місцем ...

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

Див. "Як перевірити та збалансувати трафік WebSockets за допомогою диспетчера трафіку Stingray, а за необхідності - як керувати WebSockets та HTTP-трафіком, що надходить на ту саму IP-адресу та порт". https://splash.riverbed.com/docs/DOC-1451