OpenFlow勉強会その1 #nwstudy 分科会 ログ

行ってきたのでまたメモを出すよ。いつもの通り、間違いがあるとか、それ違うよっていうのがある可能性は多々あるので、その辺はコメントなり @stereocat なりで教えてください。直します。

以降、敬称略です。

[追記] 02/12

はじめに(石光)

  • アンケート
  • アプリ開発したことある?
    • 大半がしたことあるで挙手
  • OpenFlowへの関わり
    • ほとんど初心者
    • コントローラとか作ってる人も数人(5−6人くらい?)

OpenFlow概要の概要(石光)

アプリとネットワークの違い

  • アプリ開発
    • アプリはコーディングすればどうにかなる
  • ネットワークエンジニアへ
    • プロトコル(約束事)の世界、何でも自由になるわけではない。できないことはできない。
  • これって、アプリみたいに自由にならないのかな?
  • OpenFlow でなんとかなりそう?

OpenFlowへの期待

  • ネットワークを柔軟に・制約の世界から自由になれるのか?

でも…

  • 動くの?
  • 食わず嫌いじゃなくて勉強しよう

OpenFlowについて

  • 何か?
    • ネットワークを Top-down/Open に
    • Programmable: SDN コンセプトを実現するためのプロトコル

仕組み

  • いままでのネットワーク機器
    • ソフトウェアとハードウェアが一体化した専門の機器で実現
  • これから(OpenFlow)
    • 専用機 → 汎用機で、ベンダにとらわれないオープンな世界
    • 制御と転送に分離
      • 制御: OpenFlow Controller (OFC)
        • 専用機器じゃなくて汎用的な機器・OSで構成
      • 転送: OpenFlow Switch (OFS)
        • 転送に特化した専用のハードウェア
        • コントローラからスイッチを制御するためのプロトコルが OpenFlow

メリット

  • ネットワークの自由度が上がる
    • 従来: 転送に使える情報は限定、レイヤ/プロトコル制約
    • OpenFlow: フローテーブルによるアプリケーションごとの経路制御、パケットの書き換えを行う…FWみたいな機能、障害による経路変更などが柔軟に
  • 仮想化を容易に実現できる
    • 従来: Live Migration…VLAN制約(設定追従/VLAN数制約)
    • VLAN/Slice を OFC で一元的に実現
  • コストが下がる
    • 従来: 専用機、開発コスト。新規参入が困難
    • OpenFlow: コントローラには汎用製品が使える、スイッチの単純化
  • 管理しやすくなる
    • 従来: NMSとか各社ばらばら。設定も個別に機器に入れなければいけない
    • OpenFlow: OFCで一元管理。コントローラに運用管理ツール組み合わせて一括設定。
  • ネットワーク機器を我々が作れる
    • 従来: 専用機器
    • OpenFlow: 自前でプログラム

"OpenFlowとともにネットワークを自由に、我々の手に"

OpenFlowについて (宮下)

OpenFlow の特徴と、OpenFlow Framework: Trema でアプリ作ってみたものの紹介、できることとできないことについて。

DCネットワークの課題

  • 仮想化集約すると複雑に。
  • 短納期なのに設計とか構築。とても大変。
  • いろんな技術が絡んでトラブルシュートが大変。
    • ネットワークにめちゃくちゃ詳しくないと、保守とか運用が困難な状況に既にになってきている。
  • 全自動化を目指すともっと多くの知識の習得が必要
    • VM/Storage は仮想化自動化が進んでいるけどネットワークがやり玉に挙がっている。
    • AMPP, VXLAN?

全自動化が流れ

  • 今のネットワークはいろんなプロトコルのパズル。でもインタフェースは統一されていない。自動化の妨げになっている。
  • ソフトウェアによってネットワークの論理構成作ってしまえという概念: SDN
    • 具体化: OpenFlow

OpenFlow への期待感

  • 1つのプロトコル、1つのレイヤリング、構築・運用・保守をシンプルに
  • いままで、いろんなレイヤ/各デバイスの自律制御: これは結構難しい
  • OpenFlow: プロトコルとコントローラ、シンプルな階層わけ

OpenFlow のアーキテクチャ

  • OpenFlow Controller (OFC)
  • OpenFlow Switch (OFS)
    • 転送に特化した機材
  • スイッチにパケットが飛ぶと
    • 既知であれば転送
    • 未知であればコントローラにクエリ
    • L2-L4のフィールドを見てスイッチングする

スイッチ

コントローラ

アプリケーションフレームワーク型のコントローラ

  • Application --(API)-- Controller --(OpenFlow)-- OFS

Trema

  • OSS, Framework型、NEC, Ruby/C++,
  • Rubyの場合
    • Test Framework (Trema がシミュレータを持っている)
    • イベントハンドラをオーバーライドするだけでプログラムができる。Frameworkで規定しているデフォルトパラメタを使うとアプリのコード数を減らせる
  • tremaによる OpenFlow Programming (ruby)
    • Controller class をオーバーライド
    • タイマハンドラの設定が可能
    • OpenFlowプロトコルで規定しているイベントに対応するハンドラをオーバーライドするだけ

NEC UNIVERGE PF6800コントローラ

  • ネットワーク全体を1台の仮想的なスイッチに見えるような管理
  • ver.1.0.0 準拠

OpenFlowは魔法の技術ではない

  • コントローラをちゃんと用意して(作って)やらないと何もできない。

