Вопрос: Заказ: 1. nginx 2. лак 3. haproxy 4. веб-сервер?


Я видел, как люди рекомендуют комбинировать все это в потоке, но у них, похоже, много перекрывающихся функций, поэтому я хотел бы вникать в то, почему вы, возможно, захотите пройти через 3 разные программы, прежде чем попасть на ваш фактический веб-сервер.

Nginx:

  • ssl: yes
  • сжать: да
  • кеш: да
  • бэкэнд-пул: да

лак:

  • ssl: no (stunnel?)
  • сжать:?
  • кеш: да (основная функция)
  • бэкэнд-пул: да

HAProxy:

  • ssl: no (stunnel)
  • сжать:?
  • кеш: нет
  • бэкэнд-пул: да (основная функция)

Является ли цель связать все это перед вашими основными веб-серверами, чтобы получить некоторые из своих основных преимуществ?

Кажется довольно хрупким, когда так много демонов текут вместе, делая подобные вещи.

Каково ваше развертывание и порядок предпочтения и почему?


47
2017-11-19 17:52


Источник


У лака теперь есть поддержка SSL: см. blog.exceliance.fr/2012/09/10/... - MiniQuark
вы хотите сказать HAProxy? - Luis Lobo Borobia
У Nginx есть все, поэтому я бы сказал, что просто использую nginx. - Seun Osewa


Ответы:


Проще говоря..

HAproxy является лучшим поставщиком балансировки с открытым исходным кодом на рынке.
лакировка является лучшим статическим файловым файлом с открытым исходным кодом на рынке.
Nginx является лучшим веб-сервером с открытым исходным кодом на рынке.

(конечно, это мнение моего и многих других народов)

Но, как правило, не все запросы проходят через весь стек.

Все проходит через haproxy и nginx / multiple nginx's.
Единственное различие заключается в том, что вы «болты» на лаке для статических запросов.

  • любой запрос уравновешен для избыточности и пропускной способности (хорошо, это масштабируемая избыточность)
  • любой запрос на статические файлы сначала попадает в кэш лака (хорошо, это быстро)
  • любой динамический запрос поступает непосредственно на бэкэнд (большой, лак не используется)

В целом, эта модель подходит для масштабируемой и растущей архитектуры (возьмите haproxy, если у вас нет нескольких серверов)

Надеюсь, это поможет: D

Заметка: Я также нахожу также предложение Pound для запросов SSL: D
У вас может быть сервер, предназначенный для дешифрования SSL-запросов, и выдача стандартных запросов в фоновый файл: D (он делает весь стек более быстрым и простым)


59
2017-11-19 18:26



Очень интересно, особенно часть сервера расшифровки. +1 - Gerry
Удивительный ответ. Мне интересно, что сидит впереди всего? Это HAProxy или Nginx? - John
@John: [Клиент -> HAProxy -> Varnish -> Nginx -> Статическое содержимое] или [Клиент -> HAProxy -> Nginx (необязательно) -> Сервер приложений (динамический контент)] - MiniQuark
Зачем вам кэшировать статические и обслуживать динамические? Nginx работает молниеносно для подачи статических файлов. Я предпочитаю использовать стек, например [HAProxy -> Nginx] для статических и [HAProxy -> Nginx -> Varnish -> Apache] для реализации кеша в динамике. Завершение SSL на балансировщике нагрузки, как вы заявляли с выделенными конечными узлами. - Steve Buzonas


предисловие

Обновление в 2016 году. Все развивается, все серверы становятся все лучше, все они поддерживают SSL, и Интернет поражает, чем когда-либо.

Если не указано, следующее предназначено для профессионалов в бизнесе и начинающих, поддерживающих тысячи-миллионы пользователей.

Эти инструменты и архитектуры требуют большого количества пользователей / оборудования / денег. Вы можете попробовать это в домашней лаборатории или запустить блог, но это не имеет большого смысла.

Как правило, помните, что вы хотите будь проще, Каждое добавленное промежуточное программное обеспечение является еще одним важным компонентом промежуточного программного обеспечения для поддержки. Совершенство не достигается, когда добавлять нечего, но когда ничего не остается удалить.

Некоторые общие и интересные развертывания

HAProxy (балансировка) + nginx (приложение php + кэширование)

Веб-сервер - nginx, работающий php. Когда nginx уже существует, он может обрабатывать кэширование и перенаправление.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (балансировка) + лак (кеширование) + Tomcat (приложение Java)

