OpenFlow勉強会 ログ
今日は OpenFlow 勉強会 にいってきたのですよ。Ust されなかったけど、内容的に特に公開しちゃいけないっていわれたところはなかったので(ないよね? あったら連絡ください)、取ってたメモを公開してみようと思う。わりと勢いだけで書いてるし、自分も OpenFlow 周りのところとかよくわかってないので、間違いがあるかもしれないけどその点はあしからずご承知おきください。あと、以下敬称略です。
[追記 10/3]
資料公開
開催趣旨説明(NEC Biglobe 川村)
- あいさつ
- 一瞬でうまってごめんなさい
- 開催主旨
- 自分が学びたかった
- OpenFlow しらべてみたけどあまり情報がまとまってでてない
- まとまって話きいてみたいよね
- twitter「あるとうれしいですか?」25人もリプライが
- 自分が学びたかった
- 紹介
- オープンクラウドキャンパス Open Cloud Camputs
- オープンクラウドキャンパス【クラウドネットワーク研究会 というのがあってそこで OpenFlow のはなしが。次回11月?
- オープンクラウドキャンパス Open Cloud Camputs
サービスプロバイダ運用者から見たOpenFlow/SDNへの期待 (NEC Biglobe 内藤)
サービスプロバイダの課題、OpenFlow による解決の期待について
- クラウド、サービスにもとめられる要件
- はやく(delivery): 柔軟な構成, 変更箇所をすくなく
- やすく(cost): 先行設備投資, 高いサーバ拡張スケーラビリティ
- 安全(quality): 顧客間通信の制御, 構成管理、設定ミスが発生しないNW
Delivery
- 既存
- web-db による標準構成: これだけならだいたい即時
- 顧客要求:
- IDS/IPS/LB/FW...
- 自社環境/フロア間/DC間...NW工事が必要
- 既存環境に手をいれる: 他の顧客への影響も
- 構成管理の複雑化: 職人芸
Cost
- 基盤単位/サービスやネットワークの拡張
- 初期構築時はNWリソースの利用率が低い
- スケーラビリティ: 必要なぶんだけ必要なところをつけたしたい
バランス
- お金をかけてはやく
- 時間をかけてやすく
- "やすくはやく" をどう実現するか?
Quality
OpenFlow チュートリアル
OpenFlow標準化動向とProtocolの基本動作概要(NEC 岩田)
標準化動向
- 大学/コンテンツ事業者/ベンダ: OpenFlow consortium
- v1.1(2011/02)
- NECは v1.0 をベースに製品化
- 1.1 の機能も先取りしてくみこんでいる
- 201/03から Open Networking Foundation での標準化
- ONF標準化ポリシ
- ONFにはいっていないと標準化動向の情報は取得できない(当然、開示も不可なので今日はこれ以上はだせません)
- グループ会社の場合は代表1社で(boardingは1票のみ)
- ベンダ主導よりはプロバイダ主導
- サービスプロバイダがこうあるべきだ、という上流仕様をだして、それを実現させるための仕様をきめていくトップダウンなすすめかた
- 現状のトピック
動作
- switch <--[OpenFlow-protocol]--> controller
- コンフィグの集中制御
- 従来なら firmware かかなければいけなかったものが、ソフトウェアをかくだけでいろんなソリューションを実現
- Flow switching
- L2-L4 までの 12タプル、任意のヘッダで flow 定義できる
- Flow → Action
- Rule:Action:Statistics
- Waypoint: 強力な機能のひとつ: 多段に processing engine みたな処理をかけるということも
動作概要
- switch <--[Control Channel]--> switch (channel: TCP or SSL)
- flow search
- search key
- wildcard match flow
- exact match flow
- 優先度
- exact match のが優先, wild card match は priority 指定がある
- 同一priorityの場合は実装依存
- search key
- Action
- フィールドかきかえるとか
- ベンダ定義のアクションも
- ポート
- 入出力ポート
- 通常のスイッチとして処理するポート/OpenFlow slice として動作するところ、など定義できる
- Secure channel
- Hello
- version/feature negotiation
- Flow
- packet → flow table (なければquery) → controller
- flow table にあればハードウェア転送: switch + controlelr まで含めてひとつの FIB/RIB となる機器だというイメージ
- エージング(使われていないルールの削除)
- システム動作
- Packet driven フローテーブル設定
- PUSH型 フローテーブル学習 (従来のやりかたに近い)
- 下流スイッチから設定変更することで全体の経路変更とか、パケットロスなしで変更することもできる
最近のはなし
- Windows8/HyperV OpenFlow vSwitch
- OpenFlow controller "Trema"
- 2011/4月, Trema GPLv2 で公開
- trema's Profile - GitHub, @trema_news
- C/Ruby
QA
- controller/switch間のやりとりについて: Flow table がない場合, packet→switch→controllerに送信するのは packetまるごと、ペイロードモ含めて?
- Header だけ, payload まで全体含めて、という形態がゆるされている。NEC製品はどちらも。商用版でどちら推奨かは確認しないとわからないけど設定でえらべる。
- メリデメ: 多段スイッチでパケット全体をコントローラに送れば、コントローラから Egress に近いスイッチに直接転送してレイテンシかせげるというメリットがある。
- コントローラとスイッチのやりとりについて: Hello initiate, Controller-switch 間の接続ができない場合の動作は?
- 多段になったとき、最初のスイッチにパケットがはいったときに見える情報と次のスイッチにいったときに見える情報が異なる。転送のルールはどうする?
- どうヘッダを加工するかによる。flow aggregate しない(素の flow をそのままながす)のであれば、flowに対する同じルールを各スイッチにいれる。(static route を中間機器全部に書くイメージ)
- aggregate するのであれば、同じ egress 向けのを束ねる。中継では aggregate された flow に対するルールを持つ。複数のフローを少数の flow に束ねるところでスケーラビリティをもたせるのであればそういうルール設定が必要。
- コントローラは全トポロジを知っている(全入出力ポートを知っている)。どこから入ってきたものをどこに出すか、というのをコントローラが持つ。Hop-by-Hop の制御ではなく、どこから入ったのをどこに出すか、というルールがコントローラにあればよい。(カーナビで間の経路とか混雑状況とか把握できている状況で、どこからどこに誘導するか、その誘導のしかたがちょっとちがう、というようなイメージ)。はいってきたポートだけで制御しているわけではない。
- コントローラってスイッチいくつくらいぶらさげる?
OpenFlowの実装あれこれ (Nicira 進藤)
Component
- 切り口
- Controller, Switch(hardware/software)
- Commercial, Open Source
Open vSwitch architecture
- User space: ovsdb-server(management channel tcp/6632), ovs-vswitchd (OpenFlow channel tcp/6633)
- Kernel space: openvswitch_mod.ko
OpenFlow in Open vSwitch
- 1.0 ベース
- 拡張多数
- Nicira がリードして controbute してる
Trema: An Open Source modular framework for developing OpenFlow controllers in Ruby/C
商用のもの
- NEC
- Controller & Switch
- Pronto Systems
- Quanta Computer の子会社
- Open vSwitch をポート
- boot するときにロードするソフトを選択するようになってる
- Brocade
- のちほど。
- HP
- Procurve 5400 シリーズ? 正式リリースではないかもしれない?
- Pantou
- Opensource/Commercial の中間
- H/W はコンシューマ製品
- OpenFlow 1.0 for OpenWRT (BackFire OpenWrt(Linux 2.6.32) ベース)
- ユーザスペース実装なのでパフォーマンスはでない
そのほか OSS 実装たくさん
- search "OpenFlow" in github!
Nicira Networks
- ネットワークの仮想化とかそのへんやってます。
OpenFlow でできるかもしれないこと(Brocade 高嶋)
OpenFlow usecase と brocade implementation について。
OpenFlow でできるかもしれないこと
- コントロールプレーンとデータプレーンが分離/集中管理
- 外部情報との連携
- トポロジ情報の隠蔽
- 上位レイヤのポリシにしたがった協調動作
ネットワークの仮想化
- ネットワークの分割が "しやすくなる"
- 同一MAC/同一IPのものがあっても分離できる
- 巨大DCのL2管理
- 拠点間接続のパス管理
- 構成管理DB -- OpenFlow Controller
- 設計 → controller に設計にしたがったパス開通
- 故障/輻輳 → NMSで検知 → Controller → 別パスの再計算
- キャンパスネットワーク
- 認証vlan/802.1x
- ユーザセッション(認証) → Controller → ユーザごとの接続設定
- ほか
OpenFlow
- 12タプル使った細かいポリシベースルーティングができる、というようなのに近い
- コントローラでの作りこみが必要
- キャリア系コントローラが得意なベンダとか、キャンパス系コントローラが得意なベンダとかになったりするのでは。
Brocade の対応
- 2010 OpenFlow対応アナウンス
- 2011/03 ONF参加(設立メンバ)
- 現在: NetIron CES にプロトタイプ実装中 (開発中なのであまりだせまへん)
Brocade LAN/IP製品
- L2-L7 の体育会系
- ハードウェア処理, ワイヤレートだ!
- コンポーネント
- OpenFlow Controller (頭脳)
- OpenFlow Enabled Switch (筋肉) → Brocadeが対象にしているのはここ。
Brocade の実装方針
- Control plane
- コントローラはつくらない
- Data plane
- FIB(TCAM) を OpenFlow 経由で制御可能に
- ほか
- Patch release ではなくメインにとりこみ予定
- ソフトウェア更新だけ、追加ライセンス等は不要
まとめ
- できる "かもしれない"
- 自分たちの用途にあったコントローラをつかう必要がある
年末から年明けには新しい情報がだせそう。
パネルセッション: ホンネでOpenFlow(Chair/NEC Biglobe 内藤)
OpenFlowの適用領域
- (岩) アプリケーションの領域は広い。どこ、を決めるのは各社だけど NEC がやってるのはクラウド/DC 系の自動化。このへんが比較的はまりやすく価値がみえやすい。キャリア系でもユースケースがではじめている。トライアル例でいくと MPLS を OpenFlow でコントロールして、という実験の話も。広域系での応用もふえていくだろう。各社動向みていけば、キャリア系に強いところはキャリア向けアプリ、サーバ系に強いところはサーバ向けアプリというので出てくるだろう。
- (進) おおきなシフトはない。わかりやすいのは大規模DCでVLAN拡張とか困っているようなところだろう。DCに閉じたところじゃなくて複数DCをまたぐところとか、バックボーン全体のコントロールがその次にあるんじゃないか。
- (高) GMPLSみたいなオーバーレイの夢ふたたび、みたいなところはある。OpenFlowについては、Google/Rackspace/Facebook みたいなハイパージャイアントなところは実用に使おうとしている。使いはじめている業者があるので、そのあたりでまず普及していくだろう。
QA
- マルチテナントで使おうとした場合に気をつけるところって? (Google/FB とかはシングルテナントだよね?) ホスティングしている人達が気をつけるところは?
- (高) Openstack やってる Rackspace あたりはマルチテナント。Openstack のなかに OpenFlow (Open vSwithc)がつかわれはじめてる。面白いのは、MAC-in-MAC とかの技術とかキャリアが使っていたのをDC事業者が使おうとしているとろ。VLANとかの拡張。OpenFlow のネタとしては PBB 関連の話があるので、OpenFlow だけというよりは他技術との組合せになっていくのでは。
- (進) OpenFlow はスライスを簡単につかえる。分けつつ複数の面をつくるのはやりやすいのでクラウド事業者は積極的につかっていくだろう。
- (岩) NW config が大変になるというのがでてくるけど、そこが OpenFlow の価値。ひとつのコンフィグをコピーして deploy していくという効果はある。CLIでひとつずつスイッチにいれていたのを、1箇所でまとめられる。マルチテナントだからこそ訴求していくのでは。
- (Tremaの人) 適応領域について: Vlan使いきるような多きな話がでているが、小さな事業所とか家庭とかで使えるような例、小さい NW でテストして効果のある例とかはないか?
- (岩) 商品的にはDCとかが主戦場。小さなところ、NWコンフィグなんてやってられん、完全 autoconfig にしたい、というのを中小企業向けにやれるというのはあるとおもう。IIJ SEIL みたいなの、小さいルータ置いて設定集中管理というやつ。ああいうイメージで vlan/server まわりの機材まで config してくれるという世界はあるかもしれない。
- (進) 日本固有で、ある時期になると異動(移動)で部署ごとかわったり。そういうところの省力化というのが適用事例としてはあるのでは。もっと小さなところだと、ソフトウェア開発のフェーズ、OpenFlowで単体テスト用/結合テスト用...とか動的にステージ用環境の NW 切っていく、という話がある。
- (高) 認証VLANの類/無線などでも適用できるところはあるかも。(OpenFlowじゃなくても既存の技術があるよね、というのはあるけど。)
- 小規模展開についてはオペレータ側の方がアイデアがありそうだけど
- () 適用箇所考えているけど、接続事業、接続側ルータへのサービスへの展開はありそうかな (プロビジョニングツール的用法)
既存NWとの共存/接続方法とか見えかた
全部 OpenFlow というのはあまり考えられない。古いところとつながなければいけない。
- (岩) 例: 従来機器の下に open flow の L2 domain (fabric) の枝としてぶらさがる。上位ルータ間は VRRP/LAG で、とか。WAN 間は Ether ベースのトンネルで OpenFlow domain をつなぐ。(Ether専用線/L2トンネル)。事例(自社DC) 東西DC/Ether-over-IP で OpenFlow ドメイン連結、ひとつの OpenFlow domain としてみえたり。
- (進) レガシ環境と OpenFlow-aware な環境のつなぎこみはどうしてもある。ゲートウェイ的なものを用意して物理/論理接続, 専用機械つかわずに Open vSwitch 間直接トンネルでつなぐというのでDCまたぎのL2ドメインをつくるというような方法も。
- (高) Brocade 実装としては OpenFlow でさばく TCAM, 通常のNWと両方共存できる。IGP/Static 矛盾するとループするよね、みたいなのは従来通り検討する必要がある。レガシの雲とOpenFlowの雲については間の話はここまで、共存についてはプロトコルごと(ipv4は従来/ipv6はOpenFlow)とか、ケースバイケースかな、と。
QA
- 共存しないほうがいい? できるけど気をつけてやる?
- (高) 共存はできる。こわさないように気をつけてやる必要がある。
障害影響とその対策
コントローラ一括制御: バグ、attack(のっとり)? 対策、準備は?
- (岩) Automation が簡単になる = そこを乗っ取られると大変、というのはそう。今のルータ環境でも ACL/FW 駆使してとめてるのであれば、それを centralize するというアプローチにいくべきなのではないか。いま攻撃に対する仕組みは確立してあって、そこを centralize するというのが本質かとおもう。
- (進) スケーラビリティの方向から: コントローラが死ぬとどうにもならない(SPOFになりうる) → 冗長化が必要だし、NW規模がおおきくなればなるほど処理量がふえるので、スケールする(スケールアウトする)ようなソフトウェアになっていないといけない。
- (高) 障害がおきたとき、コントローラとのやりとりがネックになって切り替えが遅くなるのでは、という議論はある。fastfailover の group, failover するときの group を組むことができる (コントローラとやりとりしないでアクションとることができる) とかそれくらいの話はある。MPLSでやればいいじゃんという話とかもあるけど… HAについては絶賛議論中でまだ固まったところがない。
QA
- OpenFlow/障害影響とスケーラビリティの思考実験をやってみた → NGNを全部OpenFlowでやるとしたら? コントローラが何台必要か、コントローラをオーバーラップさせるとか、どこまででかいコントローラが必要になるのか? どこまでおおきくなれるのか?
- (高) Brocadeコントローラやってまへんw
- (岩) エリアごとにわけるのは運用上必要だとおもう。コントローラにどこまでの範囲をみれるかははっきりいえないが、エリアごとにコントローラを置くのだろう。コントローラの数はオペレーションする人…拠点の数と同じであればよいと思っている。管理単位ごとにおけるのであればそれが適切なサイズなのでは。ただ、人員削減とか1局にしたいのであれば大コントローラとか distributed controller みたいのになっていくだろう。
- (進) OpenFlow は自由度の高い、粗いものなので、どういう設計にするかによりけり。コントローラに負荷をかけないアーキテクチャにすれば数とかはおさえられるだろう。フェデレーションみたいに管理していくというようなのとか…
- () ひとつは分散、たくさんスイッチの方向。もうひとつはフローバイザ、サービスごとにその機能が得意なものを置いて、という実装も。サービスの人は L4-L7 で NW の人は L1-L3 までのをさわって、フローバイザで proxy していくというのもある。バックエンドの切り替えは設定による。L2におくるとかL4になげる、とかの動作はルール設定による。L2-L3 のどのブロックがきたらどのコントローラになげる、とか。
- (岩) フオーバイザの目的はマルチコントローラ。flow space をわけて、このフローならこのコントローラというのをまぜる。
スケーラビリティ
時間切れー
運用系ソフトとの連携 (障害検知)
時間切れー
最後にひとこと
- (岩) 4年くらい OpenFlow やってる。最初はスタンフォードと共同研究。研究から事業までいろんなワクがある。USではかなり盛り上っているので、日本のコミュニティがひろがってほしい。
- (進) OpenFlow は単なるプロトコル。低レベルでプリミティブ。これだけで何かが実現できるわけじゃない。便利なツール、というだけで、それで何をつくるかが問題。Nicira の CTO 曰く、"OpenFlow は USB ににている" と。USB protocol でいろんなことを実装できる。OpenFlow もいっしょ。どう使ってやりたいことを実現していくか。可能性はおおきい。
- (高) OpenFlow 自体は Control plane / Data plane を分割して間のやりとりをするというだけ。Brocade は高速I/Fを用意している。おもしろい使いかたがあれば情報交換を。
Wrap-up (NEC Biglobe 川村)
- 資料はおって公開します: SlideShare あたりに。
- OpenFlow の他の情報源、Open cloud campus, なにか他にあったりするんですかね?
- なにかアイデアとかあれば
- 勉強会、第2回やるべきかどうか? 乱立してもいいだろうし。まとめるサイトがあってもよいだろう。
