2012-04-08

HTTPプロキシ背後下でのFloodlightのビルド方法

OpenFlow

大企業などでは、HTTPプロキシを経由してしかウェブにアクセス出来なかったりして、そのせいでいろいろな場面で問題が起きたりすることが多い。

オープンソースのOpenFlowコントローラとしてhttp://floodlight.openflowhub.org/があるが、HTTPプロキシ配下ではビルドがうまくいかなかったりする（した？）

Floodlightでは、antでビルドをするときに、内部的にthriftのtar.gzをダウンロードしてきてライブラリを作成するためにCのビルドなどが始まる。また、Ant Maven Tasksなどを使っているので、AntとMaven用のHTTPプロキシの設定を行わないとビルドがうまくいかないのだ。

Ant用の設定

以下の環境変数を設定する

export ANT_OPTS="-Dhttp.proxyHost= -Dhttp.proxyPort="

Maven用の設定

~/.m2/settings.xmlを作成し、以下の設定を行う

hostタグ, portタグは自分の環境に合わせて設定を行う。usernameタグ, passwordタグ, nonProxyHostsタグは必要に応じて設定する。

もしくは、以下の環境変数を設定してもよいくさい

export MAVEN_OPTS=-Dhttps.proxyHost= -Dhttps.proxyPort=

これで無事ビルドが通ると思います。

と書いて見て気がついたが、今は、Floodlightのビルドの仕組みが変わっていて、プロキシの設定をしなくても大丈夫になっているかもしれない（自宅はプロキシ背後ではないので確認のしようがないのでよく分からない）

2012-04-08

Open vSwitchソースコードリーディングその1を開催しました

SDN Open vSwitch

4/7にOpen vSwitchソースコードリーディングその1をニフティさんの会場をお借りして開催しました。

http://www.zusaar.com/event/217007

この手の勉強会を主催したのははじめてだったんですが、運営の大変さを甘く見ていたというのが正直な感想というか反省です。

スタッフは、会場1時間前に会場入りして準備を始めたんだけれども、ちょっとしたトラブルが発生して、それにうまく対応できないまま開場時間を迎えてしまったのは、結局自分の対処能力がなかっただけです。開場時間ぴったりに来た方、待たせてしまってすみませんでした。

結局、いろいろと自分の中で尾を引きずってしまって、いっぱいいっぱいな感じで円滑な運営が出来なかったなと反省しています。会場で提供されているWiFiにMacBook Proからなぜか接続できなかったからというのもありますが、結局、勉強会の最中には1回もツイート出来なかったという感じですし。ちなみに、WiFiに接続できなかった理由は不明ですが、ここ最近Macの調子が悪かったからでしょう。

反省点

仕事の割り振りを事前に決めて割り振っておくこと
余裕のあるスタッフの人数
懇親会の準備
- 昨日は、当日その場で成り行きに任せたが、やはり事前に決めておいた方がよい気がした
- ただし、事前に人集めする場合には、ドタキャンへの対応を考える必要がある。
- ビアバッシュ形式がいいのか？
- 先人の知恵を借りるのがよさそう
発表者集め
- ソースコードリーディングとつけると敷居が高く感じられて、発表者探しが難しくなる
- 知っている人に頼んでしまいがち。そうなると、発表者が固定化されがちになる。
- 固定化は内輪感を生み、新しい人が入りにくい雰囲気が出てきてしまう

勉強会の内容

運営の方に気をとられてそわそわしてしまい、集中できてなかったような気がするのでそれが一番の反省点です。参加してくれた方が、おもしろいと感じてくれたなら、それはそれで嬉しいと思っているので問題ありませんが。

Open vSwitchの使い方とか (@kotto_hihihi)

Openv switchの使い方とか

View more presentations from kotto_hihihi

TremaでのOpen vSwitch(@countone)

Trema での Open vSwitch

View more PowerPoint from kazuyas

Open vSwitchソースコードの全体像 (@oshothebig)

Open vSwitchソースコードの全体像

View more presentations from Sho Shimizu

KVM & Open vSwitchでVPSを作ってみる (@mamesan)

OpenvswitchでVPS

View more presentations from Daisuke Nakajima

Trema Switch (@yasuhito)

http://trema-switch-talk.heroku.com/

懇親会

懇親会では、クラウドや大規模なバックエンドの運用の現実の話などを聞けてとても楽しかったです。自分がいかに、頭でっかちな「研究」をしているのかというのを実感した気がします。

2012-03-31

Open vSwitchソースコードリーディングに向けてその5

SDN Open vSwitch

PORTINGの内容の続き

移植の戦略

