web-dev-qa-db-ja.com

同じポートでリッスンする複数のプロセス。どのようにして可能ですか?

複数のプロセスが同じポートでリッスンしています。しかし、私が知る限り、ポートでリッスンできるプロセスは1つだけです。複数のプロセスが同じポートをリッスンすることは可能ですか?

$ 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出力:

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設定:

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
10
Kundan

可能です。目標は、複数の着信接続を並行して処理することです。複数のhaproxyインスタンスは、個別のCPUコアを利用して、(半)独立して動作します。着信接続は、ビジー接続のキューに入れられるのではなく、アイドルhaproxy(使用可能な場合)に渡されます。

私は推測するhaproxyは_SO_REUSEPORT_を使用します。 _man 7 socket_ このオプションの説明は次のとおりです:

_SO_REUSEPORT_(Linux 3.9以降)

複数の_AF_INET_または_AF_INET6_ソケットを同一のソケットアドレスにバインドすることを許可します。このオプションは、ソケットでbind(2)を呼び出す前に、各ソケット(最初のソケットを含む)で設定する必要があります。ポートのハイジャックを防ぐには、同じアドレスにバインドしているすべてのプロセスが同じ実効UIDを持っている必要があります。このオプションは、TCPおよびUDPソケットの両方で使用できます。

TCPソケットの場合、このオプションにより、スレッドごとに異なるリスナーソケットを使用することにより、マルチスレッドサーバーでのaccept(2)負荷分散を改善できます。これにより、接続を分散する単一のaccept(2)- ingスレッドを使用したり、同じソケットからaccept(2)と競合する複数のスレッドを使用したりする従来の手法。

また、_SO_ATTACH_REUSEPORT_CBPF_および_SO_ATTACH_REUSEPORT_EBPF_も確認してください。


編集:私は この記事 を見つけました(2017年5月3日付));それは私の推測をサポートするようです:

それまでの間、新しいより優れた_SO_REUSEPORT_実装がLinuxカーネル3.9に導入され、負荷を複数のソケットにインテリジェントに分散できるようになりました。 HAProxyは、この新しい改善からすぐに恩恵を受けることができます。

しかし、それは問題がありました[...]

問題を心配しないでください。この記事では、回避策と解決策について説明します。この種のものに興味があるなら、あなたはそれを面白いと思うかもしれません。

8