💡

Bluebird: Azure SDN を支えるプログラマブル SDN ToR スイッチ

2022/04/15に公開

Azure

network

sdn

tech

みなさまこんにちは。Azure、使ってますか？

久しぶりに Microsoft Research の出版物を漁っていたところ、なにやら面白そうな論文が NSDI 2022 に投稿されているのを見つけたので、早速紹介記事を書きました。この話を知ってもそんなに特になることはないんですが、Azure 仮想ネットワークを深く知りたい、NetApp Files があんなに早く動く理由を知りたい！って方はぜひご一読を。

かいつまんで要点だけ話すと、以下の通りです。

Azure の仮想ネットワークは基本的に Host SDN で実現されていて、ホストの Hyper-v 仮想スイッチ内にあるソフトウェアがネットワークの仮想化を担当している。
その関係で、Hyper-v を入れられないベアメタルサーバー/アプライアンス製品は、VNet とネイティブにおしゃべりできない。
なので、ToR にネットワーク仮想化の機能を内包させた、つよつよ ToR を開発しました。
既に実戦投入されていて、Azure NetApp Files とか SAP の裏側で動いてるよ。

はじめに

従来、SDN のデータプレーンは、ハイパーバイザホストのネットワークスタックで「ソフトウェア」として実装されてきました。有名なもので言えば、Open V-Switch (OVW) や DPDK 等が代表例です。

それに加えて、スケールやパフォーマンスがより重要視されるようになった事から、ASIC や FPGA といったハードウェアに SDN 機能の一部をオフロードする技術も出現してきています。

しかし、実は、この流れから取り残されていたサポート外のワークロードがありました。それは、NetApp/SAP/HPC をはじめとする、汎用マシンではなく専用ハードウェアを使うサービスです。ここではそのようなサービスを Hardware as a Service (HWaaS) と呼ぶことにします。

HWaaS をホストするハードウェアは、汎用機ではないベアメタルサーバーです。MS お得意の Hypver-V を動かすこともできず、従来のソフトウェアによる SDN データプレーン実装が通用しません。これは困りましたね。

そこで考えられたのが、本日の主役 Bluebird です。Bluebird は、bump-in-the-wire (BITW) の考え方、すなわち、「ベアメタルサーバーに手を加えられないのであれば、SDN 機能を実現する装置を、サーバーと Top-of-Rack (ToR) スイッチの間に配置してやろう」という方法で HWaaS の課題を解決します。

まとめると、SDN を実装できない特殊なベアメタルサーバーをサポートするために、本来ハイパーバイザ/ホストで担うべき SDN 機能を ToR に移植してやったぜ、というお話です。

背景

Host SDN

Bluebird が何かを知るには、どんな機能を ToR に盛り込まないといけないのか、すなわち、通常のハイパーバイザホストに実装されている SDN 機能を知る必要があります。

とはいえ、Azure の仮想ネットワークを支える SDN 機能はひとつではありません。例えば、Network Security Group (NSG) として知られるファイアウォールの機能も実装されていますし、Billing のために通信量を記録する機能も必要です。

このような Azure の SDN 機能は、Hyper-V 仮想スイッチのプラグインとして実装されています。これを Virtual Filtering Platform (VFP) と言います。VFP が有する主な SDN 機能 (データプレーンとしての役割) は、以下の通りです。

パケットをカプセル化/非カプセル化する (オーバーレイネットワーク)
ファイアウォールルールに応じてパケットを許可/拒否する (ACL)
必要に応じて NAT を行う
課金のために通信量を記録する (Billing)

僕個人的に最も重要だと思うのは、カプセル化です。Azure の仮想ネットワーク (VNet) は、オーバーレイネットワーク方式の SDN で実現されています。そのため、VNet 上のあらゆるパケットは、VXLAN/NVGRE のようなトンネリングプロトコルでカプセル化を行ってから、Azure データセンターの物理ネットワーク上をルーティング・フォワーディングされます。ここで、オーバーレイ/アンダーレイネットワークのアドレスを以下のように呼び分けます。

Customer Address (CA): VNet / オーバーレイネットワーク上のアドレス
Physical Address (PA): 物理ネットワーク / アンダーレイネットワーク上のアドレス

