自己修復するネットワーク: Flow Label の魔法と Linux カーネルをめぐる探偵。 ヤンデックスレポート

最新のデータセンターには、さまざまな種類の監視の対象となるアクティブなデバイスが数百台あります。 しかし、完璧な監視を備えた完璧なエンジニアでも、わずか数分でネットワーク障害に適切に対応できるでしょう。 Next Hop 2020 カンファレンスのレポートで、私は、データセンターがミリ秒で自動的に修復するというユニークな機能を持つデータセンター ネットワーク設計方法論を紹介しました。 より正確には、エンジニアは問題を冷静に解決しますが、サービスは単にそれに気付かないだけです。

- まず始めに、おそらく現代の DC の構造を知らない人のために、かなり詳しく説明します。


多くのネットワーク エンジニアにとって、データセンター ネットワークは、もちろん、ラック内のスイッチである ToR から始まります。 ToR には通常 5 種類のリンクがあります。 小さなスパインはサーバーに送信され、その他のスパインは、N 倍のスパインがあり、第 XNUMX レベルのスパイン、つまりアップリンクに送信されます。 通常、アップリンクは同等とみなされ、アップリンク間のトラフィックは、proto、src_ip、dst_ip、src_port、dst_port を含む XNUMX タプル ハッシュに基づいてバランスがとられます。 ここでは驚くべきことはありません。


次に、飛行機の構造はどのようなものでしょうか? 第 XNUMX レベルのスパインは互いに接続されていませんが、スーパースピンによって接続されています。 文字 X はスーパースピンを担当し、クロスコネクトに似ています。


そしてその一方で、トーリが第 1 レベルのすべての脊椎に接続されていることは明らかです。 この絵の中で何が重要ですか? ラック内でインタラクションがある場合、そのインタラクションは当然 ToR を経由します。 インタラクションがモジュール内部に入る場合、インタラクションは最初のレベルのスパインを通過します。 インタラクションがモジュール間である場合 (ここでは ToR 2 と ToR XNUMX)、インタラクションは第 XNUMX レベルと第 XNUMX レベルの両方のスパインを通過します。


理論的には、このようなアーキテクチャは容易に拡張可能です。 ポート容量、データセンター内のスペースの予備、および事前に敷設されたファイバーがあれば、プレーンの数はいつでも増やすことができ、それによってシステム全体の容量を増やすことができます。 紙の上では、これは非常に簡単に実行できます。 現実でもそうなるだろう。 しかし、今日の話はそれについてではありません。


正しい結論が導かれてほしい。 データセンター内には多くのパスがあります。 これらは条件付きで独立しています。 データセンター内への片道はToR内のみ可能です。 モジュール内には、プレーンの数と同じ数のパスがあります。 モジュール間のパスの数は、プレーンの数と各プレーンのスーパースピンの数の積に等しくなります。 より明確にし、規模を感じるために、Yandex データセンターの XNUMX つに有効な数字を示します。


32 つのプレーンがあり、各プレーンには 256 のスーパースピンがあります。 その結果、モジュール内に XNUMX つのパスがあり、モジュール間の相互作用により、すでに XNUMX のパスが存在することがわかります。

つまり、クックブックを開発し、自己修復するフォールトトレラントなデータセンターを構築する方法を学ぼうとしている場合、平面アーキテクチャが正しい選択となります。 これによりスケーリングの問題を解決でき、理論的には簡単です。 独立した道がたくさんあります。 疑問は残ります。そのようなアーキテクチャは障害にどうやって耐えられるのでしょうか? 色々なクラッシュがあります。 そして、これについては今から議論します。


スーパースピンの 11 人が病気になってみましょう。 ここで私は XNUMX つの平面のアーキテクチャに戻りました。 可動部分が少ないほうが、ここで何が起こっているのかを理解しやすくなるため、例としてそのまま使用します。 XXNUMX を病気にしましょう。 これはデータセンター内にあるサービスにどのような影響を与えるのでしょうか? 失敗が実際にどのように見えるかによって大きく異なります。


