ラベル TremaDay の投稿を表示しています。 すべての投稿を表示
ラベル TremaDay の投稿を表示しています。 すべての投稿を表示

2015年8月9日日曜日

Trema Day #7 Presented by APC に参加してきた

開催概要

他のかたのまとめ

感想

トレンドなのか、たまたまなのか、今回は無線関係のOpenFlowの話が多かった。 TremaがPure Rubyになったということで、いい加減、Trema入門します。 エーピーコミュニケーションズさんのすばらしい会場で、 懇親会まで準備いただいてありがとうございました！

OpenFlowで覚えるネットワーク

まとめると

ネットワークをあまり理解していない人に向けて、どのようにしたら 理解してもらえるか。どうやったらネットワークを理解している人を増やせるか という課題に対して、 Yellowケーブルなどのころからのネットワークの変化を OpenFlowを使って追体験することで、理解を深められるのではないか という 試み。

メモ

  • テクニカルな話ではない
− ネットワーク = コミュニケーションをする道具
  • 複数の人 で達成する
    • 情報のやりとりをやる
  • 必ず2点の「端点」がある
  • ゴール： 自分の頭の中にあるものが相手の頭の中になっている
    • 音声、紙
      • 日本語 とかいうルールがある
        • プロトコル
  • ネットワークのかたち
    • どんな情報を伝えるか
    • どこのだれに情報を伝えるか
    • 何を使って情報を伝えるか
    • メディア
  • mininet使うと簡単に試せる
  • 糸電話からLearning Switchへ
  • 同時に話すとCollisionが発生する
    • 共有メディアは人が増えるとしゃべれなくなる
  • 近代ネットワークの道
    • ブリッジ → スイッチ
    • スイッチになるとコリジョンが発生しなくなる
− スイッチにするには
  • KnownなARPテーブル
  • UnknownなARPテーブル → Learning Switch
  • よその部屋の人との会話
    • IPの話→Simple Router
  • L1とはL2というのを下から上に理解するといいのではと思っている
  • コリジョンドメイン、全二重と半二重、物理メディアの話は端よっている
  • OpenFlowを使おうとおもうと、面倒見る人がいない
    • ソフト屋

ニューTrema5つのポイント

まとめる

新しいTremaになった。 見た目は変わっていないが、中身はだいぶかわった。 OpenFlow1.3.4に対応し、Pure Rubyにして、 コントローラ連携がしやすくなって、テストフレームワークと ドキュメントが充実した。

メモ

  • OpenFlow1.3.4に対応
    • –openflow13 と足すとしゃべれるようになった
    • pioで対応
    • trema/pio を見るとわかる
  • Pure Ruby化
    • インストールが簡単
    • openvswitchを入れて、bundle install でできる
    • デバッグしやすい
    • pryとかでパケットインのところでそのときのスコープの変数とかが見える
    • pryだとmethodの補完もできる
    • show-sourceとかでmethodなので。
  • コントローラ連携
    • 既存のコントローラを組み合わせて高機能なコントローラを作ることができる
    • delegatorというのを使う
    • クラスの継承を使って機能を拡張するのも簡単
  • テストフレームワーク
    • テスト
      • INPUT とOUTPUTを定義するとできる
    • Cucumberでできる
    • Given When Thenでかける
  • ドキュメント
    • Cucumberの記述からドキュメントを生成するようにした
    ｰ その結果充実した
  • 協力のお願い
    1. バグ報告
    2. パッチのPR
    3. 新しいアプリ
    4. Trema本レビュー

OVS拡張の話(とPioの話)

まとめると

TremaのPacketParserであるPioに OVSで使われている Nicira拡張をいれたいという話。 Nicira拡張はOVSに限定されているが、 いろいろと使いやすいものがある。