カプセル化の作業では、宛先 CA は適切な PA に変換する必要があることに注意してください。ランダムな PA 宛にパケットを送信した場合、CA に対応する VM がそのホストに存在するとは限らないためです。つまり、VFP には CA と PA を対応付ける情報 (CA-PA マッピング) を保持させておき、カプセル化のたびにそれを参照させる必要があります。CA-PA マッピングは、この後にも少し出てくる話なので要点を抑えておきましょう。

さらに VFP の詳細を知りたい方は、以下の記事を参照してみてください。

SmartNIC-based SDN

ToR に SDN 機能を埋め込む話をする前に、言及しておくべき技術があります。それが SmartNIC です。

SmartNIC は、ASIC / SoC / FPGA から成るプログラマブルな物理 NIC で、一部の VFP 機能をハードウェアにオフロードできます。VFP と SmartNIC を組み合わせると、VFP 単体のときに比べて、極めて低レイテンシ・高スループットなネットワーク環境を実現できます。

実際のサービスとしても、「高速ネットワーク (Accerelated Networking)」なるものが Azure では提供されているのですが、まさにこのサービスの裏側で動いているのが SmartNIC です。ちなみに、高速ネットワークを普段から愛用している方はひょっとすると知っているかもしれませんが、SmartNIC はコネクション単位でキャッシュを作成する動作のため、頻繁にコネクションを作り直すようなワークロードでは力を発揮できません。こういった特性が気になる方は、上で紹介した SmartNIC の論文をご覧くださいまし。

SmartNIC は優秀なネットワーク装置である一方、ホスト側の VFP と協働する仕組みを取っています。つまり、SmartNIC を装着するハードウェア上で Hyper-V 動くことを前提としています。そのため、残念ながら今回の HWaaS 問題の解決策にはなりません。残念です。

SDN on ToR

従来のデータセンターでは、予め機能が定まった (プログラマブルでない) ネットワークスイッチを使います。SDN を実現するための機能はハイパーバイザ/ホスト側に実装され、ネットワーク側は単なる物理ネットワークとして実装されます。

一方で、ホストの代わりに SDN の役割を果たす、機能豊富なスイッチを考えることも出来ます。それが SDN on ToR です。

ただし、闇雲に SDN の機能を ToR に実装することは危険です。なんでもこなせる魔法の ToR は存在しません。開発スピード、複雑度、ToR の調達コストを考慮しつつ、実装対象の機能を限定するスコーピングが必要です。Bluebird では、次の 2 つの機能をもたせることにしました。

VXLAN トンネルに対応した Virtual Routing and Forwarding (VRF) 機能
CA-PA マッピングの参照機能

Bluebird を適当なベアメタルサーバーに接続すれば、ベアメタルサーバーから VNet 上 VM に対するパケットは、適切にカプセル化された後ルーティングすることが出来ます。反対に、VM からベアメタルサーバーに対する (カプセル化された状態の) パケットも、非カプセル化してベアメタルサーバーに転送されます。

思想

ベアメタルサーバー (HWaaS 用のハードウェア) 用の SDN ソリューションを開発するにあたって、以下の点が考慮されました。

