MPIプログラムがネットワークに過負荷になると、Ubuntu 22.04のTCP / IPネットワークが応答しなくなります。

MPIプログラムがネットワークに過負荷になると、Ubuntu 22.04のTCP / IPネットワークが応答しなくなります。

Ubuntu 22.04.3 LTSを実行している2つの同じサーバーがあります。どちらのシステムにも、合計1​​92のコアと512 GBのRAMを備えた2つのAMD 9654 CPUがあります。各サーバーには、マザーボードに2つの10Gイーサネットポートが組み込まれています。これらの10Gポートは、netplanを使用して単一リンク統合を生成するように構成されています。

完全なネットワーク構成は、通常の負荷で正常に動作します。以下は、最初のサーバー(Thor)の$ ip aの出力です。

Thor$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: Ethernet-10G-1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master Bond-10G state UP group default qlen 1000
    link/ether 00:00:00:00:00:04 brd ff:ff:ff:ff:ff:ff permaddr a0:36:bc:c8:c6:9b
    altname enp15s0f0
3: Ethernet-10G-2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master Bond-10G state UP group default qlen 1000
    link/ether 00:00:00:00:00:04 brd ff:ff:ff:ff:ff:ff permaddr a0:36:bc:c8:c6:9c
    altname enp15s0f1
4: Bond-10G: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:00:00:04 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.203/22 brd 10.0.3.255 scope global dynamic noprefixroute Bond-10G
       valid_lft 31554381sec preferred_lft 31554381sec
    inet6 fe80::200:ff:fe00:4/64 scope link 
       valid_lft forever preferred_lft forever

以下は、最初のサーバーから2番目のサーバー(Loki)への一般的なping出力です。

Thor$ ping loki
PING loki.elliptic.loc (10.0.1.204) 56(84) bytes of data.
64 bytes from Loki.elliptic.loc (10.0.1.204): icmp_seq=1 ttl=64 time=0.139 ms

これは、139マイクロ秒の低レイテンシを示しています。両方のサーバーは、同じスイッチ、Ntgear XS728T 28ポート10ギガビットL2 +スマートスイッチに接続されています。 iperfを使ってネットワークテストも行いました。結果(ここでは表示されていないが有用な場合は利用可能)は、2つのホスト間の持続帯域幅が10.0 GB /秒であることを確認します。

今私の質問です。私は応用数学博士課程の学生であり、このサーバーを使用して大規模な数値シミュレーションコードを実行しています。シミュレーションプログラムはMPIを使用します。私はこのプログラムをテストし、一度に1つのホストの192コアで完全に動作します。少数のコア(たとえば、コアあたり8個)を使用している場合は、2つのホストでプログラムを実行することもできます。しかし、多数のコアで実行しようとすると、プロセス間のTCP接続が失われ、MPIプログラムが中断されます。以下は、ホストごとに192コア(合計384コア)で実行しようとしましたが失敗したときに表示されるエラー出力の例です。

WARNING: Open MPI failed to TCP connect to a peer MPI process.  This
should not happen.

Your Open MPI job may now hang or fail.

  Local host: Thor
  PID:        8076
  Message:    connect() to 10.0.1.204:1162 failed
  Error:      No route to host (113)

さらに、MPIプログラムが終了した後も、サーバーの一方または両方のIPネットワークは機能しなくなります。ネットワークが停止した後、帯域外IPMIツールを使用してサーバーにアクセスできました。 TCP/IP ネットワークがダウンしたときに ping を呼び出すと、「ターゲットホストに接続できません」というエラーメッセージが表示されます。この状態では、本機はルーターやネットワークスイッチをpingすることはできません。この場合、回復できる唯一の方法は完全に再起動することでした。

この場合、リモートサーバーで$ ip aの出力を確認すると、開始された場所と同じように見えます。もし逃した内容があれば下に貼り付けます。

Loki $ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: Ethernet-10G-1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master Bond-10G state UP group default qlen 1000
    link/ether 00:00:00:00:00:05 brd ff:ff:ff:ff:ff:ff permaddr a0:36:bc:c8:c7:2b
    altname enp15s0f0
3: Ethernet-10G-2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master Bond-10G state UP group default qlen 1000
    link/ether 00:00:00:00:00:05 brd ff:ff:ff:ff:ff:ff permaddr a0:36:bc:c8:c7:2c
    altname enp15s0f1
4: Bond-10G: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:00:00:05 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.204/22 brd 10.0.3.255 scope global dynamic noprefixroute Bond-10G
       valid_lft 31555883sec preferred_lft 31555883sec
    inet6 fe80::200:ff:fe00:5/64 scope link 
       valid_lft forever preferred_lft forevera

私はいくつかの進歩を遂げ、問題はTCPネットワークが急速に生成され、多くのトラフィックを送信する多くの接続の負荷に追いついていないことに関連していると考えました。 OpenMPIドキュメントを読みながら10GB TCP / IPネットワークでMPIを実行するには、複数のLinuxカーネルパラメータを調整する必要があるというヒントを見ました。これらの変更を/etc/sysctl.d/21-net.confに次のように入力しました。

net.core.rmem_max               = 16777216
net.core.wmem_max               = 16777216
net.ipv4.tcp_rmem               = 4096 87380 16777216
net.ipv4.tcp_wmem               = 4096 65536 16777216
net.core.netdev_max_backlog     = 30000
net.core.rmem_default           = 16777216
net.core.wmem_default           = 16777216
net.ipv4.tcp_mem                = 16777216 16777216 16777216
net.ipv4.route.flush            = 1

この変更を行う前に、プログラムにノードごとに8つのMPIプロセスを実行させることはできませんでした。変更後、各ノードで32のMPIプロセスを実行できます。私は別の変更を行い、さらに増やし、net.core.rmem_maxとnet.ipv4.tcp_memを最大2^31-1に増やしました。この変更により、プログラムは両方のホストの128コアで実行される可能性がありますが、192コアの両方を使用しようとするとまだ中断されます。

これが最後のデータポイントです。私は博士指導教授が提供した2つのコンピュータを全く別のコンピュータで使ってこのテストを繰り返しました。少し古く、それぞれ28個のCPUがあり、Ubuntu 20.04 LTSを実行します。すべてが完全に一般的な構成になっています。ネットワークボンディングのないギガビットネットワーク。私は自分のコンピュータで遭遇した問題を正確に再現できました。唯一の違いは、以前のシステムがノードあたりのMPIプロセスが8つしかなく、ネットワーク負荷のために圧倒されたことです。

これが私の直感です。 MPI は共有メモリを使用して同じノードのプロセス間で通信します。非常に高速で、TCP/IP ネットワークに負荷をかけません。異なるノードにまたがるMPIプロセスペア間の各接続には、ソケットとTCP接続が必要です。これにより、複数のコアで大規模なシミュレーションを実行すると、TCP / IPネットワークに大きな負荷が発生します。バッファサイズを増やすと役に立ちますが、それでも遅くなり、TCPネットワークが完全に停止しやすくなります。ほとんどの大規模なスーパーコンピューティングクラスタは、Infinibandなどのより高速なネットワークソリューションを使用しているため、これはHPC世界のエッジケースだと思います。 10GBイーサネットを介して1000個のCPUに拡張したい他の人を見たことはありません。

Stack Exchange の誰かがこの種の問題に精通しており、提案がある場合は非常に感謝します。私は今、博士課程の4年目に入り、この問題を解決するために2週間以上を過ごしました。長年の皆さんのご苦労に心より感謝申し上げます。

-男の名前

ベストアンサー1

おすすめ記事