こんな夜中にOpenFlowでネットワークをプログラミング!

第11回 【Trema編】実践あるのみ! 生活ネットワークをOpenFlowに移行しよう

この記事を読むのに必要な時間:およそ 4 分

はじめに

やり方は3つしかない。

正しいやり方。間違ったやり方。俺のやり方だ

『カジノ』⁠マーティン・スコセッシ)

そろそろ独り立ちするときがやってきました。これまで本連載では,OpenFlowコントローラの書き方とTremaの仮想ネットワークを使った実行方法注1を知り,テスト駆動によるOpenFlowコントローラの開発手法注2を学びました。Tremaのソースコードを探検し,その設計思想にも触れました注3)⁠OpenFlowプログラマとしてやっていくための基本的な知識はすべて身につきました。

次は何をすればよいでしょうか? あとはやってみるだけです。まずは自宅のネットワークをOpenFlowで置き換えましょう。うまくいったら,こんどは職場のネットワークをOpenFlowで置き換えましょう。その環境で実際に暮らしてみて,初めて見えてくるアイデアや改善案があります。これは,とにかくやってみなければ絶対にわからないことです。

「怒られるかもしれない」⁠あなたはそう考えます。家のネットワークはともかく,職場のネットワークを止めてしまったらどうしよう……。管理者や上司に注意されたらどうしよう……。大丈夫です。筆者たちも何度も怒られたことがありますが,その経験からうまくやる方法を学びました。

今回は我々の経験を踏まえ,既存のネットワークを⁠穏便に⁠OpenFlowに移行するためのテクニックを教えます。ちょっとしたOpenFlowプログラムを書くだけで,移行の際に起こりがちなネットワーク障害を簡単に防げます。まずは,筆者たちの失敗談を振り返らせてください。

注1)
本連載の第7回第8回を参照。
注2)
第9回を参照。
注3)
第10回を参照。

コラム TremaのほかにどんなOpenFlowプロジェクトがあるの?

Q:「TremaチームってOpenFlowが出た頃から活動を始めていたんだね。TremaのほかにはどんなOpenFlowプロジェクトがあるの?」

A:現在,さまざまなプログラミング言語用のOpenFlow開発フレームワークがそろいつつあります。最も歴史が古いプロジェクトはNOXです。スタンフォード大学の学生を中心として開発が進められており,言語はC++とPythonをターゲットとしています。歴史が古いだけあって,根強いユーザが多いのが特長です。

Floodlightは,Big Switch Networks社によって始められたプロジェクトです。言語はJavaをターゲットとしており,JVM上で動作するのでWindowsやLinux,Mac OSなどプラットフォームを問わず動作するという特長があります。

OpenFlowの成熟につれて,言語に合わせてフレームワークを選べる時代になりました。

失敗談

話は2009年7月までさかのぼります。OpenFlowが登場したばかりの当時,筆者たちはさっそくOpenFlowコントローラを書いて小さなOpenFlowネットワークを職場に構築しました。うまく動作して気を良くした我々は,職場のネットワークとこのOpenFlowネットワークをいきなりつないでみました。まあ大丈夫だろうと楽観的に考えていたのです。結果的にはすぐにネットワーク障害が起こり,事態に気づいた管理者からお叱りのメールを受け取ることになりました。

当時の状況を単純化すると図1のようになります。

図1 障害を起こしたときのネットワーク構成を簡略化したもの

図1 障害を起こしたときのネットワーク構成を簡略化したもの

職場ネットワーク(レガシーネットワークとします)のスイッチにはホストがつながれており,そのうちのスイッチポート3番をOpenFlowスイッチのスイッチポート1番と接続しました。このOpenFlow スイッチは,我々が書いたBuggyController というOpenFlowコントローラで制御されています。

「警告が出ているんですけど」

具体的な障害の症状はこうでした。レガシーネットワークとOpenFlowネットワークを接続してすぐに,レガシースイッチにつながったホストどうしが通信できなくなりました。そして,ネットワークを監視するwatchdogプログラムが「Host Flappingが起こっている」という警告を出しました。これは,1つのホストがいくつかのポートの間で高速で移動しているように見えるというものです。我々はすぐにOpenFlowネットワークを切断し,原因の分析にとりかかりました。

障害の原因

分析の結果,次のようなシナリオで起こっているのではないかという結論に至りました。

  • ① host1がhost2へパケットを送信する
  • ② BuggyControllerはOpenFlowスイッチポート1番からのpacket_inを受け取り,OpenFlowスイッチのスイッチポート1番にhost1がつながっていると学習する
  • ③ host2がhost1へパケットを送信する
  • ④ BuggyControllerはスイッチポート1番から「宛先=host1」のpacket_inを受け取る。ここで,host1はOpenFlowスイッチのスイッチポート1番にあると学習しているので,スイッチポート1番にpacket_outする
  • ⑤ 結果的に,host1はポート2と3の両方から同じパケットを受け取る。外から見ると,host2がスイッチポート2番と3番を高速に移動しているように見える

つまり,BuggyController が予期せぬパケットをレガシーネットワークに送ったおかげでネットワークが混乱し,通信できない状況が起きたのです。

【教訓】これをやってはいけない

振り返ると,失敗した原因は2つありました。

1つは,OpenFlowネットワークをいきなりレガシーネットワークとつないでしまったことです。OpenFlowネットワーク単体では動いていたという言い訳はありますが,いきなりつないでしまったのは若気の至り&経験不足でした。

もう1つは,BuggyControllerがpacket_inしてきたスイッチポートにpacket_outしていたことです。assertを入れるなど防御的プログラミングが徹底できていれば防げるバグでしたが,残念ながら当時の我々では気づくことができませんでした。レガシーネットワークにつないで始めて顕在化するバグと言えます。

著者プロフィール

高宮安仁(たかみややすひと)

Trema開発チーム自称リーダー。東京の大学で計算科学を学び,並列プログラミング用ライブラリや,大規模クラスタ管理ツールの開発,とくに東工大のスパコンTSUBAME,分散クラスタInTriggerの管理基盤などなど主に分散・大規模システムのミドルウェア開発者・研究者として活動。現在は企業の研究者として,OpenFlow用プログラミングフレームワークTremaのメイン開発者。モットーは何がなんでも定時に帰ること。コンピューターはもちろん映画や音楽も好きで,スクラッチDJとしても活動しています。DJの仕事ください。


鈴木一哉(すずきかずや)

Trema開発チームのメンバー。Ascend,古河電工,ヤマハ等のネットワーク機器を扱うエンジニアを経て,現在は経路制御の研究に従事。ホエールズ時代からのベイスターズファンで,98年の優勝時にはもちろん横浜スタジアムへ駆けつけました。野球のない時期には,もっぱらSFを読んでいます。会社ではランニングサークルに入っており,先日も多摩川の駅伝に参加しましたが,練習不足で全然走れませんでした。ちゃんと練習して,来年こそはしっかり走るぞ!

コメント

コメントの記入