UCloudのXu Liang氏との独占インタビュー：UCloudの仮想ネットワークの進化

[51CTO.com からのオリジナル記事] 今日、ほぼすべての IT インフラストラクチャがクラウドに移行しています。インフラストラクチャでは、サーバーとストレージの仮想化が比較的成熟して発展しています。仮想ネットワークはインフラストラクチャとして、クラウドコンピューティングとインターネットの発展のニーズを満たすために、新たな課題をもたらしました。 UCloud仮想ネットワークプラットフォームの責任者であるXu Liang氏がこの問題を解決しました。

UCloudの仮想ネットワークプラットフォーム責任者であるXu Liang氏は、同社初のレベル5技術専門家です。彼は上海ベルとテンセントで勤務し、通信およびインターネット業界の研究開発管理で 18 年以上の経験を積んでいます。 UCloud に入社後は、UXR ネットワーク分離、ネットワーク製品アーキテクチャのアップグレード、仮想ネットワーク アーキテクチャのアップグレードなど、クラウド プラットフォームのネットワーク アーキテクチャを主に担当しています。

[[245837]]

ネットワーク仮想化とSDN

ネットワーク仮想化は長い歴史を持つ概念です。一般的に、最初のネットワーク仮想化は VLAN から始まったと考えられています。ネットワーク仮想化により、1 つの物理ネットワークで複数の論理ネットワークをサポートできるようになります。仮想化によりネットワークが保護される

設計で提供される固有の階層構造、データ チャネル、およびサービスにより、エンド ユーザー エクスペリエンスは専用の物理ネットワークと同じになります。これには、ネットワーク リソースをより有効に活用し、過剰に使用されているリソース上のトラフィックを分散するという 3 つの大きな利点があります。専用の物理アーキテクチャを導入せずに一部の分離操作を実現し、ネットワーク セキュリティを向上します。ポートを統合してネットワークの使用率とパフォーマンスを向上させます。

SDN (ソフトウェア定義ネットワーク) は、ネットワーク デバイスの制御プレーンをデータ プレーンから分離し、ソフトウェアで実装します (つまり、ソフトウェア定義ネットワーク)。 SDN を使用すると、ネットワーク管理者はハードウェア機器を変更することなく、集中管理されたプログラムを使用してネットワークを再計画できます。ネットワーク トラフィックを制御するための新しいソリューションと、コア ネットワークおよびアプリケーションの革新のための優れたプラットフォームを提供し、ネットワーク仮想化の開発の強力な推進者となります。

クラウドコンピューティングはネットワーク仮想化に新たな課題をもたらす

まず、クラウド コンピューティング、特にパブリック クラウドでは、マルチテナント機能と VPC 機能を提供するためにネットワーク仮想化が必要です。 VPC (仮想プライベートクラウド) では、異なるテナントまたは同じテナントのネットワーク アドレスを重複させ、ブロードキャスト ドメインを独立させることができるため、必然的にネットワーク仮想化が必要になります。最も初期のネットワーク仮想化は VLAN プロトコルでしたが、VLAN プロトコルの VID は 12 ビットしかなく、4094 の仮想ネットワークしかサポートされていないため、パブリック クラウド環境では到底不十分です。このため、パブリック クラウド ベンダーは、この問題を解決するために Overlay テクノロジーを導入するようになりました。初期の NVGRE から現在の主流の VxLAN、さらに新しい GENEVE まで、すべてが 24 ビット (16M) のテナント ID をサポートし、パブリック クラウドのニーズを満たしています。

第二に、クラウド コンピューティングでは、柔軟で弾力性のあるコントロール プレーンを提供するために SDN が必要です。従来のネットワークでは、主にハードウェア デバイスが使用されます。新しいテナントが追加された場合、それぞれの構成が異なるため、ハードウェア デバイスを構成することが困難になります。しかし、コンピューティング手法を使用すれば、物理的なネットワークデバイスに触れることなく、ソフトウェアを通じてネットワーク構成を動的に変更できるため、ネットワーク仮想化はコンピューティングと同じくらい簡単、高速、かつ動的になります。

