Linuxカーネルエラーにより、破損したTCP / IPパケットがMesos、Kubernetes、およびDockerコンテナーに送信されます

そして、それはTwitterで発見されました



Linuxカーネルには、コンテナーが原因のエラーがあります。 TCPチェックサムのチェックを回避するために、コンテナはネットワークルーティングにvethデバイス（IPv6 Docker、Kubernetes、Google Container Engine、Mesosなど）を使用します。 これにより、障害のあるネットワーク機器で発生するように、アプリケーションが誤って破損したデータを受信する場合があります。 このエラーは少なくとも3年前に発生し、まだカーネルに「座っている」ことを確認しました。 パッチはテストされ、カーネルに導入され、現在、さまざまなディストリビューション（SuseやCanonicalなど）の安定版リリース3.14のレトロサポートを提供しています。 システムでコンテナを使用する場合は、このパッチを使用するか、利用可能になったときにカーネルをインストールすることをお勧めします。



注：Google Container Engineは仮想ネットワークによりハードウェアエラーから実質的に保護されているため、これはDockerでデフォルトで使用されるNATネットワークには適用されません。 Jake Bowerはまた、このエラーは以前に発見されたPager Dutyエラーに非常に似ていると考えています。

それがすべて始まった方法

11月のある週末、Twitterサポートエンジニアのグループがログをスキャンしました。 動作しない各アプリケーションは、奇妙な文字列や必須フィールドの省略という形で「信じられない」エラーを生成しました。 これらのエラーの関係は、Twitterの分散アーキテクチャの性質により明らかではありませんでした。 分散システムでは、データが破損すると、かなりの時間エラーが発生する可能性があるため、状況全体が複雑になりました（キャッシュ、ディスク、ジャーナルなどに保存されます）。



アプリケーションレベルでのトラブルシューティングに関する1日の継続的な作業の後、チームは問題を個々のラックラックにローカライズすることに成功しました。 エンジニアは、宛先に到達する直前に、検出されたTCPチェックサムエラーの数が大幅に増加したと判断しました。 この結果はソフトウェアを「解放」したように見えました。アプリケーションはネットワークの輻輳を引き起こす可能性がありますが、パケットの損傷は生じませんでした！





これらのラックの電源を切るとすぐに、アプリケーションエラーがなくなりました。 もちろん、ネットワークレベルでのデータ破損はさまざまな理由で発生する可能性があります。最も奇妙な方法では、スイッチが故障したり、ワイヤが破損したり、電源が故障したりすることがよくあります。 TCPおよびIPのチェックサムは、このような障害から保護するように設計されています。 実際、機器について収集された統計は、エラーが存在することを示していました。 では、なぜさまざまなアプリケーションがクラッシュし始めたのですか？



特定のスイッチを分離した後、これらのエラーを再現する試みが行われました（主にシニア信頼性エンジニアのブライアン・マーティンの多大な作業によるものです）。 これらのラックに多数のデータパケットを送信することにより、破損したデータを再現するのは比較的簡単であることが判明しました。 一部のスイッチでは、送信されたパケットの最大10％が破損していました。 ただし、損傷は常にTCPチェックサム（TcpInCsumErrors netstat-aなどのメッセージ）を使用してカーネルによって検出され、アプリケーションに到達することはありませんでした。 （Linuxでは、文書化されていないSO_NO_CHECKオプションを使用して、チェックサムを無効にしてIPv4 UDPパケットを送信できます。この場合、パケットが破損していることがわかります。）



Evan Jonesは、破損したデータには正しいTCPチェックサムがあることを提案しました。 同じ16ビットワードで2ビットが「反転」（たとえば、0→1および1→0）ミラーリングされている場合、TCPチェックサムへの影響は互いに相殺されます（TCPチェックサムは単純なビットの追加です）。 メッセージ内のデータ破損（モジュロ32バイト）は常に同じビット位置を変更することにありましたが、そのような可能性を排除する「スティッキービット」（0→1）があったという事実。 一方、チェックサム自体は保存される前に反転されるため、チェックサム内のビットの「フリップ」とデータ内のビットの「フリップ」は互いに相殺できます。 ただし、私たちが観察したビット位置はTCPチェックサムに変更できないため、これは不可能でした。



