ネットワークを OpenFlow で構築すると、どんな利点があるのでしょうか。その答えは、ソフトウェアによる自動化です。まずは身近な自動化の例を見ていきましょう。
無精 (Laziness): エネルギーの総支出を減らすために、多大な努力をするように、あなたをかりたてる性質。こうして労力を省くために書いたプログラムは他人も使うようになり、そのプログラムに関する質問にいちいち答えずに済ますためにドキュメントを書くようになる。それゆえ、プログラマにとってもっとも重要な素質である。またそれゆえ、この本が存在するのである。
『プログラミング Perl』(オーム社)
優れたプログラマが持つハッカー気質の 1 つに無精があります。「大好きなコンピュータの前から一時も離れずに、どうやってジャンクフードにありつこう。そうだ、ソフトウェアを書けばできるじゃないか!」普通の人からするとただの横着に見えるかもしれません。しかし、ハッカーにとってはいつでも大きな問題なのです。
ソフトウェアによる横着は、ハッカーがもっとも創造性を発揮する分野の 1 つです。時間のかかる面倒な仕事も、ハッカーにかかれば気の利いたスクリプトひとつで自動化してしまいます。ハッカーによる次の 3 つの伝説的な逸話は、いずれもただ横着のためだけに高い技術力を駆使したといういい例です。
- ピザ注文コマンド
-
ハッカーの巣窟として有名な MIT の AI ラボにはかつて、コンピュータからオンラインでピザを注文できる UNIX コマンドが存在しました[1]。ハックしていて腹が減ったらコマンドを叩いてピザを取る。なんとも横着です。
- 自販機のリモート監視
-
コンピュータサイエンスの名門、カーネギーメロン大学にはコーク・マシンという変わったコーラ自販機がかつてあり、UNIX コマンド一発でコーラの冷え具合を確認できるようになっていました[2]。わざわざ遠くの自販機まで行ったのにぬるいコーラをつかまされた、なんてことが起きないようにするための工夫です。
- コーヒーポットプロトコル
-
RFC (Request For Comment) 2324 のコーヒーポットプロトコルは、遠隔地にあるコーヒーポットのコーヒーの量を監視したり、コーヒーを自動的にいれたりするための半分冗談の HTTP メッセージを定義しています[3]。いわゆるジョーク RFC にもかかわらず、本当に実装してしまった人もいたそうですから驚きです。
こうしたソフトウェアで楽をするハックの中でも、もっとも大規模な例が最新鋭のデータセンターです。クラウドサービスの裏で動く巨大なデータセンターは、大部分の管理作業をソフトウェアによって極限まで自動化しています。このおかげで、極めて少人数のエンジニアによる運用を可能にしています。
このように、ピザの注文やコーラ自販機、コーヒーポットといったお遊びから、データセンターのように一筋縄ではいかない相手まで、ソフトウェアを書けばその大部分を自動化できます。そして何より、ソフトウェアでモノを思いどおりにコントロールするのは楽しく、かつ実際に役立ちます。
|
Note
|
こうした最新鋭データセンターでのネットワーク管理自動化の仕組みは、16 章「たくさんのスイッチを制御する」および17 章「ネットワークを仮想化する」で詳しく解説します。 |
ネットワークをソフトウェア制御する技術の 1 つが OpenFlow です。より正確に言えば、OpenFlow とはネットワークスイッチの動作を制御するための標準プロトコルの 1 つです。OpenFlow を使えばスイッチ 1 つひとつの動作をソフトウェアから自由に書き換えられるので、究極的にはネットワーク全体の動作をソースコードとして記述できます。これを Software Defined Networking (ソフトウェアで定義されるネットワーク。以下 SDN と略す) と呼び、OpenFlow は SDN を実現する代表的な技術として注目を集めています。
OpenFlow の登場によって、これからはネットワークインフラもプログラミングの対象になります。「いまだに手で管理してるの? そんなのソフトウェアで自動化しようぜ!」ハッカーのこんな声が聞こえてきそうです。たしかに、今までネットワーク管理と言えば専門のオペレータによる手作業がメインでした。横着できる部分はまだまだたくさんあるはずです。
OpenFlow を使えば、次のような究極の自動化も夢ではなくなります。
-
スイッチの障害やネットワーク構成の変化など、あらゆる情報を自動収集するネットワーク
-
ユーザ／サーバ／スイッチの追加や削除に応じて、自動的に構成を変更するネットワーク
-
追加投資をしなくても、既存のインフラを目一杯まで使ってスケールするネットワーク
本書はこれらすべてのトピックを扱います。自宅や職場のような中小規模ネットワークからデータセンターのような超大規模ネットワークまで、実例を交じえながら「OpenFlow ってどんなもので、具体的に何に使えるのだろう?」という素朴な疑問に答えていきます。そして実際に動かしながら理解できるように、各章では実用的なソースコードを解説しています。
本書を読み進めるにあたって、ネットワークやプログラミングの深い知識は不要です。基本から 1 つひとつ説明しますので、ネットワークの専門家はもちろん、プログラマやシステムエンジニア、そして営業職や管理職などなど OpenFlow に興味を持つ方であれば誰でもすんなり理解できるように構成してあります。
ではさっそく、OpenFlow で構築したネットワークがどう動くかを見て行きましょう。
OpenFlow の仕組みを理解するために、ちょっとしたたとえ話から始めます。みなさんもきっと利用したことがある、電話のカスタマーサポートサービスを思い浮かべてください。そう、テレビとかパソコンの調子が悪くなったときに、フリーダイヤルで相談するアレです。でもそれって、OpenFlow とどう関係するのでしょう?
実は OpenFlow の基本的な仕組みはカスタマーサポートにとてもよく似ているのです。これからお話しするストーリーがわかれば、OpenFlow の 95% を理解できたも同然です。
それでは、このストーリーの主人公の友太郎 (ゆうたろう) 君と、カスタマーサポートセンターで働く青井さん、そして上司の宮坂部長の 3 人に登場してもらいましょう。
今年もエアコンの活躍する季節がやってきました。
ところが友太郎君のエアコンはどうにも調子がよくありません。取扱説明書に載っていたカスタマーサポートに電話し、自動音声に従ってしばし自分で直そうとしてみたものの、いっこうに解決しません。
結局、自動音声はあきらめて電話サポートに相談することにしました。
「はい、こちらカスタマーサポートセンターです。担当はわたくし青井がうけたまわります。ご要件は何でしょうか？」
青井さんはヨーヨーダイン・エアコン社で働く電話オペレータです。青井さんの普段のオペレータ業務は、主に次の 2 つです (図1-1)。
-
お客さんから不具合の症状を聞き出す
-
症状の内容に応じてそれぞれの担当技術サポートに電話をつなぐ
友太郎君は聞きます。
「なんだかリモコンの調子が悪いんです。温度表示がずっと点滅してるんですけど、どうしたら直りますか？」
青井さんは手元の対応マニュアルを開きます (表 1-1)。対応マニュアルには 3 つの項目があり、お客さんからの「問い合わせ内容」、電話オペレータの「対応方法」、そしてお客さんからの「問い合わせ件数」を調べられるようになっています。
| 問い合わせ内容 | 対応方法 | 問い合わせ件数 |
|---|---|---|
リモコンの不調 |
周辺機器担当の技術サポートに転送 |
8 件 |
エアコン本体の不調 |
エアコン担当の技術サポートに転送 |
6 件 |
室外機の不調 |
周辺機器担当の技術サポートに転送 |
4 件 |
いたずら電話 |
電話を切る |
2 件 |
青井さんはちょうどマニュアルの先頭に、探していた「リモコンの不調」の項目を見つけました。
「ご不便をおかけしました。リモコン担当の技術サポートにただいまお繋ぎいたします」
電話の転送を終えると、青井さんはリモコン不調の問い合わせ件数を 8 件から 9 件にアップデートしました (表 1-2)。
| 問い合わせ内容 | 対応方法 | 問い合わせ件数 |
|---|---|---|
リモコンの不調 |
周辺機器担当の技術サポートに転送 |
9 件 |
エアコン本体の不調 |
エアコン担当の技術サポートに転送 |
6 件 |
室外機の不調 |
周辺機器担当の技術サポートに転送 |
4 件 |
いたずら電話 |
電話を切る |
2 件 |
このように問い合わせ件数を控えておくことで、どんな故障が多いかを上司にフィードバックできます。たとえばリモコンに関する問い合わせが多ければ、上司は次の製品開発で「リモコンを改良せよ」という指示を飛ばせます。あるいは、周辺機器担当の技術サポートメンバーをもっと増やそうという判断もできます。
OpenFlow の世界では、パケットを送信するホストがお客さんの友太郎君、パケットを転送する OpenFlow スイッチが電話オペレータの青井さんに対応します (図 1-2)。ホストがパケットを送ると、OpenFlow スイッチはパケットの中身に応じてパケットを適切に処理します。これはちょうど、青井さんが友太郎君からの問い合わせ内容に応じ、適切な技術サポートに電話を転送するのと同じです。
OpenFlow スイッチは、動作がマニュアル化されています。カスタマーサポートの例では、青井さんはマニュアルから対応方法を調べました。いっぽう OpenFlow スイッチでは、スイッチ内のフローテーブルからパケットの処理方法を調べます。フローテーブルとは一種のデータベースで、パケットごとの処理方法が入っています。青井さんの業務がすべてマニュアル化されているのと同じく、OpenFlowスイッチの動作はすべてこのフローテーブルの内容によって決まります。
フローテーブルには、「こういうパケットが届いたら、こう処理する」というルールがいくつか入っています。このルールをフローエントリと呼びます。フローエントリはちょうど「リモコンの故障に関する問い合わせがきたら、リモコン担当の技術サポートに電話を転送する」といったマニュアルの各項目に対応します。
実際のフローテーブルの例を見てみましょう。表 1-3 はあるスイッチのフローテーブルで、各行がフローエントリです。フローエントリは主に、マッチフィールド・アクション・カウンタの 3 つの要素からなります[4]。
| マッチフィールド | アクション | カウンタ |
|---|---|---|
送信元 IP アドレス = 192.168.1.0 |
ポート 8 番に転送 |
80 パケット |
VLAN ID = 10 |
ポート 10 番に転送 |
64 パケット |
送信元 MAC アドレス = 00:50:56:c0:00:08 |
VLAN ID = 2 を付けてポート 8 番に転送 |
24 パケット |
送信元 IP アドレス = 203.0.113.0/16 |
パケットを破棄 |
10 パケット |
- マッチフィールド
-
届いたパケットに対応するフローエントリを探すための条件です。たとえば「リモコンの調子がおかしい」という問い合わせ内容と同じく、マッチフィールドには「送信元 IP アドレス = 192.168.1.0」などと指定します。
- アクション
-
届いたパケットをどう処理するかという処理方法にあたります。たとえば「リモコン担当の技術サポートへ引き継ぎ」という対応方法と同じく、アクションには「スイッチのポート 8 番に転送」などと指定します。
- カウンタ
-
フローエントリごとのパケット処理量を記録します。たとえば「リモコン関連の問い合わせ数は 9 件」とマニュアルに記録したように、「このフローエントリに従って処理したパケットは 80 個」といった情報が入ります。
このように、実は OpenFlow はとても単純で理解しやすい仕組みです。
エアコンもしばらくは順調でしたが、1 ヶ月後また調子が悪くなってしまいました。友太郎君は再びカスタマーサポートへダイヤルします。
「エアコンの排水ホースがすぐ詰まっちゃうんです」
どうやらまったく新しい不具合のようです。青井さんはいつものように手元の対応マニュアルを調べましたが、困ったことに排水ホースの項目は載っていません。
「申し訳ございませんが少々お待ちください。対応可能な技術サポートがいるかどうか確認いたします」
そして電話口にはどこか軽快な音楽と、「しばらくお待ちください」のメッセージが繰り返し流れはじめました。
こういうとき、青井さんがいつも頼るのは上司の宮坂部長です (図1-3)。
「宮坂さん、排水ホースについての問い合わせがきたのですが、どの技術サポートにつなげばよいですか？」
「それだったら消耗品技術サポートだよ」
転送先がわかった青井さんは、友太郎君の待つ電話に戻ります。
「大変お待たせいたしました。担当の技術サポートに転送いたします」
一度目の問い合わせと比べてかなり時間がかかってしまいましたが、これでようやく一件落着です。青井さんは忘れないうちに、宮坂部長から教わった消耗品技術サポートの連絡先をマニュアルに追加します (表 1-4)。もしも同じ問い合わせがきた場合には、素早く答えられるようにするためです。
| 問い合わせ内容 | 対応方法 | 問い合わせ件数 |
|---|---|---|
リモコンの不調 |
周辺機器担当の技術サポートに転送 |
9 件 |
エアコン本体の不調 |
エアコン担当の技術サポートに転送 |
6 件 |
室外機の不調 |
周辺機器担当の技術サポートに転送 |
4 件 |
いたずら電話 |
電話を切る |
2 件 |
排水ホースの不調 |
消耗品担当の技術サポートに転送 |
1 件 |
OpenFlow でこの上司にあたるのが、コントローラと呼ばれるソフトウェアです (図 1-4)。フローテーブルに載っていないパケットがスイッチに届くと、スイッチは「このパケットはどうすればよいですか」とコントローラに指示をあおぎます。コントローラはパケットの中身を調べ、どうすべきかという指示、つまり新しいフローエントリをフローテーブルに書き込みます。
当然ながら、コントローラへの問い合わせが発生するとパケット転送が遅くなります。そこで、あらかじめ必要とわかっているフローエントリは、スイッチの起動時に書き込んでおくようにします。そうすれば、スイッチ側でパケットを素早く処理できます。
OpenFlow でネットワークインフラをプログラミングする場合、プログラマが書くのはこのコントローラです。頭脳であるコントローラをソフトウェアとして記述することで、ネットワークを自由自在に制御できるというわけです。ただし、スイッチからの問い合わせをあまり発生させずに効率良くパケット転送できるかどうかは、すべてコントローラの設計にかかっています。
OpenFlow の大枠が理解できたところで、OpenFlow の利点を具体的に見ていきましょう。
カスタマーサポートセンターでは、お客さん対応はすべて電話オペレータがやってくれます。上司があらかじめ適切なマニュアルを作っておけば、あとはほとんどの仕事を電話オペレータにおまかせできるのです。これによって、電話オペレータが対応している間、管理職は他の部署との連携に集中できます。
OpenFlow では上司であるコントローラ自体をソフトウェアとして書けるので、ネットワークだけでなくその管理も自動化できます。さらにコントローラが Ruby や Python、Java などの汎用言語で書いてあれば、既存のシステムやサービスとの連携も簡単です。たとえば、アプリケーションからの要求やビジネスポリシーの変更、問題発生などさまざまなトリガーに応じてネットワークの設定を変更するといった、一歩進んだ自動化もできます。
|
Note
|
システム連携の一例として、コントローラに REST API を実装する方法を17 章「ネットワークを仮想化する」で解説します。また、実際のデータセンターでのコントローラと各種サービスの連携については、18 章「OpenVNet で本格的な仮想ネットワーク」で紹介します。 |
カスタマーサポートセンターでは問い合わせ件数の情報はすべて上司に上がってくるため、混み具合の把握や全体の交通整理が楽です。もし特定の技術サポートに問い合わせが集中しても、問い合わせがうまくバラけるようにマニュアルを通じて電話オペレータの全員に指示できます。反対にもし各オペレータが個々に判断してしまうと、おなじ技術サポートに問い合わせが偏ることは避けられません。
OpenFlow でもすべての情報はコントローラに上がってくるため、全体を見たトラフィックの最適化が可能です。フローエントリ内のカウンタを集計し、検出したスイッチの接続関係 (ネットワークトポロジ) と突き合わせることで、コントローラはネットワーク全体のトラフィックを把握できます。そしてその情報をもとに各スイッチのフローテーブルを更新することで、全体的に見て最適となるパケットの通り道を引けます。反対に、もし個々のスイッチが判断してしまうと、効率的にトラフィックを分散できません。
|
Note
|
各種カウンタの収集方法については4 章「スイッチ監視ツール」で、ネットワークトポロジの検出方法については15 章「ネットワークトポロジを検出する」で、またトラフィックの分散方法については16 章「たくさんのスイッチを制御する」で解説します。 |
コントローラはソフトウェアの一種なので、ソフトウェア開発で長年培われているさまざまなテクニックやツールをネットワーク構築に応用できます。
たとえば近年主流のアジャイル開発手法でコントローラを開発すれば、反復的な機能追加が可能です。ユーザからのフィードバックを受けながら少しずつバージョンアップしてくことで、ネットワークを段階的に構築できます。
またコントローラのテストコードを書くことで、ネットワーク全体を自動的にテストできます。テストコードやテスト結果の出力は、そのまま仕様書の一部として使えます。もう Excel や Word で書いた仕様書を別個に管理する必要はありません。
|
Note
|
アジャイル開発手法やソフトウェアテストによるコントローラ開発については、9 章「Trema でテスト駆動開発」で解説します。 |
従来のネットワーク機器を OpenFlow コントローラで置き換えれば、アップグレード方法の選択肢が広がります。従来のスイッチ・ルータ・ファイアウォールといったネットワーク機器では、ポート数を増やしたい場合にはワンランク上のハイエンドな機器との入れ換えが必要でした。これは、コストのかかる垂直方向のアップグレードです。しかし、ネットワーク機器を OpenFlow のコントローラとして汎用サーバ上にソフトウェア実装すれば、並べるサーバを増やすだけでポート数を増やせます。こうした水平方向へのアップグレードは垂直方向のアップグレードと比べて低コストで実現できます。
さらに、ネットワーク機器の機能アップグレードも、OpenFlow ではソフトウェアの書き換えで済みます。従来のようにワンランク上の高機能なネットワーク機器を購入するかわりに、新機能をコントローラにソフトウェアとして実装すればよいのです。
ただし、これらはもちろん自分で実装しなければならないという前提付きです。たとえば水平方向にサーバを増やす場合には、サーバ間での設定情報の同期や、一部のサーバがダウンした場合の障害復旧といった機能を自分で実装しなければなりません。また、ハイエンドなネットワーク機器の機能の中には、ソフトウェアによる実現がむずかしい複雑な機能もあるでしょう。これらを実現するには、既存の分散データベースといったミドルウェアを利用したり、OpenFlow で実装しやすい機能に置き換えたり、といった工夫が必要になります。
|
Note
|
こうしたネットワーク機器の OpenFlow 実装については、6 章「インテリジェントなパッチパネル」・7 章「すべての基本、ラーニングスイッチ」・8 章「OpenFlow1.3 版ラーニングスイッチ」・11 章「ファイアウォール」・12 章「ルータ (前編)」・13 章「ルータ (後編)」・14 章「ルータ (マルチプルテーブル編)」でそれぞれ解説します。 |
|
Note
|
OpenFlowは回転ずし
従来のファイアウォールやルータ、スイッチといった専用機器は、ベンダが提供する機能をそのまま使うしかありませんでした。たとえば、100 個ある機能のうち、本当に使いたい機能は 10 個だけだったとしても、100 機能付きのルータを買うしかありません。これではある意味、フルコースしか頼めないフレンチレストランのようなものです。一部の機能しか利用していないのに障害ポイントが無数にあるので、切り分けやデバッグが難航することもままあります。 OpenFlow は回転ずしです。フランス料理の味に近づけるのは大変ですが、必要な機能だけをチョイスしてがんばって実装すれば、思いどおりの機器が手に入るのです。 |
もちろん、OpenFlow はうれしいことばかりではありません。コントローラで制御を一手に引き受けるため、コントローラの過負荷に気をつける必要があります。たとえばもし、フローテーブルに載っていないパケットが一気にコントローラへ到着すると、パケットの配送が遅延するか、最悪の場合にはコントローラが停止してしまいます。
そこで、OpenFlow の使いどころにはとくに注意する必要があります。たとえばフローエントリの入っていない OpenFlow スイッチをインターネットのような多種多様のパケットが流れる環境につなげると、すぐにコントローラへの問い合わせが殺到し破綻してしまいます。しかしデータセンターなどの閉じた環境では、トラフィックの特徴や流れるパケットの種類はあらかじめ見当を付けておけます。そこで最低限のパケットのみがコントローラへ上がってくるようにうまくフローエントリを設計することで、スイッチが増えてもうまくスケールできます。
本章では SDN を実現する部品である OpenFlow を解説しました。OpenFlow で構築したネットワークは、フローテーブルを持つスイッチと、スイッチを集中制御するソフトウェアであるコントローラからなります。このようにネットワークの制御をソフトウェア化することによって、次の恩恵があります。
-
自動化やさまざまなシステムとの連携
-
トラフィック制御のしやすさ
-
ソフトウェア開発テクニックの適用
-
水平方向へのアップグレード
次章では OpenFlow の仕様をもう少し詳しく紹介します。