基幹系サーバ統合に適したストレージ・ネットワーク要件を探れ！：サーバ仮想化のカギはストレージ・ネットワークにあり
ITリソースの利用効率を高める手法として、サーバ仮想化を導入する企業が増えている。小規模な環境でその効果を実感し、今後より大規模なサーバ統合を目的に、さらなる導入を進めようと考えているIT部門担当者も多いのではないだろうか？ しかし、より多くのサーバを仮想化によって統合しようとしたとき、あるいはより重要度の高いアプリケーションのためのサーバを統合しようとしたとき、新たに考慮すべき要件はないのだろうか？ サーバ仮想化のメリットを最大限に得るためのストレージ・ネットワークの姿を探ってみよう。
iSCSI？ それともFC？ ミッション・クリティカルなアプリケーションに耐えられる性能と信頼性を得られるか？
ある中堅企業の情報システム部門に勤務する入社7年目のケイコと、入社3年目のタカシ。2人は、サーバ仮想化を中心にしたシステム全体の再構築プロジェクトを任されている。第1フェーズで実施した小規模なサーバ統合では良い結果を得られたのだが……。
ケイコ 昨年実施した第1フェーズでは情報系やWebなどのサーバの統合に成功したわけだけど、これから着手する第2フェーズではいよいよ基幹系サーバの統合に取り組むことになるわ。予算の制限も厳しい中、初期投資を抑えながら最適な環境を構築するにはどうしたら良いと思う？
タカシ え？ 基本的に第1フェーズと同様の考え方で大丈夫なんじゃないですか？
ケイコ そうね。でも今回のプロジェクトは大規模だし、トラフィックも大きくミッションクリティカルなアプリケーション群が対象になるのよ。第1フェーズでは、それほど負荷の大きくないWebサーバが多かったこともあって、ストレージ側には低コストで手軽に使えるiSCSI接続のストレージを採用したけど、今回も第1フェーズと同様の環境で対応しきれるかしら？
タカシ 確かに、仮想化によって複数のアプリケーションが一つのサーバで稼働するようになると、トラフィックの増加による性能の問題が気になりますね。でも、iSCSIでは本当に必要な性能を満たすことはできないんですか？
ケイコ 現在、基幹系のアプリケーション用にはFCで接続されたストレージを採用しているでしょ。そもそもFCは、高性能で低遅延という点でミッション・クリティカルなデータ用のストレージ・アクセスの技術として実績があるけれど、実は仮想サーバ環境にもとっても相性が良いのよ。
タカシ でも、第1フェーズの環境ではiSCSIでまったく問題ありませんでしたよ。
ケイコ そう、対象となるデータの重要度や求められる性能、さらにどのレベルの信頼性や耐障害性が要求されるかなどによって、ストレージ側の構成を検討する必要があるっていうことなのよ。
タカシ なるほど。勉強になりました。
ひと言でサーバ統合といっても、統合するサーバの用途によって、ストレージ構成の選択肢はさまざま。iSCSIやNASは一般的に安価であり、サーバとの接続もイーサネットで済むので手軽だ。Web系アプリケーションや開発・検証用など、比較的ライトな用途に適している。しかし、データ転送負荷が大きい場合には、ボトルネックとなる危険がある。特に、基幹系システムで大量のデータベースアクセスを行うような場合は、転送効率が大きく低下する場合がある。仮想サーバ環境でのストレージ接続には、その用途や条件を考えて最適なものを選択しよう。
●サーバ仮想化におけるiSCSiとFCの比較
|
アプリケーションの優先度に応じたエンド・トゥ・エンドの帯域制御とは？
タカシ ケイコさん、ケイコさん！ FC-SANをベースにしたテスト環境で負荷の高いアプリケーションを流してみたんですが、なんだかうまくいきません。
ケイコ うまくいかないって具体的にはどういうこと？ 慌てないでちゃんと話してみて。
タカシ はい。どうやらサーバを統合したことで、ストレージへのアクセスがサーバ上で集中してしまって、そこで輻輳が生じてしまっているみたいなんです。でも、FCってそもそも帯域を全部使い切らないっていう想定じゃなかったんでしたっけ？
ケイコ そうか。仮想サーバ上では1つの仮想OS・アプリケーションだけで帯域を占有することができないから、そういった問題が生じてしまうのね。でも大丈夫よ。今回、ストレージ・ネットワークのコアには、ポート単位で帯域を制御することができるバックボーン・プラットフォームを採用するつもりなの。
タカシ へえ。そんな機能があるんですね。あれ？ でも、仮想化したサーバからのアクセスを、どうやってQoS管理すればよいのですか？ だって、ポート単位じゃなくて、仮想サーバ単位でアプリケーションごとに管理できなければ、あまり意味がないんじゃ……？
ケイコ さすが、タカシくん。そう、タカシくんの言うとおり、仮想サーバ環境ではポート単位の管理では不十分。仮想サーバの組み合わせによっては、重要なアプリケーションに十分なスループットが出ないと文句を言われそうね。
タカシ じゃあ、どうすれば……。
ケイコ 実はね、サーバ側に実装するホスト・バス・アダプタとSANとの間で連携して、仮想サーバ単位でのQoSを提供するソリューションがあるのよ。例えば、テープ・バックアップなどはトラフィックが集中するアプリケーションだけどビジネス上の重要度が高いわけじゃないわよね。一方で、トラフィックは集中しないけど、ビジネス上の重要度が高いオンライン・アプリケーションがある場合、優先度の高いデータ転送を確実に行うために、優先度の低いアプリケーションが帯域を占有しないように制御できるのよ。
タカシ じゃあ、仮想サーバを別の物理サーバに移動させた場合はどうなるんですか？ ビジネス要件に応じて柔軟にアプリケーションを移動させることができるのも、サーバ仮想化の大きなメリットですよね？
ケイコ その場合も、仮想サーバに割り当てられた条件を引き継いだまま移動させることができるのよ。
タカシ なるほど。サーバからストレージ・ネットワークまでのQoSか。新しい技術がいろいろあるんですね。
FC-SANはデータ転送のオーバーヘッドが小さく、転送効率が高い。もちろん高負荷のDBアクセスにも強い。昨今のデータ量の増加、ストレージ・アクセスへの負荷増大に対応するため、SANのコアとなるプラットフォームにはポート単位でのQoS制御も盛り込まれるようになってきた。しかし、仮想サーバ環境ではアプリケーションごとのより細かいレベルでの帯域制御が必要となる場合がある。起動用OSイメージの管理に共有ストレージを使うケースが増えてきているが、その管理にもFC-SANストレージの柔軟性や可用性が役に立つ。
仮想サーバ環境の管理効率とセキュリティを向上するストレージ・ネットワークとは？
タカシ ケイコさん、ケイコさん！ 仮想サーバ環境にする場合、単一の物理的な接続では、個々の仮想サーバに対して独立したストレージ・アクセスを提供することができないっていう話を聞いたんですが。
ケイコ そう、その点は実は気になっていたのよ。仮想サーバ環境でも物理サーバ環境でも同等の安全性が要求されるのに、すべてのストレージポートと論理ユニットが仮想サーバ全体に公開されてしまうの。これではセキュリティ上も問題だし、管理の面でも問題だわ。
タカシ え、じゃあ、どうすれば……。
ケイコ 大丈夫。この問題を解決する技術がちゃんとあるのよ。「NPIV=N_Port ID Virtualization」を使えば、1台の物理サーバで、仮想サーバ用に255個までの固有のIDを割り当てることができるの。
タカシ ポートIDを仮想化するっていうことですね？ なるほど。
ケイコ NPIVを使えば、仮想サーバ環境でも標準的なファブリック・ゾーニングやLUN（論理ユニット）マスキングといった機能を使えるようになり、物理サーバ環境と同様、適切なアプリケーションに対して適切なLUNを割り当てられるの。
タカシ そうか。それならセキュリティの面でも管理効率の面でも問題ありませんね。
サーバ仮想化を、より大規模でミッション・クリティカルなアプリケーション環境にまでおよんで導入しようとした時、小規模な環境やテスト環境とは異なる要件が発生してくる。サーバ仮想化のメリットを最大限に得たいのであれば、ストレージ・ネットワークを最適化することも忘れずに検討しよう。
まとめ：現状の効率化から、将来の拡張まで――Brocadeデータセンター・ファブリック（DCF）ソリューション
現在、データセンターにあるサーバのうち、ストレージ・ネットワークに接続されているストレージは全体の約20％に過ぎないと言われている。しかし、今後ますますサーバの仮想化が進んでいくとこの割合は増していくと考えられている。というのは、より大規模な共有ストレージ・プールにより多くのサーバがアクセスできるようにすることで、システム全体としてのリソース利用率や可用性を向上できるからだ。
ネットワーキング・ソリューションの先進ベンダーであるブロケードは、HBAからSANスイッチ/ダイレクタ、バックボーン･プラットフォーム､SAN管理ツールまで、エンド・トゥ・エンドでさまざまな機能やサービスを含むFC-SANソリューションを提供している。ケイコさんとタカシくんが挙げていたような、サーバ仮想化環境におけるさまざまな課題を解決する、現在から将来の要求、今後のテクノロジまでを見据えた製品やソリューションにより、柔軟性と拡張性に優れたデータセンター・ファブリックを実現している。
■Brocade DCXバックボーン製品ファミリ： ファイバチャネルやiSCSI、FCIP、FICON、さらには後述する新しい技術CEE(Converged Enhanced Ethernet)やFCoE（Fibre Channel over Ethernet）など、多彩なプロトコルに対応するマルチプロトコル・データセンター・バックボーン。384ポートまで収容の大規模環境向けBrocade DCXと、192ポートまで収容の中規模から大規模環境向けBrocade DCX-4Sの2つのタイプで提供。どちらも仮想化環境での運用に対応したQoS管理や、NPIV（N_Port ID Virtualization）などの機能も備えている。
■Brocade HBA製品ファミリ： 4ギガビット/秒および8ギガビット/秒対応のファイバーチャネルHBA製品群。他社製品に比べて2倍以上の500,000 IOPSを実現。各種インテリジェント・サービスを実装し、Brocade製スイッチ製品とのエンド・トゥ・エンドでのQoS管理にも対応する。
■NPIV（N_Port ID Virtualization）： ANSIの標準規格で、仮想サーバ環境において重要な要素となる技術。通常、サーバのHBAポートには物理ポートに対応した固有のID(WWPN: World Wide Port Name)が割り当てられており、そのIDとLUNのIDとでアクセスを制御する。しかし、そのサーバ上に複数の仮想サーバが稼働している場合、各仮想サーバが各LUNを区別することができない。これに対しNPIVでは、1つのHBA当たり255個までのWWPNを利用でき、仮想サーバごとに固有のWWPNを割り当てられる。Brocade DCXバックボーン製品ファミリおよびHBAでサポート。
■FCoEへの対応： ストレージ・ネットワークの新しい技術として現在標準化が進められているFCoE。FCoEは、サーバ接続の複雑性を軽減しながら、実績に裏づけされたファイバーチャネルの技術、および既存のファイバーチャネル資産をそのまま活用できる点で期待されており、複雑さの軽減、投資の保護という観点でも、サーバ仮想化環境を強力にサポートする。ブロケードでは、FC-SANの将来を見据え、さらなる効率化を可能にするFCoEなどの次世代ネットワーク標準の策定においてもリーダーシップを取り積極的に関与している。Brocade DCXバックボーン製品ファミリは、すでにFCoEにも対応するような設計がされており、最適なタイミングで必要に応じて導入可能になっている。
ホワイトペーパーダウンロード
データセンターにおけるサーバ仮想化の成否は、ストレージネットワークで決まる！
サーバ仮想化の効果を最大限に引き出すためには、より大規模なストレージリソースへのアクセスが不可欠だ。サーバ仮想化の導入において見落としがちなストレージネットワーク構築のポイントを解説する。
仮想化によるサーバ統合を実施している企業が増えている。仮想化をより大規模に導入してその効果を最大限に引き出すためには、大規模に統合されたストレージリソースへのアクセスを提供し、システム全体で最適化を図ることが重要となる。では、実際にサーバ仮想化環境に最適化されたストレージネットワークを構築するには、どのようなポイントを考慮すべきなのだろうか？
本ホワイトペーパーでは、サーバ仮想化の効果を引き出すために最適化されたデータセンター・ネットワーク構築のためのアーキテクチャと関連する技術動向を解説する。
Copyright © ITmedia, Inc. All Rights Reserved.
提供：東京エレクトロン デバイス株式会社、ブロケード コミュニケーションズ システムズ株式会社
企画：アイティメディア営業本部／制作：ITmedia エンタープライズ編集部／掲載内容有効期限：2009年4月30日
ITmediaはアイティメディア株式会社の登録商標です。