https://www.opennet.ru/openforum/vsluhforumID3/117677.html Опубликован (https://www.haproxy.com/blog/haproxy-2-0-and-beyond/) релиз балансировщика нагрузки HAProxy 2.0 (http://www.haproxy.org), позволяющего распределять HTTP-трафик и произвольные TCP-запросы между группой серверов, учитывая множество факторов (например, проверяет доступность серверов, оценивает уровень нагрузки, имеет средства противостояния DDoS) и проводит первичную фильтрацию данных (например, можно разбирать HTTP-заголовки, отфильтровывать передачу некорректных параметров запроса, блокировать подстановку SQL и XSS, подключать агенты обработки контента). HAProxy также может применяться (https://www.haproxy.com/solutions/microservices/) для координации взаимодействия компонентов в системах на базе архитектуры микросервисов. Код проекта написан на языке Си и поставляется (http://git.haproxy.org/) под лицензией GPLv2. Проект используется на многих крупных сайтах, включая Airbnb, Alibaba, GitHub, Imgur, Instagram, Reddit, StackOverflow, Tumblr, Twitter и Vimeo.<br><br><br><br>Ключевые особенности выпуска:<br><br><br>- https://www.opennet.ru/openforum/vsluhforumID3/117677.html#33 Wed, 26 Jun 2019 19:41:47 GMT reload теперь, интересно, HAProxy умеет сам делать без обрыва соединений? Раньше вроде было только костылями, и без гарантий что соединения переживут это.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#32 Mon, 24 Jun 2019 09:57:42 GMT Там же есть "веса" в нжиксе то ... не подошло ?<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#31 Sat, 22 Jun 2019 00:31:28 GMT &gt;[оверквотинг удален]<br>&gt; - uwsgi, fastcgi, cgi. Да, можно все свести к uwsgi + <br>&gt; http взаимодействию. Но на то время было быстрее и проще оставить <br>&gt; nginx.<br>&gt; 3. http/2 + разные фишки типа fastopen, reuserport, accept_filter=httpready, accept_filter=dataready, <br>&gt; so_keepalive, {uwsgi&#124;fastcgi}_cache, open_file_cache и прочее. Возможно часть <br>&gt; этого и есть в haproxy, но в nginx все это обкатано <br>&gt; годами и гарантированно работает.<br>&gt; 3. остановились на LA потому, что бекенды с разным железом и нагрузкой <br>&gt; помимо самих апликейшин серверов. А LA хоть как-то объективно отображает загруженность <br>&gt; ноды.<br><br>спасибо )<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#30 Sat, 22 Jun 2019 00:15:02 GMT &gt;нужно правильно выставить веса<br><br>А как их правильно выставить если на сервере есть нагрузка помимо php воркеров? При статических весах сервак будет либо простаивать, либо перегружен.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#29 Fri, 21 Jun 2019 17:49:47 GMT Разумеется, что если сервера разные по производительности, то нужно правильно выставить веса.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#28 Fri, 21 Jun 2019 17:45:30 GMT Включите least_conn и получите точно такую же картинку. Не смогут у вас 70% тяжелых запросов попасть на один бекенд как раз благодаря least_conn-у. В этом месте нет рандома. Он будет всегда выбирать наименее нагруженный бекенд. А наименее нагруженным всегда будет тот, который меньше занят тяжелыми запросами.<br><br>Да, запросы создают разную нагрузку, но там же вытесняющая многозадачность. Тяжелый запрос просто отнимет ресурсы и время у других запросов на том же бекенде и он не сможет конкурировать с менее нагруженным. В результате сразу произойдет увеличение числа соединений с ним и least_conn перераспределит запросы на менее нагруженный. Причем время реакции у такой системы будет значительно выше, чем в случае любого способа измерять и передавать LA.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#27 Fri, 21 Jun 2019 13:13:11 GMT &gt;Вы сильно недооцениваете метод least_conn<br><br>Судя по всему, вы сильно переоцениваете этот метод. Пример: по велению святого рандома, 70-80% тяжелых запросов на генерацию rss попадет на один из бекендов. В итоге имеем одинаковое количество коннектов но один из бекендов оказывается перегруженным. Не стОит забывать, что разные запросы создают разную нагрузку на проц и I/O диска, даже при одинаковом времени выполнения. Динамически меняя weight каждого бекенда на основании LA и достигается более менее равномерная нагрузка. Вот пример: https://prnt.sc/o4vamk (смотреть 1-й и 3-й графики). Только следует учесть, что это разные сервера, с разным железом и разной нагрузкой помимо php воркеров.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#26 Fri, 21 Jun 2019 12:30:23 GMT Если запрос создает больше нагрузку, то он будет дольше занимать соединение, а значит в среднем к этому бекенду будет больше соединений и least_conn будет направлять больше запросов на другой бекенд.<br><br>Вы сильно недооцениваете метод least_conn, он достаточно эффективен именно для честного распределения запросов в случае, когда они отличаются по нагрузке.<br> https://www.opennet.ru/openforum/vsluhforumID3/117677.html#25 Fri, 21 Jun 2019 11:25:26 GMT Они бы текущее пофиксили, чем фичи клепать. Примерно раз в 15-20 дней становится невозможным подключиться к удаленному бякенду (например к мейл хабу), он помечается как DOWN и ничего кроме релоада не позволяет более подключиться к нему через haproxy, даже если сам удаленный сервис уже доступен. Чтобы обойти этот баг были вынуждены повесить проверялку в cron, которая парсит логи и релоадит если надо.<br>