Trema Day #3 参加メモ #tremaday

study life

はじめに

前回に引き続き Trema Day #3 参加してきました。

いやあ、今回人多かったですねえ。過去最多? 少なくとも終了後の懇親会は過去最多ですよねえ。すごいのう。

[追記 2013-07-28]
一応今回のツイートまとめもつくっておきました。(上記togetter), 公開資料とかは、追って見かけたら追記していきます。

Wakame-VDC の仮想ネットワーク, 山崎さん

Wakame-VDC の仮想ネットワークについて

ネットワーク機能の略歴

  • OpenStack みたいなもの、といって紹介しますが、OpenStack より2ヶ月早くリリースしています
  • ネットワークって難しいというのがこの頃わかった
  • 半年後(2010/11)にセキュリティグループ、分散スイッチのコントロール、いま見ると edge networking architecture にこの時点でなっている。
    • あらゆるものを edge によせるとコントロールがすごくやりやすくなる
    • 当時は linux/netfilter
  • 2011/12 ごろ、Trema/OpenFlow1.0へ置き換え
  • 2012/3 virtual network

Wakame-VDC Users

  • NTT PC Communications, 京セラコミュニケーションシステム, 九州電力など

構造

  • AMQP Network にエージェントがたくさん刺さる。Agent は物理リソースを管理。Agent 同士が話をしながら全体の仕事を行っていく。
  • RabbitMQ でとか。python か ruby かという程度でOpenStackとそんなに違わない
    • hva, bksta, sta, netbox, nwmngw, collector など、役割の違う(管理する物理リソースの違う)のエージェントがある。
  • GUI → Web API Server (dcmgr) → AMQP
    • UIを独自開発することも。

Network の論理構造

  • Edge network: リソース側だけでなく DCNW の WAN 側の Edge もある
    • WAN Edge: DNAT/LB OVS cluster
    • LAN Edge; Tunnel & SNAT/DHCP/DNS OVS cluster
    • Edge node ですべてパケットのコントロールをしていく。

Agents on logical network

  • agent を edge node に配置
    • natbox - hva - vm
    • bksta で複数拠点間マシンイメージやりとりなどの機能も。(京セラでやってる)

User defined multitenant networks

  • 任意に自分のためのネットワークを作る
  • hva が AMQP NW にジョインして管理ネットワークから指令を受け取り、OVSの設定を変えたりしていく。
phys network(phys L2/L3)

phys server --+-- virtual network (virtual L2/L3)
              |
              +-- vitual machine

Embedded Trema

  • HVA の中に Trema が組み込まれている。分散 Trema 状態。
  • スイッチ1個について1個のコントローラが張り付いている。Trema ないし OVS について正しく指示を出せればよい: HVA

Distributed DHCP server

  • 一般に DHCP/DNS server やるのにインスタンスを起動しないといけない、とか。管理が大変だろう。NWが死んだり、DNSMASQ のノードがぶっとだとか。クリティカルで簡単にメンテナンスができない。
  • DHCP Server そのものを分散で処理。discovery → OVS Flow Table → Controller Management Line で回答を DB から検索 Controller → Management Line で回答を DB から検索
  • 返すべき情報がわかったら DHCP パケットを作って返答。1つのボックス内で完結。
  • Static に処理できるものは OVS 内で処理、動的に解決するものはフックして返事を HVA/Trema 内でつくる。

Virtual Networking

  • 仕組みが二つ
    • MAC2MAC(社内呼称ですが)
      • GRE Tunnelってコスト高いのでは?
      • ARP broadcast domain のコントロール。IP わからんから ARP 投げる。でも一般的にクラウドコントローラは場所知ってる。
      • ユニキャストに変換してユニキャストで届ける。VM間ではARP届いてキャッシュに残る。間の経路もスイッチに覚えてもらえる。
      • カプセリングしないのでパケットが太らない。通常のL2スイッチでも動作。ただ、物理L3は超えられない。(そういうときは GRE 使えばよいでしょう)
    • GRE Tunnel

二つVMがある場合

  • ARP request (VM1→VM2), OVS で DST Addr を broadcast → unicast に変換して宛先のいるOVSにだけ届ける。