失敗が良好で、同じ BFD の自動化レベルで捕捉され、自動化が喜んで問題の結合部分を配置して問題を分離すれば、すべてがうまくいきます。 多くのパスがあり、トラフィックは即座に代替ルートに再ルーティングされますが、サービスは何も認識しません。 これは良いシナリオです。


悪いシナリオは、損失が継続的に発生し、自動化が問題に気付かない場合です。 これがアプリケーションにどのような影響を与えるかを理解するには、TCP プロトコルがどのように機能するかを少し時間をかけて説明する必要があります。


この情報で誰かに衝撃を与えないことを願います。TCP はハンドシェイク プロトコルです。 つまり、最も単純なケースでは、送信者は XNUMX つのパケットを送信し、それらに対する累積的な ACK を受信します。「XNUMX つのパケットを受信しました」。


その後、さらに XNUMX つのパケットを送信し、状況が繰り返されます。 一部簡略化していることをあらかじめお詫び申し上げます。 このシナリオは、ウィンドウ (送信中のパケット数) が XNUMX の場合は正しいです。 もちろん、これは一般に必ずしも当てはまるわけではありません。 ただし、パケット転送コンテキストはウィンドウ サイズの影響を受けません。


パッケージ 3 を紛失した場合はどうなりますか? この場合、受信者はパケット 1、2、および 4 を受信します。そして受信者は、SACK オプションを使用して送信者に「ご存知のとおり、2 つ来ましたが、真ん中が失われました。」と明示的に通知します。 彼は「Ack 4、SACK XNUMX」と言います。


この時点で、送信者は失われたパケットを問題なく繰り返します。


しかし、ウィンドウ内の最後のパケットが失われた場合、状況は大きく異なります。

受信者は最初の XNUMX つのパケットを受信し、まず待機を開始します。 Linux カーネル TCP スタックの最適化のおかげで、フラグにこれが最後のパケットであることなどの明示的な指示がない限り、ペアになったパケットを待ちます。 遅延 ACK タイムアウトが期限切れになるまで待機し、最初の XNUMX つのパケットに対する確認応答を送信します。 しかし、送信者は今待っています。 XNUMX 番目の荷物が紛失したのか、それとももうすぐ届くのかはわかりません。 また、ネットワークに過負荷がかからないように、パケットが失われたという明示的な指示、または RTO タイムアウトの期限が切れるまで待機しようとします。


RTO タイムアウトとは何ですか? これは、TCP スタックと何らかの定数によって計算された RTT からの最大値です。 この定数とは何なのか、これから説明します。


ただし、運悪く再び XNUMX 番目のパケットが失われた場合、RTO は XNUMX 倍になることが重要です。 つまり、試行が失敗するたびにタイムアウトが XNUMX 倍になります。


次に、この基数が何に等しいかを見てみましょう。 デフォルトでは、最小 RTO は 200 ミリ秒です。 これはデータ パケットの最小 RTO です。 SYN パケットの場合は異なり、1 秒です。 ご覧のとおり、最初のパケット再送信試行であっても、データセンター内の RTT よりも 100 倍の時間がかかります。


さて、シナリオに戻りましょう。 サービスはどうなっているのでしょうか？ サービスでパケットが失われ始めます。 サービスが最初は幸運で、ウィンドウの途中で何かを失った場合、サービスは SACK を受信し、失われたパケットを再送信します。