メモ

  • PioはRubyのパケットパーサ実装
    • パケットのパースをするツール
    • パケットを作れるツール
    • PioがだんだんCoreの部分に近づいている
    • Pioの性能がTremaの性能に影響を与える
  • OVSのNicira拡張にいろいろと使えるものがある
  • OpenFlowのきついところ
    • 「Controllerに転送を書くんでしょ？」
    • 「そうだよ？」
    • 辛そう
  • 宣言的にやりたい
  • OpenFlow的にはpacket_inさせるな！というのが一般的だが。。
  • 簡単にかけます

QA

  • Q: Pioにいれるきがあるか？
  • A: 熟読してから決める(by @yasuhito さん)
  • Q: 使える実装はどれくらい？
  • A: OVSなら使える
  • C: 他のハードのスイッチはけっこうはまりそう？。
  • C: Nicira拡張なのでOVSなら使える

いろいろなデバイスでOpenVNetを動かしてみようとした

まとめると

OpenVNet(OVS, Trema, MySQL など)を 次世代携帯型データセンター(Android 2.x)で 動かそうと頑張ったが、そこまでいかなかった。。 という 死闘の記録。

メモ

  • Edge Overlayのおさらい
    • Hostに仮想Switchがのるタイプのネットワーク
    • OpenStack Newtronとの親和性
  • 次世代携帯型データセンター
    • rbenvでrubyのコンパイルが1日で終わる。
    • Tremaのコンパイルも1時間
    • rootをとる必要がある
    • けっこう辛い
  • デモ
    • OVS, Tremaはなんとか動いたが。。
    • 無理矢理アラインメント変更したから。。

Dive into wireless openflow!

まとめると

無線LANとOpenFlowについての考えは珍しくはないが、 無線LANベンダによって、ロックインがあるため、いろいろ難しい面もある。 Raspberry Piを使った実装のデモを使って、効果の説明があった。

メモ

  • 無線とOpenFlowの組み合わせは珍しくはない
  • 無線はいろいろわからない(見えない)
  • 今回作ったやつはラズベリーパイで動いている
  • 効果
    • 状態を監視できる
    • APの電波でどちらを優先するか などの制御ができる
    • デバイスごとの癖がわかる
  • 実装
    • Linux netdev = openflow portとした

QA

  • Q: 無線LANの標準はあるのか？
  • A: 標準にしてもいいがONFとしてどうなっているかはわからない
  • C: 個人的には標準化したほうがよいかという気持ちはある

「Lagopusで遊ぶ(仮)」 あらため「Lagopusで試すFirewall」

  • @hibitomo さん
  • スライドはNot Yet

まとめると

FirewallのACLをLagopusで実装してみる試み。 ポートのRangeを実装するところはLagopusなら力業で実現できる(はず)。 ちょうどLagopusが新しくなって動いていないが、すぐに直るはず。

メモ

  • ACLのポートレンジのところは、最大26万ルールにおさまる！！
  • Lagopus →100万ルール いける(はず)
  • priorityを気をつける必要がある

QA

  • Q: テストツールは？
  • A: RyuのテストツールでJSONをいれればできるので、これでいける？

(仮題)Dockerコンテナのネットワーク周りについて

まとめると

DockerではネットワークまわりがいまHot。 docker 1.8 experimentalではいろいろ遊べる。 RunCを使えば、dockerが入らないようなシステムでも コンテナを簡単に作れる。

メモ

  • Trema関係ない
  • いまDocker Networkに力入れている
  • コンテナの周りのツール いろいろある
  • きょうの話
    • libnetwork
      • コンテナのネットワーク
    • RunC
  • libnetworkの話
    • 言葉の定義
      • SandBox → コンテナのこと
      • Endpoint → vethとかのこと
    • libnetwork driverがdocker0作成したりする
    • libnetwork driver
      • bridge デフォルト
      • overlay VXLANでトンネルをはる
    • overlay driver
      • docker 1.8-experimentalから利用可能
    • swarmはいまはネットワーク周りまだ管理していない
    • consulでやっている
    • docker create network overlay のようにやる
    • docker service publish h1.test ってやる
    • service とIPアドレスが対応している
    • /etc/hostsに書かれている
    • network driver だとarpがこない
      • broadcastとかはdocker側で管理している
    • 今後はlibnetworkを中心に発展していきそう
  • RunCの話
    • ホワイトボックススイッチ
    • Cumulus Linuxなど
      • Debian 7ベース
    • dockerを入れるにはいろいろ問題があって。。
    • そこでRunC
    • Open Container Projectに準拠させた
    • dockerのような常駐デーモンがいない
    • docker export でtarにして、それをrootfsにして、そこでruncを走らせるとコンテナが動く