そのほかのネットワーク機能

  • GRE Tunnel
    • 物理L3超えるときに使う
  • security groups
    • dynamical firewall
  • external ip

MAC2MAC or GRE

  • DBにコントロールされるスイッチの物理L2セグメントグルーピングルールを入れる。
    • 同一セグメントならMAC2MAC, 別セグならGREトンネル

Wakame SDN Architecture

  • DCMが全部のエージェントを管理
    • HVA〜Trema → OVS 1台を制御
    • Trema/OVSは1対1なので TCP socket じゃなくて unix socket を使うよう改造している。セキュリティ上のメリット
      • OVS は Unix socket 使えるので、Tremaをいじってる。ほしい人がいればあげます。
デモ1
  • 複数テナント・複数VM起動のデモ
wakame-vnet

課題

  • wakame-vdc とくっついてる
  • 仮想NW機能だけ切り離してやろう
    • IaaS に依存しないで独立して。OF1.3

物理構成はほぼ同じ。

  • vna (virtual network agent)

module 相関図

  • vna 〜 ZeroMQ (+redis)
    • trema edge, OF1.3 で OVS1.10 と会話

フローテーブルの設計

  • (略)

メタデータ

  • (略)

Flowの読み方

  • (略)

悲しいお知らせ

  • 資料書いたけどFlowTableの設計は見直し(先週根本的に見直しました)
  • Metadata のマスク設計も Table 単位に細かく行うべきだという結論に。単純に 64bit の中を適当に分割して使うとかじゃ今ひとつ。狭いメモリ領域をいかに効率よく使うかで悩んでいる。
デモ2
  • virtual network 構築
  • 分散 DHCP
  • VM間通信, MAC2MAC(同一L2内部) and GRE(L3またぎ)で仮想ネットワークを構成

使ってデバッグしてコミットしてくれるとうれしいです。

今後について

整備中

  • notification
  • packet filtering
    • per vif security groups + firewall rule
  • wan edge netwroking
    • global ip addr (NAT)

半年以内にはできあがると思う

  • 仮想L3ルーティング機能
    • 仮想L2/L3の実現
  • ほかの外部ネットワークとの連携

大変なこと

  • trema edge へのコミット
  • OF1.0 -> OF1.3 へのフロー書き直し
    • Metadata, cookie の設計が複雑
  • テスト環境が貧弱で…
    • 50A以上増やせない…

ZeroMQの性能いいよ

QA
  • RabbitMQ から ZeroMQ に変えた理由、Redis 何に使っているか?
    • ベースで使っている Ruby ライブラリ、分散処理とかRPC定義など自作だった。最近 Celluloid というライブラリを見つけた。それが ZeroMQ ベースだったというのがきっかけ。ZeroMQ は小さいメッセージのやりとりですごくパフォーマンスがいい。NWは細かいパケットいっぱい飛ぶよね、Celluloid そのまま使えるし、というので ZeroMQ に。ZeroMQ か Celluloid かどちらかの制約でバックエンドの選択肢がある。それで Redis にしている。深い意味があるわけではなく、なし崩し的にプロダクト使っている感じ。
  • ARP を unicast にする。phys broadcast になるものってほかにもある。Multicast とかどうしているか？
    • あえて無視している。broadcast 使っているもののうち、どこに行くかわかっている物だけが制御できる。どうしてもブロードキャストしなきゃいけないものもあるだろうし。やるなら unicast に変換してばらまくとか作らないといけないだろうと思っている。
    • 今は無視する設定で、どこまで客の要望を提供できているか?
    • IaaS であればいまは無視していても大丈夫だろう。Webシステムとかで使うのが通常だろうから。やりたいというリクエストがあればやるが、今はそれほどない。
  • さっき(でもムービーの中で) Ping うつとき、GRE接続のほうにも ARP 届いていたのはが気になりました…
    • 作ってる最中のデモなので、意図しない動きをしているところがまだいくつか残っています。
  • 物理L3ルータ越え、GREトンネル、カプセル化する場合 MTU 調整がいると思う。今回 wakame-vnet ではどうしている?
    • MTUは未調整。いまネットワークエンジニアがいないのでわからないことがあって、実際に運用上どういう作法があるのかとか、チューニングとかは教えてほしい。いま GRE わりと無視しているのは、実態、客先のところでは L3 が必要になるほど大きな仮想基盤の方が珍しい。L2 でがんばるというのがまずどこもあると思っている。まずL2で動くことに注目。MTU など細かいチューニングの話は組み込みたいのでご意見、コミットいただけるとありがたいです。
  • vSwitch 間の phys network backboneは各仮想ネットワークの isolation をするようになにかしているのか。MAC Addr ベース、VM上でMACアドレス偽装とかされると問題になったりしないか?
    • 物理マシン上のMACと一致してしまうとだまされてしまう。基本しらない MAC は VM から外に出さないような仕組みがある。ARP 受け入れなど混乱しないようなフローは一応はいっている。完璧ではないと思うが、port/mac, 少なくともMACレベルで違うものは外に出ない。それ以外VM上で変なパケットが作られていてもだいたいドロップされるはず。少なくともMAC書き換えレベルであれば外に得ないはず。

