it-swarm.com.de

Mehrere Prozesse überwachen denselben Port. wie ist es möglich?

Mehrere Prozesse überwachen denselben Port. Aber meines Wissens kann nur ein Prozess einen Port überwachen. Ist es möglich (wie?), Dass mehrere Prozesse denselben Port überwachen können?

$ Sudo lsof -n -i :80 | grep LISTEN
haproxy 2039 root    4u  IPv4  12874      0t0  TCP *:http (LISTEN)
haproxy 2042 root    4u  IPv4  12898      0t0  TCP *:http (LISTEN)
haproxy 2045 root    4u  IPv4  12923      0t0  TCP *:http (LISTEN)

pstree Ausgabe:

init
  ├─acpid -c /etc/acpi/events -s /var/run/acpid.socket
  ├─atd
  ├─cron
  ├─dbus-daemon --system --fork
  ├─dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 
  ├─docker -d
  │   └─6*[{docker}]
  ├─getty -8 38400 tty4
  ├─getty -8 38400 tty5
  ├─getty -8 38400 tty2
  ├─getty -8 38400 tty3
  ├─getty -8 38400 tty6
  ├─getty -8 38400 tty1
  ├─getty -8 38400 ttyS0
  ├─haproxy -f /etc/haproxy/haproxy.cfg
  ├─haproxy -f /etc/haproxy/haproxy.cfg
  ├─haproxy -f /etc/haproxy/haproxy.cfg

haproxy config:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    user ubuntu
    group ubuntu
    daemon 

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000

listen appname 0.0.0.0:80
    mode http
    stats enable
    stats uri /haproxy?stats
    balance roundrobin
    option httpclose
    option forwardfor
    server lamp1 172.31.20.0:81 check
    server lamp2 172.31.20.1:81 check
9
Kundan

Es ist möglich. Ziel ist es, mehrere eingehende Verbindungen parallel zu verarbeiten. Mehrere haproxy Instanzen können separate CPU-Kerne verwenden und (halb-) unabhängig voneinander arbeiten. Eingehende Verbindungen werden an haproxy im Leerlauf (falls verfügbar) weitergeleitet, anstatt an eine besetzte Verbindung in die Warteschlange gestellt zu werden.

Ich vermute haproxy verwendet SO_REUSEPORT. man 7 socket erklärt diese Option wie folgt:

SO_REUSEPORT (seit Linux 3.9)

Ermöglicht die Bindung mehrerer AF_INET- oder AF_INET6-Sockets an eine identische Socket-Adresse. Diese Option muss für jeden Socket (einschließlich des ersten Sockets) festgelegt werden, bevor bind(2) für den Socket aufgerufen wird. Um Port-Hijacking zu verhindern, müssen alle Prozesse, die an dieselbe Adresse gebunden sind, dieselbe effektive UID haben. Diese Option kann sowohl für TCP- als auch für UDP-Sockets verwendet werden.

Für TCP Sockets ermöglicht diese Option die Verbesserung der accept(2)-Lastverteilung in einem Multithread-Server, indem für jeden Thread ein eigener Listener-Socket verwendet wird. Dies bietet eine verbesserte Lastverteilung im Vergleich zu herkömmlichen Techniken, wie z. B. die Verwendung eines einzelnen accept(2)- Threads, der Verbindungen verteilt, oder mehrerer Threads, die mit accept(2) über denselben Socket konkurrieren.

Überprüfen Sie dort auch SO_ATTACH_REUSEPORT_CBPF und SO_ATTACH_REUSEPORT_EBPF.


Bearbeiten: Ich fand diesen Artikel (vom 3. Mai 2017); es scheint meine Vermutung zu stützen:

In der Zwischenzeit wurde eine neue und viel bessere SO_REUSEPORT-Implementierung für Linux-Kernel 3.9 eingeführt, mit der die Last auf mehrere Sockets verteilt werden kann. HAProxy könnte sofort von dieser neuen Verbesserung profitieren.

Aber es kam mit einem Problem [...]

Mach dir keine Sorgen über das Problem. Der Artikel beschreibt Problemumgehungen und eine Lösung. Du findest es vielleicht interessant, wenn du auf solche Sachen stehst.

7