OpenStack実運用の課題からひもとくNeutronとSDNの関係：いま覚えておくべきNeutronの基本（3）（2/3 ページ）

OpenStack環境の評価検証で浮かび上がった課題とは？ ネットワーク領域をつかさどるNeutronはその課題にどう対処できる？ NeutronとSDNコントローラーとの関係を見ていきましょう。

[SDNエバンジェリスト吉本昌平，ユニアデックス株式会社]

そもそもSDNとは何だろう？

　NeutronとSDN製品の連携について見ていく前に、まずは「SDN」について整理しておきましょう。

　SDNは一般的に「ソフトウエアから自由自在に制御できるネットワークもしくはそれを実現する技術」と表現されます。つまり、従来人が行うことで費用や時間がかかっていたネットワークの設計構築作業を、最小限の物理的な結線などを除いて、できる限りソフトウエアに実行させることで、管理の効率化を目指す技術です。

　人の代わりにソフトウエアにネットワークを設定させることでさまざまな機能を実現できます。例えば、ソフトウエアに設定させることで、大量のネットワークデバイスを一瞬で設定できるようになります。今までネットワークインフラ専門エンジニアの手配などで何日もかかっていたネットワークの設定変更が、ほんの数秒で終わるようになります。また、人間がExcelシートで管理するのとは比較にならないほど正確に、ネットワーク全体の情報を完全に管理することもできるようになります。今後は機械学習などの技術の進歩とともに、常にソフトウエアでネットワークを監視し、自動で障害を修復するといった機能も実現していくことでしょう。

「集中管理」「抽象化」「APIコントロール」

　SDNでは、従来のネットワークアーキテクチャを根本から見直すことで、「集中管理」「抽象化」「API実装」を実現しています。集中管理によって、従来のように個々の機器を設定するのではなく、中央にある一台のサーバーで設定を管理できるようになりました。このサーバーが「SDNコントローラー」です。さらに、抽象化によって、従来のように個々の機器に異なる複雑な設定をしなくてもネットワークを構築できるようになりました。

　そして、SDNコントローラーにAPIを実装することで、ソフトウエアから簡単に制御できるネットワークを実現しています。今回のテーマである「OpenStackとSDNの連携」の視点で見ると、OpenStack Neutronが上記の「ソフトウエア」に当たります。

　では、具体的にOpenStack NeutronというソフトウエアはSDNをどう利用しているのでしょうか？ まずはNeutronプラグインの構造から見て行きましょう。

NeutronプラグインによるSDNコントローラーとの連携

　OpenStack Neutronにはプラグイン機構が用意されており、Neutronの設定でOpen vSwitchを使う、またはLinux Bridgeを使うなどの設定を行うと、それぞれに対応したプラグインが処理を行うようになっています。

　OpenStack Icehouseリリースでは「ML2（Moduler Layer 2）」という新しいプラグイン機構が登場しました。ML2は「Mechanism」と「Type」という2種類のドライバーで構成されるプラグイン機構です（図1）。例えば、標準のNeutronではMechanismドライバーにOpen vSwitchが使われています。コンピュートノードとネットワークノード間のネットワーク分離はVLAN、GRE、VXLANのTypeドライバーを選択できるようになっています。

図1　ML2のアーキテクチャ概念図　機能ごとに分離していることが分かる

参考文献：Modular Layer 2 In OpenStack Neutron（PowerPointファイル）

　実は、以前のNeutronの実装はモノリシック（一枚岩）な構造になっていて、Open vSwitchのドライバーの中にVLANやGREに対する処理が埋め込まれていました。そのため、例えばVLANの制御に関するコードがそれぞれのプラグインごとに開発されるといった、いわば「車輪の再発明」があちこちで起きている状態でした。Neutronがプラグイン機構をML2に変更したことの意義はこの点にあります。

　図2はOpenStack JunoのML2ドライバーを格納したディレクトリ（/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers）でlsコマンドを実施したスクリーンショットです。Open vSwitchのMechanismドライバーやVLANのTypeドライバー以外にも、ブロケードやシスコ・システムズなどのSDN製品ベンダーのドライバーが存在します。プラグインは、これらのドライバーを利用してSDNコントローラーを制御します。

図2　OpenStack Juno環境でのML2ドライバーの格納ディレクトリ

　次にML2ドライバーの中身が実際にどのようになっているかを見てみましょう。

　図3はTypeドライバーの「基本形」となるソースコードです。「基本形」というのは、オブジェクト指向プログラミングの「継承」を実現するためのひな形（テンプレート）だからです。ここには実際の処理の中身は記載されておらず、書籍の目次のように実装すべき処理の名前だけが一覧になっています。このひな形に沿って、各処理の中身にVLANの処理やOpen vSwitchの制御を実装することでプラグインが動作します。

図3　Typeドライバーのひな形

　ひな形の内部を実装しているのが図4です。図3のひな形にあるreserve_provider_segment()の処理（14〜16行目）が図4で実装されています。ここではセグメントの操作を実装しています。

図4　VLANのTypeドライバーの記述から一部を抜粋

　なお、MechanismドライバーはTypeドライバーに比べて処理の種類が多いため、ソースコードの掲載は割愛しますが、GitHubで公開されているものを参照ください。リンクの358行目からが該当します。

　このソースコードを見ると、Mechanismドライバーでは、例えばネットワークについては以下の六つの処理が定義されていることが分かります。

1. create_network_precommit
2. create_network_postcommit
3. update_network_precommit
4. update_network_postcommit
5. delete_network_precommit
6. delete_network_postcommit

　これらの処理は、OpenStackの管理画面である「Horizon」で行う「ネットワークの作成」「更新」「削除」といった操作と対応しています。同じように、サブネットやポートに対しても「作成」「更新」「削除」に対応する処理が定義できるようになっています。

　このようにML2では、Horizonを操作した際に発生するネットワーク作成などのイベントに対応して処理を記述する仕組みになっています。この処理の中でSDNコントローラーに対する処理を記述することで、ネットワークを構成することができます。