1.1, 1 (??), 12:12, 20/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Представлен новый API Data Plan, позволяющий на лету управлять настройками HAProxy через REST Web API. В том числе можно динамически добавлять и удалять бэкенды и серверы, создавать ACL, изменять маршрутизацию запросов, изменять привязки обработчиков к IP;
Envoy больше не нужен?
| |
|
2.17, Лапчатый девляпс бубунтёнак (?), 21:31, 20/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
От требований зависит.
У нас например, cookie-based session stickiness обязателен. Мы по привычке юзали старую, специально замороженную версию nginx с неофициальными патчами. Но пару лет назад нам надоело и я перешёл на вышеописанный HAProxy Ingress. Он идеален. Лучшее, что мне попадалось из ингресс-контроллеров. Так что, выбора на рынке мало.
Кстати, я там слышал краем глаза, что envoy и RedHat Istio вроде скоро начнут session stickiness скоро поддерживать. Но отнюдь не все наши кубернетесы - OpenShift, а envoy я уже давно не пробовал.
| |
|
1.5, Аноним (5), 13:51, 20/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Юзаю haproxy между nginx и группой php-fpm серверов. Балансирую коннекты на основании информации о load average каждого бекенда. haproxy стал спасением после nginx-овского функционально бедного upstream.
| |
|
2.6, evkogan (?), 14:04, 20/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как раз интересно что из них в каком случае лучше.
Можете подробнее рассказать?
Зачем оставлять nginx в Вашем случае, а не перейти только на haproxy?
| |
|
3.7, Аноним (7), 14:37, 20/06/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
Потому что нжинкс - наше фсё. Отказ от нжинкса приравнивается к измене родине.
| |
|
4.8, fske (?), 15:07, 20/06/2019 [^] [^^] [^^^] [ответить]
| +12 +/– |
Вот обязательно найдется дурачек, вроде тебя, чтобы оставись свой высер на опеннете
| |
|
5.11, Andrey Mitrofanov_N0 (??), 15:43, 20/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Вот обязательно найдется дурачек, вроде тебя, чтобы оставись свой высер на опеннете
Не льсти себе-
Тут все такие.
- просто подойди поближе.
| |
|
|
7.13, Andrey Mitrofanov_N0 (??), 16:19, 20/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
#>>>Вот обязательно найдется дурачек,
>>Тут все такие.
> По себе остальных не судят
Да-да, именно. Все-все такие, как ты. Да. Вот прямо такие, как ты _сказал_.
| |
|
|
|
|
|
4.22, Аноним (5), 10:59, 21/06/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
>тоже интерестно мнение зачем nginx поверх
Причин много:
1. реврайты. Да, у haproxy есть подобие реврайтов. Только гибкость nginx пока что не переплюнул.
2. у haproxy нету интерфейса взаимодействия по разным протоколам с апликейшин серверами - uwsgi, fastcgi, cgi. Да, можно все свести к uwsgi + http взаимодействию. Но на то время было быстрее и проще оставить nginx.
3. http/2 + разные фишки типа fastopen, reuserport, accept_filter=httpready, accept_filter=dataready, so_keepalive, {uwsgi|fastcgi}_cache, open_file_cache и прочее. Возможно часть этого и есть в haproxy, но в nginx все это обкатано годами и гарантированно работает.
3. остановились на LA потому, что бекенды с разным железом и нагрузкой помимо самих апликейшин серверов. А LA хоть как-то объективно отображает загруженность ноды.
| |
|
5.31, хотел спросить (?), 03:31, 22/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> - uwsgi, fastcgi, cgi. Да, можно все свести к uwsgi +
> http взаимодействию. Но на то время было быстрее и проще оставить
> nginx.
> 3. http/2 + разные фишки типа fastopen, reuserport, accept_filter=httpready, accept_filter=dataready,
> so_keepalive, {uwsgi|fastcgi}_cache, open_file_cache и прочее. Возможно часть
> этого и есть в haproxy, но в nginx все это обкатано
> годами и гарантированно работает.
> 3. остановились на LA потому, что бекенды с разным железом и нагрузкой
> помимо самих апликейшин серверов. А LA хоть как-то объективно отображает загруженность
> ноды.
спасибо )
| |
|
|
|
2.15, Аноним (15), 16:58, 20/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Чем least_conn в nginx не устроил, который чуть менее, чем всегда будет эффективнее балансировки по la?
| |
|
3.24, Аноним (24), 13:07, 21/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Чем least_conn в nginx не устроил, который чуть менее, чем всегда будет эффективнее балансировки по la?
Тем, что least_conn ориентируется лишь на колчество соединений к каждому бекенду не взирая на нагрузку которую они создают. Ведь открытие обычной страницы сайта отличается от, к примеру, запроса на генерацию sitemap или rss ленты. В случае с haproxy + agent-check динамически меняется вес каждого бекенда исходя и текущей нагрузки.
| |
|
4.26, Аноним (26), 15:30, 21/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если запрос создает больше нагрузку, то он будет дольше занимать соединение, а значит в среднем к этому бекенду будет больше соединений и least_conn будет направлять больше запросов на другой бекенд.
Вы сильно недооцениваете метод least_conn, он достаточно эффективен именно для честного распределения запросов в случае, когда они отличаются по нагрузке.
| |
|
5.27, Аноним (24), 16:13, 21/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Вы сильно недооцениваете метод least_conn
Судя по всему, вы сильно переоцениваете этот метод. Пример: по велению святого рандома, 70-80% тяжелых запросов на генерацию rss попадет на один из бекендов. В итоге имеем одинаковое количество коннектов но один из бекендов оказывается перегруженным. Не стОит забывать, что разные запросы создают разную нагрузку на проц и I/O диска, даже при одинаковом времени выполнения. Динамически меняя weight каждого бекенда на основании LA и достигается более менее равномерная нагрузка. Вот пример: https://prnt.sc/o4vamk (смотреть 1-й и 3-й графики). Только следует учесть, что это разные сервера, с разным железом и разной нагрузкой помимо php воркеров.
| |
|
6.28, Аноним (26), 20:45, 21/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Включите least_conn и получите точно такую же картинку. Не смогут у вас 70% тяжелых запросов попасть на один бекенд как раз благодаря least_conn-у. В этом месте нет рандома. Он будет всегда выбирать наименее нагруженный бекенд. А наименее нагруженным всегда будет тот, который меньше занят тяжелыми запросами.
Да, запросы создают разную нагрузку, но там же вытесняющая многозадачность. Тяжелый запрос просто отнимет ресурсы и время у других запросов на том же бекенде и он не сможет конкурировать с менее нагруженным. В результате сразу произойдет увеличение числа соединений с ним и least_conn перераспределит запросы на менее нагруженный. Причем время реакции у такой системы будет значительно выше, чем в случае любого способа измерять и передавать LA.
| |
6.29, Аноним (26), 20:49, 21/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Разумеется, что если сервера разные по производительности, то нужно правильно выставить веса.
| |
|
7.30, Аноним (5), 03:15, 22/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>нужно правильно выставить веса
А как их правильно выставить если на сервере есть нагрузка помимо php воркеров? При статических весах сервак будет либо простаивать, либо перегружен.
| |
|
|
|
|
|
2.16, Аноним (16), 18:14, 20/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Как-то сомнительно. Ничего что LA обладает значительной лейтенси и не пригоден для балансировки в реальном времени?
| |
|
3.23, Аноним (5), 11:02, 21/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Ничего что LA обладает значительной лейтенси и не пригоден для балансировки в реальном времени?
Если коннектов очень большое количество и на обработку каждого запроса тратится сравнительно мало времени, то эта лейтенси не играет большой роли.
| |
|
|
1.9, vitalif (ok), 15:12, 20/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А он кстати у всех жрет? Я через него постгрю проксирую, и если тупо дамп льешь, оно жрет ну так... 50-80% cpu
| |
1.21, Ваш Анонимус (?), 02:49, 21/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Представлен новый API Data Plan, позволяющий на лету управлять настройками HAProxy через REST Web API.
Ну блин, из-за отсутствия этого в предыдущем хапрокси, пришлось свой написать. :(
| |
1.25, Рихад (?), 14:25, 21/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Они бы текущее пофиксили, чем фичи клепать. Примерно раз в 15-20 дней становится невозможным подключиться к удаленному бякенду (например к мейл хабу), он помечается как DOWN и ничего кроме релоада не позволяет более подключиться к нему через haproxy, даже если сам удаленный сервис уже доступен. Чтобы обойти этот баг были вынуждены повесить проверялку в cron, которая парсит логи и релоадит если надо.
| |
1.33, LeNiN (ok), 22:41, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
reload теперь, интересно, HAProxy умеет сам делать без обрыва соединений? Раньше вроде было только костылями, и без гарантий что соединения переживут это.
| |
|