【SDN特集】第二回・日本HP アプリの特性に合わせて柔軟な仮想ネットワークを提供する「VAN」


 「IT製品別にかかっている費用を見ると、実はサーバーやストレージよりもネットワークが多い。運用・保守費用が多くを占めるIT支出を削減し、全体の30%しかないといわれる新規投資の割合を引き上げるためには、ネットワークの変革が重要。当社では、それをネットワーク管理という立場から考えています」――。

 ソフトウェアによってネットワークを簡素化するというSDNのアプローチでは、新技術のOpenFlowやスイッチの機能などが注目されがちだが、それに対して、ネットワーク管理ソフトを中核に、アプリケーションに着目してネットワーク管理の簡素化を図るのが、日本HPのアプローチだ。こうした日本HPの戦略と現状を、エンタープライズインフラストラクチャー事業統括 サーバー・ネットワーク製品統括本部 インダストリスタンダードサーバー・ネットワーク製品本部の伊佐治俊介氏に聞いた。

 

仮想化についていけない、現状のネットワークの課題

 ネットワークを管理していく上での大きな変革は、やはり仮想化という技術の登場と普及だろう。仮想化技術によって、サーバーとストレージの両分野ではリソースのプール化が進んでおり、集約されるだけでなく集積度も上がっているし、ライブマイグレーションなどの技術によって、パフォーマンスを保ったままでプール内を移動させることも可能になった。

 一方でネットワークはといえば、まだそこまでの柔軟性は獲得できていないのが現状だ。「VLANによって論理的に分割されていても、VLANの数は限られてしまっているし、マルチテナントでの利用を考えた場合、柔軟に変更できるようにはなっていない。そこで、「好きなときに好きなだけ使えるリソースがネットワークでも求められるようになった」(伊佐治氏)のは、非常に素直な流れといえるだろう。


エンタープライズインフラストラクチャー事業統括 サーバー・ネットワーク製品統括本部 インダストリスタンダードサーバー・ネットワーク製品本部の伊佐治俊介氏仮想化技術によってリソースがプール化されているサーバーやストレージのように、ネットワークも“ネットワークプール”化が求められている

 ここで求められている次世代ネットワークを実現する手段の1つが、広い意味でのSDNだということは、異論はないだろう。SDNでは特にはOpenFlowへの注目度が高まっているが、HPではクラウド時代を見据え、「いかに早く、お客さまにアプリケーションを提供できるかという点を重視しているのです」と伊佐治氏が説明するように、アプリケーション視点からのSDNを提案しようとしている。

 ネットワークの世界ではまだCLIによる設定は一般的だが、500サーバー×20VMで1万VMのシステムを立ち上げる場合、どのくらいのコマンドが必要になるのかを考えてみよう。

 ポートごとに5つのネットワーク属性を設定すると仮定すると、1万VM×5=5万ネットワーク属性の設定が必要になる。そして、そのネットワーク属性1つにつき5つのコマンドラインが必要とすれば、総コマンドライン数は25万もの数になる。

 この設定をこなそうとすれば、多数のエンジニアが朝から晩まで張り付いて膨大な量の設定作業を行わなければならないため、こうした規模で新しいアプリケーションをユーザーへ提供するまでには、3カ月以上の時間が必要になるという。

 しかも、「システムダウンの7割以上が人為的ミスと言われています」(伊佐治氏)という点も、非常に重要なポイントだ。人為的ミスは決してゼロにはできないが、1つのコマンドラインの設定ミスがあったために、大きなトラブルが起こってしまうかもしれない。人に頼っている現在の運用では、常にこうした危険性をはらんでいる。

 このように、現状のままのアプローチではどうしても限界がある。「そこで当社では、コマンドラインを使わずにわかりやすくお客さまに提供できる、Virtual Application Network(VAN)を提唱しているのです」と、伊佐治氏は日本HPのアプローチを説明する。


(2枚通して)500サーバー×20VMで1万VMのシステムを立ち上げる場合は、25万以上のコマンドラインが必要になり、アプリケーションの展開には3カ月もの膨大な時間がかかってしまっているという。また、人為的なミスによるトラブルも多々発生している

 

アプリケーションに着目してネットワークをコントロールする「VAN」

