Как правильно выполнить эту балансировку нагрузки?

Или возможно, что балансировщик нагрузки передает запросы машинам №2, №3, ..., №6, а затем они отвечают клиентам напрямую, не проходя через машину №1 для ответов?

Да, это называется балансировкой нагрузки «Прямой возврат», и любой приличный балансировщик нагрузки L4 сможет это сделать.

Вы уверены, что что-то вроде http://www.haproxy.org/ не сможет обрабатывать трафик от 200+ клиентов? Прочтите это, например: http://www.haproxy.org/#perf .

Фактически все, что ему нужно сделать, это направить трафик TCP / IP на конкретную машину и обратно. С точки зрения ЦП это не очень дорого, за исключением действительно огромного количества подключений. Меня больше беспокоит емкость сетевого контроллера, и вам также нужно помнить о таких вещах, как максимальное количество открытых файлов и т. Д., Которые могут негативно повлиять на обработку сетевого трафика. Похоже, что тщательная настройка сетевого стека важнее мощности HAProxy:

Все эти микрооптимизации приводят к очень низкой загрузке ЦП даже при умеренных нагрузках. И даже при очень высоких нагрузках, когда ЦП перегружен, довольно часто встречаются такие цифры, как 5% пользователей и 95% системы, что означает, что процесс HAProxy потребляет примерно в 20 раз меньше, чем его системный аналог. Это объясняет, почему настройка операционной системы очень важна.

Единственная машина, работающая в качестве балансировщика нагрузки, является узким местом. Ты должен посмотреть на Циклический DNS (вторая ссылка) aka DNS Load Balancing. Это не очень надежно, ваши машины не будут загружены равномерно, но каждая машина должна получить определенную нагрузку.

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

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

Я только что нашел потенциальные решения этой проблемы, вот как это происходит:

Решение 1

• Браузер клиента подключается к example.com, т.е. после разрешения DNS, на сервер №1 (203.2.113.1)

• Сервер №1 смотрит, какая из машин №2, №3, ..., №6 доступна, скажем, №5 имеет наименьшую нагрузку на данный момент и может выполнять эту работу.

• Сервер №1 отправляет клиенту HTTP-ответ: yourworker=203.2.113.5 или yourworker=worker5.example.com

• Клиент получает это и знает теперь он должен подключиться 203.2.113.5 или worker5.example.com (через AJAX / XMLHttpRequest) для получения видеопотока.

Таким образом, видеотрафик никогда не проходит через балансировщик нагрузки машина №1, которая отправляет всего несколько байтов (yourworker=...) для каждого клиента в начале, то есть больше нет узких мест.

Единственная потенциальная проблема: если браузер загрузил страницу http://example.com от 203.2.113.1, может ли он выполнять AJAX / XHR до 203.2.113.5 или worker5.example.com для получения видеопотока, или он будет отклонен как CORS?

Изменить: протестировано, работает. Работает, если включить Access-Control-Allow-Origin, пример с Apache .htaccess (можно поставить более точный контроль, но здесь для теста это нормально):

Header set Access-Control-Allow-Origin "*"

Решение 2

Другое более простое решение: не может балансировщик нагрузки №1 просто проанализировать, какая машина №2, №3, ..., №6 доступна, и отправить это взамен клиенту:

<?php
$i = which_worker_available();
header('Location: https://worker' . $i . '.example.com/');
?>

?

затем весь остальной трафик никогда больше не будет проходить через балансировщик нагрузки. Больше никаких узких мест.

Проблема здесь: URL-адрес, отображаемый в браузере клиента, изменится с https://example.com к https://worker5.example.com что не очень приятно для конечного пользователя.

Изменить: протестировано, работает (но действительно URL-адрес в строке браузера изменяется с http://example.com к http://worker5.example.com/ ...)