しかし、不運が繰り返される場合は、RTO が必要になります。 ここで重要なことは何ですか? はい、ネットワークにはたくさんのパスがあります。 ただし、特定の TCP 接続の TCP トラフィックは、同じ壊れたスタックを通過し続けます。 Magic X11 が自動的に動作しなくなる限り、パケット損失が発生しても、問題のないエリアにトラフィックが流れることはありません。 同じ壊れたスタックを介してパケットを配信しようとしています。 これは連鎖的な障害につながります。データ センターは対話するアプリケーションのセットであり、これらすべてのアプリケーションの TCP 接続の一部が低下し始めます。これは、スーパースピンがデータ センター内のすべてのアプリケーションに影響を与えるためです。 ことわざにあるように、馬に靴を履かなければ、馬は足を引きずってしまいます。 馬は足を引きずった - 報告書は届けられなかった。 メッセージは届けられなかった - 彼らは戦争に負けた。 ここでのみ、問題が発生した瞬間からサービスの低下が感じられ始めるまでの秒数がカウントされます。 これは、ユーザーがどこかで何かを受け取れない可能性があることを意味します。


相互に補完する XNUMX つの古典的なソリューションがあります。 XNUMX つ目は、次のような問題を解決しようとしているサービスです。「TCP スタックの何かを調整しましょう。」 そして、内部ヘルスチェックを使用して、アプリケーションレベルのタイムアウトまたは存続期間の長い TCP セッションを作成しましょう。 問題は、そのようなソリューションが次のとおりであることです。 a) まったく拡張できない。 b) テストが非常に不十分である。 つまり、サービスが誤って TCP スタックを構成して改善されたとしても、第一に、これがすべてのアプリケーションとすべてのデータセンターに適用できる可能性は低く、第二に、何が正しく実行されたのか、何が行われたのかを理解できない可能性が高くなります。いいえ。 つまり、機能しますが、機能が低く、拡張性がありません。 ネットワークに問題が発生した場合、誰が責任を負うのでしょうか? もちろんNOCです。 NOCって何をするの？

多くのサービスは、NOC では仕事は次のように行われると考えています。 しかし、正直に言うと、それだけではありません。


NOC は古典的なスキームで多くのモニタリングの開発に取り組んでいます。 これらは、ブラック ボックス モニタリングとホワイト ボックス モニタリングの両方です。 スパインのブラックボックスモニタリングの例について 私は言いました 過去のネクストホップについて語るアレクサンダー・クリメンコ。 ちなみに、この監視は機能します。 しかし、完璧な監視であってもタイムラグは生じます。 通常は数分です。 動作後、当直のエンジニアは動作を再確認し、問題の箇所を特定し、問題箇所を解消するのに時間がかかります。 つまり、損失が発生した場所がすぐに明らかでない場合、問題の処理には最良の場合でも 5 分、最悪の場合でも 20 分かかります。 この間、5 分でも 20 分でも、サービスに損害が発生し続けることは明らかであり、これはおそらく良くありません。


何を受け取りたいですか？ 私たちにはたくさんの道​​があります。 そして、運が悪い TCP フローが同じルートを使用し続けるために問題が発生します。 単一の TCP 接続内で複数のルートを使用できるようにするものが必要です。 解決策はあるようです。 TCP には、いわゆるマルチパス TCP、つまり多くのパスの TCP があります。 確かに、それはまったく異なるタスク、つまり複数のネットワークデバイスを備えたスマートフォン用に開発されました。 転送を最大化したり、プライマリ/バックアップ モードを作成したりするために、アプリケーション用に複数のスレッド (セッション) を透過的に作成し、障害が発生した場合にそれらを切り替えることができるメカニズムが開発されました。 あるいは、先ほども述べたように、帯域幅を最大化します。

しかし、ここにはニュアンスがあります。 それが何であるかを理解するには、ストリームがどのように設定されているかを確認する必要があります。


スレッドは順番に設定されます。 最初のストリームが最初にインストールされます。 後続のフローは、そのスレッド内ですでに合意されている Cookie を使用して設定されます。 そしてここに問題があります。


問題は、最初のスレッドがインストールされないと、XNUMX 番目と XNUMX 番目のスレッドが決して起動しないことです。 つまり、マルチパス TCP では、最初のストリームの SYN パケットの損失は解決されません。 また、SYN が失われると、マルチパス TCP は通常の TCP になります。 したがって、データセンター環境では、工場での損失の問題を解決したり、障害が発生した場合に複数のパスを使用する方法を学習したりすることはできません。