VANとは?

 簡単にいえば、VANとはネットワークの集中管理を行うための手法のこと。そしてそれを実現する中核となるのが、ネットワーク管理ソフトのIntelligent Management Center(IMC)と、アドオンモジュールであるVAN Managerである。

 前述したように、アプリケーション導入のために、1つ1つのネットワークスイッチに対してコマンドラインで設定していては、手間と工数が膨大になる。最近では、ネットワークのファブリック化により複数のスイッチを統合管理できるケースも出ているが、規模に限界があったり、管理対象が単一ベンダーの製品に限られたり、といった問題があるほか、「仮想化が進む現状のネットワークでは、サーバーやストレージ、アプリケーションなど、他の管理者との調整も必要になり、ますます膨大な時間が必要になります」(伊佐治氏)といった、別の問題も生まれてしまったという。

 しかしVANでは、徹底的に単純化することでこうした問題を解決した。まず、1)ネットワーク管理者がアプリケーションに対してネットワークの適用ポリシーを作成。2)次にサーバー管理者がVMに対してそのプロファイルを登録する――。こうした2つステップだけで、アプリケーションの導入が行えるのだ。

 1)の設定では、そのアプリケーションに必要な最大・最小の帯域幅、QoS(優先制御)、アクセス制御などといったネットワークポリシーの設定を、GUIツールのVAN Designerから行う。作業自体、さほど複雑なものではないが、作成された接続プロファイルは繰り返し使えるし、一部だけを変更することも可能なため、新たなアプリケーションに向けたプロファイルの作成作業は、使い込んでいけばいくほど、より簡単になる。

 また、2)の作業はサーバー管理者が行うことになるが、ネットワーク管理ツールではなく、サーバー管理者が使い慣れた仮想サーバーの管理ツールを使用して行える点がメリットである。サーバー管理者がなじみのあるGUIツールを利用できるし、ネットワーク管理者が作ったプロファイルを適用すればいいだけなので、作業時の負担は少ない。現在はVMware vCenter向けのプラグインが提供されており、今後はXenやHyper-Vなど他のハイパーバイザーに対してもサポートを広げていくという。

 なお、物理スイッチについては現在、VANのエンジンからポリシーを適用できるのはトップオブラックなどのエッジスイッチに限られており、これとVMwareの仮想スイッチを連携させてVANを実現している。

 しかし、ブランチやキャンパスといった広域への対応も次段階では視野に入れているとのことで、伊佐治氏は「すべて統合し、ネットワークの仮想化を行えるようにしていきたい」とビジョンを語った。


徹底的に単純化されているVANでは、わずか2ステップでアプリケーションの導入が可能になるVANのコンポーネント。物理スイッチは現在、エッジスイッチのみの対応だが、今後はさまざまなスイッチへと拡張していく予定だ

 

IMCの価値を信じるからこそ

IMCの特徴

 では、日本HPはどうしてIMCを中核にしたネットワーク管理の変革を進めているのだろうか。それは、IMCが非常に高機能なネットワーク管理製品であり、日本HPがその力を信じているからにほかならない。

 「IMCでは、一般に“FCAPS”といわれるネットワーク管理・監視機能の5つの要素をすべてカバーすることができます。ところが他社のツールでは、Fault(障害)とConfiguration(設定)はできてもAccountingやSecurityがカバーできないなど、5つ全部をカバーできるものは少ないのです。また、とある大手ネットワークベンダーでは、製品全体をカバーしようとすると25のツールが必要なのですが、それらはバラバラで連携できません。それに対してIMCでは包括的な管理をサポートしています」と、伊佐治氏はその価値を強調する。

 さらに、データセンター内をすべて単一ベンダーでカバーするのは現実的でないため、マルチベンダーをサポートしているのも、IMCの大きな武器になる。IMCは、1500以上のCisco製品を含み、170ベンダーの6000製品以上に対応しているが、この強みを生かしていくためにVANでもマルチベンダー対応を進め、多くの環境への適合を目指しているのだという。

 「大きなネットワーク環境では、もう管理が限界だという声をよくいただいていますが、そうしたところにIMCとVANのご説明をすると、今後の可能性を含めて採用を検討していただけるようになりました。また、ネットワークスイッチだけでなく、著名なものを含め、ロードバランサーもIMCでサポートできるものが増えてきています。今後はVANにもロードバランサーの機能を載せ、レイヤ4-7のアプリケーションを仮想化する取り組みも行われています。こうした点も強調しておきたいポイントの1つです」(伊佐治氏)。

 

ユーザーの選択肢を広げるため、OpenFlowにも対応

 一方で、日本HPではユーザーの選択肢を排除しないという方針を掲げており、そのためにさまざまな選択肢を提供できるよう、複数の施策を並行して実施している。その1つとして、注目度の高いOpenFlowへの対応も進められている。

 「インフラを完全に仮想化、プール化してコントローラソフトからコントロールしようという発想は、VANもOpenFlowでも同じです。しかし、現状のOpenFlowコントローラではまだ多くの作業が必要で、ネットワークをすべてこれで管理しようというのは楽ではありません。そこで当社としてはネットワークアプリケーションとしてのVANを用意しているのですが、当社が押しつけるのではなくお客さまに選んでいただけるよう、OpenFlowが使える選択肢も提供します」と、伊佐治氏はその方針を話す。

 OpenFlow対応としては現在、HPが旧来から提供してきたProVision Asic搭載のProCurveシリーズ16製品でのサポートが発表されているほか、「HP 3800 Switch」も年内に対応する予定で、それになって20以上のスイッチがOpenFlowをサポートするとのこと。またそれ以外のスイッチに関しても“近々に”対応する方針だという。

 コントローラソフトとしては、BigSwitch、Nicira、またオープンソース系のコントローラとの検証はすでに完了。伊佐治氏は「既存スイッチのファームウェアをアップデートするだけで、しかも無償で既存スイッチをOpenFlow対応にできるのは大きなメリットでしょう。OpenFlow以外では、TRILL対応のファームウェアも近々提供される予定ですし、こうした取り組みは今後も続けていきます」と述べ、今後も幅広いサポートを提供していくとの戦略を再度強調した。


HPでは2007年からOpenFlowへの取り組みを始め、継続して取り組んできた多くの既存スイッチを無償でOpenFlowに対応させていくことで、ユーザーに選択肢を提供するという
関連情報