Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск HTTP/TCP-балансировщика HAProxy 3.0 "	+/–
Сообщение от opennews (??), 29-Май-24, 22:38
Спустя пять лет с момента формирования ветки 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.ru/opennews/art.shtml?num=61267
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 29-Май-24, 22:38	+17 +/–
Лучший прокси! В сочетании с Data Plane API https://github.com/haproxytech/dataplaneapi позволяет себя конфигурировать с учетом транзакционности и атомарности. Скорость обновления тяжелых конфигураций на лету просто на высоте. Обновлять сертификаты можно даже без reload конфигурации. Особенно актуально при проксировании WebSockets и замены сертификата на них. Тонна готового мониторинга и есть шаблоны для zabbix. Прометеевские метрики тоже есть. Может проксироваться на бекенд сразу по API FastCGI. По производительности и функциональности не чета этим вашим nginx (если он используется как прокси, а не как вебсервер).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #42

2. Сообщение от Аноним (2), 29-Май-24, 22:41	–18 +/–
Ну да, nginx функциональнее. Эта шляпа то хоть научилась на уровне домена балансить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3, #4, #5, #6, #11

3. Сообщение от Аноним (1), 29-Май-24, 22:55	+7 +/–
Всегда умела, у тебя ручки не оттуда растут. Это через ACL в ней делается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

4. Сообщение от Аноним (4), 29-Май-24, 22:57	+7 +/–
Оно не просто умеет балансировать на уровне домена, оно еще и health check выполняет в отличие от nginx, где это только в платной версии
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Аноним (5), 29-Май-24, 23:03	+/–
nginx - это вебсервер, который может быть HTTP прокси, почти ничего не умеет в бесплатной версии когда дело доходит до TCP или чего-то посложнее. Мониторинговая статистика тоже платная. Кроме того он имеет встроенный кэш средней паршивости. Всё в одном флаконе и всё сделано кое как. haproxy - это только прокси и ничего кроме прокси. Веб-сервера и кэши у вас должны быть отжельными на бекенде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #22

6. Сообщение от Аноним (16), 29-Май-24, 23:04	+/–
> Ну да, nginx функциональнее По функциональности с HAProxy может потягаться разве что коммерческая версия nginx. Но все равно проиграет :) > Эта шляпа то хоть научилась на уровне домена балансить? HAProxy может группировать и распределять трафик практически по любому L7-атрибуту, в отличие от nginx.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

7. Сообщение от Борат (?), 29-Май-24, 23:10	+/–
подскажите, а его в качестве tlsproxy можно заюзать? чтобы через sni и не хранил у себя серты, а проксил на https проксируемых доменов ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #17, #24

8. Сообщение от Аноним (2), 29-Май-24, 23:12	–10 +/–
Я знаю. И знаю, что это работает через пень колоду, либо вообще не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16

9. Сообщение от Аноним (2), 29-Май-24, 23:13	–2 +/–
Ну давай пример конфига. В реальном мире то, что у них в доках не работает) Сюрпрайз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #13, #20

11. Сообщение от Аноним (11), 29-Май-24, 23:19	+3 +/–
А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU? Когда я видел это как проси в последний раз его надо было пихать в односокетную виртуалку, чтобы половина входящих запросов не леградировала по производительности. На физике из коробки оно не работоспособно. Там ещё можно конечно обкостылиться, запуская 2 демона nginx на разных узлах Numa, но там чем дальше в лес тем больше дров, особенно когда дело дойдёт до вышестоящей балансировки на сети. Короче, проще хапрокси поставить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #23, #33, #34

12. Сообщение от Телемастер (?), 29-Май-24, 23:21	+1 +/–
Ага https://www.haproxy.com/blog/enhanced-ssl-load-balancing-wit...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #15

13. Сообщение от Аноним (16), 29-Май-24, 23:28	+1 +/–
Ну, давайте, расскажите нам, что вы пытались сделать, как вы это пытались сделать и что вам в итоге не понравилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