QA

  • Q: vxlanはdocker間だけ？
  • A: 現状はdocker間だけでしかvxlanは通信できない
  • Q: どうしてスイッチ上でコンテナを動かしたい？
  • A: スイッチ上でアプリが動けばいろいろやりたい。アプリの配置を簡単にしたい
  • Q: dockerのネットワーク切り替えはできる？
  • A: 一応できるけど、ホスト名では解決できない

LT

ぜんぜんかけていないので、あとで追記します。きっと。。

LT SDNに夢見た無線AP～

LT 無線LANコントローラーからSDNへの移行可能性と拡張性の模索

  • @SRCHACK さん

LT Lagopus 0.2

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2014年2月23日日曜日

Trema Day #5 に参加してきた

Trema Day #5に参加してきたので、メモしておく。

感想

TremaはOSSでがんばっている。 小さいところでも貢献したいと思う。(まずはVagrant周りとかでも)

今回は懇親会にも参加できて、楽しかった。 ネットワーク屋が多いが、いろんな分野にまたがっているので、幅があって楽しい。

概要

  • 2014/02/22 (土) 13:00-17:00
  • KDDIウェブコミュニケーションズ CloudCoreセミナールーム
  • atnd
  • ust

他のかたのまとめなど

■意外に違う Trema と Trema-Edge

  • 大芝さん
  • Trema-Edge使ってみてTremaと違うところ
    • Pio, Sinatra が手強い
    • 不具合系の回避策とか(2014/02/22時点)
  • Trema Edgeとは
    • OpenFlow1.3
      • OpenFlow1.3の違いは扱わない
  • 変わっていないところ
    • 起動
      • 違いなし
    • ハンドラ定義
      • 違いなし
        • ポート情報の一覧の取得のところFeaturesRequest/Replyでとれなくなっている
    • タイマー定義とかメッセージ創始とか
      • 違いなし
        • フロー追加はoptionに変更あり(OpenFlow1.3関連?)
  • 変わっているところ
    • パケットインのときのパケット情報取得
      • マッチ条件の名前が変わっている
    • PortStatusのポート情報受け取り
      • PortStatusがPortクラスを継承している
    • PacketOutでデータのみのパケット出力
      • PacketInに指定していないとエラーになる
    • Sinatraとの連携しようとしたときの振る舞い
      • TremaのLoggerがSinatraのモジュールのLoggerとバッティングしている
      • エラーがでない
    • Trema::Pioと連携
      • Trema-EdgeがObjectクラスのところで修正している
      • array?がtrueとかになってしまう
      • ワークアラウンドするとarpとかだせることまで確認
    • 便利メソッドの有無
      • send_flow_mod_add など基本的なところくらいしかない
      • port.up?とかport.down?とかできない
    • Statsメッセージについて
      • マルチパートメッセージになった
    • OpenFlow1.3関連でいろいろ変わっている
      • 割愛

質疑応答

  • Q. Trema-Edgeのテスト用のスイッチとか、ダンプフローとかどうなっている？
  • A. 会社ではOpenFlowスイッチがあるので、あまり使っていない
  • C. sugyoさんがやりかたがあるらしいという情報がある
  • C. なんかやったらできる記憶がある
  • Q. グループテーブルっていまも使える？
  • A. あとで調べる(大山さんがあとでまとめていただける とのこと)

