【テクニカルレポート】Microsoft SharePoint 環境の仮想化 | RBB TODAY
※本サイトはアフィリエイト広告を利用しています

【テクニカルレポート】Microsoft SharePoint 環境の仮想化

エンタープライズ ソフトウェア・サービス
図1) 3階層の SharePoint環境
  • 図1) 3階層の SharePoint環境
  • 図2) SnapManager for Microsoft Office SharePoint Server(SMMOSS)
  • 図3) MicrosoftとNetAppの併用環境におけるディザスタリカバリ
 Microsoft SharePointはさまざまなサービスの統合スイートで、包括的なコンテンツ管理やエンタープライズ検索など、ビジネス上のより良いコラボレーションを実現する諸機能を提供します。最新バージョンのSharePoint 2010では、PowerPivot によるビジネス分析機能などの新機能が追加され、ソフトウェアの活用の幅がさらに広がっています。

 SharePointはMicrosoftの歴史上、最も成長の速い製品の一つです。最近の IDGの調査 (英語)によると、企業のCIOの62%が、自社のテクノロジポートフォリオで重要な位置を占めるコンポーネントとしてSharePointを捉えています。また半数以上のCIOが、SharePointに関する課題、特にストレージ関連の課題が、自社のビジネスに影響を及ぼしていると答えています。現在、ユーザ数が1,000を超える企業の半数では、SharePointデータの年間の増加率が41%以上になっています。急速な成長の結果、物理設置面積が大幅に拡大し、リソースの枯渇を招いているうえ、管理やデータ保護の負荷も高まっています。

 これらの問題の多くは、仮想化を正しく活用することで解決できます。この記事では、Microsoft Hyper-VとNetAppストレージを使用して、SharePoint環境(SharePoint 2007またはSharePoint 2010)を仮想化する方法について説明します。仮想化を利用すると、全体的な物理設置面積を大幅に縮小し、消費電力、冷却コスト、物理スペースを削減するとともに、管理の簡易化も実現されます。SharePoint環境を拡張する必要がある場合は、既存の仮想マシンにリソースを追加するか、新しい仮想マシンを追加するだけで済みます。また、仮想化は、データ保護、可用性、ディザスタリカバリ(災害復旧)のための、より豊富で優れた選択肢を提供します。

■SharePointのコンポーネント
 SharePointは多層アプリケーションで、ロールを利用して各階層を個別にスケーリングできます。このSharePointロールをサポートするため、ITチームでは任意の数の物理サーバを使用できます。これらのデバイスは、総称して「ファーム」と呼ばれます。特定のSharePointロールをそれぞれ独立した状態で実行し、同一の物理サーバを複数のロールで共有することもできます。ただし、Microsoftのベストプラクティスでは通常、各サーバでロールを1つだけ実行するよう推奨しています。そのため、多くのIT部門は各SharePointロールを個別の物理サーバ上で実行し、そのロールのスケーリングを実行する際に、パフォーマンスのボトルネックが生じる危険を防止しています。

 Web層は、Webフロントエンドサーバ(WFE)と呼ばれる、1つ以上のステートレスなWebサーバで構成されます。WFEサーバは受信要求を処理し、アプリケーション層の適切なサーバへとその要求を転送します。WFEでは負荷分散が可能で、スケーラビリティ要件に応じて、新たにサーバを追加できます。WFEを20台以上使用している例も聞かれますが、これが大きな要因となって、物理サーバを中心に構築されたSharePoint環境の物理的なスプロールが発生しています。

 アプリケーション層では、SharePointの管理Webサイト、エンドユーザWebサイト、共有サービスプロバイダが実行されます (SharePointのWebサイトと共有サービスプロバイダは、別の物理サーバ上で実行されるのが一般的)。管理サイトはSharePointの特別なサイトで、エンドユーザ向けに管理者がサイトのセットアップと構成を行う際に使用します。SharePoint 2010では、PowerPivot用として、アプリケーション層に新しいサーバロールが追加されています。

 データベース層は、アプリケーション層で必要となる、バックエンドのすべてのデータベースサービスを提供します。SharePoint Serverでは、構成、管理情報、サイトコンテンツ、検索データを格納するために、各種のSQL Serverデータベースを使用する必要があります。SharePointをインストールすると、構成データベースが作成されます。このデータベースには、グローバル構成データ(インストール時のWebサーバに関する情報とサーバ設定)などの情報が格納されます。また、SharePointでは、すべてのサイトコンテンツがSQL Serverデータベース内で管理されます。たとえば、SharePointドキュメントライブラリで管理されるドキュメントは、Windowsファイルシステムではなく、データベースに格納されます。その他のデータベースには、SharePoint検索サービスで使用する情報(インデックスなど)や、特定のSharePoint構成に固有の機能で使用する情報が格納されます。通常、SharePointのバックエンドにはSQL Serverを実行する単一のシステムが使用されますが、大規模な構成では、上記のようなデータベースを複数の物理サーバに分散することもできます。

