仮想化ファブリック設計の考慮事項ガイド

 

このガイドの対象読者中規模または大規模な組織で働く情報技術 (IT) の専門家は、さまざまな仮想マシンに対応する仮想化ファブリックの設計を担当します。この文書では、このような専門家のことを「ファブリック管理者」と呼ぶことにします。ファブリックでホストされる仮想マシンを管理する人物は「仮想マシン管理者」とも呼ばれますが、この文書の対象読者ではありません。組織によっては IT 管理者は両方の役割を担うことがあります。

このガイドの目的このガイドは、組織内の多数の仮想マシンをホストできる仮想化ファブリックを設計する方法を理解するために役立ちます。この文書では、組織内の仮想マシンのホストに使用される一連のサーバー、ハイパーバイザー、ストレージとネットワークのためのハードウェアを「仮想化ファブリック」と呼びます。次の図は仮想化ファブリックを示しています。

仮想化ファブリック

図 1仮想化ファブリックの例

**注:**この文書の図は「Virtualization Fabric Design Considerations Diagrams」ドキュメントの各タブに存在するものです。各テーブル キャプションの図の名前をクリックするとダウンロードできます。

すべての仮想化ファブリックにはストレージのためのサーバーとホスティング仮想マシンがそれらを接続するネットワークに加えて含まれているが、すべての組織の仮想化ファブリック設計は、多くの場合、要件の違いに起因して図 1 の例とは異なります。

このガイドでは、組織固有の要件を満たす仮想化ファブリックの設計に役立つ一連の手順と作業について説明します。このガイドでは、手順と作業を通して、機能とサービス品質 (可用性、拡張性、性能、管理容易性、セキュリティなど) レベルの要件を満たすために利用できる関連技術と機能について紹介します。

この文書は管理が簡単な仮想化ファブリックの設計を支援しますが、Microsoft System Center 2012 や System Center 2012 R2 のような製品で仮想化ファブリックを管理し、操作するための設計上の考慮事項とオプションについては扱いません。詳細については、TechNet ライブラリの「System Center 2012」を参照してください。

このガイドは、「Windows Server 2012 R2 と Windows Server 2012」とベンダー非依存ハードウェアを使用して仮想化ファブリックを設計する際に役立ちます。この文書で扱う一部の機能は Windows Server 2012 R2 に固有のものであり、この文書全体で登場します。

**前提:**Hyper-V、仮想マシン、仮想ネットワーク、Windows Server ファイル サービス、フェールオーバー クラスタリングを展開した経験があり、物理的なサーバー、ストレージ、ネットワーク機器を配備した経験があること。

その他の資料

仮想化ファブリックを設計する前に、次の文書に掲載されている情報を確認しておくと役に立つことがあります。

いずれの文書も、さまざまな仮想化ファブリック設計で観察される基礎的概念を紹介し、仮想化ファブリック設計の基本として役に立ちます。

**フィードバック:**この文書に関するご意見は、virtua@microsoft.com まで電子メールにてお寄せください。

設計上の考慮事項の概要

この文書では、要件を最も効果的に満たす仮想化ファブリックの設計に役立つ一連の手順と作業について説明します。手順は順番に説明します。後半の手順で学習する設計上の考慮事項では、相反に起因し、前半の手順で決定した内容を変更しなければならなくなることがあります。ただし、設計に相反が発生しないようにこの文書全体で注意が喚起されています。

この文書のすべての考慮事項を取り入れるために必要な回数だけ繰り返して初めて要件を最も効果的に満たす設計にたどり着きます。

手順 1:仮想マシンのリソース要件の決定

手順 2:仮想マシンの構成の計画

手順 3:サーバー仮想化ホスト グループの計画

手順 4:サーバー仮想化ホストの計画

手順 5:仮想化ファブリック アーキテクチャ概念の計画

手順 6:初期機能特性の計画

手順 1:仮想マシンのリソース要件の決定

仮想化ファブリック設計の最初の手順は、ファブリックがホストする仮想マシンのリソース要件を決定することです。ファブリックにはこのリソース要件を満たすために必要な物理的ハードウェアを含める必要があります。仮想マシンのリソース要件は、仮想マシン内で実行されるオペレーティング システムとアプリケーションにより決定されます。この文書の残りの部分では、仮想マシン内で実行されるオペレーティング システムとアプリケーションの組み合わせを「ワークロード」と呼ぶことにします。この手順の作業では、ワークロードのリソース要件を定義します。

ヒント既存のワークロードのリソース要件を評価し、各要件に対処できる仮想化ファブリックを設計する代わりに、最も一般的なワークロードのニーズを満たせる仮想化ファブリックを設計することもできます。その後、個々のワークロードのニーズに対処します。

このような仮想化ファブリックの例には、Microsoft Azure (Azure) などのパブリック クラウド プロバイダーにより提供される仮想化ファブリックがあります。詳細については、「Azure の仮想マシンおよびクラウド サービスのサイズ」を参照してください。

一般的に、パブリック クラウド プロバイダーはほとんどのワークロードのニーズを満たす一連の仮想マシン構成を提供します。この手法を採用する場合、この文書の「手順 2:仮想マシンの構成の計画」に直接進むことができます。この手法のその他の利点:

  • オンプレミス仮想マシンの一部をパブリック クラウド プロバイダーに移行するとき、オンプレミス仮想マシンの構成タイプがパブリック プロバイダーのそれと似ている場合、構成タイプが異なる場合より、仮想マシンを簡単に移行できます。

  • 場合によっては、容量要件の要件が簡単になり、仮想化ファブリックのセルフサービス プロビジョニング機能を有効にできます。つまり、組織の仮想マシン管理者は新しい仮想マシンの自動セルフプロビジョニングを有効にできるので、ファブリック管理者に依頼する必要がありません。

作業 1:ワークロードのリソース要件を決定する

各ワークロードには次のリソース要件があります。最初にすることは、各ワークロードに関して次の質問に答えることです。

  • **Processor:**必要なプロセッサの速度と、アーキテクチャ (Intel または AMD) の数はいくつですか?

  • **[ネットワーク]**毎秒ギガビット数 (Gbps) で、どのくらいのネットワーク帯域幅が受信と送信のトラフィックに必要ですか?正常に機能するためにワークロードで許容されるネットワーク待ち時間は最長でどのくらいですか?

  • **ストレージ:**ワークロードのアプリケーション ファイルとオペレーティング システム ファイルに必要なストレージのギガバイト (GB) 単位でどのくらいですか?そのデータにワークロードが必要とするストレージ は GB 単位でどのくらいですか?そのストレージでワークロードが必要とする毎秒入力/出力操作 (IOPS) はどのくらいですか?

  • **メモリ:**ギガバイト (GB) で、ワークロードはどのくらいのメモリを必要としますか?ワークロードは Non-Uniform Memory Access (NUMA) 対応ですか?

以上のリソース要件を理解する以外に、次を決定することも重要です。

  • リソース要件が最小であるか、推奨であるか。

  • 時間、日、週、月、年単位における各ハードウェア要件のピーク要件と平均要件。

  • ワークロードとワークロードのデータが受け入れられる毎月のダウンタイム (分)。これを決定する際、次を考慮します。

    • ワークロードは 1 台だけの仮想マシンで実行されるか。あるいは、ネットワーク負荷が分散された一連のサーバーが同じワークロードを実行するなど、1 つとして機能する一連の仮想マシンで実行されるか。一連のサーバーを使用する場合、ダウンタイムを指定するとき、サーバーの集合に含まれる各サーバーに適用されるのか、サーバーの集合に含まれる全サーバーに適用されるのか、サーバーの集合レベルで適用されるのかを明示する必要があります。

    • 稼働時間と非稼働時間。たとえば、午後 9 時から午前 6 時まで誰もワークロードを使用しないが、月の許容ダウンタイムをわずか 10 分として午前 6 時から午後 9 時までは可能な限りワークロードを利用可能にすることが重要な場合に、この要件を指定する必要があります。

  • 仮想インフラストラクチャで予期しない障害が発生した場合に許容できるデータ損失の量。これは分単位で表現されます。仮想インフラストラクチャの複製戦略は一般的に時間に基づくためです。多くの場合、データ損失は要件として明記されないが、データの損失は非常に高くつき、パフォーマンスの低下につながることを考慮してください。

  • ワークロード ファイルとそのデータの両方または一方をディスク上で暗号化する必要があるか。仮想マシンとそのエンドユーザーの間でそのデータを暗号化する必要があるか。

前のリソース要件を決定するために次のオプションを利用できます。

オプション

利点

短所

リソース使用率の手動による評価とログ記録

選択したあらゆる項目について報告できる

多大な労力が必要になる場合あり

リソース使用率を手動で評価し、ログに記録するには、Microsoft Assessment and Planning Toolkit を使用します。

  • さまざまなリソース使用率レポートを作成します。

  • ワークロードにエージェントをインストールする必要がありません。

必要なすべてのデータがレポートで提供されるとは限りません。

**注:**リソース使用率を手動で決定する場合、Virtualization Fabric Design Considerations Guide Worksheets をダウンロードし、ワークロード リソース要件に情報を入力します。このガイドはそのドキュメントの特定のワークシートを参照します。

作業 2:ワークロードの特性を定義する

環境にさまざまなワークロード特性を定義できます。次の例が選ばれたのは、それぞれが仮想化ファブリック コンポーネントのさまざまな構成を必要とするためです。それについては後の手順で説明されます。

  • **ステートレス:**初回のプロビジョニングを実行し、一意のコンピューター名とネットワーク アドレスを割り当てた後はローカル ハード ディスクに一意の情報が書き込まれません。ただし、データベースなど、個別のストレージに一意の情報が書き込まれることがあります。ステートレス ワークロードは仮想化ファブリックでの実行に最適です。仮想マシンの「マスター」イメージを作成できるためです。このイメージは簡単にコピーし、仮想化ファブリックで起動できます。スケールを追加したり、仮想化ホストに障害が発生して利用できなくなった仮想マシンをすばやく交換したりできます。ステートレス ワークロードの一例はフロントエンド Web アプリケーションを実行する Web サーバーです。

  • **ステートフル:**初回のプロビジョニングを実行し、一意のコンピューター名とネットワーク アドレスを割り当てた後にローカル ハード ディスクに一意の情報が書き込まれます。データベースなど、個別のストレージに一意の情報が書き込まれることもあります。ステートフル ワークロードは、一般的に、ステートレス ワークロードよりも複雑なプロビジョニングとスケーリングの戦略を必要とします。ステートフル ワークロードの高可用戦略では、場合によっては、その他の仮想マシンと状態を共有する必要があります。ステートフル ワークロードの一例は SQL Server データベース エンジンです。

  • **共有ステートフル:**他の仮想マシンと一部の状態を共有する必要があるステートフル ワークロード。このようなワークロードは、多くの場合、Windows Server のフェールオーバー クラスタリングを使用し、共有ストレージにアクセスする必要があるときに可用性を高くします。共有ステートフル ワークロードの一例は Microsoft System Center – Virtual Machine Manager です。

  • **その他:**仮想化ファブリックでまったく実行されない、または最適な状態で実行されないワークロードの特徴を示します。そのようなワークロードの特性として次のものが必要になります。

    • 物理的周辺機器へのアクセス。そのようなアプリケーションの例として、物理ホストのテレフォニー ネットワーク アダプターと通信するテレフォニー ワークロードがあります。

    • 他のほとんどのワークロードより高いリソース要件。一例として、アプリケーション層の間の待ち時間を 1 ミリ秒未満にする必要があるリアルタイム アプリケーションがあります。

    このようなアプリケーションは仮想化ファブリックで実行できない場合があります。あるいは、他のほとんどのワークロードと共有されない特別なハードウェアまたは構成を必要とします。

**注:**ワークロードの特性は設定ワークシートで定義し、その後、ワークロード リソース要件ワークシートで各ワークロードに適した特性を選択できます。

手順 2:仮想マシンの構成の計画

この手順では、手順 1 で定義したワークロードのリソース要件と特性を満たすために必要になる仮想マシンの種類を定義します。

作業 1:コンピューティングの構成を定義する

この作業では、各仮想マシンが必要とするメモリの量とプロセッサを決定します。

作業 1a:仮想マシンの生成の種類を定義する

Windows Server 2012 R2 では第 2 世代の仮想マシンが導入されました。第 2 世代の仮想マシンは第 1 世代の仮想マシンでは対応していないハードウェアと仮想化機能に対応しています。仮想マシンの作成後にその種類を変更することはできないため、正しい要件を決定することが重要です。

第 2 世代の仮想マシンは次の新機能を備えています。

  • 標準のネットワーク アダプターを使用した PXE ブート

  • SCSI 仮想ハード ディスクからの起動

  • SCSI 仮想 DVD からの起動

  • セキュア ブート (既定で有効)

  • UEFI ファームウェアのサポート

第 2 世代の仮想マシンは次のゲスト オペレーティング システムをサポートします。

  • Windows Server 2012 R2

  • Windows Server 2012

  • Windows 8.1 の 64 ビット バージョン

  • Windows 8 の 64 ビット バージョン

  • Linux の特定のバージョン。第 2 世代の仮想マシンに対応しているディストリビューションとバージョンについては、「Linux Virtual Machines on Hyper-V (Hyper-V の Linux 仮想マシン)」を参照してください。

次の表は、第 1 世代と第 2 世代の仮想マシンの長所と短所をまとめたものです。

オプション

利点

短所

第 1 世代

  • サポートされるすべての Hyper-V ゲスト オペレーティング システムをサポートします

  • Azure 仮想マシンとの間に互換性があります

  • 以前のバージョンの Hyper-V をサポートします

新しい仮想マシンの機能にアクセスできません

