NetApp Tech OnTap
Hyper-Vに関する5大ベスト・プラクティス

Microsoft® Hyper-VTM仮想化テクノロジが発表されてから1年以上が経ちました。Tech OnTapでは、Hyper-VとNetApp®テクノロジの併用に関する記事を何度かお届けしています。概要を記した記事(英語) や、あるお客様の体験に基づく 詳細なケース・スタディ(英語) などです。

NetAppは数百社もの企業のHyper-V導入に携わっており、NetApp上でHyper-Vを運用する際の詳細なベスト・プラクティスを作成しています。今回は、最近リリースされたHyper-V Server 2008 R2を紹介する、NetAppとHyper-Vに関する最も重要なベスト・プラクティスを5つご紹介します。

  • ネットワーク設定
  • 適切なiGroupおよびLUNプロトコル・タイプの設定
  • 仮想マシン・ディスクのアライメント
  • Cluster Shared Volume(CSV)の使用
  • NetAppストレージ・ソフトウェアおよびツールの活用

これらの項目についての詳しい説明、およびその他の情報は、『Microsoftの仮想化に関するNetAppストレージ・ベスト・プラクティス』(英語) をご覧ください。Hyper-V R2に関する情報も追加されています。

ベスト・プラクティス1:Hyper-V環境でのネットワーク設定

ネットワーク設定については、重要なベスト・プラクティスが2つあります。

  • Hyper-Vサーバで適正な数の物理ネットワーク・アダプタを使用すること
  • Hyper-V R2がサポートする新しいネットワーク機能を可能な限り活用すること

物理ネットワーク・アダプタ:特にiSCSIを使用する場合は、十分な数のネットワーク接続を設定しないと、ストレージに問題があるように見える現象が起こる可能性があります。小規模な環境でも最低2~3個のネットワーク・アダプタが必要です。より大規模な環境では最低4~5個必要ですが、それよりはるかに多くのネットワーク・アダプタが必要になる場合もあります。その理由は次のとおりです。

  • 管理:Microsoftは、Hyper-Vサーバの管理に専用のネットワーク・アダプタを使用することを推奨しています。
  • 仮想マシン: 外部仮想ネットワーク構成には、1個以上のネットワーク・アダプタが必要です。
  • IPストレージ: Microsoftは、IPストレージ通信に専用のネットワークを使用することを推奨しています。したがってこのネットワーク用に1個のアダプタが必須で、マルチパスをサポートするには2個以上が必要になります。
  • • Windowsフェイルオーバー・クラスタ: Windows®フェイルオーバー・クラスタには、プライベート・ネットワークが必要です。
  • ライブ・マイグレーション:このHyper-V R2の新機能は、Hyper-Vサーバ間で稼働中の仮想マシンの移行をサポートします。Microsoftは、ライブ・マイグレーション・トラフィック専用の物理ネットワーク・アダプタを設定することを推奨しています。
  • Cluster Shared Volumes(CSV): Microsoftは、このHyper-V R2の新機能で生ずる通信トラフィックを、専用のネットワークでサポートすることを推奨しています。

適正な物理アダプタ数を判断する際には、次の表を参考にしてください。

表1) スタンドアロン型Hyper-Vサーバ

表2) クラスタ型Hyper-Vサーバ

表3) クラスタ型Hyper-Vサーバ(ライブ・マイグレーションを使用)

表4) クラスタ型Hyper-Vサーバ(ライブ・マイグレーションとCSVを使用)

新しいネットワーク機能: Windows Server® 2008 R2は、新しいネットワーク機能を数多くサポートしています。Hyper-Vサーバにこれらの機能を設定し、可能な限り活用することを推奨します。使用するサーバとネットワーク・ハードウェアによっては、これらの機能の一部または全部がサポートされない場合があるのでご注意ください(詳細は右欄を参照)。

ベスト・プラクティス2:適切なiGroupおよびLUNプロトコル・タイプの選択

NetApp LUNをHyper-V用にプロビジョニングする際、固有のイニシエータ・グループ(iGroups)および適切なLUNタイプを指定する必要があります。設定が不適切だと、導入が困難になり、パフォーマンスが低下する可能性があります。

iGroup:適切なHyper-Vサーバおよび仮想マシン(VM)が接続できるよう、FCPストレージとiSCSIストレージをマスキングする必要があります。NetAppストレージでは、LUNマスキングはiGroupによって処理されます。

  • Hyper-VサーバまたはVMを個別に取り扱う場合は、システム別、およびNetAppストレージ・システムの接続に使用するプロトコル(FCおよびiSCSI)別に、iGroupを1つずつ作成する必要があります。
  • Hyper-VサーバまたはVMをクラスタとして取り扱う場合は、NetAppストレージ・システムへの接続に使用するプロトコルごとに、個別のiGroupを作成する必要があります。