HAProxy может перенаправлять на Varnish на основе URI запроса (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (балансировка) + nginx (SSL для хоста и кэширования) + Web-сервер (приложение)

Веб-серверы не говорят на SSL, хотя КАЖДЫЙ ДОЛЖЕН ГОВОРИТЬ SSL (особенно эта ссылка HAProxy-WebServer с частной информацией пользователя, проходящей через EC2). Добавление локального nginx позволяет подключать SSL к хосту. Как только nginx существует, он может также сделать некоторое кэширование и переписывание URL.

Заметка: Перенаправление портов 443: 8080 происходит, но не является частью функций. Нет смысла выполнять перенаправление портов. Балансировщик нагрузки мог говорить напрямую с веб-сервером: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

Промежуточное

HAProxy: Балансировщик нагрузки

Основные функции:

  • Балансировка нагрузки (TCP, HTTP, HTTPS)
  • Множественные алгоритмы (round robin, source ip, headers)
  • Сохранение сеанса
  • Отключение SSL

Похожие альтернативы: nginx (многоцелевой веб-сервер, настраиваемый как балансировщик нагрузки)
Различные альтернативы: Cloud (Amazon ELB, балансировщик нагрузки Google), аппаратное обеспечение (F5, fortinet, citrix netscaler), Other & Worldwide (DNS, anycast, CloudFlare)

Что делает HAProxy и когда вам нужно его использовать?
Всякий раз, когда вам нужна балансировка нагрузки. HAProxy - это решение.

Кроме когда вы хотите очень дешево ИЛИ быстро и грязно ИЛИ у вас нет доступных навыков, тогда вы можете использовать ELB: D

Кроме когда вы находитесь в банке / правительстве / аналогичном, требующем использовать свой собственный центр обработки данных с жесткими требованиями (выделенная инфраструктура, надежный переход на другой ресурс, 2 уровня брандмауэра, аудита, SLA для оплаты x% за минуту простоя, все в одном), тогда вы может поставить 2 F5 поверх стойки, содержащей 30 серверов приложений.

Кроме если вы хотите пройти 100k HTTP (S) [и несколько сайтов], тогда вы ДОЛЖНЫ иметь кратные HAProxy со слоем [глобальной] балансировки нагрузки перед ними (cloudflare, DNS, anycast). Теоретически глобальный балансир мог бы говорить прямо с веб-серверами, позволяющими канаву HAProxy. Обычно, однако, вы ДОЛЖНЫ сохранять HAProxy (s) в качестве точки публичной записи в вашем центре обработки данных и настраивать расширенные параметры, чтобы сбалансировать их по всем хостам и минимизировать отклонения.

Личное мнение: Небольшой, содержащий проект с открытым исходным кодом, полностью посвященный ОДНОЙ ИСТИННОЙ ЦЕЛИ. Среди наиболее простой конфигурации (один файл), наиболее полезного и надежного программного обеспечения с открытым исходным кодом, которое я обнаружил в своей жизни.

Nginx: Apache, который не сосать

Основные функции:

  • WebServer HTTP или HTTPS
  • Запуск приложений в CGI / PHP / некоторых других
  • Перенаправление / переписывание URL
  • Контроль доступа
  • Обработка заголовков HTTP
  • Кэширование
  • Обратный прокси

Похожие альтернативы: Apache, Lighttpd, Tomcat, Gunicorn ...

Apache был де-факто веб-сервером, также известным как гигантский кластер из десятков модулей и тысяч строк httpd.confна вершине сломанной архитектуры обработки запросов. nginx redo все это, с меньшим количеством модулей (немного) упрощенной конфигурации и лучшей архитектурой ядра.

Что делает nginx и когда вам нужно его использовать?
Веб-сервер предназначен для запуска приложений. Когда ваше приложение разработано для запуска на nginx, у вас уже есть nginx, и вы можете использовать все его функции.

Кроме когда ваше приложение не предназначено для запуска на nginx и nginx нигде не может быть найдено в вашем стеке (Java-магазин никому?), тогда в nginx мало смысла. Возможности веб-серверов, вероятно, будут существовать на вашем текущем веб-сервере, а другие задачи лучше обрабатываются с помощью соответствующего выделенного инструмента (HAProxy / Varnish / CDN).

Кроме когда вашему веб-серверу / приложению не хватает функций, трудно настроить и / или вы скорее умрите работу, чем посмотрите на нее (Gunicorn any?), тогда вы можете поставить nginx впереди (то есть локально на каждом узле) для выполнения перезаписи URL-адресов , отправлять 301 переадресацию, обеспечивать контроль доступа, обеспечивать шифрование SSL и редактировать HTTP-заголовки на лету. [Это функции, ожидаемые от веб-сервера]

Лак: Сервер кеширования

Основные функции:

  • Кэширование
  • Расширенное кэширование
  • Изобразительное зернистое кэширование
  • Кэширование

Похожие альтернативы: nginx (многоцелевой веб-сервер, настраиваемый как сервер кэширования)
Различные альтернативы: CDN (Akamai, Amazon CloudFront, CloudFlare), аппаратное обеспечение (F5, Fortinet, Citrix Netscaler)

Что делает лак и когда вы его используете?
Это кэширование, только кэширование. Обычно это не стоит усилий, и это пустая трата времени. Попробуйте CDN. Имейте в виду, что кеширование - это последнее, что вам нужно заботиться при запуске веб-сайта.

Кроме когда вы используете веб-сайт исключительно о картинах или видео, вы должны внимательно изучить CDN и серьезно подумать о кешировании.

Кроме когда вы вынуждены использовать свое собственное оборудование в своем собственном центре обработки данных (CDN не является вариантом), и ваши веб-серверы ужасны при доставке статических файлов (добавление большего количества веб-серверов не помогает), тогда Лак - последнее средство.

Кроме когда у вас есть сайт с главным образом-статическим, но сложным-динамически сгенерированным контентом (см. следующие параграфы), тогда Varnish может сэкономить много вычислительной мощности на ваших веб-серверах.

Статическое кэширование переоценивается в 2016 году

Кэширование практически бесплатное, бесплатное и свободное время. Просто подпишитесь на CloudFlare или CloudFront или Akamai или MaxCDN. Время, требуемое мне для написания этой строки, дольше, чем время, затрачиваемое на настройку кеширования. И пиво, которое я держу в руке, дороже, чем медианная подписка CloudFlare.

Все эти сервисы работают из коробки для статических * .css * .js * .png и более. Фактически, они в основном Cache-Control директива в HTTP-заголовке. Первым шагом кэширования является настройка ваших веб-серверов для отправки правильных директив кеша. Не имеет значения, какой CDN, какой лак, какой браузер посередине.

Рекомендации по производительности

Лак был создан в то время, когда средние веб-серверы задыхались, чтобы служить кошачьей картине в блоге. В настоящее время один экземпляр среднего современного многопоточного асинхронного веб-сервера с ведомым модным словом может надежно доставлять котят по всей стране. Предоставлено sendfile(),

Я сделал несколько быстрых тестов производительности для последнего проекта, над которым я работал. Один экземпляр tomcat может обслуживать от 21 000 до 33 000 статических файлов в секунду через HTTP (тестирование файлов с 20B до 12kB с различным количеством подключений HTTP / клиентов). Постоянный исходящий трафик превышает 2,4 Гбит / с. У продукта будет только интерфейс 1 Гбит / с. Не может сделать лучше, чем аппаратное обеспечение, не стоит даже пытаться использовать Лак.

Кэширование комплекса Изменение динамического содержимого

CDN и серверы кэширования обычно игнорируют URL с такими параметрами, как ?article=1843, они игнорируют любой запрос с кукисами сеансов или аутентифицированными пользователями и игнорируют большинство типов MIME, включая application/json из /api/article/1843/info, Доступны параметры конфигурации, но обычно не мелкие, а скорее «все или ничего».

Лак может иметь пользовательские сложные правила (см. VCL), чтобы определить, что такое cachable, а что нет. Эти правила могут кэшировать определенный контент по URI, заголовкам и текущему пользовательскому файлу cookie, а также типу MIME и содержимому ALL TOGETHER. Это может сэкономить много вычислительной мощности на веб-серверах для некоторого очень специфического шаблона загрузки. Именно тогда Лак удобен и УДИВИТЕЛЬНЫ.

Вывод

Мне потребовалось некоторое время, чтобы понять все эти штуки, когда их использовать и как они сочетаются. Надеюсь, это может вам помочь.

Это получается довольно долго (6 часов, чтобы написать. OMG!: O). Может быть, я должен начать блог или книгу об этом. Удовлетворяющий факт: не существует предела длины ответа.


28
2018-05-22 18:37



Ограничение длины ответа ограничено, но вам нужно будет написать еще несколько книг, чтобы добраться до него. - Michael Hampton♦
Один момент стоит упомянуть о кешировании: его мощный способ повысить производительность сайта, если у вас нет контроля над приложением; особенно если приложение имеет действительно глупые заголовки кеша (корпоративные приложения - кто?). Однако вы должны быть намного более осведомлены об аутентифицированных ресурсах. - Cameron Kerr
@ user5994461 Я хотел бы прочитать ваш блог. Удивительный ответ! - oxalorg


Это правда, что 3 инструмента имеют общие функции. Большинство установок прекрасно сочетаются с любой комбинацией из 2 среди 3. Это зависит от их основной цели. Обычно принято жертвовать некоторым кешированием, если вы знаете, что ваш сервер приложений работает на статике (например: nginx). Обычно вы жертвуете некоторыми функциями балансировки нагрузки, если вы собираетесь устанавливать десятки или сотни серверов и не заботитесь о том, чтобы максимально использовать их или проблемы устранения неполадок. Обычно жертвуют некоторые функции веб-сервера, если вы намереваетесь запускать распределенное приложение со многими компонентами во всем мире. Тем не менее, некоторые люди создают интересные фермы со всеми из них.

Вы должны иметь в виду, что вы говорите о 3 твердых продуктах. Как правило, вам не нужно загружать баланс. Если вам нужен передний SSL, то сначала nginx как обратный-прокси-сервер отлично. Если вам это не нужно, тогда лак на лицевой стороне отлично. Затем вы можете поместить haproxy для балансировки ваших приложений. Иногда вам также нужно переключиться на разные серверные фермы на самом haproxy, в зависимости от типов файлов или путей.

Иногда вам придется защищать от тяжелых DDoS-атак, а haproxy впереди будет больше, чем другие.

В общем, вы не должны беспокоиться о том, какой компромисс должен делать между вашими выборами. Вы должны выбрать, как собрать их, чтобы получить максимальную гибкость для ваших нужд сейчас и вперед. Даже если вы складываете несколько из них несколько раз, иногда это может быть правильным в зависимости от ваших потребностей.

Надеюсь, это поможет!


19
2017-11-20 18:45



+1 для HAProxy - автор отвечает на вопросы о сбое сервера. Благодарю. - Joel K
Arenstar: Вы пишете один из этих инструментов? Вилли Тарро является главным разработчиком HAProxy. - Joel K
Спасибо за это Вилли. Вы ответили на мой вопрос перед Аренстаром. - John
Обратите внимание, что текущий код разработки для HAProxy теперь включает SSL. - Joel K


Все остальные ответы до 2010 года, поэтому добавление обновленного сравнения.

Nginx

  • Также можно использовать полный веб-сервер, другие функции. Например: HTTP компрессия
  • Поддержка SSL
  • Очень легкий вес, поскольку Nginx был спроектирован так, чтобы быть легким с самого начала.
  • Эффективность кеширования вблизи лака
  • Близко к производительности балансировки нагрузки HAProxy

лакировка

  • наилучшим образом подходит для сложных сценариев кеширования и Приложения.
  • лучший статический файл cacher
  • Нет поддержки SSL
  • Память и процессор

HAproxy

  • лучший балансировщик нагрузки, для функций балансировки режущей кромки, сравнимый с аппаратные балансировщики
  • SSL поддерживается с 1.5.0
  • Проще, будучи просто прокси-сервером tcp без реализации http, который делает его более быстрым и менее подверженным ошибкам.

Таким образом, лучший метод, похоже, реализует все из них в соответствующем порядке.

Однако для общего назначения, Nginx лучше поскольку вы получаете более высокую среднюю производительность для всех: Кэширование, обратное проксирование, балансировка нагрузки, при этом очень мало накладных расходов на использование ресурсов. И тогда у вас есть функции SSL и полного веб-сервера.


13
2017-11-30 11:25





Лак поддерживает балансировку нагрузки: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx поддерживает балансировку нагрузки: http://wiki.nginx.org/NginxHttpUpstreamModule

Я бы просто сконфигурировал это с помощью лака + stunnel. Если мне понадобился nginx по какой-то другой причине, я бы просто использовал nginx + лак. Вы можете подключить nginx к SSL-соединениям и прокси-серверу для лака, а затем поговорить с nginx через http.

Некоторые люди могут бросать nginx (или Apache) в микс, потому что это несколько более универсальные инструменты, чем Larnish. Например, если вы хотите преобразовать контент (например, используя XDV, фильтры apache и т. Д.) На прокси-уровне, вам понадобится один из них, потому что Лак не может этого сделать сам по себе. Некоторые люди могут просто лучше ознакомиться с конфигурацией этих инструментов, поэтому проще использовать Varnish в качестве простого кеша и выполнять балансировку нагрузки на другом уровне, потому что они уже знакомы с Apache / nginx / haproxy в качестве балансировки нагрузки.


5
2017-11-19 17:57



Правильно. «Бэкэнд-пул» должен был указать, что все три из них имеют функции балансировки нагрузки. Из моего первоначального исследования кажется, что HAProxy имеет самые настраиваемые параметры балансировки нагрузки. - Joel K
Это звучит разумно, поскольку он был создан как инструмент балансировки нагрузки. С другой стороны, функции балансировки нагрузки Varnish довольно хороши, и удаление одного процесса из этого микса позволяет упростить конфигурацию с меньшей задержкой. - larsks