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

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

OpenDaylightとの連携を題材に実装を見てみる

　それでは実例として、OSSのSDNコントローラーである「OpenDaylight」と連携する部分のソースコードを簡単にのぞいてみましょう。図5にOpenDaylightのTypeドライバーの実装（冒頭部分）を示します。

図5　OpenDaylightのTypeドライバーの実装（冒頭部分）

　図5には、OpenDaylightのMechanismドライバーのひな形に存在していた「create_network_postcommit()」などの処理が見られます（図5の144行目〜）。これはHorizonでネットワークを作成した後に呼び出される処理です。

　この処理の先がどうなっているかをたどると、図6にある「sync_single_resource()」という処理に行き着きます。

図6　OpenDaylight Typeドライバーの「sync_single_resoudrce」処理実装の抜粋

　注目すべきは、図6の267行目と280行目にある「self.sendjson(….)」という処理の呼び出しです。これはOpenDaylightのREST APIを呼び出す処理を記述している箇所です。その他の処理と合わせると「sync_single_resource()」の処理は、「必要な前提条件を調べてデータを組み立てて、適切なOpenDaylihgtのREST APIを呼び出す」という内容になっていることが分かります。

　このように、SDN製品のNeutronプラグインの実装を見ていくと、Horizonでのネットワーク登録などのイベントに対応して、RESTで必要な情報をSDNコントローラーに伝えるという実装が多く見られます。

　では、以降で具体的にどのような連携が可能なのかを見ていきましょう。

NeutronとSDNコントローラ連携の実際

　ここからは一般的な見解ではなく筆者の個人的な分類ですが、Neutronと連携するSDN製品には「補完型」と「代替型」の二つのアプローチがあると考えています。以降では、この分類に即して見ていきます。

　補完型のSDN製品とは、Neutronが動作するのに必要なネットワークの実装を自動で行い、ネットワークの冗長化やVLANリソースの問題など、Neutronに欠けている機能をSDN側で補うものを指します。補完型のSDN製品を利用する場合、これまでの連載で解説してきたNeutronの機能やコンポーネントを大きくは変更しません。Neutronのネットワーク機能に不満はないが、冗長性や管理性、パフォーマンス向上の観点からSDN製品を採用したい方に向いています。

　一方、代替型のSDN製品はNeutronの機能とコンポーネントを置き換えることで、上記の問題解決はもちろん、より高度な機能や冗長性、管理性を提供します。これまでの連載で解説してきたOpen vSwitchやNamespaceなど、全てのコンポーネントを入れ替える製品も存在します。

　図7は、Neutronの標準構成とNuage Networks社のNeutronプラグインを組み込んだ場合のOpenStackネットワークの実装の違いを表したものです。

図7　Neutronの標準構成（左）と「代替型」SDN製品の実装例（右）（クリックで拡大）

　Nuageを使った構成では、全てのNeutronコンポーネントが「Nuage VRS」という単一のコンポーネントで置き換えられています。このNuage VRSはOpen vSwitchに相当する仮想スイッチですが、ルーティングやNATなどの機能も内蔵しているので、Open vSwitchやNamespaceなどのコンポーネントやネットワークノードも不要になっています。

インスタンス生成時の動作

　では、代替型SDN製品の場合、インスタンスを生成する際にOpenStackとNeutronプラグインがどのように動作しているかを見てみましょう（図8）。

図8　代替型SDN製品でインスタンスを生成する場合のNeutronプラグインの動作（クリックで拡大）

　OpenStackのHorizonで利用者がネットワークの設定を行い、仮想マシンインスタンスを作成すると、HorizonはNeutron APIを利用して「Neutronサーバー」にネットワーク作成の指示を出します（1）。指示を受けた「Neutronサーバー」は「Neutronプラグイン」を利用してSDNコントローラーにネットワーク作成の指示を出します（2）。SDNコントローラーはVRSと物理ネットワークに指示を出し、必要なネットワークを作成します（3）。

　必要なネットワークの作成が終わるとNeutronサーバーはコンピュートノード（Nova）に通知を出します（4）。通知を受けるとコンピュートノードはインスタンスをネットワークに接続して動作を開始します（5）。

　内部の挙動は複雑に見えますが、実際の設定作業自体はシンプルです。利用者がHorizonでネットワークを設定すると、Neutronプラグインを通じてSDNコントローラー側にも同じネットワーク設定が反映されます。この状態でSDNコントローラー側の設定画面を用いることで、Horizon側では設定できないような、さらに細かな設定を行うことができます（図9）。

図9　SDNコントローラー側から詳細を設定する（クリックで拡大）

　これらのSDN実装を活用することで、本稿冒頭で挙げた「適切な責任分界の問題」も解決できる可能性が高くなります。基本的な設定は標準のNeutronと同様に、開発者自身がHorizonの画面から行い、より詳細な設定などはネットワーク管理者がSDNコントローラー画面から行えるようになるためです。

　代替型SDN製品の多くがデータセンター間接続にも対応していますので、複数データセンターをまたぐシステムや、ディザスターリカバリの課題にも対応できます。

最後に

　今回はOpenStack Neutronとは何か、SDNとはどのような関係かについて、Neutron初学者の方に内部構造から理解していただく目的で解説を進めてきました。

　本連載が、これからOpenStack Neutronを学び始める皆さま、ひいてはOpenStack普及の一助になれば幸いです。

連載バックナンバー