完全分散エッジ処理で実現するNeutron仮想ネットワーク

オープンクラウド・キャンパス完全分散エッジ処理で実現する Neutron仮想ネットワーク中井悦司 Twitter @enakai00

完全分散エッジ処理で実現するNeutron仮想ネットワークこの資料について  Midokura社が提供する商用のNeutron Plugin仮想ネットワーク製品「MidoNet」のアーキテクチャー、および、内部構造について解説しています。  MidoNetはソフトウェアによる分散アーキテクチャーで仮想ネットワークを実現する、「完全分散エッジ処理」を採用しており、その実装技術は、Neutron/SDN 全般に興味を持つ方の参考になります。  私はMidokura社のまわし者ではありません。本資料の内容は、MidoNetのユーザーとして知り得た技術情報をMidokura社の協力の下に公開しています。 2 Open Cloud Campus

OpenStackとNeutronの基礎

完全分散エッジ処理で実現するNeutron仮想ネットワーク OpenStackが提供するコンピューティングリソース  OpenStackのユーザは、Webコンソール/APIを利用して、次のようなコンピューティングリソースを利用します。 – 仮想ネットワーク – 仮想マシンインスタンス – ブロックボリュームプロジェクト環境仮想ルータ仮想スイッチ外部ネットワーク OpenStackユーザ OS領域仮想マシンインスタンスデータ領域ブロックボリューム  各ユーザは特定の「プロジェクト」に所属します。 – プロジェクト内でリソースを共有 – プロジェクト全体でのリソース使用量の上限設定、リソース使用状況のレポーティングなどが可能 4 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OpenStackのアーキテクチャー  各モジュールは、REST APIによりクライアントからの指示を受け付けます。 – プログラムコードからの呼び出しによる環境操作の自動化  外部のSDN製品やストレージ装置とドライバー/プライグインで連携する仕組みを持ちます。 – 外部製品とのインテグレーションによりさまざまな要件に対応テンプレートイメージ保存仮想マシンイメージ Nova Compute Nova Compute 仮想ネットワーク作成 Glance Horizon Neutron 管理ネットワーク LUN 仮想マシン起動ブロックボリューム提供 5 認証サーバ Open Cloud Campus MySQL Network Node Nova Compute Cinder Keystone Swift メッセージキューパブリックネットワーククライアントPC Webコンソールアクセステンプレートイメージ検索テンプレートダウンロード QPID/ RabbitMQ データベース LUN LUN Nova 外部のSDN製品が構成する仮想ネットワークと連携外部のストレージ装置と連携