NetApp SnapDrive®を使用すると、iGroupを簡単に管理することができます。SnapDriveは使用しているOSを認識し、それに応じてiGroupを自動的に設定するため、人的ミスを減らすことができます。

LUNタイプ:LUNプロトコル・タイプの設定によって、ディスク上でのLUNのレイアウトが決定されます。LUNに含まれるファイルシステムとLUNのアライメントを確実に一致させるには、適切なLUNタイプを指定することが重要です(詳しくは下記のヒントを参照してください)。これはNetAppストレージだけの問題ではありません。この問題はどのストレージ・ベンダー(またはホスト・プラットフォーム)にも存在します。

ヒント: どのLUNタイプを指定するかは、OS、OSバージョン、ディスク・タイプ、およびData ONTAP®バージョンによって異なります。各OSに対応するLUNタイプについての詳細は、使用しているData ONTAPバージョンの『ブロック・アクセス管理ガイド』を参照してください。

以下の表を参考に、適切なLUNタイプを選択してください。

表5) Data ONTAP 7.3.1以降で使用するLUNタイプ

表6) Data ONTAP 7.2.5~7.3.0で使用するLUNタイプData ONTAP 7.2.5~7.3.0

ベスト・プラクティス3:仮想マシンのディスク・アライメント

ヒント: このヒントはベスト・プラクティス2と密接な関係があります。ベスト・プラクティス2の設定を正しく行わなかった場合、ミスアライメントが発生するからです。仮想マシンのディスク・アライメントの問題は、Hyper-VまたはNetAppストレージだけに限ったことではありません。この問題はすべてのストレージ・プラットフォームで動作するすべての仮想環境に存在します。

この問題が起こる原因は、多くのゲストOS(Windows 2000、2003のほか、各種Linux®)が、デフォルトで最初のプライマリ・パーティションをセクタ(論理ブロック)63から開始するようになっているためです。この動作により、パーティションの先頭がブロック境界に揃わず、ファイルシステムのミスアライメントが発生します。その結果、仮想マシンでブロックを読み取るたびに、LUNからブロックを2つ読み取る必要が生じ、I/O負荷が倍増します。

図1) 仮想ディスクのミスアライメント

仮想マシンをHyper-Vサーバのファイルシステム内のファイルとして管理する場合、適切に位置合わせすべき層がもう1つ加わるため、状況はさらに複雑化します。LUNタイプの選択が重要なのは、この理由からです。

  • すべてのVMテンプレートでオフセットを訂正するとともに、ミスアライメントが原因でI/Oパフォーマンスに問題が発生している既存のVMについても、オフセットを訂正することを強く推奨します(I/O動作をそれほど多く必要としないVMのミスアライメントについては、訂正するメリットが労力に見合わない場合があります)。
  • 仮想ハード・ディスク(VHD)を使用する場合は、Microsoft Hyper-V仮想環境(特に業務環境)には、できるだけ固定サイズVHDを使用することを推奨します。適切なファイルシステム・アライメントを高い信頼性で達成できるのは、固定サイズVHDだけだからです。動的に拡張/差分化されるタイプのVHDは、ファイルシステム・アライメントを高い信頼性で達成できないため、このタイプのVHDの使用は避けてください。

アライメントの問題を特定して訂正するための詳しい手順は、 ベスト・プラクティス・ガイド に記載されています。

ベスト・プラクティス4:Cluster Shared Volume(CSV)の使用

CSVは、Hyper-V R2で導入されたまったく新しい機能です。VMware®を使い慣れた方なら、CSVはVMFSに似たものと考えることができます(ただし、両者には大きな違いがあります)。

CSVは、Hyper-V親パーティションに接続された「ディスク」であり、Windowsフェイルオーバー・クラスタとして構成された複数のHyper-Vサーバ・ノード間で共有されます。CSVは、共有型のストレージ(NetAppストレージ・システムでプロビジョニングされたLUNなど)でしか作成できません。フェイルオーバー・クラスタ内のすべてのHyper-Vサーバ・ノードは、この共有ストレージ・システムに接続する必要があります。

CSVには、次のように多くの利点があります。

  • ネームスペースの共有: CSVにはドライブ文字を割り当てる必要がないため、制約が少なくなり、GUIDやマウント・ポイントを管理する必要もありません。
  • ストレージ管理の簡易化: より多くのVMでより少ないLUNを共有できます。
  • ストレージ効率: 複数のVMを同一のLUNにプールすることで、VMごとに容量を小分けにする必要がなくなるため、容量のプランニングが簡易化され、将来の拡張に備えて確保する容量が節約できます。

