誰がFCoEを管理するのか
- - PR -
Nexus 7000にとってFCoE(Fibre Channel over Ethernet)のサポートはそれほど重要ではないのだろうか。
最初から(FCoEを)持つ必要はない。プラットフォームのライフサイクルという点では重要だ。しかしFCoEがお客様に最大のメリットをもたらすのはアクセスレイヤで、サーバのケーブル数を減らすとか、複数サーバ間での移動を支えるためにインターフェイスの同一化を進める目的で使われる。
最初はサーバからネットワーク(スイッチ)への接続でFCoEが使われる。そこからファイバチャネルあるいはイーサネットにつなげられる(注:これはNexus 5000の仕事になる)。主なメリットはサーバの接続であり、現在はサーバの20%しかSANにつながっていないが、これを急速に100%に近づけることができる。これはデータ管理の観点から非常に価値がある。
次の段階はFCoE接続のストレージだが、これは重要性という点ではより小さい。ストレージ側での根本的な変化をもたらすわけではないからだ。しかしホストやターゲットの接続が進化していくと、ネクストホップとしてNexus 7000がSANにつながるようになる。製品出荷の時点で、われわれはNexus 7000でFCoEを出すと明言しており、これは変わっていない。だが、当社ではまずお客様の危急の課題を解決し、その次にネットワークアーキテクチャの進化を考える。(Nexus 7000のFCoE対応は)ビジネス面よりオペレーション面で重要だ。
逆にNexus 5000については、FCoE接続のストレージができるだけ増えることが望ましいといえるのか?
(FCoE直結ストレージは)助けにはなるが、このプラットフォームの成功に不可欠というわけではない。FCoE接続されるストレージが増えれば、より多くの顧客がFCoEの妥当性や機能に信頼性を寄せるようになる。
ストレージ管理者はFCoEへの移行を好まないのでは?
われわれはMDS製品群のおかげで、最初からストレージ管理者が異なる人種だということを理解している。従って、MDSとまったく同じツールをNexus 5000の管理にも適用できるようにするつもりだ。つまりストレージ管理者の仕事は変わらない。このため新技術への恐怖は少なくなる。
第2に、Nexus 7000では仮想化技術を導入した。「仮想デバイスコンテキスト」と呼ぶものだ。これによりストレージ管理者はFCoEを見ることができ、ネットワーク管理者はイーサネットあるいはIPプロトコル部分を見られるようになった。どちらも互いの領域に足を踏み入れることがなくなる。同じ機能は試験段階のネットワークと本番ネットワークとの間でも使える。LANとSANを分けられるし、複数の事業部門も分けられる。こうした機能は個々の役割や責任の維持に貢献する。
ただしその一方で、テクノロジが進化するたびに、そしてネットワークが速くなるたびに、コンバージェンス(統合)が起こることはたしかだ。FDDI、ATM、トークンリングでも、音声とビデオ、データの統合でもこれが起こった。われわれはできるだけ急激な変化をもたらさないように努力する。しかし新技術を最大限に、最適な形で利用しようとする場合、組織やプロセスにおける変更を伴うこともある。
ネットワークサービスと仮想マシンの親和性
(サーバ仮想化の進展に際して)シスコは負荷分散、セキュリティなどの機能をどのように実装していくのだろうか? サーバ仮想化インフラの運用担当者はこうした機能を仮想マシンとして利用したがるのではないか。そのほうが(アプリケーションを稼働する)仮想マシンとの関連付けはしやすいはずだ。
それと同じような話は一部の顧客からも聞いている。一部のサービスが仮想マシンとして提供されるべきであるという点に異論はない。
Nexus 1000Vを設計した際に解決しようとしていた問題は、(同一物理サーバ上の)各仮想マシンが(ハイパーバイザの)仮想スイッチを通じ、ネットワークポリシーをバイパスする形で、同一のハイパーバイザ上のほかの仮想マシンと通信できてしまうことだった。仮想マシン1が仮想マシン2と話すことができないというACLを、インフラ上のあらゆるスイッチに設定することは可能だ。しかしこの2つの仮想マシンが同一の物理サーバ上にあると、これらは直接話し合えてしまう。
最初考えられた解決策は、複数のVLANを各仮想マシンに対して構成することだった。これは効果的だが、ネットワーク的には悪夢のような構成だ。あらゆる仮想ポートがそれぞれ802.1Qトランクとなり、それぞれVLANが構成されている状態だからだ。そこでわれわれはNX-OSを仮想スイッチの部分に組み込んだ。これがNexus 1000Vだ。これにより、ネットワーク側で設定したポリシーを、(ハイパーバイザ内にも)適用できるようになった。すべての仮想マシンを可視化し、これに対する透過性を得られたことになる。しかも仮想マシンが(物理サーバ間を)移動したとしても、すべてのポリシーは、カウンタレベルまで含めて一緒に移動できる。こうしたメカニズムは(サーバに)組み込む意味がある。
どんな仮想マシンでもCPUやメモリを消費する。もし負荷分散機能を仮想マシンとして実装したとすると、すべてのトランザクションでトラフィックがI/Oバスを二重に行き来することになる。また、多くの負荷分散メカニズムはSSL処理を行うが、x86の汎用プロセッサは暗号処理に向かない。このためパフォーマンスで大きな問題を生じる。当社の暗号化処理チップははるかにパフォーマンスが高く、消費電力も少ない。
ネットワーキング技術が仮想マシンとして動く可能性がないとはいわないが、適切な技術を選んで仮想マシンとして稼働すべきだ。
2/3 |
Index | |
シスコはデータセンターをどう変えられるか | |
Page1 マイクロソフトとも仮想化で組まない理由はない |
|
Page2 誰がFCoEを管理するのか ネットワークサービスと仮想マシンの親和性 |
|
Page3 インテリジェンスをどこに置くか タグを活用する意味 |
- Windows 10の導入、それはWindows as a Serviceの始まり (2017/7/27)
本連載では、これからWindows 10への移行を本格的に進めようとしている企業/IT管理者向けに、移行計画、展開、管理、企業向けの注目の機能について解説していきます。今回は、「サービスとしてのWindows(Windows as a Service:WaaS)」の理解を深めましょう - Windows 10への移行計画を早急に進めるべき理由 (2017/7/21)
本連載では、これからWindows 10への移行を本格的に進めようとしている企業/IT管理者に向け、移行計画、展開、管理、企業向けの注目の機能を解説していきます。第1回目は、「Windows 10に移行すべき理由」を説明します - Azure仮想マシンの最新v3シリーズは、Broadwell世代でHyper-Vのネストにも対応 (2017/7/20)
AzureのIaaSで、Azure仮想マシンの第三世代となるDv3およびEv3シリーズが利用可能になりました。また、新たにWindows Server 2016仮想マシンでは「入れ子構造の仮想化」がサポートされ、Hyper-V仮想マシンやHyper-Vコンテナの実行が可能になります - 【 New-ADUser 】コマンドレット――Active Directoryのユーザーアカウントを作成する (2017/7/19)
本連載は、Windows PowerShellコマンドレットについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、「New-ADUser」コマンドレットです
|
|