15. Сообщение от Аноним (16), 29-Май-24, 23:34	+/–
Изящнее было бы использовать map: use_backend %[req.ssl_sni,lower,map_dom(/etc/haproxy/maps/hosts.map,be_default)]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 29-Май-24, 23:35	+1 +/–
Если руки не из того места, то обычно > работает через пень колоду, либо вообще не работает. так всегда и получается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

17. Сообщение от Аноним (1), 29-Май-24, 23:49	+/–
В каком смысле "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-сессиями, которые радостно терминируете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #18, #19

18. Сообщение от Борат (?), 30-Май-24, 00:44	+/–
я про поделки на основе вот этого https://github.com/inetaf/tcpproxy в той части что ближе к вот этому https://github.com/inetaf/tcpproxy/blob/master/cmd/tlsrouter... кажется это вс еиз гугловой либы какойто древней ноги растут вообще грязный хак чистой воды - но многие считают "работает-не трогай" хотел попробовать заменить на чтото более правильное
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #21

19. Сообщение от Борат (?), 30-Май-24, 00:47	+/–
и tcp проксирование тут совсем не всралось - оно пойдет только на один домен а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршруту и на одном порту может висеть десяток ссл доменов и успешно проксируются вот тем самым поделием древним
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #26, #30

20. Сообщение от Аноним (1), 30-Май-24, 00:51	+/–
Например: 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 оно уже полтора года как в проде работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #28

21. Сообщение от Аноним (1), 30-Май-24, 01:41	+/–
> я про поделки на основе вот этого 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

22. Сообщение от Аноним (22), 30-Май-24, 02:48	+/–
> Веб-сервера и кэши у вас должны быть отжельными на бекенде. Из реального боевого haproxy.cfg cache cache     total-max-size 100       #Mb     max-object-size 2097152  #b     max-age 1800             #s     process-vary off Угадай с трех раз о чем это? А еще HAProxy не плохо справляется с задачами WAF
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #27

23. Сообщение от Tron is Whistling (?), 30-Май-24, 08:52	–1 +/–
Плин, сколько объективщины по nginx в ветке - аж прослезился. Но самое оно в том, что того, чего умеют хапроксевские ACL, на нгинхе не сделаешь никак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #29

24. Сообщение от Tron is Whistling (?), 30-Май-24, 08:55	–1 +/–
В TCP-режиме через req.ssl_sni, естественно без терминации SSL - вполне возможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #25

25. Сообщение от Tron is Whistling (?), 30-Май-24, 08:58	+/–
В принципе даже юзкейс описан https://www.haproxy.com/blog/enhanced-ssl-load-balancing-wit...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

26. Сообщение от Tron is Whistling (?), 30-Май-24, 09:18	+/–
В haproxy TCP-проксирование умеет дожидаться Client Hello / SNI, если настроить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

27. Сообщение от Аноним (1), 30-Май-24, 10:05	+/–
Это так... не лучше чем cache в nginx. Для сложного кэширования динамического контента рядом с haproxy исторически принято ставить Varnish Cache: https://varnish-cache.org/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #31, #32

28. Сообщение от Аноним (16), 30-Май-24, 12:19	+/–
DNS-балансировка средствами nginx? Серьёзно? Пойду расскажу разработчикам dnsdist, они осознают бесполезность своего труда, расплачутся и уйдут в дворники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

29. Сообщение от Аноним (16), 30-Май-24, 12:22	–1 +/–
> Плин, сколько объективщины по nginx в ветке - аж прослезился. Потому что пришёл какой-то обиженный ребенок и стал доказывать, что этот игрушечный грузовичок лучше настоящих. Как тут удержаться от того, чтобы его аргументированно отпинать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

30. Сообщение от Аноним (16), 30-Май-24, 12:25	+/–
> а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршруту Вот именно на это вам уже два раза здесь ссылку скинули (Enhanced SSL Load Balancing With Server Name Indication (SNI) TLS Extension).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