完全分散エッジ処理で実現するNeutron仮想ネットワーク Neutronによる仮想ネットワークの典型例  プロジェクトごとに仮想ルータを用意して、その背後にプライベートなネットワーク環境を構成します。 – ブロードバンドルータで家庭内LANをインターネットに接続するような感覚です。  仮想スイッチを作成して、ルータに接続します。 – それぞれの仮想スイッチは、プライベートIPの独立したサブネットを持ちます。  仮想マシンインスタンス起動時は、接続する仮想スイッチを選択します。 – DHCPでプライベートIPアドレスが割り当てられます。 – 同じプロジェクトの仮想マシンインスタンス間は、プライベートIPで通信できます。プロジェクトA 専用ルータ仮想スイッチ 192.168.101.0/24 外部ネットワークプロジェクトB 専用ルータ仮想スイッチ 192.168.102.0/24 6 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワークフローティングIPの利用  外部ネットワークと通信する際は、仮想マシンインスタンスに「フローティングIP」を割り当てます。 – 外部ネットワークのサブネット上で、フローティングIPとして利用可能なIPアドレスをプールしておきます。 – 仮想ルータ上で、フローティングIPとプライベートIPのNATが行われます。 – フローティングIPを割り当てない場合でも、仮想マシンインスタンスから外部ネットワークへの接続は可能です。（仮想ルータのIPアドレスを代表IPとして、マスカレード接続します。）外部ネットワークからはフローティングIPで接続フローティングIP インスタンス同士はプライベートIPで接続プライベートIP プライベートIP WebサーバーDBサーバー 7 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVS Plugin実装方式の特徴  Neutron標準のプラグイン – オープンソース！  仮想スイッチ／仮想ルーター／ファイアーウォールなど、それぞれの仮想ネットワークコンポーネントを既存技術の組み合わせで個別に実装します。 – 仮想スイッチ : Open vSwitch + VLAN / GRE Tunnel – 仮想ルーター : Linuxのパケットフォワーディング/NAT機能 – ファイアーウォール : Linuxのiptables – DHCP : Linuxのdnsmasq  仮想ネットワークトポロジーがそのままの形で実装されるので、仮想ネットワークが複雑になると問題判別が難しくなります。（仮想ネットワーク上のパケットの流れをそのまま追いかけていく必要があります。）  現在の実装では、仮想ルーターは、単一のネットワークノードに集約されるため、ネットワークノードがSPOF/ボトルネックになります。（仮想ルーターの分散実装は、Junoで実現される予定です。） 8 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVS Pluginによる典型的なノード構成  仮想ルーターがネットワークノードに集約されるので、仮想ルーターを経由する通信は、すべてネットワークノードを経由します。パブリックネットワークプライベートネットワーク・・・ eth0 eth1 eth2 eth0 eth1 IP IP IP br-priv br-int VM br-ex br-priv NAT br-int ネットワークノード eth0 eth1 br-priv br-int VM コンピュートノード eth0 IP コントローラノード Open vSwitch 仮想ルーター 9 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVS Pluginによる仮想ネットワークの実装例 (1)  Open vSwitchプラグインを用いて、下図の仮想ネットワークを作成した際の具体的な実装をコンピュートノード、ネットワークノードのそれぞれで示します。プロジェクトB 仮想ルータ – 2つのプロジェクトがそれぞれの仮想ルータを持っています。プロジェクトA 仮想ルータ外部ネットワーク仮想スイッチ projectA 仮想スイッチ projectB vm01 vm02 vm03 vm04 10 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVS Pluginによる仮想ネットワークの実装例 (2)  仮想スイッチごとに内部VLAN / 外部VLANを割り当てることでパケットを分離します。 vm02 eth0 IP qvoYYY ポートVLAN tag:1 int-br-priv phy-br-priv br-priv vm01 eth0 br-int eth1 IP qvoXXX Nova Computeが構成 vm04 eth0 IP vm03 eth0 qvoZZZ qvoWWW ポートVLAN tag:2 仮想スイッチごとに異なる「内部VLAN」を割り当てる L2 Agentが構成 VLAN101 VLAN102 内部VLANと外部VLANを相互変換・内部VLAN1⇔外部VLAN101 ・内部VLAN2⇔外部VLAN102 Open vSwitch IP 11 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVS Pluginによる仮想ネットワークの実装例 (3) dnsmasq パブリックネットワークへ eth1 br-ex IP qg-VVV iptablesで NAT&フィルタリング br-int L3 Agentが構成 qg-CCC qr-BBB IP int-br-priv ポートVLAN tag:2 phy-br-priv br-priv eth2 IP IP IP tapXXX qr-YYY ポートVLAN tag:1 dnsmasq tapAAA IP L2 Agentが構成  複数の仮想ルータに対応して iptablesによるパケット転送のパスが複数用意されます。 DHCP Agentが構成内部VLANと外部VLANを相互変換・内部VLAN1⇔外部VLAN101 ・内部VLAN2⇔外部VLAN102 プライベートネットワーク用スイッチへ 12 Open Cloud Campus

エッジ処理方式の例 OpenFlowを利用した実装アイデア

