Hyper-V 2.0とNetAppの導入-最新“仮想化テクノロジ”のメリット

仮想化の話に入る前に、Avanadeの企業概要について紹介させてください。Avanadeは、Microsoft®テクノロジに関する見識、斬新なアイデア、専門知識を連携させたビジネス・テクノロジ・サービスを提供し、お客様がビジネスで明確な結果を残せるよう支援しています。当社が提供するMicrosoftの専門知識には、グローバルなコンサルタント・ネットワークが生かされています。これは多くの場合、数ある同業他社に比べ、当社がより迅速に最新テクノロジを取り入れられるということです。

私の担当チームの1つであるAvanadeのDynamic Computing Services(DCS)チームの場合、特にそれがはっきり現れます。DCSは、開発、負荷テスト、コンセプトの実証(POC)のためのグローバル・プラットフォームで、社内作業とお客様向けの作業の両方をサポートしています。当チームの業務は、お客様とパートナー様向けに、Avanadeが推奨するソリューションや構成に反映されることが少なくありません。ここでは、Microsoft仮想化テクノロジ(Hyper-V™搭載のMicrosoft Windows Server® 2008 R2とMicrosoft System Centerスイート)およびNetApp®共有ストレージを使用した最近の経験に基づいて、少しガイダンスができればと考えています。この記事では、以下について説明します。

  • 当社の現在の仮想サーバ環境に関する情報
  • Hyper-V 2.0への移行に関する当社の事例
  • パフォーマンスを得るための構造
  • ライブ マイグレーションの計画
  • CSV(クラスタの共有ボリューム)に関するストレージのヒント
  • サーバおよびストレージの管理と、VM(仮想マシン)のセルフサービス・ポータル

現在の仮想サーバ環境

私が、「当社では『動的な』コンピューティング・サービス環境を運用しています」と言う場合、次のようなことを意味しています。Avanadeの社内業務環境経由で新規のプロビジョニング要求または変更要求を1件処理する間に、私たちのグループでは10~20件を処理することができます。30~40件の異なるプロジェクトを並行して進行させることもあります。当社のお客様は、ほぼすべてのエンタープライズ・アプリケーションを利用されているため、当社のVM環境でも、Microsoftアプリケーションかどうかを問わず、市場に提供されているアプリケーションはほぼすべてサポートしています。当社の現在のMicrosoft仮想化環境は、次のような構成になっています。

仮想マシン

  • 350台の仮想マシン:
    • Windows Server 2008 R2に搭載の Hyper-V 2.0上で実行される225台のVM
    • Microsoft Virtual Server 2005 R2上で実行される125台のVM
  • 2カ月以内に、Hyper-V 2.0環境でさらに200~300台のVMを追加予定

サーバ

  • Sun Fireクアッドコア・サーバ×8(それぞれ、平均100 GBのRAMを搭載)

ストレージ

  • NetApp FAS3170

この環境は、Microsoft System Center Virtual Machine Manager 2008 R2とSystem Center Operations Manager 2007 R2を使用して管理されています。図1は、このアーキテクチャのコンセプトを図式化したものです。基盤となるNetAppアグリゲート(中央の水色の部分)、ボリューム(グレーの部分)、LUN(白い部分)のレイアウトも併せて示しています。ストレージ構成の詳細については、本稿で後述します。


図1)Avanade DCS Hyper-V 2.0環境

Hyper-V 2.0への移行に関するAvanadeの事例

Avanadeでは、ライブ マイグレーションとCSV(クラスタの共有ボリューム)といったHyper-V 2.0の高可用性機能を待ち望んできました。この2つの重要な機能は、私がずっと期待していたものです。 Hyper-V 2.0が利用可能になった時点で、私はすでにその導入を決めており、しかもできるだけ早い導入を目指しました。Hyper-V 2.0のデータを入手してから24時間後には、すでに最初のクラスタを立ち上げて、そこで複数の仮想マシンを稼働させていました。2週間後には、Hyper-V 1.0システム全体(数百台のVMを含む)を完全にHyper-V 2.0へ移行しました。

