Unterschied zwischen globalem maxconn und Server maxconn haproxy

91

Ich habe eine Frage zu meiner Haproxy-Konfiguration:

#---------------------------------------------------------------------
# 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

Wie Sie sehen, ist es unkompliziert, aber ich bin etwas verwirrt darüber, wie die maxconn-Eigenschaften funktionieren.

Es gibt die globale und die maximale Verbindung auf dem Server im Listen-Block. Mein Gedanke ist folgender: Der globale verwaltet die Gesamtzahl der Verbindungen, die Haproxy als Dienst gleichzeitig in die Warteschlange stellt oder verarbeitet. Wenn die Zahl darüber hinausgeht, wird entweder die Verbindung unterbrochen oder in einem Linux-Socket zusammengefasst? Ich habe keine Ahnung, was passiert, wenn die Zahl höher als 4000 wird.

Dann haben Sie die Server-Maxconn-Eigenschaft auf 15 gesetzt. Zunächst einmal habe ich diese auf 15 gesetzt, da meine PHP-Fpm, die auf einem separaten Server weitergeleitet wird, nur so viele untergeordnete Prozesse hat, die sie verwenden kann, also stelle ich sicher, dass ich es bin Pooling der Anfragen hier, anstatt in PHP-Fpm. Was ich denke ist schneller.

Aber zurück zum Thema, meine Theorie über diese Nummer ist, dass jedem Server in diesem Block nur 15 Verbindungen gleichzeitig gesendet werden. Und dann warten die Verbindungen auf einen offenen Server. Wenn ich Cookies aktiviert hätte, würden die Verbindungen auf den RICHTIGEN offenen Server warten. Aber ich nicht.

Fragen sind also:

  1. Was passiert, wenn die globalen Verbindungen über 4000 liegen? Sterben sie Oder irgendwie unter Linux bündeln?
  2. Bezieht sich die globale Verbindung auf die Serververbindungen, abgesehen von der Tatsache, dass Sie nicht eine größere Anzahl von Serververbindungen als global haben können?
  3. Sollte es bei der Ermittlung der globalen Verbindungen nicht die Anzahl der im Serverabschnitt hinzugefügten Verbindungen plus ein bestimmter Prozentsatz für das Pooling sein? Und natürlich haben Sie andere Einschränkungen bei den Verbindungen, aber wirklich, wie viele möchten Sie an die Proxies senden?

Vielen Dank im Voraus.

Chantheman
quelle

Antworten:

165

Willy hat mir eine Antwort per E-Mail geschickt. Ich dachte, ich würde es teilen. Seine Antworten sind fett gedruckt.

Ich habe eine Frage zu meiner Haproxy-Konfiguration:

   #---------------------------------------------------------------------
   # 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

Wie Sie sehen, ist es unkompliziert, aber ich bin etwas verwirrt darüber, wie die maxconn-Eigenschaften funktionieren.

Es gibt die globale und die maximale Verbindung auf dem Server im Listen-Block.

Und es gibt noch einen anderen im Listen-Block, der standardmäßig so etwas wie 2000 ist.

Mein Gedanke ist folgender: Der globale verwaltet die Gesamtzahl der Verbindungen, die Haproxy als Dienst gleichzeitig in die Warteschlange stellt oder verarbeitet.

Richtig. Dies ist die maximale Anzahl gleichzeitiger Verbindungen pro Prozess.

Wenn die Zahl darüber hinausgeht, wird entweder die Verbindung unterbrochen oder in einem Linux-Socket zusammengefasst?

Je später, es werden einfach keine neuen Verbindungen mehr akzeptiert und diese verbleiben in der Socket-Warteschlange im Kernel. Die Anzahl der Suiten in der Warteschlange wird durch das Minimum von (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog und das maxconn des Listenblocks) bestimmt.

Ich habe keine Ahnung, was passiert, wenn die Zahl höher als 4000 wird.

Die überschüssigen Verbindungen warten, bis eine weitere abgeschlossen ist, bevor sie akzeptiert werden. Solange die Warteschlange des Kernels jedoch nicht gesättigt ist, bemerkt der Client dies nicht einmal, da die Verbindung auf TCP-Ebene akzeptiert, aber nicht verarbeitet wird. Der Client bemerkt also nur eine Verzögerung bei der Bearbeitung der Anfrage. In der Praxis ist das maxconn des Listenblocks jedoch viel wichtiger, da es standardmäßig kleiner als das globale ist. Das maxconn des Listen begrenzt die Anzahl der Verbindungen pro Listener. Im Allgemeinen ist es ratsam, es für die Anzahl der Verbindungen zu konfigurieren, die Sie für den Dienst wünschen, und das globale maxconn für die maximale Anzahl von Verbindungen zu konfigurieren, die der Haproxy-Prozess verarbeiten lässt. Wenn Sie nur einen Dienst haben, können beide auf den gleichen Wert eingestellt werden. Aber wenn Sie viele Dienste haben,

