プライベートクラウド管理のすゝめ③ - 其の弐

既存のネットワーク資産も有効に活用しよう
Software-Defined Infrastructureの実現へ
技術情報
関連情報
採用事例
お問い合わせ

作成日	2014/8/6
更新日	-

応用編

既存のネットワーク資産も有効に活用しよう

ネットワークアプライアンスを適材適所に利用しよう

OpenFlowを活用することで、L1～L4までのレイヤのヘッダ情報を柔軟に組み合わせて転送あるいは破棄といったプリミティブな通信制御が可能となります。

一方で、DPI（Deep Packet Inspection）製品のようなパケットのデータ部（ペイロード）に基づき、転送あるいは破棄といった通信制御は得意としない部分となります。もちろん、Packet-InメッセージによりOpenFlowコントローラにパケット情報を常に通知し続け、OpenFlowコントローラ側でデータ部を読み、転送あるいは破棄を判断する、という動作自体はOpenFlowのアーキテクチャにおいて可能です。しかしながら、OpenFlowスイッチとOpenFlowコントローラ間でのOpenFlowプロトコルによるメッセージ送受はOpenFlowスイッチに搭載されたCPUの性能（スイッチはソフトウェアではなくASICなどのハードウェアによりパケットを処理するため、対向となるOpenFlowコントローラに用いられるIAサーバと比べて低性能なCPUとなります）に依存することから秒間数百パケット程度となり、転送性能は全く期待できません。また、OpenFlowプロトコル（Flow-Modifyメッセージ）を送受して通信路を確立するための処理時間という側面を考慮すると、ロードバランシングというネットワーク機能を実現する際も同様となります。数百程度の有限のアクセス元に対して単なる負荷分散として振り分けるだけであれば通信路の生成頻度が低いことから、転送性能を担保することが可能かもしれませんが、数万以上の不特定のアクセス元に対しては毎回の通信路の確立に数10msecを要することから適切とはいえないでしょう(*1)。

このように、ネットワーク機能全てをOpenFlowで実現しようと捉えるのではなく、得意・不得意・メリット・デメリットと適切に踏まえた上で、従来から利用されてきた高度なネットワーク機能については流用していくという考え方が無理のないネットワークを実現する上で重要となります。

Hinemos仮想ネットワーク管理オプションにおいて、ファイアウォールやロードバランサといった既存のネットワーク機器を経路上に組み込むことは極めてシンプルに実現できます。物理サーバなどと同じように、ネットワークエディタ上に経由させたいネットワーク機器のMACアドレスを登録し、仮想L2スイッチと接続させるだけです。

これは、NFV（Network Function Virtualization）と組み合わせて用いられることが多いキーワードではあるサービス・チェイニングという概念に近いOpenFlowの活用法になります。

(*1) OpenFlow v1.0の場合に該当します。OpenFlow v1.1以降で追加されたGroupアクションを活用することで、実用レベルの高速化を実現できる可能性はあり、その場合、高価なロードバランサ相当の機能をL2/L3スイッチ相当のOpenFlowスイッチで満たせるメリットがあります。

既存のネットワークを併用しながら、段階的に集中管理の実現へ

従来のネットワークより求められてきた集中管理・分散制御がOpenFlowで実現できるからといって、企業内のスイッチ全てをあるタイミングでOpenFlow対応させることは容易ではありません。クリティカルでない領域から部分的に試験導入していき、費用対効果を見極めながら、ネットワークのSDN/OpenFlow化を拡大していくのが現実解になります。

アクセスポートを活用することにより既存のネットワークとシームレスに接続できることは、プライベートクラウド管理のすゝめ② ネットワーク管理者編 - 其の参にて説明しました。既存のネットワークの一部分（例えば、マシンルームの開発環境など）をOpenFlowスイッチにリプレースし、アクセスポートを用いて既存のネットワークと接続する構成が最もスモールな導入形態となります。