Hyper-V 2.0への移行は目覚ましい効果をもたらしました。日常的にCSVとライブ マイグレーションを使用することで、私たちの業務は大きく変化しました。Hyper-V 2.0への移行後に実感した利点には、次のようなものがあります。

  • 保守の容易さと負荷の軽減:ライブ マイグレーションにより、環境内の全システムの可用性が大幅に向上しました。今では、夜間や週末を待ってハードウェアの保守を行う必要がなくなり、業務に影響を及ぼすことなく、ライブ マイグレーションを使用して日中に保守作業ができるようになりました
  • ストレージ管理の簡易化:NetAppシステムでCSVを使用することにより、Hyper-V 1.0で行っていた多くの作業(GUIDの割り当てや、各VMを専用のLUNに配置する必要性など)がなくなりました。代わりに、大容量のNetAppストレージ・プールに仮想サーバを収容することで、多くの設定が 環境側で自動的に行われます
  • サービス・レベルの向上:ライブ マイグレーションにより、私たちはすべてのHyper-V VMを同じように扱えるようになりました。今ではお客様から、ダウンタイム発生の了承を得る必要がほとんどありません。ライブ マイグレーションを使用すれば、データを別のノードへと簡単に移動できるため、お客様のシステムは稼働したままにできるからです
  • パフォーマンスの向上:CSVを使用することで、NetAppシステムの性能とスピンドルをコントロールし、パフォーマンスを最適化できる ようになりました。さらに、Hyper-V 2.0の他の機能もパフォーマンス向上に役立っています。現在、当社のR2環境は、以前のR1環境と比較して、処理速度が20~30%向上しています(パフォーマンスの詳細については次のセクションで後述)。

当社ではベータ版の段階から、Hyper-Vに関してMicrosoftアプリケーションの大規模なパフォーマンス・テストを実施してきました。アプリケーション間には明らかなパフォーマンスの違いがあるため、依然として慎重なストレージ設計が欠かせません。ただし、今までのところ、優れたパフォーマンスが発揮されています。一例を挙げると、NetAppシステムを併用したHyper-VでMicrosoft SQL Server®を実行し、毎秒5,000を超えるトランザクションの処理に成功しました(大量のトランザクション負荷を処理するには、SQL Serverをホストする仮想マシン用に専用のiSCSI接続を用意し、必要なI/Oを確保するのも1つの方法です)。

パフォーマンスを得るための構造

Hyper-V 2.0環境で、当社が20~30%のパフォーマンス向上を達成できたのには、複数の要因があります。1つは、Hyper-V自体のパフォーマンスの改善です。それに加え、本社新設に伴う動きとして、次に示すさまざまなコンポーネントがアップグレードされたことも要因になっています。

  • ネットワーク・インフラのアップグレード:当社はNetApp FAS3170用に10ギガビット・イーサネット接続を導入すると同時に、新たに全サーバに対してノンブロッキング接続を導入しました。この新しいネットワークにより、大量のI/Oを要求されるiSCSIストレージ・トラフィックとライブ マイグレーションに対して、十分なパフォーマンスが実現されます
  • サーバの統合:以前はHyper-V 1.0をサポートするために15~20台の小規模なサーバを使用していましたが、R2ではより大規模な大容量のサーバ8台に移行しました
  • ストレージのアップグレード:NetApp Performance Acceleration Module(PAM)を搭載したNetApp FAS3170システムを導入しました。これにより、I/Oスループットが向上し、ディスク遅延が大幅に削減されました。今では、より多くのディスク・スピンドルをI/Oに割り当てることができ、さらにPAMのキャッシング機能を使用することで、ランダムI/O要求の処理時間も短縮できるようになっています。

ライブ マイグレーションの計画

