ネットワーク障害の目に見えない原因: MTU 構成をご存知ですか?

背景

当社はAmazonのクラウドサービスを利用しています。メーカーのメッセージキュー製品は使用しません。私たちは自分たちで構築することを選択します。独自に構築する利点は、より柔軟性が高く、カスタマイズ性が高いことです。社内には複数の Kafka クラスターと 100 を超えるブローカー ノードがあります。 Kafka 用の比較的完全な自動運用・保守管理システムも備えています。最近、Kafka クラスターへの業務接続が頻繁にタイムアウトする状況が発生しました。ネットワーク知識の理解を深めるために、処理プロセスをここに記録します。

問題現象

企業は、サービスの可用性の低下に関するアラートを受け取ります。ログを分析したところ、Amazon Kafka クラスターへの接続が頻繁にタイムアウトしていることがわかりました。タイムアウトログは次のとおりです。

ファンダメンタル分析

• 影響要因: 複数のホストが同時にアラームを発し、単一のホストの問題をトラブルシューティングします。
• クラスター チェック: Kafka クラスターの正常性状態と関連トピックをすぐに確認します。クラスターの状態は正常、メッセージの送受信は正常、圧力負荷は正常です。トピックの読み書きは正常です。
• 変更操作: 最近、Kafka に変更は加えられていません。変更の影響を確認します。
• 影響の範囲を特定する: 他のサービスにタイムアウトがあるかどうかを確認します。ほとんどのビジネス フィードバックではタイムアウトは発生せず、問題の範囲は現在のビジネスに限定されていました。

位置

ネットワークの問題は表面からは見えないため、パケットキャプチャによってのみ分析できます。クライアントとサーバーのデータ パケットは同時にキャプチャされます。パケットキャプチャコマンドは次のとおりです。

 # 客户端（抓所有和kafka节点通信的网络数据包） nohup tcpdump port 9092 -w kafka.pcap & # 服务端（抓所有和客户端主机通信的数据包） nohup tcpdump host 10.66.67.166 -s0 -w 10.66.67.166.pcap &

注: パケット キャプチャを有効にした後、クライアント ホストでタイムアウト ログをフィルターします。タイムアウトが発生した場合、パケットキャプチャ操作を停止します。

パケット分析

• エラーログ:
• 2023-05-24 20:46:29.947 kafka クライアント/メタデータは、メタデータの取得中にブローカーからエラーを受け取りました: read tcp 10.66.67.166:37272->10.68.0.151:9092: i/o タイムアウト
• クライアントメッセージ

• サーバーメッセージ

• メッセージ分析
• クライアントメッセージ:
• シーケンス番号が 793 を超えるすべてのメッセージはサーバーから応答を受信して​​おり、メッセージの配信に Kafka プロトコルが使用されていることがわかります (Kafka は応答を生成します)。
• シーケンス番号が 794 の場合、クライアントは長さ 8514 の TCP パケットを 7 つ送信しますが、サーバーからの応答はありません。
• シーケンス番号が 803 と 804 の場合、クライアントはさらに 2 つの異なる長さの TCP パケットを送信します。
• シーケンス番号 807 から、クライアントが以前送信した長さ 8514 の TCP パケットをすべて再送信したことがわかりました (パケットが失われました。クライアントはサーバーから応答を受信しなかったため、再送信しました)。
• サーバーメッセージ。
• サーバーの観点から見ると、クライアントからの最初のいくつかの TCP メッセージはサーバーによって正常に処理されました。 (以前のメッセージの長さは非常に短く、1000 未満でした)。
• サーバーは、クライアントから送信された長さ 8514 の 9 つのパケットを受信しませんでした。
• サーバーは 60 秒間待機した後、TCP 接続を閉じました。 (サーバー上で設定されているアイドル接続時間は 1 分であり、これは予想どおりです)。

パケット損失問題分析

• 破棄されたデータグラムの長さは比較的大きいです。データグラムの長さが大きすぎるからでしょうか?
• マシンのネットワーク カードの MTU 構成を確認し、9001 (TCP/IP ジャンボ フレーム) であることを確認します。 ping コマンドを使用して、テスト用のサイズをランダムに指定します。
• TCP 最大セグメント サイズ (MSS) は、ネットワーク カードによって設定された MTU 値によって決まります。 9001 に設定した場合でも、テストでサポートされる最大 MSS は 8468 です。この値を超えると、データは直接ドロップされます。

• 比較テストルールの概要

• Tencent および Alibaba ホスト (mtu=1500): ネットワーク カードはすべて 1500 に設定されているため、パケットが大きすぎるために破棄される状況は発生しません。
• Amazon ホスト (mtu=9001): 8468 より大きいパケットは破棄されます (問題は、新しいアカウントと古いアカウント間の通信で発生します)。

物事の真相を突き止める

他のAmazonビジネスネットワークカードのMTU設定も9001です。なぜ問題ないのでしょうか？

• 直ちに問題があった事業者に、事業の調整や変更があるかどうかを確認しました。同社は、サービスが調整されておらず、サービスを展開するためにAmazonに新しいアカウントを開設したと説明した。現在、ビジネス アクセスはクロス アカウント コールです。

クロスアカウント ネットワーク リンクを確認するには、製造元にお問い合わせください。

• メーカーのテクニカル サポート スタッフに MTU の問題を報告したところ、新旧アカウントのネットワーク接続デバイス (TGC) の最大 MTU 制限は 8500 であるため、ゲートウェイ デバイスを通過するパケットは破棄されたという結論が示されました。

解放プログラム

• 製造元の MTU 制限に合わせてホスト MTU 値を調整します。

 # 临时生效ip link set dev eth0 mtu 1500永久生效vim /etc/sysconfig/network-scripts/ifcfg-eth0 增加如下内容MTU="9000" # service network restart