Я исследовал различные алгоритмы балансировки нагрузки для HTTP и только что нашел 3. Случайный, циклический и взвешенный циклический. Есть ли другие варианты?
Спасибо Пол
Наиболее распространенные алгоритмы балансировки нагрузки для балансировщиков нагрузки HTTP - это IMHO:
По-круговой (иногда называется «Далее в цикле»).
Взвешенный круговой алгоритм - как Round Robin, но некоторые серверы получают большую долю от общего трафика.
Случайный.
Исходный IP хэш. Подключения распределяются между внутренними серверами на основе исходного IP-адреса. Если веб-узел выходит из строя и выводится из эксплуатации, распределение изменяется. Пока все серверы работают с данным IP-адресом клиента, он всегда будет обращаться к одному и тому же веб-серверу.
URL хэш. Подобно хешу исходного IP-адреса, за исключением того, что хеширование выполняется для URL-адреса запроса. Полезно при балансировке нагрузки перед кешами прокси, поскольку запросы для данного объекта всегда будут поступать только в один внутренний кеш. Это позволяет избежать дублирования кэша, поскольку один и тот же объект хранится в нескольких / всех кэшах, и увеличивает эффективную емкость внутренних кешей.
Наименьшее количество связей, взвешенное наименьшее количество соединений. Балансировщик нагрузки отслеживает количество открытых подключений для каждого сервера и отправляет их на наименее загруженный сервер.
Наименьший трафик, наименьшее количество трафика. Балансировщик нагрузки отслеживает битрейт с каждого сервера и отправляет его на сервер с наименьшим исходящим трафиком.
Наименьшая задержка. Perlbal делает быстрый HTTP-запрос OPTIONS к внутренним серверам и отправляет запрос первому серверу для ответа.
Возможно, приведенные выше алгоритмы не являются алгоритмами в строгом смысле компьютерных наук, это более общие описания общих подходов. Вот небольшой документ от Cisco, в котором описаны некоторые из алгоритмы, которые они используют более подробно. Реализации от других поставщиков будут немного отличаться.
Есть крайние случаи, когда полезны более экзотические алгоритмы - например, потоковое видео может хорошо подойти «с минимальным трафиком». Но, вообще говоря, для большинства веб-приложений и веб-сайтов оптимальным решением является:
А общая / распределенная система сеансов, так что любой веб-узел может ответить на любой запрос пользователя (т. е. данные сеанса пользователя, такие как файлы cookie сеанса, одинаково доступны для всех серверов).
Балансировка нагрузки с использованием По-круговой (необязательно взвешенный круговой алгоритм) или случайный распространение. Round Robin и Random - это простые и устойчивые алгоритмы без каких-либо проблем с «горячими точками», то есть распределение нагрузки по бэкэндам остается справедливым во всех ситуациях.
Вопрос неполный:
Балансировка нагрузки ЧТО?
Процессоры могут перегружаться; обычная перспектива обратная - толкать ресурс вместо того, чтобы тянуть к нему.
На дисках нужно сбалансировать множество различных нагрузок, таких как пространство, скорость чтения, скорость записи, пропускная способность и т. Д.
Сети могут быть сбалансированы по нагрузке на основе задержки или общей пропускной способности ...
Люди могут быть сбалансированы по нагрузке на основе индивидуальных возможностей; одни хорошо справляются с несколькими задачами, другие - нет, а есть качество и количество. Вы можете оптимизировать свои человеческие ресурсы на основе множества факторов и с разным весом, присвоенным разным атрибутам.
Вышеизложенное далеко не исчерпывающе; Дело в том, что разные ресурсы требуют совершенно разных видов балансировки нагрузки. Из их доступных атрибутов и возможностей вы должны указать, какие из них интересны для балансировки.
То, что вы пытаетесь сбалансировать, является первым критерием в создании хорошего алгоритма балансировки. И предположение, что их всего три ... непонятно. Было бы достойно получить степень доктора философии, если бы он постарался описать все способы «уравновешивания нагрузок».
RT
Не прямой ответ на ваш вопрос, а реальное решение, которое мы сочли полезным. Используя LVS и демон pulse, наша балансировка нагрузки HTTP настроена на вызов специального сценария bash, который определяет нагрузку на «реальные серверы» через простое соединение SSH и вызов время безотказной работы.
Затем на основе средней нагрузки серверов устанавливается весовой коэффициент для каждого сервера. Не самый научный подход, поскольку средняя загрузка не обязательно указывает на HTTP-соединения или загрузку процессора, вызванную этими соединениями. Тем не менее, мы достигли удивительно эффективных результатов.
Мой 2c. YMMV.
PS: взгляните на LVS проект - вы обязательно найдете информацию о реализациях планирования балансировки нагрузки.