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