容量管理のベスト プラクティス
この記事では、Microsoft Office SharePoint Server 2007 のベスト プラクティスについて説明します。他のベスト プラクティスの記事については、「ベスト プラクティス」を参照してください。Office SharePoint Server 2007 のベスト プラクティスに関するその他の情報とリソースについては、「Best Practices Resource Center (英語)」(https://go.microsoft.com/fwlink/?linkid=125981&clcid=0x411) を参照してください。パフォーマンスと容量の計画の詳細については、「パフォーマンスと容量を計画する (Office SharePoint Server)」を参照してください。
ベスト プラクティス
計画プロセスのできる限り早い段階で容量計画の戦略を文書化しておき、プロジェクトの進行に合わせて修正を加えます。計画を早期に行うことで、展開の開始後にハードウェアのニーズが過小評価されていたことが判明するリスクを大幅に減らすことができます。
次のような情報を文書化します。
ユーザーの数、秒あたりの要求数 (RPS)、サイトの数、ドキュメントの数、および保存されるデータの量は、記録する必要のある重要な数値です。
検索用に、コンテンツ ソースの数とインデックス サイズを文書化します。
ユーザー認証のアクセス方法とその回数を文書化します。
時間の経過と共に変化する値はこの方法で割り出し、通常は年単位で計画する必要があります。
データやアプリケーションの移行については、広範囲にわたる要件や複雑な要件が生じることもあります。また、複雑な統合やカスタマイズ コードが必要になる場合もあります。カスタマイズするサイトの数と、カスタム コードおよびデータに関する場所と移行の要件を見積もります。
可用性の目標を高く設定すると、ファーム トポロジの複雑さと範囲に大きな影響を及ぼす可能性があります。詳細については、「冗長性を計画する (Office SharePoint Server)」を参照してください。
グローバルな展開を行う場合は、十分なパフォーマンスと運用を確保するために、特別な対策が必要になることがあります。詳細については、「複数のファームをグローバルに展開する」を参照してください。
仮想化を使用して Office SharePoint Server コンピュータをホストする場合は、仮想化がサイズ設定に及ぼす影響について調査してください。仮想化にはさまざまなメリットがありますが、メモリとプロセッサの使用率、共有ディスクのパフォーマンスと容量など、重要な要素に及ぼす影響について把握しておくことは重要です。詳細については、「Hyper-V のパフォーマンスおよび容量の要件」を参照してください。
これらの情報は、必要なファームの数とその最適なトポロジ (小規模、中規模、および大規模) を判断するうえで役立ちます。
プロジェクトのどの段階でも、計画の具体性が高まり、ハードウェアと構成についてより詳細な決定を下す必要が生じるたびに、容量計画を見直します。状況に合わせて計画を修正してください。
既知のガイドラインを利用すると、プロセスの早い段階で容量の概算計画を短時間で行うことができますが、この概算計画は、プロジェクトの後半で行う詳細なサイズ設定に代わるものではありません。こうした概算計画は、実際の展開に適用できるかどうかについて確認する必要があります。
既知のガイドラインには次のようなものがあります。
ユーザー 1,000 人あたりの RPS は 1 とする このガイドラインは、同時実行率が 10% の一般的なユーザーに対して適用できます。詳細については、「Windows SharePoint Services グループ作業環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)」を参照してください。
グループ作業 Web サーバー 1 台あたりの最大ユーザー数は 20,000 人とする このガイドラインは、前のガイドラインと、「Windows SharePoint Services グループ作業環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)」に記載されている Windows SharePoint Services 3.0 のグループ作業のベンチマークから導き出されたものです。
1 つのグループ作業ファームあたり 4 ～ 5 台の Web サーバーを展開する 一般に、グループ作業ファームの展開の効率が最も高まるのは、4 ～ 5 台の Web サーバーを使用したときです。詳細については、「Windows SharePoint Services グループ作業環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)」に記載されているグループ作業のベンチマークを参照してください。
コンテンツ 5 TB ごとに 1 つの SQL Server インスタンスを使用する これまでの例から、100 GB のコンテンツ データベースの展開数が 50 を超えた時点で、データベースのパフォーマンスが低下し始めることがわかっています。
高速で信頼性の高いバックアップを実現すると同時に、ピーク時にリストの競合の問題が発生するのを避けるため、コンテンツ データベースのサイズは 100 GB 未満に抑えます。次の点にも注意が必要です。
大きなリスト (アイテム数が 2,000 を超えるリスト) の使用については、慎重に計画する必要があります。大きなリストの計画方法の詳細については、「ホワイト ペーパー : Office SharePoint® Server 2007 で大きなリストを操作する」を参照してください。
バックアップの実行時間と信頼性は、Office SharePoint Server データベースで使用されている記憶域の構成に大きく左右されます。
サイトを運用環境に移す前や、プロセスの定義を作成する前に、現実的なサイズが設定されたデータ セットのバックアップから復元までに必要な時間と、そのプロセスの信頼性をラボで測定してください。環境によっては、信頼性の高いバックアップを、必要なときにすぐに実行できるように、コンテンツ データベースのサイズを 100 GB よりもかなり小さくする必要があります。
SharePoint の論理的な計画のドキュメントには、少なくとも次の情報のレコードを含める必要があります。
ファーム
Web アプリケーション
コンテンツ データベース
サイト コレクション
サイト
カスタム アプリケーション
管理パス
URL
認証と承認
これらの各項目について、次の点を考慮する必要があります。
どの項目にも、注意が必要な制限事項があります。制限とソフトウェア境界の詳細については、「ソフトウェア境界を計画する (Office SharePoint Server)」を参照してください。
これらすべての項目に関して、制限を超える可能性があるかどうか、制限超過の状態を管理者が検知するために設定するルールのトリガとなる項目はどれか、そしてその状態を解消するためにどのような操作を実行するかについて検討してから、展開を行います。
ソフトウェア境界の管理は、通常、反復的なプロセスです。大規模なインストールの場合、関係するすべての境界を考慮に入れるのは容易ではなく、ファームを 2 つに分割しなければならないこともあります。この段階の計画に、十分な時間と労力をかけられるようにします。
SharePoint グループまたは Active Directory グループを使用してユーザーを管理する場合、容量とパフォーマンスに影響が及ぶことがあります。SharePoint グループまたは Active Directory を使用する場合は、構成時にファームに与える影響について確認してください。
テスト済みの Office SharePoint Server のシナリオについて把握しておく必要があります。自分のアプリケーションを次のシナリオと照らし合わせ、詳細なサイズを決定する際に役立ててください。
**グループ作業 ** Plan for performance and capacity (Windows SharePoint Services)
**ポータル グループ作業 ** ポータル グループ作業環境のパフォーマンスと容量の要件を予測する
**発行 ** インターネット環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)
**検索 **検索環境のパフォーマンスと容量の要件を予測する
**Excel Services **Excel Services 環境のパフォーマンスと容量の要件を予測する
**InfoPath Forms Services ** InfoPath Forms Services 環境のパフォーマンスと容量の要件を予測する (Office SharePoint Server)
**ワークフロー アプリケーション ** Performance Characteristics of Windows Workflow Foundation (英語) (https://go.microsoft.com/fwlink/?linkid=135708&clcid=0x411)
**エンタープライズ コンテンツ管理 ** エンタープライズ コンテンツ ストレージを計画する
スケールアップ シナリオに対応できるように、またパフォーマンスを高めるために、できる限り 64 ビット バージョンのサーバーを使用します。64 ビットのハードウェアとソフトウェアの使用をお勧めする理由の詳細については、「64-Bit and the Admin Toolkit Download Trend (英語)」(https://go.microsoft.com/fwlink/?linkid=135709&clcid=0x411) を参照してください。Office SharePoint Server の将来のバージョンでは、64 ビットのハードウェアとオペレーティング システムだけがサポートされる見込みです。
適切なスケールアウト オプションおよびスケールアップ オプションをトリガするために使用する監視ルールを計画します。さらに、そのトリガによって開始されるプロセスも計画します。重要性の高いトリガの一部を次に示します。
コンテンツ データベースが制限に達した。
サイト コレクション内のサイトの数が推奨最大数に達した。
コンテンツ データベース内のサイト コレクションの数が推奨最大数に達した。
その他の制限については、「ソフトウェア境界を計画する (Office SharePoint Server)」と「SharePoint 用 SQL Server 記憶域の計画と監視 : パフォーマンスの推奨事項とベスト プラクティス (ホワイト ペーパー)」を参照してください。
一般的に、ハードウェアを単純にファームに追加するだけでなく、アプリケーションを最適化することで、より長期的なメリット (サーバーの処理速度向上や負荷の軽減など) が得られるようになります。展開されるカスタマイズとアプリケーションがパフォーマンスとリソース使用率の最低基準を満たすように、ガバナンスを策定してください。
カスタマイズのテストと最適化の詳細については、次の記事を参照してください。
カスタマイズしたプラットフォームを運用環境に移す前に、必ずストレス テストを行ってください。展開前に正確なユーザーの動作を予測およびシミュレートするのが難しい場合でも、ストレス テストを行うことで、次のようなメリットを得ることができます。
カスタマイズのパフォーマンス上の問題を特定し、解決できる。
カスタマイズの品質上の問題を、ファーム ユーザーに影響が及ぶ前に発見できる。
展開の直後に発生する問題を少なくすることで、すばやく適切に展開を進めることができ、結果的には展開の投資収益率を上げることができる。