私がオーバーレイトンネルを最初に使用したのは 2003 年、Squid と Cisco WCCP (Web Cache Communication protocol) に基づく透過プロキシを作成するプロジェクトに取り組んでいたときでした。Cisco ルーターと Squid プロキシ間の設定の一部で、通信に GRE (Generic Routing Encapsulation) トンネルを使用する必要がありました。当時、私はトンネルプロトコルの必要性を完全には理解していませんでしたが、今ではその重要性を理解しています。なぜなら、大規模なマルチテナントクラウドでは VLAN が壊れてしまうからです。

VLAN は、ネットワークトラフィックを小規模で複雑さの少ないネットワークにセグメント化するために開発されました。欠点は、固定の 12 ビットフィールドしかないことです。これは、1 つのネットワークトポロジーで約 4,000 の VLAN しか持つことができないことを意味します。1990 年代後半から 2000 年代前半には、これはネットワークに対応するのに十分すぎるほどのセグメントでした。しかし、クラウド時代の幕開けとマルチテナント環境に伴い、より多くの個別のネットワークトンネルが必要になりました。

この問題に対処するために、VXLAN (Virtual Extensible LAN)、NVGRE (Network Virtualization using Generic Routing Encapsulation)、STT (Stateless Transport Tunneling) など、さまざまなベンダーがさまざまなソリューションを提案してきました。3 つすべてが、アプリケーションデータを新しい大きな固定ヘッダーフィールドにカプセル化します。VXLAN と NVGRE (後者は主に Microsoft が使用) のヘッダーサイズは 24 ビットで、STT のヘッダーサイズは 64 ビットです。これらのカプセル化トンネリング方式は、いずれもハードウェア・ネットワーク・インフラストラクチャを変更する必要はありません。ただし、ソリューションの効率を向上させるのに役立つハードウェアを提供しているベンダーもあります。ただし、いずれのソリューションも相互に互換性がありません。

しかし、大規模なマルチテナントクラウドの時代において、すべてが失われてしまう訳ではありません。新しいネットワーク仮想化標準の GENEVE (Generic Network Virtualization Encapsulation) が登場しました。GENEVE は、以前の仕様で認識されていた制限に対処し、VXLAN、NVGRE、および STT のすべての機能をサポートすることを約束しています。多くの人は、最終的に GENEVE がこれらの以前のフォーマットを完全に置き換える可能性があると考えています。

GENEVE の規定された目標は、カプセル化データ形式のみを定義することです。以前の形式とは異なり、コントロールプレーンの情報や仕様は含まれていません。作成チームは次のように述べています

「データ形式を決めることには、明らかな利点があります。ほとんどのプロトコルは表面的な違いしかなく、重複する作業にはほとんど利点がありません。ただし、コントロールプレーンについては同じことが言えません。コントロールプレーンは根本的に多様です。要件、目標、デプロイシナリオは多種多様であるため、標準化の必要性もあまり明確ではありません。」

これらの目標を達成するために、GENEVE の作成者らは、データ形式は可能な限り柔軟かつ拡張可能であるべきであることに同意しました。現在の VXLAN と NVGRE の 24 ビットのトンネル識別子フィールドと STT の 64 ビットは、必要とされるすべての仮想ネットワークを指定するのに十分すぎるほどですが、将来の開発者はこのフィールドを細分化して、仮想ネットワーク識別子以外の情報を追加するのに使うと考えられています。このフィールドの潜在的な用途と、仮想化サーバー内またはシャーシスイッチのラインカード間で現在交換されているシステム状態情報とを比較します。彼らは、将来のあらゆる用途に十分に対応できる固定フィールドサイズを指定することはできないことに気づいています。さらに、GENEVE の作成者は、長寿命を実証している他の多くのプロトコルからヒントを得ています。BGP (Border Gateway Protocol)、LLDP (Link Layer Discovery Protocol)、IS-IS (Intermediate System - Intermediate System) などのプロトコルは、数十年前から存在し、今でも変わらず使用されています。

その理由は簡単です。拡張性があるからです。これらは、基本プロトコルを改訂するのではなく、新しいオプション機能を追加することによって、新しい機能とともに進化しています。

