卓越した運用のためのベスト プラクティス (SharePoint Server 2010)

  • [アーティクル]

 

適用先: Excel Services, SharePoint Server 2010

トピックの最終更新日: 2016-11-30

Microsoft SharePoint Server 2010 は、スタンドアロンであれ、他のシステムと協調した形であれ、幅広いアプリケーションとソリューションで使用されます。こうした柔軟性を実現するために、このプラットフォームは、可能性のあるアーキテクチャと構成を数多くサポートしています。システムの一部のパーツはよく知られていますが、これらのパーツにも変化が見られます。この記事では、フロント エンド Web サーバー構成、データベース構成、サービス、修正プログラムの適用など、検討の必要がある上位構成のベスト プラクティスに注目します。

この記事は、SharePoint Server 2010 のベスト プラクティスに関するシリーズ記事の 1 つです。この記事では、卓越した運用のためのベスト プラクティスについて説明します。このシリーズの他の記事については、「ベスト プラクティス (SharePoint Server 2010)」を参照してください。SharePoint Server 2010 のベスト プラクティスに関するその他の情報とリソースについては、「Best Practices Resource Center (英語)」(https://go.microsoft.com/fwlink/?linkid=221383&clcid=0x411) (英語) を参照してください。

1. 十分な量のメモリと高速ネットワーク アダプターを使用する

必要なパフォーマンスを環境から得るために、Web サーバーとアプリケーション サーバーで十分な量のメモリを使用するようにします。

ネットワーク速度も環境のパフォーマンスにとって重要です。次の操作によってネットワーク トラフィックの移動を迅速にします。

  • すべてのサーバー ロールでギガビット ネットワーク アダプターを使用します。

  • フロントエンド Web サーバーとアプリケーション サーバーについては、運用環境でデュアル ネットワーク アダプターを使用します。1 つはユーザー用のネットワーク アダプター、もう 1 つは Microsoft SQL Server の通信用です。

  • 管理やバックアップといった作業のサーバー間通信では、プライベート ネットワーク アダプターを使用します。その場合、こうしたトラフィックがファーム全体のパフォーマンスに影響を及ぼすことはありません。

  • 負荷が大きい場合は、仮想ローカル エリア ネットワーク (VLAN) を使用してネットワーク トラフィックを削減することを検討します。

詳細については、「ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)」および「パフォーマンスと容量の管理 (SharePoint Server 2010)」を参照してください。

2. 距離を短くする: フロント エンド Web サーバー、アプリケーション サーバー、およびデータベース サーバーの間のネットワーク距離が長くなり過ぎないようにする

どのようなフロント エンド Web サーバーやアプリケーション サーバーも、データベース サーバーとの間の遅延が 1 ミリ秒 (ms) を超えてはなりません。実際のところは、通常、ファーム内のすべてのサーバーを同じデータ センター内に置くことになります。また、ファーム内のすべてのサーバーは同じタイム ゾーンに属している必要があります。

詳細については、「SharePoint 2010 製品のグローバル ソリューション (モデル)」を参照してください。

3. Web サーバーとアプリケーション サーバーの構成時にパフォーマンスと可用性を考慮する

Web サーバーとアプリケーション サーバーの構成方法は、スループットと可用性に大きな影響を与える可能性があります。最適な結果を得るには、次の推奨事項に従います。

  • システム コンポーネントを別々の論理ドライブに分散させて、冗長性を得るために RAID を使用します。

    ドライブ上のコンポーネント 推奨 RAID レベル

    Windows およびプログラム ファイルのドライブ

    RAID 1

    オペレーティング システムのスワップ ドライブと一時ディレクトリ

    RAID 1

    ログ ファイル

    RAID 1

    イメージング用のブート ディスクと Windows デスクトップ サーチ (オプション)

    RAID 1

  • 少なくとも 4 つの物理ディスクを使用し、ログ ファイルとスワップ ドライブを Windows およびプログラム ファイル用のドライブと分けるために個別のディスクを使用します。

  • ほとんどの運用環境では、少なくとも 200 GB のディスク領域をオペレーティング システムおよび一時ファイル用に、150 GB のディスク領域をログ用に割り当てることをお勧めします。

  • Web サーバーの容量を確認し、ファーム内のユーザーおよび要求の数に見合った十分な数のサーバーを用意します。可用性を高めるには、ネットワーク負荷分散サーバー ファームからサーバー 1 台をリサイクルのために引き上げてもサービスの可用性に影響しないように、サーバーを 1 台余分に割り当てます。

詳細については、以下を参照してください。

4. データベース サーバーの構成時にパフォーマンスと可用性を考慮する

Web サーバーやアプリケーション サーバーの場合と同様に、データベース サーバーの構成も SharePoint Server 2010 のパフォーマンスを左右します。データベースによっては、他のデータベースとの併置や分離が必要になります。詳細については、「SharePoint Server 2010 での容量管理と規模設定の概要」の記事の「データ規模」および「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

