物理ストレージに関する推奨事項 (Office SharePoint Server)
ディスクとアレイの選択および選択したディスクとアレイへのデータの配置方法は、システムのパフォーマンスに大きく影響する可能性があります。RAID (Redundant Array of Independent Disks) の知識を深めるには、以下のリソースを参照してください。
Microsoft SQL Server 2008 で使用される RAID の種類については、「RAID レベルと SQL Server」(https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x411) を参照してください。
SQL Server 2008 で使用される RAID レベルの比較については、「さまざまな RAID レベルの実装の比較」(https://go.microsoft.com/fwlink/?linkid=105582&clcid=0x411) を参照してください。
Microsoft SQL Server 2005 と Microsoft SQL Server 2000 もサポートされますが、このトピックでは基本的に SQL Server 2008 について説明します。
適切なディスクと RAID アレイを使用する
最も適した RAID レベルおよびハード ディスクを選択するためのベスト プラクティスと推奨事項を以下に示します。
ディスクまたはアレイが高速でその数が多いほど、パフォーマンスが向上します。重要なことは、待機時間を短くすることと、すべてのディスクのキュー処理を維持することです。
ランダムな読み取り/書き込みで高い可用性とパフォーマンスを得るには、RAID 10 アレイを構成します。
RAID アレイを構成する前に、ストレージ ハードウェアのベンダに問い合わせるか、ドキュメントを参照してください。ランダムな読み取り応答時間が早くなることでデータベースにメリットがあるかどうかを考慮します。たとえば、静的な Web コンテンツの場合は、RAID 5 と RAID 10 で、同様のパフォーマンスが得られます。ランダムな書き込み応答時間の高速化の方が重要な場合があります。たとえば、読み取りと書き込みが混在する共同作業サイトでは、RAID 10 にメリットがあります。
RAID アレイを構成するときは、ベンダに指示されたオフセットに合わせてファイル システムを調整することがきわめて重要です。ベンダの指示がない場合は、「Predeployment I/O Best Practices (英語)」(https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x411) を参照してください。
RAID および SQL Server I/O サブシステムの準備方法については、「SQL Server Best Practices Article (英語)」(https://go.microsoft.com/fwlink/?linkid=168612&clcid=0x411) を参照してください。
新しいファームを展開する前に、SQLIO ディスク サブシステム ベンチマーク ツールを使用して、I/O サブシステムのベンチマークを測定することが推奨されます。詳細については、「SQLIO Disk Subsystem Benchmark Tool (英語)」(https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x411) を参照してください。
データ ファイルとログ ファイルの拡張を積極的に管理する
データ ファイルとログ ファイルには、事前にサイズを割り当てます。
自動拡張に頼るのではなく、データ ファイルとログ ファイルの拡張は手動で管理します。自動拡張は安全上の理由で有効にできますが、データとログ ファイルの拡張はユーザーが積極的に管理する必要があります。
展開のニーズを満たすように自動拡張設定を構成します。
推奨サイズ (100 GB) を超えるコンテンツ データベースを計画する場合、データベースの自動拡張値をパーセンテージではなく MB 単位の固定値に設定します。これは、SQL Server によるファイル サイズの拡張回数を減らすためです。ファイル サイズの拡張は、新たな領域を空のページで埋めるブロッキング操作です。
注意
Windows Server 2003 で実行される SQL Server 2008 では、ファイルの瞬時初期化がサポートされます。ファイルの瞬時初期化によって、ファイル拡張操作のパフォーマンスへの影響を大幅に削減できます。詳細については、「データベース ファイルの初期化」(https://go.microsoft.com/fwlink/?linkid=132063&clcid=0x411) を参照してください。
推奨サイズ (100 GB) よりも小さいコンテンツ データベースを計画する場合、データベースを作成するときに、ALTER DATABASE MAXSIZE プロパティを使用してデータベースを 100 GB に設定します。
ディスクの空き領域が制限されている場合、つまりデータベースのサイズを拡張できない場合は、自動拡張値を固定パーセンテージに構成する必要があります。たとえば、500 GB 未満のデータベースでは自動拡張値に 10% を、500 GB を超えるデータベースでは自動拡張値に MB 単位の固定数を構成します。
全ディスクで 25% 以上のレベルの空き領域を維持して、拡張と、ピーク使用時のパターンに対応できるようにします。RAID アレイにディスクを追加したり、記憶域の割り当てを増やしたりすることで成長を管理する場合、ディスク サイズを綿密に監視して、領域が不足することを防ぎます。
コンテンツ データベースのサイズを制限して、管理性を向上する
環境の管理性とパフォーマンスを向上するようにデータベースのサイズを計画します。
注意
ここで推奨する制限は、SQL Server 2008 を実行し、Microsoft Office SharePoint Server 2007 をホストするサーバーだけに当てはまるものであり、SQL Server 2008 に対する全般的なガイダンスではありません。
ほとんどの場合、Office SharePoint Server 2007 のパフォーマンスを向上するには、100 GB 以下のコンテンツ データベースを使用することが推奨されます。設計で、100 GB を超えるデータベースが必要な場合は、次のガイダンスに従ってください。
単一のサイト コレクション以外で、100 GB を超えるデータベースを使用しないでください。
組み込みのバックアップと復元ツールの代わりに、SQL Server 2008 や Microsoft System Center Data Protection Manager 2007 などの差分バックアップ ソリューションを使用します。
100 GB のコンテンツ データベースに依存するソリューションに移行する前に、SQL Server 2008 を実行するサーバーと I/O サブシステムをテストします。
複数のサイト コレクションを含むコンテンツ データベースを約 100 GB に制限します。
ディスクを分類し、優先順位を付ける
tempdb データベース、コンテンツ データベース、および SQL Server 2008 トランザクション ログを、別々の物理ハードディスクに配置することが理想です。
データに優先順位を付けるためのベスト プラクティスと推奨事項を以下に示します。
高速なディスク間のデータに優先順位を付けるには、以下の順序を使用します。
Tempdb データ ファイルとトランザクション ログ
データベース トランザクション ログ ファイル
検索データベース
データベース データ ファイル
読み取りが非常に多いポータル サイトでは、ログよりもデータを優先するようにします。
テストと顧客から得たデータによると、tempdb の不十分なディスク I/O によって、Office SharePoint Server 2007 ファームのパフォーマンスが大幅に低下する場合があることが示されています。この問題を回避するには、tempdb に専用ディスクを割り当てます。高い作業負荷が予想されるか、既に観測されている (読み取り処理と書き込み処理の実行に、平均して 20 ミリ秒 (ms) 以上かかっている) 場合は、ファイルをディスクに分けて配置するか、ディスクをより高速なディスクに交換することによって、このボトルネックを軽減する必要がある場合があります。
ベスト プラクティスとして、tempdb を RAID 10 アレイに配置します。tempdb データ ファイルの数はコア CPU と同数にし、すべての tempdb データ ファイルのサイズを同じにします。この場合、デュアルコア プロセッサは 2 CPU とカウントします。ハイパースレッディングをサポートする各プロセッサは 1 CPU とカウントします。詳細については、「tempdb のパフォーマンスの最適化」(https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x411) を参照してください。
データベース データとトランザクション ログ ファイルは、異なるディスクに配置します。ディスク全体またはストライプを保証するのにファイルが小さすぎる、またはディスク容量が足りないという理由でディスクを共有する必要がある場合は、アクセス要求の同時発生を最小限に抑えるために、使用パターンが異なるファイルを同一ディスクに配置します。
ストレージ ハードウェアのベンダに問い合わせて、特定のストレージ ソリューションですべてのログと検索データベースへの書き込みを最適化するように構成するための情報を入手します。
検索データベース専用のスピンドルを割り当てます。
大きなコンテンツ データベースおよび SSP 検索データベースでは複数のデータ ファイルを使用する
大きなコンテンツ データベースおよび SSP 検索データベースの場合は、パフォーマンス向上のために、複数のデータ ファイルを使用することを検討してください。
注意
-
コンテンツ データベースおよび SSP 検索データベース以外のデータベースのために複数のデータ ファイルを使用することはサポートされていません。
-
SharePoint 製品とテクノロジのデータベースでは、SQL Server のパーティション分割を使用することはサポートされていません。単純なデータ ファイルのみを使用してください。
コンテンツ データベースの場合は複数のデータ ファイルを使用する
最適なパフォーマンスを得るには、以下の推奨事項に従ってください。
データベースのプライマリ ファイル グループ内にのみファイルを作成します。
別々のディスクにファイルを分散します。
データ ファイルの数は、コア CPU と同数またはそれより少ない数にします。この場合、デュアルコア プロセッサは 2 CPU とカウントします。ハイパースレッディングをサポートする各プロセッサは 1 CPU とカウントします。
同じサイズのデータ ファイルを作成します。
重要
SharePoint 製品とテクノロジに組み込まれているバックアップと復元のツールでは、同じ場所で上書きする場合に複数のデータ ファイルのバックアップと復元を行えますが、複数のデータ ファイルを別の場所に復元することはできません。このため、1 つのコンテンツ データベースで複数のデータ ファイルを使用する場合は SQL Server のバックアップと復元のツールを使用することを強くお勧めします。Office SharePoint Server 2007 のバックアップと復元の詳細については、「バックアップと復元ツールを選択する (Office SharePoint Server)」を参照してください。
ファイル グループの作成および管理の詳細については、「ファイルとファイル グループのアーキテクチャ」(https://go.microsoft.com/fwlink/?linkid=117909&clcid=0x411) を参照してください。
SSP 検索データベースでは複数のデータ ファイルを使用する
検索データベースの場合、ファイル グループを使用して、クロールとクエリ処理で主に使用するテーブルを分離することが推奨されます。I/O サブシステムへの影響を最小限に抑えるには、クロールで最も影響を受けるテーブルをホストするファイル グループを、プライマリ グループとは別のスピンドル セットに移動する必要があります。
次の表に含まれるデータベース テーブルは、基本的にクロールに関連します。
MSSAnchorChangeLog |
MSSCrawlDeletedErrorList |
MSSAnchorPendingChangeLog |
MSSCrawlDeletedURL |
MSSAnchorText |
MSSCrawlErrorList |
MSSAnchorTransactions |
MSSCrawlHostList |
MSSCrawlChangedSourceDocs |
MSSCrawlQueue |
MSSCrawlChangedTargetDocs |
MSSCrawlURL |
MSSCrawlContent |
MSSCrawlURLLog |
MSSTranTempTable0 |
重要
これらのテーブルをファイル グループに移動するには、Transact-SQL スクリプトを使用できます。このスクリプトは、クロールに関連するテーブルの移動のみに対応するメカニズムです。このスクリプトは、Microsoft Enterprise Search ブログに投稿された「SQL File groups and Search (英語)」(https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x411) に含まれています。
検索データベースの最適なパフォーマンスを得るためには、次の推奨事項に従います。
データベースのプライマリ ファイル グループからテーブルを移動します。
別のディスクにファイルを分散します。
重要
新しいファイル グループにテーブルを移動するプロセスは、非常にコストが高く、完了するまでに数時間かかることがあります。これは、多くのクラスタ化インデックスの削除と再作成を伴うためです。移動の際にはデータベースをオフラインにすると仮定します。
既知の問題
ここでは、検索データベースでのファイル グループの使用に関する既知の問題について説明します。
バックアップと復元
SharePoint 製品とテクノロジのバックアップと復元はファイル グループに対応していません。新しいファイル グループの復元先を指定する方法はありません。復元プロセスでは、クロール ファイル グループは、バックアップ作成時にそのファイル グループが存在していたドライブに配置されます。復元するには、クロール ファイル グループとプライマリ ファイル グループのドライブに、当初のバックアップ ドライブと同じドライブ名のドライブを使用する必要があります。
将来の更新プログラム、Service Pack、および修正プログラム
サーバーに適用する各更新プログラム、Service Pack、および修正プログラムによって、クロール ファイル グループに移動したインデックスが変更されたり、ファイル グループに移動したいずれかのテーブルに新しいインデックスが追加されたりする可能性があります。このような場合、インデックスがプライマリ ファイル グループに戻されるか、プライマリ ファイル グループでインデックスが再作成されます。
インデックスが変更される可能性があるため、あらゆる更新プログラムを適用した後は、Enterprise Search ブログで提供されているスクリプトを実行して、テーブルをファイル グループに移動するプロセスを繰り返す必要があります。
SQL Server 2005 が最低限必要。SQL Server 2008 が推奨される
インデックスの移動に使用する製品チームのスクリプトでは、SQL Server 2005 でリリースされ、SQL Server 2008 で継続的にサポートされる機能が使用されます。この最適化は SQL Server 2005 以降を実行している場合にのみ実行できます。
ベンダが推奨する構成に従う
物理ストレージ アレイを構成するときに最適のパフォーマンスを得るには、オペレーティング システムの既定値に頼らずに、ストレージ ベンダが推奨するハードウェア構成に従います。
ベンダからの指示がない場合は、DiskPart.exe ディクス構成ユーティリティを使用して SQL Server 2008 用のストレージを構成することをお勧めします。詳細については、「Predeployment I/O Best Practices (英語)」(https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x411) を参照してください。
このブックをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。
- Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2 (https://go.microsoft.com/fwlink/?linkid=85548&clcid=0x411)
入手可能なドキュメントの詳細な一覧については、「Microsoft Office SharePoint Server 2007 ダウンロード可能ドキュメント」(https://go.microsoft.com/fwlink/?linkid=89172&clcid=0x411) を参照してください。