Dann haben Sie die Server-Maxconn-Eigenschaft auf 15 gesetzt. Zunächst einmal habe ich diese auf 15 gesetzt, da meine PHP-Fpm, die auf einem separaten Server weitergeleitet wird, nur so viele untergeordnete Prozesse hat, die sie verwenden kann, also stelle ich sicher, dass ich es bin Pooling der Anfragen hier, anstatt in PHP-Fpm. Was ich denke ist schneller.

Ja, es sollte nicht nur schneller sein, sondern es ermöglicht Haproxy, wann immer möglich, einen anderen verfügbaren Server zu finden, und es ermöglicht ihm auch, die Anforderung in der Warteschlange zu beenden, wenn der Client auf "Stopp" klickt, bevor die Verbindung an den Server weitergeleitet wird.

Aber zurück zum Thema, meine Theorie über diese Nummer ist, dass jedem Server in diesem Block nur 15 Verbindungen gleichzeitig gesendet werden. Und dann warten die Verbindungen auf einen offenen Server. Wenn ich Cookies aktiviert hätte, würden die Verbindungen auf den RICHTIGEN offenen Server warten. Aber ich nicht.

Das ist genau das Prinzip. Es gibt eine Proxy-Warteschlange und eine Server-Warteschlange. Verbindungen mit einem Persistenz-Cookie werden in die Serverwarteschlange und andere Verbindungen in die Proxy-Warteschlange gestellt. Da in Ihrem Fall jedoch kein Cookie konfiguriert ist, werden alle Verbindungen in die Proxy-Warteschlange gestellt. Wenn Sie möchten, können Sie sich das Diagramm doc / queuing.fig in Haproxy-Quellen ansehen. Dort wird erläutert, wie / wo Entscheidungen getroffen werden.

Fragen sind also:

  1. Was passiert, wenn die globalen Verbindungen über 4000 liegen? Sterben sie Oder irgendwie unter Linux bündeln?

    Sie stehen unter Linux in der Warteschlange. Sobald Sie die Warteschlange des Kernels überfordert haben, werden sie im Kernel abgelegt.

  2. Bezieht sich die globale Verbindung auf die Serververbindungen, abgesehen von der Tatsache, dass Sie nicht eine größere Anzahl von Serververbindungen als global haben können?

    Nein, globale und Serververbindungseinstellungen sind unabhängig.

  3. Sollte es bei der Ermittlung der globalen Verbindungen nicht die Anzahl der im Serverabschnitt hinzugefügten Verbindungen plus ein bestimmter Prozentsatz für das Pooling sein? Und natürlich haben Sie andere Einschränkungen bei den Verbindungen, aber wirklich, wie viele möchten Sie an die Proxies senden?

    Du hast es richtig. Wenn die Antwortzeit Ihres Servers kurz ist, ist es nichts Falsches, Tausende von Verbindungen in die Warteschlange zu stellen, um jeweils nur wenige zu bedienen, da dies die Verarbeitungszeit für Anforderungen erheblich verkürzt. Praktisch dauert das Herstellen einer Verbindung heutzutage in einem Gigabit-LAN ​​etwa 5 Mikrosekunden. Es ist daher sehr sinnvoll, haproxy die Verbindungen so schnell wie möglich von seiner Warteschlange auf einen Server mit einem sehr kleinen maxconn verteilen zu lassen. Ich erinnere mich, dass eine Spieleseite mehr als 30000 gleichzeitige Verbindungen in die Warteschlange stellte und mit einer Warteschlange von 30 pro Server lief! Es war ein Apache-Server, und Apache ist mit einer kleinen Anzahl von Verbindungen viel schneller als mit einer großen Anzahl. Aber dafür brauchst du wirklich einen schnellen Server, weil du nicht ' Sie möchten nicht, dass alle Ihre Clients in der Warteschlange auf einen Verbindungssteckplatz warten, da der Server beispielsweise auf eine Datenbank wartet. Was auch sehr gut funktioniert, ist das Widmen von Servern. Wenn Ihre Site über viele statische Daten verfügt, können Sie die statischen Anforderungen an einen Pool von Servern (oder Caches) weiterleiten, damit Sie keine statischen Anforderungen in die Warteschlange stellen und die statischen Anforderungen keine teuren Verbindungssteckplätze verschlingen. Ich hoffe, das hilft, Willy

Chantheman
quelle
10
Vielen Dank für die Veröffentlichung.
Tarantula
9
Ich habe einen Haproxy, der für ungefähr 200 andere Backends steht. Sobald ein Backend mit ca. 300.000 Verbindungen / Sekunde DDOS-bearbeitet wurde, sterben alle anderen Backends. Mit dem Wert maxconn 2048 auf dem Backend-Server (unter ddos) läuft unser Haproxy einwandfrei. Vielen Dank, du hast mich eines Nachts gerettet :)
hungnv