各層でのサーバの急増は、物理環境でのスプロールの原因となっています。サーバとストレージの両方を仮想化し、統合することにより、SharePoint環境で必要となる物理サーバ数は大幅に減少します。また、管理全般の簡易化が可能となり、サーバの利用率も向上します。

■NetAppとHyper-Vを利用した導入の計画
 Hyper-Vは、物理環境を仮想化するための最もシンプルな方法だといえます。Hyper-Vを使用すると、Microsoft System Center Virtual Machine Managerなどのツールを通じて、各物理サーバを簡単に仮想マシンとして利用できるようになります。計画の際には、単一の物理サーバの障害がSharePointに及ぼす影響を最小限に抑えられるよう、注意を払う必要があります。言い換えれば、SharePointで使用されるすべての仮想マシンは、単一の物理サーバ上に配置可能ですが、そうした構成は推奨できません。SharePointの各機能は、耐障害性とパフォーマンスの観点から、利用可能な複数のサーバに分散させます。Hyper-Vを利用したSharePointの仮想化に関する詳しいガイドラインについては、Microsoftが提供するこちらのTechNetの記事(英語)をご覧ください。また、NetAppでも、最近リリースしたベスト・プラクティス・ガイド(英語)の中で、SharePoint環境に関する詳細なガイダンスを提供しています。このガイドは物理的な導入について書かれたものですが、ベストプラクティスは仮想環境にも適用できます。

NetAppでは、次のような点に考慮することが重要だと考えています。

・環境のサイジング
・重複データの排除
・データのレイアウト

 サイジング
使用環境のストレージ容量とパフォーマンスについてサイジングする際、明らかに避けなくてはならないことは、オーバーサイジングとアンダーサイジングです。NetAppでは、環境のサイジングについて2つのアプローチを使用します。1つ目は、総ユーザ数と、ユーザ1人に提供しなければならないストレージ容量に基づいたアプローチです。2つ目のアプローチでは、保有するドキュメント数やそのドキュメントの平均サイズ、バージョン数を割り出し、将来のいくつかの時点に関して、それらの値を見積もる必要があります。現在の情報を提供でき、成長率について何らかの予測が可能であれば、明らかにこちらのアプローチの方が正確な予測値を割り出すことができます。
 
 重複データの排除
SharePoint環境には例外なく、各サーバ上にインストールされたオペレーティング・システム・ファイルやアプリケーション・バイナリなど、大量の重複データが存在します。NetAppを利用したSharePointの仮想化がもたらす独自の利点に、プライマリストレージの重複データを排除し、そのスペースを再利用できることが挙げられます。NetApp FlexCloneを使用すると、適切なソフトウェアで仮想マシンのテンプレートを作成したあと、各テンプレートのクローンを必要なだけ作成して、同じ種類の仮想マシンを準備することができます。テンプレート全体を複製する必要がないため、この処理はきわめて高速でスペース効率にも優れています。ディスク上には、さまざまなクローン間の変更点のみが格納されます。