第 2 世代

  • 新機能をサポートします

  • 仮想マシンの起動とゲストのインストールにかかる時間がわずかに短縮されました

  • SCSI デバイスまたは標準のネットワーク アダプターを利用して仮想マシンを起動できます

  • セキュア ブートを有効にすると、無許可のファームウェア、オペレーティング システム、UEFI ドライバーの実行を防止します

  • ゲスト オペレーティング システムの制限付きサポート

  • Azure 仮想マシンとの互換性はありません

  • RemoteFX には対応していません

  • 仮想フロッピー ディスクには対応していません

**重要:**Linux の第 2 世代仮想マシンはセキュア ブートに対応していません。仮想マシンを作成し、Linux をインストールするとき、仮想マシンの設定でセキュア ブートをオフにする必要があります。

追加情報:

第 2 世代仮想マシンの概要

作業 1b:メモリを定義する

物理コンピューターのサーバー アプリケーションの場合と同様に、仮想マシンのメモリのサイズを計画する必要があります。通常時とピーク時に予測される負荷を無理なく処理できる量にする必要があります。メモリが足りないと、応答時間、CPU 使用率、I/O 使用率が大幅に増えます。

静的メモリまたは動的メモリ

静的メモリとは、仮想マシンに割り当てられるメモリの量です。仮想マシンを起動したときに常に割り当てられ、仮想マシンの実行中は変更されません。全メモリが起動時に仮想マシンに割り当てられます。ある仮想マシンによって使用されていないメモリを他の仮想マシンが使用できることはありません。ホストに十分なメモリがなく、起動時に仮想マシンに割り当てられない場合、仮想マシンは起動しません。

静的メモリは、メモリの使用率が高いワークロードや、SQL Server など、独自のメモリ管理システムを持つワークロードに最適です。このような種類のワークロードは静的メモリで性能が上がります。

**注:**静的メモリを有効にする設定はありません。静的メモリは動的メモリ設定が有効でない場合に有効になります。

動的メモリを有効にした場合、システムの物理メモリを効率的に利用できます。複数の仮想マシンの間で合計物理メモリをバランス良く配分します。多忙な仮想マシンに多くのメモリを割り当て、利用頻度が少ない仮想マシンからメモリを解放します。仮想デスクトップ インフラストラクチャ (VDI) または Web サーバーなどの動的な環境で、統合率が上がることが見込まれます。

静的メモリを利用するとき、仮想マシンに 10 GB のメモリが割り当てられているが、3 GB しか利用していない場合でも、残りの 7 GB を他の仮想マシンが利用することはできません。仮想マシンで動的メモリを有効にすると、仮想マシンは必要な量のメモリだけを使用します。ただし、設定されている最小 RAM より下になることはありません。他の仮想マシンのためにメモリが多くのメモリが解放されます。

次の表は、静的メモリと動的メモリの長所と短所をまとめたものです。

オプション

利点

短所

静的メモリ

  • 仮想マシンに構成されたメモリを常に利用できます

  • パフォーマンスが良くなります

  • 仮想 NUMA とともに使用できます

  • ある仮想マシンが使用していないメモリを他の仮想マシンに割り当てることはできません

  • 十分なメモリを利用できない場合、仮想マシンは起動しません

動的メモリ

  • アイドル状態または低負荷のワークロードを実行しているとき、仮想マシンの密度が上がります

  • 利用されていないメモリを他の仮想マシンが利用できるように割り当てることができます

  • 構成されているメモリをオーバーサブスクライブできます

  • メモリ割り当て管理のための諸経費が増えます

  • 仮想 NUMA に対応していません

  • 独自のメモリ管理機能を実装するワークロードに対応していません

次はメモリ構成設定です。

  • **スタートアップ RAM:**仮想マシンの起動に必要なメモリの量を指定します。この値はゲスト オペレーティング システムの起動に必要な大きさにする必要があるが、最適なメモリ利用率と高い統合率のために、可能な限り低く設定します。

  • **最小 RAM:**仮想マシンの起動後に仮想マシンに割り当てる必要があるメモリの最小量を指定します。この値は 32 MB の最小値からスタートアップ RAM 値に等しい最大値の間で設定できます。この設定は動的メモリが有効な場合にのみ使用できます。

  • **最大 RAM:**この仮想マシンで使用が許可されるメモリの最大量を指定します。この値は最小値 (スタートアップ RAM の値) から 1 TB の最大値の間で設定できます。ただし、仮想マシンが使用できるメモリは、多くてもゲスト オペレーティング システムでサポートされている最大メモリと同量になります。たとえば、最大 32 GB をサポートするゲスト オペレーティング システムを実行する仮想マシンに 64 GB を指定した場合、仮想マシンは 32 GB 以上を使用できません。この設定は動的メモリが有効な場合にのみ使用できます。

  • **メモリの優先度:**すべての仮想マシンにそれが要求したメモリ量を与えるだけの十分な物理メモリがホストにない場合、仮想マシン間のメモリ配分を決定する方法を Hyper-V に提供します。メモリの優先度が高い仮想マシンは優先度の低い仮想マシンに優先します。

注:

  • 動的メモリと仮想 NUMA の機能は同時に使用できません。動的メモリを有効にしている仮想マシンの仮想 NUMA ノードは、実質、1 つだけです。仮想 NUMA の設定に関係なく、NUMA トポロジは仮想マシンに提示されません。

  • 仮想マシンのオペレーティング システムをインストールまたはアップグレードするとき、インストールまたはアップグレードのプロセス中に仮想マシンが利用できるメモリ量はスタートアップ RAM に指定された値になります。仮想マシンに動的メモリが構成されている場合でも、仮想マシンはスタートアップ RAM 設定に構成されているメモリ量だけを使用します。インストールまたはアップグレードの手順でスタートアップ RAM の値がオペレーティング システムの最小メモリ要件を満たすことを確認してください。

  • 仮想マシンで実行されているゲスト オペレーティング システムが動的メモリに対応している必要があります。

  • SQL Server や Exchange Server のような複雑なデータベース アプリケーションは独自のメモリ管理機能を実装します。ワークロードが動的メモリに対応しているかどうかを判断するには、そのワークロードの文書を参照してください。

追加情報:

動的メモリの概要

作業 1c:プロセッサを定義する

仮想マシンを構成するとき、次の構成設定を決定する必要があります。

  • 各仮想マシンに必要なプロセッサの数を決定します。多くの場合、ワークロードで必要となるプロセッサの数と同じになります。Hyper-V は仮想マシンあたり最大 64 個の仮想プロセッサをサポートします。

  • 各仮想マシンのリソース コントロールを決定します。仮想化ホストのプロセッサ リソースを仮想マシンが独占できないように上限を設定できます。

  • NUMA トポロジを定義します。NUMA 対応の高性能ワークロードの場合、プロセッサの最大数、1 つの仮想 NUMA ノードで許可されるメモリ量、1 つのプロセッサ ソケットで許可される最大ノード数を指定できます。詳細については、「Hyper-V 仮想 NUMA の概要」を参照してください。

**注:**仮想 NUMA と動的メモリは同時に使用できません。動的メモリを使用するのか、NUMA を使用するのか決定するとき、次の質問に答えます。いずれの答えも「はい」の場合、仮想 NUMA を有効にして動的メモリは無効にします。

  1. 仮想マシンで実行しているワークロードは NUMA 対応ですか。

  2. 仮想マシンは 1 つの物理 NUMA ノードで利用できる以上のリソース、プロセッサ、メモリを消費しますか。

作業 1d:サポートされるオペレーティング システムを明確にする

ワークロードに必要なオペレーティング システムがゲスト オペレーティング システムとしてサポートされることを確認する必要があります。次の点を考慮します。

**注:**Hyper-V には、性能と物理コンピューターと仮想マシンの統合を改善する、サポートされるゲスト オペレーティング システム用のソフトウェア パッケージが含まれています。この一連のサービスとソフトウェア ドライバーを統合サービスと呼びます。最高の性能を引き出すには、仮想マシンで最新の統合サービスを実行します。

ライセンス

ゲスト オペレーティング システムにライセンスが適切に与えられていることを確認する必要があります。仮想化環境を実行するときの特定のライセンス要件については、ベンダーのドキュメントを参照してください。

仮想マシンの自動ライセンス認証 (AVMA) は、Windows Server 2012 R2 で導入された機能です。AVMA は仮想マシンのライセンス認証をライセンスを付与する仮想化サーバーにバインドし、起動時に仮想マシンをアクティブにします。これにより、ライセンス情報を入力し、仮想マシン別にアクティブにする必要がなくなります。

AVMA を利用するには、ホストが Windows Server 2012 R2 Datacenter を実行していることと、ゲスト オペレーティング システムが Windows Server 2012 R2 Datacenter、Windows Server 2012 R2 Standard、Windows Server 2012 R2 Essentials であることが要求されます。

**注:**仮想化ファブリックに展開されているホストごとに AVMA を構成する必要があります。

追加情報:

仮想マシンの自動ライセンス認証

作業 1e:仮想マシンの命名規則を定義する

既存のコンピューターの命名方法により、コンピューターまたはサーバーの物理的配置が示されることがあります。仮想マシンはホスト間で移動されます。異なるデータセンサー間で移動されることもあります。そのため、既存の命名方法は適用されないことがあります。コンピューターを仮想マシンとして実行していることを示す既存の命名規則を更新すれば、仮想マシンの実行場所を簡単に特定できます。

作業 2:ネットワーク構成を定義する

各仮想マシンはさまざまな種類のネットワーク トラフィックを送受信します。ネットワーク トラフィックの種類が異なれば、性能、可用性、セキュリティ要件も異なります。

第 1 世代の仮想マシンには最大 12 個のネットワーク アダプターを接続できます。レガシー ネットワーク アダプターが 4 個と仮想ネットワーク アダプターが 8 個です。第 2 世代の仮想マシンはレガシー ネットワーク アダプターに対応しておらず、サポートされるアダプターの最大数は 8 になります。

作業 2a:ネットワーク トラフィックの種類を定義する

各仮想マシンは次のようなさまざまな種類のデータを送受信します。

  • アプリケーション データ

  • データ バックアップ

  • クライアント コンピューター、サーバー、サービスとの通信

  • ワークロードがゲスト仮想マシンのフェールオーバー クラスターの一部である場合、クラスター内通信

  • サポート

  • 記憶域

さまざまな種類のネットワーク トラフィックに専用の既存ネットワークがすでにある場合、この作業にそれを利用できます。仮想化ファブリックをサポートする新しいネットワーク設計を定義する場合、仮想マシンごとにそれがサポートするネットワーク トラフィックの種類を定義できます。

作業 2b:ネットワーク トラフィックのパフォーマンス オプションを定義する

ネットワーク トラフィックの種類ごとに最大帯域幅と最小待ち時間要件があります。次の表は、さまざまなネットワーク パフォーマンス要件を満たすために利用できる戦略をまとめたものです。

方策

利点

短所

トラフィックの種類により物理ネットワーク アダプターを変える

トラフィックを分割するので、他の種類のトラフィックと共有されません。

  • ネットワーク トラフィックの種類ごとに、別個の物理ネットワーク アダプターをホストにインストールする必要があります。

  • 可用性の高いネットワークを必要とする場合、ネットワークごとにハードウェアを追加する必要があります。

  • ネットワークの数が多い場合、効果的に拡大できません。

Hyper-V 帯域幅管理 (Hyper-V QoS)

  • 仮想ネットワーク トラフィックの QoS を提供します。

  • トラフィック フローの最小帯域幅と最大帯域幅を強制します。トラフィック フローは Hyper-V 仮想スイッチのポート番号により識別されます。

  • PowerShell コマンドレットと Windows Management Instrumentation (WMI) のいずれかを利用し、Hyper-V 仮想スイッチごとに最小帯域幅と最大帯域幅を構成します。

  • Hyper-V で複数の仮想マシン アダプターを構成し、仮想ネットワーク アダプターごとに QoS を指定します。

  • 物理ネットワークの QoS ポリシーを補完します。

  • ソフトウェア QoS とハードウェア QoS は同じネットワーク アダプターで同時に使用することはできません。

  • 互いに上書きしないように、ネットワークと Hyper-V の QoS ポリシーを適切に計画する必要があります。

  • 仮想スイッチのサービス品質のモードを設定した場合、それを変更できません。

  • 別の QoS モードを使用するように設定されている仮想スイッチを持つホストに仮想マシンを移行することはできません。

  • 仮想マシンに設定された絶対値を順守できない場合、移行はブロックされます。

SR-IOV

  • 仮想マシンのネットワーク待ち時間を最小化します。

  • 仮想マシンのネットワーク I/O を最大化します。

  • 仮想ネットワークに必要な CPU オーバーヘッドを減らします。

  • ホストと仮想機能を割り当てる各仮想マシンに SR-IOV 対応のネットワーク アダプターとドライバーを用意する必要があります。

  • SR-IOV 対応の仮想ネットワーク アダプターはホストの NIC チームに属することができません。

  • ネットワークの可用性を上げるには、2 つ以上の SR-IOV ネットワーク アダプターをホストに配置し、NIC チーミングを仮想マシンで構成する必要があります。

  • SR-IOV の利用は信頼できるワークロードに限定します。トラフィックが Hyper-V スイッチを迂回し、物理ネットワーク アダプターに直接アクセスするためです。

  • 仮想スイッチ ポート ACL、Hyper-V QoS、RouterGuard、DHCPGuard を構成すると、SR-IOV は利用できなくなります。

  • Azure で実行されている仮想マシンの場合、SR-IOV はサポートされていません。