OSのネットワークデバイスに対応したnetdevを実装したのちの移植戦略としては以下の3つがとれる。

一番手間がかからないのは"userspace switch"を使うこと。この場合、パケットの受信動作に対応するようにnetdevを実装していれば、追加のコードを書く必要はない。一方で、全てのパケットがovs-vswitchdのプロセスを通過するので性能は低くなる。"userspace swtich"の構成の仕方はINSTALL.userpaceに書いてある。

ユーザー空間のスイッチを使うことが移植の際に適切ではない場合には、よりコードを書く必要がある。"ofproto provider"か"dpif provider"どちらかを実装するかを選択でき、どちらを選択すべきなのかは状況によって異なる。

ofproto providerを使う場合においてのみハードウェア的にワイルドカードをサポートする機能（たとえば、ACLテーブルやTCAM）を十分に活用できる。
dpif providerを使うことで、Open vSwitchでサポートされているボンディング、LACP, 802.1ag, 802.1Q VLANなどの機能を活用できる。それらの機能についてハードウェアのサポートがある場合には、ofproto providerでは、独自の実装が必要になる。
通常は、dpif providerを実装する方が容易で、最もソフトウェアスイッチングに適した方法である。dpif providerを用いる場合には、ワイルドカードのルールをexact-matchエントリーの中に"爆発?"させる。

ofproto provider

"ofproto provider"は、ofprotoが直接OpenFlow-capableスイッチをモニターしたり制御したりするために使うものである。新規のハードウェア、ソフトウェアのためのofproto providerを実装するためのインターフェイスがofproto/ofproto-provider.hの中のofproto_class構造体で定義されている。この構造体には、多くの関数ポインタがあり、それぞれについてその動作の詳細を説明するコメントがある。もしそのコメントの意味が不明確であれば、バグとして報告してほしい。

ofproto providerのインターフェイスはまだ十分ではないので、もしあなたの目的にそぐわない場合には教えてほしい。改善するようにする。

dpif providerを書く

"dpif"と呼ばれるdatapathを操作するためのライブラリの最上部に作られた"ofproto-dpif"と呼ばれる組み込みのofproto providerがOpen vSwitchにある。"datapath"は単純なフローテーブルであり、exact-matchフローのみをサポートする。つまり、ワイルドカードはサポートしていない。ネットワークデバイスにパケットが到着すると、datapathはexact-matchテーブルから対応するものを探す。一致するものが存在すれば、対応するアクションを実行する。一致するものがなければ、ofproto-dpifにパケットが渡される。ofproto-dpifは、OpenFlowのフローテーブル（ワイルドカードをサポートしている）の状態を維持するものである。このフローテーブルに合致するならば、ofproto-dpifはそのアクションを実行し、新しいexact-matchエントリーとしてdpifフローテーブルにエントリーを追加する。（それ以外の場合には、ofproto-pdifはofprotoにパケットを渡し、パケットがOpenFlowコントローラに送信されるように設定されているならば、OpenFlowコントローラにパケットが送信される）

"dpif"ライブラリは自信の多くの機能を"dpif provider"に委譲している。以下の図が、dpif providerがどのようにOpen vSwtichのアーキテクチャに合わせているのかを示したものである。

                _
               |   +-------------------+
               |   |    ovs-vswitchd   |<-->ovsdb-server
               |   +-------------------+
               |   |      ofproto      |<-->OpenFlow controllers
               |   +--------+-+--------+  _
               |   | netdev | |ofproto-|   |
     userspace |   +--------+ |  dpif  |   |
               |   | netdev | +--------+   |
               |   |provider| |  dpif  |   |
               |   +---||---+ +--------+   |
               |       ||     |  dpif  |   | implementation of
               |       ||     |provider|   | ofproto provider
               |_      ||     +---||---+   |
                       ||         ||       |
                _  +---||-----+---||---+   |
               |   |          |datapath|   |
        kernel |   |          +--------+  _|
               |   |                   |
               |_  +--------||---------+
                            ||
                         physical
                           NIC

lib/dpif-provider.hの中にあるdpif_struct構造体は、新しいハードウェア、ソフトウェアのためのdpif providerを実装するために必要なインターフェイスを定義している。この構造体には、多くの関数ポインタがあり、それぞれについてその動作の詳細を説明するコメントがある。もしそのコメントの意味が不明確であれば、バグとして報告してほしい。

既存のdpifの実装は2種類あり、それらは移植の際に有用な実例として参考になるはずである。