何が私たちを助けてくれるでしょうか？ 名前から、今後の話で重要なフィールドが IPv6 フロー ラベル ヘッダー フィールドであることをすでに推測している方もいるでしょう。 実際、これは v6 に登場するフィールドですが、v4 にはなく、20 ビット必要であり、その使用については長い間論争がありました。 これは非常に興味深いことです。論争があり、RFC の枠組み内で何かが修正され、同時に、どこにも文書化されていない実装が Linux カーネルに登場しました。


ちょっとした調査に参加することをお勧めします。 過去数年間に Linux カーネルで何が起こったのかを見てみましょう。

2014年。 評判の高い大企業のエンジニアが、Linux カーネルの機能に、ソケットのハッシュに対するフロー ラベルの値の依存性を追加しました。 彼らはここで何を直そうとしているのでしょうか？ これは、次の問題について説明した RFC 6438 に関連しています。 データセンター内では、工場自体が IPv4 であるため、IPv6 が IPv6 パケットにカプセル化されることがよくありますが、何らかの方法で IPv4 を配布する必要があります。 スイッチには長い間、5 つの IP ヘッダーを調べて TCP または UDP にアクセスし、そこにある src_ports と dst_ports を見つけることができないという問題がありました。 最初の XNUMX つの IP ヘッダーを見ると、ハッシュはほぼ修正されていることがわかりました。 これを回避して、このカプセル化されたトラフィックのバランシングが正しく機能するように、XNUMX タプルのカプセル化されたパケットのハッシュをフロー ラベル フィールドの値に追加することが提案されました。 他のカプセル化スキーム、UDP、GRE についてもほぼ同じことが行われ、後者では GRE Key フィールドが使用されました。 いずれにせよ、ここでの目標は明確です。 そして、少なくともその時点では、それらは役に立ちました。

2015 年、同じ尊敬されるエンジニアから新しいパッチが提供されました。 彼はとても興味深い人です。 これには次のように書かれています - ネガティブなルーティング イベントの場合にはハッシュをランダム化します。 ネガティブ ルーティング イベントとは何ですか? これは、先ほど説明した RTO です。つまり、ウィンドウ テールの損失は、非常にネガティブなイベントです。 確かに、それが何であるかを推測するのは比較的困難です。

2016 年も評判の良い企業で、こちらも大手です。 これは最後の松葉杖を解析し、以前にランダム化したハッシュが SYN 再送信ごと、および RTO タイムアウトごとに変更されるようにします。 そしてこの手紙では、最初で最後となる最終的な目標が掲げられています。それは、チャネルの損失または過負荷が発生した場合に、トラフィックが複数のパスを使用してソフト再ルーティングできるようにすることです。 もちろん、その後も出版物はたくさん出ていて、簡単に見つけることができます。

いいえ、できませんが、このトピックに関する出版物は一冊も存在しないためです。 しかし、私たちは知っています！

何が行われたのか完全に理解していない場合は、今すぐ説明します。


Linux カーネルには何が行われ、どのような機能が追加されましたか? txhash は、RTO イベントが発生するたびにランダムな値に変更されます。 これは同じネガティブ配線結果です。 ハッシュはこの txhash に依存し、フロー ラベルは skb ハッシュに依存します。 ここには関数に関する計算がいくつかあり、すべての詳細を XNUMX つのスライドに配置することはできません。 興味のある人は、カーネル コードを調べて確認してください。

ここで重要なことは何ですか? フロー ラベル フィールドの値は、RTO ごとに乱数に変わります。 これは私たちの不運な TCP ストリームにどのような影響を与えるでしょうか?


SACK の場合、既知の失われたパケットを再送信しようとしているため、何も変化しません。 ここまでは順調ですね。