GENEVE のカプセル化パケットは、標準のネットワーク機器を介して送信されるように設計されています。パケットは、ユニキャストまたはマルチキャストのアドレス指定を使用して、1 つのトンネルエンドポイントから 1 つ以上のトンネルエンドポイントに送信されます。クライアントアプリケーションとそれが実行されているホストは一切変更されません。アプリケーションは、あたかもハードウェアのスイッチとルーターを介して通信しているかのように、同一の IP パケットを生成します。パケットに含まれる宛先 IP アドレスは、クラウドテナントの仮想ネットワーク内でのみ意味があります。トンネルエンドポイントはエンドユーザー IP パケットを GENEVE ヘッダーにカプセル化し、テナントの仮想ネットワークを指定するトンネル識別子とそれに続くオプションを追加します。ヘッダーは、それが GENEVE パケットであることを指定するフィールド、オプションがある場合はその全長、トンネル識別子、および一連のオプションで構成されます。完成したパケットは、IPv4 および IPv6 経由でサポートされている標準の UDP パケットで宛先エンドポイントに送信されます。受信側のトンネルエンドポイントはヘッダーを取り除き、含まれているオプションを解釈して、トンネル識別子で示される仮想ネットワーク内の宛先にエンドユーザーパケットを転送します。

Geneve_VxLAN Headers.jpg

 

GENEVE 仕様では、断片化を回避し、ECMP (等コストマルチパス) および NIC ハードウェアオフロード機能を活用することで、効率的な運用を実現する方法に関する推奨事項が提供されています。この仕様では、差別化サービスと明示的な輻輳通知をサポートする方法に関するオプションも提供しています。作成者は、GENEVE と他の 1 つ以上のカプセル化方法が同じシステムで使用されている場合に問題が発生することはないと考えています。GENEVE トンネルのエンドポイントは相互にのみ通信し、パケットはネットワークインフラストラクチャによって他の UDP パケットと同様に処理されます。このデータ形式は、VXLAN、NVGRE、および STT のすべての機能をサポートしているため、最終的には、それ以前の 3 つの形式の使用は減少する可能性があります。コントロールプレーンのプロトコルは指定されていないため、作成者は、他のカプセル化方法で使用されているプロトコルをサポートするものと想定しています。他のカプセル化方法と比較した場合の主な利点の 1 つは、GENEVE の柔軟なオプション形式と、IANA (Internet Assigned Numbers Authority) を使用してオプションクラスを指定できることです。開発者は、24 ビットに制限されることなく、任意の数のオプションを動的に含めることができます。また、64 ビットのフィールドの一部のサイズのみが必要な場合に 64 ビットフィールドのオーバーヘッドが発生することもありません。

GENEVE への移行はすぐには行われません。他のカプセル化方式もしばらく前から使用されており、同じシステム内で複数の方式を動作させることができます。しかし、GENEVE は OVN (Open Virtual Network) のデフォルトのトンネリングプロトコルとして採用され、今後の OpenStack リリースでは OVS (OpenvSwitch) の実装として推進されています。

大規模なマルチテナントクラウドでの使用は増え続けており、標準として受け入れられるカプセル化方式が 1 つだけになることはないでしょう。しかし、柔軟なオプション形式と他の方法のすべての機能をサポートする GENEVE は、幅広く採用される有力な候補となるでしょう。


Want to learn more about edge computing?

Edge computing is in use today across many industries, including telecommunications, manufacturing, transportation, and utilities. Visit our resources to see how Red Hat's bringing connectivity out to the edge.


Benjamin Schmaus (ベンジャミン・シュマウス) は、北米中部リージョンの Red Hat Cloud TAM です。1998 年から Linux に携わっており、小売、防衛、ソフトウェア、金融、高等教育、初等教育など、さまざまな業界のビジネス環境をサポートしてきました。直近では、Red Hat OpenStack Platform および Red Hat Ceph Storage のデプロイ、運用、サポートにおいてお客様を支援することに注力してきました。

Red Hat テクニカルアカウントマネージャー (TAM) は専門の製品エキスパートで、IT 組織と協力しながらデプロイを成功に導くよう戦略的な計画を練り、最適なパフォーマンスと成長の実現を支援します。TAM は Red Hat のワールドクラスのカスタマーエクスペリエンス & エンゲージメント組織の一部で、事前にアドバイスとガイダンスを提供して、潜在的な問題が発生する前に特定して対処できるよう支援します。問題が発生すると、TAM が問題に責任をもって対応し、最適なリソースを可能な限り速やかに解決に当たらせ、お客様のビジネスの中断を最小限に抑えます。


About the author

Benjamin Schmaus is a Red Hat Principle Product Manager for Edge Solutions. He has been involved with Linux since 1998 and has supported business environments in a variety of industries: retail, defense, software development, pharmacy, financial, higher education and K-12. His experience in those industries along with various positions within Red Hat have enabled him to have a broad and deep understanding of customer challenges. Most recently, he has been focused on enabling our customers at the edge by driving the Red Hat portfolio to deliver edge solutions that meet their ever diverse needs as they journey through modernization.

Read full bio