lib/dpif-linux.cはLinuxに特化したdpifの実装であり、Open vSwitch特有のカーネルモジュール（datapath/のディレクトリに格納されている）とやりとりを行う実装である。カーネルモジュールはスイッチングにに必要な作業全てを実行し、どのフローテーブルのエントリーにもマッチしないパケットをユーザー空間に渡す。dpifの実装は必然的にこのカーネルモジュールのラッパーになる。

lib/dpif-netdev.cは一般的なdpifの実装で、スイッチング動作をその内部で全て行っている。Open vSwitchのユーザー空間のスイッチがこれによって実装されている。

その他

uint_16t, uint32_t, uint64_tというホストバイトオーダーの固定長の型が使われている
ovs_be16, ovs_be32, ovs_be64はネットワークバイトオーダーの固定長の型が使われている
それぞれビット長が等しいものは等価なものであるが、使用意図を明確にするために名前を変えている

lib/entropy.cは、起動時に/dev/urandomを読み出すことで得られる高品質な乱数のシードを得ることが出来るということを前提にしている。対象とするプラットフォームでその前提が成立しないなら変更する必要がある。
vswitchd/system-stats.cはLinuxでのいくつかの統計情報の取得方法だけを知っている。対象とするプラとフォームにあわせて実装が必要になる可能性がある。

2012-03-28

Open vSwitchソースコードリーディングに向けてその4

SDN Open vSwitch

結局なんだかんだで前回から1週間あいてしまったが、気を取り直してトップディレクトリに置いてあるドキュメントの中身を読み進める。今日は、PORTINGについてまとめる。このファイルは、LinuxからほかのUnix系のプラットフォームにOpen vSwitchを移植する際の注意点について書かれたファイルなのだが、これを読むと何となくOpen vSwitchのアーキテクチャやソースコードについての理解が深まるような内容になっている。

とりあえず、Open vSwitchは移植性が高いように作ってあるとのこと。

単語の意味

歴史的な背景によって、同じコンセプトを指し示す場合であっても、ソースツリー上のコードの場所によって使われている言葉が異なっているらしい。

datapath/	vport	--
vswitchd/	iface	port
ofproto/	port	bundle
lib/bond.c	slave	lacp
lib/netdev.c	netdev	--
database	Interface	Port

そして、上記のような対応表が書かれているが、どのように読み取ったら良いのかよく分からない。一番左の列はソースツリー上の場所を指しているのは明白だが、2列目、3列がそれぞれ列方向で同じコンセプトのものがどのように表現されていると思っておけば良いのだろうか？詳しい人がいたら教えてほしい。

アーキテクチャの概要

以下の図がアーキテクチャの全体像を表している。

                   +-------------------+
                   |    ovs-vswitchd   |<-->ovsdb-server
                   +-------------------+
                   |      ofproto      |<-->OpenFlow controllers
                   +--------+-+--------+
                   | netdev | | ofproto|
                   +--------+ |provider|
                   | netdev | +--------+
                   |provider|
                   +--------+

ovs-vswitchd

Open vSwitchのユーザ空間で動くメインのプログラムで、vswitchd/に格納されている。Open vSwitchの設定情報をovsdb-serverからIPCを用いて読み出し、その設定をofprotoライブラリに渡す。逆に、ofprotoから得られる統計情報をデータベースに渡したりもする。

ofproto

Open vSwitchのライブラリで、ofproto/に格納されており、これを用いてOpen vSwitchが実装されている。ネットワーク越しにOpenFlowコントローラと通信士、また、ofproto providerを通じてスイッチ（ハードウェア実装、ソフトウェア実装を含む）と通信を行う。

netdev

Open vSwitchのライブラリで、lib/netdev.cに格納されており、ネットワークデバイス、つまり、Ethernet インターフェイスとのやりとりを抽象化している。netdevライブラリはnetdev providerのコードへの薄いレイヤーとして機能している。

netdev providerの書き方

netdev providerはOSとネットワークデバイス、たとえば、Linuxでのeth0を実装している。Open vSwitchではスイッチの各ポートをnetdevとして開くことが出来る必要があるので、それぞれの目的に合ったスイッチ実装で動作するようなnetdev providerを実装する必要がある。

lib/netdev-provider.hの中にあるnetdev_classは、netdevを実装するのに必要なインターフェイスを定義している。この構造体の中には多くの関数ポインタがあり、それぞれについてその振る舞いを詳しく説明したコメントがついている。もし、そのコメントが不明確であった場合には、バグとして報告すればいいと書いてある。

netdevインターフェイスは、以下の種類に大まかに分類可能である。

OpenFlowの機能を適切に実装するために必要となる関数。たとえば、OpenFlowでは、ポートのMACアドレスを報告する機能が必要である。これらの関数は最小限の正しい操作を実現するために実装されていなくてはいけない。

