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をサポートする方向で。
    • がちでできるように性能は気にしてほしい
    • 必要なスパイスは消さないように