Рівень 4 проти шару 7 Врівноваження навантаження

Я намагаюся вирішити між використанням рішення рівня балансування навантаження 4 для мого центру обробки даних або рішення рівня 7. На жаль (на мій розум, тобто), мій варіант використання досить простий, щоб обидва рішення спрацювали добре, уникаючи більшості слабких сторін і не використовуючи сильних сторін з іншого. Яке б рішення ми не закінчили використовувати, воно повинно мати високу доступність та високу пропускну здатність. Але ми лише плануємо використовувати його для завантаження балансу через кластер веб-серверів, жоден з яких не має жодних вимог до "липкого" управління сеансом (cookie або IP), складних правил перезапису - або, з цього приводу, будь-яких правил перезапису на всі.

Балансові навантаження будуть підключені до двох комутаторів, обидва з незалежним підключенням до рівня агрегації центру центрів даних і об'єднані разом за допомогою дерева швидкого розмахування та будь-якого патентованого протоколу, який комутатори використовують для віртуалізації. Балансири навантажень також будуть зшиті один з одним по перехресному кабелю. Всі сервери кластера підключені до обох комутаторів. Все, що повинні робити балансири навантажень, - це спрямовувати трафік на них.

Оскільки це просто HTTP, я можу використовувати рішення для балансування навантаження в шарі 7 типу HAProxy або nginx. Але я також міг би використовувати проект LVS з ldirectord або keepalived або будь-яким іншим.

Я намагався розбити плюси і мінуси, як їх бачу, але це просто закінчується. Що б ти порадив і чому? Я щось пропускаю?

Однією корисною перевагою "L7", як haproxy, є можливість використання файлів cookie для того, щоб той самий веб-переглядач не потрапляв на той самий сервер сервера. Це значно спрощує налагодження клієнтських звернень.

Врівноваження L4 може підстрибувати одного користувача на декількох серверах. (що в певних випадках може бути вигідним, але в сенсі налагодження / профілювання використання "L7" набагато цінніше.)

EDIT: Також існує потенційна перевага швидкості використання балансування HTTP. Завдяки підтримці зберігання клієнтів можуть встановити один баланс TCP до вашого балансира, а потім надіслати багато HIT без необхідності повторного встановлення нових сеансів TCP (3-х тисне рукостискання). Точно так само багато ЛБ підтримують постійні сеанси для підтримки систем заднього кінця, усуваючи необхідність робити те саме рукостискання на задньому кінці.

Суворе врівноваження TCP-навантажень може не виконати обох цих можливостей так легко.

/ * FWIW: Я б не сказав "L7" або "L4", я б сказав HTTP або TCP. Але я чіпляюсь за те, щоб уникнути використання OSI для опису речей, які не узгоджуються. * /

Я думаю, що принципово, якщо ви не впевнені, що розгорнути, виконайте те, що вам здається простим і природним. Перевірте його (використовуєте апач-лавку?) І переконайтеся, що він працює для ваших потреб. Для мене HTTP LB є більш природним.

Зважаючи на відсутність переваги для вас, щоб робити балансування L7, замість цього я б вирішився на балансуванні L4. Я великий фанат зберігати це якомога простіше, не жертвуючи занадто багато.

L7 вимагає, щоб балансири перевіряли заголовки http у пакетах, які проходять через них, на предмет відповідного маршрутизації, додаючи додаткові накладні витрати та граничне збільшення затримки для кінцевого користувача. Мені здається безглуздим витратом, якщо ти цим нічого не заробиш.

Деякі постачальники DNS мають прості функції відмови. Ви згадали, що ваші вимоги не є, а не те, що вони є, але якщо все, що вам потрібно, це круглої робін з відмовою, якщо щось не вдається , тоді ви можете використовувати напр., Відмову від безпеки . Залежно від ваших потреб в HA, які можуть бути досить хорошими, і ви можете пропустити цілий рівень в своїй архітектурі.