プログラマビリティ (programability): SDN 機能は年々進化していくので、機能を随時書き換えられるようなモデルが必須です。Bluebird では、プログラマブルな ASIC を利用して対応しています。
スケーラビリティ (scalability): Host SDN の場合、ホスト上の VM 数に比例して VFP の負荷が高まるものの、あわせてホストの物理リソースも潤沢になるので SDN 機能が容易にスケールします。Bluebird の場合、ToR 配下の VM 数とスイッチスペックを比例させることは難しいので、ハードウエア性能を高めるキャッシュ機構を用いて対応しました。
レイテンシ/スループット (latency/throughput): ベアメタルサーバーのワークロードは、一般に高いネットワーク性能を要求します。この課題に対しては、ASIC を導入することで解決を図りました。
可用性 (availability): 障害やメンテナンスによるサービス影響が発生しないよう、高可用性であることが求められます。Bluebird では、冗長化の対策を実施しています。
マルチテナント (multitenancy support): Azure には数多くの仮想ネットワークが混在しています。ネットワークの分離性はもちろん、物理基盤が共有リソースであることを感じさせないようなユーザー体験を提供する必要もあります。
ホストでのオーバーヘッド削減: VFP ならびに SmartNIC では、大なり小なり SDN 処理にホストのリソースを消費します。一方 Bluebird では、SDN 処理を完全に外部委託することが出来るため、ベアメタルサーバーの性能を最大に引き出すことが可能です。
シームレスな統合: Azure サービスごとに、利用されるベアメタルサーバーの種類は異なるかもしれません。Bluebird であれば、ベアメタルサーバーの種類に依存せず、どんなものでも Azure 仮想ネットワーク環境に接続することが出来ます。
外部ネットワーク接続: ベアメタルサーバーからインターネット宛アクセスが発生すると、Source NAT (SNAT) をどこかで実施する必要があります。理想的には ToR で SNAT が出来ると嬉しいです。
相互運用性 (interoperability): 当たり前の話ではありますが、Bluebird につないだベアメタルサーバーは、従来の VFP を採用したホスト (並びにその上の VM) とコミュニケーションしなければなりません。VFP と対話できることは、絶対に外してはならない必要条件です。

システムデザイン

30 Tbps 以上のトラフィックをさばける高価なインターネットコアルーターと違って、データセンターの ToR スイッチは安価で性能も限定的です。Bluebird の実現のためには、そんな ToR に比較的多くの VNET 用ルーティングテーブルを載せなくてはならないので、工夫が必要です。

そこで、ToR のメモリを効率的に使い、メモリ上に配置出来る CA-PA マッピングの数を最大化することに注力しました。P4 と呼ばれるネットワーク処理用のプログラミング言語を使って、IPv4/IPv6 のユニキャストルートテーブルサイズを削減し、VXLAN Tunnel Endpoint (VTEP) = CA-PA Mapping の数も、当初 16K だったものを 192K まで増やすことに成功します。さらに、この後説明する "キャッシュ機構" により、ハードウェアリミットである 192K よりも多いエントリ数の VTEP テーブルをサポートすることにも成功します。

以下では、Bluebird を使った時のパケットのフロー、ToR に採用した ASIC、ならびにキャッシュ機構による工夫の話をしていきます。

パケットフロー

仮想ネットワーク上にデプロイされた 192.168.10.2 のアドレスを持つ Azure VM が、192.168.11.1 のアドレスを持つベアメタルサーバー (例: NetApp Files) と通信するシナリオを考えます。あくまでユーザーとして認識するアドレスは、この 2 つだけです。

ベアメタルサーバーから VM に対するパケットは、図の左側、緑色の 1/2/3/4 の順で転送されていきます。

ベアメタルサーバーが VM に対してパケットを送信する (VLAN 400)。
対応する ToR のインターフェイスにパケットが着信すると、VLAN 400 に対応する VRF (VNI: 20500) が参照される。VRF は、この仮想ネットワーク環境固有のものである。
ToR では、CA-PA マッピングを参照することで、宛先 VM に対応する MAC アドレスを知ることができる。パケットの宛先 MAC を書き換え、VXLAN VTEP からパケットが出ていく過程でカプセル化が行われる。
アウターパケットの宛先 IP アドレス (宛先 PA) である、VM ホストがパケットを受け取る。ここからは従来の方法で処理される。つまり仮想スイッチの VFP によって、非カプセル化や NAT 等の SDN データプレーン処理をした後、最終的に VM 側にパケットを渡す。

反対に、VM からベアメタルサーバーに対するパケット (戻り) は、図の右側の 1/2/3/4 の順で転送されていきます (やることは先程の反対なので割愛)。

製品選択

多くの VTEP (CA-PA マッピング) に対応するハードウェアスペック、プログラミング言語 P4 が使える、供給が安定している、等々の要因から、Bluebird にはインテルの「Tofino」が採用されています。

結果的に、P4 をパイプライン設計 (実装) に使ったことで以下のメリットを得られたそう。

プロトタイプの作成と検証のサイクルを、高速に回すことができた。
P4 Profile を切り替えることで、SDN on ToR の動作を切り替える機能を実装できた。

キャッシュ機構

