シスコはデータセンターをどう変えられるか

　インテリジェンスをどこに置くか

　その負荷分散メカニズムはNexusシリーズに搭載するのか？

　Nexusスイッチに直接統合してはいないが、われわれにはACEアプライアンスがあり、これをつなげることができる。

　当社の戦略やサービスは過去3〜4年の間に大きく進化した。すべてのスイッチにモジュールとして各種のサービスを組み込むことを考えた時期はあった。スイッチに空きスロットがあれば、これにサービスモジュールを入れるのは簡単だ。

　そのうちいろいろな教訓を学んだ。喜んでくれる顧客もいれば、毛嫌いする顧客もいる。毛嫌いされる理由は、OSが違うし、コマンドラインも違う。依存性やバージョン管理の問題も発生する。つまり負荷分散モジュールをバージョンアップすると、スイッチコアのOSもバージョンアップしなければならないといった問題が起こる。

　最後の問題は電源容量だ。Nexus 7000にはスロット当たり800Wの容量を用意している。しかし、800Wではバックプレーン容量の20％に対しても十分な速さを発揮する負荷分散モジュールをつくることができない。現在のハイエンド製品であるASA 5580は1200Wのプラットフォームで、これでやっと10Gbps（の処理能力）だ。もし10Gbpsの処理能力のモジュールをNexus 7000のスロット1つに組み込んだとしても、そのスロットで使える220Gbpsの容量を無駄にすることになる。

　そこでわれわれは多少異なる解決策を考えることにした。今後われわれが提供を考えているのは、Nexus 7000のようなシャーシと、セキュリティについてはASA、負荷分散についてはACEといったアプライアンスを、ソフトウェアで非常に緊密に結び付けるということだ。

　これにより、コントロールプレーンが正しい振る舞いだと判断したトラフィックについては（ファイアウォールなどを）ショートカットすることができる。例えば1GbpsのSecure FTPセッションに対してファイアウォールができることは限られている。それなら高速にパケットを移動するという、スイッチの本来の目的である機能を果たせばいい。あるいはトラフィック容量が増えた場合に、人がまったく設定にかかわることなくファイアウォールの数を増やせるようにすることが考えられる。つまり容量が足りなくなったら、追加のファイアウォールを接続して電源を投入しさえすればいいというものだ。これだけで、スイッチが利用できるファイアウォールのリソースに対して自動的に負荷分散を行えるようになればいい。

　コントロールプレーンの容量に対応し、必要に応じて動的にファイアウォールの容量を追加でき、必要でなくなれば電源をオフする。Wake-on-LANや遠隔シャットダウン・コマンドを使って、運用環境全体の電力効率を向上することが可能だ。こうしたことは当社が現在提供しているテクノロジを活用して実現できる。

　こうしたテクノロジは何にも増して、アプライアンスとコントロールプレーンの間に非常にリアルな関係を構築し、パフォーマンスの向上、構成の容易化、電力効率の向上を実現する。

　つまり、われわれが目指しているのはこういうことだ。

　まず、コンポーネントはそれぞれ独立して役割を果たせなければならない。標準以下のファイアウォールを提供して、「これで大丈夫です」と言いたくはない。当社が業界をリードするスイッチを提供しているからといって、ごまかしたくはない。われわれは業界最高のファイアウォールや負荷分散装置を提供したい。

　その後で、ソリューションやシステム全体が1つのユニットとして一緒に動けるようにしていきたい。すなわち、それぞれがスタンドアロンでも十分機能を果たすが、まとまることでさらに価値が生まれるようにしたい。

　タグを活用する意味

　その話は分かるが、例えばサーバ仮想化運用の担当者は、新たな仮想マシンを作る際に、セキュリティと負荷分散のポリシー設定を即座にその仮想マシンに関連付けられるようにしたいはずだ。

　われわれはVN-Linkテクノロジを提供している。サーバに統合されるNexus 1000Vがあり、リンク上ではVNタグが利用できる。VNタグは1つ１つの仮想マシンについて、そのアイデンティティをネットワーク経由でネットワーク機器に伝達できる。これを使ってポリシーを仮想マシンに適用できる。「この仮想マシンは負荷分散の対象だ」とか「この仮想マシンはファイアウォールで保護されなければならない」、「別個のファイアウォールのインスタンスを適用しなければならない」といったポリシーを伝えられる。

　従って、新たな仮想マシンを立ち上げた場合、これに適切なVNタグを付けさえすればいい。この機能はVirtualCenter（VMｗare Infrastructure 3で提供されている管理サーバ。現在の製品名はvCenter）に統合されているので、ポートプロファイルに「電子メールサーバ」だとか「○○の電子商取引用Webサーバ」といったタグを適用すればいい。適切なVNタグを付ければ、これがリンクを通じてハードウェアにプロトコルレベルで伝わる。（セキュリティやネットワークのサービスを仮想マシンとして稼働するための）CPUやメモリを消費したり、仮想マシンの稼働可能数を減らしたりといったことは不要だ。

　これは普通とは異なるアプローチだ。しかし最終的には効率的だと考えられるようになるだろう。適切な場所で適切な仕事を行い、同時に迅速なサービスの展開という運用上の要件に対応できる。

　こうしたシナリオでは、あるIPアドレスが仮想マシンかどうかについてASAやACEは知る必要はないということか。

　そうだ。これらの機器にとってはIPアドレスでしかない。1台の物理サーバに20個かもしれないが、IPアドレスであることに変わりはなく、これら機器の仕事に影響はない。影響があるのは、仮想マシンが移動するものであるという要素だ。われわれはサービスを豊富に利用する環境における仮想マシンのモビリティをどう認識し、対応するかについて、まだ開発を続けている。例えば仮想マシンの移動に応じて、適用する負荷分散のインスタンスを別のACEに切り替えるのはどうすればいいかという問題だ。

　まだこの問題は解決していないが、解決するつもりだ。仮想化への対応に成功すれば、ネットワークや高度なネットワーク上のサービスの役割を、大きく変えることになると思う。こうしたことを実現できる競合他社はいない。

3/3

Index
シスコはデータセンターをどう変えられるか
	Page1 マイクロソフトとも仮想化で組まない理由はない
	Page2 誰がFCoEを管理するのか ネットワークサービスと仮想マシンの親和性
	Page3 インテリジェンスをどこに置くか タグを活用する意味