ただし、RTO の場合、ToR のハッシュ関数にフロー ラベルを追加していれば、トラフィックは別のルートを通ることができます。 また、飛行機の数が多いほど、特定のデバイスのクラッシュの影響を受けないパスが見つかる可能性が高くなります。


RTO という問題が 200 つ残っています。 もちろん、別のルートが見つかりますが、それには多くの時間がかかります。 1ミリ秒は長いです。 XNUMX番目は一般的に野生です。 前に、サービスを構成するタイムアウトについて説明しました。 したがって、XNUMX 番目は、通常はアプリケーション レベルでサービスを設定するタイムアウトであり、この場合、サービスは比較的適切です。 さらに、繰り返しますが、最新のデータセンター内の実際の RTT は約 XNUMX ミリ秒です。


RTO タイムアウトについて何ができるでしょうか? データ パケット損失の場合に RTO の原因となるタイムアウトは、ユーザー空間から比較的簡単に設定できます。IP ユーティリティがあり、そのパラメータの XNUMX つに同じ rto_min が含まれています。 もちろん、RTO をグローバルにではなく、特定のプレフィックスに対して有効にする必要があることを考慮すると、そのようなメカニズムは非常に機能しているように見えます。


確かに、SYN_RTO を使用すると、すべてが多少悪くなります。 自然と定着していきます。 値はコアで固定されています - 1 秒、それだけです。 ユーザー空間からはアクセスできません。 方法は XNUMX つだけです。


eBPF が助けになります。 簡単に言うと、これらは小さな C プログラムであり、カーネル スタックと TCP スタックの実行のさまざまな場所にあるフックに挿入でき、これを使用して非常に多くの設定を変更できます。 一般に、eBPF は長期的な傾向です。 数十の新しい sysctl パラメータを追加して IP ユーティリティを拡張する代わりに、この動きは eBPF とその機能を拡張する方向にあります。 eBPF を使用すると、輻輳制御やその他のさまざまな TCP 設定を動的に変更できます。


しかし、それを利用して SYN_RTO の値を変更できることが重要です。 そして、公開されている例があります。 https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c。 ここでは何が行われているのでしょうか？ この例は機能していますが、それ自体は非常に大雑把です。 ここでは、データセンター内で最初の 44 ビットを比較し、一致する場合は DC 内にいることを前提としています。 この場合、SYN_RTO タイムアウトの値を 4ms に変更します。 同じタスクをよりスムーズに実行できます。 しかし、この簡単な例は、次のことが可能であることを示しています。 b) 比較的簡単。

私たちがすでに知っていることは何でしょうか? 平面アーキテクチャによってスケーリングが可能になるため、ToR でフロー ラベルをオンにして、問題領域を回避する機会を得るときに非常に便利であることがわかります。 RTO および SYN-RTO 値を下げる最良の方法は、eBPF プログラムを使用することです。 フローラベルをバランシングに使用しても安全なのかという疑問が残ります。 そして、ここにはニュアンスがあります。


ネットワーク上にエニーキャストで動作するサービスがあるとします。 残念ながら、エニーキャストについて詳しく説明する時間がありませんが、これは、同じ IP アドレス上で異なる物理サーバーが利用できる分散サービスです。 そして、ここに考えられる問題があります。RTO イベントは、トラフィックが工場を通過するときだけではなく発生する可能性があります。 これは ToR バッファ レベルでも発生する可能性があります。インキャスト イベントが発生したとき、ホストが何かをスピルしたときにホスト上でも発生する可能性があります。 RTO イベントが発生し、フロー ラベルが変更されたとき。 この場合、トラフィックは別のエニーキャスト インスタンスに送信される可能性があります。 それがステートフル エニーキャストであると仮定すると、それには接続状態が含まれており、L3 バランサーまたはその他のサービスである可能性があります。 RTO の後、TCP 接続はサーバーに到着しますが、サーバーはこの TCP 接続について何も知らないため、問題が発生します。 また、エニーキャスト サーバー間で状態を共有していない場合、そのようなトラフィックはドロップされ、TCP 接続は切断されます。


