Есть ли предложения о том, когда мне следует использовать roundrobin и когда мне следует использовать leastconn?
Я использую roundrobin в настоящее время и наблюдается, что загрузка моего внутреннего сервера не распределяется равномерно. Конечно, может быть и другая проблема, но мы хотим дать leastconn попытка, но, поскольку это критически важный сервер, я хочу проконсультироваться с другим опытом, прежде чем вносить изменения.
Есть идеи поделиться?
Я не экспериментировал с минимальным подключением, но, насколько я понимаю, типичный вариант использования минимального подключения - это когда вы балансируете нагрузку на то, что может иметь долгоживущие соединения. Причина этого в том, что меньше всего внимания уделяется обеспечению сбалансированного параллелизм где, как и в случае с роуд-робином, будет скорость прибытия. Если это различие неясно, посмотри мой ответ о разнице.
Когда вы говорите, что нагрузка распределяется неравномерно, это может помочь немного лучше определить «нагрузку». Если вы имеете в виду ресурсы сервера, я предлагаю определить, что именно вызывает повышенную нагрузку (например, определенные типы соединений), и работать в обратном направлении.
Это зависит от протокола и варианта использования для балансировки. Для всего, где количество подключений коррелирует с нагрузкой / использованием, лучше использовать leastconn. Из-за того, как работают сети и приложения, это почти всегда верно, и вам лучше использовать leastconn по умолчанию.
Например, у компании есть пул удаленных рабочих столов, к которым подключаются сотрудники. Вы хотите, чтобы сотрудники были равномерно распределены по рабочим столам.
Количество активных подключений в этом варианте использования примерно равно «сколько сотрудников используют этот рабочий стол прямо сейчас». На хосте с наименьшим количеством подключений меньше всего его используют сотрудники и, вероятно, он наименее загружен. В таких случаях используйте команду "leastconn", она равномерно распределяет нагрузку по количеству пользователей.
Идеальный балансировщик нагрузки должен учитывать нагрузку на удаленный рабочий стол. Сколько пользователей? Сколько приложений? Сколько потребляется памяти и процессора? Существуют коммерческие решения, предназначенные для удаленных рабочих столов (Microsoft / Citrix / и т. Д.), Они обычно измеряют эти показатели, чтобы очень хорошо распространять использование. HAProxy - это простой балансировщик сетевой нагрузки, и он не может лучше, чем подсчет подключений с leastconn.
В случае HTTP активное соединение означает, что сервер занят обработкой запроса. Подключения прямо пропорциональны нагрузке. Вы хотите выбрать сервер с наименьшим количеством активных подключений (выполняемых запросов). Использовать leastconn для HTTP (S) трафика.
Представьте себе сценарий с двумя HTTP-серверами, где один сервер медленнее обрабатывает запросы (возможно, он перегружен, возможно, у него более старое оборудование).
roundrobin распределяет половину запросов между двумя серверами. Это очень неэффективно, более быстрый сервер должен занять больше. Что еще хуже, более медленный сервер может быть перегружен, он станет еще медленнее по мере поступления новых запросов и может начать отбрасывать запросы в любое время. Вы этого не хотите.
leastconn обнаружит, что серверы работают неравномерно. Более медленный сервер удерживает соединения дольше, у него большее количество соединений. leastconn учитывает это и предпочитает другой сервер.
По моему опыту, включая роли, в которых я проводил исключительно тестирование производительности для средних и крупных веб-сайтов. leastconn может быть на 300% эффективнее, чем roundrobin для HTTP (S). roundrobin не распределяет соединение справедливо и вызовет нестабильность при высокой нагрузке.
(Давайте проигнорируем, что HAProxy не поддерживает UDP, а UDP не поддерживает соединение).
И последний пример. DNS - это простой протокол. Клиенты отправляют одно сообщение UDP для запроса домена, а DNS-сервер отвечает одним сообщением.
В этом случае связи на самом деле нет. Даже если бы были, то сразу закрыли бы (теоретически).
Считать связи в таких условиях не имеет смысла, это не оптимально для leastconn. Простой roundrobin может распространять сообщения.
Иногда люди считают, что не следует использовать leastconn для короткоживущих соединений (аналогично последнему примеру). Даже документация HAProxy вводит в заблуждение по этому поводу.
leastconn
Use of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP.
[misleading advice, should ignore it]
В реальном мире, short connections это не вещь.
Приложения построены на основе TCP. Сообщения доставляются и часто обрабатываются по порядку. Когда сервер работает медленно или перегружен, «короткие» соединения становятся длиннее. Если есть (больше) соединений, вероятно, есть (больше) работа. Количество подключений и продолжительность подключения различаются и имеют значение.
Представьте себе простой HTTP-сервер. Некоторые ресурсы занимают несколько миллисекунд, некоторые вызовы API - несколько секунд, страница может занять любое время для загрузки с любым количеством запросов внутри нее и т. Д. Запросы не являются краткосрочными, их время жизни зависит от того, что обрабатывается на каком сервере. leastconn понимает текущую активность и корректирует распределение, а это именно то, что вы хотите от балансировщика нагрузки.