Diferencia entre maxconn global y servidor maxconn haproxy

91

Tengo una pregunta sobre mi configuración 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

Como puede ver, es sencillo, pero estoy un poco confundido acerca de cómo funcionan las propiedades de maxconn.

Está el global y el maxconn en el servidor, en el bloque de escucha. Mi pensamiento es el siguiente: el global gestiona el número total de conexiones que haproxy, como servicio, pondrá en cola o procesará al mismo tiempo. Si el número supera eso, ¿mata la conexión o se agrupa en algún socket de Linux? No tengo idea de lo que sucede si el número supera los 4000.

Luego, tiene la propiedad maxconn del servidor establecida en 15. En primer lugar, lo configuré en 15 porque mi php-fpm, esto se reenvía a un servidor separado, solo tiene tantos procesos secundarios que puede usar, así que me aseguro de estar agrupando las solicitudes aquí, en lugar de en php-fpm. Lo que creo que es más rápido.

Pero volviendo al tema, mi teoría sobre este número es que a cada servidor en este bloque solo se le enviarán 15 conexiones a la vez. Y luego las conexiones esperarán un servidor abierto. Si tuviera cookies, las conexiones esperarían a que el servidor abierto CORRECTA. Pero no lo hago.

Entonces las preguntas son:

  1. ¿Qué sucede si las conexiones globales superan los 4000? ¿Mueren? ¿O agruparse en Linux de alguna manera?
  2. ¿La conexión global está relacionada con las conexiones del servidor, aparte del hecho de que no puede tener un número total de conexiones de servidor mayor que global?
  3. Al calcular las conexiones globales, ¿no debería ser la cantidad de conexiones agregadas en la sección del servidor, más un cierto porcentaje para la agrupación? Y, obviamente, tienes otras restricciones en las conexiones, pero ¿realmente cuántas quieres enviar a los proxies?

Gracias de antemano.

chantheman
fuente

Respuestas:

166

Willy me envió una respuesta por correo electrónico. Pensé que lo compartiría. Sus respuestas están en negrita.

Tengo una pregunta sobre mi configuración 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

Como puede ver, es sencillo, pero estoy un poco confundido acerca de cómo funcionan las propiedades de maxconn.

Está el global y el maxconn en el servidor, en el bloque de escucha.

Y también hay otro en el bloque de escucha que tiene un valor predeterminado como 2000.

Mi pensamiento es el siguiente: el global gestiona el número total de conexiones que haproxy, como servicio, pondrá en cola o procesará al mismo tiempo.

Correcto. Es el número máximo de conexiones simultáneas por proceso.

Si el número supera eso, ¿mata la conexión o se agrupa en algún socket de Linux?

Cuanto más tarde, simplemente deja de aceptar nuevas conexiones y permanecen en la cola de sockets del kernel. El número de sockets que se pueden poner en cola está determinado por el mínimo de (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog y maxconn del bloque de escucha).

No tengo idea de lo que sucede si el número supera los 4000.

Las conexiones en exceso esperan a que se complete otra antes de ser aceptadas. Sin embargo, mientras la cola del kernel no esté saturada, el cliente ni siquiera se da cuenta de esto, ya que la conexión se acepta a nivel TCP pero no se procesa. Entonces, el cliente solo nota cierto retraso para procesar la solicitud. Pero en la práctica, el maxconn del bloque de escucha es mucho más importante, ya que por defecto es más pequeño que el global. El maxconn de escucha limita el número de conexiones por oyente. En general, es aconsejable configurarlo para el número de conexiones que desea para el servicio, y configurar el maxconn global al número máximo de conexiones que deja que maneje el proceso haproxy. Cuando solo tiene un servicio, ambos pueden configurarse con el mismo valor. Pero cuando tienes muchos servicios,

Luego, tiene la propiedad maxconn del servidor establecida en 15. En primer lugar, lo configuré en 15 porque mi php-fpm, esto se reenvía a un servidor separado, solo tiene tantos procesos secundarios que puede usar, así que me aseguro de estar agrupando las solicitudes aquí, en lugar de en php-fpm. Lo que creo que es más rápido.

Sí, no solo debería ser más rápido, sino que permite a haproxy encontrar otro servidor disponible siempre que sea posible, y también le permite eliminar la solicitud en la cola si el cliente presiona "detener" antes de que la conexión se reenvíe al servidor.

Pero volviendo al tema, mi teoría sobre este número es que a cada servidor en este bloque solo se le enviarán 15 conexiones a la vez. Y luego las conexiones esperarán un servidor abierto. Si tuviera cookies, las conexiones esperarían a que el servidor abierto CORRECTA. Pero no lo hago.

Ese es exactamente el principio. Hay una cola por proxy y una cola por servidor. Las conexiones con una cookie de persistencia van a la cola del servidor y otras conexiones van a la cola del proxy. Sin embargo, dado que en su caso no se configura ninguna cookie, todas las conexiones van a la cola del proxy. Puede ver el diagrama doc / queueing.fig en fuentes haproxy si lo desea, explica cómo / dónde se toman las decisiones.

Entonces las preguntas son:

  1. ¿Qué sucede si las conexiones globales superan los 4000? ¿Mueren? ¿O agruparse en Linux de alguna manera?

    Están en cola en Linux. Una vez que abruma la cola del kernel, se colocan en el kernel.

  2. ¿La conexión global está relacionada con las conexiones del servidor, aparte del hecho de que no puede tener un número total de conexiones de servidor mayor que global?

    No, la configuración de la conexión global y del servidor es independiente.

  3. Al calcular las conexiones globales, ¿no debería ser la cantidad de conexiones agregadas en la sección del servidor, más un cierto porcentaje para la agrupación? Y, obviamente, tiene otras restricciones en las conexiones, pero ¿realmente es cuántas desea enviar a los proxies?

    Lo hiciste bien. Si el tiempo de respuesta de su servidor es corto, no hay nada de malo en poner en cola miles de conexiones para atender solo unas pocas a la vez, porque reduce sustancialmente el tiempo de procesamiento de solicitudes. Prácticamente, establecer una conexión hoy en día toma alrededor de 5 microsegundos en una LAN gigabit. Así que tiene mucho sentido dejar que haproxy distribuya las conexiones lo más rápido posible desde su cola a un servidor con un maxconn muy pequeño. Recuerdo que un sitio de juegos puso en cola más de 30000 conexiones simultáneas y se ejecutó con una cola de 30 por servidor. Era un servidor apache y apache es mucho más rápido con un número reducido de conexiones que con un gran número. Pero para esto realmente necesita un servidor rápido, porque no No desea que todos sus clientes estén en cola esperando una ranura de conexión porque el servidor está esperando una base de datos, por ejemplo. También algo que funciona muy bien es dedicar servidores. Si su sitio tiene muchas estáticas, puede dirigir las solicitudes estáticas a un grupo de servidores (o cachés) para que no ponga en cola solicitudes estáticas en ellos y que las solicitudes estáticas no consuman ranuras de conexión costosas. Esperando que esto ayude, Willy

chantheman
fuente
10
Gracias por publicar esto.
Tarántula
9
Tengo un haproxy que actúa como proxy para otros 200 backend. Una vez que un backend fue DDOS-ed con aproximadamente ~ 300k conexiones / segundo, todos los demás backend mueren. Con el valor maxconn 2048 en el servidor backend (bajo ddos), nuestro haproxy funciona bien. Muchas gracias, me salvaste una noche :)
hungnv