標準的なプロビジョニング方法を通じて導入済みの仮想マシンについては、複数の仮想マシンで同じLUNまたはボリュームを共有している場合、NetAppの重複排除機能を使用して、重複データが格納されているストレージの多くを解放できます。

 レイアウト
考慮すべき点の最後は、データ保護とディザスタリカバリに最適なデータのレイアウト方法についてです。アプリケーション層とデータベース層に含まれるすべてのSharePointデータは、仮想マシンのオペレーティング・システムやアプリケーションとは異なるLUNに格納することを推奨します (これは、VMwareによるMicrosoftアプリケーションの仮想化について書かれた、Tech OnTapの最近の掲載記事で紹介しているレイアウトに似ています)。この方法により、NetApp SnapManagerの各種ツールを最大限に活用して、SharePointデータを保護できるようになります。

Hyper-V上で実行されているSharePoint環境の場合、使用するSnapManagerツールは3種類あります。

・SnapManager for Hyper-V:各Hyper-Vサーバ上にインストールされます。Hyper-V仮想マシンの、整合性のあるバックアップと複製を実行します。

・SnapManager for Microsoft Office SharePoint Server:SharePointと関連付けられた各仮想マシン上にエージェントがインストールされ、整合性のあるバックアップと複製が実行されるよう調整します。

・SnapManager for SQL Server:各SQL Server仮想マシン上にインストールされ、SQL Serverの整合性のあるバックアップと複製を実行します (SnapManager for SQL ServerはSnapManager for SharePointの一部であり、前者は後者によって制御されます)。

 SharePointのデータ保護とDR
SharePointは一般に、プロジェクト管理とコラボレーションのために利用され、顧客サービスや研究開発のほか、部門レベルでの処理の自動化に活用されるケースが増えてきています。SharePoint環境がシステムダウンすれば、製品開発の遅延や、お客様をお待たせする結果につながりかねません。ESGによると、SharePointの導入を検討するユーザの約3分の1は、組織全体にわたってSharePointを展開しようと考えています。つまり、Exchangeと同様に、システムが万一ダウンすると、ほぼ全員に影響が及ぶわけです*。こうした理由により、SharePointのデータ保護とディザスタリカバリがますます重要になっています。

前のセクションで挙げた各種のSnapManagerツールを使用すれば、仮想化されたSharePoint環境に、バックアップと複製の両方の機能が提供されます。SnapManager for Hyper-Vには、仮想マシン自体を保護する機能があります。SnapManagerでは、NetApp Snapshotテクノロジを使用して定期的に仮想マシンのバックアップを作成することにより、システムダウンを最小限に抑え、ほぼ瞬時にリカバリを実行できます。SnapManager for Hyper-Vを使用して仮想マシンをセカンダリサイトへと複製しておけば、プライマリサイトで災害が発生しても、セカンダリサイトですぐに仮想マシンの運用を再開できます。

SnapManager for Microsoft Office SharePoint Server(SMMOSS)は、SharePoint環境全体のバックアップと複製を調整する機能を備えています。

 SMMOSS Managerは、SharePoint環境内にインストールされたControl AgentとMember Agentが提供するサービスを利用して、バックアップとリストアを集中管理する役割を果たします。集中管理用のGUI(グラフィカル・ユーザ・インターフェイス)も用意されており、SharePoint Webアプリケーションのバックアップタスクとリストアタスクを実行できます。

SMMOSS Media Serverは、SharePoint Webアプリケーションのバックアップセットに関連する、さまざまな情報を生成して保存します。こうした情報には、バックアップセットのインデックスやバックアップセットのメタデータが含まれます。

SMMOSS Control Agentは、SharePointの各Web上でサービスとして実行され、そのWFE上で実行されているSharePoint Webアプリケーションを検出する役割を果たします。さらに、それぞれのWFEサーバ上で、Webアプリケーションのバックアップタスクとリストアタスクを実行する機能も提供します。この処理はMember Agentと連動して実行されます。