オプションのOpen vSwitchの機能を実装するために必要となる関数。たとえば、Open vSwitchでのインバンド制御を実現するには、netdevがTCP/IPスタックのARPテーブルの検査に対応していなければならない。これらの関数は動かそうとするOVSの機能に対応して実装する必要があるが、最初はやらなくても問題ない。

ある部分には必要だが、ほかでは必要とされない関数。たとえば、大半の種類のポートではネットワークデバイスからのパケットを受信するための機能は必要とされない。（→よく理解できていない）

既存のnetdevの実装は、ポート中の有用な実例として使える。

lib/netdev-linux.cでは、Linuxのカーネル呼び出しを使いながらLinuxのネットワークデバイスのためにnetdevの機能を実装している。

lib/netdev-vport.cはLinux カーネルでのOpen vSwitchのデータパスモジュールによって実装される仮想ポートに対応するためのものである。

lib/netdev-dummy.cはテストにおいてのみ有用なダミーのnetdev実装である。

と、ここまで、概要をまとめて簡潔に記述するのではなく、ドキュメントの和訳のようになってしまった。。。

本日は、ここまでにして、次回はPORTINGの残りの部分、どのように移植するのが良いのかという部分について書く。

2012-03-21

Open vSwitchソースコードリーディングに向けてその3

SDN Open vSwitch

トップディレクトリ直下のファイルにいろいろ役に立ちそうな情報が書かれていることが判明。というか、最初からREADMEなり読めという話だが。。。

README

プラットフォーム独立なCのコードで大半が書かれていて移植性が高い
カーネルモジュールを使用せずに全てをユーザーモードで動かすことが可能
ユーザーモード実装はカーネルモードの実装に比べて移植しやすい。ただし、ユーザーモードの動作は、実験的なものである。

というような話が書かれている。そのほか、Open vSwitchの全体像の理解に役立ちそうなのは、含まれているコンポーネントの概要説明。

ovs-vswitchd
- フロースイッチングをするためのLinux カーネルモジュールと一緒になって動作するデーモン
ovsdb-server
- ovs-vswitchdが自身の設定を問い合わせるための軽量データベースサーバ
ovs-brcompatd
- 多くの環境でLinuxブリッジを置き換える形でovs-vswitchdを動作させるためのデーモンで、ブリッジのioctlをインターセプトするカーネルモジュールと一緒になって動作する。
ovs-dpctl
- カーネルモジュールの設定を行うためのツール
Citrix XenServerとRedHat Enterprise Linxu用のRPMをビルドするためのスクリプトとSpecファイル
ovs-vsctl
- ovs-vswitchdの設定の問い合わせと更新を行うユーティリティ
ovs-appctl
- 動作中のOpen vSwitchデーモンにコマンドを送るユーティリティ
ovsdbmonitor
- OVSデータベースとOpenFlowテーブルを外部から見るためのGUIツール
ovs-controller
- 単純なOpenFlowコントローラ
ovs-ofctl
- OpenFlowスイッチおよびコントローラに問い合わせを行うためのユーティリティ
ovs-pki
- OpenFlowスイッチのための公開鍵基盤を作成、管理するユーティリティ
OpenFlowメッセージをtcpdumpでパースするためのパッチ

何となく、全体の構成が見えてきた気がする。ファイルの行数をとったりする前にこのファイルをちゃんと読むべきだった。。。。反省。

PORTINGの中身を読んで、だいたい理解したけれど、本日はもう時間がないようなのでまた次回に。

2012-03-20

Open vSwitchソースコードリーディングに向けてその2

SDN Open vSwitch

昨日は、ファイルの行数トップ10などを確認したが、ソースコードツリーの全体をざっくと見てみることにする。

トップディレクトリ

READMEをはじめとして、まず最初に目を通しておいた方が良さそうなファイルが並んでいる。各種インストール手順はINSTALL.*に書いてある。

DESIGNは、Open vSwitchのアーキテクチャ設計が解説されているのかと思ったが、中を見てみると主にOpenFlow関係の実装方針が書かれているようである。

実は、アーキテクチャ全体の概略はPORTINGを見た方が分かるくさい。"Open vSwitch Architectural Overview"という見出しがある。

NEWSには、これまでのリリースノートと、これからのリリースの載せる機能が書かれている。Version 1.6.0までの機能追加プランとPost 1.6.0のプランが記載されている。

datapath/

名前からしてパケットフォワーディングに関係したソースコードが格納されているくさい場所。vport-*.c, vport.cとdatapath.c, datapath.hあたりが重要そう。子ディレクトリのlinuxの下にはカーネルモジュールに関係したファイルが置かれていると推測。

debian/

