オーバーレイ ネットワーク。 Docker Network とは何ぞ?

SDN環境に必要なネットワーク

オーバーレイ ネットワーク

本記事は business network. jp に寄稿した「<コンテナNWの課題と展望>Kubernetes環境のネットワークの基礎を学ぶ」の内容を再編・要約したものです。 ではKubernetesのストレージ機能に関して説明しましたが、今回はKubernetesのネットワーク部分に焦点を当ててご説明します。 Dockerにおけるコンテナネットワーク Kubernetesのネットワークを説明する前に、Dockerにおけるコンテナのネットワークに関して整理します。 コンテナが起動するホストはコンテナホストと呼ばれ、コンテナホストの内部には論理的なネットワークが存在し、各コンテナはこの論理的なネットワークに接続されています。 コンテナホスト内部には論理的なブリッジ Linux Bridge が存在し、各コンテナは仮想的なネットワークインターフェース veth によりこのブリッジに接続され、Linux カーネルのNetwork Namespace機能により、それぞれが独自のネットワークインターフェースを持つことを実現しています。 コンテナ内で起動するプロセスから見ると、自分専用のネットワークインターフェースがあるように見えており、コンテナホストが持つネットワークインターフェースもこのブリッジに接続されています。 コンテナとして起動するサービスを外部に公開する場合は、コンテナホストの特定ポートに対するアクセスをコンテナに対してiptablesによりDNATすることで、コンテナに対するアクセスを実現しています。 Kubernetesにおけるコンテナネットワーク Pod間通信 Kubernetesではコンテナをクラスター環境で実行するため、コンテナ 以下Podと呼びます 間の通信が課題となります。 Dockerと同じように各Podには独立したIPアドレスが割り当てられますが、これはコンテナホストであるNode内でのみ有効なものであり、Pod同士がNodeを跨いで通信しようとすると、そのままのIPアドレスで通信することは困難です。 Dockerではこの課題を解決するためにNATを利用していますが、Pod作成の度にNATテーブルを操作するのは効率的ではありません。 そこで、多くのコンテナネットワークソリューションではオーバーレイネットワークを採用しています。 オーバーレイネットワークは送信されたパケットをカプセル化して宛先に届け、受信側でカプセル化を解いて宛先に届けます。 既存のSDNソリューションにはVXLANによるオーバーレイネットワークを利用するものが多くありますが、コンテナ環境でもVXLANが利用されます。 Podから送信されたパケットはNode内のブリッジを経由して、Linuxカーネルでカプセル化され、宛先Nodeに送信されます。 受信したNodeは受信したパケットのカプセル化を解いて宛先のPodにパケットを届けます。 このようなオーバーレイネットワークをNode間で構成することにより、複数Node環境におけるPod間通信を実現します。 やはオーバーレイネットワークを採用しています。 また、別の実装としてPodが持つIPアドレスをNodeネットワークに公開する方法もあります。 は、Podに割り当てられるIPアドレスをBGPによりNode外部に広報し、各Node上で機能するBGPの機能がPodに対する経路情報を学習します。 この手法であれば、基本的にNATは利用されないため、パフォーマンスインパクトを小さくすることができます。 また、Nodeが接続されたネットワーク機器もBGPを設定することで、Pod向けネットワークをルーティングテーブル上で確認することが可能です。 ServiceによるPodの負荷分散 クラウドネイティブなアプリケーション環境では、ロードバランサーが非常に重要な役割を果たします。 Kubernetes上ではPodに対する可用性やスケーラビリティ向上のためにロードバランサーを利用することができます。 クラウドネイティブ環境において、可用性やスケーラビリティの向上と同じく重要なのが、「Pod同士を疎結合に構成する」という点です。 具体的には、Podグループに対してロードバランサーで仮想サーバーを構成し、仮想サーバーに対する名前解決を設定します。 これにより、Podが別のPodにアクセスする際に、PodのIPアドレスを指定してアクセスするのではなく、アクセス先のPodサービス名でアクセスすることが可能になります。 この機能はKubernetes上で「Service」と呼ばれるリソースで実現します。 この実装により、Pod同士を疎結合に構成する事が可能になり、Podグループは簡単にスケールアウトすることができるようになります。 多くの実装ではこのService向けのロードバランサーはLinuxカーネルのiptablesが利用されます。 ServiceリソースにはいくつかのTypeが存在しますが、「Type: LoadBalancer」として設定することで、クラスター外部のロードバランサーを介してPodを外部向けに公開することもできます。 この機能はKubernetesクラスターの外部の機能との連携が必要になります。 例えば、パブリッククラウド上でKubernetesクラスターを構成している場合、クラウドサービスが提供するロードバランサーサービスが利用されます。 Kubernetesクラスター外部へのサービスの公開 KubernetesにIngress Controllerと呼ばれる機能を追加することで、L7ロードバランサーを使用してサービスを外部に公開する事も可能です。 Ingressはクラスター外部からのアクセスを前述のServiceに対してルーティングします。 L7ロードバランサー機能はバーチャルホストとパスベースのルーティングに対応しているため、パス毎に異なるサービスにルーティングすることができ、きめ細かい負荷分散機能を利用することが可能です。 Ingressによりサービスをクラスター外部に公開し、クラスター内のPod間通信をServiceによって制御することで、以下のようにマイクロサービスアーキテクチャを構成することが可能です。 ベンダーソリューションを活用したコンテナネットワークの運用管理 コンテナネットワークはオープンソースによる実装が数多くありますが、ネットワーク機器ベンダーやインフラベンダーもコンテナネットワーク向けソリューションを提供しています。 KubernetesのコンテナネットワークはCNI Container Networking Interface と呼ばれる仕様に対応しており、ベンダーがCNI向けプラグインを提供していれば、こうしたベンダーのソリューションをKubernetesのネットワーク機能として利用することが可能です。 例えば、Cisco社はCisco ACIのCNIプラグインを提供しており、Kubernetes環境のネットワークとしてCisco ACIを利用することができます。 KubernetesにはPod間の通信制御を行うNetwork Policyと呼ばれる機能がありますが、ACIを利用することでACIのEndpoint GroupやContractを利用してNetwork Policyを実現します。 また、ACIにロードバランサーを連携させることで、L4ロードバランサーやIngress機能もAPIC経由で管理することができます。 ACIとKubernetesの連携に関してはで詳細をご紹介しています。 また、VMware社もNSX-T Data Center用のCNIプラグインを提供しています。 また、Nodeが起動するハイパーバイザー内にインストールされたNSXモジュールが持つ分散ファイアウォール機能によりKubernetesのNetwork Policyを利用してPod間の通信制御を行うことも可能です。 これらの商用SDNソリューションを利用することにより、インフラ管理者は従来のネットワークとコンテナネットワークを統合管理することが可能になます。 各社ともネットワークソリューション向けの運用管理ツールを提供しており、これらを利用することにより従来のネットワークの運用管理手法を使って、コンテナネットワークを可視化、運用することができます。 まとめ コンテナネットワークはサーバー内部で機能するため、従来のサーバー管理者・ネットワーク管理者の責任分界点はより曖昧になります。 しかし、テクノロジーとしては従来から存在するSDNを活用しているため、ベンダー各社が提供する商用SDNソリューションを利用することで、従来のネットワークと管理を統合し、可視化を実現することが可能になります。