Hybrid SDN によるルーティングの実用性向上を目指して, 仲程さん

SDNとはなにか?

  • software によってNW構成・機能・設定をプログラミング

OSPFについて

  • 現在のルーティング
    • 最短経路が主流
  • OSPF
    • 一部NWにおけるNW輻輳率の増加
  • Smart-OSPF
    • IEEE Globecom 2007
    • 発ノード別の分散

S-OSPF

  • 発ノードが隣接に対して分散してデータをばらして送る

S-OSPF実装

  • 非SDNで実装
    • 機能追加が大変
    • 実用が難しい
    • ネットワーク全体の状態把握が難しい
  • SDNの考え方で解決

S-OSPF実装(w/SDN)

  • エッジノードのみSDNを適用、それ以外は通常のOSPFノード

ロードマップ

  • 今回 POX でかいたらすごく長くなりました…
  • mininet つかって実験。

今後

  • 実機実験

QA

  • デバッグ大変だと思いますがどういう戦略?
    • 結構 trial and error になると思いますが…, どういう割合で転送料を決める、というのもいろいろある。計算方法とかももまた違う。まだアルゴリズムも決定していないのでこれから考えます。
  • エッジの機器は宛先だけ降ってやるだけでOSPFはいらない? S-OSPFのメリットは?
    • 根底、OSPFの環境をうまく使う。全員がOSPFをしゃべれるという前提でやっていた。エッジが分散の計算だけで、というのについてどうするか。本来S-OSPF自体はコントローラのない状態なので、エッジがルートを把握することによって、というのがあるはず。
    • 分散環境、ループフリーというあたりがキーでは。エッジノードだけルールを外れて分散の計算をやるんだけど、ほかのノードには影響を与えずに、エッジノードがうまく回してくれるという話じゃないか。
  • OSPF、S-OSPFは分散。それを集中管理で。論文と価格と気は集中制御でマルチパス制御っていろいろ方法がある。その辺、比較とかサーベイの話がないと reject しちゃうかも。根本的に集中管理できれば全部コントロールできちゃうしね。
  • [メモ取得漏れ]
  • S-OSPFについてはよくわかってないけど、Edgeってどういう意味?
    • OSPF Area Edge という意味, OSPFのネットワークに対してのSDN対応を考えていた。前提としてノード全員がOSPFしゃべるというので考えていた。
    • OSPFパケットを解析してにDB組んでアクションを考えるみたいのをやる?
    • 考えています。

Rubyでパケットパーサ, 高宮さん

資料: Ruby でパケットパーサを作ろう

Trema Day の話
  • 今回、新しい試みとしてLineのスクリーンショットを張ってみた。そうしたら、すごい人が来た。3回目で過去最多参加者。
  • Field of dreams という映画があった。主人公、夢の中でお告げ、あれを作ると人が集まってくるぞ、というのを夢の中で聞く。トウモロコシ畑をつぶして野球場を作ると…。
  • Field of dreams 作戦。何か作ると人が集まってくる。Lineで画面を作ると人が集まってくる。
  • KDDIウェブコミュニケーションズさんありがとうございます。