すぐに、チームはテストが標準のLinuxシステムで実行され、TwitterのほとんどのサービスがLinuxコンテナを使用してさまざまなアプリケーションを分離するMesosで実行されることに気付きました。 特に、仮想イーサネットデバイス（vethデバイス）はTwitter構成で作成され、すべてのアプリケーションパケットはそれらを介して送信されます。 もちろん、テストアプリケーションを起動した後、TCPチェックサムが間違っていた（および不正として検出された：TcpInCsumErrorsの数が増加した）にもかかわらず、破損したデータがTCP接続を介してMesosコンテナーを介してすぐに現れました。 誰かが、仮想イーサネットデバイスの「チェックサムオフロード」設定を変更することを提案しました。これにより、問題が解決され、対応する破損データが削除されました。



今、私たちには重大な仕事があります。 Mesos Twitterチームは、情報をMesosオープンソースプロジェクトに迅速に中継し、すべてのTwitter作業コンテナの設定を変更しました。

さらに掘る

Evanと私がこのエラーについて話し合ったとき、TCP / IPプロトコルはOSに違反しているため、Mesosの構成ミスの結果ではなく、カーネルネットワークスタックで以前に検出されなかったエラーの結果である可能性が高いと判断しました。



この調査を続行するために、可能な限り単純なテストシステムを作成しました。

1. ソケットを開き、非常にシンプルで長いメッセージを1秒に1回送信する単純なクライアント。
2. 単純なサーバー（実際にはリスニングモードでネットワークコンピューターを使用しました）。これは、ソケットをリッスンし、情報を受信すると情報を表示します。
3. ネットワークデバイス。ユーザーがパケットを有線で送信する前に任意に損傷することを可能にする伝送コントローラー。
4. クライアントとサーバーを接続したら、ネットワークデバイスを使用して、10秒以内に送信されたすべてのパケットを破壊しました。

クライアントをあるマシンから管理し、サーバーを別のマシンから管理しました。 スイッチを介して接続されたコンピューター。 コンテナなしでテストシステムを起動したとき、期待どおりに動作しました。 破損したパッケージのアラートは受信されていません。 実際、破損したデータが送信されていた10秒間は、メッセージをまったく受信しませんでした。 クライアントがパケットの破損を停止すると、10個すべてのメッセージ（配信されなかった）がすぐに到着しました。 これにより、コンテナなしのLinux上のTCPが正常に機能することが確認されます。不良TCPパケットは遅延せず、エラーなしで受信できるまで常に再送信されます。





したがって、これは理論的には機能するはずです。破損したデータは配信されません。 TCPはそれらを再送信します。

Linuxとコンテナー

この場所に戻って（問題を診断するときに行ったように）Linuxコンテナー環境でネットワークスタックがどのように機能するかを簡単に説明すると便利です。 コンテナは、ユーザーサービングアプリケーションがコンピューターで連携できるように設計されているため、仮想化環境の多くの利点を提供します（アプリケーションが相互に影響する可能性を低減または完全に排除し、複数のアプリケーションが異なる環境または異なるライブラリーで動作する機能を低コストで提供します）仮想化。 理想的には、互いに競合するすべてのオブジェクトが分離されます。 例には、ディスク要求キュー、キャッシュ、およびネットワーク操作が含まれます。



Linuxでは、コンピューターで実行されている一部のコンテナーを他のコンテナーから分離するためにvethデバイスが使用されます。 Linuxネットワークスタックは非常に複雑ですが、基本的にvethデバイスは、ユーザーの観点からは「通常の」イーサネットデバイスのように見えるはずのインターフェイスです。



仮想イーサネットデバイスを使用してコンテナを作成するには、（最初​​に）コンテナを作成し、（2番目に）vethを作成し、（3番目に）vethの一端をコンテナにバインドし、（4番目に）vethにIPアドレスを割り当て、（5番目に）ルーティングを構成する必要があります、Linuxトラフィック制御を使用して、コンテナがパケットを送受信できるようにします。

なぜこのすべての仮想経済が「落ちている」のか