完全分散エッジ処理で実現するNeutron仮想ネットワーク OpenFlowの仕組み  OpenFlowスイッチは、ローカルのフローテーブルを参照して、個々のパケットの処理方法を判断します。 – フローテーブルは、パケットのマッチング条件と対応するアクションの一覧表です。  フローテーブルにマッチしないパケットが来た際は、OpenFlowコントローラーに処理方法を問い合わせて、結果をフローテーブルに追加します。 – コントローラーのロジックはソフトウェアで実装されているので、（理論上は）どれだけ複雑な処理でも実施することが可能です。 OpenFlowコントローラ受信パケットの処理方法をコントローラに問い合わせフローテーブルフローテーブルフローテーブル問い合わせ結果をフローテーブルに記録 14 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OpenFlowによる仮想ネットワークエミュレーション  OpenFlowコントローラに仮想ネットワークの構成情報を持たせておき、仮想マシンから送信されたパケットの行き先をコントローラで計算して、パケットの到達先を決定します。 – 仮想マシンからパケットを受け取ったOpen vSwitchは、コントローラの計算結果に基づいて、パケットの内容を変更した後に、最終到達先のOpen vSwitchにパケットを転送します。 – 物理的なパケット転送はワンホップで済むので、問題判別はシンプルになります。（コントローラーの計算にミスがない限り、ワンホップのパケット転送を追いかけるだけ。）  ただし、単純に実装するとコントローラーの計算量が膨大になり、スケーラビリティに問題が発生します。（コンピュートノードが増えると計算量はリニアに増加） VM VM Open vSwitch VM VM Open vSwitch 外部ネットワーク普通のローカルネットワーク網仮想ネットワークの論理構成 OpenFlow コントローラーパケットの処理方法を指示 15 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク MidoNetの完全分散アーキテクチャーによるアプローチ  MidoNetは、パケット転送先の計算をコンピュートノード上のエージェントが行うことで、コントローラーがボトルネックになることを回避します。 – 各エージェントは、自分が稼働するコンピュートノードだけを担当します。 OpenFlowによる実装MidoNetの実装 VM VM Open vSwitch 構成データベース OpenFlowコントローラー OpenFlowプロトコル VM VM Open vSwitch VM VM MidoNet Agent Kernel flowtable データ参照 VM VM MidoNet Agent Kernel flowtable 16 Open Cloud Campus

MidoNetの特徴と実装方式

