NetApp Tech OnTap
Hyper-Vの導入

Avanadeのビジネスが成功するかどうかは、当社のグローバルコンサルタントが企業クライアントのニーズにうまく対応できるかどうかに懸かっています。当社では、目標達成に必要なあらゆるデジタルツールを提供するITアプリケーションとサービスに積極的に投資しています。Microsoft® Hyper-V™によるサーバ仮想化への移行に踏み切った最大の理由の1つは、このソリューションによって提供される柔軟な災害対策と可用性シナリオにあります。このタイプのアーキテクチャを共有型ストレージバックエンドと組み合わせた場合、別のローカルノードへのアプリケーションとサービスのスムーズなフェイルオーバー、およびリモートデータセンター間での複製が可能になり、さまざまな災害からの保護が可能になると確信しました。

Hyper-Vへの移行を決定した背景には、その他の要因もありましたが、最終的には仮想サーバ環境の柔軟なリストアとリカバリによる災害対策が決め手となって、CIOから多額の先行投資への承認が下りました。Hyper-Vに決定したその他の要因としては、次のようなニーズがありました。

  • サービスの品質を落とさずに、データセンターコスト(ラックスペース、電力、冷却)を削減したい
  • 強力なサーバリソースをさらに活用したい
  • 新しいアプリケーションサーバ環境をより迅速に導入したい

当社はこれらすべての点を改善できればと考えていました。その点を踏まえて、当社はリリース前のMicrosoft Windows Server® 2008とHyper-Vのベータユーザとして名乗りを上げました。それが本当のスタート地点でした。

Hyper-Vの導入

当社の現在のHyper-V環境について説明する前に、Hyper-Vを実装する前のIT環境について、簡単に背景を説明します。当社の環境は3箇所のデータセンター(米国、ヨーロッパ、アジア)で構成されています。コンサルタントが利用するアプリケーションサービスの大部分は、シアトルにある米国データセンターから配信されています。Hyper-Vの導入を開始した時点では、200台以上の分散型サーバで8,000人を超えるAvanade専門スタッフの業務をサポートしていました。

AvanadeはMicrosoftとAccentureのジョイントベンチャーであるため、当社のIT環境は、主にMicrosoft製アプリケーションに依存しながら、現場スタッフと全社的な業務をサポートしています。これらのアプリケーションには、大規模なMicrosoft Office SharePoint® Server環境のほか、Microsoft Exchange、Microsoft SQL Server®、Microsoft Team Foundation Server、Microsoft Terminal Services、そしてWebフロントエンドを使用する120の基幹アプリケーションが含まれます。

今後の仮想サーバ環境をフルに活用するため、Microsoft Hyper-Vを共有型ストレージインフラと組み合わせることに決定しました。当社はすでにNetApp®ストレージをiSCSIで運用し、SQL Serverインフラをサポートしていました。そのため、Hyper-V環境のサポートには当然、NetAppを検討するのが妥当と思われました。データの保護と複製に使用しているNetApp Snapshot™やSnapMirror®などのテクノロジの柔軟性と効率性を、当社では高く評価していました。そして、新しいアプリケーション用のストレージを迅速にプロビジョニングする体制が整い、NetAppの重複排除機能をプライマリストレージで利用してキャパシティを節約することも検討し始めました。

その場合、当社の他の環境と同じようにHyper-VにもNetAppが適していると予測されます。Hyper-VおよびiSCSIでNetAppを使用してパフォーマンステストを実行した結果、NetApp/Hyper-Vの組み合わせに要求される高度なパフォーマンスが得られることが確認されました。

当社ではHyper-Vへの移行を決定して以来、業務環境とテスト/開発の2つの環境でHyper-Vを導入しています。当社の現在の環境の特徴のいくつかを以下にまとめます。

業務環境

  • Microsoft Hyper-V for Windows Server 2008、コアインストール、Enterprise Edition
  • 4ノードのHyper-Vクラスタとして構成
  • 27の子パーティション(仮想マシン)
  • 仮想化アプリケーションはWindows Server 2003またはWindows Server 2008ゲストOSのいずれかで稼働
    仮想化アプリケーション
  • Team Foundation Server
  • Systems Center Operations Manager 2007
  • Microsoft Windows Server 2008 Terminal Services(TSファームおよびTSゲートウェイ)
    サーバとストレージ
  • Sun Fire X4150サーバ(それぞれクワドコアプロセッサ×2、32 GB RAMを搭載)
  • NetApp FAS3040ストレージシステム(iSCSIプロトコルで構成)