ここで何ができるでしょうか？ フロー ラベル バランシングを有効にする制御された環境内では、エニーキャスト サーバーにアクセスするときにフロー ラベルの値を修正する必要があります。 最も簡単な方法は、同じ eBPF プログラムを通じてこれを行うことです。 しかし、ここで非常に重要な点があります。データセンター ネットワークを運用していないが通信事業者である場合はどうすればよいでしょうか。 これはあなたの問題でもあります。Juniper と Arista の特定のバージョンから、デフォルトでハッシュ関数にフロー ラベルが含まれるようになりました。正直に言うと、理由はわかりません。 これにより、ネットワークを経由するユーザーからの TCP 接続が切断される可能性があります。 したがって、この場所でルーターの設定を確認することを強くお勧めします。

いずれにせよ、実験に移る準備ができているように思えます。


ToR でフロー ラベルをオンにし、ホスト上に存在するエージェントの eBPF を準備したとき、次の大きな障害を待つのではなく、制御された爆発を実行することにしました。 私たちは 75 つのアップリンクを持つ ToR を採用し、そのうちの 25 つにドロップを作成しました。 彼らはルールを決めた、つまり今ではすべてのパケットを失うことになる、と彼らは言いました。 左側にあるように、パケットごとのモニタリングが行われていますが、これは 25% に低下しています。つまり、パケットの 3% が失われています。 右側は、この ToR の背後にあるサービスのグラフです。 実際、これらはラック内のサーバーとの接続部分のトラフィック グラフです。 ご覧のとおり、さらに低く沈みました。 なぜ、4% ではなく、場合によっては XNUMX ～ XNUMX 倍も低下したのでしょうか? TCP 接続がうまくいかない場合は、壊れたインターフェイスを介して接続を試行し続けます。 これは、DC 内のサービスの一般的な動作によってさらに悪化します。XNUMX つのユーザー要求に対して、内部サービスへの N 個の要求が生成され、すべてのデータ ソースが応答するか、タイムアウトがトリガーされたときに、応答がユーザーに送信されます。アプリケーション レベル。まだ構成する必要があります。 つまり、すべてが非常に悪いということです。


同じ実験ですが、フロー ラベルが有効になっています。 左側にあるように、バッチ監視は同じ 25% 減少しました。 これはまったく正しいです。再送信については何も知らず、パケットを送信し、単に配信されたパケットと失われたパケットの数の比率をカウントするだけです。

そして右側にはサービススケジュールが表示されます。 ここでは問題のあるジョイントの影響は見つかりません。 同じミリ秒間のトラフィックは、問題エリアから問題の影響を受けなかった残りの XNUMX つのアップリンクに流れました。 私たちは自らを修復するネットワークを手に入れました。

これが最後のスライドです。評価してみましょう。 ここで、自己修復データセンター ネットワークを構築する方法を理解できたと思います。 Linux カーネル アーカイブを調べてそこで特別なパッチを探す必要はありません。この場合、Flow ラベルが問題を解決することはわかっていますが、このメカニズムには慎重に取り組む必要があります。 そして、通信事業者の場合は、フロー ラベルをハッシュ関数として使用すべきではないことを再度強調します。そうしないと、ユーザーのセッションが中断されてしまいます。

ネットワーク エンジニアにとって、ネットワークは ToR やネットワーク デバイスからではなく、ホストから始まるという概念の変化を起こす必要があります。 かなり印象的な例は、RTO の変更とエニーキャスト サービスへのフロー ラベルの修正の両方に eBPF を使用する方法です。

フロー ラベルの仕組みは、制御された管理セグメント内の他の用途にも確かに適しています。 これはデータセンター間のトラフィックである場合もあれば、そのような仕組みを特別な方法で使用して発信トラフィックを制御することもできます。 しかし、これについては次回お話しできればと思います。 ご清聴ありがとうございました。

出所： habr.com