OpenFlowはやすいのか?

  • コモディティ化が進んでネットワーク構築が安価になる?
  • コントローラのベンダロックインにならないか?
    • サポート費用、機能不足対応はどうか
    • トータルな費用が安くなるのか、疑心暗鬼
    • コントローラ同士の強調動作とかどうなるのか? コントローラが一つに(ロックイン)されるのでは?

OpenFlow の普及

  • フリーのコントローラが必要なのでは
    • Openで機能拡張できる
    • トラブルシュートが簡単
    • 設定が不要、導入が簡単、既存ネットの統合が容易、etc
    • 怠け者のためのコントローラ

Tremaアプリ(lily)

  • IaaSで使うような環境を想定

MAC addr base vlan

  • MAC addr group: 手動定義(xml file)
  • グループが同じ MAC addr 同士が通信できる
  • 長所
    • 動作原理が簡単(実装が簡単)
    • TAG数の制限をうけない
  • 短所
    • 書き換えによるセキュリティホール(サーバがMAC書き換える場合)
      • 書き換え可能なパラメタでサーバ識別している
      • 隣接スイッチのポートを識別しないといけない
      • 仕様ではポートがダウンリンクかアップリンクかを識別する機能がないので自力でトポロジ検索しないといけない。ただ、ダウンリンクとサーバの接続関係はわからない。他の管理機能と連携しなければいけない。
      • KVM連携とか考えている。サーバが接続するポートをどうにかして検出する仕組み? いまはダウンリンク情報手書き。
    • フロー数爆発
      • MPLSによるネットワーク分割とかできないか
      • いま Trema ではMPLSサポートしていない様子

物理ネットワークトポロジの自動検出

  • L2専用パケットをスイッチ間で定期送信、管理LAN/業務LANわけて
  • 課題
    • L2専用フレーム、非OpenFlowスイッチを検出できない → LLDP?
    • OpenFlow プロトコル自体がトポロジ検出サポートしたらいいのに
      • 将来的にはトポロジ検出サポート?

ループ自動検出、最短パス検索、障害箇所迂回

帯域制御

  • OpenFlow 1.1.0 では帯域制御自体、オプション、帯域制御設定は仕様外
  • 実装
    • ダウンリンクしらべて帯域設定
      • VMホストに乗り込んで設定ごにょごにょ(入るための情報は別途用意)
      • OVS port 番号を tap 名に変換

まとめ

  • DCネットワーク課題解決に OpenFlow が期待されてる
    • VLAN自動設定、シンプルなネットワーク設計
  • OpenFlow 技術だけでは解決はできない。外部管理ソフトとの連携が必要だろう
  • 普及阻害要因としてコントローラのベンダロックインがありそう
    • フリーでリッチな OpenFlow 界のLinuxみたいなコントローラが必要なのでは。

QA

  • MAC-in-MAC, QinQ とかちゃんと使えるようなハードウェアがどこまであるか。いま出回ってる OFS では対応できなくて2層にならないといけないとか、技術的にはいろいろありそう。
  • OFS がコントローラと接続切れた場合?
    • まだあまり考えてない。lily ではトポロジ検索情報から外れるので、迂回するようになる。ただ、コントローラとの間が切れただけでスイッチが生きているとかだと変な動作になるかも。
  • 商用とかで使われてないので、その辺がどう動くのか、というのがネックか。unknown flow に対して ARP 解決しないといけない。タイムラグとかあるはず。それがある程度スイッチスケールしていくと大変なのかな。
    • Unknown パケットがどんどんスイッチにきたときは弱点として言われてるみたい。ただ、Whitepaper見たら、クラスタリングとか負荷分散しろとかくらいで、楽観的な感じ。Nicira の代表も結構いける、みたいな感じで、解決する技術はありそう。クラスタリングとかで負荷分散みたいなのが中心になっていくのでは。
  • Linuxみたいなコントローラを、という話。Linuxもその前、Unixとかだとベンダ主導なところとかがあったり。今のところあまりそういう動きが見えてこないが、何かそういう働きかけとかあるのか?
    • この後の話で。
  • 触ってみたいがモノがない。会社で買う予算もない。個人が自宅で検証できるような、そういう情報とかソフトウェア上で実装してどこまでできるか?
    • コントローラ縛りで言うと Trema simulator で仮想ネットワークはくめる。OVSが対応しているのでそれで実験するというのはできそう。コントローラは自作してみるしかないかな。
  • これ使うとして、ネットワークのヘッダの話とか知らないといけない。アプリ作ってる人が簡単に作れるかというとすごく乖離があるのではないか?
    • プログラムが書けてネットワークにも詳しい人、が中心になっていくのでは。OpenFlow みたいに抽象化されていくと、個々のパケットが単なる識別子みたいに扱えるので、従来のネットワークプロトコルとは切り離された論理的プログラミングとして語られていくのではないか。
  • 前にB社と話をしたけど、OpenFlow でこんなにわいわい言ってるのは日本だけ。なんでそんなに? と彼らは言ってる。でも IPv6 もそうだったよねという話も。日本で言いはじめて3年後にわいわい言い出すんじゃないかなと。Early なんだけどこれからどうなのかな、と。VXLANとか代替のものがありそうだけど、現実的には OpenFlow が一つ抜けてそう。そのへんどう?
    • パネルで!

OpenFlowコントローラを取り巻く状況とその実装(清水)

OSSコントローラとその特徴、Java実装のものの話について。

OpenFlowの構成

  • switch -- controller -- application

OpenFlow Switch

  • ソフトウェア
    • reference implementation (stanford)
    • OVS
  • ハードウェア

OFC

  • OSS
    • NOX, Trema, Beacon/floodlight, Ryu, NodeFlow...
  • 商用
    • NEC, Nicira, BigSwitch(floodlight), Midokura, NTT Data