自己紹介

  • 周りの、使ってる人が発表したらいいや、と思っていたので、私は発表しないことにしています。なので、スペシャルゲストを呼びます。
  • 東京都立川市でコンビニの店長をしております。大木と申します。
  • 最近、コンビニでこういう事件がありました。こういうことをするとコンビニがなくなっちゃうのでやめてほしいなーと。日本だけじゃなくて海外でも…(台湾・アメリカ)、ただ涼むだけのために中に入っちゃう人が。未然にふさげないか? 最新のネットワークを使って!
Rubyでパケットのパーサとジェネレータを作ろう
  • トポロジ探索サンプルコード
  • 短く、読みやすく、改造しやすい、コードがあるといいな
  • コントローラの中でLLDPのパケットを作って、パケットアウトしている。
  • コントローラの中にLLDPパケットジェネレータとパーサがある。
  • パケット作ったり読んだり。Rubyでライブラリないかな。Rubyだとあんまりネットワーク系のパーsがない。
    • packetfu: ソースがPerlっぽい +1 とか -1 とか。Rubyで書く意味あんまりないなあ
    • racket, 1年くらいメンテされてない。ちょっと思っていたのと違う。おしい…。やりたいのはパケット作ってパース、ってとこなのでそこだけでいいな。

理想

l = lldp.read(bynary)
l.dpid #=> 12345

とか

  • bindata
    • 宣言的DSLでクラスを定義すると、動的にジェネレータとパーサを生成する。
    • 試しにこれでやってみたらうまくいった。

Bindataでどう作るか?

  • LLDP Frame Format
  • Bindataでかくとこうなる
    • クラス定義に型とフィールドを定義していく
      • 型: フィールド名
    • すごくきれいに書ける。フォーマット見たままクラスに落とせる。
  • 定義したクラスを使う

型

  • primitive 型
    • string, stringz, int8/16/32be, bit1/2/4_l3, float_le, double_be,.....
    • primitive 型だけでも全部やれるけど、すごく長くなる + TLVとかまとめたい。
  • ユーザ定義型
    • mac_address, chassis_id_tlv など。プリミティブ型を組み合わせて作っていく。
    • TLVとかもかなり直感的に書きくだせる

これで、Optional TLVとか来るかどうかわからないところ以外は LLDP parse できる。

Optional TLV, 結構使う。ちょっと凝ったことをしようとすると、Ciscoの何とかとか。TLVに入ってくる。問題は、TLVあるかないかわからない。一つのヤマはあるかないかわからないデータをどう扱うか。

解決策。Optional TLV, endof LLDPDU TLV をまとめて、1〜N個のTLVだと考える。可変長Arrayみたいなモノとして実装。

Optional TLV

  • End of LLDPDU でおわる Optional TLV 配列
array :optional_tlv,
      :type => :optional_tlv,
      :read_until
        => lambda { element.end_of_lldpdu? }

終端チェック

  • OptionalTlv class
tlv_type = 0

タイプの判別

choice :tlv_value,
        :selection => :chooser do
    end_of_lldpdu_value 0
    ....

def chooser
   if tlv_type == 0 or
      (...)
      tlv_type
   else
     "unknown"
   end
end

これですべてパースできた!

  • "ちょっと一手間でこのうまさ" (神田川俊郎)
  • MACの指定、octet array? 文字列で渡したいよね。
    • 文字列→整数配列, set method
  • 複合型…ちゃんとテストが必要
    • rspec でテスト
    • たんぽぽを作ってみました(近藤さん) w/ruby_topology
    • 近いうちにTremaのサンプルに入ります。

Tremaレシピ集を

  • みんな使う同じようなことはまとめて配布したい。

parserとかは手分けしやすい。

  • pcapを集める人
  • コーディングをする人
  • 実環境でテストする人

こういうのをパースしたいとか、こう言うよとが、とか使う部分から作っていけばいいかな。と考えている。

いま、Trema, Trema-edge は結構共通している。共通ところを抜き出して汎用gemとして重複部分をなくそうとしている。

  • paper-house (done)
  • Trema::Packet (今後)

興味のある人は是非参加を。

