今日はあなたのために謎があります。AzureでCoreOS（2023.5.0 / Linux 4.19.25-coreos）に基づいた小さな3ノードのElasticsearchクラスターを実行します。Elasticsearchは、ホストネットワークモードのDockerコンテナ内で実行されます。ほぼ完全にメンテナンスフリーで1年以上稼働した後、マシンが非常に興味深い状態になるのを見てきました。
更新
この問題は、Linuxカーネルのドライバーを修正することで解決しました。以下の回答をご覧ください。
症状
基本的に、影響を受けるマシンと他の2つのノード間のネットワークは停止します。すべてが同じ仮想ネットワークと同じサブネットにあり、通常は他のeathと通信できます。影響を受けるノードは、他のサブネット（sshに接続できます）および別のピア仮想ネットワークからも到達できます。マシンにはインターネットへの（非常にむらのある）接続もありますが、ほとんどの要求はタイムアウトになります。
影響を受けるノードで報告される「使用されるソケット」の数/proc/net/sockstatが非常に多いことを確認しました（正常なノードでは〜300ではなく〜4.5k）。監視により、この数はノードが利用できなくなった瞬間から急速に増加することがわかります。
面白いのは、これらの使用済みソケットのソースを特定できないように見えることです。
# cat /proc/net/sockstat
sockets: used 4566
TCP: inuse 2 orphan 0 tw 2 alloc 98 mem 4
UDP: inuse 1 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
# cat /proc/net/sockstat6
TCP6: inuse 98
UDP6: inuse 1
UDPLITE6: inuse 0
RAW6: inuse 1
FRAG6: inuse 0 memory 0
それ以外は、マシンは問題ないようです。疑わしいプロセスは実行されておらず、CPU使用量は最小限であり、使用可能なメモリは十分にあります。
同じサブネット内の「到達不能な」VMにpingを実行すると、にいくつかのEAGAIN応答recvmsgがENOBUFS返され、から戻ってに戻りsendmsgます。ここでstrace ping出力
（システムに変更を加える前に）追加の出力を収集し、この要点に投稿しました：https : //gist.github.com/privatwolke/e7e2e7eb0272787765f5d3726f37107c
分析
Elasticsearchが最初の容疑者であるため、サーバー上で考えられるすべてのものをシャットダウンしようとしました。ただし、elasticsearchコンテナをシャットダウンしても、使用済みのソケットは解放されません。すべてのCoreOS関連プロセス（update-engine、locksmithdなど）、またはDockerランタイム全体またはAzure固有のものでも同じです。何も役に立たなかったようです。
しかし、今ではさらに奇妙にtcpdumpなっています。マシン上で実行して、何が起こっているのかを確認しようとしました。そして見よ：問題はそれ自体で解決し、接続が回復した。私たちの理論では、tcpdumpはそれを解決するある種のsyscallを実行します。gdbでtcpdumpを実行し、すべてのsyscallにブレークポイントを設定しました。ブレークポイントのロードをステップ実行した後、キャプチャソケット（具体的にはlibpcapのこの行）で無差別モードを設定する行為は、使用されているソケットをリセットし、通常の状態に戻すことであることが最終的にわかりました。
追加の調査結果
- フラグを指定して実行
tcpdumpしても-p/--no-promiscuous-mode、ソケット使用カウンタがクリアされず、マシンが使用可能な状態に戻らないことを確認しました。 - 実行すると
ifconfig eth0 txqueuelen 1001、使用されているソケットのカウンターがリセットされますが、接続は復元されません。 ip link set eth0 promisc onまた、promiscモードを手動で設定しても、接続は復元されません。net.ipv4.xfrm4_gc_threshを32768に設定し、少し大きくしても問題は解決しません。
私たちは、私たちと同じくらい困惑しているAzureと連絡を取り合っています。これはおそらく問題ではなく、単なる症状であることを理解しています。しかし、これは私がこれまでに見つけた唯一の具体的なものです。私の希望は、症状を理解することで根本原因に近づくことができることです。Azureのネットワークインターフェイスは、このネットワークドライバーで実行されます。
CoreOS / Kernelのせいかもしれない？
タイムラインの観点から、問題は2019-03-11に始まりました。これは、CoreOSが最新バージョンに自動更新された日です。リリースノートによると、このアップデートには4.15.23から4.19.25へのカーネルアップデートが含まれていました。私はまだ変更ログを調べて、何か問題があるかどうかを確認しています。これまでのところ、hypervネットワークドライバーがここ数か月でかなりの数の更新を受け取っていることを発見しただけで、そのすべてが4.19.25の一部であるとは限りません。CoreOSが4.19.25に適用したパッチセットはそれほど印象的ではありませんが、偽のnf_conntrack_ipv4モジュールを導入するパッチは新しいものです。
助けて！
これまでの質問は次のとおりです。
この「使用済みソケット」メトリックが急騰する原因は何ですか？私はこのメトリックのカーネルソースを読みましたが、実際にはどのようなソケットであるか、またはどのソケットを作成したかについては言及していない単なるカウンターのようです。
数が約4.5kで平坦になるのはなぜですか？どの制限が原因ですか？
カーネル4.14.96と4.19.25の間で何か大きな変更がありましたか？
setsockopt()libpcap の呼び出しが状態をリセットするのはなぜですか？
関連するCoreOSバグ：https : //github.com/coreos/bugs/issues/2572