仮想化ファブリック設計の考慮事項ガイド
このガイドの対象読者 中規模または大規模な組織で働く情報技術 (IT) の専門家は、さまざまな仮想マシンに対応する仮想化ファブリックの設計を担当します。この文書では、このような専門家のことを「ファブリック管理者」と呼ぶことにします。ファブリックでホストされる仮想マシンを管理する人物は「仮想マシン管理者」とも呼ばれますが、この文書の対象読者ではありません。組織によっては IT 管理者は両方の役割を担うことがあります。
このガイドの目的 このガイドは、組織内の多数の仮想マシンをホストできる仮想化ファブリックを設計する方法を理解するために役立ちます。この文書では、組織内の仮想マシンのホストに使用される一連のサーバー、ハイパーバイザー、ストレージとネットワークのためのハードウェアを「仮想化ファブリック」と呼びます。次の図は仮想化ファブリックを示しています。
.jpeg "仮想化ファブリック")
図 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 世代 |
|
新しい仮想マシンの機能にアクセスできません |
第 2 世代 |
|
|
重要: Linux の第 2 世代仮想マシンはセキュア ブートに対応していません。仮想マシンを作成し、Linux をインストールするとき、仮想マシンの設定でセキュア ブートをオフにする必要があります。
追加情報:
作業 1b:メモリを定義する
物理コンピューターのサーバー アプリケーションの場合と同様に、仮想マシンのメモリのサイズを計画する必要があります。通常時とピーク時に予測される負荷を無理なく処理できる量にする必要があります。メモリが足りないと、応答時間、CPU 使用率、I/O 使用率が大幅に増えます。
静的メモリまたは動的メモリ
静的メモリとは、仮想マシンに割り当てられるメモリの量です。仮想マシンを起動したときに常に割り当てられ、仮想マシンの実行中は変更されません。全メモリが起動時に仮想マシンに割り当てられます。ある仮想マシンによって使用されていないメモリを他の仮想マシンが使用できることはありません。ホストに十分なメモリがなく、起動時に仮想マシンに割り当てられない場合、仮想マシンは起動しません。
静的メモリは、メモリの使用率が高いワークロードや、SQL Server など、独自のメモリ管理システムを持つワークロードに最適です。このような種類のワークロードは静的メモリで性能が上がります。
注: 静的メモリを有効にする設定はありません。静的メモリは動的メモリ設定が有効でない場合に有効になります。
動的メモリを有効にした場合、システムの物理メモリを効率的に利用できます。複数の仮想マシンの間で合計物理メモリをバランス良く配分します。多忙な仮想マシンに多くのメモリを割り当て、利用頻度が少ない仮想マシンからメモリを解放します。仮想デスクトップ インフラストラクチャ (VDI) または Web サーバーなどの動的な環境で、統合率が上がることが見込まれます。
静的メモリを利用するとき、仮想マシンに 10 GB のメモリが割り当てられているが、3 GB しか利用していない場合でも、残りの 7 GB を他の仮想マシンが利用することはできません。仮想マシンで動的メモリを有効にすると、仮想マシンは必要な量のメモリだけを使用します。ただし、設定されている最小 RAM より下になることはありません。他の仮想マシンのためにメモリが多くのメモリが解放されます。
次の表は、静的メモリと動的メモリの長所と短所をまとめたものです。
オプション |
利点 |
短所 |
|---|---|---|
静的メモリ |
|
|
動的メモリ |
|
|
次はメモリ構成設定です。
スタートアップ 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 を有効にして動的メモリは無効にします。
仮想マシンで実行しているワークロードは NUMA 対応ですか。
仮想マシンは 1 つの物理 NUMA ノードで利用できる以上のリソース、プロセッサ、メモリを消費しますか。
作業 1d:サポートされるオペレーティング システムを明確にする
ワークロードに必要なオペレーティング システムがゲスト オペレーティング システムとしてサポートされることを確認する必要があります。次の点を考慮します。
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
Linux の場合:サポートされている Linux ディストリビューションの詳細については、「Hyper-V の Linux 仮想マシン」を参照してください。
注: 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) |
|
|
SR-IOV |
|
|
|
|
|
Jumbo Frame |
|
|
作業 2c:ネットワーク トラフィックの可用性オプションを定義する
LBFO (Load Balancing and FailOver/負荷分散とフェールオーバー) とも呼ばれている NIC チーミングを利用すると、複数のネットワーク アダプターを 1 つのチームに配置し、帯域幅集約とトラフィック フェールオーバーを実行できます。 それにより、ネットワーク コンポーネントに障害が発生した場合も接続が維持されます。一般的に NIC チーミングはホストで構成されます。仮想スイッチを作成すると、ネットワーク アダプター チームにバインドされます。
展開されているネットワーク スイッチにより NIC チーミング モードが決定されます。大半の展開では、Windows Server 2012 R2 の既定設定で十分です。
注: SR-IOV は NIC チーミングに対応していません。SR-IOV に関する詳細については、「作業 2b:ネットワーク トラフィックのパフォーマンス オプションを定義する」を参照してください。
追加情報:
作業 2d:ネットワーク トラフィックのセキュリティ オプションを定義する
ネットワーク トラフィックの種類ごとにセキュリティ要件を変えることができます。たとえば、分離や暗号化に関連する要件を与えることができます。次の表は、さまざまなセキュリティ要件を満たすために利用できる方策についてまとめたものです。
方策 |
利点 |
短所 |
|---|---|---|
複数のネットワーク アダプターで分割する |
他のネットワーク トラフィックからトラフィックを切り離します。 |
拡張性が制限されます。ネットワークの数が増えると、それだけ多くのネットワーク アダプターをホストにインストールし、管理する必要があります。 |
IPsec と IPsec タスク オフロード |
|
|
VLAN タグ付け |
|
|
|
|
|
|
有効にしたとき、パフォーマンスがわずかな影響を受けます。 |
|
|
有効にしたとき、パフォーマンスがわずかな影響を受けます。 |
設計の決定 - 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 サーバーのふりをする悪意のある仮想マシンを防止します。
追加情報:
作業 3:記憶域構成を定義する
記憶域構成を決定するには、仮想マシンにより保存されるデータの種類と仮想マシンで必要とされる記憶域の種類を定義する必要があります。
作業 3a:データの種類を定義する
次の表は、仮想マシンで保存することがあるデータの種類とその種類のデータが一般的に保存される場所をまとめたものです。
［データの種類］ |
その種類のデータの保存場所 |
|---|---|
オペレーティング システム ファイル |
仮想化ホストにより保存されている仮想ハード ディスク ファイル内仮想化ホストの保存に関する考慮事項については下の「手順 4:サーバー仮想化ホストの計画」で詳しく扱います。 |
Windows ページ ファイル |
多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。 |
アプリケーション プログラム ファイル |
多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。 |
アプリケーション構成データ |
多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。 |
アプリケーション データ |
多くの場合、アプリケーション ファイルとオペレーティング システム ファイルから離して保存されます。たとえば、アプリケーションがデーベース アプリケーションの場合、データベース ファイルは、オペレーティング システム ファイルやアプリケーション プログラム ファイルが保存されている場所から離れたところにあるネットワーク ベースの可用性と効率性にすぐれたストレージ ソリューションに保存されることが多いです。 |
クラスター化共有ボリューム (CSV) とディスク監視 (ゲスト仮想マシン クラスタリングに必要) |
多くの場合、アプリケーション ファイルとオペレーティング システム ファイルから離して保存されます。
|
クラッシュ ダンプ ファイル |
多くの場合、オペレーティング システム ファイルと同じ場所に保存されます。 |
作業 3b:記憶域の種類を定義する
次の表は、上の「手順 2、作業 2a」で定義されたデータの種類に利用されることがある記憶域の種類をまとめたものですす。
記憶域の種類 |
注意事項 |
|---|---|
仮想 IDE ディスク |
第 1 世代の仮想マシン:
第 2 世代の仮想マシンは IDE デバイスに対応していません。 |
仮想 SCSI |
|
仮想マシンの iSCSI イニシエーター |
|
仮想ファイバ チャネル |
|
SMB 3.0 |
仮想マシン内からサーバー メッセージ ブロック (SMB) 3.0 共有に保管されているファイルにアクセスします。 |
作業 3c:仮想ハード ディスクのフォーマットと種類を定義する
仮想ハード ディスク ストレージ タイプを使用している場合、最初に次の表にあるオプションから使用する VHD フォーマットを選択する表があります。
ディスク フォーマット |
利点 |
短所 |
|---|---|---|
VHD |
|
|
|
|
|
ゲスト仮想マシン クラスターの共有記憶域に使用されます。 |
|
次に、次の表にあるオプションから使用するディスクの種類を選択します。
ディスクの種類 |
利点 |
短所 |
|---|---|---|
固定 |
|
|
動的 |
プロビジョニングされているすべてのディスク領域を使用するのではなく、必要な分だけディスク領域を使用します。 |
|
差分 |
複数の差分ディスクで同じ親を使用する場合、使用するディスク領域が少なくて済みます。 |
|
仮想ハード ディスク ファイルの種類と形式を選択するときは次を考慮します。
VHDX フォーマットを使用するとき、動的ディスクを使用できます。必要なときにだけ領域を割り当てることで領域を節約できることに加え、回復性が保証されるためです。
ホスト ボリュームの記憶域を積極的に監視しない場合、フォーマットに関係なく、固定ディスクも使用できます。それにより、VHD ファイルが実行時に展開されるとき、十分なディスク領域が与えられます。
仮想マシンのチェックポイント (以前のスナップショット) により、ディスクへの書き込みを保存するための差分仮想ハード ディスクが作成されます。チェックポイントがほんのわずかであれば、記憶域 I/O の CPU 利用率が上がっても、パフォーマンスには目立った影響はないでしょう (I/O が激しいサーバー ワークロードを除いて)。
ただし、チェックポイントの連続が長くなると、パフォーマンスに目立った影響が現れます。仮想ハード ディスクから読み込むとき、たくさんの差分ディスクで、要求されたブロックを確認する必要があるからです。ディスクの I/O パフォーマンスを良好な状態に維持するには、チェックポイントの連続を短くすることが重要です。
作業 3d:データの種類別に使用する記憶域の種類を定義する
仮想マシンが保存するデータの種類と記憶域の種類を定義したら、データの種類別に使用する記憶域の種類と仮想ディスクのフォーマット/種類を決定できます。
作業 4:仮想マシンの可用性戦略を定義する
ファブリック管理者がファブリックの可用性を担当するが、仮想マシン管理者が最終的に仮想マシンの可用性を担当します。結果として、仮想マシン管理者はファブリックの機能を理解し、仮想マシンに適した可用性戦略を設計する必要があります。
次の表は、上の「手順 1、作業 2」で定義した特徴を持つワークロードを実行する仮想マシンについて 3 つの可用性戦略を分析したものです。一般的に、仮想マシン管理者が適宜計画できるように、ファブリックにダウンタイム アクティビティが予定されているとき、ファブリック管理者は仮想マシン管理者に前もって通知します。3 つの可用性戦略は次のようになります。
ステートレス
ステートフル
共有ステートフル
ステートレス
オプション |
注意事項 |
|---|---|
ホスト レベルで仮想マシン ライブ マイグレーション |
|
負荷分散クラスター (Windows ネットワーク負荷分散による) |
|
負荷分散クラスター (ハードウェア ロード バランサーによる) |
|
ステートフル
オプション |
注意事項 |
|---|---|
|
共有ステートフル
クラスター対応のワークロードの実行中、仮想マシンのゲスト クラスタリングを有効にして可用性をさらに上げることができます。ゲスト クラスタリングは、仮想マシン内のワークロードの高可用性をサポートします。ゲスト クラスタリングは、仮想マシンが実行されているホストで障害が発生した場合でも、仮想マシンで実行されているワークロードを保護します。ワークロードはフェールオーバー クラスタリングによって保護されたため、他のノードの仮想マシンが自動的に引き継ぎます。
オプション |
注意事項 |
|---|---|
|
追加情報:
共有仮想ハード ディスクを使用したゲスト クラスターを展開する
障害回復
障害が発生した場合、必要なワークロードをどのくらい早く復旧し、クライアントへのサービス提供を再開できますか。場合によっては、わずか数分しか与えられないこともあります。
最新のデータを複製し、遅延によるデータの損失を許容できる範囲に抑えるためには、メイン データセンターから障害回復センターにデータを複製する必要があります。仮想マシンでワークロードを実行することで、プライマリ サイトからレプリカ サイトに仮想ハード ディスクと仮想マシンの設定ファイルを複製できます。
次の表は障害復旧オプションを比較したものです。
オプション |
注意事項 |
|---|---|
Hyper-V レプリカ |
|
バックアップ |
|
注:
System Center 2012 R2 - Virtual Machine Manager を実行しているときにレプリケーションを集中管理し、自動化するには、Microsoft Azure Site Recovery を使用する必要があります。
仮想マシンを Azure に複製するには、Microsoft Azure Site Recovery を利用します。Azure への仮想マシンの複製は現在のところプレビュー モードです。
追加情報:
重要:
Hyper-V レプリカ Capacity Planner を利用し、Hyper-V Replica がネットワーク インフラストラクチャに与える影響、プライマリ サーバー、レプリカ サーバー、拡張レプリカ サーバーのプロセッサ利用率、プライマリ サーバーとレプリカ サーバーのメモリ利用率、既存仮想マシンに基づくプライマリ サーバー、レプリカ サーバー、拡張レプリカ サーバーのディスク IOPS を理解します。
ワークロードには、AlwaysOn 可用性グループ (SQL Server) など、障害復旧ソリューションが内蔵されている場合があります。Hyper-V レプリカがワークロードでサポートされているかどうかはワークロードの文書で確認します。
追加情報:
System Center Data Protection Manager
作業 5:仮想マシンの種類を定義する
環境でワークロードをサポートするには、一意のリソース要件で仮想マシンを作成し、あらゆるワークロードのニーズを満たす必要があります。あるいは、同様のアプローチに仮想マシン ホスティング サービスの公共プロバイダーを利用することもできます。これは IaaS (Infrastructure-as-a-Service) とも呼ばれています。
Microsoft Azure インフラストラクチャ サービスが提供する仮想マシン構成の詳細については、「Azure の仮想マシンおよびクラウド サービスのサイズ」を参照してください。この文書の執筆時点で、このサービスは 13 通りの仮想マシン構成をサポートしていました。それぞれ、プロセッサ、メモリ、記憶域、IOP の領域の組み合わせが異なります。
設計の決定 - この手順の全作業で行った決定は仮想マシン構成ワークシートに入力できます。
手順 3:サーバー仮想化ホスト グループの計画
個々のサーバー ホストを定義する前に、ホスト グループを定義しておくと便利です。ホスト グループは、この手順の残りの作業で説明される共通目標を満たすためにまとめられ、名前が付けられたサーバーの集合です。
作業 1:物理的な場所を定義する
多くの場合、ハードウェア リソースは物理的な場所でグループに分け、管理します。そのため、組織内のファブリック リソースを含む場所を最初に定義します。
作業 2:ホスト グループの種類を定義する
さまざまな理由でホスト グループを作成できます。たとえば、次を基準にしてワークロードをホストします。
ワークロードの特性
リソースの要件
サービスの品質要件
次の図は、2 つの場所で 5 つのホスト グループを作成した組織の例です。
.jpeg "ホスト グループ")
図 2ホスト グループの例
この組織は次の表にある理由からホスト グループを作成しました。
ホスト グループ |
作成理由 |
|---|---|
ステートレスとステートフルのワークロード |
|
会計部門のステートフル ワークロードとステートレス ワークロード |
このホスト グループのサーバーのハードウェア構成は環境にある他のステートレスまたはステートフル ワークロード ホスト グループと同じであるが、会計部門には組織の他の部門よりセキュリティ要件が高いアプリケーションがあります。その結果、ファブリックの他のホスト グループとは異なる方法で保護されるように、会計部門には専用のホスト グループが作成されました。 |
共有ステートフル ワークロード |
このホスト グループによりホストされるワークロードは共有記憶域を必要とします。可用性の維持に関して Windows Server のフェールオーバー クラスタリングに依存しているためです。仮想マシンの構成が組織の他の仮想マシンと異なるため、これらのワークロードは専用ホスト グループによりホストされます。 |
高 I/O ステートフル ワークロード |
このホスト グループのすべてのホストが他のホスト グループのホストより高速のネットワークに接続されています。 |
この組織はホスト グループで場所をつなぐこともできましたが、管理を簡易化するために、各ホスト グループの全メンバーを同じ場所に保持することにしました。この例からわかるように、ホスト グループはさまざまな理由から作成できます。その理由は組織によって異なります。組織に作成するホスト グループの種類が多ければ、環境の管理がそれだけ複雑になります。最終的に、仮想マシンのホスティング費用が増えます。
ヒントホスト グループ内のサーバー ハードウェアの標準化の度合いが高ければ、長期間におけるホスト グループの拡張と維持がそれだけ簡単になります。ホスト グループ内のサーバー ハードウェアを標準化する場合、仮想化ファブリック設計の考慮事項ワークシートでホスト グループ ワークシートに標準化された設定データを追加できます。物理ハードウェアの考慮事項の詳細については、「手順 4:サーバー仮想化ホストの計画」を参照してください。
現在のところ、仮想マシンをホストするパブリック クラウド プロバイダーのサービスは次のようになっています。
共有ステートを必要としない仮想マシンのみをホストします。
多くの場合、すべての顧客に提供するサービス品質指標のセットは 1 つだけです。
特定のハードウェアを特定の顧客専用にしません。
同じハードウェアを含む 1 つのホスト グループ タイプで始め、ホスト グループ タイプを追加することをお勧めします。そのようにする利点は費用に勝ります。
作業 3:ホスト グループ メンバーをクラスター化するかどうかを決める
以前は、Windows Server のフェールオーバー クラスタリングはサーバーの可用性を上げるためだけに利用されていましたが、さまざまな機能を提供できるように改善されました。次の表の情報は、ホスト グループ メンバーをクラスター化するかどうか決める際に役立ちます。
オプション |
利点 |
短所 |
|---|---|---|
ホスト グループのメンバーはフェールオーバー クラスターの一部である |
|
|
ホスト グループのメンバーはフェールオーバー クラスターの一部ではない |
|
障害が発生したホストで実行されている仮想マシンは残っているホストに手動で移し (あるいは、何らかの自動化を利用できます)、再開する必要があります。 |
設計の決定 - この手順の全作業で行った決定は設定ワークシートに入力できます。
手順 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 つだけです。
追加情報:
Performance Tuning for Hyper-V Servers (Hyper-V サーバーのパフォーマンス調整)
作業 1b:メモリを定義する
物理サーバーはホストと実行する仮想マシンのために十分なメモリを必要とします。ホストは、仮想マシンの代わりに I/O を効率的に実行し、仮想マシン チェックポイントなどの操作を実行するためのメモリを必要とします。Hyper-V によりホストは十分なメモリを利用することができます。残りのメモリは仮想マシンに割り当てることができます。仮想マシンのサイズは各仮想マシンに予想される負荷ニーズに基づいて決定されます。
ハイパーバイザーはゲスト物理メモリを仮想化して仮想マシンを互いから分離し、仮想化されていないシステムと同様に、ゲスト オペレーティング システムごとに連続するゼロ基準のメモリ領域を提供します。最大のパフォーマンスを得るには、SLAT ベースのハードウェアを使用し、メモリ仮想化のパフォーマンス コストを最小限に抑えます。
仮想マシン メモリのサイズは、物理コンピューターのサーバー アプリケーションの場合と同じように決定します。仮想マシンに割り当てるメモリの量は、通常時とピーク時に予想される負荷を仮想マシンが無理なく処理できる量にする必要があります。メモリが足りないと、応答時間と CPU または I/O 使用率が大幅に増えます。
ある仮想マシンにメモリを割り当てると、他の仮想マシンが利用できるメモリの量が減ります。ホストに十分なメモリがなければ、仮想マシンは起動しません。
動的メモリを利用すれば、再起動操作の信頼性が上がり、統合数が増えます。それにより、プールされた VDI 環境など、仮想マシンのアイドル状態が多く、負荷が低い環境で特にコストが下がります。動的メモリの実行時構成を変更すると、ダウンタイムを減らし、要件変更に機敏に対応する能力を上げることができます。
動的メモリに関する詳細については、「作業 1b:メモリを定義する」を参照してください。仮想マシンのメモリの決定方法が説明されています。
追加情報:
作業 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 を実行する必要があります。次の表は各エディションを比較したものです。
エディション |
利点 |
短所 |
|---|---|---|
標準 |
|
仮想マシンが 2 つに制限されます。 |
Datacenter |
|
より高額です。 |
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 は無料でダウンロードできます。そのインストールはすでにライセンス認証されています。ただし、ホストされている仮想マシンで実行されているすべてのオペレーティング システムには適切なライセンスが必要です。
追加情報:
作業 2:ネットワーク構成を定義する
上の「手順 2、作業 2」では、仮想マシンのネットワークの設計に関する考慮事項について説明します。次にホストのネットワーク上の考慮事項について説明します。Hyper-V を展開するときに考慮し、計画しなければならないネットワーク トラフィックの種類がいくつかあります。次の目標を念頭に置いてネットワーク構成を設計します。
ネットワーク QoS を維持するには
ネットワークの冗長性を実現するには
決められたネットワークにトラフィックを分離するには
作業 2a:ネットワーク トラフィックの種類を定義する
Hyper-V クラスターを展開するとき、いくつかの種類のネットワーク トラフィックを考慮する必要があります。次の表はトラフィックの種類をまとめたものです。
トラフィックの種類 |
説明 |
|---|---|
管理 |
|
クラスターと CSV |
|
ライブ マイグレーション |
仮想マシンのライブ マイグレーションとシェアード ナッシングのライブ マイグレーションに使用されます |
記憶域 |
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 ポリシーは最小帯域幅という新しい帯域幅管理機能を提供します。帯域幅の上限である最大帯域幅とは異なり、最小帯域幅は帯域幅の下限です。特定の量の帯域幅を特定の種類のトラフィックに割り当てます。帯域幅の下限と上限を同時に実装できます。
利点 |
短所 |
|---|---|
|
|
追加情報:
データ センター ブリッジング
データ センター ブリッジング (DCB) は特定の種類のトラフィックにハードウェア ベースの帯域幅を割り当て、優先度基準のフロー制御でイーサネット トランスポートの信頼性を強化します。DCB は FCoE と iSCSI の使用時に推奨されます。
利点 |
短所 |
|---|---|
|
|
追加情報:
SMB ダイレクト
SMB ダイレクト (SMB over RDMA (リモート ダイレクト メモリ アクセス )) は Windows Server 2012 R2 のストレージ プロトコルです。サーバーとストレージの間でメモリ間の直接データ転送が可能になります。CPU の利用が最小限で済み、標準の RDMA 対応ネットワーク アダプターを使用します。ネットワーク要求に対する応答が非常に速くなり、結果として、リモート ファイル ストレージの応答時間が直接接続ブロック ストレージと同等になります。
利点 |
短所 |
|---|---|
|
|
Receive Segment Coalescing
Receive Segment Coalescing (RSC) は、CPU から RSC 対応ネットワーク アダプターに作業負荷を分散することで、入ってくるネットワークの処理のための CPU 利用を減らします。
利点 |
短所 |
|---|---|
|
|
Receive Side Scaling
Receive-side scaling (RSS) を利用すると、ネットワーク アダプターは複数のコア コンピューターにある複数のプロセッサ コア全体でカーネルモードのネットワーク処理にかかる負荷を分散できます。この処理を分散することで、1 つのコアを使用する場合より、高いトラフィック負荷を処理できます。RSS は、たくさんのプロセッサ間でネットワーク処理の負荷を分散し、伝送制御プロトコル (TCP) により終了するトラフィックを積極的に負荷分散することでこれを達成します。
利点 |
短所 |
|---|---|
|
|
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 つのホストで作成できます。
追加情報:
Microsoft Virtual Academy:Windows Server 2012 の NIC チーミング
Windows PowerShell の NIC チーミング (NetLBFO) コマンドレット
Windows Server 2012 R2 NIC チーミング (LBFO) の展開と管理
作業 2d:ネットワーク トラフィックの分離とセキュリティの方策を定義する
ネットワーク トラフィックの種類ごとに分離や暗号化などの機能に関するセキュリティ要件を変えることができます。次の表は、さまざまなセキュリティ要件を満たすために利用できる方策についてまとめたものです。
方策 |
利点 |
短所 |
|---|---|---|
暗号化 (IPsec) |
転送中のトラフィックが保護されます。 |
|
物理ネットワークの分離 |
ネットワークが物理的に分離されます。 |
|
仮想ローカル エリア ネットワーク (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 またはその他のディスク コントローラーで接続されるエンクロージャなど、ハード ディスク ドライブを含む外部ディスク エンクロージャを使用することもできます。
利点 |
短所 |
|---|---|
|
|
オプション 2:ネットワーク接続記憶域
ネットワーク接続記憶域デバイスは、そのデバイスがファイル共有を介してアクセスされるネットワークに記憶域を接続します。直接接続記憶域とは異なり、コンピューターに直接接続されません。
ネットワーク接続記憶域デバイスはイーサネット接続をサポートし、通常、管理者はディスク スペースを管理し、ディスク クォータを設定し、セキュリティを提供し、チェックポイント技術を使用できます。ネットワーク接続ストレージ デバイスは複数のプロトコルをサポートします。ネットワーク接続ファイル システム、共通インターネット ファイル システム (CIFS)、サーバー メッセージ ブロック (SMB) などです。
利点 |
短所 |
|---|---|
|
|
オプション 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 マスキング、障害管理など、追加機能を提供します。
利点 |
短所 |
|---|---|
|
|
オプション 4:サーバー メッセージ ブロック 3.0 ファイル共有
Hyper-V は、サーバー メッセージ ブロック (SMB) 3.0 プロトコルを使用するファイル共有に、構成ファイル、仮想ハード ディスク ファイル、チェックポイントなど、仮想マシン ファイルを保存できます。ファイル共有は一般的にスケールアウト ファイル サーバーに置かれ、冗長性を提供します。スケールアウト ファイル サーバーを実行しているとき、1 つのノードが停止した場合でも、スケールアウト ファイル サーバーの他のノードからファイル共有を引き続き利用できます。
利点 |
短所 |
|---|---|
|
|
SMB ダイレクト
SMB ダイレクトは SMB ファイル共有の一部として機能します。SMB ダイレクトは、記憶域に短い待機時間で高速アクセスするために、RDMA をサポートするネットワーク アダプターとネットワーク スイッチを必要とします。SMB ダイレクトを利用すれば、リモート ファイル サーバーをローカルの直接接続記憶域のように利用できます。SMB の利点に加え、SMB ダイレクトには次の長所と短所があります。
利点 |
短所 |
|---|---|
|
|
.jpeg "スケールアウト ファイル サーバー")
図 3ネットワーク集約と RDMA を利用するスケールアウト ファイル サーバーの例
追加情報:
Windows Server を使用した Hyper-V ワークロードのコスト効果の高い記憶域の提供
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 台のサーバーが含まれています。
.jpeg "ホスト スケール単位")
スケール ユニットは事前に構成されており、UPS とネットワーク スイッチに事前に配線された状態で提供されます。ユニットはデータセンターに追加し、電源装置に差し込み、ネットワークと記憶域に接続するだけですぐに使用できます。個々のコンポーネントをスケール ユニットとして購入した場合、購入者はすべてのコンポーネントをラックに入れ、配線する必要があります。
設計の決定 - サーバー仮想化ホストのスケール ユニットを使用する場合、ホストのスケール ユニット ワークシートに仮想化ホストのスケール ユニットのハードウェアを明記できます。
ヒントMicrosoft Private Cloud Fast Track プログラムでは、さまざまな Microsoft ハードウェア パートナーの事前構成済みスケール ユニットを購入できます。
作業 5:サーバー仮想化ホストの可用性戦略を定義する
前から決められていた理由 (保守管理) または予想外の理由により、仮想化サーバー ホストが利用できなくなることがあります。次はそのいずれの場合にも利用できる戦略です。
[計画済み]
ライブ マイグレーションを使用し、ホスト間で仮想マシンを移動できます。その場合、仮想マシンにダウンタイムがないことが求められます。
予想外
このシナリオは、ホストがホスティングしているワークロードの特性の種類によります。
共有ステートフル ワークロードの場合、仮想マシン内でフェールオーバー クラスタリングを使用します。
ステートフル ワークロードの場合、Hyper-V クラスターで高可用仮想マシンとして実行します。
ステートレス ワークロードの場合、手動で、または何らかの自動化された手法で新しいインスタンスを起動します。
Windows Server と Hyper-V でフェールオーバー クラスタリングを使用している場合、次の表にある機能を使用するかどうかを考慮します。各機能に関する詳細については、ハイパーリンクをクリックしてください。
機能 |
注意事項 |
|---|---|
フェールオーバー クラスタリング サービスで監視されないネットワークと記憶域のエラーがないか、仮想マシンを監視します。 |
|
|
|
仮想マシンのアンチアフィニティ |
Hyper-V クラスターの同じノードで実行しない仮想マシンにアンチアフィニティを設定します。この設定は冗長性サービスを提供する仮想マシンやゲスト仮想マシン クラスターの一部である仮想マシンに使用されることがあります。 注:アンチアフィニティ設定は Windows PowerShell を利用して構成されます。 |
|
|
|
|
仮想マシンの優先順位を設定するもう 1 つの理由は、優先順位の高い仮想マシンに起動するために必要なメモリとその他のリソースがないときに、クラスターは優先順位の低い仮想マシンをオフラインにできることにあります。
|
注: Hyper-V クラスターには最大 64 個のノードと 8,000 個の仮想マシンを追加できます。
手順 5:仮想化ファブリック アーキテクチャ概念の計画
この手順では、ファブリック アーキテクチャで採用する論理概念を定義します。
作業 1:保守管理ドメインを定義する
保守管理ドメインは、まとめてサービスが提供されるサーバーの論理的集合です。サービス提供には、ハードウェアまたはソフトウェアのアップグレードや構成変更が含まれることがあります。保守管理ドメインは一般的に各種のホスト グループにまたがるか、各場所で形成されます。ただし、そうする必要はありません。この目的は、サーバーの保守管理がコンシューマーのワークロードに悪影響を与えないようにすることです。
注: この概念は物理ネットワークと記憶域コンポーネントに適用されます。
作業 2:物理フォールト ドメインを定義する
ネットワーク スイッチや無停電電源装置 (UPS) など、共有インフラストラクチャ コンポーネントに障害が発生すると、多くの場合、仮想化サーバー ホストのグループに同時にエラーが発生します。物理フォールト ドメインは仮想化ファブリック内の回復に役立ちます。ファブリックに定義した各ホスト グループにフォールト ドメインが影響を与えるしくみを理解することが重要です。
注: この概念は物理ネットワークと記憶域コンポーネントに適用されます。
次の図の例をご覧ください。データセンター内のホスト グループの集合に保守管理と物理フォールト ドメインを重ねています。
.jpeg "フォールト ドメイン")
この例では、サーバーの各ラックが別個の番号付きの物理フォールト ドメインとして定義されています。これは各ラックの上部にネットワーク スイッチがあり、下部に UPS があるためです。ラック内のすべてのサーバーはこの 2 つのコンポーネントに依存しています。いずれかに障害が発生した場合、ラックのすべてのサーバーが事実上機能しなくなります。
ラック内のすべてのサーバーが一意のホスト グループのメンバーでもあるため、この設計の場合、物理フォールト ドメインのいずれかに障害が発生した場合、軽減策がないことを意味します。この問題を軽減するために、ホスト グループの種類ごとに物理フォールト ドメインを追加できます。これより規模の小さい環境であれば、各ラックに冗長のスイッチと電源装置を追加できます。あるいは、物理フォールト ドメイン全体で仮想化サーバー ホストにフェールオーバー クラスタリングを使用します。
図 5 では、色付きの点線ボックスにより保守管理ドメインが定義されます (MD 1 ～ 5 のラベルが付いています)。仮想マシンの負荷分散されたクラスターの各サーバーが、別個の保守管理ドメインと別個の物理フォールト ドメインに含まれるサーバー仮想化ホストでホスティングされるしくみに注意してください。
これにより、ファブリック管理者は、複数のサーバーを保守管理ドメイン全体で分散しているアプリケーションに大きな影響を与えることなく、すべての仮想化サーバー ホストを休止できます。これはまた、物理フォールト ドメインに障害が発生した場合、負荷分散されたクラスターで実行されているアプリケーションが完全に利用不可になることはないことを意味します。
設計の決定 - 作業 1 と 2 で行った決定は設定ワークシートに入力できます。
作業 3:予約容量を定義する
ファブリック内の個々のサーバーの障害は避けられません。ファブリックの設計では、フォールト ドメインと保守管理ドメインでサーバーの集合の障害に対応するのと同じように、個々のサーバーの障害に対応する必要があります。次の図は図 5 と同じであるが、障害が発生したサーバーを赤で示しています。
.jpeg "障害が発生したサーバー")
図 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 をファブリック管理に利用する方法を学習できます。