■ of_protocol で遊んでみた

  • 近藤さん(@Eishun_Kondoh)
  • 資料
  • of-protocolとは？
    • Erlangで実装
    • flowforwading.orgのなかのerlangな人たちが作ったLINCというスイッチのパーサ
    • 使えるバージョンは1.2、1.3のようだ
    • モジュール
      • ofprotocol
        • ofpv4utilsとか使うとなんかできる感じ
  • 使いかた(こんな感じ)
    • of_protocol:encode(#ofp_message)
    • of_protocol:decode(BinaryData)
  • Flower?ベースで作ってみた
    • 3.5klocくらい
    • Tremaにコネクトできた
  • 遊ぶのにはよいと思う。

質疑応答

  • Q. どこら辺を参考にしている?
  • A. LINC-Switchを参考にした
  • A. FlowERを参考にした
  • C. 半年コードを読んで、3ヶ月かけて実装したような感じ
  • C. Erlangの本(飛行機本)にはいろいろ書かれている
  • C. ElixirだとErlangのVMでRubyっぽい
  • C. ElixirだとRubyとかのように文法定義できるかんじ
  • Q. Erlangのメリットは？
  • A. VMの上で動いていて、他のマシンの上にあるVMに移せたりする
  • A. 小さいスレッドが作れる
  • A. 横方法にスケールアウトすることができる
  • Q. 構成図の四角はプロセス？
  • A. 違う。もっとごちゃごちゃしている

■Tremaをもっと手軽で簡単に。

  • 大山さん(@userlocalhost)
  • 素人がTremaを使うにあたって
    • 一般の声
      • Trema 覚えるの大変そう
      • やりたいことは簡単なのにやることが多い
    • 呪文が多い
    • そこで
      • Observed
        • 他のシステムと連携するシステム
      • Observedが仕組み
        • 外部システム連携は各プラグインが肩代わり
    • Trema−Gmail連携
      • Tremaから情報をとって、Gmailに送る
        • observe(見るところ).then(やること) という感じでかくと
    • HTTP-Trema連携
      • 監視しておいて落ちたら、他のサーバに振るテーブルにする
    • Pluginはいくつかある

質疑応答

  • Q. 他のフレームワークは？それとの優位性は？
  • A. JavaでCamelがある。連携作業を並列にやれたり とか効率的にできるように。まだpluginが充実していない。
  • Q. メッセージングで使えるやつのメッセージングツールとの差は？
  • A. fluentdはログに特化している
  • A. Observedはなんでも対応できるフレームワーク
  • Q. Observedは社内でやっているの？
  • A. 完全に個人のレベルでやっている
  • C. 呪文が多すぎる？について、視点が複数ある。サンプルコードが恣意的。
  • C. 共通化できると連携処理はかける
  • C. フレームワークを1つ覚えればいろいろできる
  • Q. 取りこぼしが起こるのか？syslogのように取りこぼしがあるのか?
  • A. 他のシステムに依存するところ。
  • Q. どれくらいTremaに対応しているか？
  • Q. なにができているか？
  • A. statをとる、flowを変更する というレベルはある。
  • C. Trema本体からそとに提供する仕組みがあるといいが、hookしてレポートする仕組みがあれば十分

■Go Deep

  • 千葉さん(@chibacchie)
    • 最近Rubyを勉強し始めた
  • 資料
  • Tremaでコントローラを作るときの課題
    • 受信したところからパケットパースするとるのは面倒だ
    • Rubyでパケットパーサが欲しい
    • libwireshark を使って、rubyに返す
    • ruby-wiresharkを作った
    • wiresharkの対応している分だけメソッドができる
    • まだ公開できるレベルではないが、公開できるようになったら公開する

質疑応答

  • Q. wiresharkのバージョンが変わると変わる?
  • A. 変わる
  • Q. Packetはリアルタイムで見える?
  • A. 見える。pcapの機能である。
  • C. parserの仕事。パースする。treeを表示する。意味がわかる。の両方の機能
  • C. wiresharkが意味づけしてくれる
  • Q. IPアドレスとかはRubyのクラスにマッピングできる?
  • A. できる
  • C. wiresharkのラッピングがgemでなはないのであるとうれしい

■[LT]エクルとリームなネットワーク機器テスト環境の実現

  • 空閑さん
  • ネットワークテスタHWが持つ高精度な試験をSWツールに適用したい
  • チャレンジ
    • アプローチ1: Userspace Dataplane
      • ハードのDataplaneをソフトに持って行く
    • アプローチ2: Timing API
      • パケット送受信のタイミングをNICにオフロード
      • Userspaceからパケットごとに送信タイミングを指定
        • NICにその送信タイミングにしたがって送出する実装を追加する
      • 8nsの精度
    • 2つの時間の指定方法
      • Global(絶対的な指定)
      • Local(相対的な指定)
    • アプローチ3: Programmable Interface
      • Ethernet Character device
        • echo "0000 FFFF"> /dev/ethpipe/0 などのようにする
        • リプレイできる
  • shell scriptで実装してみる
    • shell scriptで書いて8nsの精度でやる
  • アプリケーションとしては
    • latency emuration
    • "Extreme" network testing
    • Generic purpose network IO
  • オープンソースなので使える

質疑応答

  • Q. ppsとかをはかるとかそういうことにも使えるのか？
  • A. 使える。jitterとかを作れる。1GのNICで500Mbpsとかもきれいにだせる。
  • C. 10Gも目指す。
  • Q. bash押しな理由は?
  • A. シンプル化という視点でいうと、cat コマンドというイメージだったから。
  • A. sedとかして、プロセスが重くなる。gnu grepだと6Gbpsくらいはできる
  • A. 高速化を考えるんらASCIIにせずに、binaryで扱うとよいと思う。
  • Q. NICからデータをユーザープログラムが受け取るのは割り込みベース？
  • A. データの割り込みは間引きする
  • Q. いろいろDPDKとかに? ポーリング vs 割り込み
  • A. 割り込みだからできない という話ではない。(バウンダリ周り)

■[LT]VagrantとかTrema-edge switchとかデバッグツール

質疑応答

  • Q. Vagrantまわりで他になにか情報あるか？
  • A. あまりない
  • C. 作ってくれる人がいればぜひ

■[LT]Tremaの作り直し

  • 高宮さん(@yasuhito)
  • Tremaの現状
    • C
      • 37000行
      • test 30000行
    • Ruby
      • 8500行
      • test 7000行
    • 合計
      • 80000行
  • 目標
    • できるところはRubyにしたい(メンテナンスのため)
  • Cの部分の分類
    • switch manager
      • 試しに実装した
        • C: 3000行
        • Ruby : 200行
        • 期間1週間
    • switch daemon
    • openflow ライブラリ
    • main loop
    • messanger
    • packet in filter
  • 試しに実装してみた
    • switch manager
      • C: 3000行
      • Ruby : 200行
      • 期間1週間かかった
  • やることがたくさんある
  • 方針?
    • アプリからやる
    • Trema-Edgeから？
    • TremaでもRuby2.0以上にする予定
    • Tremaでも1.3をサポートする方向で。
    • がちでできるように性能は気にしてほしい
    • 必要なスパイスは消さないように
投稿者 時刻: 0 件のコメント:
ラベル:

2013年7月28日日曜日

Trema Day #3 に参加してきた(一部)

Trema Day #3に参加してきたので、まとめる。 ぜんぜんまとまっていないが、とりあえず出す。ということで。。

全体(といっても前半)

4歳の息子が一緒にいきたがったので、連れて行ったが、 結果としては最初に少し間に合わず、途中で帰ることに。。

ustに録画がでたので、あとでこちらを参考に、あとで書き直す予定。

Wakame-VDCの話はとても興味深かった。 TremaをHiper Visorごとにいれてあり、それを集中管理するという方法が、 「そういう使い方もあるのか」と思った。 Wakame-VDC自身も興味深かった。lxcとかも使えるということで、 Macの上にVMを立てて、いろいろ遊べる気がした。 ちょっといろいろ調べてみようと思う。

RubyでPacketParserの話も興味深かった。 今回はLLDPの話だったが、もっとレイヤが上位のパケットを考えると、 tcpdumpレベルでは難しいパケットの抽出もでき、 解析もけっこうやりやすくなるのかもしれないと思った。

概要

  • 2013/07/27 (土) 13:00-17:00
  • KDDIウェブコミュニケーションズ CloudCoreセミナールーム
  • atnd
  • ust

他のかたのまとめ

Wakame-VDCの仮想ネットワーク

  • あくしゅ 山崎泰宏( @sparklegate )さん
  • Virtual Networking
    • 構造
      • Agent Network
    • VM同士のネットワーク
    • eth0とeth1でeth1をマネジメントにしてhva(Hyper Visor Agent)を接続
    • 分離
      • 物理NW
      • 論理NW
      • VM
    • WakameではHVに1つのovs、1つのhva(Tremaコントローラ含む)
    • dhcp、dnsなどはTremaコントローラで折り返す
    • トンネリング
      • MAC2MAC(と呼んでいる方法を使っている)
        • ARPのブロードキャストドメインをコントロール
        • ARPブロードキャストをユニキャストに変換する(これでスイッチは学習できる)
          • L3は超えられない
      • DBで管理できているので、それを使ってやる
    • WakameではTremaとovsの間はUnixSocket通信している
    • Wakame-vnetというのを切り出そうとしている
  • Q&A
    • RabbitMQからZeroMQにした理由は?
      • セルロイドというライブラリがzeroMQだった
      • 小さいパケットの処理が早い
    • ブロードキャストをユニキャストに変換するのはarp以外にも制御できる?
      • 明らかに対向がわかるものしかできない
  • 資料
    • 見つけられていないが、OPEN CARFの資料を参考にするとちょっとわかりやすいかも。

OpenFlowでSDN作りました

  • 中程さん@UEC
  • ospf -> sospf関連のとOpenFlowの話
  • ospfだと経路が重なり輻輳の問題がある
    • それを解決したい
  • 今回はPOXで書いたので長くなってしまった

Rubyでパケットパーサ

  • @yasuhito さん
    • trema #3の話
      • Lineを貼ってみた
      • フィールドオブドリームズのように人が来る
    • 今回はコンビニの大木さんが発表。
  • LLDPを使ったトポロジ探索サンプルプログラム
    • 短く、読みやすく、改造しやすく
    • LLDPジェネレータとパーサ
    • PacketFu
      • ちょっと流儀が。。
    • Racket
      • おしい
    • BinData
      • けっこう使われている
      • バイナリをパースするライブラリ
      • DSL的
  • BinData
    • プリミティブ型があり、それを組み合わせて定義できる
  • Trema::Packetとして共通部を切り出してやっていければなと思う
  • 資料

OpenFlowの可視化ツール

  • 大山裕泰さん
  • ＊＊＊ここで帰ることになってしまった。。＊＊＊

LT 安くOFS&冗長化

  • あとで

LT OpenStackでのトラフィックフロー制御

Virtual Network Platform の紹介

投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年4月21日日曜日

Trema Day #2 に参加してきた

1.1 概要

1.2 全体

OpenFlow/SDN周辺を勉強しないとなと思いながら、 ずっと手をつけられていなかったが、 Tremaでいい加減OpenFlowを体験してみようと思い、 Trema day #2に参加した。

会場はネットワーク系のエンジニア7割、サーバ・アプリよりのエンジニア3割という 感じの参加者だった。

OpenFlow関連の技術はまだユースケースが多くなく(データセンターなどでは一部確立できている部分はあるが)、 どのようにOpenFlowをやっていくか というところの議論が多く、ためになった。 IPv6と同じ(？)で、なかなか、キラーアプリがない状態で、 エンジニアがこれは大事だとは思いながらも、実際にどのように いまの環境、会社に適用していくか というところのイメージがあまりない状態だと思う。

手段の目的化もときにはあってよいと思うので、 エンジニアは、この技術を心に秘めて、いろんな困りごとを見て、 OpenFlowを使うと、その困りごとがどのように解決できるか というのを探し続けるのかな と思う。 (アプリ開発者と机を隣にするという議論もあったが、そういうことだと思う。)

Tremaをまだほとんど触れていないので、 どこら辺に困難があるかわかっていないため、 理解ができていないところが多いと思うが、メモしてみる。

次回のTrama Dayには違う視点で話を理解できるように、 まずは、ソースコード読んだり、実装してみたりしよう。 テストフレームワークも。。

参考：nanapi社長日記 - 「目的があっての手段だ」なんて考え、つまらなくないですか？

1.3 OpenFlow 1.2で、トラフィックエンジニアリングを試してみた by @ttsubo さん

OpenFlow 1以降で追加された機能のひとつである、マルチフローテーブルを使って、 通信種別によってパスを使い分けて、経路に問題が発生したら、 瞬時に切り替えるということをやっていた。

通信種別はTOS(Type of Serive)を使って分けていて、 普段は別の経路を指定して、いざというときには、 同じパスを通るようにする という手段だと思う。

この手法であれば、コントローラに負荷をかけずに マルチパス、と問題発生時の切り替えができる と理解した。

ちなみに、説明の中にでてきたOAMはOperations Administration and Maintenanceの略のようだ。 OAMの説明を読むとそうかなと思う。

資料リンク

1.4 Tremaで作る実用OpenFlowコントローラ by @chibacchie さん

いろいろな事情があって、いろいろ話せないことがあった模様。 前半はOpenFlowを(TremaのC言語ライブラリで)実装するときの注意点。

  1. TremaはOFCではない
    • Tremaはフレームワーク
    • 他のライブラリを使えばよい
  2. OFSはデータベースではない
    • Flow modは確実にすぐに実行されるわけではない
    • Barrier Requestをすると実行される
      • apps/transaction manager
  3. 非同期でイベントが発生する feathres request/replyよりも前に
    • そういうことも考慮する
    • 無視するための処理が必要
  4. send_openflow_messageはqueueに追加するだけ
    • 順序の保証もない
  5. libtramaはthread safeではない関数がある
    • thread safe化プロジェクトをこじんまりとしている
  6. send queueは固定長
  7. flush_messenger()を読んではいけない
    • Handlerが再帰的に呼ばれる可能性がある
  8. start_tremaはfork(2)を呼ぶ可能性がるので注意

後半は、大量のネットワークスライスを制御するために、 OpenFlowController(Work)を配置して、REST APIで制御する システムの説明だった。

WorkerとDBを使って負荷分散するとスケールアウトで対応できそうだな と思う一方、勉強しないと大変そうなところがわからないな と思った。

資料リンク

1.5 SDN人生相談

みなさん、エンジニアとして悩んでいるなと。 (全体のところで省略。)

1.6 会社をOpenFlowにしちゃおう by 大山さん

会社に入ると説明責任がある。 ただ自分がやりたいからやるではできない。 なので、GUIで可視化して、OpenFlowとかをやっていきたい という趣旨と思う。

利用者(一般社員、アプリ開発者、サーバ管理者、インフラ運用者)によって、 いろいろみたいビューが違うので、それを表現できるようにしたらよいのでは？という コメントがあったが、 そうだなぁ と思った。

インフラのエンジニアとしては、数あるネットワーク機器で 問題が発生していたらすぐにわかるように、とか、 いつもと違うことがすぐにわかる(感覚的に)といいなぁ と思った。

1.7 Tremaで構築中小企業の社内LAN by 近藤さん

中小企業で実際にOpenFlowで社内ネットワークを構築した という話。

これこそ、手段の目的化だが、 実際にやってみないと、なにが問題なのか どうなのかがわからない というところから出発していて、 自分もこういうアプローチでいくのかな と漠然と思った。

社内LAN環境だと、場合によってはセキュリティを絡めて、 Radiusとかの認証と組み合わせてもよいかな と思った。

1.8 LT - 手半田でつくるEthernetスイッチ箱 by @SRCHACK さん

自作でEthernetスイッチ箱を作るという話。 詳しくはInteropのORCを参照のことということで、 Interopで時間をとって見に行こうと思う。

投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)