完全分散エッジ処理で実現するNeutron仮想ネットワーク MidoNetの特徴  商用のNeutronプラグイン – オープンソースではありません・・・。残念。  仮想ネットワーク全体を独自の構造でデータ化して、構成データベースに保存します。 – 仮想ネットワーク内部のパケットの動きをMidoNetエージェントが計算して、最終的なパケットの転送先を決定します。  物理的なパケット転送は、すべてワンホップで行います。 – 実際の転送処理は、カーネル内部のフローテーブルを直接に使用します。（Open vSwitch / OpenFlowは使用していません。） – 1つの通信セッションに伴うパケットは、同じフローテーブルでまとめて処理するので、エージェントによる計算が発生するのは、最初のパケット転送時のみです。 – 物理サーバー間のパケット転送は、GRE、もしくは、VXLANでカプセリングします。  仮想スイッチ、仮想ルーター、セキュリティグループ、LBaaSなど、Neutronが提供する仮想ネットワークコンポーネントをすべて提供します。 – エンドユーザーは、NeutronのAPIから操作するので、MidoNetの存在を意識する事はありません。 18 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク「カーネル内部のフローテーブル」とは？  Open vSwitchは、OpenFlow機能を提供するLinux上の仮想ネットワークスイッチです。 – OpenFlow機能を効率的に実現するために、パケット転送に使用するフローテーブルは、カーネルモジュールとして実装されています。 – OpenFlowコントローラーとの通信やフローテーブルの書き換えは、ユーザーランドのモジュールが行います。  MidoNetでは、MidoNetエージェントが、パケットの転送先に合わせて、直接にカーネル内部のフローテーブルを書き換えます。 – Linuxカーネルは、フローテーブルを見てパケット転送を行うので、実際の転送処理は、カーネル内部で完結します。 OpenFlow コントローラ OpenFlowプロトコルフローテーブルユーザーランドモジュールフローテーブル Linuxカーネルこの組み合わせが OVSの実体 MidoNetエージェントがフローテーブルを直接変更 MidoNet エージェントフローテーブル Linuxカーネルカーネルモージュルは OVSから借用 19 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク GREトンネルについて  GREトンネルは、物理ネットワーク上にパケットを送出する際に、「GREヘッダー」でパケットをカプセル化する仕組みです。 – 「トンネル」と言っていますが、VPNのように固定的なトンネルのセッションが張られているわけではありません。 – GREヘッダー付きのパケットを受け取るように設定されたサーバーに対しては、いつでも自由に GREパケットを送信することができます。 From 172.16.1.1 To 172.16.1.2 VM From 192.168.1.10 To 192.168.1.11 送信データ 172.16.1.1 172.16.1.2 From 192.168.1.10 To 192.168.1.11 送信データ 192.168.1.10 VM 192.168.1.11 20 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク OVSプラグインでのGREトンネルの取り扱い  Neutron標準のOVSプラグインでGREトンネルを使用する際は、すべてのサーバー間でフルメッシュになるように、GREパケット送受信用仮想ポートが用意されます。 – これは、OVSカーネルモジュールの「Port base tunneling」と呼ばれる機能です。 # ovs-vsctl show 911ff1ca-590a-4efd-a066-568fbac8c6fb [... Bridge br-int omitted ...] Bridge br-tun Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal Port "gre-2" Interface "gre-2" br-tun gre-1 gre-2 gre-1 gre-2 gre-1 gre-2 type: gre options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.101"} Port "gre-1" Interface "gre-1" type: gre options: {in_key=flow, local_ip="192.168.1.100", out_key=flow, remote_ip="192.168.1.102"} br-tun br-tun ピア情報の事前設定が必要 21 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク MidoNetでのGREトンネルの取り扱い (1)  MidoNetでは、OVSカーネルモジュールの「Flow base tunneling」機能を利用しており、ピアを特定しない汎用のトンネルポートから、GREパケットを送信します。 – フローテーブルのアクションで、GREパケット送信先のアドレスを指定して送信します。 tapXX tapYY VM VM midonet tapXX tapYY midonet tngre-overlay tngre-overlay tapXX tapYY # mm-dpctl --show-dp midonet Datapath name : midonet Datapath index : 10 midonet Datapath Stats: Flows :0 Hits :0 tngre-overlay Lost :0 Misses:0 Port #0 "midonet" Internal Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0} Port #1 "tngre-overlay" Gre Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0} Port #2 "tnvxlan-overlay" VXLan Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0} Port #3 "tnvxlan-vtep" VXLan Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0} Port #4 "tap81362f30-43" NetDev Stats{rxPackets=0, txPackets=0, rxBytes=0, txBytes=0, rxErrors=0, txErrors=0, rxDropped=0, txDropped=0} 22 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク MidoNetでのGREトンネルの取り扱い (2)  次は、GREトンネルを経由してパケットを送受信するフローテーブルの例です。 – 送信先サーバーの他に、「トンネルID（tun_id）」を指定することで、受信側でのパケットの処理を条件分岐することが可能です。 – MidoNetでは、最終到達先のVMに直接にパケットを転送するために、VM接続ポートとトンネルID を一対一で紐づけています。 Flow: match keys: 送信側のテーブル FlowKeyInPort{portNo=4} FlowKeyEthernet{eth_src=fa:16:3e:b6:2e:ec, eth_dst=fa:16:3e:8d:72:ce} FlowKeyEtherType{etherType=0x800} FlowKeyIPv4{ipv4_src=192.168.1.4, ipv4_dst=192.168.1.6, ipv4_proto=6, ipv4_tos=16, ipv4_ttl=64, ipv4_frag=0} FlowKeyTCP{tcp_src=49580, tcp_dst=22} actions: FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=13, ipv4_src=192.168.40.7, ipv4_dst=192.168.40.8, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1}} FlowActionOutput{portNumber=1} stats: FlowStats{n_packets=2, n_bytes=276} tcpFlags: PSH | ACK Flow: match keys: トンネルID=13と送信先サーバー192.168.40.8を指定 GREトンネルポートからパケットを送出トンネルID=13で受信したパケットにマッチ受信側のテーブル FlowKeyTunnel{tun_id=13, ipv4_src=192.168.40.7, ipv4_dst=192.168.40.8, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1} FlowKeyInPort{portNo=1} FlowKeyEthernet{eth_src=fa:16:3e:b6:2e:ec, eth_dst=fa:16:3e:8d:72:ce} FlowKeyEtherType{etherType=0x800} FlowKeyIPv4{ipv4_src=192.168.1.4, ipv4_dst=192.168.1.6, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=64, ipv4_frag=0} FlowKeyTCP{tcp_src=49580, tcp_dst=22} actions: FlowActionOutput{portNumber=4} 受け取り先のVMが接続したポートに転送 23 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワークパケット転送処理の例 (1)  VM1からVM2にSSH接続する例で、具体的に考えます。 – ここでは、VM1でのARP解決は終わっているものとします。ARP解決については後述します。  Node#1での処理 – VM1からVM２宛のSSHパケットが、Node#1の仮想スイッチ「midonet」に入ります。 – フローテーブルには、このパケットにマッチするエントリーが無いので、Node#1のMidoNetエージェントに問い合わせが行きます。 – MidoNetエージェントは、仮想ネットワークトポロジーを参照して、最終到達先のポート（VM2が接続したポート）を特定します。その後、ポートに対応したトンネルIDを付与して、Node#2にトンネル経由でパケットを転送するエントリーをフローテーブルに作成します。  Node#2での処理 – Node#1から受信したパケットは、フローテーブルにマッチするエントリーが無いので、Node#2の MidoNetエージェントに問い合わせが行きます。 – MidoNetエージェントは、トンネルIDから対応するポートを判別して、このパケットを該当ポートに転送するエントリーをフローテーブルに作成します。 VM1 Node#1 tapYY Node#2 tapXX tapYY midonet tngre-overlay tapXX VM2 midonet tngre-overlay 24 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワークパケット転送処理の例 (2)  その後、SSH接続として続くパケットは、先に作られたフローテーブルのエントリーで処理されるので、MidoNetエージェントによる計算は発生しません。カーネル内部で転送処理が完結します。 – 裏を返すと、一発目のパケットだけは、転送に時間がかかります。  VM1がVM2にSSH接続する場合、実際には、最初にVM1からARPパケットが送信されます。 MidoNetエージェントは、ARPパケットについては、仮想L2レイヤーのすべてのポートに転送します。 – IPアドレスとMACアドレスの対応は、構成データベースに記録されているので、MidoNetが代理で返答することも可能ですが、そのような実装はしていません。（それをやると、VM上のアプリケーションがARPパケットのブロードキャストを利用した処理をする場合に、うまく動かない恐れがあります。）  MidoNetでは、異なるテナント間でのパケット転送についても、すべてワンホップで直接に転送します。 – 途中の仮想ルーターでNATが入る場合は、NAT変換を行った状態のパケットを送信します。具体例は後で紹介します。 25 Open Cloud Campus