開発/テスト環境

  • Microsoft Hyper-V for Windows Server 2008、フルインストール、Enterprise Edition
  • 4ノードクラスタ×1
  • 2ノードクラスタ×1
  • スタンドアロンサーバ×3
  • 開発/テスト用Hyper-Vホスト上の子パーティション(仮想マシン)150以上
    仮想化アプリケーション
  • 業務アプリケーションを含む多様なアプリケーション
    サーバとストレージ
  • Dell 2950サーバ(それぞれクワドコアプロセッサ×2、32 GB RAMを搭載)
  • NetApp FAS3020ストレージシステム(iSCSIプロトコルで構成)

VMware DRS

図1) NetAppがサポートするAvanadeの4ノードHyper-Vクラスタ

Hyper-V導入に至るまでの判断

当社での導入体験を振り返ってみると、いくつかの重要事項で決定した方針が、プロジェクト全体の成功に大きく貢献していることがわかります。具体的な決定事項は次のとおりです。

  • 導入するMicrosoft Windows Server 2008エディションの選択。フルエディションか、またはより軽量なWindows Server Core Editionか。
  • Hyper-V子パーティションのVirtual Hard Disk(VHD)ファイルと連携するためのNetAppシステムの設定方法。
  • 新しいVHDを迅速にプロビジョニングし、既存のHyper-Vノードに接続するプロセスの開発。

Microsoft Windows Server 2008 Core Editionの選択
Windows Server 2008のServer Coreを使用するか、それともフルエディションにするかを決定するのに、しばらく時間がかかりました。セキュリティの観点から考えると、Server Coreならフットプリントがはるかに小さいことは明らかであり、パッチを適用する頻度が少なくなると思われました。これは重要なポイントでした。というのは、各ホストで最終的に10、15、あるいは20もの仮想マシンが稼働することが見込まれたからです。VMの高可用性を保つには、ホストサーバのリブート回数を最小限にする必要がありました。

ただし、Server Coreにはコマンドラインインターフェイスがあり、それが現場のオペレーションスタッフには少々荷が重いのではないかと思われました。スタッフからは「コマンドラインインターフェイスの管理やトラブルシューティングを自分がうまくこなせるかどうか」という声が聞かれました。繰り返し交渉した結果、Server Coreで行くことに決定しました。これは結果的に大成功でした。導入後、Server Coreは問題なく動作しており、非常に安定したインフラを提供しています。サポートスタッフは引き続き、Windows Server 2008の標準ツール(MMCスナップインやリモートサーバ管理ツールなど)を併用することができます。この体験から当社の全員がServer Coreの熱烈なファンになりました。

Hyper-V子パーティションおよびVHDと連携するためのNetAppストレージの設定