QA
  • TLVのパース、Mandatory & Option, 全部まとめた方がシンプルでは?
    • それは考えたんだが、なんかうまくいかなそう。LLDP の 使用が 2005年版と2009年版であって、mandatory field の解釈が違ってうまく一般化できなかった。共通化しようと思ったんだけどそういうのがあったのでやめました。
  • TLVって、ether の仕様が増えるたびに増えたり、サブフィールドがあるのもあったりするのだけど、拡張しやすいようにするには?
    • ネストするときとか。調べると、昔の Ruby の ML で、BinData の作者が直回答でできるよとだけ。ネストの例はサンプルに載っているのでやれるのはやれる。
    • ネストする場合は。タイプが増える場合
    • はじめは愚直にクラスを作って、共通化していくくらいしかない気がする。
    • chooser を増やしていく、クラスをマルチ継承するのもうまくいかなさそう。EtherとLLDPを分けたい。
    • 分けたい理由は、LLDPの次のほかのパーサを作る。Ether(L2)の部分が重複する。そこはほかのでも使うから。
    • 増えてきたら共通する部分を分ける。
    • L2でVLANとか増えてくると、LLDPだけで対処するのは難しいから分けておいた方がよさそう。
  • TremaとTrema-edgeで、Trema-edgeが情報が byte array で渡される。仕様的なところの統一とかある?
    • packet_in.data で、trema-edge は byte code array がくる。iterator とかもつかえるので。とりあえずの対処としては、array がきたかどうかで分ける。ゆくゆくはTrema/Trema-edgeで統一。

いまTremaに必要なもの, 大山さん

  • ユーザ視点で、機能的にあったらいいよね、というものを考えてみました。
    • OpenFlowの本を書きました。増刷しました!
Trema とは何か?
  • All in one な openflow framework
    • All in one -> eclipse? 的なモノをイメージ(個人的には)
    • emulator, debugger, profiler, ...

可視化・モニタリングのツールがない(プロファイラ相当のモノがない)なあ

カスタマイズ可能な、可視化・モニタリングするプラグイン

  • tremaday #2 の続きです。
  • Trema-satelite Architecture
  • カスタマイズ性
    • "Mechanism, Not Policy"
    • 利用シーンによってやりたいことや見たい情報は異なる。
    • 用途に特化させるのではなく、用途に合わせてカスタマイズできるようにしよう

じゃどうやってやるの?

  • まだ実装が固まっていないので考え方の話をします。
    • 軸: 全体-個別, 物理ポート-フローエントリ

一緒に開発しませんか？
フィードバック大募集

QA
  • いまtrema-satelliteで手伝ってほしいとことかフィードバックのほしいところってどのへん?
    • 実際に使っている場面、自社でもNWの監視に気をつかっているところがある。こういうツールが有効だというのが感触としては持っている。どういう場面とか利用例とか、そう言うのは知りたい。あと、いま単純に見せるだけなのだけど、その情報を別途Export/Import するような機能はリクエストでもらっていて、そう言われて初めて気づくこともあるので、そういう要望がほしい。これまで UI を刷新して、描画ルーチンとか細かいところをいろいろやっていて全体のところがあまり進んでいないです。Protovis というのがあって、これをいじっていたら3ヶ月あまり進んでない。
  • ネットワークの監視ツールとか職場で使ってる。見るだけじゃなくて、閾値監視とか、そういう要望は出そうだけど、今後どういう方向を狙っているか?
    • あまり大きく設計して作ろうとすると失敗しそうな気がしている。ゴールは近いところにして考えていこうとしているので、監視ツール連携とかよりは、見せるところ、Export/Import あたり。まだどういうところで使うか、というのがはっきり見えていないので、ゴール設定は曖昧。どこでどう使うかをみながら検討。
  • ネットワーク管理監視をやってる。CSV とかいう話あるけど、リアルタイム流量計測、情報を見てどういう対処をするか、リアルタイム性が求められている。なので、Fluentd とかに加えるようなこと、流量や障害の起きそうなデータとか、静的データじゃなくて動的に流すルートを作れるとうれしい。NW規模が大きくなると一人では追えない。怪しいところとか分析したりして出してくれるようなものがほしい。
  • 監視システム連携みたいな話と、Viewer/GUIって分かれると思う。Tremaの中にある情報を外に出すっていう連携の話と、可視化・Viewerの分離できるといろいろやれるのでは?
    • [メモ取得漏れ]
  • グループの指定, URLどうやってやろうかとか。Tremaで仮想NWとか作り始めると、そこでやってることこっちでもやるのか。Sliceable Switchとか、Tremaアプリ上で論理ネットみたいな話。IaaS監視などやると、そういう仮想NWのはOFコントローラから出さないといけない。
    • [メモ取得漏れ]