サーバーがコンテナ内で動作していたことを除き、上記のテストシステムを再作成しました。 しかし、それを起動したとき、正反対の画像を見ました：破損したデータは遅延されず、アプリケーションに配信されました！ 非常に単純なテストシステム（テーブル上の2台のマシンと2つの非常に単純なプログラム）でエラーを再現しました。





破損したデータはアプリケーションに配信されます。左側のウィンドウを見てください！



また、このテストシステムをクラウドプラットフォームで再現することもできました。 Kubernetesの構成には、デフォルトで同じ画像が表示されます（たとえば、Google Container Engineを使用する場合）。 デフォルトのDocker構成（NATを使用）は安全ですが、IPv6上のDocker構成は安全ではありません。

エラーを修正します

カーネルネットワークコードを調べた後、このエラーがカーネルvethモジュールにあることが明らかになりました。 カーネルでは、実際のネットワークデバイスからのパケットで、ハードウェアがチェックサムをチェックした場合はip_summedがCHECKSUM_UNNECESSARYに設定され、パケットが不良であるかチェックする方法がない場合はCHECKSUM_NONEに設定されます。



veth.cのコードは、CHECKSUM_NONEをCHECKSUM_UNNECESSARYに置き換えました。 これにより、ソフトウェアによって検証および拒否されるはずのチェックサムが単に黙って無視されるという事実に至りました。 このコードを削除した後、パケットは変更されずにスタックから別のスタックに転送され始め（予想どおり、tcpdumpは両側で誤ったチェックサムを示しました）、アプリケーションに正しく配信（または遅延）されました。 ホストとコンテナ間のNATを使用したブリッジコンテナ接続、実際のデバイスからコンテナへのルーティングなど、いくつかの一般的なネットワーク構成のみをチェックしました。 これをTwitterに効果的に実装しました（受信時のチェックサム計算を無効にし、vethデバイスをアンロードします）。



コードがこのように記述された理由は正確にはわかりませんが、これは最適化の試みだと考えています。 多くの場合、同じ物理マシン上のコンテナを接続するためにvethデバイスが使用されます。 同じ物理ホスト内のコンテナー（または仮想マシン）間で送信されるパケットは、チェックサムを計算またはチェックすべきではないことは論理的です：パケットは決してワイヤを介して送信されないため、唯一の損傷の原因はホスト自身のRAMです。 残念ながら、この最適化は意図したとおりに機能しません。ローカルに送信されるパケットの場合、ip_summedパラメーターはCHECKSUM_NONEではなくCHECKSUM_PARTIALに設定されます。



このコードは、最初のドライバーリリース用に作成されています（コミットe314dbdc1c0dc6a548ecf [NET]：仮想イーサネットデバイスドライバー）。 Commit 0b7967503dc97864f283a net / vethのリリース：パケットチェックサムの修正（2010年12月）は、CHECKSUM_PARTIALを変更せずにローカルで作成され、実際のデバイスに送信されるパケットに対してこれを設定しました。 ただし、実際のデバイスから送信されたパケットの場合、この問題はまだ解決されていません。



以下は、カーネルのパッチです。



diff — git a/drivers/net/veth.cb/drivers/net/veth.c

index 0ef4a5a..ba21d07 100644

— — a/drivers/net/veth.c

+++ b/drivers/net/veth.c

@@ -117,12 +117,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)

kfree_skb(skb);

goto drop;

}

- /* don't change ip_summed == CHECKSUM_PARTIAL, as that

- * will cause bad checksum on forwarded packets

- */

- if (skb->ip_summed == CHECKSUM_NONE &&

- rcv->features & NETIF_F_RXCSUM)

- skb->ip_summed = CHECKSUM_UNNECESSARY;



if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {

struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);



結論

全体として、netdevグループとLinuxカーネルの専門家には本当に感銘を受けました。 コード検査は十分に速く、パッチは数週間接続され、1か月後には、さまざまなカーネルディストリビューション（Canonical、Suse）で古い安定バージョン（3.14 +）のレトロサポートが提供されました。 コンテナ環境のすべての利点により、このエラーが何年も気付かれずに続いたことが本当に驚きました。 それが原因で、アプリケーションプログラムの障害やその他の予測できない動作がいくつ発生するのだろうか。