NetAppの重複排除機能およびSnapshotテクノロジはボリュームレベルで動作することがわかっていたので、これらの機能を可能な限り活かせるように、Hyper-V子パーティション用のストレージを設計することにしました。
同じゲストOSのインスタンスには重複するデータが非常に多いため、Hyper-V VHDが存在する開発/テスト用ボリュームにNetApp重複排除を実行すれば、著しい節約効果が見られるものと期待しました。その期待どおり50%以上のスペースが節約されました。現在、業務環境にも重複排除機能を導入することを検討しています。これらのボリュームレベル機能に関して、当社で採用したプラクティスは次のとおりです。

  • 同じゲストOSを実行する子パーティションを、同じNetAppフレキシブルボリューム(FlexVol®)にグループ化する。
    当社の業務環境の場合、Windows Server 2003子パーティションを1つのボリュームに集め、Windows Server 2008パーティションを別のボリュームに集めるという意味になります(開発/テスト環境では、NetApp Snapshotを使用して環境全体をテスト用にすばやくバックアップまたはリストアできるので、このルールは若干緩和されます。その場合、環境を複数のゲストOSで構成することができます)。
  • VHDとLUNに1:1マッピングを採用する。
    子パーティションごとに、子パーティションのVHDファイルと関連データを保存する1つのLUNを対応付けます。子パーティション同士を相互に独立させるため、この1:1マッピングによって子パーティションが同一のLUNを他の子パーティションと共有しないようにします。ただし、同一のNetAppボリュームに多数のLUN(およびVHD)が存在することは可能です。
  • MicrosoftのボリュームGUIDを使用して、それぞれの子パーティションに一意の識別子を割り当てる。
    Hyper-Vクラスタには多数の仮想マシンが存在するため、ドライブ文字ではすぐに底をついてしまいました。マウントポイントを使用すると、ディスク間に不要な依存関係が成立してしまうので、この方法を選ぶわけにはいきません。当社では、ボリュームGUIDを使用してクラスタ上の各ディスクを識別することにしました。文字で表されるドライブ(E:ドライブなど)にLUNを保存するよりも、ドライブ文字を割り当てないことを選びました。その場合、次のような形式のGUIDが割り当てられます。\\?\Volume{c9612f6f-702e-11dc-b79a-00123f769676}\

次に、業務環境および開発/テスト環境における現在のストレージ構成について説明します。

業務用Hyper-V環境のストレージ構成
2つのNetApp FlexVolで、それぞれの子パーティションに関連するデータを保存しています。パフォーマンスを最大化するため、子パーティションのVHDファイルはHyper-Vで「固定VHD」ファイルとして構成しています。NetApp重複排除テクノロジを導入すれば、動的VHDの場合のようなスペース節約効果が得られることがわかっていたからです。

ボリューム1:

  • 7つのWindows Server 2003子パーティション(仮想マシン)のデータを保存しています。子パーティションのデータはそれぞれ専用のiSCSI LUNに保存されます。
  • ボリューム全体で500 GBのストレージ容量を割り当てています。
  • ボリュームの利用率は現在48%です。

ボリューム2:

  • 20のWindows Server 2008子パーティションのデータを保存しています。子パーティションのデータはそれぞれ専用のiSCSI LUNに保存されます。
  • ボリューム全体で1.25 TBのストレージ容量を割り当てています。
  • ボリュームの利用率は現在76%です。

開発/テスト環境のストレージ構成
30以上のNetApp FlexVolで、子パーティションに関連する開発データまたはテストデータを保存しています。テストおよび開発中に簡単にサイズを増減できるようにするため、子パーティションのVHDファイルはHyper-Vで「動的VHD」ファイルとして構成されています。

ボリューム1:開発用

  • 25のWindows Server 2008子パーティションのデータを保存しています。
  • 子パーティションのデータはそれぞれ専用のiSCSI LUNに保存されます。
  • LUNのサイズは40~100 GBです。
  • ボリューム全体で600 GBのストレージ容量を割り当てています。
  • ボリュームの利用率は現在39%です。

32以下のボリューム:開発チームとテストチームが共用

  • 一連のボリュームで100超のWindows Server 2008 Hyper-V子パーティションのデータを集合的に保存しています。
  • 子パーティションのデータはそれぞれ専用のiSCSI LUNに保存されます。
  • LUNのサイズは平均20 GBです。
  • 各ボリュームには平均3つのLUNがあります。
  • 一連のボリュームに全体で2.5 TBのストレージ容量を集合的に割り当てています。

新しいLUNとVHDの迅速なプロビジョニング
当社がNetAppを高く評価していた点の1つは、バックエンドストレージアレイの柔軟性です。わずか5分で新しいLUNをプロビジョニングし、新品のディスク(VHD)をHyper-Vノードに接続する方法を、容易に開発することができました。当社はセキュアシェル(ssh)コマンドをラップアラウンドした一連のスクリプトを開発しました。これらのスクリプトによってLUNが作成され、そのLUNが自動的にHyper-Vクラスタに接続されます。以後、このプロセスにより、LUNプロビジョニングが自動化されています。今後、このプロセスを完全に文書化し、アプリケーション担当者にその文書を渡せば、担当者が自分でLUNプロビジョニングを実行できるようになると期待しています。ホストにアクセスして、コマンドを実行すればLUNが接続されるという、非常に簡単なプロセスです。