外部ネットワークとの接続方法

完全分散エッジ処理で実現するNeutron仮想ネットワーク外部ネットワークとの接続方法 (1)  外部ネットワークとの接続は、ゲートウェイノードを経由して行います。 – 複数のゲートウェイノードが論理的に1つのBGPルーターとして振る舞います。・・・BGPルーター Neutronの定義上での「外部ネットワーク」 Neutronで定義した仮想ネットワーク MidoNet Agent VM VM MidoNet Agent MidoNet Agent 物理的な意味での外部ネットワーク物理構成図 VM VM MidoNet Agent 論理構成図 27 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク外部ネットワークとの接続方法 (2)  外部ネットワーク上のIPアドレスに向けたパケットは、コンピュートノードのMidoNetエージェントが、ゲートウェイノードに転送した後、ゲートウェイノードのMidoNetエージェントが、外部ネットワークに送出します。 MidoNet Agent VM VM MidoNet Agent MidoNet Agent ・・・物理構成図 VM VM MidoNet Agent  パケットの送出については、複数のゲートウェイノードで、パケット単位の負荷分散を行います。 – コンピュートノードのエージェントが転送先のゲートウェイノードをパケット単位で振り分けます。  外部ネットワークからの受信については、外部ルーター（BGPルーター）の設定で負荷分散するようにしておきます。  ゲートウェイノードが停止（リンクダウン）した際は、自動的に該当ノードの使用を停止します。 – コンピュートノードのエージェントは該当ノードへの転送を停止します。 – 外部ルーターの方でもリンクダウンした経路には転送しないように設定しておきます。 28 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク NATを伴う通信処理の例 (1)  コンピュートノード上のVMから、テナントルーター（仮想ルーター）を経由して外部ネットワークと通信する際は、仮想ルーター上でNAT処理が行われます。このような通信を MidoNetエージェントは、次のように処理します。 – 例として、プライベートIP「192.168.3.5」とフローティングIP「72.16.128.3」を持ったVMからグローバルIP「108.171.178.131」に接続します。外部ネットワーク vm 論理構成図プロジェクト用仮想ルータ仮想スイッチ vm 論理的には、ここでプライベートIPとフローティングIPを変換 29 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク NATを伴う通信処理の例 (2)  送信パケットの処理 – コンピュートノードでは、送信元IPを変換した後に、ゲートウェイノードに転送します。 Flow: match keys: FlowKeyInPort{portNo=4} FlowKeyEthernet{eth_src=fa:16:3e:11:7c:2c, eth_dst=02:65:b4:09:aa:6a} FlowKeyEtherType{etherType=0x800} FlowKeyIPv4{ipv4_src=192.168.3.5, ipv4_dst=108.171.178.131, ipv4_proto=6, ipv4_tos=16, ipv4_ttl=64, ipv4_frag=0} FlowKeyTCP{tcp_src=43771, tcp_dst=22} actions: FlowActionSetKey{flowKey=FlowKeyEthernet{eth_src=fa:16:3e:9a:76:2c, eth_dst=fa:16:3e:fa:78:6a}} FlowActionSetKey{flowKey=FlowKeyIPv4{ipv4_src=172.16.128.3, ipv4_dst=108.171.178.131, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=62, ipv4_frag=0}} 送信元IPをフローティングIPに変換 FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=16, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.10, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1}} FlowActionOutput{portNumber=1} – ゲートウェイノードでは、受け取ったパケットをそのまま外部ルータ接続ポートに送信します。 Flow: match keys: トンネルIDでパケットを同定 FlowKeyTunnel{tun_id=16, ipv4_src=192.168.30.7, ipv4_dst=192.168.30.10, tun_flag=0, ipv4_tos=0, ipv4_ttl=-1} FlowKeyInPort{portNo=1} FlowKeyEthernet{eth_src=fa:16:3e:9a:76:2c, eth_dst=fa:16:3e:fa:78:6a} FlowKeyEtherType{etherType=0x800} FlowKeyIPv4{ipv4_src=172.16.128.3, ipv4_dst=108.171.178.131, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=62, ipv4_frag=0} FlowKeyTCP{tcp_src=43771, tcp_dst=22} actions: FlowActionOutput{portNumber=4} 外部ルータ接続ポートに送信 30 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク NATを伴う通信処理の例 (3)  受信パケットの処理 – ゲートウェイノードでは、宛先IPを変換した後に、コンピュートノードに転送します。 Flow: match keys: FlowKeyInPort{portNo=4} FlowKeyEthernet{eth_src=fa:16:3e:ec:e7:da, eth_dst=fa:16:3e:2e:54:a1} FlowKeyEtherType{etherType=0x800} FlowKeyIPv4{ipv4_src=108.171.178.131, ipv4_dst=172.16.128.3, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=64, ipv4_frag=0} FlowKeyTCP{tcp_src=22, tcp_dst=43771} actions: FlowActionSetKey{flowKey=FlowKeyEthernet{eth_src=02:65:b4:09:aa:6a, eth_dst=fa:16:3e:11:7c:2c}} FlowActionSetKey{flowKey=FlowKeyIPv4{ipv4_src=108.171.178.131, ipv4_dst=192.168.3.5, ipv4_proto=6, ipv4_tos=0, ipv4_ttl=6 2, ipv4_frag=0}} 送信元IPをプライベートIPに変換 FlowActionSetKey{flowKey=FlowKeyTunnel{tun_id=5, ipv4_src=192.168.30.11, ipv4_dst=192.168.30.7, tun_flag=0, ipv4_ tos=0, ipv4_ttl=-1}} FlowActionOutput{portNumber=1} stats: FlowStats{n_packets=5, n_bytes=1875} tcpFlags: PSH | ACK lastUsedTime: 290859609 – コンピュートノードでは、受け取ったパケットをそのままVM接続ポートに送信します。（フローテーブルは省略） 31 Open Cloud Campus

