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 件のコメント:
ラベル: ,

2013年4月20日土曜日

ネットワークパケットを読む会(仮) 14回に参加してきた

1.1 概要

  • ネットワークパケットを読む会(仮) 14回

1.2 全体

初めてネットワークパケットを読む会(仮)にパケット解析経験者として参加した。 今回はフレッシャーズ向けということで、パケット解析のいろは、 パケット解析の心得、パケット解析の黒い部分？について、 振り返ることができて、とてもよかった。

月曜日からは心得にしたがって、正常系のパケットをいっぱい見るようにしようと思う。

次回は2013/05/24(金)を予定しているとのことなので、こちらも参加したいと思う。

1.3 フレッシャーのためのパケット解析入門 by @hebikuzure さん

パケットの解析とはなにか、パケットを採る場所、方法、ツールなどの紹介だった。

パケットツールの紹介では、Wireshark、tcpdump を中心にいろいろなツールの紹介があった。 その中で、NetworkMinerというツールの紹介があった。 このツールは、キャプチャした通信から、ファイル、画像などが見やすい形で 表示することができるツールで、アプリケーションの通信でどのような 通信がされているかを見ることができ、Wiresharkとは違った用途で使えそうだ。

また、Windowsの場合は、MicrosoftのNetwork Monitorがパケットとプロセスの情報とを 結びつけられるということで、これも使えそうだ。

資料リンク

1.4 tcpdumpから始まるネットワークエンジニアの朝 by @twovs さん

ネットワークエンジニアとしての心得を紹介だった。 経験に基づき、どのようなところに着目するか、どのように 異常に気づくかを簡潔にまとめてあった。

その中で、一番こころに残ったのは、 「正常系のパケットをいっぱい見よう」「パケットは読むんじゃない感じるんだ」というところ。

日頃から正常系のパケットを見ていると、 異常が起こったときに、パケットの感じが違う ということに気づくことができる。 tcpdumpで多くのパケットを見ることで、正常系を意識に残す。 もし、tcpdumpでなにか違う と思ったら、Wiresharkでじっくり現象を見ていく と いうように、tcpdumpでパケットを感じるということが大切だということだった。 (だいぶ意訳がはいっているが。。)

資料リンク

1.5 とある環境(3G回線)であるアプリのパケットを見てみた by @totoromasaki さん

ちょっとここではかけない。。 とても黒い感じがした。

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