この試験導入の効果が確認した後、OpenFlow化が横展開される段階に進むと、OpenFlowスイッチで構成されるネットワークコロニーが既存のネットワークを挟む形でいくつか形成されていくことが想定されます。ただし、ネットワークコロニーごとにOpenFlowコントローラを配置することは本来目指すべき集中管理と真逆の方向であり、OpenFlowコントローラ増設に伴うコストも要します。そこで、OpenFlowプロトコルを送受するための管理ネットワークを延伸し、既存のOpenFlowコントローラから全てのネットワークコロニーを制御することが現実解となります。そのような状況下において、OpenFlowスイッチ間にトンネルを張ることにより、仮想的に単一のネットワークコロニーで構成されているかのように扱うことが効果的です。こうすることで、あるネットワークコロニーAに属するサーバAと、別のネットワークコロニーBに属するサーバBを同一セグメントとして通信させたい場合、コロニー間に存在する既存のスイッチを全く意識する必要はなく、ネットワークエディタ上で仮想L2スイッチを用いるだけで実現できます。

拠点内でのOpenFlow化が促進していくと、複数の拠点をまたがるネットワークを一元管理したいというニーズが出てきます。拠点ごとにOpenFlowコントローラを配置すべきかどうかは、ネットワークの規模やトラフィックの特性などを考慮する必要がありますが、各拠点が比較的に小規模なネットワークであった場合、広域網にOpenFlowプロトコルとデータ通信を同居させつつ、単一のOpenFlowコントローラで一元管理することも可能となります。ただし、実際の利用においては、広域網あるいは拠点などの障害が発生した場合に備えて、各拠点にOpenFlowコントローラのスタンバイ機を設けておく必要があるでしょう。

Software-Defined Infrastructureの実現へ

OpenFlowおよびネットワーク仮想化を活用することにより、これまでに様々な制御プロトコルによって複雑化されたネットワークをシンプルにし、人手で行ってきた作業を自動化し、柔軟なシステム構成にもたらすことが可能となることをこれまでにお伝えしてきました。

Hinemos仮想ネットワーク管理オプションでは、仮想ネットワークの管理・制御と連動して、多様なハイパーバイザ（VMware、KVM、XenServer）上の仮想サーバまでもソフトウェア制御可能なリソースとして制御するオーケストレーション機能が提供されます。システムに利用される汎用的なサーバ構成をテンプレートとして予めカタログ化しておくことにより、そのテンプレートを仮想ネットワーク内のネットワークセグメントに対して自由にプロビジョニングできます。プロビジョニングの際には、ネットワークマップエディタに登録されたNIC定義に合わせて、仮想サーバに搭載される仮想NICも再構成されます。

さらに、OpenFlowコントローラがDHCPサーバとして機能するため、仮想サーバの起動時にIPアドレス・デフォルトゲートウェイ・DNS/NTPの設定もネットワークマップエディタの定義に基づいて自動的に行われます。仮想ネットワークの生成＋仮想マシンのプロビジョニング＋仮想NICの再構成＋仮想マシンの起動までの処理が1クリックで実行されるため、ユーザが必要とするシステム構成を迅速に提供できます。

ネットワークの管理・制御の自動化をOpenFlowコントローラを含むSDNコントローラ、コンピュートリソースの管理・制御の自動化を各種ハイパーバイザが提供するコントローラに委ねる形で各システムリソースを集中管理させることにより、システムリソースの使用状況に応じて最適なリソース配分・障害対応に対する運用が効率化されます。各コントローラと運用管理ソフトウェアが密に連携することにより、システムリソースの状態可視化や自動運転状況の把握を可能とし、最小限のコストで最大限に活用できるプライベートクラウドのプラットフォームを実現できます。

既存のネットワーク＋αを実現するための手段としてOpenFlowを捉えるだけでなく、システムを構成する多様なリソースやサービスを連携させるための手段として捉えることが有効です。例えば、企業内のプライベートクラウドにおけるマルチテナンシの実現、各テナントのシステム構成の柔軟性向上、多様なリソース管理の自動化・非属人化による運用コストの削減を実現する上で、Hinemos仮想ネットワーク管理オプションの活用をぜひご検討ください。

< 1 2