Debianのパッケージを作成するのに必要なファイルが格納されていると思われる。

include/

サブディレクトリとして、

linux
openflow
openvswitch
sparse

がある。最後のsparseは何に関係しているのかちょっと想像がつかない。

lib/

ファイルが大量にある。基本的なデータ構造に関係しそうな、hmapなどといったものからAES関係くさいaes128.cやら、flow, dpif, vconnなどネットワークに関わるもの、ofp-*などのOpenFlow関係のものなどいろいろ格納されている。

ofproto/

名前からしてOpenFlowプロトコル関係のファイルが格納されていると推測。

ovsdb/

Open vSwitchの制御プロトコル？のOVSDB関係のファイルが格納されていると推測。

python/

Open vSwitchをPythonから使うためのファイルなのか？ほとんど見ていないので詳細不明。

rhel/

おそらく、Red Hat向けのパッケージ作成のためのファイルが格納されている。

test/

その名の通りテスト関連のディレクトリ。格納されているファイルの種類としては、*.pyと*.cと*.atがあるようだ。前者二つは分かるが、*.atが何だか分かっていない。

third-party/

tcpdumpをOpenFlowプロトコルのメッセージに対応させるためのパッチが格納されている。

utilities/

ovs-*という実行ファイルを最終的に作るためのmain関数を含んだソースファイルが格納されている。

xenserver/

中身をほとんど確認していないが、Xenに関係したファイルが格納されていると推測。このディレクトリに含まれているREADMEを読めば概要が分かるような気がする。

今回は中身が非常に薄いエントリになってしまった。次回は、DESIGNとPORTINGあたりの内容を読んでまとめようかと思う。

2012-03-19

Open vSwitchソースコードリーディングに向けてその1

SDN OpenFlow

http://www.zusaar.com/event/217007
Open vSwitchのソースコードリーディングをやると言い出したからには、そろそろソースコード読まないといけないと思いつつ、まだほとんど手がついていないので自分を奮い立たせるためにも、何らかのアウトプットをと思ってこれから毎日とは言わないがOpen vSwitchネタを書いていこうかと思う。

まずは、レポジトリからソースを取得

git clone git://openvswitch.org/openvswitch

HTTPプロキシの背後にいる場合にはHTTPでも取得が出来る。

git clone http://openvswitch.org/git/openvswitch

Open vSwitchの開発スピードは非常に速いのでどこかで固定しないと話が変わってきてしまったりするので、ここでは、私がレポジトリから最後にPullしたときの最新版である8a5b3cfd91841c97fbc8a003857cacbd602646edの時点のソースコードであるという前提で話を進める。

本日は、コードの中身に入る前にざっくりとした統計などを見てみることにする。

コードの中身はCとPythonで構成されているようなので、*.c, *.h, *.pyのファイルのの行数を"wc -l"で単純に集計したものがhttps://gist.github.com/2111386になる。

テストコードも含んでいるとはいえ全部で164700行ある。テンプレート用なのかよく分からないけど、上記でリストアップした拡張子以外のファイルもあったので、実際はもっと多いということになる。思いの外大きいなという印象。CとJavaという違いがあって比較するのはナンセンスだとは思うが、Cassandraが前に見たときに14万行くらいだったからそれより大きいのか。

行数トップ10を抜き出すと以下の通り

    6494 ./ofproto/ofproto-dpif.c
    4551 ./lib/netdev-linux.c
    4096 ./ofproto/ofproto.c
    3953 ./lib/ofp-util.c
    3924 ./utilities/ovs-vsctl.c
    3749 ./vswitchd/bridge.c
    2461 ./lib/meta-flow.c
    2350 ./python/compat/argparse.py
    2263 ./lib/ovsdb-idl.c
    2241 ./datapath/datapath.c

argparse.pyを除いて重要そうな大物の印象。トップのofproto-dpif.cはOpenFlowのDatapathに関係しそうな雰囲気。datapath.cはフォワーディングに関わるメインのところの雰囲気。このあたりを見ていけば、いいような気がしてくる。

あと、個人的に気になるのはトップ10に入らなかったが1971行のnicira-ext.h。NiciraのOpenFlowベンダ拡張メッセージが沢山詰まっている。ちなみに、OpenFlowの標準メッセージの行数は以下の通り

     716 include/openflow/openflow-1.0.h
     204 include/openflow/openflow-1.1.h
     197 include/openflow/openflow-common.h

いつの間にかにOpenFlow 1.1のメッセージが取り込まれておる！

そして、全ファイル数は837ある。全ファイルをざくっと眺めて分類しようかなと思ったけど厳しいことが判明。

ということでまた次回。