SMMOSS Member Agentは各SQL Serverにインストールされ、SnapManager for SQL Server(SMSQL)ベースのコマンドを通じて、実際のバックアップタスクやリストアタスクを実行します。SMSQLが必要な理由は、SMSQLが、SQL Serverデータベースをバックアップまたはリストアできる唯一のツールだからです。SharePoint Webアプリケーションは、特別なSQL Serverデータベース(コンテンツデータベース)を使用して、使用するすべてのコンテンツを保存します。

SharePoint Index Server上のSMMOSS Member Agentは、SharePointの検索データベースファイルとインデックスファイルのバックアップまたはリストアを実行します (インデックスファイルは、NetApp LUNに格納されている場合にのみバックアップ可能)。

NetApp Snapshotテクノロジを利用するため、SnapManagerのバックアップはわずか数秒で実行されます。これは、システムダウンを発生させることなく、頻繁にバックアップを実行できるということです。作成後のSharePointバックアップは、セカンダリサイトへと簡単に複製できます。SnapManagerを使用すると、複製スケジュールを簡単に設定できます。

仮想マシンとSharePointデータの両方をセカンダリサイトへと複製すれば、災害発生時にSharePoint環境をリカバリするために、必要なすべての情報を確保できます (このプロセスは、手動やスクリプト経由でも実行可能)。

 このアプローチは、物理環境でのディザスタリカバリと比較して、仮想化された環境に次のような大きな利点をもたらします。

・複雑なサーバベースのディザスタ・リカバリ・ソフトウェアが必要なくなります。

・物理サーバでは、基本的に同一のサーバを使用し、前もってDR環境を構築しておくか、システムをダウンさせて、ベアメタル上に一から環境を再構築する必要があります。仮想マシンを使用すると(仮想マシンのデータが複製されていることが前提)、Hyper-Vが有効なサーバ上で、必要なSharePoint仮想マシンの運用を数分で再開できます。災害発生時にSharePointのパフォーマンスが低下してもかまわない場合は、セカンダリ環境のHyper-Vサーバの設置数を減らすこともできます (サーバを増設し、大規模な災害が発生した場合に、必要に応じて実行中の仮想マシンをライブ移行することも可能)。

・NetAppソリューションでは、全体的なストレージ所要量を削減できます。NetApp FlexCloneと重複排除テクノロジを使用すれば、プライマリとセカンダリの両方のストレージ環境で重複データを排除できます。多くのサイトでは、こうして削減されたコストによって、セカンダリ環境のコストがまかなわれています。

■まとめ
 SharePoint環境を仮想化すると、関連するコストの多くを削減できます。サーバを削減し、物理設置面積を縮小し、利用率を向上させることにより、電力、冷却、物理スペース、保守に関するコストを節約できます。また、管理が容易になるうえ、数日かかっていた新しいサーバのプロビジョニング時間が、数時間、さらには数分にまで短縮されます。

 仮想化されたSharePoint環境にNetAppストレージを追加すると、こうしたメリットが急速に拡大します。NetAppストレージでは、FlexCloneと重複排除テクノロジを使用することで、仮想環境につきものの重複データを排除できるうえ、優れたデータ保護機能とディザスタリカバリ機能を備えているため、重要なSharePointリソースの保護を強化できます。

■執筆者(敬省略)

John Parker
リファレンス・アーキテクト
NetApp

Johnは、NetAppストレージと併用されるMicrosoft SQL ServerとSharePointに関して、ストレージの運用方法やベストプラクティスを定義する業務を担当しています。彼はナレッジマネジメントがいかに組織のパフォーマンス向上に役立つかについて、長年研究を重ねています。Johnが専門とする分野は、ITシステムアーキテクチャとデータベース・サーバ・アーキテクチャです。

※同記事はネットアップ(NetApp)の発行する「Tech OnTap」の転載記事である。


《RBB TODAY》
【注目の記事】[PR]

関連ニュース

特集

page top