次の表に挙げたデータベースは、他のデータベースから分離しておく必要があります。

データベース名 サイズ 読み取り/書き込みの最適化 併置

TempDB

中

他のすべてのデータベースとは別のスピンドルに配置する必要があります。

Secure Store

小

別のデータベース インスタンス上にホストされます。アクセスを 1 人の管理者に制限します。

検索クロール

特大

読み取り用に最適化

大規模データベースです。検索プロパティ データベースとは別のサーバー上にホストされます。

検索プロパティ

大から特大

書き込み用に最適化

大規模データベースです。独自のサーバー上にホストされます。

利用状況

特大

書き込み用に最適化

別のスピンドルに配置する必要があります。

注意

利用状況データベースは別のサーバーに配置でき、他のデータベースほど高いパフォーマンスを必要としません。利用状況データベースの速度は、サイトのパフォーマンスに影響しません。

次の表にあるデータベースは、他のデータベースと同じ場所に配置する必要があります。

データベース名 サイズ 併置

構成

サーバーの全体管理コンテンツ

小

一緒に配置する必要あり

SQL Server ReportServer

ReportServerTempDB

小

さまざま

同じデータベース サーバー上に配置する必要あり

データベースのサイズ決定と特定のデータベースで読み取り/書き込み併用の可否の詳細については、「Databases That Support SharePoint 2010 Products model (英語)」(https://go.microsoft.com/fwlink/?linkid=187970&clcid=0x411) (英語) を参照してください。

5. クリーンな状態を維持する: データベースを正常な状態に保つ

正常なデータベース サーバーには、データベースおよびログ ファイルのための十分なヘッドルームに加え、要求に対処できる十分な容量があります。データベース サーバーのパフォーマンスを最適な状態に維持するには、次の一覧に挙げた推奨事項に従ってください。

  • 可能であれば、すべてのデータベースとログのサイズを事前に大きくしておきます。これらのサイズを監視して、ディスク領域を使い果たすことのないようにします。

  • 使用するデータベースやデータが多すぎてデータベース サーバーが過負荷にならないようにします。次のガイドラインに従ってください。

    • SQL Server ミラーリングの使用時には、SQL Server の 1 つの物理インスタンスに 50 を超えるデータベースを保存しないでください。

    • コンテンツ データベースの容量は 200 GB までに制限します。

  • インデックスの最適化と再構築を毎日行います (再構築に必要なダウンタイムに対処できる場合)。

  • データベース サーバーを監視して、応答が適切で過負荷になっていないことを確認します。以下に、監視すべき重要なパフォーマンス カウンターを示します。

    • ネットワーク待機キュー: 0 または 1 の場合、パフォーマンスは良好

    • ディスク キューの平均の長さ (待機時間): 5 ミリ秒未満

    • 使用済みメモリ: 70% 未満

    • 空きディスク領域: 25% を超える

    • バッファー キャッシュ ヒット率: 90% 以上

詳細については、以下を参照してください。

6. 最新の更新プログラムを使用してサーバーを最新の状態に保つ

最新の修正プログラム、更新プログラム、およびサービス パックの適用によって最新の状態を維持することが重要です。これらの更新プログラムには、製品の重要な拡張機能や改良が含まれています。ただし、これらの更新プログラムは、運用環境に適用する前に、運用前環境で十分にテストするようにします。以下のような、更新プログラムを展開する推奨手順に従ってください。

  • Windows Update を有効にして更新プログラムを自動的にダウンロードします。ただし、自動インストールは行わないでください。

  • 更新プログラムのインストールをピーク外の時間帯にスケジュールします。

  • 可用性を高めるには、更新処理時にサーバーを一度に 1 台ずつ順番に停止させます。

BIOS (サーバー コンピューター、コントローラー、およびディスク)、Windows オペレーティング システム、Microsoft SharePoint Foundation 2010 および SharePoint Server 2010、SQL Server に修正プログラムが適用されていることを確認します。

詳細については、「SharePoint 2010 製品の更新プログラム」(https://go.microsoft.com/fwlink/?linkid=209614&clcid=0x411) を参照してください。

7. 各種の操作ごとに異なるアカウントを使用する

Web アプリケーションおよびサービスでは、適切なアカウントを使用します。すべてのアカウントはドメイン アカウントである必要があります (注意: ネットワーク サービス アカウントは使用しないこと)。ベスト プラクティスとして、次のように個別のアカウントを使用してください。

  • Web アプリケーション: セキュリティ要件に基づいて各種のアカウントを使用します。

  • Search アカウント: ファームのアカウントの 1 つを使用します。

  • Excel Services アカウント: 外部接続用アカウントの 1 つを使用します。

詳細については、「アカウントの権限とセキュリティ設定 (SharePoint Server 2010)」を参照してください。

SharePoint Server 2010 で使用されるアカウントは、SQL Server サービス アカウント、サーバーの全体管理アプリケーション プール ID、SharePoint Foundation Timer Service アカウント、既定のコンテンツ アクセス アカウント、シングル サインオン アカウント、プロファイル インポート アカウントなど、他にも数多くあります。それぞれのパスワードを最新の状態に保ち、サービスの稼働状態を維持するために、推奨手順に従ってください。

詳細については、「管理アカウントに使用するパスワードを変更する (SharePoint Server 2010)」を参照してください。

8. データのバックアップと復元に関する推奨事項に従う

通常、バックアップにはネットワーク ドライブではなくローカル ディスクを使用し、バックアップしたデータを後でコピーするのが最善です。可能であれば圧縮を使用しますが、バックアップに圧縮を使用する際には SQL Server に過剰な負荷がかからないように注意してください。たとえば、SQL Server 用の LiteSpeed はバックアップ中に圧縮を行うため、SQL Server のパフォーマンスを悪化させる可能性があります。

大規模なデータベースの場合は、System Center Data Protection Manager (DPM) 2010 で利用できるような増分バックアップを利用します。完全バックアップは基本的なメカニズムとしては利用しないでください。完全バックアップはサイズが大きくなり過ぎて復元に時間がかかります。

詳細については、「バックアップと復旧のベスト プラクティス (SharePoint Server 2010)」を参照してください。

9. 必ずログ ファイルのバックアップと切り捨てを行う

データだけでなく、ログ ファイルもバックアップしてください。環境を完全に回復するためには、利用状況ログ、IIS ログ、トランザクション ログ、および SMTP 電子メール ログはすべてバックアップが必要です。トランザクション ログについては、5 分ごとにバックアップと切り捨てを行う必要があります。ただし、トランザクション ログは決して縮小しないでください。ログの再拡張時にパフォーマンス上の問題が発生する可能性があるからです。

詳細については、「ログをバックアップまたはアーカイブする (SharePoint Server 2010)」および「SQL Server データベースのトランザクション ログが突然拡張されないようにする方法」(https://go.microsoft.com/fwlink/?linkid=111458&clcid=0x411) を参照してください。

10. データを復元する: サービスの継続性を確保するためにバックアップをテストしてスタンバイ環境を用意する

定期的にバックアップのテストを行い、整合性を検証します。必要になったときにバックアップが利用できるとは限りません。利用できることを確認しておいてください。実際に回復を行い、環境全体を元に戻すために他に必要な作業がないか把握します。地理的に分散している環境では、リモート ファームをセットアップして障害復旧に備えます。その場合は、データベース接続コマンドによってデータベースのコピーをリモート ファームにアップロードして環境を復元し、ユーザーをリダイレクトできます。同様に、データベースの復元とドキュメントの回復を迅速に行えるように、運用環境と同じバージョンのソフトウェアを実行しているスタンバイ環境をセットアップすることもできます。復元にかかる時間を短縮するために、データベースのサイズは小さく抑えておきます。

詳細については、「操作のベスト プラクティス」を参照してください。

バックアップと復元に DPM 2010 を使用する場合は、各サービス アプリケーションのバックアップおよび復元を個別に計画するようにします。DPM 2010 は、Search Service アプリケーションや他のサービス アプリケーションのバックアップを行いません。

詳細については、「環境内での保護および復元対象を選択する」および「How to protect SharePoint with DPM 2010 whitepaper (英語)」(https://go.microsoft.com/fwlink/?linkid=218153&clcid=0x411) (英語) を参照してください。

謝辞

SharePoint Server 2010 Content Publishing チームは、この記事の作成に協力していただいた以下の方々に感謝の意を表します。

  • Aaron Saikovski (Microsoft Consulting Services)

  • Ali Mazaheri (Microsoft Consulting Services)

  • Bryan Porter (Microsoft Consulting Services)

  • Chris Holder (Microsoft SharePoint Customer Engineering)

  • Dan Winter (Microsoft SharePoint Customer Engineering)

  • Eric Charran (Microsoft Consulting Services)

  • Gus Apostol (Microsoft SQL Server Customer Programs)

  • John S. Moh (Microsoft Consulting Services)

  • Luca Bandinelli (Microsoft SharePoint Customer Engineering)

  • Rahim Dossa (Microsoft Consulting Services)

  • Steve Peschka (Microsoft Consulting Services)

  • Steve Walker (Microsoft SharePoint Customer Engineering)

  • Tajeshwar Singh (Microsoft Consulting Services)

See Also

Concepts

正常性の監視 (SharePoint Server 2010)

Other Resources

正常性の監視 (SharePoint Foundation 2010)