1.1, Аноним (1), 22:38, 29/05/2024 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +17 +/– |
Лучший прокси!
В сочетании с Data Plane API https://github.com/haproxytech/dataplaneapi
позволяет себя конфигурировать с учетом транзакционности и атомарности.
Скорость обновления тяжелых конфигураций на лету просто на высоте. Обновлять сертификаты можно даже без reload конфигурации. Особенно актуально при проксировании WebSockets и замены сертификата на них.
Тонна готового мониторинга и есть шаблоны для zabbix. Прометеевские метрики тоже есть. Может проксироваться на бекенд сразу по API FastCGI.
По производительности и функциональности не чета этим вашим nginx (если он используется как прокси, а не как вебсервер).
| |
|
|
|
|
5.16, Аноним (16), 23:35, 29/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Если руки не из того места, то обычно
> работает через пень колоду, либо вообще не работает.
так всегда и получается.
| |
|
|
3.4, Аноним (4), 22:57, 29/05/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +7 +/– |
Оно не просто умеет балансировать на уровне домена, оно еще и health check выполняет в отличие от nginx, где это только в платной версии
| |
3.5, Аноним (5), 23:03, 29/05/2024 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
nginx - это вебсервер, который может быть HTTP прокси, почти ничего не умеет в бесплатной версии когда дело доходит до TCP или чего-то посложнее. Мониторинговая статистика тоже платная. Кроме того он имеет встроенный кэш средней паршивости. Всё в одном флаконе и всё сделано кое как.
haproxy - это только прокси и ничего кроме прокси. Веб-сервера и кэши у вас должны быть отжельными на бекенде.
| |
|
4.22, Аноним (22), 02:48, 30/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Веб-сервера и кэши у вас должны быть отжельными на бекенде.
Из реального боевого haproxy.cfg
cache cache
total-max-size 100 #Mb
max-object-size 2097152 #b
max-age 1800 #s
process-vary off
Угадай с трех раз о чем это?
А еще HAProxy не плохо справляется с задачами WAF
| |
|
|
|
7.35, Аноним (35), 10:15, 31/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Смотря какой контент, если один и тот же динамический ответ выдаётся десяткам тысяч клиентов, то однозначно не напрасное.
| |
|
6.32, Аноним (22), 13:11, 30/05/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
В HAProxy кэш используется для разгрузки отдачи мелкой статики
backend lig-1
http-request cache-use cache if { path_end .gif .png .jpg .css .js }
http-response cache-store cache
| |
|
|
|
3.6, Аноним (16), 23:04, 29/05/2024 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
> Ну да, nginx функциональнее
По функциональности с HAProxy может потягаться разве что коммерческая версия nginx. Но все равно проиграет :)
> Эта шляпа то хоть научилась на уровне домена балансить?
HAProxy может группировать и распределять трафик практически по любому L7-атрибуту, в отличие от nginx.
| |
|
|
5.13, Аноним (16), 23:28, 29/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Ну, давайте, расскажите нам, что вы пытались сделать, как вы это пытались сделать и что вам в итоге не понравилось.
| |
|
6.28, Аноним (16), 12:19, 30/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
DNS-балансировка средствами nginx? Серьёзно?
Пойду расскажу разработчикам dnsdist, они осознают бесполезность своего труда, расплачутся и уйдут в дворники.
| |
|
|
|
3.11, Аноним (11), 23:19, 29/05/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +3 +/– |
А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU?
Когда я видел это как проси в последний раз его надо было пихать в односокетную виртуалку, чтобы половина входящих запросов не леградировала по производительности.
На физике из коробки оно не работоспособно.
Там ещё можно конечно обкостылиться, запуская 2 демона nginx на разных узлах Numa, но там чем дальше в лес тем больше дров, особенно когда дело дойдёт до вышестоящей балансировки на сети.
Короче, проще хапрокси поставить.
| |
|
|
5.29, Аноним (16), 12:22, 30/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
> Плин, сколько объективщины по nginx в ветке - аж прослезился.
Потому что пришёл какой-то обиженный ребенок и стал доказывать, что этот игрушечный грузовичок лучше настоящих.
Как тут удержаться от того, чтобы его аргументированно отпинать?
| |
|
4.33, Аноним (33), 02:08, 31/05/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>А что nginx научился располагать воркеры на разных узлах Numa? Он умеет учитывать с какой сетевки идут коннекшены и правильно выбирать воркеры запущенные на разных сокетах/CPU?
Хапрокси умеет определять к какому узлу нумы относится прерывание очереди сетевой для пришедшего запроса?
А то ведь там все сильно по разному может быть.
>На физике из коробки оно не работоспособно.
Хорошо что мы не знали. А то он у нас на физике спокойно 50к з/с держит.
| |
|
|
2.42, Ilya Indigo (ok), 13:59, 01/06/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Я правильно понимаю, haproxy используется для распределения нагрузки и организации отказоустойчивости nginx-серверов?
Я не сильно разбираюсь в хайлоуде.
| |
|
1.7, Борат (?), 23:10, 29/05/2024 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
подскажите, а его в качестве tlsproxy можно заюзать? чтобы через sni и не хранил у себя серты, а проксил на https проксируемых доменов ?
| |
|
|
3.15, Аноним (16), 23:34, 29/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Изящнее было бы использовать map:
use_backend %[req.ssl_sni,lower,map_dom(/etc/haproxy/maps/hosts.map,be_default)]
| |
|
2.17, Аноним (1), 23:49, 29/05/2024 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
В каком смысле "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-сессиями, которые радостно терминируете.
| |
|
3.19, Борат (?), 00:47, 30/05/2024 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
и tcp проксирование тут совсем не всралось - оно пойдет только на один домен
а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршруту
и на одном порту может висеть десяток ссл доменов и успешно проксируются вот тем самым поделием древним
| |
|
4.30, Аноним (16), 12:25, 30/05/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> а мне надо принять соединение на ссл-порту, проверить что они там запросили (sni) и спроксировать по маршруту
Вот именно на это вам уже два раза здесь ссылку скинули (Enhanced SSL Load Balancing With Server Name Indication (SNI) TLS Extension).
| |
|
|
|
|
|
3.45, Анонус (?), 09:50, 04/06/2024 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Cloudflare пилят собственную вундервафлю
Я знаю. Поэтому и удивляюсь, что не пользуются таким замечательным функциональным продуктом (судя по комментам выше).
| |
|
|
|