Nuro biz の話[タイトル記録漏れ], 近藤さん

nuro biz?
  • 下り最大2Gbps,登り最大1Gbps
  • 効率よく利用できて安いルータ?
    • 上司いわく「じゃOpenFlowで作れよ」
  • LINCやろうとしてたけど…まだつかってません。TremaEdgeもまだ使っていません。
nuroの構成
  • 1Gずつ2本回線がある。ひとつは固定IP(LAN1), もう一つは Global IP DHCP (LAN2)
  • 回線分散装置、DHCPくらいあのみたいな機能も必要
  • PPPoEとか使わないので簡単に使える。
検証構成
  • 自分で作ったのと、普通のルータでどう違うか。
  • CDN〜NURO〜ローカルで負荷生成
  • 既存のルータもバランシングの機能があってマルチホーミングみたいなので来て、2系統の回線を使える。
    • 某ルータだと、うまくLAN1/LAN2のバランシングができてない(偏りがある)。900MbpsこえるとCPU90%とか(ソフトウェアベースのルータ)、
  • OFSの場合、だいたい2本同等に使える、合計1,3Gとか。だいたい1.3倍くらいにやれた。(端末数の都合でここまで。ソフトウェア的にはまだ余裕があった)

OFSの場合

  • WANトラフィックに応じた動的な経路割り当てができる
  • NAPTセッションを管理している部分の負荷が高い

やりのこし

  • ルーティングテーブルの処理、NAPTテーブルの処理が重い。設計の見直しや別言語での実装も視野に入れる必要がありそう。
  • nuro bizサービスのうち、公開IP一つという品目。公開IPが複数とかの場合にどうするか、通信制限などをどうするかも考える必要がある。
  • 設定が今SQLなので設定が大変。管理UIを作ろう。

今後進展があればまた発表します。

QA
  • OFCテンパる、packet-in, どれくらいとかデータある?
    • 500-600 packet-in-req/sec, NAPTセッション管理がまだあまりよくない。配列に通信割り当て push/pop みたいなので管理。それはかなり負荷が高いのでどうにかしないといけない。

OpenStack 仮想ネットワークでのトラフィックフロー制御, 坪井さん

資料: OpenStack with OpenFlow

OpenStack 環境を手元で作っていろいろテストしてた。

環境作ってみると OpenFlow の振る舞いと似ているかなあ、というあたりの荷ほどき。

IaaS基盤の理想像
  • 仮想インスタンスがほしいときに、簡単な操作で、すぐにデプロイしたい
  • OpenStackで簡単に、トポロジかしかしながらできたりする。

OpenStack の技術課題

  • 仮想NWを作る
    • 見た目はそれっぽいけど、うまく動かない事例が何度かある。
    • 原因解析のノウハウためないと実運用で使うのは難しいかな…
    • OpenStackの仮想NWを理解した上でスキルをためていきたい
    • OpenStackの仮想NWを理解する上で、わかりやすい技術書籍とかはあまりないよね
OpenStackの理解

知りたいこと

  • Neutron仮想ネットワーク技術要素において
    • OVSを活用したテナント分離方法
    • OVSを活用したトラフィックフロー制御方法

Grizzly盤仮想NWを作ってみた

  • 特徴, GRE tunnel, key id, vlan tag などがあってこれでテナントとかを区別してるんじゃないか

わかったこと

  • OVS, br-int, br-tun トンネルIDを利用してテナント分離を図っている
  • neutron 仮想ネットワークの特徴
    • Compute Nodeの仮想エッジに事前にフローエントリを設定

チャレンジ

  • 課題認識
    • GRE Tunnel 内でNW障害があるとSPoF
    • GRE Tunnel 2本はるとL2ループの危険性 (FDB依存(action=NORMAL))
    • OFとかうまく使うとL2マルチパス環境ができるんじゃないか。

