Я досліджував різні алгоритми балансування навантаження для HTTP, і я щойно знайшов 3. Випадковий, Круглий Робін та Зважений Круглий Робін. Чи є інші варіанти?
Спасибі Пол
Я досліджував різні алгоритми балансування навантаження для HTTP, і я щойно знайшов 3. Випадковий, Круглий Робін та Зважений Круглий Робін. Чи є інші варіанти?
Спасибі Пол
Відповіді:
Найпоширенішими алгоритмами балансування навантаження для балансирів навантаження HTTP є IMHO:
Круглий Робін (іноді його називають "Далі в циклі").
Зважений Round Robin - як Round Robin, але деякі сервери отримують більшу частку в загальному трафіку.
Випадкові .
Джерело IP хеша. З'єднання поширюються на сервери, що базуються на основі вихідної IP-адреси. Якщо веб-вузол виходить з ладу і виходить із служби, розподіл змінюється. Поки всі сервери працюють із заданою IP-адресою клієнта, він завжди переходитиме на той самий веб-сервер.
URL- хеш. Так само, як джерело хешу IP, за винятком хешування, робиться за URL-адресою запиту. Корисно під час завантаження балансування перед кешами проксі, оскільки запити для певного об'єкта завжди перейдуть до лише одного кеш-пам'яті. Це дозволяє уникнути дублювання кешу, якщо один і той же об'єкт зберігається в кількох / всіх кешах, і збільшує ефективну ємність резервних кеш-пам'яток.
Найменші з'єднання , найменш зважені з'єднання. Балансир навантаження відстежує кількість відкритих підключень для кожного сервера та надсилає на сервер з найменшою зайнятістю.
Найменший трафік , найменше зважений рух. Балансир навантаження відстежує бітрейт з кожного сервера і відправляє на сервер, який має найменший вихідний трафік.
Найменша затримка . Perlbal робить швидкий HTTP OPTIONS запит на бекенд-сервери та надсилає запит на перший сервер для відповіді.
Напевно, вищезгадані - це не алгоритми в суворому розумінні інформатики, це більш загальні описи загальних підходів. Ось один невеликий папір від Cisco, який детальніше описує деякі алгоритми, які вони використовують . Реалізація від інших постачальників буде дещо відрізнятися.
Існують крайні випадки, коли корисніші екзотичні алгоритми є корисними - наприклад, потокове відео може добре піддатися «мінімуму трафіку». Але, загалом кажучи, для більшості веб-додатків та веб-сайтів оптимальним є рішення:
Загальний / розподілена система сеансу , так що будь-який Webnode може відповісти на будь-який запит користувача (наприклад , призначені для користувача дані сеансу , такі як сесійні куки однаково доступні для всіх серверів).
Балансування завантаження використовуючи Round Robin (необов'язково зважений круглий Robin) або випадкове розподіл. Раунд Робін і Рандом - це прості та стійкі алгоритми без будь-яких проблем з «гарячою точкою», тобто розподіл навантаження на бакендекси залишається справедливим у будь-яких ситуаціях.
Питання неповне:
ШАГА ЗАБЕЗПЕЧЕННЯ ЩО?
Процесори можуть сприймати насичення; звичайна перспектива назад - натискання на ресурс, а не тягнення до нього.
Диски мають багато різних навантажень для балансування, наприклад, простір, швидкість читання, швидкість запису, пропускну здатність тощо.
Мережі можуть бути врівноваженими на основі затримки або загальної пропускної здатності ...
Люди можуть бути навантажені збалансованими на основі індивідуальних можливостей; деякі багатозадачні добре, інші - ні, і тоді є якість у порівнянні з кількістю. Ви можете оптимізувати свої людські ресурси на основі багатьох факторів і з різною вагою, що надається різним ознакам.
Сказане далеко не вичерпне; справа в тому, що різні ресурси приймають абсолютно різні види балансування навантаження. З їх наявних атрибутів та можливостей ви повинні вказати, КОТИ цікавлять балансування.
Те, що ви намагаєтеся збалансувати, - це перший критерій створення хорошого алгоритму балансування. І припущення про те, що їх є лише три, є ... непросвітленим. Достойно було б докторанту зробити належну роботу, намагаючись окреслити всі шляхи "навантаження збалансовані".
RT
Не пряма відповідь на ваше запитання, а власне рішення, яке ми знайшли корисним. Використовуючи LVS та демон імпульсу, наше балансування навантаження HTTP налаштовано для виклику користувальницького сценарію bash, який визначає навантаження на "реальні сервери" за допомогою простого SSH-з'єднання та виклику до безперервного часу .
Потім, виходячи із середньої завантаженості серверів, встановлюється зважування на один сервер. Це не самий науковий підхід, оскільки середнє навантаження не обов'язково вказує на HTTP-з'єднання або навантаження процесора, викликані цими з'єднаннями. Тим не менш, ми мали дивовижні результати.
Мій 2с. YMMV.
PS: подивіться на проект LVS - ви обов'язково знайдете інформацію про реалізацію планування балансу навантаження.