31. Сообщение от Аноним (22), 30-Май-24, 12:58	+/–
Кэшировать динамический контент перед отдачей, ИМХО, это напрасное согревание вселенной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #35

32. Сообщение от Аноним (22), 30-Май-24, 13:11	+/–
В HAProxy кэш используется для разгрузки отдачи мелкой статики backend lig-1     http-request cache-use cache if { path_end .gif .png .jpg .css .js }     http-response cache-store cache
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #36

33. Сообщение от Аноним (33), 31-Май-24, 02:08	+/–
>А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU? Хапрокси умеет определять к какому узлу нумы относится прерывание очереди сетевой для пришедшего запроса? А то ведь там все сильно по разному может быть. >На физике из коробки оно не работоспособно. Хорошо что мы не знали. А то он у нас на физике спокойно 50к з/с держит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

34. Сообщение от Аноним (35), 31-Май-24, 10:12	+1 +/–
>А что nginx научился располагать воркеры на разных узлах Numa? Разумеется, worker_cpu_affinity
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

35. Сообщение от Аноним (35), 31-Май-24, 10:15	+/–
Смотря какой контент, если один и тот же динамический ответ выдаётся десяткам тысяч клиентов, то однозначно не напрасное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #39

36. Сообщение от Аноним (35), 31-Май-24, 10:17	–1 +/–
А вот с кэшированием статики любого размера отлично справляется ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #37, #38

37. Сообщение от Аноним (22), 31-Май-24, 10:30	+/–
И с установлением кучи HTTP соединений тоже ядро будет сравляться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

38. Сообщение от Аноним (22), 31-Май-24, 10:43	+/–
На сайт одновременно пришли 100 клиентов. Вэб сервер в любом случае установит 100 коннектов и каждому клиенту будет вынужден отдать кучу одинаковых css, js, gif и т.п. не зависимо от НТТР1.1 keep-alive или HTTP2. HAProxy на фронтенде тоже установит 100 коннектов. Только эти css, js, gif отдаст всем из своей памяти, не дергая бэкенд. Это назывется offload. Ядро тут не причем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #40

39. Сообщение от Аноним (22), 31-Май-24, 10:56	+/–
>если один и тот же динамический ответ выдаётся десяткам тысяч клиентов то его надо перегнать (curl, wget, httrack, etc) в статический HTML и перестать увеличивать глобальное потепрление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

40. Сообщение от Аноним (35), 31-Май-24, 19:24	+/–
Разница между отдачей из своего кэша и из кэша ФС - это всего один сисколл. Кому-то поможет, но для большинства это преждевременная оптимизация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #41, #46

41. Сообщение от Аноним (16), 31-Май-24, 23:09	+/–
Скромно замечу, что sleep(65535) — это тоже "всего один сисколл".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

42. Сообщение от Ilya Indigo (ok), 01-Июн-24, 13:59	+/–
Я правильно понимаю, haproxy используется для распределения нагрузки и организации отказоустойчивости nginx-серверов? Я не сильно разбираюсь в хайлоуде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

43. Сообщение от Анонус (?), 02-Июн-24, 10:40	+/–
А в Клаудфлэр знают, что этот Хахапрокси настолько лучше Энджинкс?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

44. Сообщение от Аноним (44), 04-Июн-24, 01:01	+/–
Cloudflare пилят собственную вундервафлю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #45

45. Сообщение от Анонус (?), 04-Июн-24, 09:50	+/–
> Cloudflare пилят собственную вундервафлю Я знаю. Поэтому и удивляюсь, что не пользуются таким замечательным функциональным продуктом (судя по комментам выше).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

46. Сообщение от rex (??), 08-Окт-24, 18:00	+/–
Разница в том, что клиент может быть с медленным соединением, а у бакенда более дорогой процесс, который будет практически простаивать на время отдачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема