仮想環境での容量管理と高可用性 (SharePoint Server 2010)
トピックの最終更新日: 2016-11-30
ここでは、Microsoft SharePoint Server 2010 をホストする仮想環境の容量管理と高可用性について説明します。これら 2 つの概念をこの記事でまとめて説明するのは、容量とサイズ調整は仮想化計画および仮想環境のアーキテクチャの開発の非常に重要な部分であり、容量管理は仮想環境での高可用性から切り離すことができないためです。仮想化ホストの場合、容量が十分ではないと、ファーム レベルおよびホスト レベルで高可用性が阻害されます。
仮想環境におけるバックアップや回復などの他の側面と同様に、容量管理と高可用性も仮想環境の 2 つの階層に対応する必要があります。つまり、SharePoint Server 2010 に使用される仮想マシンと、仮想マシンをホストするために使用される物理サーバーです。ハイブリッド環境の場合は、物理的な Microsoft SharePoint Server ファーム サーバーにも対応する必要があります。
この記事の内容
仮想化の概要
容量管理
仮想化サーバーの容量とサイズ調整
アーキテクチャの作成と調整
アーキテクチャを改善するための他のオプション
仮想化の概要
Windows Server 2008 Hyper-V テクノロジまたは Microsoft Hyper-V Server 2008 で実装されるサーバーの仮想化は、ソフトウェアではなくハードウェアに基づくものであり、ハードウェア依存の仮想化とも呼ばれます。ソフトウェア ベースの仮想化テクノロジと比較して、Hyper-V のハイパーバイザーと物理サーバーのハードウェア コンポーネントとの間の通信パスおよび相互作用は、いっそう直接的です。結果として、パフォーマンスはソフトウェア ベースの仮想化テクノロジより優れています。Hyper-V のアーキテクチャの詳細については、「An Introduction to Hyper-V in Windows Server 2008 (英語)」(https://go.microsoft.com/fwlink/?linkid=188006&clcid=0x411) (英語) および「Monitoring Hyper-V performance (英語)」(https://go.microsoft.com/fwlink/?linkid=187746&clcid=0x411) (英語) を参照してください。
物理サーバーが Hyper-V の要件を満たすとしても、各物理サーバーは固有です。すべての製造元は、プロセッサ、マルチコア テクノロジ、メモリ、データ バス、ハード ディスク、ネットワーク アダプターなどに独自の実装を使用しています。さらに、製造元が同じであっても、ハードウェアの設計や実装はモデルごとに異なります。そのため、SharePoint Server 2010 を仮想環境に展開するときは、厳密なテストを実施する必要があります。
ソフトウェア プログラムとアプリケーションも、ハードウェアと同じようなパフォーマンスの差異を示します。CPU を大量に使用するプログラム、メモリが大量に必要なプログラム、ハード ディスクを大量に使用するプログラムなどの違いがあります。SharePoint Server には、インターネット インフォメーション サービス (IIS) や SQL Server 2008 と同様に、独自の容量ニーズがあります。やはり、厳密なテストが必要です。
容量管理では、仮想化サーバー、ストレージ ソリューション、ネットワーク インフラストラクチャ、SharePoint Server 環境で実行するテクノロジ、SharePoint Server ソリューションを実装するために有効にする機能などを考慮する必要があります。
容量の管理
容量管理は、容量計画の概念を拡張して循環的な方法を表したものであり、変化する条件と要件に対応するために SharePoint Server 2010 展開の容量を継続的に監視して最適化します。この方法は、完全に仮想化されたものや、部分的に仮想化されたものなど、すべての SharePoint Server ファームに適用できます。容量管理の概要については、「SharePoint Server 2010 での容量管理と規模設定」を参照してください。「Capacity Management for SharePoint Server 2010 (英語)」(https://go.microsoft.com/fwlink/?linkid=194748&clcid=0x411) (英語) リソース センターには、容量管理に関する他のリソースがあります。
仮想化サーバーの容量とサイズ調整
SharePoint Server ファームの設計と、ファーム サーバーのサイズに関する推奨事項を作成した後、仮想ファームのサポートに必要な物理仮想化ホスト アーキテクチャを設計します。仮想アーキテクチャの詳細については、「仮想アーキテクチャを計画する (SharePoint Server 2010)」を参照してください。
SharePoint Server 2010 の容量管理から該当する原則を使用し、それを仮想環境のガイドとして使用することをお勧めします。以下のアクティビティでは、初期計画から運用環境への展開までの、仮想および物理アーキテクチャの設計、サイズ調整、および調節の反復的特徴を説明します。
注意
徹底的な計画とテストを行っておけば、後でアーキテクチャやサーバーの構成を変更することが必要になるのは、ファームの使用が予想外に大きく増加した場合、または SharePoint Server ソリューションに新しい機能が追加された場合だけです。
ファームの展開を開始する前に、仮想および物理アーキテクチャと、仮想マシンおよび仮想化サーバーのサイズ調整を作成します。複数の仮想化ホストがある場合は、このアーキテクチャに仮想マシンの分散を含める必要があります。
展開のパイロット フェーズの間に、正常性およびパフォーマンスのデータを収集します。それを使用すると、ファームの仮想マシンおよび仮想化ホストのベンチマークを確立できます。
展開のユーザー受け入れテストの間に、ベンチマーク データに基づいて、仮想化ホストと仮想マシンの構成を調節します。必要がある場合は、仮想化ホスト上に仮想マシンを再度分散させて、物理アーキテクチャを変更します。
展開の後は、引き続き正常性とパフォーマンスのベンチマークを収集し、仮想マシンおよび該当する場合は物理マシンの構成を微調整します。必要に応じて、両方のアーキテクチャを調節します。
仮想化ホストと仮想マシンのパフォーマンス データを分析し、それが容量のニーズおよび容量に対するアプリケーションの影響をどのように反映しているかを理解できることが重要です。さらに、パフォーマンスと容量の制限を理解する必要があります。仮想層と物理層の間の相互関係を考慮して、仮想マシンの容量とパフォーマンスに影響を与えるものは、ホストに直接反映するか、またはファームで許容されるパフォーマンスを維持するために仮想化ホストの構成を変更することで対応する必要があります。
場合によっては、新しく仮想化ホストを追加し、物理アーキテクチャでの仮想マシンの分散を変更することで、物理アーキテクチャを変更することが必要になる場合があります。
重要
物理コンピューターと仮想マシンの間のベンチマーク テストでは、通常、仮想マシンのスループットは、物理コンピューターのスループットと一致できません。わずかな例外はありますが、仮想マシンのパフォーマンスは、常に、物理コンピューターのパフォーマンスより劣ります。パフォーマンスの違いの大きさは、仮想化ホストの能力、実行しているアプリケーション、および主要なパフォーマンス指標として選択したベンチマークによって異なります。
「Hyper-V Performance FAQ R2 (英語)」(https://go.microsoft.com/fwlink/?linkid=187745&clcid=0x411) (英語) を読むことをお勧めします。この資料は、Windows Server 2008 R2 および Windows Server 2008 Service Pack 2 (SP2) の容量とパフォーマンスの情報を反映して更新されています。この FAQ には、一般的な Hyper-V の質問に対する解答、ガイダンス、および仮想化ホスト、仮想マシン、および Windows ネットワークのベンチマークの開発に使用できる詳細な記事へのリンクが含まれます。
また、Hyper-V のパフォーマンス カウンターに関する以下の投稿も読むことをお勧めします。
Hyper-V Performance Counters - Part one of many - The overview (英語) (https://go.microsoft.com/fwlink/?linkid=125651&clcid=0x411) (英語)
Hyper-V Performance Counters – Part two of many – "Hyper-V Hypervisor" counter set (英語) (https://go.microsoft.com/fwlink/?linkid=125652&clcid=0x411) (英語)
Hyper-V Performance Counters – Part three of many – "Hyper-V Hypervisor Logical Processors" counter set (英語) (https://go.microsoft.com/fwlink/?linkid=125653&clcid=0x411) (英語)
Hyper-V Performance Counters – Part four of many – "Hyper-V Hypervisor Virtual Processor" and "Hyper-V Hypervisor Root Virtual Processor" counter set (英語) (https://go.microsoft.com/fwlink/?linkid=125655&clcid=0x411) (英語)
アーキテクチャの作成と調整
完全なアーキテクチャは、仮想化ホスト、仮想マシン、および展開する SharePoint Server 環境を構成する物理マシンで構成されます。仮想化アーキテクチャの詳細については、「仮想アーキテクチャを計画する (SharePoint Server 2010)」を参照してください。
仮想アーキテクチャを開発して実装する手順は以下のとおりです。
仮想アーキテクチャと物理アーキテクチャを作成します。SharePoint Server 2010 ファームの目標をサポートするアーキテクチャを作成します。
アーキテクチャを分析します。足りない情報、または展開する予定の環境の設計を改善する情報を識別して取得します。
アーキテクチャを微調整します。手順 2. の情報を使用してアーキテクチャを調整します。
さまざまな展開ステージの過程で、アーキテクチャとサーバー構成の調整を続行します。展開ステージの詳細については、「技術ダイアグラム (SharePoint Server 2010)」の記事で説明されている SharePoint 2010 製品の展開と SharePoint 2010 製品の仮想化プロセス モデルを参照してください。
アーキテクチャを作成する
仮想マシンおよび仮想化ホストの構成を評価および調整するためのツールとして使用できるアーキテクチャのモデルを作成します。以下の条件をガイドとして使用して、モデルを開発します。
必要な仮想マシンの数および SharePoint Server ファームでのそれぞれの役割を識別します。
個別の仮想マシンの構成要件 (ディスク領域、メモリ、プロセッサの数) を指定します。これらは SharePoint Server の容量要件に基づきます。
仮想化ホストの要件 (ディスク領域、メモリ、論理プロセッサの数) を指定します。これらは仮想マシンの要件に基づきます。
仮想化ホストでの仮想マシンの分散を識別します。これらはファームの高可用性要件に基づき、仮想化ホストの数と容量によって制約されます。
ネットワークとストレージの一般的な要件を識別します。
仮想化ホストおよび仮想マシンの拡大に対応します (スケールアップまたはスケールアウト)。
アーキテクチャ モデルを作成した後、両方のアーキテクチャを分析して、設計および仮想化ホストと仮想マシンの構成を検証する必要があります。
アーキテクチャを分析する
アーキテクチャを分析する基本的な目的は、展開する SharePoint Server 2010 ソリューションを問題なくサポートできるかどうかを判定することです。ただし、設計とサーバーの構成は展開プロセスの過程で変化すると想定してもかまいません。
次の図は、フロントエンド Web サーバー、アプリケーション サーバー、およびデータベース サーバーで構成されるファームの仮想アーキテクチャのサンプルです。このアーキテクチャは、「小規模から中規模のファームの仮想アーキテクチャの例」で説明されている小規模から中規模のファームの典型であり、仮想ファームの容量と可用性の要件を分析するときに考慮する必要のある重要な要素を示すために使用できます。
重要
次の図での仮想化サーバーと仮想マシンのサイズは、規範的なものではありません。
図 1. 予備アーキテクチャ
.gif "仮想 SharePoint Server 2010 ファーム トポロジ")
仮想アーキテクチャの作成に対して提供されている条件を使用して、前の図で示されているサンプル アーキテクチャを分析します。図のアーキテクチャでは、すべての Web サーバーとアプリケーション サーバーは仮想マシンであるものと想定しています。ファーム データベース サーバーが物理マシンか仮想マシンかは決定されていません。
仮想化ホストの分析
次の表 (HOST-1 および HOST-2) では、各仮想化ホストの分析を示し、条件にとしてメモリ、プロセッサ、およびスケーラビリティを使用しています。ホストの分析の後で設計を分析します。
HOST-1
| 条件 | 分析 |
|---|---|
メモリ |
ホスト オペレーティング システムに 2 GB の RAM を割り当てて、予想される RAM の要件を使用すると、2 GB の RAM を将来的に使用できるものと推定されます。 |
プロセッサ |
論理プロセッサから仮想プロセッサへのマッピングは 8:10 (1:1.25) であり、CPU が若干オーバーサブスクライブされることを意味しますが、テスト環境では問題ありません。 重要 仮想化サーバーで CPU をオーバーサブスクライブすると、全体的なパフォーマンスが低下します。この影響の範囲は、仮想マシンにかかる負荷によって決定されます。避けられる場合は仮想化サーバーの CPU をオーバーサブスクライブしないことが、ベスト プラクティスです。 |
スケーラビリティ |
十分なメモリがないため、これはオプションではありません。さらに、CPU のオーバーサブスクリプションの程度が (仮想マシンに 2 つのプロセッサを追加しても)、パフォーマンスに大きく影響します。 |
HOST-2
| 条件 | 分析 |
|---|---|
メモリ |
ホスト オペレーティング システムに 2 GB の RAM を割り当てて、予想される RAM の要件を使用すると、6 GB の RAM を将来的に使用できるものと推定されます。 |
プロセッサ |
論理プロセッサから仮想プロセッサへのマッピングは 8:8 (1:1) であり、ベスト プラクティスのガイダンスを満たします。 |
スケーラビリティ |
仮想マシンに対するメモリの割り当てを増やすのに十分なメモリがあります。2 つのプロセッサと 4 GB の RAM の新しい仮想マシンを追加するのに十分な容量があります。これは、仮想化ホストの CPU が若干オーバーサブスクライブ (8:10) されることを意味しますが、HOST-1 と同様に、テスト環境では問題ありません。 |
設計の分析
サンプル アーキテクチャは、一般に、ファーム サーバーに対する高可用性の程度を示します。たとえば、3 つのフロントエンド Web サーバーが HOST-1 と HOST-2 に分散されていて、データベース サーバー (クラスター化またはミラー化) も異なる仮想化ホストまたは異なる物理サーバーに存在します。仮想化ホスト レベルでの高可用性はアーキテクチャには含まれず、関連する情報はありません。設計を修正するには、事前に以下の情報が必要です。
データベース サイズ
コンテンツ データベースのサイズにより、すべてのファーム サーバーを構成および分散させる方法が決まります。
ストレージ サブシステム
たとえば、サンプルのアーキテクチャでは、各仮想マシンに必要なディスクの数、およびディスクの分散と容量については示されていません。ストレージ システムを決定して構成するには、この情報が非常に重要です。アーキテクチャ サンプルではローカル ストレージが使用されています。これが環境に適しているかどうか、または SAN 上の LUN に対してパススルー ディスク構成を使用するかどうかを、決定する必要があります。
ネットワークの要件
ネットワーク アダプターの数および最小限のスループットを識別する必要があります。
仮想ハード ディスクの構成
使用する Hyper-V ハード ディスクの構成も決定する必要があります (たとえば、固定サイズ、パススルー)。詳細については、「ディスクと記憶域の計画」(https://go.microsoft.com/fwlink/?linkid=188007&clcid=0x411) および「Virtual Hard Disk Performance: Windows Server 2008 / Windows Server 2008 R2 / Windows 7 (英語)」(https://go.microsoft.com/fwlink/?linkid=186519&clcid=0x411) (英語) を参照してください。
設計の検討が済んだ後、次の手順はアーキテクチャの調整です。
アーキテクチャを調整する
アーキテクチャの調整の範囲は、初期アーキテクチャ、分析の結果、および実装計画に依存します。提供されているサンプルを使用すると、何も変更しないシナリオがあります。次に例を示します。
予備アーキテクチャが、早期テスト、概念実証、および限られたパイロット展開に適しています。
仮想化ホストはテスト専用であり、ユーザー受け入れテスト フェーズの間により高容量のホストに置き換えられます。
仮想ファームはテスト専用であり、テストが終了した後でシャットダウンされます。場合によっては、環境を残しておき、後日、ソフトウェア更新のテストに使用する可能性があります。
次の図は、運用ファームにより適している修正されたアーキテクチャを示しています。
図 2. 修正後のアーキテクチャ
.gif "仮想アーキテクチャの変更")
修正後のアーキテクチャでの主要な想定は、8 コアの製品仮想化サーバーを残すというものです。前の図での変更は、この想定を反映しており、以下の考慮事項を含んでいます。
コンテンツ データベースの推定サイズは 1 テラバイト (TB) です。
目標は、すべてのファーム サーバーに高可用性を提供し、インフラストラクチャ全体のパフォーマンスを最大にすることです。
ファームのデータベース サーバーは、高可用性をサポートするためにクラスター化またはミラー化できる物理サーバーです。各サーバーは 8 つのコアと 16 GB の RAM を備え、ローカル ドライブを使用して遅延を減らします。
仮想化ホストの分析
次の表 (HOST-1 修正および HOST-2 修正) では、メモリ、プロセッサ、およびスケーラビリティを条件として使用して各仮想化ホストを分析しています。
HOST-1 修正
| 条件 | 分析 |
|---|---|
メモリ |
ホスト オペレーティング システムに 2 GB の RAM を割り当てて、予想される RAM の要件を使用すると、2 GB の RAM を将来的に使用できるものと推定されます。 |
プロセッサ |
論理プロセッサから仮想プロセッサへのマッピングは 8:10 (1:1.25) であり、わずかにオーバーサブスクライブされています。 |
スケーラビリティ |
仮想マシンに対するメモリの割り当てを増やすのに最小限の量のメモリを使用できます。メモリの量およびプロセッサの比を基にすると、新しい仮想マシンを追加するのに十分なホスト容量はありません。 |
HOST-2 修正
| 条件 | 分析 |
|---|---|
メモリ |
ホスト オペレーティング システムに 2 GB の RAM を割り当てて、予想される RAM の要件を使用すると、4 GB の RAM を将来的に使用できるものと推定されます。 |
プロセッサ |
論理プロセッサから仮想プロセッサへのマッピングは 8:12 (1:1.50) であり、50 パーセントだけオーバーサブスクライブされています。 |
スケーラビリティ |
仮想マシンに対するメモリの割り当てを増やすのに最小限の量のメモリを使用できます。メモリの量およびプロセッサの比を基にすると、新しい仮想マシンを追加するのに十分なホスト容量はありません。 |
設計の分析
各仮想マシンは、3 ドライブ構成を使用し、SharePoint Server のベスト プラクティス ガイダンスに従ってサイズを決定されています。通常、これらのドライブは次のように構成されます。
ドライブ C (50 GB): Windows インストール用
Drive D (50 GB): SharePoint Server 2010 ファイル用
Drive E (300 GB): Web コンテンツおよびログ ファイル用
各フロントエンド Web サーバーには、4 つの仮想プロセッサ (4xVP) と 8 GB の RAM が構成されています。これは、運用環境に対する最小限の推奨構成です。
フロントエンド Web サーバーの数は、効果的なクラスタリングと高可用性をサポートするために、4 台に増やされています。この 4 サーバーの構成は、更新をインストールするときに常に 2 台のサーバーを使用できるので、ソフトウェア更新のインストールに特に適しています。
2 台のアプリケーション サーバー (App-1、App-2) は高可用性を提供します。App-1 は、サーバーの全体管理、Search クロール コンポーネント、および検索クエリ コンポーネントのパッシブ インデックスをホストします。プロセッサの数とメモリの量は、コンテンツ データベースの推定サイズに基づいています。
App-2 は検索クエリ サーバー専用です。また、サーバーの全体管理のコピーも含みます。プロセッサの数とメモリの量は、コンテンツ データベースの推定サイズに基づいています。
高可用性のため、サーバーの全体管理は別のホストのフロントエンド Web サーバーにもインストールされます。
データベース サーバーは、高可用性のためにクラスター化またはミラー化される物理サーバーです。この物理サーバーへの移動には、仮想ファーム サーバーの仮想化ホストの容量を増やし、データベース全体のパフォーマンスを高めるという利点があります。
注意
前に示したように、データベース サーバーを仮想化するか否かの決定は複雑な決定であり、広範な計画とテストが必要です。
ネットワークの観点から、両方の仮想化ホストには、2 つの異なる 1 ギガビット物理ネットワーク アダプターが構成されています。これは、仮想化ホストと仮想マシンのデータ トラフィックを分離して、パフォーマンスの向上とアダプターの冗長性を実現する、推奨される方法です。
各仮想化ホストは仮想 LAN (VLAN) を使用しており、これにはネットワークの分離、セキュリティの向上、パフォーマンスという利点があります。
修正後の仮想および物理アーキテクチャは大きく改善されており、運用環境に展開できます。ただし、構成では、使用可能な仮想化ホスト リソースがファームのスケーリングをサポートしていないことに注意することが重要です。さらに、必要になってもホスト間のファーム サーバーの移行をサポートできません。
現実的には、この例のファームを運用環境に展開する場合は、以下のアップグレードを検討することをお勧めします。
16 コアで 48 または 64 ギガバイトの RAM を備えたコンピューターを使用して、仮想化ホストの容量を増やします。
1 台以上の仮想化ホストを追加します。
最善のレベルの高可用性を実現するには、次のセクションで示す追加オプションを検討します。
アーキテクチャを改善するための他のオプション
前のセクションでは、モデルを修正するためのオプションを示しました。もちろん、よりよいパフォーマンスと高可用性を実現するためのオプションは他にもあります。仮想化ホスト環境のスケールアウト、または仮想化ホストのスケールアップは優れた代替手段ですが、常にコストが問題になります。組織の仮想化戦略が最善の方法の定義に役立ちます。
ヒント
コストに関しては、通常、短期的に必要なものより多くの容量を備えたサーバーを購入する方が、サーバーをアップグレードして容量を増やすより安上がりです。メモリのアップグレードの場合はこのことが特に当てはまります。一般に、メモリをアップグレードするには、既存のメモリ モジュールを廃棄し、新しいメモリのフル セットを購入する必要があります。
パフォーマンスの向上は以下のオプションで達成できます。
Second-Level Address Translation (SLAT) 対応のプロセッサを備えたサーバーを展開または購入します。Intel プロセッサではこの機能は Nested Page Tables と呼ばれ、Nehalem 55xx シリーズ プロセッサで利用できます。AMD の場合は、この機能は Enhanced Page Tables (EPT) と呼ばれます。
CPU コア保留を提供するサーバーを展開または購入します。これは、実行中の Hyper-V が最小限の数のプロセッサ コアを使用して作業負荷の要求を満たすことができるようにする機能です。
TCP Chimney オフロード、Virtual Machine Queues (VMQ)、および Jumbo Frame を調査します。これらの機能はネットワークのパフォーマンスを上げて CPU の使用率を下げることで、システム全体の容量を増やします。
大量のデータを転送するときのネットワーク パフォーマンスを上げるために、Jumbo frame support を調査します。ただし、Jumbo Frames が機能しない環境があるので、詳しくテストする必要があります。
アダプターのチーミングを調査します。この機能を使用すると、ネットワークのパフォーマンスが向上し、物理ネットワーク アダプターにフェールオーバー機能が提供される可能性があります。
重要
アダプターのチーミングはサードパーティのソリューションであり、ベンダーによってのみサポートされます。詳細については、「Microsoft Support Policy for NIC Teaming with Hyper-V (英語)」(https://go.microsoft.com/fwlink/?linkid=194749&clcid=0x411) (英語) を参照してください。
仮想環境の高可用性を保証するには、以下のように、Windows Server 2008 R2 フェールオーバー クラスタリングおよび Hyper-V ライブ移行の実装を検討します。
フェールオーバー クラスタリングの範囲には、仮想化ホストおよび各ホスト上の仮想マシンを含めることができます。仮想化ホストで予期しない障害が発生した場合、仮想マシンは別の仮想化ホストに自動的にフェールオーバーします。
ライブ移行は計画的なダウンタイムのためのソリューションです。実行中の仮想マシンを別のサーバーに (ダウンタイムなしで) 移行し、物理サーバーをシャットダウンして、メンテナンスを実行できます。サーバーでのメンテナンスが終了したら、ライブ移行を使用して、仮想マシンを元の物理サーバーに戻します。
詳細については、「Hyper-V: Using Hyper-V and Failover Clustering (英語)」(https://go.microsoft.com/fwlink/?linkid=187967&clcid=0x411) (英語) および「Hyper-V: Windows Server 2008 R2 でライブ移行とクラスターの共有ボリュームを使用する (英語)」(https://go.microsoft.com/fwlink/?linkid=188009&clcid=0x411) (英語) を参照してください。