Спустя пять лет с момента формирования ветки 2.0 опубликован релиз балансировщика нагрузки HAProxy 3.0, позволяющего распределять HTTP-трафик и произвольные TCP-запросы между группой серверов, учитывая множество факторов (например, проверяет доступность серверов, оценивает уровень нагрузки, имеет средства противостояния DDoS) и проводя первичную фильтрацию данных (например, можно разбирать HTTP-заголовки, отфильтровывать передачу некорректных параметров запроса, блокировать подстановку SQL и XSS, подключать агенты обработки контента). HAProxy также может применяться для координации взаимодействия компонентов в системах на базе архитектуры микросервисов. Код проекта написан на языке Си и поставляется под лицензией GPLv2. Проект используется на многих крупных сайтах, включая Airbnb, Alibaba, GitHub, Imgur, Instagram, Reddit, StackOverflow, Tumblr, Twitter и Vimeo...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61267
Лучший прокси!
В сочетании с Data Plane API https://github.com/haproxytech/dataplaneapi
позволяет себя конфигурировать с учетом транзакционности и атомарности.Скорость обновления тяжелых конфигураций на лету просто на высоте. Обновлять сертификаты можно даже без reload конфигурации. Особенно актуально при проксировании WebSockets и замены сертификата на них.
Тонна готового мониторинга и есть шаблоны для zabbix. Прометеевские метрики тоже есть. Может проксироваться на бекенд сразу по API FastCGI.
По производительности и функциональности не чета этим вашим nginx (если он используется как прокси, а не как вебсервер).
Ну да, nginx функциональнее. Эта шляпа то хоть научилась на уровне домена балансить?
Всегда умела, у тебя ручки не оттуда растут. Это через ACL в ней делается.
Я знаю. И знаю, что это работает через пень колоду, либо вообще не работает.
Если руки не из того места, то обычно> работает через пень колоду, либо вообще не работает.
так всегда и получается.
Оно не просто умеет балансировать на уровне домена, оно еще и health check выполняет в отличие от nginx, где это только в платной версии
nginx - это вебсервер, который может быть HTTP прокси, почти ничего не умеет в бесплатной версии когда дело доходит до TCP или чего-то посложнее. Мониторинговая статистика тоже платная. Кроме того он имеет встроенный кэш средней паршивости. Всё в одном флаконе и всё сделано кое как.haproxy - это только прокси и ничего кроме прокси. Веб-сервера и кэши у вас должны быть отжельными на бекенде.
> Веб-сервера и кэши у вас должны быть отжельными на бекенде.Из реального боевого haproxy.cfg
cache cache
total-max-size 100 #Mb
max-object-size 2097152 #b
max-age 1800 #s
process-vary offУгадай с трех раз о чем это?
А еще HAProxy не плохо справляется с задачами WAF
Это так... не лучше чем cache в nginx.Для сложного кэширования динамического контента рядом с haproxy исторически принято ставить Varnish Cache:
https://varnish-cache.org/
Кэшировать динамический контент перед отдачей, ИМХО, это напрасное согревание вселенной.
Смотря какой контент, если один и тот же динамический ответ выдаётся десяткам тысяч клиентов, то однозначно не напрасное.
>если один и тот же динамический ответ выдаётся десяткам тысяч клиентовто его надо перегнать (curl, wget, httrack, etc) в статический HTML и перестать увеличивать глобальное потепрление.
В HAProxy кэш используется для разгрузки отдачи мелкой статики
backend lig-1
http-request cache-use cache if { path_end .gif .png .jpg .css .js }
http-response cache-store cache
А вот с кэшированием статики любого размера отлично справляется ядро.
И с установлением кучи HTTP соединений тоже ядро будет сравляться?
На сайт одновременно пришли 100 клиентов. Вэб сервер в любом случае установит 100 коннектов и каждому клиенту будет вынужден отдать кучу одинаковых css, js, gif и т.п. не зависимо от НТТР1.1 keep-alive или HTTP2.
HAProxy на фронтенде тоже установит 100 коннектов. Только эти css, js, gif отдаст всем из своей памяти, не дергая бэкенд. Это назывется offload.
Ядро тут не причем.
Разница между отдачей из своего кэша и из кэша ФС - это всего один сисколл. Кому-то поможет, но для большинства это преждевременная оптимизация.
Скромно замечу, что sleep(65535) — это тоже "всего один сисколл".
Разница в том, что клиент может быть с медленным соединением,
а у бакенда более дорогой процесс, который будет практически простаивать на время отдачи.
> Ну да, nginx функциональнееПо функциональности с HAProxy может потягаться разве что коммерческая версия nginx. Но все равно проиграет :)
> Эта шляпа то хоть научилась на уровне домена балансить?
HAProxy может группировать и распределять трафик практически по любому L7-атрибуту, в отличие от nginx.
Ну давай пример конфига. В реальном мире то, что у них в доках не работает) Сюрпрайз.
Ну, давайте, расскажите нам, что вы пытались сделать, как вы это пытались сделать и что вам в итоге не понравилось.
Например: https://www.haproxy.com/user-spotlight-series/load-balancing...
Что может тебе бесплатный nginx построить кластер PostgreSQL с read-only роутингом запросов по репликам поверх patroni? Сюрпрайз.Или может быть nginx умеет нормально прокидывать IP-адреса на postfix, когда делается балансировка граничных MTA?
https://www.haproxy.com/blog/efficient-smtp-relay-infrastruc...Ну то есть платный nginx умеет делать клиентскую точку подключения с предаутентификацией, не знаю разрешили ли это делать в бесплатном. Вот только это не публичный SMTP на 25-ом порту, а тот который обычно вешают на 465 или 587.
Или может мне порассказывать тебе про бредятину, которую адепты nginx пишут про DNS-балансировку, которую предлагает nginx. Вот тебе пример того что в nginx есть и не работает by-design.
Нельзя баланcировать UDP-протоколы через вебсервер, терминируя соединения.
Во-первых, потому что в UDP-нет понятия сессии. Она есть в вышестоящем протоколе.
Во-вторых, потому что обычные UDP-протоколы не могут быть разобраны быстро ядром, нужно осмысленно разбирать всё содержимое в юзерспейсе.
В-третьих терминирование именно DNS - это особенная форма безумия, потому что это протокол в котором ответ может в разы превышать запрос. Терминирующий балансировщик станет бутылочным горлышкомюНормальные люди используют прозрачные балансировщики на L4 вроде keepalived в режиме Direct Server Return, опять же из-за особенностей самого DNS. При этом HAproxy не имеет такого DNS-функционала, потому что это не её задача. В nginx этот функционал есть, но в проде он не работоспособен и используется строго для галочки, типа а вот как мы умеем и пофигу что оно не работает на большой нагрузке, зато есть.
Ну и на последок: https://www.haproxy.com/blog/how-to-enable-quic-load-balanci...
Есть проксирование HTTP/3 в nginx? И как оно там готово к проду? Просто в haproxy оно уже полтора года как в проде работает.
DNS-балансировка средствами nginx? Серьёзно?Пойду расскажу разработчикам dnsdist, они осознают бесполезность своего труда, расплачутся и уйдут в дворники.
А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU?Когда я видел это как проси в последний раз его надо было пихать в односокетную виртуалку, чтобы половина входящих запросов не леградировала по производительности.
На физике из коробки оно не работоспособно.
Там ещё можно конечно обкостылиться, запуская 2 демона nginx на разных узлах Numa, но там чем дальше в лес тем больше дров, особенно когда дело дойдёт до вышестоящей балансировки на сети.
Короче, проще хапрокси поставить.
Плин, сколько объективщины по nginx в ветке - аж прослезился.
Но самое оно в том, что того, чего умеют хапроксевские ACL, на нгинхе не сделаешь никак.
> Плин, сколько объективщины по nginx в ветке - аж прослезился.Потому что пришёл какой-то обиженный ребенок и стал доказывать, что этот игрушечный грузовичок лучше настоящих.
Как тут удержаться от того, чтобы его аргументированно отпинать?
>А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU?Хапрокси умеет определять к какому узлу нумы относится прерывание очереди сетевой для пришедшего запроса?
А то ведь там все сильно по разному может быть.>На физике из коробки оно не работоспособно.
Хорошо что мы не знали. А то он у нас на физике спокойно 50к з/с держит.
>А что nginx научился располагать воркеры на разных узлах Numa?Разумеется, worker_cpu_affinity
Я правильно понимаю, haproxy используется для распределения нагрузки и организации отказоустойчивости nginx-серверов?
Я не сильно разбираюсь в хайлоуде.
подскажите, а его в качестве tlsproxy можно заюзать? чтобы через sni и не хранил у себя серты, а проксил на https проксируемых доменов ?
Ага https://www.haproxy.com/blog/enhanced-ssl-load-balancing-wit...
Изящнее было бы использовать map:
use_backend %[req.ssl_sni,lower,map_dom(/etc/haproxy/maps/hosts.map,be_default)]
В каком смысле "tlsproxy"?
Если с целью подмены сертификата с целью раскрытия TLS-трафика, то нет. Вам нужен прямой прокси, а это обратный прокси. Это разные вещи у обратной прокси такого функционала не заложено.
Если с целью терминирования соединений, и просовывания на другие TLS-бекенды, то можно.Но вот с хранением сертификатов у вас будут проблемы. HAproxy хранит свои сертификаты исключительно в оперативной памяти. При запуске она их подгружает с диска или внешней шары, которую вы примонтировали. Дальше она их обновляет по запросу на сокет или после перегрузки конфигурации (reload). Она подбирает сертификаты по заголовкам из хранилища сама, но ей нужно дать это хранилище.
Если подключить внешнюю шару к паре своих проксей с pem-файлами это не считается за "хранение у себя", то так можно. Если вам нужно, чтобы она "магически" работала без сертификатов, то так не бывает. Терминирование TLS обязывает иметь не только открытый но и закрытый ключ на любом обратном прокси сервере. Если речь идёт про SNI на самой проксе. То есть, если вы хотите собрать трафик на один и тот же HTTPS IP:порт фронтенда с нескольких бекендов, вы обязаны дать прокси серверу доступ к каким-то валидным сертификатам, которые вы туда вешаете и не важно один SAN-сертификат там или несколько для SNI.
Если вам нужно, чтобы балансировщик ничего не знал о сертификатах вообще, вы используете mode tcp c включенным TPROXY, если везде Linux (IP-адрес источника запроса передается с фронтенда на бекенд в заголовках TCP) или без TPROXY (информация об IP клиента есть на прокси, но она не приходит на бекенд). Но у вас тогда нет SNI, вы вообще тогда один бекенд на 1 IP:порт кладете. И еще в этом случае вы потеряете возможность вмешаться в запросы на HTTP-уровне. И никакого SNI-у вас нет. Вы рулите TCP-сессиями, которые радостно терминируете.
я про поделки на основе вот этого https://github.com/inetaf/tcpproxy
в той части что ближе к вот этому https://github.com/inetaf/tcpproxy/blob/master/cmd/tlsrouter...
кажется это вс еиз гугловой либы какойто древней ноги растут
вообще грязный хак чистой воды - но многие считают "работает-не трогай"
хотел попробовать заменить на чтото более правильное
> я про поделки на основе вот этого https://github.com/inetaf/tcpproxy
> в той части что ближе к вот этому https://github.com/inetaf/tcpproxy/blob/master/cmd/tlsrouter...
> кажется это вс еиз гугловой либы какойто древней ноги растут
> вообще грязный хак чистой воды - но многие считают "работает-не трогай"
> хотел попробовать заменить на чтото более правильноеЯ кажется понял, что это за "грязный хак". Она умеет его повторить через вот это:
https://docs.haproxy.org/3.0/configuration.html#ssl_fc_sni как раз с тем самым mode tcp
Всё что вы приводите, это именно tcp-проксирование c эдаким policy-based роутингом.
Примерно так: use_backend bk_domain_1 if { ssl_fc_sni -i www.domain1.com }
Вот только надо ли это?ИМХО, то что вы можете повторить это на haproxy не повод это повторять. Я не знаю вашего юзкейса, сроков и требований по безопасности, но всё же посоветую пересмотреть это на архитектурном уровне.
Например, сделать нормальный балансировщик с терминированием или оффлоадингом и дать haproxy ходить за сертификатами. Еcли не можете дать сертификаты локально или шарой, прикрутите хотя бы Hashicorp Vault.
Опять же, если ваши сервисы требуют клиентские сертификаты (из браузера) для аутентификации на бекенде (хотя врядли, вы тогда уникум, это редкость), то вы не можете терминировать такие соединения (вы вынуждены использовать mode tcp). ИЛИ вам нужна предаутентификация на прокси и вот она во всех таких проксях платная. ИЛИ вам нужно начать использовать SSO, с OpenID Connect и JWT-токенами.Правильно сильно зависит от того что на бекенде. Если у вас обычные сайты-порталы, то можно просто настроить SNI и разместить сертификаты там, где безопасность позволяет. В идеале, для разгрузки можно использовать TLS Offloading и убрать криптографию с бекенда, опять же если сетевая безопасность позволяет. Это разгрузит бекенд. Если это высоконагруженные сервисы и нельзя допустить, чтобы возникло бутылочное горлышко в форме балансировщика, через который проходят все запросы, то нужно построить в несколько этажей.
Вот вам статья "для легкого чтения": https://vincent.bernat.ch/en/blog/2018-multi-tier-loadbalancer
и tcp проксирование тут совсем не всралось - оно пойдет только на один домен
а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршруту
и на одном порту может висеть десяток ссл доменов и успешно проксируются вот тем самым поделием древним
В haproxy TCP-проксирование умеет дожидаться Client Hello / SNI, если настроить.
> а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршрутуВот именно на это вам уже два раза здесь ссылку скинули (Enhanced SSL Load Balancing With Server Name Indication (SNI) TLS Extension).
В TCP-режиме через req.ssl_sni, естественно без терминации SSL - вполне возможно.
В принципе даже юзкейс описан
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-wit...
А в Клаудфлэр знают, что этот Хахапрокси настолько лучше Энджинкс?
Cloudflare пилят собственную вундервафлю
> Cloudflare пилят собственную вундервафлюЯ знаю. Поэтому и удивляюсь, что не пользуются таким замечательным функциональным продуктом (судя по комментам выше).