CSVの動的なI/Oリダイレクトは、プライマリ・パスウェイに障害が発生した場合に、フェイルオーバー・クラスタ内でのストレージI/OおよびネットワークI/Oのリダイレクションを可能にします。I/Oリダイレクトの影響を最小限に抑えるため、特にCSVの使用に関して次の推奨事項があります。

  • Hyper-Vサーバに管理、VM、IPストレージなどの用途ごとに専用のNICを取り付けることに加え(ベスト・プラクティス1を参照)、CSVトラフィック専用の物理ネットワーク・アダプタを使用することを推奨します。この物理ネットワーク・アダプタは、最低でもギガビット・イーサネット(GbE)アダプタでなければなりません。大容量のサーバ(16 LCPU以上、64 GB以上)を稼働したり、CSVを多用したり、SCVMMによってクラスタ内でVMを動的に負荷分散したり、ライブ・マイグレーションを多用したりする計画がある場合は、CSVトラフィック用に10ギガビット・イーサネットを検討してください。
  • CSV I/Oリダイレクトが発生する可能性を最小限に抑えるため、すべてのHyper-Vクラスタ・ノードにMPIOを設定することを強く推奨します。CSV I/Oリダイレクトは、業務環境における単一障害点を削減するためのマルチパスやストレージ・レイアウト/ネットワーク接続の適切なプランニングに代わるものではありません。
  • CSVでI/Oリダイレクションが発生していることが判明した場合には、I/Oパスウェイの問題を診断して是正するまで、該当するクラスタ上の該当するすべてのVMに対して他のHyper-Vクラスタ・ノードへのライブ・マイグレーションを実行し、最適なパフォーマンスを回復することができます。

ベスト・プラクティス・ガイドには、CSVを使用する場合のバックアップおよびVMプロビジョニングに関連するその他のベスト・プラクティスの情報も記載されています。

ベスト・プラクティス5:NetAppストレージ・ソフトウェアおよびツール

NetAppは、Hyper-V環境の運用を簡易化する、さまざまなストレージ・ソフトウェアおよびツールを提供しています。Hyper-V R2のリリースに伴い、多くのソフトウェア・エレメントで最低要件が変更になりました。

  • Hyper-V仮想環境では、最低でもData ONTAP 7.3以降を使用することを推奨します。
  • NetAppストレージに接続されている場合、Hyper-Vの親OSまたは子OSができるだけ高い信頼性で動作するよう、Windows Host Utilities Kitでシステム設定を変更できます。NetAppは、すべてのHyper-VサーバにWindows Host Utilities Kitをインストールすることを強く推奨します。Windows Server 2008の場合、Windows Host Utilities Kit 5.1以上が必要です。Windows Server 2008 R2(Hyper-V R2)の場合、Windows Host Utilities Kit 5.2以上が必要です。
  • 可用性の高いストレージ設定には、適切なバージョンのData ONTAP DSM for Windows MPIOが必要です。Windows Server 2008の場合、Data ONTAP DSM 3.2R1以降が必要です。Windows Server 2008 R2の場合、Data ONTAP DSM 3.3.1以降が必要です。MPIOを使用する場合には、最低キュー・デプスのポリシーを設定する必要があります(デフォルト設定)。
  • 機能性を最大限に生かし、重要機能をサポートするために、すべてのHyper-VサーバおよびSCVMMサーバにNetApp SnapDriveをインストールすることを推奨します。Hyper-Vロールが有効なMicrosoft Windows Server 2008、およびMicrosoft Hyper-V Server 2008の場合、NetApp SnapDrive for Windows 6.0以降をインストールします。Hyper-Vロールが有効なMicrosoft Windows Server 2008 R2、およびMicrosoft Hyper-V Server 2008 R2の場合は次のとおりです。
    • 既存の機能をサポートするには (R2の新機能を使用しない場合)、NetApp SnapDrive for Windows 6.1P2以上をインストールします。
    • 新機能をサポートするには (R2のすべての新機能)、NetApp SnapDrive for Windows 6.2以上をインストールします。
  • サポート対象の子OS(Microsoft Windows Server 2003、Microsoft Windows Server 2008、Microsoft Windows Server 2008 R2)には、NetApp SnapDrive for Windows 6.0以上をインストールできます。

サポートされるソフトウェア・バージョンについての最新情報は、 NetApp Interoperability Matrix(互換性マトリックス). をご確認ください(このリソースにアクセスするには、NOWTM [NetApp on the Web] アカウントが必要です)。

まとめ

以上説明したベスト・プラクティスに注意すれば、Hyper-V環境を設定する際に陥りやすい問題をほとんど避けることができるでしょう。これらの手順についての詳しい説明とその他の情報は、Hyper-Vベスト・プラクティス・ガイドおよび Hyper-V実装ガイド(英語) を参照してください。


Chaffie McKenna
リファレンス・アーキテクト
NetApp

Chaffieは2008年初頭にNetAppのMicrosoftアライアンス・エンジニアリング・チーム(ワシントン州シアトル)の一員として入社しました。専門は仮想化(特にMicrosoft Hyper-VおよびSCVMM)。仮想化の黎明期から10年にわたりこの技術に取り組み続けています。


関連情報