Должен ли 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-трафик непосредственно на веб-интерфейс 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 Virtual Server , потому что он не мешает, как HAproxy. Используйте HAproxy, если требуется, чтобы выполнить внутреннюю балансировку нагрузки, такую ​​как балансировка запросов к пулу бэкэнд-работников.


2
Говорят, что балансировка нагрузки в NginX проста, это просто циклический подход. Вот почему я принимаю во внимание HAProxy.
Морган Ченг

1
Сказано правильно; Я сказал это сам. Вот почему я не рекомендую использовать nginx в качестве балансировщика нагрузки, и вы не найдете упоминаний об использовании nginx в качестве балансировщика нагрузки в этом (или любом другом) моем ответе.
Уомбл

Это только в том случае, если вы боитесь использовать свой собственный компилятор из исходного кода (или портов во FreeBSD). Существует несколько сторонних модулей, которые улучшают балансировку нагрузки: wiki.nginx.org/3rdPartyModules
Martin Fjordvald

2
Улучшите, да. Делай адекватно, нет. Мои мысли по этому поводу можно найти в hezmatt.org/~mpalmer/blog/2011/07/24/… (поиск «не очень»).
womble
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.