仮想 Receive-Side Scaling

  • 仮想 Receive-Side Scaling をサポートします。 これを利用すると、仮想マシンは複数の仮想プロセッサ (vCPU) 間でネットワーク処理負荷を分散し、仮想マシン内のネットワーク スループットを上げることができます。

  • 次との互換性を提供します。

    • NIC チーミング

    • ライブ マイグレーション

    • NVGRE

  • 仮想 Receive-Side Scaling を利用するには、物理ネットワーク アダプターが仮想マシン キュー (VMQ) をサポートする必要があり、それをホストで有効にする必要があります。

  • SR-IOV 対応の仮想ネットワーク アダプターとの互換性はありません。

  • 仮想マシンは Windows Server 2012 R2 または Windows 8.1 を実行する必要があります。

  • VMQ アダプターが 10 Gbps 未満の場合、既定では無効になります。

Jumbo Frame

  • 転送する必要があるフレームの数が減り、各イーサネット トランザクションで転送できるデータが多くなります。

  • 通常、ストレージとの通信に使用されるが、あらゆる種類の通信に使用できます。

  • 仮想マシン、ネットワーク機器、データの送信先となるエンド サーバーのオーバーヘッドが減ります。

  • すべてのホップの最大転送単位 (MTU) 設定を制御できるデータ センター内の通信のために構成されます。

  • エラーの検出確率がわずかに下がります。

  • パスにある各ネットワーク デバイスが Jumbo Frame をサポートする必要があり、同じかそれ以上の MTU 設定で構成する必要があります。Ping コマンドを使用し、エンドツーエンドの MTU 設定を検証します。

  • ホップの 1 つが Jumbo Frame をサポートしないか、MTU 設定が低いと、パケットが失われます。

作業 2c:ネットワーク トラフィックの可用性オプションを定義する

LBFO (Load Balancing and FailOver/負荷分散とフェールオーバー) とも呼ばれている NIC チーミングを利用すると、複数のネットワーク アダプターを 1 つのチームに配置し、帯域幅集約とトラフィック フェールオーバーを実行できます。 それにより、ネットワーク コンポーネントに障害が発生した場合も接続が維持されます。一般的に NIC チーミングはホストで構成されます。仮想スイッチを作成すると、ネットワーク アダプター チームにバインドされます。

展開されているネットワーク スイッチにより NIC チーミング モードが決定されます。大半の展開では、Windows Server 2012 R2 の既定設定で十分です。

**注:**SR-IOV は NIC チーミングに対応していません。SR-IOV に関する詳細については、「作業 2b:ネットワーク トラフィックのパフォーマンス オプションを定義する」を参照してください。

追加情報:

NIC チーミングの概要

作業 2d:ネットワーク トラフィックのセキュリティ オプションを定義する

ネットワーク トラフィックの種類ごとにセキュリティ要件を変えることができます。たとえば、分離や暗号化に関連する要件を与えることができます。次の表は、さまざまなセキュリティ要件を満たすために利用できる方策についてまとめたものです。

方策

利点

短所

複数のネットワーク アダプターで分割する

他のネットワーク トラフィックからトラフィックを切り離します。

拡張性が制限されます。ネットワークの数が増えると、それだけ多くのネットワーク アダプターをホストにインストールし、管理する必要があります。

IPsec と IPsec タスク オフロード

  • IPsec オフロードをサポートし、Hyper-V を利用して仮想マシンとの間でのネットワーク トラフィックを暗号化できます。

  • ネットワークを通過するトラフィックを暗号化します。

  • 設定が複雑です。

  • ホストまたは仮想マシンとの間のトラフィックを開くことができないため、問題解決が難しくなります。

  • ホストの物理ネットワーク アダプターが IPsec オフロードをサポートしていないときにプロセッサ使用率が上がります。

VLAN タグ付け

  • ほとんどの企業ですでに使用されています。

  • QoS ポリシーとの間に互換性があります。

  • プライベート VLAN をサポートします。

  • 仮想マシンの VLAN トランク モードをサポートします。

  • ホストに設置しなければならない物理アダプターの数を減らします。

  • VLAN は最大 4094 個に制限されます。

  • スイッチ、ホスト、仮想マシンを構成する必要があります。

  • VLAN の構成設定を間違って変更すると、サーバー固有またはシステム全体のネットワーク問題を引き起こすことがあります。

Hyper-V ネットワーク仮想化

  • ネットワーク分離や VLAN なしの IP アドレス再利用など、ワークロードを柔軟に配置できます。

  • ワークロードをクラウドに簡単に移動をできます。

  • サブネット間でライブ マイグレーションできます。新しいサーバーで新しい IP アドレスを入力する必要がありません。

  • マルチテナント ネットワーク ソリューションが可能です。

  • ネットワーク設計が単純になり、サーバーとネットワークのリソース利用が改善されます。物理ネットワーク インフラストラクチャに仮想マシンの配置を依存する堅牢な VLAN では、一般的に、過度のプロビジョニングと利用不足が発生します。

  • Hyper-V ネットワーク仮想化の管理には、System Center 2012 R2 - Virtual Machine Manager または Microsoft 以外の管理ソリューションが必要になります。

  • 仮想ネットワーク外の通信を可能にするには、Hyper-V ネットワーク仮想化ゲートウェイが必要になります。

DHCPGuard

  • 仮想ネットワークでの DHCP 提供を仮想マシンに禁止します。

  • 仮想ネットワーク アダプター単位で構成できます。

  • 仮想マシンが DHCP サーバーからアドレスを受信することは停止しません。

有効にしたとき、パフォーマンスがわずかな影響を受けます。

RouterGuard

  • 次のパケットをブロックします。

    • ICMPv4 タイプ 5 (リダイレクト メッセージ)

    • ICMPv4 タイプ 9 (ルーター アドバタイズ)

    • ICMPv6 タイプ 134 (ルーター アドバタイズ)

    • ICMPv6 タイプ 137 (リダイレクト メッセージ)

  • 仮想ネットワーク アダプター単位で構成できます。

有効にしたとき、パフォーマンスがわずかな影響を受けます。

設計の決定 - Virtualization Fabric Design Considerations Guide Worksheetsをダウンロードし、仮想マシン構成ワークシートのサンプル データを変更し、この手順の前のすべての作業で行った決定を取り入れることができます。後続の設計決定のために、この文書はこのガイドの (データ入力が可能な) 特定のワークシートを参照します。

作業 2e:仮想ネットワーク アダプターを定義する

トラフィックの性能、可用性、セキュリティ戦略に加え、仮想マシンで必要なトラフィックの種類を理解したら、仮想マシンごとに必要となる仮想ネットワーク アダプターの数を決定できます。

仮想ネットワーク アダプターが仮想スイッチに接続されます。3 種類の仮想スイッチがあります。

  • 外部仮想スイッチ

  • 内部仮想スイッチ

  • プライベート仮想スイッチ

外部仮想スイッチにより、仮想マシンは仮想スイッチに関連付けられているネットワーク アダプターを介して物理ネットワークにアクセスできます。ホストの物理ネットワーク アダプターを関連付けられる外部スイッチは 1 つだけです。

第 1 世代の仮想マシンには最大 12 個のネットワーク アダプターを接続できます。レガシー ネットワーク アダプターが 4 個と仮想ネットワーク アダプターが 8 個です。第 2 世代の仮想マシンはレガシー ネットワーク アダプターに対応しておらず、サポートされるアダプターの最大数は 8 になります。トランク モードで構成されていない限り、仮想ネットワーク アダプターには VLAN ID を 1 つ割り当てることができます。

仮想マシンのトラフィックを複数の VLAN に割り当てる場合、VLAN をサポートするネットワーク アダプターをホストに配置し、仮想スイッチに割り当てる必要があります。仮想マシンのプロパティで仮想マシンの VLAN ID を設定できます。仮想スイッチで設定されている VLAN ID は、ホスト オペレーティング システムに割り当てられている仮想ネットワーク アダプターに割り当てられる VLAN ID です。

**注:**利用できるアダプター以上のネットワークに仮想マシンがアクセスする必要がある場合、Set-VMNetworkAdapterVlan Windows PowerShell コマンドレットを利用し、仮想マシンのネットワーク アダプターの VLAN トランク モードを有効にする必要があります。

作業 2f:IP アドレス指定戦略を定義する

IP アドレスを仮想マシンに割り当てる方法を決定する必要があります。決定しない場合、IP アドレスの競合が発生する可能性があります。その場合、ネットワーク上の他の仮想マシンや物理デバイスに悪影響を与える可能性があります。

また、DHCP サーバーが承認されていない場合、ネットワーク インフラストラクチャに混乱が生じ、特にサーバーが仮想マシンとして実行されているときに追跡が難しくなることがあります。仮想マシンの設定で DHCPGuard を有効にすれば、ネットワークの仮想マシンで未承認の DHCP サーバーの実行を防止できます。DHCPGuard は、中間者攻撃で DHCP サーバーのふりをする悪意のある仮想マシンを防止します。

追加情報:

動的ホスト構成プロトコル (DHCP) 概要

DHCPGuard

IP アドレス管理 (IPAM) 概要

作業 3:記憶域構成を定義する

記憶域構成を決定するには、仮想マシンにより保存されるデータの種類と仮想マシンで必要とされる記憶域の種類を定義する必要があります。

作業 3a:データの種類を定義する

次の表は、仮想マシンで保存することがあるデータの種類とその種類のデータが一般的に保存される場所をまとめたものです。

[データの種類]

その種類のデータの保存場所

オペレーティング システム ファイル

仮想化ホストにより保存されている仮想ハード ディスク ファイル内仮想化ホストの保存に関する考慮事項については下の「手順 4:サーバー仮想化ホストの計画」で詳しく扱います。

Windows ページ ファイル

多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。

アプリケーション プログラム ファイル

多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。

アプリケーション構成データ

多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。

アプリケーション データ

多くの場合、アプリケーション ファイルとオペレーティング システム ファイルから離して保存されます。たとえば、アプリケーションがデーベース アプリケーションの場合、データベース ファイルは、オペレーティング システム ファイルやアプリケーション プログラム ファイルが保存されている場所から離れたところにあるネットワーク ベースの可用性と効率性にすぐれたストレージ ソリューションに保存されることが多いです。

クラスター化共有ボリューム (CSV) とディスク監視 (ゲスト仮想マシン クラスタリングに必要)

多くの場合、アプリケーション ファイルとオペレーティング システム ファイルから離して保存されます。

  • CSV 記憶域は、クラスターのすべてのノードで利用できるように、クラスター化されたアプリケーションがデータを保存する場所です。

  • ディスク監視は、クラスター構成データベースのコピーを保持するように指定されたクラスター記憶域内のディスクです。フェールオーバー クラスターには、クォーラム構成の一部として指定されている場合にのみディスク監視が与えられます。

クラッシュ ダンプ ファイル

多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。

作業 3b:記憶域の種類を定義する

次の表は、上の「手順 2、作業 2a」で定義されたデータの種類に利用されることがある記憶域の種類をまとめたものですす。

記憶域の種類

注意事項

仮想 IDE ディスク

第 1 世代の仮想マシン:

  • IDE コントローラーを 2 つ。各コントローラーは最大 4 つの IDE デバイスに対して最大 2 つの IDE デバイスをサポートできます。

  • ブート ディスクとも呼ばれる起動ディスクを仮想ハード ディスクまたは物理ディスクとして IDE デバイスの 1 つに接続する必要があります。

第 2 世代の仮想マシンは IDE デバイスに対応していません。

仮想 SCSI

  • 4 つの仮想 SCSI コントローラーがサポートされます。各コントローラーが最大 64 のデバイスをサポートするため、合計で 256 の SCSI デバイスがサポートされます。

  • 第 2 世代の仮想マシンは SCSI ドライブのみをサポートするため、第 2 世代の仮想マシンは SCSI ブート ディスクをサポートすることになります。

仮想マシンの iSCSI イニシエーター

  • SAN の記憶力の長所を活用します。ホストにファイバ チャネルを配置しません。

  • ブート ディスクには使用できません。

  • ネットワーク QoS ポリシーを使用し、記憶域と他のネットワーク トラフィックに適切な帯域幅を与えます。

  • Hyper-V レプリカとの互換性はありません。SAN 記憶域バックエンドを使用する場合、ストレージ ベンダーが提供する SAN レプリケーション オプションを使用します。

仮想ファイバ チャネル

  • 仮想ファイバ チャネル アダプターのある仮想マシンをホストする各ホストで 1 つまたは複数のファイバ チャネル HBA (Host Bus Adapter/ホスト バス アダプター) または FCoE (Fibre Channel over Ethernet) Converged Network Adapter を必要とします。

  • HBA と FCoE のドライバーが仮想ファイバ チャネルをサポートする必要があります。

  • NPIV 対応 SAN。

  • ライブ マイグレーションをサポートするには追加の構成が必要です。ライブ マイグレーションと仮想ファイバ チャネルの詳細については、「Hyper-V 仮想ファイバ チャネルの概要」を参照してください。

  • Hyper-V レプリカとの互換性はありません。SAN 記憶域を使用する場合、ストレージ ベンダーが提供する SAN レプリケーション オプションを使用します。

  • 仮想マシンには最大 4 つの仮想 SCSI ポートを与えることができます。

  • 仮想ファイバ チャネル LUN は仮想マシンのブート メディアとして使用できません。

SMB 3.0

仮想マシン内からサーバー メッセージ ブロック (SMB) 3.0 共有に保管されているファイルにアクセスします。

作業 3c:仮想ハード ディスクのフォーマットと種類を定義する

仮想ハード ディスク ストレージ タイプを使用している場合、最初に次の表にあるオプションから使用する VHD フォーマットを選択する表があります。

ディスク フォーマット

利点

短所

VHD

  • すべてのバージョンの Hyper-V でサポートされます。

  • オンプレミスの実装と Azure の両方でサポートされます。

  • 記憶域の最大容量は 2040 GB です。

  • Azure でサポートされている最大仮想ハード ディスクは 1 TB です。

  • 第 2 世代の仮想マシンでサポートされていません。

VHDX

  • 記憶域の最大容量は 64 テラバイト (TB) です。

  • 電源障害の発生時にデータが破損から保護されます。

  • 大容量のセクター ディスクで効率的に動作するように、仮想ハード ディスク フォーマットの配列が改善されました。

  • 4 KB 論理セクター仮想ディスクにより、4 KB セクターに合わせて設計されたアプリケーションまたはワークロードで使用されるときに性能が上がります。

  • フェールオーバー クラスタリングを必要とする仮想マシンの共有記憶域として使用できます。

  • 現在のところ、Azure の仮想マシンではサポートされていません。

  • Windows Server 2012 以前の Hyper-V バージョンでは使用できません。

共有 VHDX

ゲスト仮想マシン クラスターの共有記憶域に使用されます。

  • Hyper-V を実行しているホストで Windows Server 2012 R2 を必要とします。

  • 共有仮想ハード ディスクを使用するゲスト クラスターでサポートされるゲスト オペレーティング システムには Windows Server 2012 R2 と Windows Server 2012 が含まれます。ゲスト オペレーティング システムとして Windows Server 2012 をサポートするには、ゲスト (仮想マシン) 内に Windows Server 2012 R2 統合サービスをインストールする必要があります。

  • 次の機能は共有 VHDX との間に互換性がありません。

    • Hyper-V レプリカ

    • 構成した仮想マシンのいずれかを実行中に仮想ハード ディスクのサイズを変更すること

    • ライブ記憶域移行

    • ホスト レベルの VSS バックアップ。物理サーバーで実行しているクラスターに使用するものと同じ方法でゲスト レベルのバックアップを実行する必要があります。

    • 仮想マシンのチェックポイント

    • 記憶域 QoS

次に、次の表にあるオプションから使用するディスクの種類を選択します。

ディスクの種類

利点

短所

固定

  • 他の種類のディスクに比べ、断片化が発生しにくくなります。

  • 他の種類のディスクに比べ、CPU のオーバーヘッドが少なくなります。

  • VHD ファイルの作成後、他の種類のディスクに比べ、ディスク領域の可用性に関する心配が少なくなります。

  • オンプレミスの実装と Azure の両方でサポートされます。

  • 作成された仮想ハード ディスクは、仮想マシンが一部の領域しか使用しない場合でも、すべての領域を利用可能であることを必要とします。

  • 十分な記憶域領域が利用できないと、仮想ハード ディスクは作成できません。

  • 仮想ハード ディスクの未使用領域を他の仮想ハード ディスクに割り当てることはできません。

動的

プロビジョニングされているすべてのディスク領域を使用するのではなく、必要な分だけディスク領域を使用します。

  • 現在のところ、Azure ではこの機能はご利用いただけません。動的ディスクを固定ディスクに変換することはできます。

  • 動的仮想ハード ディスクを使用するとき、空きディスク領域を監視することが重要になります。動的仮想ハード ディスクの増加に対応できるディスク領域がない場合、仮想マシンは一時停止の危機的状態に入ります。

  • 仮想ハード ディスク ファイルが断片化することがあります。

  • 固定ディスクの場合と比べ、読み書き操作の CPU オーバーヘッドがわずかに高くなります。

差分

複数の差分ディスクで同じ親を使用する場合、使用するディスク領域が少なくて済みます。

  • 現在のところ、Azure ではご利用いただけません。

  • 親ディスクを変更すると、子ディスクのデータに不整合が生じる可能性があります。

  • I/O が大きいワークロードの場合、読み書き操作の CPU オーバーヘッドがわずかに高くなります。

仮想ハード ディスク ファイルの種類と形式を選択するときは次を考慮します。

  • VHDX フォーマットを使用するとき、動的ディスクを使用できます。必要なときにだけ領域を割り当てることで領域を節約できることに加え、回復性が保証されるためです。

  • ホスト ボリュームの記憶域を積極的に監視しない場合、フォーマットに関係なく、固定ディスクも使用できます。それにより、VHD ファイルが実行時に展開されるとき、十分なディスク領域が与えられます。

  • 仮想マシンのチェックポイント (以前のスナップショット) により、ディスクへの書き込みを保存するための差分仮想ハード ディスクが作成されます。チェックポイントがほんのわずかであれば、記憶域 I/O の CPU 利用率が上がっても、パフォーマンスには目立った影響はないでしょう (I/O が激しいサーバー ワークロードを除いて)。

    ただし、チェックポイントの連続が長くなると、パフォーマンスに目立った影響が現れます。仮想ハード ディスクから読み込むとき、たくさんの差分ディスクで、要求されたブロックを確認する必要があるからです。ディスクの I/O パフォーマンスを良好な状態に維持するには、チェックポイントの連続を短くすることが重要です。

作業 3d:データの種類別に使用する記憶域の種類を定義する

仮想マシンが保存するデータの種類と記憶域の種類を定義したら、データの種類別に使用する記憶域の種類と仮想ディスクのフォーマット/種類を決定できます。

作業 4:仮想マシンの可用性戦略を定義する

ファブリック管理者がファブリックの可用性を担当するが、仮想マシン管理者が最終的に仮想マシンの可用性を担当します。結果として、仮想マシン管理者はファブリックの機能を理解し、仮想マシンに適した可用性戦略を設計する必要があります。

次の表は、上の「手順 1、作業 2」で定義した特徴を持つワークロードを実行する仮想マシンについて 3 つの可用性戦略を分析したものです。一般的に、仮想マシン管理者が適宜計画できるように、ファブリックにダウンタイム アクティビティが予定されているとき、ファブリック管理者は仮想マシン管理者に前もって通知します。3 つの可用性戦略は次のようになります。

  • ステートレス

  • ステートフル

  • 共有ステートフル

ステートレス

オプション

注意事項

ホスト レベルで仮想マシン ライブ マイグレーション

  • 予定の保守管理のためにホストを休止させる場合、実行中の仮想マシンを稼働可能方途に移行し、仮想マシンのダウンタイムをなくすることができます。ホストの考慮事項に関する詳細については、下の「作業 5:サーバー仮想化ホストの可用性戦略を定義する」を参照してください。

  • 両方のホストがアクセスできるストレージに仮想マシンが保存されていない場合、ライブ マイグレーション中に仮想マシン記憶域を移動する必要があります。

  • ホストが予期せず失敗した場合、ホストで実行されているすべての仮想マシンは実行を停止します。別のホストで同じワークロードを実行し、仮想マシンを起動する必要があります。

負荷分散クラスター (Windows ネットワーク負荷分散による)

  • 仮想マシン管理者は少なくとも 2 つの仮想マシンで異なるホストにホストされている同一のワークロードを実行する必要があります。

  • ネットワーク負荷分散 (NLB) は仮想マシン管理者により仮想マシン内で構成されます。

  • NLB では、静的 IP アドレスをネットワーク アダプターに割り当てる必要があります。DHCP アドレス割り当てはサポートされていません。

  • 仮想マシン管理者はファブリック管理者と連係し、NLB 仮想 IP アドレスで使用するための IP アドレスを取得し、必要な DNS エントリを作成する必要があります。

  • ゲストの NLB により使用される仮想ネットワークに対して MAC スプーフィングを有効にします。この機能はノードとして NLB クラスターに参加している各仮想マシンのネットワーク アダプター設定から有効にできます。仮想マシンを再起動することなく、NLB クラスターを作成し、ノードを追加し、NLB クラスター構成を更新できます。

  • NLB クラスターに参加しているすべての仮想マシンが同じサブネットに存在する必要があります。

  • (ホストに障害が発生した場合でも) ワークロードの可用性を維持するために、仮想マシンのファブリック管理者は仮想マシンを異なるホストで実行する必要があります。

負荷分散クラスター (ハードウェア ロード バランサーによる)

  • この機能はファブリック レベルで提供する必要があります。ファブリック管理者はそれを必要とする仮想マシンのために負荷分散クラスターを構成する必要があります。あるいは、ハードウェア ロード バランサーの管理ポータルで仮想マシン管理者がそれを構成できるようにします。

  • 仮想マシン管理者は少なくとも 2 つの仮想マシンでファブリックにホストされている同一のワークロードを実行する必要があります。

  • 詳細については、ハードウェア ベンダーの製品ドキュメントを参照してください。

ステートフル

オプション

注意事項

Hyper-V クラスター

  • フェールオーバー クラスターを構成する必要があります。

  • CSV ファイルのクラスターの全ノードの間で記憶域を共有する必要があります。これは SAN 記憶域または SMB 3.0 ファイルの共有になります。

  • クラスターがホストの問題を検出したか、Hyper-V が仮想マシンのネットワークまたは記憶域の問題を検出したとき、仮想マシンを別のホストに移動できます。移動中、仮想マシンは実行を続けます。

  • ホストに致命的な障害が発生した場合、そのホストで実行されていた仮想マシンをクラスターの別のノードで起動できます。重要な仮想マシンを自動的に起動するように設定できます。それにより、ホストに致命的な障害が発生した場合のダウンタイムを抑えることができます。

  • クラスター対応更新を利用し、実行中の仮想マシンに影響を与えることなくホストに修正プログラムを適用できます。

  • 仮想マシンのアンチアフィニティを設定し、同じノードで仮想マシンを実行することを回避します。たとえば、2 つの Web サーバーを実行し、バックエンド アプリケーションにフロントエンド サービスを提供する場合、同じノードで両方の Web サーバーを実行しません。

  • ノードを保守管理モードにすることができます。フェールオーバー クラスター サービスが実行中の仮想マシンをクラスター内の別のノードに移します。ノードで仮想マシンが実行されていないとき、必要な保守管理を実行できます。

    フェールオーバー クラスターは保守管理モードのノードに仮想マシンを移しません。ノードを保守管理モードにする前に、既存の仮想マシンを実行し、お客様の SLA を維持できるだけの容量が Hyper-V の他のノードにあることを確認します。

共有ステートフル

クラスター対応のワークロードの実行中、仮想マシンのゲスト クラスタリングを有効にして可用性をさらに上げることができます。ゲスト クラスタリングは、仮想マシン内のワークロードの高可用性をサポートします。ゲスト クラスタリングは、仮想マシンが実行されているホストで障害が発生した場合でも、仮想マシンで実行されているワークロードを保護します。ワークロードはフェールオーバー クラスタリングによって保護されたため、他のノードの仮想マシンが自動的に引き継ぎます。

オプション

注意事項

仮想マシンのゲスト クラスタリング

  • 2 つ以上の仮想マシンが同時にアクセスできる共有記憶域が必要です。次の種類の接続がサポートされます。

    • iSCSI

    • 仮想ファイバ チャネル

    • 共有 VHDX

  • 仮想マシンのアンチアフィニティを設定し、両方の仮想マシンを同じクラスター ノードで実行することを回避します。

  • Azure では、仮想マシンのゲスト クラスタリングはサポートされていません。

  • 次の機能は共有 VHDX との間に互換性がありません。

    • Hyper-V レプリカ

    • 構成した仮想マシンのいずれかを実行中に仮想ハード ディスクのサイズを変更すること

    • ライブ記憶域移行

    • ホスト レベルの VSS バックアップ。物理サーバーで実行しているクラスターに使用するものと同じ方法でゲスト レベルのバックアップを実行する必要があります。

    • 仮想マシンのチェックポイント

    • 記憶域 QoS

追加情報:

共有仮想ハード ディスクを使用したゲスト クラスターを展開する

高可用性のためのゲスト クラスタリングの使用

障害回復

障害が発生した場合、必要なワークロードをどのくらい早く復旧し、クライアントへのサービス提供を再開できますか。場合によっては、わずか数分しか与えられないこともあります。

最新のデータを複製し、遅延によるデータの損失を許容できる範囲に抑えるためには、メイン データセンターから障害回復センターにデータを複製する必要があります。仮想マシンでワークロードを実行することで、プライマリ サイトからレプリカ サイトに仮想ハード ディスクと仮想マシンの設定ファイルを複製できます。

次の表は障害復旧オプションを比較したものです。

オプション

注意事項

Hyper-V レプリカ

  • 安価であり、障害復旧サイトでホストと記憶域のハードウェアを複製する必要がありません。

  • 仮想マシンを管理するツールと同じ管理ツールを使用し、レプリケーションを管理します。

  • データ損失要件に合わせてレプリケーション間隔を設定できます。

  • レプリカ サイトで使用する複数の IP アドレスを構成します。

  • ネットワーク インフラストラクチャに与える影響は最小です。

  • 物理ディスク (パススルー ディスクとも呼ばれます)、仮想ファイバ チャネル記憶域、共有仮想ハード ディスクで構成された仮想マシンはサポートされていません。

  • Hyper-V レプリカはデータ バックアップ記憶域とデータ取得の代わりとして利用できません。

  • 追加の復旧ポイントを構成する場合、レプリカ サイトで追加の記憶域が必要になります。

  • レプリケーション間隔の程度によりデータ損失量が決まります。

  • 大量の変更が発生する仮想マシンに短いレプリケーション間隔を設定した場合、レプリカ サイトで追加の記憶域が必要になります。

バックアップ

  • System Center Data Protection Manager など、Hyper-V 対応のバックアップ ソリューションを利用して完全な仮想マシンをバックアップします。

  • データ損失は前回のバックアップの古さで決まります。

  • 共有 VHDX ファイルで構成された仮想マシンはホスト レベルでバックアップできません。仮想マシンにバックアップ エージェントをインストールし、仮想マシン内からデータをバックアップします。

注:

  • System Center 2012 R2 - Virtual Machine Manager を実行しているときにレプリケーションを集中管理し、自動化するには、Microsoft Azure Site Recovery を使用する必要があります。

  • 仮想マシンを Azure に複製するには、Microsoft Azure Site Recovery を利用します。Azure への仮想マシンの複製は現在のところプレビュー モードです。

追加情報:

Microsoft Azure Site Recovery

重要:

  • Hyper-V レプリカ Capacity Planner を利用し、Hyper-V Replica がネットワーク インフラストラクチャに与える影響、プライマリ サーバー、レプリカ サーバー、拡張レプリカ サーバーのプロセッサ利用率、プライマリ サーバーとレプリカ サーバーのメモリ利用率、既存仮想マシンに基づくプライマリ サーバー、レプリカ サーバー、拡張レプリカ サーバーのディスク IOPS を理解します。

  • ワークロードには、AlwaysOn 可用性グループ (SQL Server) など、障害復旧ソリューションが内蔵されている場合があります。Hyper-V レプリカがワークロードでサポートされているかどうかはワークロードの文書で確認します。

追加情報:

Hyper-V レプリカ

System Center Data Protection Manager

作業 5:仮想マシンの種類を定義する

環境でワークロードをサポートするには、一意のリソース要件で仮想マシンを作成し、あらゆるワークロードのニーズを満たす必要があります。あるいは、同様のアプローチに仮想マシン ホスティング サービスの公共プロバイダーを利用することもできます。これは IaaS (Infrastructure-as-a-Service) とも呼ばれています。

Microsoft Azure インフラストラクチャ サービスが提供する仮想マシン構成の詳細については、「Azure の仮想マシンおよびクラウド サービスのサイズ」を参照してください。この文書の執筆時点で、このサービスは 13 通りの仮想マシン構成をサポートしていました。それぞれ、プロセッサ、メモリ、記憶域、IOP の領域の組み合わせが異なります。

設計の決定 - この手順の全作業で行った決定は仮想マシン構成ワークシートに入力できます。

手順 3:サーバー仮想化ホスト グループの計画

個々のサーバー ホストを定義する前に、ホスト グループを定義しておくと便利です。ホスト グループは、この手順の残りの作業で説明される共通目標を満たすためにまとめられ、名前が付けられたサーバーの集合です。

作業 1:物理的な場所を定義する

多くの場合、ハードウェア リソースは物理的な場所でグループに分け、管理します。そのため、組織内のファブリック リソースを含む場所を最初に定義します。

作業 2:ホスト グループの種類を定義する

さまざまな理由でホスト グループを作成できます。たとえば、次を基準にしてワークロードをホストします。

  • ワークロードの特性

  • リソースの要件

  • サービスの品質要件

次の図は、2 つの場所で 5 つのホスト グループを作成した組織の例です。

ホスト グループ

図 2ホスト グループの例

この組織は次の表にある理由からホスト グループを作成しました。

ホスト グループ

作成理由

ステートレスとステートフルのワークロード

  • これらのワークロード特性がこの組織で最も共通しており、両方の場所でこの種類のホスト グループを配置しました。

  • これらのワークロードはパフォーマンス レベルとサービス レベルで要件が似ています。

会計部門のステートフル ワークロードとステートレス ワークロード

このホスト グループのサーバーのハードウェア構成は環境にある他のステートレスまたはステートフル ワークロード ホスト グループと同じであるが、会計部門には組織の他の部門よりセキュリティ要件が高いアプリケーションがあります。その結果、ファブリックの他のホスト グループとは異なる方法で保護されるように、会計部門には専用のホスト グループが作成されました。

共有ステートフル ワークロード

このホスト グループによりホストされるワークロードは共有記憶域を必要とします。可用性の維持に関して Windows Server のフェールオーバー クラスタリングに依存しているためです。仮想マシンの構成が組織の他の仮想マシンと異なるため、これらのワークロードは専用ホスト グループによりホストされます。

高 I/O ステートフル ワークロード

このホスト グループのすべてのホストが他のホスト グループのホストより高速のネットワークに接続されています。

この組織はホスト グループで場所をつなぐこともできましたが、管理を簡易化するために、各ホスト グループの全メンバーを同じ場所に保持することにしました。この例からわかるように、ホスト グループはさまざまな理由から作成できます。その理由は組織によって異なります。組織に作成するホスト グループの種類が多ければ、環境の管理がそれだけ複雑になります。最終的に、仮想マシンのホスティング費用が増えます。

ヒントホスト グループ内のサーバー ハードウェアの標準化の度合いが高ければ、長期間におけるホスト グループの拡張と維持がそれだけ簡単になります。ホスト グループ内のサーバー ハードウェアを標準化する場合、仮想化ファブリック設計の考慮事項ワークシートでホスト グループ ワークシートに標準化された設定データを追加できます。物理ハードウェアの考慮事項の詳細については、「手順 4:サーバー仮想化ホストの計画」を参照してください。

現在のところ、仮想マシンをホストするパブリック クラウド プロバイダーのサービスは次のようになっています。

  • 共有ステートを必要としない仮想マシンのみをホストします。

  • 多くの場合、すべての顧客に提供するサービス品質指標のセットは 1 つだけです。

  • 特定のハードウェアを特定の顧客専用にしません。

同じハードウェアを含む 1 つのホスト グループ タイプで始め、ホスト グループ タイプを追加することをお勧めします。そのようにする利点は費用に勝ります。

作業 3:ホスト グループ メンバーをクラスター化するかどうかを決める

以前は、Windows Server のフェールオーバー クラスタリングはサーバーの可用性を上げるためだけに利用されていましたが、さまざまな機能を提供できるように改善されました。次の表の情報は、ホスト グループ メンバーをクラスター化するかどうか決める際に役立ちます。

オプション

利点

短所

ホスト グループのメンバーはフェールオーバー クラスターの一部である

  • いずれかのホストで障害が発生した場合、それがホストしている仮想マシンが残っているノードで自動的に再開されます。

  • 仮想マシンが現在実行されているノードでノードまたは仮想マシンの問題が検出された場合、仮想マシンをクラスター内の別のノードに移動できます。

  • クラスター対応更新を利用し、クラスター内のノードを簡単に更新できます。実行中の仮想マシンに影響はありません。

  • クラスター メンバーになるにはホストに特定の構成が必要になります。

  • ホストを Active Directory ドメインのメンバーにする必要があります。

  • フェールオーバー クラスタリングでネットワークと記憶域に関する追加要件が必要になります。

ホスト グループのメンバーはフェールオーバー クラスターの一部ではない

  • ホストは特定のクラスター構成を必要としません。

  • ホストを Active Directory ドメインのメンバーにする必要はありません。

  • 追加のネットワークと記憶域は必要ありません。

障害が発生したホストで実行されている仮想マシンは残っているホストに手動で移し (あるいは、何らかの自動化を利用できます)、再開する必要があります。

設計の決定 - この手順の全作業で行った決定は設定ワークシートに入力できます。

手順 4:サーバー仮想化ホストの計画

この手順では、仮想化ファブリックで実行する予定の仮想マシンをホストするために必要なホストの種類を定義します。場合によっては、調達とサポートの費用を下げるためにホスト構成の数を 1 つに限定します。また、間違った機材を購入すると展開費用が跳ね上がります。

クラウド プラットフォーム システム

Microsoft は最大級のデータセンターとクラウド サービスを運営してきた経験をファクトリ統合/完全検証集中システムに持ち込みます。Cloud Platform System (CPS) は Microsoft から Windows Server 2012 R2、System Center 2012 R2、Azure Pack からなる証明済みのソフトウェア スタックを Dell のクラウド サーバー、ストレージ、ネットワーク ハードウェアと組み合わせます。クラウドの拡張可能ビルディング ブロックとして、CPS は価値創出までの時間を短縮し、一貫性のあるクラウド体験を可能にします。

CPS は Platform-as-a-Service、Windows 仮想マシン、Linux 仮想マシンのためにセルフサービスのマルチテナント クラウド環境を提供します。SQL Server、SharePoint、Exchange など、Microsoft アプリケーションの最適化された展開パックが含まれています。ファクトリ統合によりリスクと複雑性が減り、展開時間が数か月から数日に短縮されます。サポート プロセスが簡略化され、インフラストラクチャの定期作業が自動化されたことで、IT リソースが解放され、イノベーションに集中できます。

詳細については、クラウド プラットフォーム システムサイトを参照してください。

Fast Track

独自のハードウェア (およびソフトウェア) 構成を設計する代わりに、Microsoft Private Cloud Fast Track プログラムを利用し、さまざまなハードウェア パートナーが提供するハードウェア構成を購入できます。

Fast Track プログラムは Microsoft とそのハードウェア パートナーが共同で取り組んでいるものであり、事前設定/検証済みのソリューションとそれを管理するためのツールを提供します。仮想化ファブリックの実装にともなうリスクと複雑性が減ります。

Fast Track プログラムは柔軟なソリューションを提供します。お客様はハードウェア ベンダーの技術を選ぶことができます。Windows Server オペレーティング システム、Hyper-V 技術、Microsoft System Center のコア技術を利用し、プライベート クラウド インフラストラクチャのビルディング ブロックをサービスとして提供します。

追加情報:

Microsoft Private Cloud Fast Track サイト

作業 1:コンピューティングの構成を定義する

この作業では、各ホストに必要なメモリの量、プロセッサの数、Windows Server のバージョンを決定します。ホストで実行する仮想マシンの数はこのセクションで説明するハードウェア コンポーネントにより決定されます。

**注:**ソリューションが完全にサポートされるには、購入したすべてのハードウェアに、実行している Windows Server のバージョンの Certified for Windows Server ロゴが付いている必要があります。

Certified for Windows Server ロゴは、サーバー システムがセキュリティ、信頼性、管理容易性において Microsoft の最高の技術水準を満たしていることを示します。その他の認定デバイスと認定ドライバーとともに、Cloud ワークロード、Enterprise ワークロード、ビジネス クリティカル アプリケーションの役割、機能、インターフェイスをサポートします。

Certified for Windows Server ハードウェアの最新一覧については、Windows Server カタログを参照してください。

作業 1a:プロセッサを定義する

Hyper-V は論理プロセッサをアクティブな各仮想マシンに 1 つまたは複数の仮想プロセッサとして与えます。Extended Page Table (EPT) や Nested Page Table (NPT) のような SLAT (Second Level Address Translation/第 2 レベルのアドレス変換) をサポートするプロセッサを利用し、実行時の効率性を上げることができます。Windows Server 2012 R2 の Hyper-V は最大 320 の論理プロセッサをサポートします。

考慮事項:

  • プロセッサを集中的に使用しないワークロードの場合、仮想プロセッサを 1 つ使用するように構成します。ホスト プロセッサの利用率を長期間観察し、割り当てたプロセッサで最大の効果が得られていることを確認します。

  • CPU を集中的に使用するワークロードの場合、2 つ以上の仮想プロセッサを割り当てます。最大 64 の仮想プロセッサを仮想マシンに割り当てることができます。仮想マシンで認識される仮想プロセッサの数はゲスト オペレーティング システムに依存します。たとえば、Windows Server 2008 Service Pack 2 が認識する仮想プロセッサは 4 つだけです。

追加情報:

Hyper-V の概要

Performance Tuning for Hyper-V Servers (Hyper-V サーバーのパフォーマンス調整)

作業 1b:メモリを定義する

物理サーバーはホストと実行する仮想マシンのために十分なメモリを必要とします。ホストは、仮想マシンの代わりに I/O を効率的に実行し、仮想マシン チェックポイントなどの操作を実行するためのメモリを必要とします。Hyper-V によりホストは十分なメモリを利用することができます。残りのメモリは仮想マシンに割り当てることができます。仮想マシンのサイズは各仮想マシンに予想される負荷ニーズに基づいて決定されます。

ハイパーバイザーはゲスト物理メモリを仮想化して仮想マシンを互いから分離し、仮想化されていないシステムと同様に、ゲスト オペレーティング システムごとに連続するゼロ基準のメモリ領域を提供します。最大のパフォーマンスを得るには、SLAT ベースのハードウェアを使用し、メモリ仮想化のパフォーマンス コストを最小限に抑えます。

仮想マシン メモリのサイズは、物理コンピューターのサーバー アプリケーションの場合と同じように決定します。仮想マシンに割り当てるメモリの量は、通常時とピーク時に予想される負荷を仮想マシンが無理なく処理できる量にする必要があります。メモリが足りないと、応答時間と CPU または I/O 使用率が大幅に増えます。

ある仮想マシンにメモリを割り当てると、他の仮想マシンが利用できるメモリの量が減ります。ホストに十分なメモリがなければ、仮想マシンは起動しません。

動的メモリを利用すれば、再起動操作の信頼性が上がり、統合数が増えます。それにより、プールされた VDI 環境など、仮想マシンのアイドル状態が多く、負荷が低い環境で特にコストが下がります。動的メモリの実行時構成を変更すると、ダウンタイムを減らし、要件変更に機敏に対応する能力を上げることができます。

動的メモリに関する詳細については、「作業 1b:メモリを定義する」を参照してください。仮想マシンのメモリの決定方法が説明されています。

追加情報:

動的メモリの概要

仮想 NUMA の概要

作業 1c:Windows Server オペレーティング システムのエディションを定義する

Windows Server Standard と Windows Server Datacenter の機能セットはまったく同じです。Windows Server Datacenter の場合、仮想マシンを無制限で利用できます。Windows Server Standard の場合、仮想マシンは 2 つに制限されます。

Windows Server 2012 R2 では、仮想マシンの自動ライセンス認証 (AVMA) 機能が追加されました。AVMA を利用すると、適切にライセンス認証されたサーバーに仮想マシンをインストールできます。分離された環境であっても、仮想マシンごとにプロダクト キーを管理する必要はありません。

AVMA を利用するには、ゲスト オペレーティング システムで Windows Server 2012 R2 Datacenter、Windows Server 2012 R2 Standard、または Windows Server 2012 R2 Essentials を実行する必要があります。次の表は各エディションを比較したものです。

エディション

利点

短所

標準

  • すべての Windows Server 機能を含みます。

  • 仮想化されていない環境または仮想化の度合いが低い環境で受け入れられます。

仮想マシンが 2 つに制限されます。

Datacenter

  • すべての Windows Server 機能を含みます。

  • 仮想マシンは無制限で利用できます。

  • 高度に仮想化されたプライベート クラウド環境で受け入れられます。

より高額です。

Hyper-V は Windows Server の Server Core インストール オプションにインストールできます。Server Core インストールはディスクに必要な領域、潜在的な攻撃、とりわけ、サービス提供要件を減らします。Server Core インストールはコマンド ライン、Windows PowerShell、またはリモート管理により管理されます。

使用する予定のソフトウェアのライセンス条項を確認することが重要です。

Microsoft Hyper-V Server

Microsoft Hyper-V Server はシンプルで信頼性の高い仮想化ソリューションを提供し、組織のサーバー活用を改善し、コストを削減します。Windows ハイパーバイザー、Windows Server ドライバー モデル、仮想化コンポーネントのみを含むスタンドアロンの製品です。

Hyper-V Server は顧客の既存 IT 環境に適合し、既存のプロビジョニング、管理プロセス、サポート ツールを活用できます。Windows Server の対応エディションと同じハードウェアと互換性があり、Microsoft System Center と、Windows Update、Active Directory、フェールオーバー クラスタリングなどの Windows 技術と完全統合します。

Hyper-V Server は無料でダウンロードできます。そのインストールはすでにライセンス認証されています。ただし、ホストされている仮想マシンで実行されているすべてのオペレーティング システムには適切なライセンスが必要です。

追加情報:

仮想マシンの自動ライセンス認証

Microsoft Hyper-V Server

Hyper-V Server のリモート管理

作業 2:ネットワーク構成を定義する

上の「手順 2、作業 2」では、仮想マシンのネットワークの設計に関する考慮事項について説明します。次にホストのネットワーク上の考慮事項について説明します。Hyper-V を展開するときに考慮し、計画しなければならないネットワーク トラフィックの種類がいくつかあります。次の目標を念頭に置いてネットワーク構成を設計します。

  • ネットワーク QoS を維持するには

  • ネットワークの冗長性を実現するには

  • 決められたネットワークにトラフィックを分離するには

作業 2a:ネットワーク トラフィックの種類を定義する

Hyper-V クラスターを展開するとき、いくつかの種類のネットワーク トラフィックを考慮する必要があります。次の表はトラフィックの種類をまとめたものです。

トラフィックの種類

説明

管理

  • Hyper-V を実行しているサーバーと基本インフラストラクチャ機能を接続します

  • Hyper-V のホスト オペレーティング システムと仮想マシンの管理に使用されます

クラスターと CSV

  • クラスター ハートビートやクラスター共有ボリューム (CSV) のリダイレクトなど、ノード間のクラスター通信に使用されます

  • フェールオーバー クラスタリングを利用して Hyper-V が展開されているときにのみ

ライブ マイグレーション

仮想マシンのライブ マイグレーションとシェアード ナッシングのライブ マイグレーションに使用されます

記憶域

SMB トラフィックまたは iSCSI トラフィックに使用されます

レプリカ

Hyper-V レプリカ機能を利用し、仮想マシンのレプリケーション トラフィックに使用されます

仮想マシン (テナント) トラフィック

  • 仮想マシンの接続に使用されます

  • 一般的に、クライアントの要求に応じるには外部のネットワークに接続する必要があります

注:仮想マシンのトラフィックの種類の一覧については「手順 2:仮想マシンの構成の計画」を参照してください。

バックアップ

仮想ハード ディスク ファイルのバックアップに使用されます

作業 2b:ネットワーク トラフィックのパフォーマンス オプションを定義する

ネットワーク トラフィックのそれぞれの種類に最大と最小の帯域幅要件と最小待機時間要件があります。以下では、さまざまなネットワーク パフォーマンス要件を満たすための戦略についてまとめています。

ポリシー ベース QoS

Hyper-V クラスターを展開するとき、少なくとも 6 つのトラフィック パターンまたはネットワークが必要になります。それぞれのネットワークがネットワークの冗長性を必要とします。まず、ホストの 12 のネットワーク アダプターから始めます。複数のクアッド ネットワーク アダプターを取り付けることができるが、ある時点でホストのスロットがなくなります。

ネットワーク機器は高速化が進んでいます。つい最近まで、1 GB ネットワーク アダプターが最速でした。サーバーには 10 GB のアダプターが一般的になり、10 GB インフラストラクチャの構築価格も手頃になってきました。

2 つの 10 GB ネットワーク アダプターからなるチームを取り付けると、1 GB のクアッド アダプターを 4 つの場合より帯域幅が増え、スイッチ ポートが少なくて済み、配線が単純になります。10 GB ネットワーク アダプターのチームにさらに多くの種類のネットワーク トラフィックを集中させるとき、ポリシー ベース QoS を利用すれば、仮想化インフラストラクチャのニーズが満たされるようにネットワーク トラフィックを管理できます。

ポリシー ベース QoS では、アプリケーションの種類、ユーザー、コンピューターに基づき、ネットワークの帯域幅制御を指定できます。QoS ポリシーを利用すれば、ネットワーク帯域幅を測定し、ネットワーク状態の変化 (帯域幅の輻輳や可用性など) を検出し、ネットワーク トラフィックに優先順位を付けることでワークロードまたはアプリケーションのサービス要件を満たします。

最大帯域幅を強制できるだけでなく、Windows Server 2012 R2 の QoS ポリシーは最小帯域幅という新しい帯域幅管理機能を提供します。帯域幅の上限である最大帯域幅とは異なり、最小帯域幅は帯域幅の下限です。特定の量の帯域幅を特定の種類のトラフィックに割り当てます。帯域幅の下限と上限を同時に実装できます。

利点

短所

  • グループ ポリシーにより管理されます

  • 複数の VLAN がネットワーク アダプターで実行されているとき、あるいは NIC チーミングを使用しているとき、簡単に VLAN に適用し、適切な帯域幅設定を提供します

  • ポリシー ベース QoS は IPsec トラフィックに適用できます

  • 仮想スイッチを利用しているトラフィックの帯域幅は管理しません

  • Hyper-V ホストはドメインに参加している必要があります

  • ソフトウェア ベース QoS ポリシーとハードウェア ベース QoS ポリシー (DCB) は同時に使用できません

追加情報:

サービスの品質 (QoS) の概要

ポリシー ベースのサービスの品質

データ センター ブリッジング

データ センター ブリッジング (DCB) は特定の種類のトラフィックにハードウェア ベースの帯域幅を割り当て、優先度基準のフロー制御でイーサネット トランスポートの信頼性を強化します。DCB は FCoE と iSCSI の使用時に推奨されます。

利点

短所

  • Microsoft iSCSI をサポートします。

  • FCoE をサポートします。

  • 次を含むハードウェア投資が必要です。

    • DCB 対応のイーサネット アダプター

    • DCB 対応のハードウェア スイッチ

  • 展開と管理が複雑です。

  • 仮想スイッチ トラフィックの帯域幅は管理しません。

  • ソフトウェア ベース QoS ポリシーと DCB ポリシーは同時に使用できません

追加情報:

データ センター ブリッジング (DCB) の概要

SMB ダイレクト

SMB ダイレクト (SMB over RDMA (リモート ダイレクト メモリ アクセス )) は Windows Server 2012 R2 のストレージ プロトコルです。サーバーとストレージの間でメモリ間の直接データ転送が可能になります。CPU の利用が最小限で済み、標準の RDMA 対応ネットワーク アダプターを使用します。ネットワーク要求に対する応答が非常に速くなり、結果として、リモート ファイル ストレージの応答時間が直接接続ブロック ストレージと同等になります。

利点

短所

  • スループットの向上:ネットワーク アダプターが回線速度で大量のデータの転送を調整する高速ネットワークの完全スループットを活用します。

  • 低い待機時間:ネットワーク要求に対する応答が非常に速くなり、結果として、リモート ファイル ストレージが直接接続ブロック ストレージのようになります。

  • 低い CPU 使用率:ネットワークでデータを転送するときに使用される CPU サイクルが少なく、仮想マシンの CPU サイクルを多く解放します。

  • 高速のライブ マイグレーションに SMB ダイレクトを使用するようにライブ マイグレーションを構成できます。

  • 既定ではホストで有効になっています。

  • 適切な構成が識別される場合、SMB クライアントは複数のネットワーク接続を自動的に検出し、使用します。

  • SMB 帯域幅管理を構成し、ライブ マイグレーション、仮想マシン、既定のストレージ トラフィックに制限を設定します。

  • SMB マルチチャンネルは RDMA 対応アダプターを必要としません。

  • RDMA 対応のネットワーク アダプターと NIC チーミングの間に互換性がありません。

  • 可用性を上げるには、2 つ以上の RDMA ネットワーク アダプターを各ホストに展開する必要があります。

  • 現在のところ、次の種類のネットワーク アダプターに制限されています。

    • iWARP

    • Infiniband

    • RoCE

  • RDMA と RoCE の組み合わせの場合、フロー制御に DCB が必要になります。

Receive Segment Coalescing

Receive Segment Coalescing (RSC) は、CPU から RSC 対応ネットワーク アダプターに作業負荷を分散することで、入ってくるネットワークの処理のための CPU 利用を減らします。

利点

短所

  • 大量の入ってくるネットワーク トラフィックの処理にかかる諸経費を減らし、サーバーの拡張性を高めます。

  • ネットワーク ストレージとライブ マイグレーションに使われる CPU サイクルを最小限に抑えます。

  • RSC 対応のネットワーク アダプターを必要とします。

  • 送信が多いワークロードの場合、大幅な向上はありません。

  • IPsec 暗号化トラフィックとの互換性はありません。

  • ホスト トラフィックに適用されます。RSC を仮想マシン トラフィックに適用するには、仮想マシンで Windows Server 2012 R2 を実行し、SR-IOV ネットワーク アダプターを含めて構成する必要があります。

  • Windows Server 2012 R2 にアップグレードされたサーバーでは既定では有効になっていません。

Receive Side Scaling

Receive-side scaling (RSS) を利用すると、ネットワーク アダプターは複数のコア コンピューターにある複数のプロセッサ コア全体でカーネルモードのネットワーク処理にかかる負荷を分散できます。この処理を分散することで、1 つのコアを使用する場合より、高いトラフィック負荷を処理できます。RSS は、たくさんのプロセッサ間でネットワーク処理の負荷を分散し、伝送制御プロトコル (TCP) により終了するトラフィックを積極的に負荷分散することでこれを達成します。

利点

短所

  • 複数のプロセッサに監視割り込みを分散するので、初期のバージョンの Windows Server のように 1 つのプロセッサですべての I/O 割り込みを処理する必要がありません。

  • NIC チーミングと連動します。

  • ユーザー データグラム プロトコル (UDP) トラフィックと連動します。

  • RSS 対応のネットワーク アダプターを必要とします。

  • 仮想ネットワーク アダプターが仮想スイッチにバインドされている場合は無効になります。仮想スイッチにバインドされている仮想ネットワーク アダプターの場合、RSS の代わりに VMQ が使用されます。

SR-IOV

Hyper-V は SR-IOV 対応のネットワーク デバイスをサポートし、物理ネットワーク アダプターの SR-IOV 仮想機能を仮想マシンに直接割り当てることができます。それによりネットワーク スループットが増え、ネットワークの待機時間が減り、ネットワーク トラフィックの処理に必要なホスト CPU オーバーヘッドが減ります。

SR-IOV の詳細については、上の「作業 2b:ネットワーク トラフィックのパフォーマンス オプションを定義する」を参照してください。

作業 2c:ネットワーク トラフィックの高可用性と帯域幅集約の方針

LBFO (Load Balancing and FailOver/負荷分散とフェールオーバー) とも呼ばれている NIC チーミングを利用すると、複数のネットワーク アダプターを 1 つのチームに配置し、帯域幅集約とトラフィック フェールオーバーを実行できます。それにより、ネットワーク コンポーネントに障害が発生した場合も接続が維持されます。

この機能はネットワーク アダプター ベンダーから提供されています。Windows Server 2012 で導入された NIC チーミングは Windows Server オペレーティング システムの機能として追加されています。

NIC チーミングは、次の 3 つの例外を除き、Windows Server 2012 R2 のすべてのネットワーク機能との間に互換性があります。

  • SR-IOV

  • RDMA

  • 802.1X 認証

拡張性の観点からは、Windows Server 2012 R2 では、最小 1 ~ 最大 32 のネットワーク アダプターを 1 つのチームに追加できます。無制限の数のチームを 1 つのホストで作成できます。

追加情報:

NIC チーミングの概要

Microsoft Virtual Academy:Windows Server 2012 の NIC チーミング

Windows PowerShell の NIC チーミング (NetLBFO) コマンドレット

Windows Server 2012 R2 NIC チーミング (LBFO) の展開と管理

ファイル サーバー記憶域を持つ集約型のデータ センター

作業 2d:ネットワーク トラフィックの分離とセキュリティの方策を定義する

ネットワーク トラフィックの種類ごとに分離や暗号化などの機能に関するセキュリティ要件を変えることができます。次の表は、さまざまなセキュリティ要件を満たすために利用できる方策についてまとめたものです。

方策

利点

短所

暗号化 (IPsec)

転送中のトラフィックが保護されます。

  • トラフィックの暗号化と復号化でパフォーマンスが影響を受けます。

  • 構成、管理、問題解決が複雑です。

  • IPsec 構成を間違って変更すると、ネットワークが混乱したり、トラフィックが正しく暗号化されなかったりします。

物理ネットワークの分離

ネットワークが物理的に分離されます。

  • 追加のネットワーク アダプターをホストに取り付ける必要があります。

  • ネットワークが高い可用性を必要とする場合、2 つ以上のネットワーク アダプターがネットワークごとに必要になります。