NOX

  • GPL3, Nicira 主導, C++/Python
  • 最も歴史がある (stanford キャンパス内で使用)
  • 最近、開発が停滞気味?

Trema

  • GPLv2, NEC主導, C/Ruby
  • フルスタック: 1台のPCで開発が完結
  • 簡潔な記述でアプリが作れる(ruby)

Beacon/Floodlight

  • Beacon → fork して floodlight
  • Beacon(例外条項付きGPLv2), Floodlight(Apache license v2)
    • 例外: 本体はGPL2, 上のアプリはGPLじゃなくてもよい(決められたOSSライセンスで配布)
  • beacon → stanfordの人, floodlight → BigSwitch
  • 非同期IO, High performance (beacon:600M flow req/sec): でも実際試したら10分の1くらいだったのでどうなのか?

Ryu

  • GPLv3, NTT(サイバーソリューション研究所?) + VA Linux, pure python
  • OpenStackとの連携

NodeFlow

  • MIT license, gary berger, javascript(node.js)
  • 詳細わかりません

コントローラ関連の動向

NEC --+-- trema(OSS)
      |
      +-- UNIVERGE PF(商用)

BigSwitch -- floodlight(OSS) -- BigController?(商用)

Nicira --+-- NOX(OSS)
         |
         +-- NVP?(Nicira Virtualization Platform) (商用) (ステルスなので謎)

今年のニュース

  • floodlight のリリース
    • 12月後半にソースコード公開
    • beacon からフォーク
      • ライセンスが違う
      • OSGi(動的モジュール管理機構)への依存除去(モジュールシステム実装中)
      • Nettyを使用するようになった
    • アプリ募集中→Tシャツプレゼント中
      • patch pull request だしたらすごいまともなのがきました

Nicira の動き

  • 2月にステルスを終える予定
  • NTTと共同でライブマイグレーション実験(2011/8)
  • Nicira Virtualization Platform (NVP) (TED)
    • 詳細は不明
  • Onix
    • OSDI'10
    • OpenFlow 分散コントローラの論文(Nicira, Google, NEC, UC Berkeley)
    • 分散コントローラ
      • Zookeeper を使用して実装

Onix

  • Distributed controller -- NIB -- application
  • NIB(Network Information Base)
    • ネットワークのステートはグラフで表現
    • アプリ特性に合わせたDB
      • 一貫性、レスポンス、…くみあわせ
        • Transactional Persistent DB
        • DHT key-value store (cassandra?)

OFCの実装

  • 動作
    • メッセージの切り出し
    • ハンドシェイク処理
    • コネクション維持
    • スイッチから送られてくるメッセージへの応答

OpenFlow Message

  • Symmetric message
    • どっちからしゃべってもいい
  • Contoller/Swich message
    • コントローラをトリガにする
  • Async message
    • スイッチのイベント、スイッチをトリガにする

メッセージの切り出し

  • length を読んでメッセージを切り出す
  • Netty: LengthFieldBasedFrameDecoder
    • floodlight ではつかっていない

Floodlight でのメッセージ処理

OpenFlow のバージョンと実装について

  • OpenFlow 1.1 が公開されているのが最新
    • ただ、ほぼすべてのコントローラ実装が 1.0準拠
  • v1.1 以降はハードウェア実装が難しいと言われている
    • Multiple table の実装が難しい。いま知る限りは1.1準拠がない
    • OFSがないのでOFCがない
  • v1.2 公開
    • コントローラ実装はどうなるか??

さいごに

QA

  • OpenFlow 1.1、マルチプルテーブルってどんなものなのか、それがないことによって何が問題なのか。v1.2になってipv6対応ができてブーストするのかと思ったがスイッチがないと困るね。
    • マルチプルテーブル、OpenFlow 1.0 まではフローテーブルは1つだけ、そこにマッチしなければ packet_in とか1段の処理だけ。1.1からは複数用意して、1つめのテーブルにマッチしなければ次のテーブルへ、みたいなカスケードができるようになっている。
  • 分散コントローラ対応のためにそういうことをしている? なんでカスケードしないといけないのだろう?
    • そこはちょっとよくわからない。
  • マルチプルテーブル、ハード作るの難しいのはわかるが、ソフトウェアのほう(OVS)だとどうなのか。
    • OVSの中身詳しくないので…。たしかOVSだと1.0+some extension みたいな感じの記述だったとおもう。その some に含まれているかはちょっとわからない。
  • スイッチの仮想化…スイッチのソフトウェア化、ハードウェアコーディングみたいなのはなくなっていくんじゃないかな、というのが感想。
  • コントローラの調査してみてる。運用に使えるような機能を最初から持ったコントローラってありますか? フレームワーク型が中心で、機能はプログラマが作ってね、というのがほとんどだと思うので。
    • コントローラの上で乗るアプリがたくさん用意されているわけではない。なので floodlight もそのあたりが欲しくて Tシャツ配ってるのだとおもう。

パネルディスカッション

(筆記者註: 発言者氏名までちゃんと追えていませんでした…。というかパネラ氏名はあとでWebで確認しようとおもたら全員分は記載がなかったという。途中追い切れなくなってぐだぐだなのでいろいろ間違えてるかもしれないです。)

  • パネラー
    • (ismt): 石光 (司会)
    • (myst): 宮下
    • (kato): Midokura 加藤
    • (cupa): CUPAの方 (名前記録もれた…)
    • (smz): 清水
    • (tkd): 日立Sol たけだ (飛び入り)
    • (smsk): Orca Networks しまさか
Toward the next generation network in the era of cloud computing - SDNの1つの解 MidoNet -(Midokura/加藤)

SDN

  • 古くて新しいネットワークの概念: ソフトウェアでネットワークを制御
  • 何が変わる?(Nick McKeon)
    • ネットワーク運用者に自由を、イノベーションの加速、新しいプレーヤーの登場、強固な土台
  • OpenFlowは、この概念を実現するspec/proocolの代表格
  • Midokura は OpenFlow どうこうじゃなくて、SDN。

Midonet

  • OpenFlow 技術を利用
    • OVS, OpenFlow, Zookeeper(変わるかも) とかも使ったり
    • 技術的には OFS と組み合わせたシステムを構築可能に

Midonet 現在と未来(目標)

Midonet Benefit = SDNの目標

  • 物理からの分離、自由なネットワークトポロジ・サービス設定・変更
  • 冗長化: コントローラの分散。
    • いまはZookeeper, コントローラも分散・クラスタ
  • マルチテナント、必要なときに即座にテナントの増減
  • IPとかに制限はかけない。既存の設備の有効活用、物理・仮想のハイブリッドシステムを構築可能に
  • 必要なときに必要なだけスケールアウトでシステム拡張
    • 実装は x86 linux なのでサーバ増やせばいい
  • VMとの Orchestration
    • Openstack nova support, そのほか CloudStackとかも
  • APIで集中管理システムを実現、運用コスト最小化

OpenFlow は仲間で一緒に拡大したい。OpenFlow も重要だと思っている。OpenFlow++ くらいか。いまあまり情報公開していない(単純に手が回らないので)けど、OVSコミュニティにも OpenStack にもいるし、ONF にもいるので。

パネルディスカッション
  • () Midokuraはクラウドの上のアプリケーション(LBとか)も一体化して出してる?
    • (kato) そこは聞きたい。LB/FWって既存の機器があって性能はすごくいい。ソフトウェアでもある程度やれる。ハードをクラウドで使うとして冗長化の問題とかがある。ユースケースによりけりで、どのレベルのところでどのくらいにすべきなんだろう。
  • () OpenFlow で L4、FW/LB もできる。ただしアプリケーション側、コントロールフレームワークの実装だと思うけど、他のソフトとかアプリってどういう状態でやってるのか?
    • () 一般的な OpenFlow Whitepaper の受け売りだけど、コントローラでもそういう仕組みはできる。一方、性能とか機能とかで問題になるという話があって、道が二つくらいあるだろう: ハードウェアと連携/仮想アプライアンスとの連携。いまのクラウド導入顧客の感触でいえば、ソフトだとSSLアクセラレーションあたりでネックになるので、ハード使いたいという人が。物理FWおいてマルチテナントやるというのは実際にある。
    • (tkd) ネットワーク製品(Juniperとか), FW/LB distribution/marketing している。世の中的にはまだうやむやだと思う。JuniperとかだとFW(というよりSecure Router)で取り込んでいこうという話とか。Ciscoも違う表現で似たような話、セキュリティを取り込んでいこうという動きはある。いまユーザからすると、LBはアプリに近い、セキュリティはまた別もの、それとはまたネットワークがあるという状況。ややこしいけど、アプリとセキュリティとネットワークの管理は全部別というのがキツイ。ただ全部まとめてやれるとしても、それ全部できる人もいないけど…。規格が統一されてうまくまとめてやれるようになるといいなあ(ベンダロックインを避けるようにしながら)。
    • (kato) 統一されるメリットはある?
    • (tkd) 現状、管理できてるようで実はできてない。物理構成と仮想・論理構成が全部別でどれが正しいかわからんという状況なので、ないといけない。けどなかなか難しくて放置されてるところが…。
  • () OpenFlow でうれしいと思っているところ: Broadcast分離…いまVLANしかない。いままでL2細かく切ってセキュリティ担保だったんだけどそれを大量に持つのがネック。OpenFlow であるユーザのブロードキャストを定義して提供できないか。あるユーザのセグメント、FW/LB ほしい、といったときに、VLAN気にしないで環境を定義できないか、という期待。ユーザごとの識別だけできて連携できたら。
    • (kato) 我々が考えているのはそういうところ。やりたいこと、サービスのカップリング、あまり細かいこと意識しないでできるようにしようよ…というのが Midokura が考えている実装。

ML上で集めた意見について:

OpenFlow/SDN つかったときに既存環境の棲み分けどうする?

  • (smsk) なんでも OpenFlow でやろうというのはしてない。導入提案のときとかは分けざるを得ない。業務LANと管理LANを分ける: 管理LANは別なL2を入れる。OSPF/Routing考慮がないというのがあるので、境界L3をたてて OpenFlow Network と既存のネットワークという作りにするしかない。FW/LBについても、一度そこを通るフローとその戻り、という設定。今の時点ではまだ使いにくい。夢の技術では全くないので、幻想は捨ててね。
    • () 自動でなんかやるじゃなくてStaticとかでふる?
    • (smsk) そう。
  • (cupa) 境界は重要。そこをstaticでやるとSPoFになりそうなので、何らかの動的制御がやれたりする?
    • (smsk) いまのところ、製品機能要望をあげたり改善されたりするのを待っている。
    • (smz) もともと OpenFlow は Clean slate project がベース。既存のネットワークとの inter networking とかあまり考えてないんじゃないかな。既存とのつなぎは課題だと思う。いまのところ、まっさらな環境にゼロから入れる、というのがわかりやすいユースケースだろう。
    • (kato) まだ我々もできていないが、OpenFlowとイコールではないです。対応しているだけで、マルチプロトコル。それは既存の環境とのマイグレーションを意識しているから。そこは既存環境とのパートナーシップを結んで話を進めていくことになりそう。アーキテクチャ上複数にしているのは、OpenFlow だけだと完全にまっさらになっちゃうから。
  • (myst) いまのところ分かれてしまって、せいぜいL3で境界作るしかない、というところですね。
    • (会場) あまり OpenFlow と既存環境の融合とかやらないんじゃないかな。マイグレーションはあまり問題じゃないのでは。OpenFlow も VXLAN もオーバーレイネットワークだよね。ベースになるネットワークを誰も議論していないのはどうなんだろうか。OFC/OFS の通信って誰がどう作るの、という議論は? そこにまやかしがあるような気がしている。既存ネットワークとのマイグレーションと言うより、そこをどういう管理にするのか、というのが絵に描いた餅なんじゃないか。B社の話もだけど、スイッチ会社はその辺見ている。スイッチ作るところはあるけどコントローラ作るってところがなかなか出てこない。オーバーレイ作るところに解があるのか。Midokuraさん、いつも何をしているんだろう? 中身もうちょっと技術の話出てこないかな。
    • (kato) 具体的な企業名はいえないけど、POCで日本のキャリアとか始まるし、海外のキャリアも始まってる。そもそものネットワークどうするかという話であれば、いまは、OpenStack とやってコモディティサーバ用意してもらってfabricみたいなかたちになってる。我々はサーバの上でスイッチ・ルータ動くけどリソース食うから OFS にして切り出したい、Stackable なかたちにしよう…で、いくつか実験はやり出している。
    • (ismt) OpenFlow ネットワーク、業務LANと別に管理LANが必要になる。OpenFlow って管理LANについては規定しない。そこは問題だろう。ただ、v1.1仕様書、管理LANでも自動ディスカバリみたいな記載があった気がする。やがては管理LANレスな世界、自動ディスカバリとかやっていくのではないかと思う。
    • (tkd) ベンダ側の話、OpenFlow の幻想みたいな話があったけど。上から下まで OpenFlow ってことはまずないと思っている。オーバーレイにするのはいいと思っていて、いいところを見つけてそれが標準になったらよいのでは。OpenFlow 使って BCP の観点、東京-大阪のスイッチが一つに見えたら DR とかすごくやりやすいよね、みたいなユースケースあつめて、オーバーレイとか実現するノウハウためて、そういうのが実現できるようにならないかな。という位置づけで考えている。
    • (kato) マルチサイトの議論。みんなマルチサイトでやりたい。作れるけど、リアルタイムフェイルオーバとか、DR は単にバッチでやればいいのか、とか、要件いってくれないと。無限にはできない。ユースケースはとても知りたい。それがわかれば新しい SDN もマッチしたところでうまく使っていくというのができる。どこなのよ、というのはすごく知りたい。マルチサイトで何でもできるというのではないよね(将来的にはわからないけど)。
    • (tkd) FO/DR, 誰もやったことがない。作るのは作るけど、やっちゃうと大事件になるので誰もやらない、というのが一番大きな問題。USとか災害大国なので、東部・中部・南部各地の DC を2週間ごとに FO しながら使ったりする。US は動いて初めて冗長化実装をしているとみなす。日本では、できますというだけでじゃなくて、ちゃんとやっていくことが重要。やって初めてわかる。WAN ごし FO って 60% は FO 失敗するって、そのくらいのものらしい。そういうところやってつぶしていって初めてやれる。日本はどこもやってないので、そういうところから変えていかないと、見えてこないんじゃないかな。
  • (smz) FOできないのは帯域とかの問題?
    • (tkd) 詳しくはわからないけど LAN と WAN はどうしても遅延とかいろいろと違う。どうしても元々想定していたスペックとか仕組みがうまく動かなくなるというのがあるらしい。
    • (kato) DC間をMPLSとかで性能保証してマルチスライスネットワークとかやるとそこらがみえるとできるんじゃないか。ただ、どう使いたいかが見えないので困ってる。
    • (smz) 帯域、光ネットワークだとパケット交換が非常に難しい(光はバッファに入らないから)。有効なのは回線交換タイプに戻すことじゃないかとか研究してた。ダイナミックに光のパスを張る。そういうのができたら、WANごしの問題は減るんじゃないかな。ただ、先 1年2年 の話ではないけど。
  • (cupa) DR/BCP の話は大きな課題。マルチサイトでマイグーションは BCP 上必要。ただ、ライブマイグレーションって本当に必要? DCいかれたらライブマイグレーションできないよね。DC間のところ、OpenFlow が本当にいいの? MPLS/GMPLS とかとの連携が良いのかとかは気になる。
    • (会場) SE的に、一番問題なのはストレージ。TBオーダーの移動ができない。距離、IO遅延の問題。そのあたりをどう回避するか。離れたところは OpenFlow とは関係なく難しい。
  • (会場) 使う側からすると、インターネット越しでクラウドつかってる。国(region)違いで、IP違うから経路が違う。Mobile IP とかで吸収するようなのがないと切れるけど、その辺 OpenFlow でどうにかできたりする?
    • (cupa) IPアドレスにはモビリティはない。なので、ライブマイグレーションとかで移動するならIPも持って行きたい。DC間が OpenFlow でつながっていて、IP持って行けるととてもうれしい。ただ現実的にできるかはわからない。Mobile IP でやるというのは 1つの解としてはあるだろう。
    • (smz) ひとつは巨大なL2を作る(スケールするか)。ただそれってどうなんだろうね…
    • (会場) IPって経路情報を内蔵している。OpenFlowって IP情報の構造に関係なく転送できる。IPが変わると困るよね、というのはルーティングできないから。ルーティングできればいい。となると巨大なL2なのか、という話とか…。頭を変えないといけない技術なのだろう。今までのルール、IPでルーティング頑張れというのから変わるイメージがある。
    • (kato) はい。IPをいじるのはマイグレーションだけじゃなくて、そこ意識することなくやれるような環境を作りましょうというのは考えている。ただマルチサイトになると、キャリアと一緒にやらないといけない世界が出てるかなあ。L2までかL3までか、ユーザによってちがうので。ユースケースが見えないので実験がまだできていない。技術的にはIPをポータブルにする、というのは SDN のいいところだと思う。
    • (cupa) IPのモビリティはアプリケーション依存。GSLBだとか単純にDNSで対応とか。アプリの要求によるけど、IP変えないでそのまま使えるのはユーザには理想だろう。ただ、ルーティング的な部分は課題がある。
    • (会場) 可能かどうかわからないけど、IPとTCPをレイヤ切り離して考えて、TCPだけ引き継いでいけるという実装があるとおもしろいのでは?
    • (cupa) それはクライアントの実装から変えないといけない。IP/Protocol/Sessionもってるので。それやるのであれば、サービスの前にでっかいNATとかいう構造に。おもしろいところだけど難しいな。
    • (smz) インターネットそのものが大きなスイッチに見えたらいいなと。実際はそうじゃなくてユーザがいろいろ設定しながら使ってるけど、挿せば使える、というのが理想だろう。Internet as a switch みたいなのができる研究がしたいな。
    • (会場) L3/L4分割の話、IETFでは Name based sockets というので、sockaddr_in でやらないで名前でやって分離しましょうという話はあった。ただ、プログラミングモデルの互換性どうするかなという問題がある。IPの問題も、OpenFLow はL2も見る。結局IPから ARP 解決やってるので、そこがネックになってる。OpenFlow は Flow: L3 でやれたらいいじゃんと思うけど、下をハンドリングしているのが Ethernet なのでそこがしっくりこないかなというところはある。
    • (会場) 結局、7階層の話、プロトコルの話、セッションが保てれば層はどこでもいい。でも層をわけないと責任範囲がわからない。歴史的には分業で成功した。OpenFlow は7階層自体を見直してみようみたいな議論になっている気がする。そこの議論、セクショナリズムに走ると不毛になりそう。
    • (smz) OSI階層モデルがいいのかというのは、新世代ネットワークとかで議論されてる。実際、ネットワーク使うこと考えると、OSにプロトコルスタックが乗らないといけないとか、そこまでリーチできないといけないのが難しい。
    • (会場) 使えるものじゃないと意味がないというのがネックだよね。
    • (cupa): えらい昔の話までもどりましたねー


非機能要件の対応状況について

  • (会場) OpenFlow でロギング(OFC/OFS/Traffic/ACL/Flow代替?)はどこまで仕様に入っているか、運用するに当たってどこまで使えるものなのか、今わかっている範囲であれば。
    • (smz) 仕様にはそういったことは一切ない。統計情報くらい(フローテーブルに基づいたカウンタくらい)。スイッチの動作とかステートとかは、実装依存だと思う。
    • (smsk) N社についてはログの機能がある。L2とかL3のログ、全部はとりようがないしすぐ流れる。1つの通信に対していくつも Flow を作るので、その情報が全部出る。検索することはあるけど、機械自体ログがあまりとれるものと思わない方がいい。syslog とかで別出しする運用になるのだろう。
    • (smz) Packet capture とかなら可能だろう。
    • (会場) そのへん全部実装依存?
    • (smz) …になるとおもいます。
  • (myst) 性能・冗長性・セキュリティについては?
    • (smsk) PFは導入検討で考えてはいる、現状のPFについては、コントローラで管理できるのが今25台(フローの数から台数を逆算)。フロー数の制限がある。50万フローとかそのくらい。コントローラ冗長としてはAct-Stbまで。今のところ大規模ネットワークを作れるわけではない。今後、センターまたぎとか拡張の部分を検討しているという話はある。
    • (会場): PFはコントローラでフローをしっかり管理しているから50万フローというのはそのへん。作りの問題で、管理きっちりしているはずなので、その辺の作りによるのではないか。
  • (会場) セキュリティ、コントローラへの攻撃、コントローラとスイッチ間の認証、フロー情報乗っ取りみたいな話とかは?
    • (smz) OpenFlow プロトコルでは、スイッチ - コントローラ間は SSL/TLS なのでそこで担保。実際、SSLでセッションはっているかというと floodlight はそこはなくて、TCP の普通のセッション。BigSwitch は要求きてないから優先度高くないとのこと。スイッチがSSL 対応させる機構がないという話があって、そこが問題なのでは。
    • (smsk) 現状の構成としては、そこで管理ネットワークを分離するというところに持って行くしかない。業務とは別に管理作って、そこのセキュリティはしっかりしてね、ということ。
    • (kato) 実装は違うかもしれないけど、Midonet はサーバ側で動かしちゃうから。POCやってる人たちは、1000台2000台がサーバとしてぶら下がる。コントローラとかはクラスタ化されるので、複数台クラスタして FO できる。エッジにキャッシュおいて全部コントローラにいかないようにとか。クラウドにあった OpenFlow(SDN) を作ろうとしているので、すごい台数動かして、完全に冗長化できるアーキテクチャにしている。
  • (会場) セキュリティのところ気になるの、DoS があうと思う。Nessus やるとコントローラ死ぬとか。そういう対応は OpenFlow 側ではどうしている?
    • (tkd) セキュリティの議論、OpenFlow がそこまでやらなきゃいけないのかな、という話はある。 OpenFlow も FW のステートフルインスペクションみたいな機能を別にいれることになるんじゃないか。規格ではなく。
    • () OpenFlow Fプロトコルは、わからなければ捨てる・聞きに行く、両方できる。わかっているもの以外は捨てるというのもやれる。
    • (kato) コントローラはひとつ死んでも他のでぐるぐる回す。スイッチ側にインテリジェント機能おいて全部問い合わせ行くというのはないから、そこでセキュリティ機能担保している。あとは L7/FW とかまでどう入れるかとか、ハードウェア含めた実装どうするかの話(今後だけど)。OpenFlow は、L2-L4 フロー定義しますよ以上のことは特にないはず。
  • (cupa): コントローラの冗長、Zookeeper が一般的だけどそのほか何かないのかな?
    • (smz) Zookeeper が多い。Niciraの求人は Zookeepre/Cassandora だった。Floodlight でつかっている DB は Cassandra とある。


SDN時代のビジネスモデルについて

  • (cupa): ビジネスの課題クリアできないと世の中に広がらない。そのへん、モデルとして Midokura さんがどう考えているのか、他のベンダさんがどう考えているのか。
    • (kato) いままだ考えている最中です。結局、導入したときに CAPEX/OPEX どうするかとか言う話が見えてこないとあまり価格付けできない。ライセンスモデル、ライセンスどうするか、従量課金もあるし、やりかたはいろいろある。Nicira は Virtual Port 単位で月額課金とか? (高いよね) いま Midonet は OpenStack ベース、何台 Midonet インストールするかみたいな感じで、サブスクリプション・台数あたりでやろうとしている。
  • (会場) 話のレンジ、DC あたりだと思うけど、一般企業の中に OpenFlow が入っていくのは想定の外なのか内なのか。想定があるとしたら時期とか、そういうイメージは?
    • (smsk) 事例として日本通運、海外のDCあたりか。金融分野で入れる検討もあるらしい。OpenFlow 簡単ですよ、何でもできますよ、みたいな売り方あるけど、設計がすごく面倒でちゃんと考えて作るのが大変。入れた後、管理運用、入れた先の情シス要員でできるから管理コスト下がるよ、みたいに言うけど、ネットワークエンジニア的には保守費用とかメンテ費用とかもらいにくくなるという問題が。OpenFlow 製品を本格的に売ろうとするなら、次から次にそういう案件持ってこないといけなくて、そういうのは現実的には無理だなとは思う。
    • (cupa) PFの価格・ライセンス体系とかは?
    • (smsk) いますぐには回答できません。コントローラとスイッチ、本体価格、出てるとおり。あとはボリュームディスカウントとかはあるか。
    • (tkd) Midokura が狙いたいのは最終的にはエンタープライズ。ただ、今はインターネットとかホスティングで、大規模なところ、クラウド向けになっている。エンタープライズはやりたくて、1つ SaaS のところはある。まだ価格体系はできていない。オンプレミス DB とかはいじらないで、コストがかかる Web・AP、ネットワークがボトルネックになっているところを解決するようにしてとか。
    • (smz) 企業内に OpenFlow がどのくらい入るか。SDN のメリットはダイナミック性。それが企業に入って活きるかというと、働き方みたいなところによる。ダイナミックな働き方ができないんだったらあまり入れる価値ないのかな。あとパブリッククラウドプライベートクラウドかという話、パブリックでやります、そこまでつながればよいです、でよいなら SDN で規定するダイナミック性は必要ないのではないかな。
    • (tkd) 製品ディストリビュータSIerの立場から。SIer からすると、DC とかはもうかるのでそちらから進んでいくのじゃないかな。エンタープライズに広まるのは3年とか先じゃないかと思っている。そのためにはセキュリティとか運用管理の話とかが解決されないと。日立だとJP1とかで、サーバもネットワークとかも垣根をなくして全部統合管理できるような仕組みができればとか。そういうのが 3-5 年後なんじゃないかな。
    • (kato) USと日本はたぶん違う。アーリーアダプタとして IDC としたけど、US で話があるのは、US はエンタープライズが DC を持っているので、そちらで話がきている。すごく大きな規模の環境で SDN とか。それは言い方を変えればエンタープライズ。そうじゃなくて、自社内にIT部門持たずに、業務系ネットワークにSDN入っていくかというのはある。ユースケース出てくるのは3年以降とかじゃないか。
    • (ismt) NTT Comm は2012年とか。通信事業者としての期待は、DCでライブマイグレーションBCPとか。あとセルフプロビジョニング: ネットワークの帯域変えたり。いま申込書書いてとか時間がかかるのが、自分で簡単に設定変えられると顧客向けに意味がある。通信事業者としてはそういうところだろう。
    • (cupa) ビジネスモデルとしては、ユースケースが一つのポイント。エンタープライズと DC ではケースが違うしUSと日本でもまた違う。ビジネスモデルについては各社いろいろ検討しているという段階。