例: テナント VPC-100 の VM 10.10.12.34 が同じサブネット内の別の IP 10.10.56.78 にアクセスする場合、まず ARP プロトコルを通じて 10.10.56.78 の MAC アドレスを取得する必要があります。この ARP 要求メッセージがホストの vSwitch に到達すると、VPC が存在するため、IP アドレスが異なるテナントによって再利用される可能性があるため、まず ARP 要求が VPC-100 から来ていることを識別し、ARP メッセージが VPC-100 の下の IP 10.10.56.78 を要求していることを識別する必要があります。 Overlay ネットワークはブロードキャストをサポートしていないため、サブネット内のすべての VM が配置されているホスト マシンの場所を把握して、ARP 要求を Overlay でカプセル化し、宛先ホスト マシンに送信できるようにする必要があります。もちろん、vSwitch が VPC-100 の 10.10.56.78 の MAC が 52:54:12:34:56:78 であることを知っていれば、ARP プロキシ テクノロジーを使用して ARP 応答を直接返すこともできます。これらはすべてネットワーク デバイスによって自動的に実行されるのではなく、SDN を介したソフトウェア制御によって実現されます。

さらに、オーバーレイは物理ネットワークに大きな複雑さをもたらし、ハードウェアのサポートは非​​常に遅くなります。 Xu Liang 氏は証拠として、最も人気のある 10G ネットワーク カード チップ Intel 82599 がオーバーレイ プロトコルのオフロードをサポートしていないという例を挙げました。 Mellanox ネットワーク カードが VxLAN の TSO オフロードを徐々にサポートし始めたのは今年になってからでした。スイッチ チップが VxLAN プロトコルをサポートするまでに 5 年かかり、他のオーバーレイ プロトコルはスイッチ チップでまだサポートされていないため、オーバーレイ ネットワークのパフォーマンスは長い間物理ネットワークよりも低いままでした。

UCloud仮想ネットワーク開発の歴史

UCloud が 2012 年に初めて設立されたとき、仮想ネットワークは IaaS の中核コンポーネントでした。当時は、テナント分離を実現するために EBTables と IPTables の組み合わせが使用されていました。しかし、UCloud チームはすぐに、この技術的ソリューションでは顧客に安全で安定したサービスを提供するには不十分であることに気付きました。

そこで、2013 年から、UCloud の仮想ネットワークでは、テナント分離を実現するために SDN テクノロジー、つまり VPC (仮想プライベート クラウド) が使用され始めました。同年末、UCloudは、顧客がクラウドホストを利用する際に物理マシン（ベアメタル）も利用したいというニーズがあることに気づき、Centec社のSDNスイッチをいち早く採用し、パブリッククラウドネットワークと相互接続する物理クラウドホスト製品を発売した。

2015 年、顧客ビジネスの急速な発展に伴い、ハードウェア SDN スイッチの OpenFlow フロー テーブルの限られたエントリでは、物理クラウド ホストのニーズをサポートできなくなりました。 UCloud は、ハードウェア SDN スイッチを置き換えるために、DPDK テクノロジーを使用してサーバー クラスターを迅速に開発しました。その後、OVS を補完する DPDK ゲートウェイが UCloud の仮想ネットワークにさらに追加され、顧客にさらに高速な仮想ネットワークが提供されるようになりました。

2017 年以降、25G ネットワークの開発に伴い、UCloud はハードウェア オフロードに基づく仮想ネットワーク ソリューションの開発を開始しました。最終的に確認された方向性は、プログラム可能なスイッチとスマート ネットワーク カードの両方を同時に進化させることです。

コントロール プレーン フロー テーブル管理には、パッシブ トリガーとアクティブ プッシュという 2 つの主なソリューションがあります。パッシブ トリガー方式は、従来の OpenFlow フロー テーブル管理方式です。メッセージを受信すると、まずローカル フロー テーブル ヒットがあるかどうかを確認します。そうでない場合は、OpenFlow Packet-in メッセージを介して処理するためにコントローラに送信します。コントローラは、このタイプのメッセージを処理するために新しいフロー テーブルを送信します。アクティブ プッシュ方式は、ネットワーク トポロジが変更されたときに、変更されたフロー テーブルを転送プレーンにアクティブにプッシュする方法です。

