Разница между глобальным maxconn и сервером maxconn haproxy

91

У меня вопрос по конфигурации моего haproxy:

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log         127.0.0.1 syslog emerg
    maxconn     4000
    quiet
    user        haproxy
    group       haproxy
    daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will 
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode        http
    log         global
    option      abortonclose
    option      dontlognull
    option      httpclose
    option      httplog
    option      forwardfor
    option      redispatch
    timeout connect 10000 # default 10 second time out if a backend is not found
    timeout client 300000 # 5 min timeout for client
    timeout server 300000 # 5 min timeout for server
    stats       enable

listen  http_proxy  localhost:81

    balance     roundrobin
    option      httpchk GET /empty.html
    server      server1 myip:80 maxconn 15 check inter 10000
    server      server2 myip:80 maxconn 15 check inter 10000

Как видите, это просто, но я немного смущен тем, как работают свойства maxconn.

В блоке прослушивания на сервере есть глобальный и maxconn. Я думаю так: глобальный управляет общим количеством подключений, которые haproxy, как сервис, будет ставить в очередь или обрабатывать одновременно. Если число становится выше этого, он либо убивает соединение, либо пулы в каком-то сокете linux? Я понятия не имею, что произойдет, если число станет больше 4000.

Затем у вас есть свойство server maxconn, установленное на 15. Во-первых, я установил его на 15, потому что мой php-fpm, он пересылается на отдельный сервер, имеет только такое количество дочерних процессов, которые он может использовать, поэтому я уверен, что объединение запросов здесь, а не в php-fpm. Что, я думаю, быстрее.

Но, возвращаясь к теме, моя теория об этом количестве заключается в том, что каждому серверу в этом блоке будет отправляться только 15 соединений за раз. И тогда соединения будут ждать открытого сервера. Если бы у меня были куки-файлы, соединения будут ждать ПРАВИЛЬНОГО открытого сервера. Но я этого не делаю.

Итак, вопросы:

  1. Что произойдет, если количество глобальных подключений превысит 4000? Они умирают? Или пул в линуксе как-нибудь?
  2. Связано ли глобальное соединение с подключениями к серверу, кроме того факта, что у вас не может быть общего количества подключений к серверу больше глобального?
  3. При выяснении глобальных подключений, не должно ли это быть количество подключений, добавленных в разделе сервера, плюс определенный процент для пула? И, очевидно, у вас есть другие ограничения на соединения, но действительно сколько вы хотите отправить на прокси?

Заранее спасибо.

Chantheman
источник

Ответы:

167

Вилли получил ответ по электронной почте. Я думал, что поделюсь им. Его ответы выделены жирным шрифтом.

У меня вопрос по конфигурации моего haproxy:

   #---------------------------------------------------------------------
   # Global settings
   #---------------------------------------------------------------------
   global
       log         127.0.0.1 syslog emerg
       maxconn     4000
       quiet
       user        haproxy
       group       haproxy
       daemon
   #---------------------------------------------------------------------
   # common defaults that all the 'listen' and 'backend' sections will 
   # use if not designated in their block
   #---------------------------------------------------------------------
   defaults
       mode        http
       log         global
       option      abortonclose
       option      dontlognull
       option      httpclose
       option      httplog
       option      forwardfor
       option      redispatch
       timeout connect 10000 # default 10 second time out if a backend is not found
       timeout client 300000 # 5 min timeout for client
       timeout server 300000 # 5 min timeout for server
       stats       enable

   listen  http_proxy  localhost:81

       balance     roundrobin
       option      httpchk GET /empty.html
       server      server1 myip:80 maxconn 15 check inter 10000
       server      server2 myip:80 maxconn 15 check inter 10000

Как видите, это просто, но я немного смущен тем, как работают свойства maxconn.

В блоке прослушивания на сервере есть глобальный и maxconn.

И есть еще один в блоке прослушивания, который по умолчанию равен 2000.

Я думаю так: глобальный управляет общим количеством подключений, которые haproxy, как сервис, будет обрабатывать в очереди или обрабатывать одновременно.

Верный. Это максимальное количество одновременных подключений для каждого процесса.

Если число становится выше этого, он либо убивает соединение, либо пулы в каком-то сокете linux?

Позднее он просто перестает принимать новые соединения, и они остаются в очереди сокетов в ядре. Количество сокетов в очереди определяется минимальным значением (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog и maxconn блока прослушивания).