P4 の言語仕様をカスタマイズしたり、実装を最適化するといった工夫により、Bluebird は以下の機能を実現できました。

192K までの CA-PA マッピングのサポート
IPv6アンダーレイサポート
1対1の静的 NAT

しかしながら、CA-PA マッピングの最大値が 192K では、すぐに Bluebird がボトルネックになることが判明します。次世代の Tofino-2 を採用する案も検討されましたが、ハードウェアに依存しない別の解法、つまりルートキャッシュにより CA-PA マッピングの最大値を引き伸ばす手法が考案されます。

キャッシュ機構は、すべてのユーザーが同時にすべての ToR を使うわけではない、という事実に基づき、直近により多くパケットを観測した CA-PA マッピングを優遇しよう、という戦略です。

前提として、Bluebird は CPU を積んでいるので、Tofino によるハードウェアパケット処理も、CPU によるソフトウェアパケット処理も可能です (Tofino と CPU 間の wire は 2x10 Gbps)。を結合するなのでヒット確率が高いパケットだけハードウェアで処理して、その他はケアしない (i.e., 最悪ソフトウェア処理でなんとかする) という戦法と取ることが出来ます。

より具体的に言えば、一定時間パケットが観測されない VTEP/マッピングを見つけると、Bluebird はハードウェア領域からデータを削除し、ソフトウェア領域のエントリとして退避させます。逆に、キャッシュに乗っていないマッピングのパケットを観測すると、一旦 CPU で処理した後、急いでハードウェア領域にデータを乗せ直します。キャッシングにかかる時間よりも、TCP の 3way handshake レイテンシのほうが遥かに長いため、実影響はほとんど出ません。

論文によれば、こうした戦略により、192K の 5 倍程まで、CA-PA マッピングをホストできるようになったようです。もちろん、ASIC のハードウェアスペックと、CPU 側で使えるメモリ次第ではありますが、概ね心配が必要ないレベルにまで拡張できるのは素晴らしいことです。

性能

既に Bluebird は Azure デビューを果たしてます！2020-2022 年の間、42 個のデータセンターで Bluebird が使われてきました。Azure NetApp Files も、Cray ClusterStor in Azure もその成果の例です。

気になる性能なんですが、高速ネットワークと同等であることが言及されています。凄いですね。残念ながら詳細な数字までは公開されていなかったのですが、Azure NetApp Files などを実際に使って、手元で性能を測定することも可能です。時間があるときに今度測定比較してみようと思います。

また、Bluebird 単体でのパフォーマンス調査についてはかなり詳細に分析されていました。その中から一つ例をあげると、Bluebird を DUT として、Bluebird のポートにトラフィック生成装置を直接接続し、さまざまなフレームサイズのトラフィックを流し込んだ時のスループット計測があります。

その結果が以下です。計測されたスループットの絶対値とそのラインレート比率を、フレームサイズごとに示した図です。ほとんどのシナリオ (パケットサイズ) でラインレート比 100% という素晴らしい数字を叩き出しています。凄いですね。

また、消費電力も優秀です。同じ帯域幅を持つ通常の ToR でも、平均/最大の消費電力が 314W/616W なのに対し、Bluebird は 271W/571W でした。

	通常の ToR	Bluebird
平均の消費電力(W)	314	🏆271
最大の消費電力(W)	616	🏆571

最後に

Azure インフラのファンとしてはなかなかしびれる内容でしたね (?)。Ananta/VFP/SmartNIC と立て続けに技術仕様が公開された後、すっかり MSR (Microsoft Research) が論文公開をやめてしまったので、もう公開していく方針やめたのかなぁと思ってしまっていましたが、忘れた頃にアメが降ってきました。

歴代の話を知っていたほうがより楽しく資料を読み込めると思うので、(出典重複ありますが) ぜひ時間のある方は以下の技術資料もご覧くださいませ。

Ananta (2013): Azure Load Balancer の実装について
https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p207.pdf
VFP (2017): Host SDN の基盤となるネットワーク仮想化技術
https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/publications/
SmartNIC (2018): VFP の HW オフローディング (高速ネットワーク)
https://www.microsoft.com/en-us/research/project/azure-smartnic/