初期の頃、UCloud は主にパッシブ トリガー方式を使用していました。実装が簡単なのが利点ですが、最初のパケットが遅延することや、制御面がユーザーの行動に大きく左右され、緊急事態が多く発生する可能性があることが欠点です。最初のパケットの遅延の問題に対処するために、UCloud は、ユーザーがパケットを外部に送信することを積極的にシミュレートしてフロー テーブルの送信をトリガーし、アクティブ プッシュと同様の効果を実現します。頻繁なコントロール プレーンのバーストの問題に対処するために、ローカル コントローラは、パケット イン メッセージをリモート コントローラに送信する前に、パケット イン メッセージのフローを重複排除して制限します。

UCloud は、多数の DPDK ゲートウェイを導入した後、アクティブ プッシュ メソッドも使用しています。その利点は、最初のパケットの遅延が効果的に排除され、転送プレーンに影響を与えずに制御プレーンの圧力をより制御できることです。ただし、アクティブ プッシュ方式の問題点は、仮想ネットワークが大きい場合、プッシュ範囲が非常に大きくなり、プッシュ時間が長くなりすぎて、ネットワークの変更がリアルタイムで有効にならない可能性があることです。

上記の問題に対応するため、UCloud は現在、これら 2 つを組み合わせる新しい方法を検討しています。

UCloud仮想ネットワークの課題と解決策

仮想ネットワーク分野は、10 年近くの進化を経て、依然として急速な発展、変化、そして百もの学派の争いの段階にあり、UCloud 仮想ネットワーク チームにも多くの課題をもたらしています。

フォワーディングプレーンの課題と解決策

1. ネットワークカードの性能が1Gから10G、25G、100Gへと大幅に向上したことによるパフォーマンス上の課題

ネットワーク性能の向上速度がCPU性能の向上速度を上回っており、これが大きな課題となっています。 UCloud は現在、プログラム可能なスイッチやスマート ネットワーク カードなどのハードウェア オフロードを主に使用してこの問題を解決しています。

プログラム可能なP4スイッチソリューション

2017年第4四半期に、UCloudはBarefootのP4対応プログラマブルスイッチ（Tofinoチップ）に関する予備調査を開始し、P4とBarefoot Tofinoがニーズを十分に満たすことができることを発見しました。 P4 と Barefoot Tofino の主な利点は次のとおりです。

1. DPDK と比較して、転送パフォーマンスが高くなります。 DPDK は基本的に、単一マシンで 10G または 25G のパフォーマンスを備えたネットワーク カードを使用します。プログラム可能なスイッチの場合、出発点は 1.8T ～ 6.5T のパフォーマンスであり、これは DPDK のパフォーマンスの数十倍、さらには 100 倍近くになります。さらに、スイッチのレイテンシは低く、単一のネットワーク ケーブルで 100G をサポートしているため、基本的に単一回線の輻輳の影響を回避できます。

2. スイッチの転送パフォーマンスは非常に安定しており予測可能ですが、DPDK の転送パフォーマンスはビジネス モデルによって変化する可能性があります。

3. 他のハードウェア スイッチと比較して、プログラム可能な P4 スイッチはよりオープンです。強力なプログラマビリティを備えており、転送プレーン上の p4lang 処理パケット全体をカスタマイズできます。プログラム可能な P4 スイッチは、Ethernet Over GRE およびフロー ベース トンネリングの問題を完全に解決できます。 P4 言語でプログラムを書くことは、DPDK の C 言語でプログラムを書くよりも簡単で、開発効率が高くなります。プログラム可能な P4 スイッチは基本的にリモート管理に gRPC インターフェイスを使用し、オペレーティング システムは Open Network Linux (Debian ベース) を使用するため、スイッチは従来のサーバーに似たものになります。さらに、他のスイッチと比較して、プログラム可能な P4 スイッチには、P4 Runtime や Stratum などのオープン ソース コミュニティを含むエコシステムがあり、スイッチの開発をより効果的に促進します。