完全分散エッジ処理で実現するNeutron仮想ネットワーク NATを伴う通信処理の例 (4)  このようなアドレス変換のタイミングの違いは、コンピュートノードとゲートウェイノードの間のGREパケットをtcpdumpで観察すると分かります。送信パケットは、ゲートウェイノードに行く段階で、送信元IPがフローティングIPになっている 02:19:14.257684 IP 192.168.30.7 > 192.168.30.11: GREv0, key=0x12, length 82: IP 172.16.128.3.43771 > 108.171.178.131.ssh: Flags [S], seq 2970049644, win 14600, options [mss 1460,sackOK,TS val 72390453 ecr 0,nop,wscale 2], length 0 02:19:14.281226 IP 192.168.30.11 > 192.168.30.7: GREv0, key=0x5, length 82: IP 108.171.178.131.ssh > 192.168.3.5.43771: Flags [S.], seq 3583501603, ack 2970049645, win 14020, options [mss 1414,sackOK,TS val 28875923 ecr 72390453,nop,wscale 7], length 0 受信パケットは、コンピュートノードに行く段階で、宛先IPがプライベートIPになっている  この例から、NATテーブルのような動的なステータス情報が、MidoNetエージェント間で共有されていることが分かります。 32 Open Cloud Campus

バックエンドデータベースについて