ライブ マイグレーションをサポートするには、間違いなく一定の計画が必要になります。この計画は、ネットワーク設計のほか、さまざまな種類のトラフィックを適切にサポートするために、サーバでいくつの物理ネットワーク・アダプタが必要になるかといった、より広範な議論の一部として扱われます。MicrosoftNetAppはいずれも、このHyper-V固有のトピックについて優れたガイダンスを提供しています。以下に、ヒントを2つ示します。

  • 設計原則1:iSCSIストレージ・ネットワークの扱いには、ファイバ・チャネル環境の場合と同じくらい注意を払います。これには、VLANやサブネットなど、ストレージ関連のトラフィックを処理する専用のネットワークとネットワーク・アダプタの計画に時間を割かなければなりません。こうすることで、物事がうまく運ぶ確率が高くなります。逆にこれを怠ると、間違いなく何らかの問題に直面するでしょう
  • 設計原則2:この原則は、1つ目の原則と密接な関係があります。簡単にいうと、他のリンクのパフォーマンスを無視して、1つのネットワーク・リンクの処理だけを優先することは避けるべきです。これは、iSCSIを使用している場合、ライブ マイグレーションのトラフィックを他のストレージ・トラフィックやエンドユーザのVMトラフィックと分離する、ということです。それには、ライブ マイグレーションのトラフィック用に専用のネットワーク・アダプタを割り当てます。また、ネットワーク・インフラを監視して、各リンクが過負荷になっていないことを確認する必要もあります(Hyper-Vと併用する専用のネットワーク・アダプタの推奨数については、サイドバーから詳しい資料を参照してください)

ライブ マイグレーションは、ネットワークの処理能力の大部分を占有します。仮想マシンの1つのノードから別のノードへとライブ マイグレーションを実行すると、移行中はネットワーク・リンクの利用率がほぼ100%に上昇します。通常、トランク構成のギガビットNICが(または、単一のギガビットNICでも)飽和状態になることはありえませんが、大半のライブ マイグレーション処理では、1つのシステムから別のシステムへとRAMの内容をコピーする作業が発生するため、ネットワーク利用率が極端に高くなるのは普通だといえます。こうした負荷により、企業のサーバとネットワーク・インフラに、従来にないレベルの処理能力が求められます。また、ごく短期間のうちに、別の弱点も顕在化するでしょう。

Avanadeでは、iSCSIトラフィックを2つの独立した専用リンクに分離する方法を選択しました(図1を参照)。現在では、ライブ マイグレーションの実行中も、ストレージの通信に影響が及ばないようになっています。

CSVに関するストレージのヒント

CSV(クラスタの共有ボリューム)はR2のもう1つの新機能です。CSVを使用すると、ストレージ構成が簡易化され、Hyper-Vを搭載した Windows Server 2008 R2のフェイルオーバー クラスタリングがより効果的にサポートされます。以前のHyper-V 1.0には設計上の制約があり、VMの高可用性をサポートするには専用のLUNを作成する必要がありました。ストレージの複雑化には目をつぶって可用性を優 先させるか、またはその逆しか選択できないということです。R2では、CSVによって多数のVMを同じLUN上に格納し、同時にVMの高可用性も実現され るようになりました。

この違いについては、Microsoftのシニア・プログラム・マネージャーであるSteve Ekren氏が、TechEd 2009で行ったセッションでわかりやすく説明しています。Ekren氏の説明から、一部を図2と図3に示します。


出典:Copyright Microsoft, TechEd 2009
図2)R2登場前のLUNとVMのマッピング


出典:Copyright Microsoft, TechEd 2009
図3)R2以降のLUNとVMのマッピング

ただし、CSVにはストレージ・システムの設計担当者にとって良い面と悪い面があります。

悪い面とは、CSVではすべてのクラスタ・ノードで共有可能なストレージ・アーキテクチャが必要となる点です。複数のVMに障害が発生すると、ストレージ・ボリュームにかかるI/O負荷も比例して増大します。これは、物理ストレージ・システムを、追加の負荷に対応できるように設計する必要があるということです。そうしないと、パフォーマンス低下やアプリケーション・タイムアウトといった悪影響だけでなく、システム・クラッシュやデータ破損まで引き起こす危険性があります。

次に、よい面について説明します。慎重に設計した適切なストレージ・システムを使用すれば、こうした問題は克服できます。この点については、NetAppに大きな違いを感じています。当社は、Hyper-V搭載のMicrosoft Windows Server 2008 R2とNetAppの統合に、とても満足しています。NetAppストレージとクラスタ構成のHyper-Vホストの連係は非常に簡単に行え、他に多くのツールを使用する場合と比べて、はるかに手間が少なくてすみます。

