The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от opennews (??), 20-Июн-19, 12:12 
Опубликован (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.

Ключевые особенности выпуска:


-  Представлен новый API Data Plan (https://github.com/haproxytech/dataplaneapi), позволяющий на лету управлять настройками HAProxy через REST Web API. В том числе можно динамически добавлять и удалять бэкенды и серверы, создавать ACL, изменять маршрутизацию запросов, изменять привязки обработчиков к IP;

-  Добавлена директива nbthread, позволяющая настроить число потоков, используемых в HAProxy для оптимизации работа на многоядерных CPU. По умолчанию число рабочих потоков выбирается в зависимости от доступных в текущем окружении ядер CPU, а в облачных окружениях по умолчанию устанавливается один поток. Для задания жёстких лимитов добавлены сборочные опции MAX_THREADS и MAX_PROCS, ограничивающие верхний предел на число потоков и процессов;

-  Упрощено использование директивы bind для привязки обработчиков к сетевым адресам. При настройке теперь не обязательно определение параметров  процесса - по умолчанию соединения будут распределяться по потокам в зависимости от числа активных соединений.

-  Упрощена настройка логов при запуске в изолированных контейнерах - лог теперь можно направить в  stdout и stderr, а также в любой существующий файловый дескриптор (например, "log fd@1 local0");

-  Включена по умолчанию поддержка HTX (Native HTTP Representation), позволяющего обеспечить балансировку при применении расширенных возможностей, таких как end-to-end HTTP/2, Layer 7 Retries и gRPC. HTX не заменяет  заголовки по месту, а сводит операцию изменения к удалению и добавлению нового заголовка в конец списка, что позволяет манипулировать любыми расширенными вариантами протокола HTTP, сохраняя исходную семантику заголовков и позволяя добиться более высокой производительности при трансляции HTTP/2 в HTTP/1.1 и наоборот;

-  Добавлена официальная поддержка режима End-to-End HTTP/2 (обработка всех стадий в HTTP/2, в том числе обращений к бэкенду, а не только взаимодействие прокси с клиентом);

-  Реализована полная поддержка двунаправленного проксирования протокола gRPC c   возможностью разбора потоков gRPC, выделяя отдельные сообщения, отражая gRPC-трафик в логе и отфильтровывая сообщения при помощи ACL. gRPC позволяет организовать работу микросервисов на различных языках программирования, которые взаимодействуют между собой при помощи универсального API. Сетевое взаимодействие в gRPC реализовано поверх протокола HTTP/2 и базируется на применении Protocol Buffers для сериализации данных.

-  Добавлена поддержка режима "Layer 7 Retries", позволяющего отправлять повторные HTTP-запросы в случае программных сбоев, не связанных с проблемами установки сетевого соединения (например, при отсутствии ответа или пустого ответа на POST-запрос). Для отключения режима в опцию "http-request" добавлен флаг "disable-l7-retry", а для тонкой настройки в секциях defaults, listen и backend появилась опция "retry-on". Доступны следующие признаки для повторной отправки: all-retryable-errors, none, conn-failure, empty-response, junk-response, response-timeout, 0rtt-rejected, а также привязка к возвращаемым кодам состояния (404 и т.п.);

-  Реализован новый менеджер процессов (Process Manager), позволяющий настроить вызов внешних исполняемых файлов с обработчиками для HAProxy.
Например, в виде такого внешнего обработчика реализован API Data Plan (/usr/sbin/dataplaneapi), а также различные движки Offload-обработки потоков;

-  Для .NET Core, Go, Lua и Python добавлены биндинги для разработки расширений SPOE (Stream Processing Offload Engine) и SPOP (Stream Processing Offload Protocol). Ранее поддерживалась разработка расширения только на Си;

-  Добавлен внешний обработчик spoa-mirror (/usr/sbin/spoa-mirror) для зеркалирования запросов на отдельный сервер (например, для копирования части рабочего трафика для тестирования экспериментального окружения на реальной нагрузке);

-  Представлен  HAProxy Kubernetes Ingress Controller (https://github.com/haproxytech/kubernetes-ingress/) для обеспечения интеграции с платформой Kubernetes;

-  Добавлена встроенная поддержка экспорта статистики в  систему мониторинга Prometheus (https://prometheus.io/);
-  Расширен протокол Peers Protocol, используемый для обмена информацией с другими узлами с HAProxy. В том числе добавлена поддержка Heartbeat и шифрованной передачи данных;

-  В директиву "log" добавлен параметр "sample", позволяющий сбрасывать в лог лишь часть запросов, например 1 из 10, для формирование аналитической выборки;

-  Добавлен режим автоматического профилирования (директива profiling.tasks, которая может принимать значения auto, on и off). Автоматическое профилирование включается в случае если средняя величина задержки превышает отметку в 1000 мс. Для просмотра данных профилирования в  Runtime API добавлена команда "show profiling" или имеется возможность сброса статистики в лог;

-  Добавлена поддержка обращения к бэкенд-серверам с использованием протокола SOCKS4;

-  Добавлена оконечная (end-to-end, на своём пути обработки запроса, охватывая бэкенд) поддержка механизма быстрого открытия TCP-соединений (TFO - TCP Fast Open, RFC 7413), который позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения и даёт возможность отправки данных на начальном этапе установки соединения;

-  Добавлены новые действия:


-  "http-request replace-uri" для замены URL с использованием регулярного выражения;
-  "tcp-request content do-resolve" и "http-request do-resolve" для резолвинга имени хоста;
-   "tcp-request content set-dst" и "tcp-request content set-dst-port"  для подстановки целевого IP-адреса и порта.


-  Добавлены новые модули конвертирования:


-  aes_gcm_dev для расшифровки потоков с использованием      алгоритмов AES128-GCM, AES192-GCM и AES256-GCM;
-  protobuf для извлечения полей из сообщений Protocol Buffers;
-  ungrpc  для извлечения полей     из сообщений gRPC.


URL: https://www.haproxy.com/blog/haproxy-2-0-and-beyond/
Новость: https://www.opennet.dev/opennews/art.shtml?num=50904

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от 1 (??), 20-Июн-19, 12:12 
>Представлен новый API Data Plan, позволяющий на лету управлять настройками HAProxy через REST Web API. В том числе можно динамически добавлять и удалять бэкенды и серверы, создавать ACL, изменять маршрутизацию запросов, изменять привязки обработчиков к IP;

Envoy больше не нужен?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +1 +/
Сообщение от Аноним (2), 20-Июн-19, 12:47 
Ура, конкуренция в области микросервисов!
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от zo0Memail (ok), 20-Июн-19, 13:18 
поясните
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  –5 +/
Сообщение от Некто (??), 20-Июн-19, 13:17 
тебе - нет
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

17. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Лапчатый девляпс бубунтёнак (?), 20-Июн-19, 21:31 
От требований зависит.

У нас например, cookie-based session stickiness обязателен. Мы по привычке юзали старую, специально замороженную версию nginx с неофициальными патчами. Но пару лет назад нам надоело и я перешёл на вышеописанный HAProxy Ingress. Он идеален. Лучшее, что мне попадалось из ингресс-контроллеров. Так что, выбора на рынке мало.

Кстати, я там слышал краем глаза, что envoy и RedHat Istio вроде скоро начнут session stickiness скоро поддерживать. Но отнюдь не все наши кубернетесы - OpenShift, а envoy я уже давно не пробовал.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +7 +/
Сообщение от Аноним (5), 20-Июн-19, 13:51 
Юзаю haproxy между nginx и группой php-fpm серверов. Балансирую коннекты на основании информации о load average каждого бекенда. haproxy стал спасением после nginx-овского функционально бедного upstream.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +1 +/
Сообщение от evkogan (?), 20-Июн-19, 14:04 
Как раз интересно что из них в каком случае лучше.
Можете подробнее рассказать?
Зачем оставлять nginx в Вашем случае, а не перейти только на haproxy?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  –3 +/
Сообщение от Аноним (7), 20-Июн-19, 14:37 
Потому что нжинкс - наше фсё. Отказ от нжинкса приравнивается к измене родине.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +12 +/
Сообщение от fske (?), 20-Июн-19, 15:07 
Вот обязательно найдется дурачек, вроде тебя, чтобы оставись свой высер на опеннете
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +1 +/
Сообщение от Andrey Mitrofanov_N0 (??), 20-Июн-19, 15:43 
> Вот обязательно найдется дурачек, вроде тебя, чтобы оставись свой высер на опеннете

Не льсти себе-

Тут все такие.

- просто подойди поближе.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от fske (?), 20-Июн-19, 16:14 
>Тут все такие.

По себе остальных не судят

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +1 +/
Сообщение от Andrey Mitrofanov_N0 (??), 20-Июн-19, 16:19 
#>>>Вот обязательно найдется дурачек,
>>Тут все такие.
> По себе остальных не судят

Да-да, именно.  Все-все такие, как ты.  Да.  Вот прямо такие, как ты _сказал_.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

20. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +1 +/
Сообщение от хотел спросить (?), 21-Июн-19, 00:28 
тоже интерестно мнение зачем nginx поверх
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

22. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +4 +/
Сообщение от Аноним (5), 21-Июн-19, 10:59 
>тоже интерестно мнение зачем 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 хоть как-то объективно отображает загруженность ноды.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от хотел спросить (?), 22-Июн-19, 03:31 
>[оверквотинг удален]
> - 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 хоть как-то объективно отображает загруженность
> ноды.

спасибо )

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

32. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Ktoto (?), 24-Июн-19, 12:57 
Там же есть "веса" в нжиксе то ... не подошло ?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

10. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  –3 +/
Сообщение от другойАноним (?), 20-Июн-19, 15:41 
дал два к бабла nginx.com - шапрокся нафиг не нужна.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

14. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Anonymoussemail (?), 20-Июн-19, 16:36 
Можно деталей? интересно
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (15), 20-Июн-19, 16:58 
Чем least_conn в nginx не устроил, который чуть менее, чем всегда будет эффективнее балансировки по la?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

24. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (24), 21-Июн-19, 13:07 
>Чем least_conn в nginx не устроил, который чуть менее, чем всегда будет эффективнее балансировки по la?

Тем, что least_conn ориентируется лишь на колчество соединений к каждому бекенду не взирая на нагрузку которую они создают. Ведь открытие обычной страницы сайта отличается от, к примеру, запроса на генерацию sitemap или rss ленты. В случае с haproxy + agent-check динамически меняется вес каждого бекенда исходя и текущей нагрузки.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (26), 21-Июн-19, 15:30 
Если запрос создает больше нагрузку, то он будет дольше занимать соединение, а значит в среднем к этому бекенду будет больше соединений и least_conn будет направлять больше запросов на другой бекенд.

Вы сильно недооцениваете метод least_conn, он достаточно эффективен именно для честного распределения запросов в случае, когда они отличаются по нагрузке.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (24), 21-Июн-19, 16:13 
>Вы сильно недооцениваете метод least_conn

Судя по всему, вы сильно переоцениваете этот метод. Пример: по велению святого рандома, 70-80% тяжелых запросов на генерацию rss попадет на один из бекендов. В итоге имеем одинаковое количество коннектов но один из бекендов оказывается перегруженным. Не стОит забывать, что разные запросы создают разную нагрузку на проц и I/O диска, даже при одинаковом времени выполнения. Динамически меняя weight каждого бекенда на основании LA и достигается более менее равномерная нагрузка. Вот пример: https://prnt.sc/o4vamk (смотреть 1-й и 3-й графики). Только следует учесть, что это разные сервера, с разным железом и разной нагрузкой помимо php воркеров.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +2 +/
Сообщение от Аноним (26), 21-Июн-19, 20:45 
Включите least_conn и получите точно такую же картинку. Не смогут у вас 70% тяжелых запросов попасть на один бекенд как раз благодаря least_conn-у. В этом месте нет рандома. Он будет всегда выбирать наименее нагруженный бекенд. А наименее нагруженным всегда будет тот, который меньше занят тяжелыми запросами.

Да, запросы создают разную нагрузку, но там же вытесняющая многозадачность. Тяжелый запрос просто отнимет ресурсы и время у других запросов на том же бекенде и он не сможет конкурировать с менее нагруженным. В результате сразу произойдет увеличение числа соединений с ним и least_conn перераспределит запросы на менее нагруженный. Причем время реакции у такой системы будет значительно выше, чем в случае любого способа измерять и передавать LA.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (26), 21-Июн-19, 20:49 
Разумеется, что если сервера разные по производительности, то нужно правильно выставить веса.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (5), 22-Июн-19, 03:15 
>нужно правильно выставить веса

А как их правильно выставить если на сервере есть нагрузка помимо php воркеров? При статических весах сервак будет либо простаивать, либо перегружен.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

16. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  –1 +/
Сообщение от Аноним (16), 20-Июн-19, 18:14 
Как-то сомнительно. Ничего что LA обладает значительной лейтенси и не пригоден для балансировки в реальном времени?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

23. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Аноним (5), 21-Июн-19, 11:02 
>Ничего что LA обладает значительной лейтенси и не пригоден для балансировки в реальном времени?

Если коннектов очень большое количество и на обработку каждого запроса тратится сравнительно мало времени, то эта лейтенси не играет большой роли.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

9. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от vitalif (ok), 20-Июн-19, 15:12 
А он кстати у всех жрет? Я через него постгрю проксирую, и если тупо дамп льешь, оно жрет ну так... 50-80% cpu
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Онаним (?), 20-Июн-19, 21:43 
i386?
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

19. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  –1 +/
Сообщение от Аноним (19), 20-Июн-19, 21:53 
Когда завезут поддержку udp?
Nginx же умеет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Ваш Анонимус (?), 21-Июн-19, 02:49 
> Представлен новый API Data Plan, позволяющий на лету управлять настройками HAProxy через REST Web API.

Ну блин, из-за отсутствия этого в предыдущем хапрокси, пришлось свой написать. :(

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от Рихад (?), 21-Июн-19, 14:25 
Они бы текущее пофиксили, чем фичи клепать. Примерно раз в 15-20 дней становится невозможным подключиться к удаленному бякенду (например к мейл хабу), он помечается как DOWN и ничего кроме релоада не позволяет более подключиться к нему через haproxy, даже если сам удаленный сервис уже доступен. Чтобы обойти этот баг были вынуждены повесить проверялку в cron, которая парсит логи и релоадит если надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Выпуск HTTP/TCP-балансировщика HAProxy 2.0"  +/
Сообщение от LeNiN (ok), 26-Июн-19, 22:41 
reload теперь, интересно, HAProxy умеет сам делать без обрыва соединений? Раньше вроде было только костылями, и без гарантий что соединения переживут это.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру