「OpenFlow勉強会その１」議論ネタ大募集
Kazuhiro MIYASHITA
CC: CUPA)荒井様
宮下です。
「OpenFlow勉強会その１」の再参加募集の呼びかけは別途行われる予定ですが、
先に、勉強会の中身をもう少し詰めたいと思います。
予定しているアジェンダは今のところ、以下のとおりですが、OpenFlowを
キーワードとして、何かネタを発表してくださる方はいらっしゃいませんでしょうか。
---------------------------------
前半：OpenFlow とはなんぞや(宮下：13:10～14:10(質疑応答10分を含む))
- ざっくりとした説明
- 何が出来て何が出来ないか
- 現時点での利用方法(Tremaについて)
- 簡単な実装例（拙作のTrema上のAPPの紹介）
後半：ノウハウ等の実践的内容とディスカッション(14:20～17:00)
- （未定）
---------------------------------
例えば、、、
・OpenFlowとソフトルータの組み合わせについてネタを持っている方
・コントローラを自作で作っているんだよ。という方
清水様＠個人に声をかけていただけるとありがたいです＞CUPA)荒井様
・OpenFlowの導入を考えている方
などなど。
個人的にはOpenFlowは非常におもしろい技術だと思っていて、今後、
どんどん広まって行けば良いと思っています。しかし、キーワードだけ
先行しているので、この技術を実運用で使用するためには、
何が足りないのか？などを、ディスカッションしたいと
考えています。
以上です。
Yasuhiro Arai
> ・コントローラを自作で作っているんだよ。という方
> 清水様＠個人に声をかけていただけるとありがたいです＞CUPA)荒井様
はい。了解しましたー
コントローラで実装する機能とその実装方式は
非常に重要なポイントとなりますので、是非活発な
ディスカッションの場になることを期待しております！
2012年1月14日0:17 Kazuhiro MIYASHITA <miyak...@gmail.com>:
Kazuhiro MIYASHITA
宮下です。
先のメールでは、ネタの発表者を募っていましたが、
同時に、議論ネタも募集したいと思います。
OpenFlowについて～な事を議論してみたい。
という事がございましたら、ぜひ、教えてください。
ディスカッションの中に組み込みたいと思います。
以上です。
ISHIMITSU,Naoki
石光＠スタッフです。
思いつきですが、以下の点が気になっております。
・既存環境との棲み分け
⇒例えば社内ネットワークの一部にOpenFlowを導入する際に、既存ネットワークとの接続はどのように行うのか。
・非機能要件の対応状況
⇒性能や冗長性、セキュリティなどなどどこまで検討進んでいるのか。
＞皆様
いかがでしょうか？
2012/1/15 Kazuhiro MIYASHITA <miyak...@gmail.com>:
--
石光直樹（ISHIMITSU,Naoki）
ishi...@gmail.com
yamada...@gmail.com
石光さんに賛成です。
加えて、物理スイッチ/仮想スイッチと言う観点はいかがでしょうか。
物理スイッチはまだ先の話と思いますが、
すぐ使えそうな話として、IaaSの仮想スイッチにOpen vSwitchは採用に足るのか？
ラボではない開発・運用がどれくらい大変か？と言う辺りが気になっています。
2012年1月19日0:22 ISHIMITSU,Naoki <ishi...@gmail.com>:
Kazuhiro MIYASHITA
宮下です。
素晴らしい議論ネタ提供ありがとうございます。
そういった発言を待っていました。
> > ・既存環境との棲み分け
> > ⇒例えば社内ネットワークの一部にOpenFlowを導入する際に、既存ネットワークとの接続はどのように行うのか。
OpenFlow Switch Specification 1.1.0の中でも、既存ネットワークとの接続について
触れられています。その点について、少し発表に組み込むのと、
ディスカッションの場でも取り上げて、議論の対象にさせて頂きます。
>
> > ・非機能要件の対応状況
> > ⇒性能や冗長性、セキュリティなどなどどこまで検討進んでいるのか。
おもしろいところです。
セキュリティについては、OpenFlowで決められているのはContorller-Switch間の
セキュアチャネル程度かなと思っていまして、その他の観点のセキュリティ、冗長、性能
などについて、如何にController側で機能を作るか、運用させるのか、というところが
決め手になると思います。
同様に、ディスカッションの場でも取り上げて、議論の対象にさせて頂きます。
> 物理スイッチはまだ先の話と思いますが、
> すぐ使えそうな話として、IaaSの仮想スイッチにOpen vSwitchは採用に足るのか？
大変興味深いところです。
open vswitchはlinux-nextにはすでに組み込まれているようで、かつ、
Open vswitch自体がOpenFlowを意識して作られているように見えます。
今後、Linuxの標準機能として定着するため、採用していく企業は増えて
ゆくのではないでしょうか（楽観的な推測）。
※linux-next
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> ラボではない開発・運用がどれくらい大変か？と言う辺りが気になっています。
これもどうなんでしょう、上記と合わせてディスカッション参加者にも聞いてみたいところですね。
ディスカッションは二時間もあります。内容を充実させるために、どんどんネタを
ください。
以上です。
On 1月19日, 午前2:10, yamada.hid...@gmail.com wrote:
> 山田@Jinmen です。
>
> 石光さんに賛成です。
> 加えて、物理スイッチ/仮想スイッチと言う観点はいかがでしょうか。
>
> 物理スイッチはまだ先の話と思いますが、
> すぐ使えそうな話として、IaaSの仮想スイッチにOpen vSwitchは採用に足るのか？
> ラボではない開発・運用がどれくらい大変か？と言う辺りが気になっています。
>
>
>
>
>
>
>
> > 宮下様
>
> > 石光＠スタッフです。
>
> > 思いつきですが、以下の点が気になっております。
>
> > ・既存環境との棲み分け
> > ⇒例えば社内ネットワークの一部にOpenFlowを導入する際に、既存ネットワークとの接続はどのように行うのか。
>
> > ・非機能要件の対応状況
> > ⇒性能や冗長性、セキュリティなどなどどこまで検討進んでいるのか。
>
> > ＞皆様
> > いかがでしょうか？
>
D.N.
> すぐ使えそうな話として、IaaSの仮想スイッチにOpen vSwitchは採用に足るのか？
>Open vswitch自体がOpenFlowを意識して作られているように見えます。
Kazuhiro MIYASHITA
宮下です。
> よく、仮想化環境で議論になるのは「仮想スイッチの設計や運用ってサーバサイド？ネットワークサイド？」です。
サーバ管理者は「ネット」というキーワードが現れた時点で、拒絶してしまいます。
VLANなんて言葉が出てくると尚更ですね。
> OpenFlow環境だとどうなるんでしょうか？
変わらないと思います。ネット管理者の範疇でしょう。
> 余談ですが、自宅環境でopen vswitchをKVMに入れて使い始めましたが、慣れていないこともあり、ハマることが多いです。
> NIC（ドライバ？）との相性でうまくトランクされないことがあったり・・・
私もまだまだ勉強中ですが、何か力になれたら(or 互いの情報交換が出来たら)良いなと思います。
以上です。
> 皆様
>
> 中嶋です。
>
> > 物理スイッチはまだ先の話と思いますが、
> > すぐ使えそうな話として、IaaSの仮想スイッチにOpen vSwitchは採用に足るのか？
>
> さくらインターネットさんでは仮想スイッチにopen vswitchを使っていて、制御にOpenFlowをつかています。http://goo.gl/CkcYA
> ※さくらインターネットさんは先進的すぎて参考ならないかもしれませんが^^;
>
> よく、仮想化環境で議論になるのは「仮想スイッチの設計や運用ってサーバサイド？ネットワークサイド？」です。
> OpenFlow環境だとどうなるんでしょうか？
>
> >open vswitchはlinux-nextにはすでに組み込まれているようで、かつ、
> >Open vswitch自体がOpenFlowを意識して作られているように見えます。
>
> XEN環境ではすでにopen vswitchは標準で使えるようです。
> Open vswitchはNiciraさんが開発にかなり関わっているようです。ですので、OpenFlowは相当意識していると思います。
>
> 余談ですが、自宅環境でopen vswitchをKVMに入れて使い始めましたが、慣れていないこともあり、ハマることが多いです。
> NIC（ドライバ？）との相性でうまくトランクされないことがあったり・・・
>
yumano
初めまして、yumanoと申します。
思いつきでネタを投稿させて頂きます。
個人的に気になるのは、サーバのライブマイグレーションとの連携ですね。
NTTさんの昨年のニュースリリースを見る限り、Hinemosではすでに実現できてそうに読み取れました。
将来的にサーバもネットワークも同じ基盤で管理されていく気がしており、
OpenStackとかの連携とかも気になってます。(Midokuraさんあたりがやってそうですよね？)
そういえば、BigSwitchが彼らのコントローラーをOpenSource化しましたね。
http://www.publickey1.jp/blog/12/big_switchopenflowfloodlight.html
http://floodlight.openflowhub.org/
これでOSSのOpenFlowコントローラーは
Trema - Ruby/C
Nox - Python/C++
Floodlight - Java
NodeFlow - JavaScript
上記の4つでしょうか？中身とか全然見てませんが、追いかけている方とかいらっしゃいます？
これらの比較とかも面白いかもしれませんね。
勉強会の開催が楽しみです。
ではでは
2012/1/21 Kazuhiro MIYASHITA <miyak...@gmail.com>:
Yutaka Kumamoto
実際に規模が大きめのネットワークを構築していますが、openflowが実際の所実践導入できるのかどうかという所に興味があります。
現段階では難しい・・・というのが一般論のようですが、どこを改善していかないといけないのかなどの議論ができるといいですよね。
個人的には映像配信で1Gを超えるトラフィックを吐くような環境でストリーミング部分をスルーで接続してそれ以外の管理用ポートや、HTTPサービスなどはFWを通すというような使い方が実用的になればいいなと感じています。（10GしゃべることのできるFWとかいくらするんだって話なので。）
最終的には昨年のInterop tokyoであったようなDC間の大移動のための利用なんでしょうけどね。
話はそれますが、当日は遠方から伺う予定なので、募集開始等の日程がわかれば教えて頂ければと思います（切符や宿泊の手配等の事もありますので）
Kazuhiro MIYASHITA
宮下です。
書き込みありがとうございます。
> 個人的に気になるのは、サーバのライブマイグレーションとの連携ですね。
> NTTさんの昨年のニュースリリースを見る限り、Hinemosではすでに実現できてそうに読み取れました。
> 将来的にサーバもネットワークも同じ基盤で管理されていく気がしており、
> OpenStackとかの連携とかも気になってます。(Midokuraさんあたりがやってそうですよね？)
思います。VM管理ソフト(Hyper-V/VMware/KVMなど）が、OpenFlowコントローラにVMの
所在位置を知らせる必要があるためです。
現在のOpenFlow Switchspecification 1.1.0ではこのあたりは仕様外としており、
OpenFlowコントローラ作者がガリガリ作り込む必要があります。
面倒くさいなぁ・・・と思っています。
テストのために、VMホストを二つも持っていないので、KVM上でKVMのVMゲストをVMホストとして動作させて
その中にまたVMを起動する形で、この辺の動作検証してみようと画策しています。
> Trema - Ruby/C
> Nox - Python/C++
> Floodlight - Java
> NodeFlow - JavaScript
Beacon
Maestro
あとは、
Reference Implementation v0.1.2でしょうか。
(http://www.openflow.org/wp/tag/controller/)
> 上記の4つでしょうか？中身とか全然見てませんが、追いかけている方とかいらっしゃいます？
> これらの比較とかも面白いかもしれませんね。
追いかけられません（＾＾；
私はTremaしか使ったことがありませんが、Tremaは大変便利です。
rubyをサポートしているので、大変プログラムが書きやすくなっています。
また、シミュレータをサポートしているので、実機が無くてもテストができます。
Cとrubyをミックスできるので、パフォーマンスの良いものが出来そうだと
思っています。
以上です。
On 1月24日, 午前8:49, yumano <yuma...@gmail.com> wrote:
> 皆さん
>
> 初めまして、yumanoと申します。
> 思いつきでネタを投稿させて頂きます。
>
> 個人的に気になるのは、サーバのライブマイグレーションとの連携ですね。
> NTTさんの昨年のニュースリリースを見る限り、Hinemosではすでに実現できてそうに読み取れました。
> 将来的にサーバもネットワークも同じ基盤で管理されていく気がしており、
> OpenStackとかの連携とかも気になってます。(Midokuraさんあたりがやってそうですよね？)
>
> そういえば、BigSwitchが彼らのコントローラーをOpenSource化しましたね。
>
> これでOSSのOpenFlowコントローラーは
>
> Trema - Ruby/C
> Nox - Python/C++
> Floodlight - Java
> NodeFlow - JavaScript
>
> 上記の4つでしょうか？中身とか全然見てませんが、追いかけている方とかいらっしゃいます？
> これらの比較とかも面白いかもしれませんね。
>
> 勉強会の開催が楽しみです。
> ではでは
>
Kazuhiro MIYASHITA
宮下です。
書き込みありがとうございます。
On 1月24日, 午前10:29, Yutaka Kumamoto <kumamoto5...@gmail.com> wrote:
> くまもと(@hagane5563)です。
>
> 実際に規模が大きめのネットワークを構築していますが、openflowが実際の所実践導入できるのかどうかという所に興味があります。
> 現段階では難しい・・・というのが一般論のようですが、どこを改善していかないといけないのかなどの議論ができるといいですよね。
>
そうですね。
OpenFlow Switch Specification 1.1.0を一通り目を通しましたが、結構、仕様書の記述が甘いような
気がします。また、細かいところはReference Implementationのソースを見ろ。というのがスタンス、
また、実践しながら仕様を改善していく「アジャイルスタイル」な仕様決め方法なので、
OpenFlowの導入は十分な試験を経てからじゃないと危険な感じがします。
ただ、私見ですが、リスクと比較して十分な見返りはある魅力的な技術ではないかと思います。
> 個人的には映像配信で1Gを超えるトラフィックを吐くような環境でストリーミング部分をスルーで接続してそれ以外の管理用ポートや、HTTPサービスなどはFWを通すというような使い方が実用的になればいいなと感じています。（10GしゃべることのできるFWとかいくらするんだって話なので。）
OpenFlowのホワイトペーパーには、フローのマッチングはスイッチが既に備えている機能(CAM/TCAM)で
実装できるので、ワイヤレートが実現できる・・・と記載してあったような気がします。
この辺は本当にどうなんでしょう。わかりません。
また、スイッチが持つフロー数の限度もあり、IaaSなどでOpenFlowを使ったとすると、
どれくらいの規模のマルチテナントが実現で可能か。という疑問もあります。
>
> 最終的には昨年のInterop tokyoであったようなDC間の大移動のための利用なんでしょうけどね。
これはすごいですね。
>
> 話はそれますが、当日は遠方から伺う予定なので、募集開始等の日程がわかれば教えて頂ければと思います（切符や宿泊の手配等の事もありますので）
後ほど、正式な開催案内が出ると思いますので、お待ち頂けますよう、お願いします。
以上です。
D.N.
>> NIC（ドライバ？）との相性でうまくトランクされないことがあったり・・・
>私もまだまだ勉強中ですが、何か力になれたら(or 互いの情報交換が出来たら)良いなと思います。