今後の計画

これまでの経験から判断すると、今後、すべてを仮想化することは十分に可能だと考えています。目標とするアーキテクチャは、Hyper-VクラスタとSQL Serverクラスタの両方がNetAppストレージに接続された状態を目指しています。当社で使用しているすべてのフロントエンドアプリケーションは、最終的には、Hyper-Vクラスタで仮想化することになるでしょう。このクラスタは4ノードから最大8ノードに成長すると予測しています。さらに、VMが増加した場合、NetApp重複排除の実行を開始して必要なストレージ容量を削減できるように、業務システムでNetAppファームウェアをアップグレード中です。

仮想化計画
当社ではSharePoint実装を仮想化する計画があります。また、SQL Serverクラスタも仮想化できると考えています。MicrosoftによるHyper-Vのサポートが充実していくことを考えると、当社の仮想化計画はさらに拡大し、エッジサーバ、ファイアウォールISAサーバ、およびIIS Webフロントエンドサーバも対象になる可能性があります。現在、データセンターでラックスペースを大きく占有している多数のシングルボックス、シングルアプリケーションサーバを、今後6~9カ月間で仮想化する予定です。これらは人事や会計などの部門で10~20人程度のユーザが使用しているアプリケーションです。当社はこれらのアプリケーションを、仮想マシンに移行するうえでの手慣らしと考えています。

Hyper-Vに関する当社のプラクティスの多くは、まだ進化の途上にあります。そのうちのいくつかの点は、Service Center Virtual Machine Manager(SCVMM)、Microsoft Data Protection Manager(DPM)など、MicrosoftソリューションとHyper-Vをさらに緊密に統合した最近のMicrosoftリリースとのタイミング的な兼ね合いがあります。実際、当社ではすでにSCVMMのP to V(Physical to Virtual)機能のテストを開始しており、多くの物理サーバを仮想マシンに変換するためのスピーディな方法として有望視しています。そのほかにも、VSSを活用してMicrosoft Hyper-VでベースVMの高速スナップショットをキャプチャする、新しいNetAppデータ保護テクノロジの最適な組み込み方についても検討しています。このタイプのNetAppテクノロジをData Protection Managerと併用し、管理とデータ保護に利用できるものと期待しています。

データ保護とDR計画
当社では、多層型のデータ保護プロセスも開発しています。

  • Microsoft Data Protection Manager(DPM)またはDPMとNetAppデータ保護テクノロジ(VSSに対応)の組み合わせを使用して、一部のHyper-Vデータをバックアップする予定です。
  • 当社の業務環境では現在DPMを使用していますが、そのためには子パーティションごとにエージェントが必要です。
  • NetApp Snapshotを使用して一部のデータをバックアップする予定です(当社では現在、開発/テスト環境でSnapshotを使用しています)。
  • シアトルのデータセンターと米国東部の事業所にあるオフサイトDRロケーションの間でNetApp SnapMirrorを使用して、一部のクリティカルデータを複製する予定です。

まとめ

Microsoft Hyper-VとNetAppは、当社に多大なメリットをもたらしています。(NetApp重複排除によって)貴重なディスクスペースを増やし、4台ものサーバを1時間以内に自動プロビジョニングできるようになりました。SCVMMを導入すれば、このプロセスはさらに高速化されるでしょう。仮想マシンは高可用性を維持しています。Hyper-VとNetAppの組み合わせは、パフォーマンス的にも優秀です。

© 2008 Avanade Inc. All Rights Reserved. Avanadeの名称およびロゴは、米国およびその他の国における登録商標です。その他のブランドおよび製品名は、それを所有する各社の商標です。


Andy Schneider Andy Schneider
Avanades、シニアシステムエンジニア

Schneider氏は3年半前に、Avanadeにフィールドコンサルタントとして入社し、この2年間は現場での経験を活かして本社のITインフラチームで活躍しています。彼とそのチームは、Avanadeの業務環境における新しいテクノロジの最適な利用方法を決定する立場にあります。


関連情報