仮想ローカル エリア ネットワーク (VLAN)

  • 割り当てた VLAN ID を利用し、トラフィックを分離します。

  • VLAN トランキング プロトコルをサポートします。

  • プライベート VLAN をサポートします。

  • 多くの法人顧客によりすでに採用されています。

  • VLAN は最大 4094 個に限定されます。また、ほとんどのスイッチでサポートする VLAN は 1000 個までです。

  • ネットワーク機器に追加の構成と管理が必要となります。

  • VLAN は複数のイーサネット サブネットをまたぐことができません。そのため、1 つの VLAN のノード数が限定され、物理的な場所によっては仮想マシンの配置が制限されます。

作業 2e:仮想ネットワーク アダプターを定義する

仮想化サーバー ホストで必要なトラフィックの種類と、トラフィックのパフォーマンス、可用性、セキュリティに関する方策を理解したら、ホストごとに必要な物理ネットワーク アダプターの数と、各アダプターで転送されるネットワーク トラフィックの種類を決定できます。

作業 2f:仮想スイッチを定義する

仮想マシンをネットワークに接続するには、ネットワーク アダプターを Hyper-V 仮想スイッチに接続する必要があります。

3 種類の仮想スイッチを Hyper-V で作成できます。

  • 外部仮想スイッチ

    仮想マシンに物理ネットワークへのアクセスを与え、外部にあるサーバーとクライアントと通信するとき、外部仮想スイッチを使用します。この種類の仮想スイッチは、同じホストの仮想マシンが互いに通信することも可能にします。この種類のネットワークは、ネットワークの構成方法によっては、ホスト オペレーティング システムによる使用にも利用できます。

    **重要:**物理ネットワーク アダプターを一度にバウンドできる仮想スイッチは 1 つだけです。

  • 内部仮想スイッチ

    同じホストの仮想マシン間で、または仮想マシンとホスト オペレーティング システムの間で通信を許可するときは内部仮想スイッチを使用します。この種類の仮想スイッチは、ホスト オペレーティング システムから仮想マシンに接続する必要があるテスト環境を構築する際によく使用されます。内部仮想スイッチは物理ネットワーク アダプターにバインドされません。結果として、内部仮想ネットワークは外部ネットワーク トラフィックから分離されます。

  • プライベート仮想スイッチ

    同じホストの仮想マシン間でのみ通信を許可するときはプライベート仮想スイッチを使用します。プライベート仮想スイッチは物理ネットワーク アダプターにバインドされません。プライベート仮想スイッチは仮想化サーバーのすべての外部ネットワーク トラフィックから分離され、ホスト オペレーティング システムと外部ネットワークの間のネットワーク トラフィックから分離されます。この種類のネットワークは、隔離されたテスト ドメインなど、隔離されたネットワーク環境を構築する必要がある場合に役立ちます。

    **注:**プライベート仮想スイッチと内部仮想スイッチの場合、外部仮想スイッチに接続されている仮想マシンで利用できるハードウェア加速機能を利用しても効果が得られません。

設計の決定 - この手順の全作業で行った決定は仮想化ホスト ワークシートに入力できます。

ヒント同じネットワークに接続する異なるホストの仮想スイッチには同じ名前を付ける必要があります。それにより、仮想マシンを接続する仮想スイッチについて混乱がなくなり、ホスト間での仮想マシンの移動が簡単になります。同じ仮想スイッチが移動先のホストにないと、Move-VM Windows PowerShell コマンドレットは失敗します。

作業 3:記憶域構成を定義する

ホスト オペレーティング システムに必要な記憶域に加えて、各ホストは、仮想マシンの構成ファイルと仮想ハード ディスクが保存されている記憶域にアクセスする必要があります。この作業は仮想マシンの記憶域を中心に進めます。

作業 3a:データの種類を定義する

次は、記憶域要件について考慮する必要があるデータの種類の例です。

[データの種類]

その種類のデータの保存場所

ホスト オペレーティング システムのファイル

通常、ローカル ハード ドライブ

Windows のホスト ページ ファイルとクラッシュ ダンプ

通常、ローカル ハード ドライブ

フェールオーバー クラスターの共有状態

共有ネットワーク記憶域またはクラスター共有ボリューム

仮想ハード ディスク ファイルと仮想マシンの構成ファイル

通常、共有ネットワーク記憶域またはクラスター共有ボリューム

この手順の残りの部分では、仮想マシンに必要な記憶域を中心に進めます。

作業 3b:記憶域オプション

次のオプションは、仮想マシンの構成ファイルと仮想ハード ディスクを格納するために使用できます。

オプション 1:直接接続記憶域

直接接続記憶域は、ネットワークに直接接続する代わりに、サーバーに直接接続するコンピューター記憶域システムを指します。直接接続記憶域は内部記憶域のみに限定されません。JBOD (just-a-bunch-of-disks/ただのディスクの束) エンクロージャや、SAS またはその他のディスク コントローラーで接続されるエンクロージャなど、ハード ディスク ドライブを含む外部ディスク エンクロージャを使用することもできます。

利点

短所

  • 記憶域ネットワークを必要としません。

  • ディスク I/O が速く、記憶域要求をネットワークに送信する必要がありません。

  • 内部記憶域または、JBOD を含む、外部ディスク エンクロージャになります。

  • JBOD を記憶域スペース技術とともに利用し、すべての物理ディスクを 1 つの記憶域プールに結合し、プールの空き領域から 1 つまたは複数の仮想ディスク (記憶域スペースと呼ばれています) を作成できます。

  • JBOD は一般的に安価であり、専用 RAID アダプターの代わりに Windows または Windows Server オペレーティング システムを使用して記憶域を管理するため、多くの場合、RAID エンクロージャより柔軟であり、管理が簡単です。

  • 外部ディスク エンクロージャに接続できるサーバーの数には限りがあります。

  • 記憶域スペースを含む共有 SAS など、外部共有記憶域のみでフェールオーバー クラスタリングに対応します。

オプション 2:ネットワーク接続記憶域

ネットワーク接続記憶域デバイスは、そのデバイスがファイル共有を介してアクセスされるネットワークに記憶域を接続します。直接接続記憶域とは異なり、コンピューターに直接接続されません。

ネットワーク接続記憶域デバイスはイーサネット接続をサポートし、通常、管理者はディスク スペースを管理し、ディスク クォータを設定し、セキュリティを提供し、チェックポイント技術を使用できます。ネットワーク接続ストレージ デバイスは複数のプロトコルをサポートします。ネットワーク接続ファイル システム、共通インターネット ファイル システム (CIFS)、サーバー メッセージ ブロック (SMB) などです。

利点

短所

  • SAN より設定が簡単で、専用記憶域ハードウェアが少なくて済みます。

  • プラグ アンド プレイに対応しています。

  • 既存のイーサネット ネットワークを使用できます。

  • ネットワーク接続記憶域デバイスは SMB 3.0 をサポートする必要があります。CIFS はサポートされていません。

  • 記憶域にアクセスするホスト サーバーには直接接続できません。

  • 他の選択肢より遅くなります。

  • 最適なパフォーマンスを得るには、通常、専用ネットワークを必要とします。

  • 管理と機能に制限があります。

  • Hyper-V は、SMB 3.0 をサポートするネットワーク接続記憶域デバイスをサポートします。SMB 2.0 と CIFS はサポートされません。

  • RDMA はサポートされない場合があります。

オプション 3:記憶域ネットワーク

SAN (Storage Area Network/記憶域ネットワーク) は、記憶域の共有を可能にする専用ネットワークです。SAN は記憶域デバイス、相互接続ネットワーク インフラストラクチャ (スイッチ、ホスト バス アダプター、配線)、そのネットワークに接続されているサーバーから構成されます。SAN デバイスでは、大量のデータに連続して高速でアクセスできます。特定の展開のための通信とデータ転送は記憶域ファブリックと一般的に呼ばれています。

SAN は別個のネットワークを使用します。通常、ローカル エリア ネットワーク経由で他のデバイスがそのネットワークにアクセスすることはできません。SAN は Storage Management Initiative Specification (SMI-S)、簡易ネットワーク管理プロトコル (SNMP)、または独自の管理プロトコルで管理できます。

SAN はファイル抽象化をサポートしていません。ブロックレベルの操作のみです。使用されている最も一般的な SAN プロトコルは iSCSI、ファイバ チャネル、FCoE (Fiber Channel over Ethernet/イーサネット上のファイバ チャネル) です。SMI-S または独自の管理プロトコルは、ディスク ゾーニング、ディスク マッピング、LUN マスキング、障害管理など、追加機能を提供します。

利点

短所

  • SAN は別個のネットワークを使用するため、データ ネットワークに与える影響を抑えます。

  • 大量のデータに連続して高速でアクセスできます。

  • 通常、データの保護や複製など、追加機能を提供します。

  • さまざまなチームの間で共有できます。

  • 記憶域 LUN に直接アクセスするための仮想ファイバ チャネルをサポートします。

  • ゲスト クラスタリングをサポートします。

  • 64 TB 以上のデータ ボリュームにアクセスする必要がある仮想マシンは直接 LUN アクセスに仮想ファイバ チャネルを利用できます。

  • 高額になります。

  • 展開、管理、保守に専門的な技能が必要です。

  • HBA または FCoE ネットワーク アダプターを各ホストに取り付ける必要があります。

  • Hyper-V クラスターを移行するとき、計画を追加し、ダウンタイムを抑える必要があります。

  • FCoE トラフィックの帯域幅を管理するには、データ センター ブリッジングを使用するハードウェア QoS ポリシーが必要です。

  • FCoE トラフィックはルーティングできません。

オプション 4:サーバー メッセージ ブロック 3.0 ファイル共有

Hyper-V は、サーバー メッセージ ブロック (SMB) 3.0 プロトコルを使用するファイル共有に、構成ファイル、仮想ハード ディスク ファイル、チェックポイントなど、仮想マシン ファイルを保存できます。ファイル共有は一般的にスケールアウト ファイル サーバーに置かれ、冗長性を提供します。スケールアウト ファイル サーバーを実行しているとき、1 つのノードが停止した場合でも、スケールアウト ファイル サーバーの他のノードからファイル共有を引き続き利用できます。

利点

短所

  • 既存のネットワークとプロトコルを使用できます。

  • SMB マルチチャンネルは、Hyper-V を実行しているサーバーと SMB 3.0 ファイル共有の間で複数のパスを利用できるとき、ネットワーク帯域幅の集約とフォールト トレランスを提供します。

  • JBOD を記憶域スペース技術とともに利用し、すべての物理ディスクを 1 つの記憶域プールに結合し、プールの空き領域から 1 つまたは複数の仮想ディスク (記憶域スペースと呼ばれています) を作成できます。

  • SMB マルチチャンネルを仮想マシンの移行に利用できます。

  • SAN の展開より安価です。

  • Windows Server を実行するファイル サーバーで記憶域を柔軟に構成できます。

  • Hyper-V サービスを記憶域サービスから分離することで、必要に応じて各サービスを拡張できます。

  • Hyper-V クラスターを実行していれば、次のバージョンに柔軟にアップグレードできます。Hyper-V を実行しているサーバーまたはスケールアウト ファイル サーバーを任意の順序でダウンタイムなくアップグレードできます。アップグレードするには、1 つまたは 2 つのノードを削除するための容量がクラスターに必要になります。

  • スケールアウト ファイル サーバーは共有 VHDX をサポートします。

  • SMB 帯域幅管理では、ライブ マイグレーション、仮想ハード ディスク、既定の記憶域トラフィックに上限を設定できます。

  • SMB トラフィックを暗号化できます。パフォーマンスへの影響は最小限に抑えます。

  • VDI 展開では、データの重複除去でディスク領域を節約します。

  • 展開、管理、保守に専門的な技能を必要としません。

  • I/O パフォーマンスは SAN 展開の場合ほど速くありません。

  • VDI 展開を除き、仮想マシン ファイルの実行ではデータの重複除去がサポートされません。

SMB ダイレクト

SMB ダイレクトは SMB ファイル共有の一部として機能します。SMB ダイレクトは、記憶域に短い待機時間で高速アクセスするために、RDMA をサポートするネットワーク アダプターとネットワーク スイッチを必要とします。SMB ダイレクトを利用すれば、リモート ファイル サーバーをローカルの直接接続記憶域のように利用できます。SMB の利点に加え、SMB ダイレクトには次の長所と短所があります。

利点

短所

  • 高速で機能し、待機時間が短く、わずかしか CPU を利用しません。

  • Microsoft の記憶域ソリューションと安価な共有直接接続記憶域を利用することで、スケールアウト ファイル サーバーは記憶域に関して従来の SAN と同様のパフォーマンスと回復性を実現します。

  • ライブ マイグレーションと記憶域マイグレーションを最も速く完了します。

  • NIC チーミングではサポートされていません

  • 記憶域の冗長接続には、2 つ以上の RDMA 対応ネットワーク アダプターを必要とします。

スケールアウト ファイル サーバー

図 3ネットワーク集約と RDMA を利用するスケールアウト ファイル サーバーの例

追加情報:

Windows Server を使用した Hyper-V ワークロードのコスト効果の高い記憶域の提供

ファイル サーバー記憶域を持つ集約型のデータ センター

Hyper-V over SMB の展開

Windows Server 2012 R2 を使用してスケールアウト ファイル サーバー クラスター内の Hyper-V VM から 100 万を超える IOPS を実現する

作業 3c:物理ドライブ アーキテクチャの種類を定義する

記憶域に選択する物理ドライブ アーキテクチャの種類により記憶域ソリューションのパフォーマンスが変わります。ディスクの種類の詳細については、「Infrastructure-as-a-Service 製品ラインのアーキテクチャ」のセクション 7.1 を参照してください。