Я понятия не имею, что произойдет, если число станет больше 4000.

Лишние соединения ждут завершения другого, прежде чем будут приняты. Однако, пока очередь ядра не заполнена, клиент даже не замечает этого, поскольку соединение принимается на уровне TCP, но не обрабатывается. Таким образом, клиент замечает лишь некоторую задержку обработки запроса. Но на практике maxconn блока прослушивания намного важнее, так как по умолчанию он меньше глобального. Параметр maxconn прослушивания ограничивает количество подключений на одного слушателя. В общем, разумно настроить его на количество подключений, которое вы хотите для службы, и настроить глобальный maxconn на максимальное количество подключений, которое вы разрешаете процессу haproxy. Если у вас только одна служба, для обеих может быть установлено одинаковое значение. Но когда у вас много услуг,

Затем у вас есть свойство server maxconn, установленное на 15. Во-первых, я установил его на 15, потому что мой php-fpm, он пересылается на отдельный сервер, имеет только такое количество дочерних процессов, которые он может использовать, поэтому я уверен, что объединение запросов здесь, а не в php-fpm. Что, я думаю, быстрее.

Да, это не только должно быть быстрее, но и позволяет haproxy находить другой доступный сервер, когда это возможно, а также позволяет ему убивать запрос в очереди, если клиент нажимает «стоп» до того, как соединение будет перенаправлено на сервер.

Но, возвращаясь к теме, моя теория об этом количестве заключается в том, что каждому серверу в этом блоке будет отправляться только 15 соединений за раз. И тогда соединения будут ждать открытого сервера. Если бы у меня были куки-файлы, соединения будут ждать ПРАВИЛЬНОГО открытого сервера. Но я этого не делаю.

Это в точности принцип. Есть очередь на прокси и очередь на сервер. Соединения с сохраняемым cookie попадают в очередь сервера, а другие соединения - в очередь прокси. Однако, поскольку в вашем случае cookie не настроен, все подключения попадают в очередь прокси. Вы можете посмотреть диаграмму doc / queuing.fig в источниках haproxy, если хотите, она объясняет, как и где принимаются решения.

Итак, вопросы:

  1. Что произойдет, если количество глобальных подключений превысит 4000? Они умирают? Или пул в линуксе как-нибудь?

    В Linux они стоят в очереди. Как только вы перегружаете очередь ядра, они теряются в ядре.

  2. Связано ли глобальное соединение с подключениями к серверу, кроме того факта, что у вас не может быть общего количества подключений к серверу больше глобального?

    Нет, глобальные настройки и настройки подключения к серверу не зависят.

  3. При выяснении глобальных подключений, не должно ли это быть количество подключений, добавленных в раздел сервера, плюс определенный процент для пула? И, очевидно, у вас есть другие ограничения на соединения, но действительно сколько вы хотите отправить на прокси?

    Вы все правильно поняли. Если время отклика вашего сервера невелико, нет ничего плохого в том, чтобы поставить в очередь тысячи соединений для обслуживания только нескольких одновременно, поскольку это существенно сокращает время обработки запроса. На практике установление соединения в настоящее время занимает около 5 микросекунд в гигабитной локальной сети. Поэтому имеет смысл разрешить haproxy максимально быстро распределять соединения из своей очереди на сервер с очень маленьким maxconn. Я помню, как один игровой сайт создавал в очереди более 30000 одновременных подключений и работал с очередью по 30 на сервер! Это был сервер apache, и apache намного быстрее при небольшом количестве подключений, чем при большом. Но для этого вам действительно нужен быстрый сервер, потому что вы не Я хочу, чтобы все ваши клиенты стояли в очереди в ожидании слота подключения, потому что, например, сервер ожидает базу данных. Также очень хорошо работает выделение серверов. Если на вашем сайте много статики, вы можете направить статические запросы в пул серверов (или кешей), чтобы не ставить статические запросы на них в очередь и чтобы статические запросы не занимали дорогие слоты для подключения. Надеясь, что это поможет, Вилли

Chantheman
источник
10
Спасибо, что разместили это.
Tarantula
9
У меня есть один haproxy, который проксирует около 200 других серверов. Как только бэкэнд подвергся DDOS-атаке со скоростью ~ 300 тыс. Соединений в секунду, все остальные бэкэнд умирают. При значении maxconn 2048 на внутреннем сервере (под ddos) наш haproxy работает нормально. Большое вам спасибо, вы спасли меня однажды ночью :)
hungnv