IaaSとしてOVSとか耐えられるのか? サービスで使うとして開発とか運用とかどうか?

  • (kato) POC 動かし出してるし、開発もいろいろやってる。独自にやっていて Nicira vs Midokura みたいな状況。外側の動きは別。何千台規模の DC を動かすためのものとして、POC なので 100 台とかだけど、今のところ問題にはそれほどなってない。足りるかというと大丈夫だと思う。
  • (smz) 大規模環境で OVS やってないのでわからないけど、物理マシンに OVS + Agentみたいな構成とか大量のフロー入れるとか避けられる構造ならスケーラビリティの問題はおきにくいだろう。ただ、10GbEオーバーとかになると、CPUのロードとしてかかるのがきついので、CPU の仮想化支援機構とか、NICにオフロードされる機能とか、そういうのがないと厳しいだろう。
    • (kato) チップセットメーカーとも話をしてます。
    • (smsk) スイッチ速度の話、PF,10Gx2と1Gx48というのがベース製品。スイッチをまとめる用途で10G+40Gの製品が出る? 基本的には大容量データをやりとり、NASを束ねる、とかの用途には今のところまだ向いていない。そういうパフォーマンスは期待できない。
  • (会場:質問投稿者) この質問の理由は、社内クラウド構築やるというとき、OVS を検証環境でやってみて上にもっていくと「OVS? 何それ? だめ」っていわれて、どう説得したらいいのかと。競合・選択肢となるのって、OVSか標準のLinux Bridge とか?
    • () XenだとOVS標準なので、Xenっていえばいけるんじゃない?
    • () KVM だと OVS か Bridge module か。OVS は Xen 標準だから大丈夫とするか、KVMの Bridge Moduleと比較するか。
    • () 個人的にやっただけど。RedHat が新しく出すのがあるのだけど、それもOVSじゃないかな。KVM + OVS だと、マニュアルがほとんどないので、使ってみて何とかするしかない。エラーとか出てもよくわからん。わけわからないトラブルを避けるために、NICIntel にしておくのがよい。
    • (ismt) Linux kernel のソース、最新だと OVS がブランチに入っているので、今後標準になっていくんじゃ。たぶん、コアのカーネルモジュールはLinux標準の Bridge と同じだと思う。
    • (smz) あと上司対応でおもいつくのは、この会社に先を越されるのがまずいとか、あそこがやってますよ、と言うのがいいんじゃないかな。他の人が・あそこやってるのに、というので。

最後に

  • (kato) エンジニア募集してます。

LT

(筆記者註: LTはとってません)

5分で作れるクラウド型OpenFlowコントローラ(高宮)
Trema Sliceable Routing Switch の紹介(鈴木)

全体をとおして QA とかあれば

  • (cupa) Midonetとかできて企業展開されていくとき、展開時の設計から実装まで、いまのネットワーク技術者やサーバ技術者の持っているスキルセットとは違うものになるのか? 人材としてどういうリクエストがあるか?
    • (kato) 非常に難しい。Midonet がもし広がれば、ネットワーク機器ごとの違いがなくなっていく…というところを指向している。むしろより上のレイヤ、システムに合ったアーキテクチャをどう設計するか、というデザインのスキルセットが重要になるだろう。サーバやパソコンでホワイトボックス化が進んで、ミドルウェアとか上の方にスキルセットが移行したのと同じようなことが、ネットワークでも起こる。サーバの人が、これまではわからないからと言って放置していたネットワークのところに踏み出していける。サーバエンジニアとネットワークエンジニアの端境がなくなる。個別機器についてのスキルセットではなく、アーキテクチャデザインへのシフトが起こる。
  • (会場) いまネットワーク仮想化という流れの中で主戦場になってる。OpenFlow はメジャープレイヤーだろうけど、MPLS 関連の WAN 系とか VXLAN とか。どこら辺に落ち着くと思っていますか? それはいつくらいになりそう?
    • (suzuki) OpenFlow で DC やる流れが流行っているモチベーションは、大きなDC でベンダ供給の機能でコントロールできないというのを変えたい、というのがひとつあるだろう。DC、大きなところはベンダガ提供する機能に依存せず柔軟に制御したいというので OpenFlow がマッチしたのではないか。VXLAN とかそのほかのものについては個々に長短ある。どういう場面で、どのソリューションがマッチするかしないか、で棲み分けができていくのでは。後はベンダの力とかDCの力とかビジネスの力関係もあると思うので、なかなか読めない。
  • (会場) ベンダフリーの方向。いままでベンダの力が強すぎた。我々のユースケース、どう使いたいのか、と言うところ。こちらにコントロールが戻ってきたというのが楽しみ。
    • (suzuki) と思ってもらえると。そういうところやりたくて開発してる。目指すのはユーザが自由にやれる世界。ただ、プログラミングできないと、というのはあるけど。
    • (会場) 別にプログラムって書けばいいじゃん。そこ、そんなハードル高いもんじゃないよね。
    • (kato) DCを巨大に運用している人たちで、すでにサーバとかストレージの仮想化を進めている人は、ネットワークのボトルネックに直面している。ネットワークの柔軟性とかスケーラビリティとか担保しないともうどうにもならない。Zynga ではネットワークが問題に。需要に追いつけない。既存ベンダのだとコストがあわないしシングルポイントが。Google/Amazon だと自社の巨大センタやるのは、コモディティ化した機材で、その上でシステムを構築している。そういう技術を世の中に出していけば、というのは OpenFlow なり SDN のポイントだろうと。それがいつ来るのか、というのは正直わからない。巨大な人たちがニーズは持ってるけど、いま日本とかでどれくらいくるかは正直見えない。ただUS は急速に動いている。
    • (会場) USの人に言わせるとUSは冷えてて日本があついと言うけど、プレーヤが違うんだよね。