現在、UCloud は P4 プログラマブル スイッチを使用した新しいコア ゲートウェイの開発とテストを完了し、展開とグレースケールの起動を開始しています。

スマートNICソリューション

同時に、UCloud はコンピューティング ノードにおいて、25G ネットワークによってもたらされるパフォーマンスの課題を解決する方法も模索しています。

VMware が仮想化を支配していた初期の段階では、VLAN によるテナント分離と、SRIOV を介して仮想マシンが使用できるようにハードウェア ネットワーク カードを複数の仮想ネットワーク カードに仮想化するという手法が非常に成熟した効率的なソリューションでした。 SRIOV を使用することで、仮想マシンは物理ネットワーク カードの PPS パフォーマンスの 95% 以上を実現できます。ただし、12 ビット VLAN では最大 4094 テナントしかサポートできないため、パブリック クラウドのニーズを満たすことができず、レイヤー 2 ネットワーキング方式はパブリック クラウドの大規模データ センターには適していません。ほぼすべてのパブリック クラウドは Overlay ソリューションを使用しています。オーバーレイ ソリューションは VLAN よりもはるかに複雑です。新世代の非インテリジェント ネットワーク カード ASIC チップのほとんどは、現在、VXLAN のカプセル化とカプセル化解除のみを実行できます。ただし、仮想マシンのホスト アドレス情報はコントロール プレーンによって提供される必要があるため、SRIOV テクノロジはオーバーレイ ネットワークではまったく役に立ちません。

Linux カーネル ベースの vSwitch と比較すると、DPDK ベースの vSwitch ソリューションはパケット転送パフォーマンスを数倍向上させます。 DPDK の Vhost ライブラリを介して、VM のネットワーク パケットはホスト マシン上の vSwitch に到達し、ゼロ コピー方式で Virtio 仮想ネットワーク カードを介して処理されます。ホスト マシン上の vSwitch は、コントロール プレーン情報に基づいて、宛先 MAC または IP が配置されているホスト マシン情報を学習し、高速転送のためにオーバーレイ カプセル化を追加します。しかし、その代償として、ほとんどのネットワーク カードは Busy Poll DPDK 動作モードしかサポートできません。仮想マシンの現在の PPS に関係なく、DPDK は一定数の CPU コアを占有し、この部分のコンピューティング リソースはアイドル時間中に販売できます。

SmartNIC の目標は、ネットワーク転送によって占有されているホスト コンピューティング リソースを解放し、TCO を削減するという目標を達成することです。現在、スマート ネットワーク カードの実装は数多く存在します。たとえば、AWS は汎用 ARM ベースのマルチコア ソリューションを採用し、AZure は FPGA ベースのソリューションを採用し、Huawei Cloud は専用のネットワーク プロセッサ (NP) ベースのソリューションを採用し、Alibaba Cloud はプログラム可能な ASIC チップ ベースのソリューションを採用しています。現時点では、それぞれの計画にはそれぞれの利点があり、世界を統一できるほどの特に優れた計画はありません。

一般的な ARM および MIPS マルチコア ソリューションに基づいて、ホスト マシン上で元々実行されていた vSwitch をネットワーク カードに移植するだけで、Linux カーネルと DPDK の両方をサポートできるため、ホスト マシンのコンピューティング リソースを解放するという目的を達成できます。 FPGA、NP、およびプログラム可能な ASIC に基づく他のほとんどのソリューションは、ネットワーク カード上で高速転送パス (FastPath) を維持します。メッセージを受信すると、まず、このタイプのメッセージの処理ルールが FastPath にキャッシュされているかどうかがチェックされます。見つかった場合は、ルールに従ってアクションを直接実行します。それ以外の場合は、処理のために SlowPath に転送します。この SlowPath は DPDK または Linux カーネルになります。したがって、FastPath にとって最も重要なことは、十分なアクションとカスタム アクションのスケーラビリティをサポートしているかどうかです。 SlowPath および FastPath 通信には、各メーカーの独自のインターフェースに加えて、DPDK によって提供される標準の TC オフロード インターフェースと RTE フロー インターフェースもあります。

