Чи повинен Nginx бути в передній частині HAProxy або навпаки?


11

У мене мало досвіду в розробці інфраструктурної архітектури веб-сайтів. Я знаю, що це може бути конкретним. Передбачається, що веб-сайт:

1) Потрібна підтримка HTTPS для певної сторінки (наприклад, сторінка входу), а інші - лише HTTP-сторінка.

2) Потрібні кілька веб-серверів, щоб було потрібно деяке врівноваження навантаження.

3) Потрібні кешування HTTP та стиснення для підвищення продуктивності.

4) Деякі запити (наприклад, завантаження зображень) повинні бути перенаправлені на спеціальні сервери, що беруть вихід. Отже, потрібне врівноваження на основі URL.

Я знаю, що NginX і HAProxy - це хороший зворотний проксі з відкритим джерелом та / або балансир завантаження. Оскільки HAProxy не підтримує SSL, тоді як балансування навантаження Nginx не так добре, як HAProxy. Я візьму обох.

Отже, чи слід ставити Nginx (як зворотний проксі) перед HAProxy (як балансир навантаження) чи навпаки?

Спасибі

Відповіді:


7

Якщо ви плануєте, щоб кожен веб-сервер був доступний через HTTPS, тоді вам потрібно буде встановити Nginx перед HAProxy. При такій конфігурації ваш Nginx буде обробляти всю роботу SSL та відправлятиме розшифрований трафік HTTP безпосередньо на FAP-інтерфейс HAProxy, який потім завантажить балансові запити на ваші веб-сервери на основі визначених вами правил.

Ідея використання LVS, як згадується Womble, полягає в тому, що вона дещо менш нав'язлива, оскільки вона не підтримує зв'язку між вашим веб-сервером і клієнтом, що отримує доступ до сайту. З іншого боку, LVS надасть вам лише просте збалансування завантаження і не дозволить пересилати запити на основі розширення файлів, запитуваної URL-адреси, заголовків тощо. Тому HAProxy використовується в багатьох ситуаціях.

Якщо вам потрібен лише SSL на одному сервері (не збалансований навантаженням), ви можете безпечно використовувати HAProxy для всього, не використовуючи Nginx. З іншого боку, у вас виникне проблема з тим, що неможливо побачити вихідну IP-адресу клієнта в журналах HTTPS веб-сервера (оскільки HAProxy переписує цю адресу). IP буде в журналах HAProxy, якщо ви ввімкнете його;)


Спасибі. оскільки "Деякі запити (наприклад, завантаження зображень) повинні бути перенаправлені на спеціальні сервери, що займаються заднім числом. Отже, потрібне балансування на основі URL." (як я оновив питання). LVS може не відповідати моїм вимогам.
Морган Ченг

До речі, приховування IP-адреси за HAProxy - це лише для HTTPS, а також для HTTP?
Морган Ченг

@Morgan, приховування ip - це лише для HTTPS.

Це лише для програмного забезпечення в режимі TCP, тому все, що не є HTTP, не побачить IP-адресу, оскільки надсилається як заголовк HTTP (X-Forwarded-For).

Не зовсім. Haproxy може підключитися до сервера за допомогою IP-адреси клієнта, але для цього потрібна співпраця з ядром (наприклад, функція TPROXY). Хоча цього слід уникати, коли це можливо.
Віллі Тарро


1

Вам слід просто використовувати nginx, він робить все необхідне як веб-сервер для інтерфейсів. Якщо вам потрібна фронтальна балансування навантаження, використовуйте балансир навантаження L3, наприклад, віртуальний сервер Linux , оскільки він не відбувається таким чином, як це робить HAproxy. Використовуйте HAproxy, якщо потрібно, щоб виконати балансування навантажень за кадром, як запити на врівноваження до пулу зайнятих працівників.


2
Кажуть, що балансування навантаження NginX - це простий, просто круговий підхід. Ось чому я беру до уваги HAProxy.
Морган Ченг

1
Це сказано правильно; Я сам це сказав. Тому я не рекомендую використовувати nginx як балансир навантаження, і ви не знайдете жодної згадки про використання nginx як балансира навантаження в цій (або будь-якій іншій) моїй відповіді.
живіт

Це лише у тому випадку, якщо ви боїтеся використовувати власну компіляцію з джерела (або портів у FreeBSD). Є декілька сторонніх модулів, які покращують балансування навантаження: wiki.nginx.org/3rdPartyModules
Martin Fjordvald

2
Поліпшити, так. Зробіть адекватним, ні. Мої думки з цього приводу можна знайти в hezmatt.org/~mpalmer/blog/2011/07/24/… (пошук "не дуже").
живіт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.