ネットワークエンジニアが世界を変える⑪ なぜ今、FCoE か？を、腹に落ちるまで理解すると...（後編） ----------------------------------- 前回、 「サービス指向」の意味と、それを実現するために IT インフラの仮想化が必要であ ることを述べました。 今日の話は、この続きになりますので、前編を読んでいない人は先に目を通してください ね。 http://nw-expert.jp/column/column01/198.html ＊ ＊ ＊ 仮想化には様々なメリットがありますが、 「サービス指向」を実現する目的において、IT イ ンフラを仮想化する（しなければいけない）最も重要な理由を整理すると、以下の 2 点に 集約できると思います。 ・CPU やメモリなどの物理リソースを、仮想化技術によって抽象化された仮想マシン（引 いては、仮想マシン上で動作する「サービス」）に対して、オンデマンドで柔軟に配分でき るようになる ・ 「サービス」の稼動に影響を与えずに、ハードウェアの交換や増設などのメンテナンスが 出来る 2 つ目の点について少し補足します。 前編の最後にも書きましたが、IT インフラを仮想化することによって、ハードウェアの「運 用者」と、仮想マシンから上の部分の「利用者」を明確に分けられるため、大きなビジネ ス上のメリットが期待されています。 裏返して言えば、現在の IT システムでは、「運用者」と「利用者」を切り離して考えるこ とが出来ません。 なぜかと言うと、例えば、システムの動作が不安定になり、問題箇所の切り分けをしたい 場合、どのプログラムがどのハードウェアで動作しているかを把握していなければ何も出 来ません。また、ハードウェアの交換をしたい場合、それによって、エンドユーザーにど のような影響が出るかを理解するためには、システムの依存関係を完全に把握しなければ いけません。 従って、現在は何か問題があると、 「利用者」＝「運用者」となって解決に当たらなければ いけないのです。 では、上記 2 つの目的を実現する仕組みについて、もう少し具体的に例をあげてみましょ う。 ① ライブ・マイグレーション 仮想マシンが稼動した状態で、サービスを停止することなく、異なる物理マシンへ移動で きる機能です。 （VMware の"VMotion"、Citrix Xen Server の"XenMotion"も同じです） ライブ・マイグレーションは、更なる高度な機能の基盤にもなっています。 例えば、VMware の DRS(Distributed Resource Scheduler)は、VMotion を自動実行する ことでサーバーの負荷を分散させる機能であり、同じく FT(Fault Torelance)は VMotion の動作を途中で止めることによって、2 台の仮想サーバー間を同期させた状態で冗長化（バ ックアップ）する機能です。 ライブ・マイグレーションを実行するための最低限の条件として、ネットワーク経由でア クセスできる共有ディスクを利用することがあります。 仮想サーバーが、物理サーバーの内蔵ハード・ディスクにデータを保存してしまったら、 別のサーバーへ移動できなくなりますので、考えてみれば当然のことですね。 ② サーバーのステートレス化 サーバーのハードウェアを交換すると、通常は、様々な手間が発生します。 BIOS のセットアップを行い、ハード・ディスクに OS をインストールすることは最低限必 要です。 そこで、ネットワーク経由のディスクから OS を起動する方法が考えられます。 幾つかの方法がありますが、最も自然なのは、SAN（Storage Area Network）を利用した リモートブートでしょう。 SAN で接続されたストレージは、Raw Device（ロウ・デバイス） 、つまり、CPU からは内 蔵ディスクと同じように認識されるので運用がシンプルですし、高速・低遅延でアクセス できることや、バックアップなどのツールが豊富に揃っているなどのメリットもあります。 また、最近のブレードサーバーの中には、BIOS の設定情報も抽象化して管理システム側で 保存することで、サーバーを交換しても、一切の手間が発生しないよう考えられている機 種もあります（Cisco UCS の Service Profile 機能など） こういった事を、 「サーバーのステートレス化」と呼んでいます。 「ライブ・マイグレーション」と「ステートレス化」に対応した IT インフラであれば、ハ ードウェアは、いつでも交換することが可能です。 これによって、 「ハードウェアの運用者」と「仮想マシンの利用者」を明確に役割分担でき ますね。 また、 「ハードウェアの運用者」は自社の社員である必要はなく、アウトソースしても良い し、クラウドサービスを利用してもよい、ということになります。 そして、前述のとおり、 「ライブ・マイグレーション」と「ステートレス化」が可能な IT インフラを構築するためには、リモート・ブートが可能な共有ディスクが必要であり、SAN のニーズが高まっているのです。 従来、SAN を利用するのは、データウェアハウスのような大規模なストレージを保有する 企業など、一部の顧客に限られていました。 しかし、これからは、パブリック・クラウドの提供業者はもちろんのこと、プライベート・ クウドや社内の仮想化インフラとして、SAN を必要とする企業が増加するでしょう。 ここから、やっと FCoE の出番です。 LAN の他に SAN を利用するということは、各サーバーから 2 つのネットワークへの接続 が必要ということであり、サーバー側のインタフェース・カードもアクセススイッチも 2 倍必要で、運用の手間も 2 倍かかり、コストも 2 倍になる訳です。 それをなんとか低減できないか、ということで、SAN と LAN のインタフェースを統合す るために FCoE が登場するのですね。 （FCoE そのものの説明は、ここでは割愛しますので、他の情報を参照してください） FCoE 以外にも、iSCSI（TCP/IP 上で SCSI プロトコルを転送する技術）を使って、イン タフェースを LAN に統合することが可能です。 しかし、TCP/IP は一般的な SAN で利用される FC（Fibre Channel）と比較して、遅延が 大きいとか信頼性が低いといった制約があるので、FCoE ではイーサネットを拡張して問題 を解決しています。 （機能追加されたイーサネットを、IEEE では DCB、シスコでは DCE と呼んでいます） ●参考：シスコ テクノロジー解説（FCoE） http://www.cisco.com/web/JP/news/cisco_news_letter/tech/fcoe/index.html ●参考：シスコ DCE (Data Center Ethernet) http://www.cisco.com/web/JP/solution/places/datacenter/literature/qa_c67-461717.html ＊ ＊ ＊ やっと繋がりました。先週の中島氏 vs 平井氏対談から始まり、FCoE の話まで、長い長い 旅路でしたが、皆さん、ついてきて頂けましたでしょうか。 エンジニアの思い込みで作られた「先進の技術」は、なかなか売れない場合が多いですが、 FCoE はビジネス上の必要性から生まれた「ストーリーのある技術」ですから、期待して良 いと思います。 Written by Keiichi Takagi. as of Mar 10,2010
© Copyright 2024 ExpyDoc