ほぼすべてのスマート ネットワーク カードを SRIOV を使用して仮想マシンに接続できます。 VF でサポートされるキューの数も非常に重要です。複数のキューをサポートする VF のみが、RSS を通じて仮想マシンのマルチコアの利点を最大限に活用し、より高いネットワーク処理パフォーマンスを実現できます。 FastPath と SRIOV を統合することで、Smart NIC は仮想マシンのネットワーク パフォーマンスを物理 NIC に近づけることもできます。

ただし、SmartNIC が SRIOV を採用できない主な理由の 1 つは、仮想マシンのライブ マイグレーションです。 SRIOV モードでは、仮想マシンが VF を直接管理するため、ライブ マイグレーションは不可能になります。ライブマイグレーション問題に対する従来の解決策は、VF と Virtio Bind を通じてそれを回避することです。通常操作中は、高性能転送に VF を使用し、ライブ マイグレーションの前に VF ネットワーク カードをホット アンプラグして Virtio ネットワーク カードにシームレスに切り替え、ライブ マイグレーションが完了したら VF ネットワーク カードをホット インサートします。

当然のことながら、ライブ マイグレーション プロセス中に Virtio ネットワーク カードを使用するとネットワーク パフォーマンスが低下するため、ライブ マイグレーションはオフピーク時間帯に実行する必要があります。 Intel は、ライブ マイグレーションをより適切にサポートするために、VF 上の Virtio と互換性のある vhost データ パス アクセラレーション (vDPA) テクノロジーを提案しました。同時に、Virtio 1.1 仕様の導入により、ネットワーク カード ハードウェアと Virtio の互換性が容易になります。

現在、ホットマイグレーションをサポートするSRIOVベースのUCloudの高性能25Gスマートネットワークカードは社内テスト段階にあり、まもなく発売される予定です。

2. ステートフルサービス（セキュリティグループなど）の導入によってもたらされるパフォーマンスの課題

UCloud は、スマート ネットワーク カードを通じてファイアウォール、NAT、セキュリティ グループなどのステートフル サービスをオフロードできるようになることを期待しています。ステートフル サービスでは、接続追跡の実装が必要です。新しい接続には

FastPath は新しいルールを挿入するため、非常に高いルール更新速度が必要です。各接続は FastPath でルールを維持する必要があり、メモリに対する要求が非常に高くなります。接続ステータスの変更は FastPath と SlowPath 間で同期する必要があり、TCP ステータスが変更されたときに SEQ をチェックする必要があります。

UCloud は現在、いくつかの商用 SmartNIC をテストしています。スマート NIC が提供するステートフル サービスのサポートはますます充実しており、近い将来には十分に成熟したステートフル ビジネス ソリューションを提供できるようになると予想されます。

コントロールプレーンの課題と軽量な ServiceMesh ソリューション

仮想化の利点は明らかです。仮想化により、サーバー、コンピューティング、ネットワーク容量の利用効率が向上し、設備投資が削減されます。しかし同時に、仮想化は、仮想ネットワークの管理を担当するデータセンターの担当者に新たな課題をもたらします。

SDN のコントロール プレーンは、本質的には超大規模 (x 百万ノード) の分散システムである各コンピューティング ノードに展開する必要があります。直面する問題は従来の分散システムと同じで、CAP問題やスケーラビリティ問題などを解決する必要があります。変化の影響を軽減するために、UCloudでも徐々にマイクロサービス化を進め始めています。同時に、ユーザーによるグレースケールリリースをより適切に実装するために、軽量の ServiceMesh アーキテクチャが導入されました。

Lightweight ServiceMesh は、Envoy と Istio Pilot をベースにした Istio のバリアントです。 Istio は優れた ServiceMesh ソリューションです。 UCloud チームは Istio のトラフィック管理機能に非常に満足しており、評価を通じて Envoy のパフォーマンス オーバーヘッドも受け入れることができました。