作業 3d:記憶域ネットワークの種類を定義する

使用する記憶域コントローラーまたは記憶域ネットワーク コントローラーの種類は、ホスト グループごとに選択した記憶域オプションによって決まります。詳細については、「作業 3b:記憶域オプション」を参照してください。

作業 3e:データの種類別に使用する記憶域の種類を決定する

データの種類を理解したら、要件を最も効果的に満たす記憶域オプション、記憶域コントローラー、記憶域ネットワーク コントローラー、物理ディスク アーキテクチャを決定できます。

設計の決定 - この作業で行った決定は仮想化ホスト ワークシートに入力できます。

追加情報:

Windows Server 2012 と Windows Server 2012 R2 における Hyper-V over SMB のネットワーク構成

Windows Server 2012 Hyper-V コンポーネント アーキテクチャ ポスターと比較参照

記憶域技術の概要

作業 4:サーバー仮想化ホストのスケール ユニットを定義する

個々のサーバーを購入するとき、各サーバーの調達、取り付け、構成が必要になります。スケール ユニットを利用することで、サーバー (通常、同一のハードウェアを含む) の集合を購入できます。サーバーは事前構成されており、個々のサーバーを追加するのではなく、スケール ユニットを追加することでデータセンターに容量を追加できます。

次の図はスケール ユニットの例です。数に関係なく、さまざまなハードウェア ベンダーから事前構成されたスケール ユニットを購入できます。ラック、無停電電源装置 (UPS)、ラック内に追加されたサーバーの冗長ネットワーク スイッチのペア、10 台のサーバーが含まれています。

ホスト スケール単位

図 4仮想化サーバー ホストのスケール ユニットの例

スケール ユニットは事前に構成されており、UPS とネットワーク スイッチに事前に配線された状態で提供されます。ユニットはデータセンターに追加し、電源装置に差し込み、ネットワークと記憶域に接続するだけですぐに使用できます。個々のコンポーネントをスケール ユニットとして購入した場合、購入者はすべてのコンポーネントをラックに入れ、配線する必要があります。

設計の決定 - サーバー仮想化ホストのスケール ユニットを使用する場合、ホストのスケール ユニット ワークシートに仮想化ホストのスケール ユニットのハードウェアを明記できます。

ヒントMicrosoft Private Cloud Fast Track プログラムでは、さまざまな Microsoft ハードウェア パートナーの事前構成済みスケール ユニットを購入できます。

作業 5:サーバー仮想化ホストの可用性戦略を定義する

前から決められていた理由 (保守管理) または予想外の理由により、仮想化サーバー ホストが利用できなくなることがあります。次はそのいずれの場合にも利用できる戦略です。

[計画済み]

ライブ マイグレーションを使用し、ホスト間で仮想マシンを移動できます。その場合、仮想マシンにダウンタイムがないことが求められます。

予想外

このシナリオは、ホストがホスティングしているワークロードの特性の種類によります。

  • 共有ステートフル ワークロードの場合、仮想マシン内でフェールオーバー クラスタリングを使用します。

  • ステートフル ワークロードの場合、Hyper-V クラスターで高可用仮想マシンとして実行します。

  • ステートレス ワークロードの場合、手動で、または何らかの自動化された手法で新しいインスタンスを起動します。

Windows Server と Hyper-V でフェールオーバー クラスタリングを使用している場合、次の表にある機能を使用するかどうかを考慮します。各機能に関する詳細については、ハイパーリンクをクリックしてください。

機能

注意事項

Hyper-V アプリケーション監視

フェールオーバー クラスタリング サービスで監視されないネットワークと記憶域のエラーがないか、仮想マシンを監視します。

仮想マシンの優先順位設定

  • ワークロードに基づき、仮想マシンの優先順位を設定します。高可用性仮想マシン (クラスター化された仮想マシン) に次の優先順位設定を割り当てることができます。

    • 中 (既定)

    • 自動起動しない

  • クラスター化された役割のうち、優先順位の高いものが低いものより先に起動し、ノードに配置されます。

  • [自動起動しない] 優先順位が割り当てられていない場合、その役割が障害の発生後に自動的にオンラインになることはありません。他の役割が起動できるように、リソースは利用可能な状態が維持されます。

仮想マシンのアンチアフィニティ

Hyper-V クラスターの同じノードで実行しない仮想マシンにアンチアフィニティを設定します。この設定は冗長性サービスを提供する仮想マシンやゲスト仮想マシン クラスターの一部である仮想マシンに使用されることがあります。

注:アンチアフィニティ設定は Windows PowerShell を利用して構成されます。

ノード ドレインの自動化

  • クラスターは、ノードを保守管理モードに入れる前に、またはその他の変更をノードで行う前に、ノードを自動的にドレインします (ノードで実行されているクラスター化された役割を別のノードに移動します)。

  • 保守管理操作の後、役割は元のノードにフェールバックします。

  • 管理者はフェールオーバー クラスター マネージャーで、または Windows PowerShell コマンドレットの Suspend-ClusterNode を使用し、1 回の操作でノードをドレインできます。移動するクラスター化された役割の移動先ノードを指定できます。

  • クラスター対応更新は自動化されたプロセスでノード ドレインを使用し、ソフトウェア更新をクラスター ノードに適用します。

クラスター対応更新

  • クラスター対応更新では、クラスターで実行している仮想マシンに影響を与えることなく、クラスターのノードを更新できます。

  • 実行中の仮想マシンの負荷を処理するために、更新プロセスの間、十分な数のクラスター ノードが利用可能な状態になっている必要があります。

優先順位に基づく仮想マシンのプリエンプション

仮想マシンの優先順位を設定するもう 1 つの理由は、優先順位の高い仮想マシンに起動するために必要なメモリとその他のリソースがないときに、クラスターは優先順位の低い仮想マシンをオフラインにできることにあります。

  • プリエンプション (差し替え) は優先順位が最も低い仮想マシンから始まり、優先順位が上位の仮想マシンに続きます。

  • 差し替えられた仮想マシンは後で優先順位に基づき再起動されます。

**注:**Hyper-V クラスターには最大 64 個のノードと 8,000 個の仮想マシンを追加できます。

手順 5:仮想化ファブリック アーキテクチャ概念の計画

この手順では、ファブリック アーキテクチャで採用する論理概念を定義します。

作業 1:保守管理ドメインを定義する

保守管理ドメインは、まとめてサービスが提供されるサーバーの論理的集合です。サービス提供には、ハードウェアまたはソフトウェアのアップグレードや構成変更が含まれることがあります。保守管理ドメインは一般的に各種のホスト グループにまたがるか、各場所で形成されます。ただし、そうする必要はありません。この目的は、サーバーの保守管理がコンシューマーのワークロードに悪影響を与えないようにすることです。

**注:**この概念は物理ネットワークと記憶域コンポーネントに適用されます。

作業 2:物理フォールト ドメインを定義する

ネットワーク スイッチや無停電電源装置 (UPS) など、共有インフラストラクチャ コンポーネントに障害が発生すると、多くの場合、仮想化サーバー ホストのグループに同時にエラーが発生します。物理フォールト ドメインは仮想化ファブリック内の回復に役立ちます。ファブリックに定義した各ホスト グループにフォールト ドメインが影響を与えるしくみを理解することが重要です。

**注:**この概念は物理ネットワークと記憶域コンポーネントに適用されます。

次の図の例をご覧ください。データセンター内のホスト グループの集合に保守管理と物理フォールト ドメインを重ねています。

フォールト ドメイン

図 5保守管理と物理フォールト ドメインの定義例

この例では、サーバーの各ラックが別個の番号付きの物理フォールト ドメインとして定義されています。これは各ラックの上部にネットワーク スイッチがあり、下部に UPS があるためです。ラック内のすべてのサーバーはこの 2 つのコンポーネントに依存しています。いずれかに障害が発生した場合、ラックのすべてのサーバーが事実上機能しなくなります。

ラック内のすべてのサーバーが一意のホスト グループのメンバーでもあるため、この設計の場合、物理フォールト ドメインのいずれかに障害が発生した場合、軽減策がないことを意味します。この問題を軽減するために、ホスト グループの種類ごとに物理フォールト ドメインを追加できます。これより規模の小さい環境であれば、各ラックに冗長のスイッチと電源装置を追加できます。あるいは、物理フォールト ドメイン全体で仮想化サーバー ホストにフェールオーバー クラスタリングを使用します。

図 5 では、色付きの点線ボックスにより保守管理ドメインが定義されます (MD 1 ~ 5 のラベルが付いています)。仮想マシンの負荷分散されたクラスターの各サーバーが、別個の保守管理ドメインと別個の物理フォールト ドメインに含まれるサーバー仮想化ホストでホスティングされるしくみに注意してください。

これにより、ファブリック管理者は、複数のサーバーを保守管理ドメイン全体で分散しているアプリケーションに大きな影響を与えることなく、すべての仮想化サーバー ホストを休止できます。これはまた、物理フォールト ドメインに障害が発生した場合、負荷分散されたクラスターで実行されているアプリケーションが完全に利用不可になることはないことを意味します。

設計の決定 - 作業 1 と 2 で行った決定は設定ワークシートに入力できます。

作業 3:予約容量を定義する

ファブリック内の個々のサーバーの障害は避けられません。ファブリックの設計では、フォールト ドメインと保守管理ドメインでサーバーの集合の障害に対応するのと同じように、個々のサーバーの障害に対応する必要があります。次の図は図 5 と同じであるが、障害が発生したサーバーを赤で示しています。

障害が発生したサーバー

図 6障害が発生したサーバー

図 6 では、サーバー仮想化ホストで次のホスト グループ、保守管理ドメイン、物理フォールト ドメインに障害が発生しました。

ホスト グループ

物理フォールト ドメイン

保守管理ドメイン

2

2

3

3

3

2

4

4

2

物理フォールト ドメイン 2 のホストに障害が発生しているが、負荷分散されたクラスターで実行されているアプリケーションは引き続き利用できます。ただし、アプリケーションは 3 分の 1 少ない容量で動作します。

物理フォールト ドメイン 3 の仮想マシンの 1 つをホスティングしているサーバー仮想化ホストにも障害が発生した場合、あるいは保守管理ドメイン 2 を保守管理のために休止した場合、何が起こるか考えてください。そのような場合、アプリケーションの容量が 3 分の 2 に減ります。

場合によっては、仮想化ファブリックにとってそれは受け入れられない状態であると判断されます。サーバー障害の影響を軽減するためには、物理フォールト ドメインと保守管理ドメインにそれぞれ、十分な予約容量を与えます。そうすれば、定義した許容レベルより容量が下がることはありません。

予約容量の計算に関する詳細については、「Cloud Services Foundation Reference Architecture – Principles, Concepts, and Patterns」の「Reserve Capacity」を参照してください。

手順 6:初期機能特性の計画

この文書の全作業を完了したら、ファブリックで満たせる初期サービス品質レベルに加え、ファブリックに仮想マシンと記憶域をホストするための初期費用を決定できます。ただし、この文書の「次の手順」セクションで説明するファブリック管理ツールと人事を実装するまで、これらの作業のいずれも最終処理することはできません。

作業 1:記憶域と仮想マシンの初期 SLA 指標を定義する

ファブリック管理者は、多くの場合、ファブリックが満たすサービス品質指標について説明するサービス レベル アグリーメント (SLA) を定義します。仮想マシン管理者がファブリックの利用方法を計画するためには、この SLA を把握する必要があります。

SLA には少なくとも可用性指標を含めるが、その他の指標も含まれます。仮想化ファブリックの SLA 指標の基準を理解するには、Microsoft Azure などのパブリック クラウド プロバイダーが提供する基準を参考にできます。仮想マシンのホスティングの場合、お客様が同じワークロードを実行している仮想マシンの 2 つ以上のインスタンスを展開し、それらのインスタンスを異なるフォールト ドメインとアップグレード ドメイン (この文書では「保守管理ドメイン」と読んではいます) で展開するとき、Microsoft Azure の SLA は、仮想マシンの少なくとも 1 つの可用性を 99.95% にするとしています。

Azure SLA の全文については、「サービス レベル アグリーメント」を参照してください。仮想化ファブリックはパブリック クラウド プロバイダーの SLA を満たすか、それを超えるものにします。

作業 2:記憶域と仮想マシンをホストするための初期コストを定義する

ファブリックを設計したら、次の計算も可能になります。

  • ファブリックのハードウェア、領域、電力、冷却費用

  • ファブリックのホスティング容量

この情報を、ファブリック管理ツールや人事のコストなど、他のコストと合わせることで、仮想マシンと記憶域をホストするための最終的なコストを決定できます。

仮想マシンと記憶域の基準コストを理解するには、Microsoft Azure などのパブリック クラウド プロバイダーのホスティング費用を参考にできます。詳細については、「Virtual Machine 料金」を参照してください。

常にではありませんが、一般的に、ホスティング費用はパブリック プロバイダーのそれよりも高くなります。それはあなたのファブリックが大手のパブリック プロバイダーのファブリックよりずっと小さいためです。ファブリックが大きければ、ハードウェア、データセンターの領域、電力でボリューム割引きを受けられます。

次のステップ

この文書の全作業を完了したら、組織の要件を満たすファブリックが設計されています。初期サービスの特性も定義され、それにコストとサービス レベル指標が含まれています。人事費用と、ファブリックに使用する管理ツールとプロセスを決定するまで、最終的なサービス レベル指標とコストは決定できません。

Microsoft System Center 2012 が提供する包括的な機能セットを利用すれば、仮想化ファブリックをプロビジョニングし、監視し、保守管理できます。次のリソースを参考にして System Center をファブリック管理に利用する方法を学習できます。

System Center テクニカル ドキュメント ライブラリ

ファブリック管理アーキテクチャ ガイド