NetAppを使用したマルチサーバ・アクセスのサポートは簡単です。これは、NetAppとMicrosoftの技術が緊密に統合されているためです。マルチプロトコルのサポートとSnapDrive®によるストレージの直接統合機能を利用すれば、Windows®クラスタはごく簡単に構築できます。

当社の場合、NetAppアグリゲート間とスピンドル間で、どのように負荷が分散されるかを確認することが特に重要でした。図4と図5に、当社の構成の詳細を示します。


図4)NetAppアグリゲートのレイアウト


図5)各アグリゲートのNetAppボリュームとLUNのレイアウト

CSVを利用したストレージ設計のヒントをもう少し紹介します。

  • NetAppテクノロジを最大限に活用:AvanadeではNetAppテクノロジ(特にNetAppアグリゲート)を最大限活用しました。そうすることで、サーバだけでなくストレージの仮想化も可能になりました。このような使いやすいストレージ仮想化テクノロジの開発にかけては、NetAppは本当によい仕事をしていると思います。
  • 障壁の排除:何年もの間、ストレージ業界では、ワークロードごとに異なるディスク・スピンドルを使用することの価値が議論されてきました。NetAppアグリゲートを取り入れてみると、この原則の多くが必ずしも当てはまらないことがわかります。当社の設計では、2つの大規模なNetAppアグリゲート上に、少数の大容量LUN(またはCSV)を作成することができました。ストレージを統合し、アグリゲートとして利用することを、ぜひ皆さんにも検討していただきたいと思います。

    当社の場合、最大規模のアグリゲートの1つには、約35の物理ディスク・スピンドルが含まれます。この構成にすることで、それらのディスク・ドライブをすべてまとめて動作させ、アグリゲートとしての処理能力をCSV全体で共有できるようになります。NetAppシステムを使用すれば、そうした個々のディスク・ドライブの性能を簡単に統合し、平均よりずっと多くのI/O負荷に対応できます。さらにNetAppなら、あとから構成を変更することも非常に簡単なため、必要に応じて負荷の増大に対応できます。
  • CSVとNetApp重複排除技術の併用:CSV用にNetAppアグリゲートとボリュームを設計変更して以来、NetAppの重複排除を利用することでストレージ容量を大幅に削減できることがわかりました。現在当社では、仮想ストレージ・インフラ全体で平均50%の重複排除率を達成しています。重複排除前のVM環境のサイズ(約7~8 TB)を考えると、3~4 TBもの容量を削減できていることになるため、さらに多くのVMを追加しようという計画も持ち上がっています。CSVにNetAppシステムを併用する当社の使い方は、重複排除の利点を本当に生かすことができる最適な組み合わせだといえます。

まとめ

当社では引き続きHyper-VとNetAppを両方利用していますが、非常に肯定的な印象は今も変わりません。今後は、Microsoftの仮想化に対応した、NetAppの他の統合ソリューションも試してみるつもりです。具体的には、NetApp SnapManager® for Hyper-Vを使用して、データ保護を強化することなどを計画しています。Microsoft System Center Operations Managerを介したNetAppストレージの集中監視機能を向上させるため、NetApp ApplianceWatch™ PRO 2.0の使用も検討する予定です。

またNetAppと協力して、社内用のセルフサービス・ポータルを開発しています。このポータルを使用すると、たとえば3週間だけというような、仮想マシンの短期利用を申し込むことができます。このポータルでは仮想環境をすばやくプロビジョニングするために、NetApp FlexClone®テクノロジを活用します。実装には、Microsoft Virtual Machine Managerと、Microsoft PowerShell™スクリプトを組み合わせて使用する予定です。


Patrick Cimprich
バイス・プレジデント兼チーフ・アーキテクト
グローバル・テクノロジ/ソリューション担当
Avanade

Patrick Cimprich氏は19年の間、IT業界で大規模アプリケーションとストレージ・インフラの設計を手掛けてきました。Avanadeでは、データ・センター・ソリューションのグローバル・リーダーを務めるとともに、開発、テスト、ホスティングのグローバル・プラットフォームとして成長中の、Dynamic Computing Servicesも担当しています。このプラットフォームは、お客様やパートナーに構成を推奨する際、メインの性能試験基盤としてよく使用されています。

 
関連情報