GREトンネル冗長

  • 故障があると、予備系GREトンネルを迂回させる。(OF1.0 + Nicira extension)
    • Compute node 物理NICがとまってもport statusが送出されない。故障検知の仕掛けが必要。
デモ
  • ICMPを定期的に投げてGRE Tunnel経路の故障検出を行っている
  • NIC Shut して GRE Tunnel の経路切り替え
おわりに
  • OSPT仮想ネットワークの理解、という流れで試してみた。
  • 本当は neutron plugin 化が必要なのだろう。
QA
  • [メモ取得漏れ]

Virtual network platform の紹介, すぎょうさん

資料: Virtual Network Platformの紹介

なにができるか

  • 仮想ネットワークの作成と管理
    • 物理ネットワーク上に仮想ネットワークを作っていく
    • ポート; datapath id, port name, port number, vlan id で識別
  • vxlan base
    • vxlan で switch(ovs), レガシーなどとつながる

アーキテクチャ

  • コントローラ
    • Virtual network manager: メインのコンポーネント
    • Frontend で要求を受けてデータベース(MySQL)にデータ入れる
    • データベースの情報を元に vnm がほかのスイッチをコントロール
  • スイッチ
    • virtual network agent: manager から vxlan endpoint 設定要求などを受けて処理を行う。
    • vxlan tunnel endpoint: linux kernel の vxlan module か、自前処理で vxlan
    • OVS, ubuntu12.04 のパッケージをそのまま利用

VXLANはOVSじゃなくて独自。ユーザ空間で動くプロセスになっている。

  • vxland が linux tap device で OVS datapath にくっつく

VXLAN 部分は hogelan ベースで改造

特徴

  • プロアクティブ型
    • コントローラが要求を受けたタイミングでフローを設定する
    • packet-in は全部落とす
    • 設定ではVMなどのMACアドレスを登録する方向。登録しない場合、broadcast同等の動作をする。MAC登録されている場合は全部ユニキャスト。
    • VXLANのMAC学習とは別で連動していない

API

  • sliceable_switch みたいなかたちにしてある
    • REST Base, JSON format
    • NW、ポート、MACの追加削除一覧詳細
    • "Busy Here", proactive なので設定中は次の設定ができない。
今後の予定
  • 決まってません。
    • 公開するのに時間がかかってしまった
QA
  • trema? trema-edge?
    • trema
    • ruby? C?
    • VNMはC, frontend/agentはruby (RESTとかはrubyが楽)
  • VXLAN ほかのベンダともつながる?
    • 接続確認とかはしたことがないです。が、Draft準拠なのでいけるんじゃないか…、いまはipv6は対応してないけどipv4であれば
  • broadcast mapping (underlay) は? ip multicast?
    • 全部入り。マルチキャストもユニキャストもソースにはあるけど、ユニキャストについてはドキュメントには書いてない。READMEとかで書いてあるのはMulticastの例。ソースを見ていただければ。リフレクタとか例は。使い方とかはドキュメントがないので難しいかもしれないですが。
    • CiscoとやるとかだとCiscoでもエンドポイントの設定いるの?
    • 設定しないといけないのはMulticast Group Addrとポート番号。それだけであとはアクセスコントロールとかの制限がなければ普通につながるはず。ポート番号は、一応Draftで 4789 が IANA から割り当てられている, 一時的に 8472 とか使ってるものがあるかも。グループアドレスは使う人がアサインする。Linux Kernel とはつながった実績はあるので、そんなにトラブルにはならないのではないかと思っている。ただ、Linux Kernel 3.7 とかはデフォルトポートが違ったので注意。新しいカーネルでは変更されたかなあ。OVS はユニキャストなので、マルチキャストVXLANではつながらないだろう。
  • sliceable switch like API, やりたいことは、たくさんネットワーク作りたい。ハードウェアスイッチのしがらみとかがないときに、sliceable じゃなくてこっちを使うメリット?
    • sliceable は hop-by-hop, こっちは overlay, 全部がOFSでなくても何とかなる。
    • ユニキャストでもできる?
    • 一応…。ユニキャストでも使える、というので試しに入れている。