次の

VXLANの仕組みを調べてみよう!

オーバーレイ ネットワーク

VMware NSXによるオーバーレイネットワーク(VXLAN) 今回は、Software Defined Network(SDN)環境を支えるアンダーレイ、物理ネットワークのソリューション Juniper QFX5100 シリーズ連携についてご紹介します。 まず、本題に入る前に、オーバーレイネットワーク(VXLAN)について、簡単にご説明します。 従来は、ネットワークの変更の際には、ネットワーク機器1台1台に対して設定が必要でした。 ネットワーク管理者の負担は大きく、柔軟な運用の妨げになっていました。 ネットワークをNSXで仮想化すると、ネットワークの変更などは論理的に行うことができるので、ネットワーク機器への設定変更は不要となり、管理者の負担は劇的に下がります。 また、物理的なネットワーク機器はパケットを通過させる役割だけを担います。 この論理的なネットワークをオーバーレイネットワーク、物理的なネットワークをアンダーレイネットワークといいます。 技術的には、仮想マシンからのレイヤー2(L2)通信がアンダーレイを通る際、送信元のハイパーバイザーでそのパケットをVXLANでカプセル化します。 カプセル化された通信はレイヤー3(L3)のネットワークで転送され、宛先のハイパーバイザーで脱カプセル化を行うことで、異なる物理サーバー間に広がったオーバーレイネットワークを構築します。 (下図参照) オーバーレイネットワークの仕組み 物理ネットワークを選ぶ際の 検討ポイント例• 高パフォーマンス• 高帯域• 低遅延• 耐障害性• 拡張性• ジャンボフレームの転送• 管理容易性 また、仮想化されていない物理サーバー等をオーバーレイネットワーク VXLAN に接続する際にも、物理スイッチをうまく活用することで大きなメリットが出ます。 NSXではソフトウェアVTEP(VXLAN Tunnel Endpoint)機能を利用して、オーバーレイネットワークと物理ワークロードを接続することができます。 NSXだけでも仮想化されていない物理サーバーとの接続は可能ですが、 より広い帯域・パフォーマンスでの接続、より高い拡張性、より高速なHA機能などが必要な場合には、物理スイッチによるハードウェアVTEPとの連携ソリューションが必要になります。 Juniper NetworksのハードウェアVTEPソリューション ハードウェアVTEP連携ソリューション概要 まずは、QFXによるハードウェアVTEP連携ソリューションについてご説明します。 この連携によって、旧来のネットワークアプライアンスやデータベース、ストレージなどベアメタルなデバイス、またはNSXを導入していない旧来の仮想サーバーなどを、NSX環境の仮想マシンに高速接続することが可能です。 また、QFXは、複数の筐体を1つの仮想シャーシスイッチとすることができるイーサネットファブリック技術、Virtual Chassis Fabric VCF を構成することが可能で、このVCFを構成した状態でNSXと連携させることが可能です。 物理スイッチによるカプセル処理.

