# Сопутствующие продукты и альтернативы > Взаимодействие HAProxy с Apache, NGINX, Varnish, LVS, Envoy и другими балансировщиками нагрузки --- Индекс LLMS: [llms.txt](/ru/llms.txt) --- HAProxy хорошо сочетается с некоторыми перечисленными ниже продуктами. Поэтому они упомянуты здесь, хотя и не связаны непосредственно с HAProxy. ## 4.1. HTTP-сервер Apache {#section-4-1} Apache — фактический стандарт среди серверов HTTP. Это очень функциональный модульный проект, поддерживающий как выдачу файлов, так и динамическое содержимое. Он может служить фронтендом для серверов приложений, а также проксировать запросы и кешировать ответы. Во всех этих сценариях перед ним обычно требуется балансировщик нагрузки. Apache может работать в разных режимах, одни из которых требуют больше ресурсов, чем другие. Некоторые модули до сих пор требуют более тяжёлой модели с заранее созданными процессами, что мешает Apache эффективно работать с большим числом соединений. В таком случае HAProxy может значительно помочь: он ограничивает число соединений с каждым сервером безопасным значением, заметно ускоряя сервер и сохраняя его ресурсы для приложения. Apache может извлекать адрес клиента из заголовка X-Forwarded-For с помощью расширения «mod_rpaf». HAProxy автоматически заполняет этот заголовок, если в конфигурации задано «option forwardfor». HAProxy также может хорошо защищать Apache, доступный из интернета, поскольку лучше противостоит многим видам атак DoS. ## 4.2. NGINX {#section-4-2} NGINX — второй фактический стандарт среди серверов HTTP. Как и Apache, он предоставляет широкий набор функций. NGINX построен по модели, сходной с HAProxy, поэтому без труда обрабатывает десятки тысяч одновременных соединений. При использовании в качестве шлюза к приложениям (например, через включённый PHP FPM) часто полезно ограничить число соединений на входе, чтобы снизить нагрузку на приложение PHP. Здесь HAProxy пригодится и как обычный балансировщик нагрузки, и как регулятор трафика, ускоряющий PHP за счёт устранения перегрузки. Кроме того, благодаря событийной архитектуре оба продукта потребляют мало CPU, и их часто легко разместить в одной системе. NGINX поддерживает протокол PROXY от HAProxy, поэтому HAProxy легко передаёт ему сведения о клиентском соединении, необходимые приложению. Некоторые тесты также показали, что при выдаче больших статических файлов согласованное хеширование в HAProxy перед NGINX повышает долю попаданий в кеш операционной системы, фактически умножая её на число серверных узлов. ## 4.3. Varnish {#section-4-3} Varnish — интеллектуальный кеширующий обратный прокси, который, пожалуй, точнее всего назвать ускорителем веб-приложений. Varnish не реализует SSL/TLS, предпочитая отдавать все ресурсы CPU тому, что умеет лучше всего. Он также поддерживает протокол PROXY от HAProxy, поэтому HAProxy легко развернуть перед Varnish для обработки SSL и балансировки нагрузки с передачей всех необходимых сведений о клиенте. Кроме того, Varnish умеет распаковывать объекты из кеша, если сервер передал их сжатыми, но сам сжатие не выполняет. Если серверы бэкенда не поддерживают сжатие, исходящие данные можно сжимать в HAProxy, хотя делать это на балансировщике редко бывает хорошей идеей, кроме случаев небольшого трафика. При построении больших кеширующих ферм из нескольких узлов HAProxy может применять согласованное хеширование URL для разумного распределения нагрузки между кеширующими узлами и предотвращения дублирования кеша. Тогда общий размер кеша равен сумме кешей всех узлов. Кроме того, кратковременное кеширование очень маленьких простых объектов в HAProxy иногда позволяет избежать сетевых обменов и снизить нагрузку на CPU как узлов HAProxy, так и Varnish. Это возможно только тогда, когда Varnish никак не обрабатывает эти объекты. Такой подход часто называют «кешем favicon»: иногда он позволяет исключить заметную долю бесполезных запросов к следующему уровню. Однако не включайте длительное кеширование в HAProxy (более нескольких секунд) перед другим кешем: это значительно усложнит устранение неполадок без существенной экономии ресурсов. ## 4.4. Альтернативы {#section-4-4} Linux Virtual Server (LVS или IPVS) — балансировщик нагрузки уровня 4, встроенный в ядро Linux. Он работает на уровне пакетов и обрабатывает TCP и UDP. В большинстве случаев он скорее дополняет HAProxy, чем заменяет его, поскольку совершенно не понимает уровень 7. Pound — ещё один известный балансировщик нагрузки. Он значительно проще HAProxy и обладает гораздо меньшим числом функций, но для многих простейших конфигураций подходят оба продукта. Автор Pound всегда ставил на первое место возможность аудита кода и стремится сохранять небольшой набор функций. Его архитектура на основе потоков хуже масштабируется при большом числе соединений, но это хороший продукт. Pen — довольно лёгкий балансировщик нагрузки. Он поддерживает SSL и сохраняет привязку с помощью таблицы фиксированного размера с IP-адресами клиентов. У него есть режим работы с пакетами, позволяющий в определённых пределах поддерживать прямой ответ сервера и UDP. Он рассчитан на небольшие нагрузки: таблица привязок содержит всего 2048 записей. NGINX в определённой мере умеет балансировать нагрузку, хотя это явно не его основное назначение. Сбои серверов выявляются по рабочему трафику, набор алгоритмов балансировки более ограничен, а поддержка привязки сеансов очень невелика. Но он может быть уместен в простых схемах развёртывания, где уже используется. Поскольку NGINX отлично сочетается с HAProxy, ничто не мешает добавить HAProxy позже, когда возможности NGINX будут исчерпаны. Varnish также балансирует нагрузку между своими серверами бэкенда и поддерживает полноценные проверки работоспособности. Однако привязку сеансов он не реализует, поэтому, как и в случае NGINX, его может быть достаточно для начала, если привязка не нужна. И аналогично, благодаря хорошей совместимости HAProxy и Varnish, HAProxy легко добавить позже, чтобы расширить набор возможностей.