コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第74回　VPCネットワークを支える仮想ネットワーク基盤：Andromeda（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第74回　VPCネットワークを支える仮想ネットワーク基盤：Andromeda（パート2） (中井悦司) 2020年1月

はじめに

　前回に引き続き、2018年に公開された論文「Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization」を元にして、Google Cloud Platform（GCP）のVirtual Private Cloud（VPC）ネットワークを支える仮想ネットワーク基盤を紹介していきます。今回は、Andromedaを構成するコントロールプレーンとデータプレーンについて、具体的なアーキテクチャーを解説したいと思います。

Andromedaの全体像とコントロールプレーン

　まず、次の図1は、論文に記載されているAndromedaの全体像になります。上半分は、仮想ネットワークの構成を行う管理系の部分で、SDNの用語で言うとコントロールプレーンにあたります。そして、下半分は、ホスト上のVMが外部とのネットワーク通信を行う仕組みを表しており、SDNの用語で言うとデータプレーンにあたります。

図1 Andromedaの全体像（論文より抜粋）

　はじめに、コントロールプレーンの概要を説明します。Googleのデータセンターには、複数のサーバーを束ねたクラスターが配置されていますが、それぞれのクラスターに対してコントロールプレーンのセットがインストールされており、該当のクラスター内のホスト、および、VMの構成情報を保持します。コントロールプレーンの処理をクラスターごとに分散化して、スケーラビリティを確保する仕組みになります。
　コントロールプレーンの一番上にある「Fabric Manager API」は、仮想ネットワークの構成変更リクエストを外部から受け付けるAPIを提供します。この部分では「何を実現したいか」を示す、いわゆる宣言的な定義をAPIで受け取ります。外部のアプリケーションや人間のオペレーターが、具体的な設定内容を指示する必要はありません。その下の「VM Controller(VMC)」は、クラスター内のホストの構成情報に基づいて、具体的な設定内容を決定します。それぞれのホストの仮想ネットワークは、Open vSwitchで構成されており、「OpenFlow Front End(OFE)」を経由して、Open vSwitchの構成変更が行われます。
このOFEは、VMCからの構成変更リクエストをOpen vSwitchの構成情報に翻訳する役割を持っており、VMC自身は、Open vSwitchの仕様変更などを意識する必要はありません。また、OFEは、ホスト、および、ホスト上のVMの状態を監視しています。VMに仮想NICが追加されるなどの構成変更は、OFEが検知して、その情報をVMCに伝えます。
　なお、クラスター内では複数のVMC、および、OFEが稼働しており、この部分でもスケーラビリティと冗長性を確保するようになっています。図2は、複数のVMCとOFEが連携する様子を示したものになります。一番上のCMは、クラスタ全体の構成管理を行うCluster Managerです。

図2 VMCとOFEの分散配置（論文より抜粋）

Andromedaのデータプレーン

　次に、図1の下半分にあるデータプレーンを説明します。図3は、データプレーンの詳細を示したもので、これを見ると、VMから送信されたパケットは、まずは「Fast Path」と呼ばれる経路を通る事がわかります。この部分の実態は、独自に機能拡張されたOpen vSwitchで、ホストOSのカーネルを経由せず、専用に予約されたCPU coreがダイレクトにパケットの処理を行います。

図3 データプレーンの詳細（論文より抜粋）

　ただし、すべてのルーティング処理をFast Pathで行おうとすると、高負荷時の性能劣化がどうしても発生してしまいます。そこで、低レイテンシーが要求されるフローは、Fast Pathだけで処理を完結して、対向のVMホストにダイレクトにパケットを転送しながら、それ以外のフローについては、VM Coprocessor、および、外部にあるHover board（ソフトウェアスイッチ）に処理を移譲するという仕組みが実装されています。それぞれのフローの重要度については、直近のパケット転送量などに基づいて、ヒューリスティックに判断されるようになっています。
　VM CoprocessorとHover boardの役割の違いは、次のようになります。まず、VM Coprocessorの場合、ルーティングの計算そのものはFast Pathで行われますが、ファイアウォールによるパケットフィルタリングなど、それに付随する処理をVMホスト上の別スレッドで行います。それぞれのVMについて、専用のVM Coprocessorのスレッドが用意されています。一方、Hover boardの場合は、ルーティングの計算そのものを外部のソフトウェアスイッチに移譲する形になります。Fast PathのvSwitchは、フローテーブルのエントリーにマッチしないパケットは、すべてHover boardに転送します。
　一般に、SNDで仮想ネットワークを構成する際は、すべてのルーティングをvSwitchで行う方式と、すべてのルーティングを外部のソフトウェアスイッチで行う方式があります。Andromedaは、これらを融合したハイブリッド方式と言えるでしょう。

次回予告

　今回は、2018年に公開された論文「Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization」を元にして、GCPのVPCネットワークを支える仮想ネットワーク基盤であるAndromedaについて、コントロールプレーンとデータプレーンのアーキテクチャーを説明しました。次回は、これまでのAndromedaの開発の経緯、そして、Andromedaによる性能向上を表すデータなどを紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