次の

SD

オーバーレイ ネットワーク

オーバーレイ技術の歴史を振り返ると、その技術の進化の方向性としては、私は3つほどあるのではないかと思っています。 一つはカプセル化技術の進化です。 古くはGREから、そしてその後もさまざまなカプセル化技術(IP in IP、MPLS、L2TP、VXLANなど)が生まれてきました。 オーバーレイの二つ目の進化の軸はシグナリングです。 こちらも過去さまざまな方式が生まれましたが、歴史的に振り返ってみると、勝者はBGP(あるいはその拡張)ということになるのではないかと思います。 3つ目の進化の軸はスケーラビリティです。 今回はここに注目してみたいと思います。 なぜフルメッシュが困難なのか? 一般的に大規模なフルメッシュのオーバーレイネットワークを構築するのは大変困難です。 大きく分けると2つ理由あります。 一つは設定(プロビジョニング)の困難さです。 初期設定時に多くの工数がかかるものもちろんですが、むしろ大変なのはサイトを追加する時です。 フルメッシュを維持するためには、対向の全てのノードにも再設定をしなければいけません。 初期構築時は仮に頑張れても、運用に入った後に全てのノードの再設定をしなければいけないのは大きな苦痛を伴います。 もう一つの困難さはステート維持です。 IPsecの鍵もこのようなステートの一種です。 IPsecのフルメッシュネットワークが難しいのは上記の二つの理由に依るところが大きいと言えます。 この方式のポイントは「オーバー・プロビジョニング」をする、という点にあります。 この方式では、例えばFrame RelayのネットワークであればDLCIをあらかじめ余計に割り当てておき、サイトが追加になった際にローカルの設定変更だけで残りのリモートサイトには変更が必要ないように工夫されています。 また、CoSine CommunicationsのIPSXは仮想ルータをIPsecで結んでオーバレイネットワーク VPN を作ることができました。 CoSineのInVisonというNMSには自由にハブ&スポークやフルメッシュのIPsecを構成する機能がありましたので、ある意味プロビジョニング上の問題は解決することができていたとも言えます。 2000年当時、1仮想ルータで1000のIPsecトンネルを終端することができた(ハブ&スポーク)を構成することができた)のはかなり頑張っていたのではないかと思いますが、では1000個の仮想ルータでフルメッシュのIPsecトンネルを作れたかというと、それは全くもって不可能な話でした。 Diffie Hellmanの鍵交換はAES-CBC-256bitに比べると二桁ほど重い処理であることがわかります。 このようにDiffie Hellmanの鍵交換処理は非常に重たい処理なのです。 鍵がpair-wiseであるというのは、相手が異なれば異なる鍵を使う、すなわちペアごとに異なる鍵が存在するということです。 暗号鍵があるということは、必ず鍵の更新(Rekey)をしなければいけないということを意味します。 どんな暗号化システムでも、同じ鍵を使い続けていけば暗号強度は必ず低下してくるからです。 例えば1,000ノードのフルメッシュを構成するとおよそ500,000のペアが存在することになります。 仮にIKEのPhase 1のRekey時間を24時間としましょう。 24時間はたった86,400秒しかありません。 この間に500,000回の鍵交換をしなければいけないわけですから、毎秒5〜6回のペースで鍵交換をし続けなければいけないことになります。 3,000ノードのフルメッシュなら毎秒50回以上になります。 このように非常に重たい処理のIKEですが、IPsecにとって本当に必須のものなのでしょうか? 実際、多くの場合IPsecを使う際にはIKEが使われます。 しかし、IPsecにとってIKEが唯一無二の鍵交換プロトコルというわけではありません。 実は、IPsecにはKINKやPhoturisといった別の鍵交換プロトコルもあります。 極端な話、手動で鍵を設定することもできるわけです(もちろん鍵の更新をしなければセキュアとは言い難いですが・・)。 つまりIPsecにとってIKEは必須ではないのです。 IKEはセキュアなチャネルがないところにセキュアなチャネルを開設するプロトコルです。 従ってすでにセキュアなチャネルがあれば、必ずしもIKEを使う必要はないという点に注意してください。 「Viptelaのアーキテクチャー」の回で、コントローラとvEdgeの間のコントロールチャネルはTLSもしくはDTLSが使われているというご説明をしました。 すでにそこにセキュアなチャネルがあるわけですから、それを使えば良いのです! Viptelaによるスケーラブルなオーバーレイネットワーク vEdgeは自分宛に送るパケットの暗号化に使う鍵を自らランダムに生成し、それをvSmartに送ります。 すると、vSmartは他のすべてのvEdgeにその鍵を配布してくれます。 これだけで鍵を更新することができるわけです。 各vEdgeがやらなければいけないのはランダムな鍵を自ら生成するだけです。 これは非常に軽い処理ですので、例えば極端に短い時間(例えば30秒)で鍵更新をするということも可能です。 Viptelaのアーキテクチャでは鍵の更新は経路のアップデートとほぼ同程度の処理です。 BGPの環境で30秒に一度程度の経路アップデートをさばくのはさほど大変なことではないのはみなさん肌でご理解いただいていると思います。 ViptelaのIPecの鍵更新は経路の更新と本質的に同じ処理ですので、BGPと同様のスケーラビリティをIPsecについても実現できる、と考えていただければいいかと思います。 また、鍵はvEdge毎に1つしかないことも注目すべき点です。 今日の多くのSD-WANソリューションは、IPsecによるオーバーレイネットワークを使ったものが多いです。 SD-WANソリューションには通常何かしらのコントローラがありますので、プロビジョニングに関する問題は多くの場合解決されていると考えて良いと思います。 しかし、維持しなければいけないステートの問題、特にIPsecの鍵交換のスケーラビリティに関して未解決のものが多いです。

次の