完全分散エッジ処理で実現するNeutron仮想ネットワーク MidoNetのバックエンドデータベース  MidoNetでは、バックエンドデータベースとして、ZooKeeperとCassandraを使用します。 – ZooKeeper : 仮想ネットワーク構成など静的な情報を保存 – Cassandra : NAT変換テーブルなど動的な情報を保存  MidoNetエージェントは、必要に応じてこれらのデータベースへのアクセスを行います。 – エージェント間で直接にメッセージをやりとりすることはありません。  ZooKeeperは、分散処理マネージャーの機能を持っており、エージェント間での分散ロック機能の提供や、構成変更に伴うエージェントへの通知処理なども行います。 – エンドユーザーがNeutron APIで仮想ネットワークを変更すると、Neutronデータベースの更新に合わせて、ZooKeeper上の構成情報が更新されます。 – この時、仮想ネットワークの変更に影響を受けるノード上のエージェントに対して、ZooKeeperから通知が行われます。  ZooKeeperに保存された構成情報は、MidoNetエージェントによるパケット処理計算に最適化された形で、「コンパイル」されて保存されているそうです。 – 自立分散したエージェントがZooKeeper経由で連携する方法とか、データ構造のもたせ方とか、エージェント内部の計算ロジックが実際には実装が難しい所で、このあたりが企業秘密な気もします。（さすがにソースを見ないと実装が分かりません。。。。） 34 Open Cloud Campus

オープンクラウド・キャンパス MidoNetで分散ネットワークアーキテクチャーを学びましょう！中井悦司 Twitter @enakai00

完全分散エッジ処理で実現するNeutron仮想ネットワーク

by Etsuji Nakai , Linux Engineer at -

on Sep 20, 2014

Statistics

Views

Actions

2 Embeds 16

Accessibility

Categories

Upload Details

Usage Rights

Report content

完全分散エッジ処理で実現するNeutron仮想ネットワーク Presentation Transcript

https://twitter.com	15
https://tweetdeck.twitter.com	1