ただし、UCloud は現在 K8S を使用していません。実際、UCloud が開発した IaaS コントロール プレーン プログラムには、K8S と同様の機能があります。さらに、UCloud には多数の既存サービスがあります。 K8S のネットワーク ソリューションは比較的複雑であり、そのパフォーマンスが懸念されます。 IPTables を使用してトラフィックを透過的に誘導することは、将来の操作とトラブルシューティングに非常に複雑な問題をもたらし、さらに事態を悪化させることになります。現在、UCloudではgRPCとHTTPが主に使用されていますが、データベースサービスなどK8Sでの実行に適さない業務も残っており、K8Sのネットワークソリューションは既存のデータベースサービスや他の業務と互換性がある必要があります。

Istio コードに関する予備調査を行った後、UCloud は最終的に Pilot を Istio から分離し、K8S から離れて軽量の ServiceMesh ソリューションを実行することを選択しました。 Istio では、Pilot は Envoy のコントロール プレーンとして集中型トラフィック管理機能を提供するモジュールです。これはグレースケールリリースには欠かせない機能であり、実はServiceMeshのコア機能です。 Mixer が提供するアクセス ポリシーと制御、および Istio-Auth が提供するセキュリティ認証機能は、どちらも UCloud のイントラネット環境で切り離すことができます。

Pilot の優れた設計により、ETCD プラットフォームを実装し、ETCD からサービスとサービス インスタンスの情報を取得することが容易になります。 UCloud は Pilott の main.go を書き直し、Pilot のモデル、プロキシ、プロキシ/エンボイ モジュールを保持し、他のプラットフォームを削除し、新しく追加された ETCD プラットフォームのみを保持しました。

最後に、完全な Istio DSL サポートを維持しながら、K8S から完全に独立して実行およびコンパイルされる Pilot ができました。同時に、Pilot と ETCD gRPC の命名と検出は深く統合されており、オンラインではない ServiceEntries を自動的に削除します。

K8S を離れた後も、Sidecar のデプロイ方法は必要です。 UCloud は、コンテナ アプローチを使用してマイクロサービスをパッケージ化してデプロイしますが、ホスト ネットワーク アプローチを使用して既存のサービスとのネットワーク通信を簡素化します。同時に、docker-compose は K8S の POD をシミュレートし、サービス間の依存関係を管理するために使用されます。シンプルなサービス管理、バージョン管理、クラスター管理、ルーティング ポリシー管理レイヤーを実装することで、クラスター内の各ノード (VM または物理サーバー) に対して docker-compose 構成ファイルが生成され、各ノードのサービス展開と管理が実装されます。

最後に、HTTP 1.0、HTTP 2.0、gRPC の RPC メソッドでは、IPTables の透過的な転送と Envoy の統合の代わりに明示的なプロキシが使用されます。サービスで Envoy プロキシ ポートが設定されている場合、ServiceMesh は Envoy を介して接続されます。 IP アドレスとポートが設定されている場合は、アドレスが直接接続されます。ドメイン名が設定されていて、Envoy Proxy が設定されていない場合、リモート サービスを検出するために ETCD gRPC 命名および検出方法が自動的に使用されます。

最後に、UCloud は Pilot と Envoy を使用して、ユーザーに応じたグレースケール リリースを簡単に実装しました。現在、ServiceMesh フレームワークは複数の UCloud プロジェクトで使用されています。

追記

Xu Liang は、UCloud 仮想ネットワーク チームに 3 年以上参加して、この分野が多様な意見に満ちた分野であり、依然として急速に変化していることを認識しました。しかし、「ソフトウェアがネットワークを飲み込んでいる」という傾向は常にはっきりと見られます。初期の SDN やソフトウェア vSwitch からスマート ネットワーク カードやプログラム可能なスイッチに至るまで、ネットワークにおけるソフトウェアの役割はますます重要になっています。

「インターネットとソフトウェアの両分野の発展に細心の注意を払い、自社のニーズを満たす新しい技術を消化・吸収することによってのみ、UCloudユーザーの発展に追いつき、顧客に安定したサービスを提供し、顧客のニーズを満たす使いやすく低コストの製品を提供することができます。」徐良は結論づけた。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]