ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)

  • [アーティクル]

 

適用先: SharePoint Foundation 2010, SharePoint Server 2010

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

この記事では、Microsoft SharePoint Server 2010 環境において、そのストレージと Microsoft SQL Server データベース層を計画して構成する方法を説明します。

この記事の容量計画に関する情報は、計画のためのガイドラインを提供するものです。これは Microsoft が現実に即した各種の特性を使って行ったテストに基づいています。しかし、実際に得られる結果は使用する環境とサイトに実装する機能によって変化します。

SharePoint Server は、データベースを管理する SQL Server データベース管理者が別に存在するような環境で実行されることが多いので、この記事の内容は SharePoint Server ファーム実装者と SQL Server データベース管理者が共に利用することを想定して書かれています。この記事を読むためには、SharePoint Server と SQL Server の両方を十分理解していることが前提となります。

この記事では、読者が「SharePoint Server 2010 での容量管理と規模設定」に説明されている概念を熟知しているものと仮定しています。

SharePoint 2010 製品のストレージおよびデータベース層の設計と構成

ストレージおよびデータベース層の設計プロセスについては、以下のステップに分解して作業を進めることをお勧めします。ストレージの要件やベスト プラクティスを含む、各設計ステップの詳細を、ステップごとに以下のセクションを設けて説明します。

  • ストレージおよび SQL Server の領域と I/O に関する要件を収集する

  • SQL Server のバージョンとエディションを選択する

  • 容量および IO の要件に基づいてストレージ アーキテクチャを設計する

  • 必要なメモリを見積もる

  • ネットワーク トポロジの要件を把握する

  • SQL Server を構成する

  • ストレージのパフォーマンスと信頼性を確認する

ストレージおよび SQL Server の領域と I/O に関する要件を収集する

ストレージの設計には、SharePoint Server 2010 のいくつかの構造上の要素が影響します。その主な要素として、コンテンツの分量、利用する機能やサービス、ファームの数、可用性のニーズなどを挙げることができます。

ストレージの計画を開始するに当たっては、SharePoint Server 2010 で使用できるデータベースについて十分理解しておくことが大切です。

このセクションの内容

  • SharePoint 2010 製品で使用されるデータベース

  • SQL Server と IOPS について

  • コア ストレージおよび IOPS のニーズを見積もる

  • サービス アプリケーションのストレージおよび IOPS のニーズを決定する

  • 可用性のニーズを決定する

SharePoint 2010 製品で使用されるデータベース

SharePoint Server 2010 でインストールされるデータベースは、その環境で利用する機能によって異なります。SharePoint 2010 Products のどの環境も、SQL Server のシステム データベースに依存します。このセクションでは、SharePoint Server 2010 でインストールされるデータベースの概要を示します。詳細情報については、「データベースの種類と説明 (SharePoint Server 2010)」と「データベース モデル (https://go.microsoft.com/fwlink/p/?LinkId=187968) をご覧ください。

製品のバージョンとエディション データベース

SharePoint Foundation 2010

構成

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

コンテンツ (複数指定可)

Usage and Health Data Collection

Business Data Connectivity

Application Registry Service (Microsoft Office SharePoint Server 2007 Business Data Catalog からアップグレードする場合)

Subscription Settings Service (Windows PowerShell で有効化されている場合)

SharePoint Server 2010 Standard Edition の追加データベース

Search Service アプリケーション:

  • Search Administration

  • クロール (複数指定可)

  • プロパティ (複数指定可)

User Profile Service アプリケーション:

  • プロファイル

  • 同期

  • ソーシャル タグ

Web Analytics Service アプリケーション

  • ステージング

  • レポート

Secure Store Service

State Service

Managed Metadata Service

Word Automation Service

SharePoint Server 2010 Enterprise Edition の追加データベース

PerformancePoint Service

Project Server 2010 の追加データベース

下書き

発行済み

アーカイブ

レポート

FAST Search Server の追加データベース

Search Administration

SQL Server との統合をさらに徹底する場合は、次のシナリオのように環境に追加データベースを含めることもあります。

  • SharePoint Server 2010 環境に SQL Server 2008 R2 Enterprise Edition と SQL Server Analysis Services が含まれていれば、その環境で Microsoft SQL Server 2008 R2 PowerPivot for Microsoft SharePoint 2010 を使用できます。これを使用する場合は、PowerPivot Application データベースをサポートし、システムの追加的な負荷をサポートするように計画する必要もあります。詳細については、「SharePoint ファームへの PowerPivot の配置の計画」(https://go.microsoft.com/fwlink/p/?LinkID=186698) を参照してください。

  • SharePoint 2010 製品のどの環境でも Microsoft SQL Server 2008 Reporting Services (SSRS) プラグインを使用できます。このプラグインを使用する場合は、2 つの SQL Server 2008 Reporting Services データベースをサポートすることと、SQL Server 2008 Reporting Services で必要とされる追加的な負荷について計画してください。

SQL Server と IOPS について

SQL Server をホストするサーバーでは、I/O サブシステムからできるだけ速やかに応答することが非常に重要です。

高速なディスクやアレイの数が多ければ多いほど、IOPS (1 秒間の入出力操作数) が向上すると同時に、すべてのディスクでの遅延が短く抑えられます。

I/O サブシステムの応答が遅い場合は、他の種類のリソース (CPU やメモリ) を追加しても埋め合わせることはできず、ファーム全体に影響を与え、問題を発生させる可能性があります。展開を行う前に最小限の遅延について計画し、既存のシステムを監視してください。

新しいファームを展開する前に、SQLIO ディスク サブシステム ベンチマーク ツールを使用して I/O サブシステムのベンチマークを測定することをお勧めします。詳細については、「SQLIO ディスク サブシステム ベンチマーク ツール」(https://go.microsoft.com/fwlink/p/?LinkID=105586) を参照してください。

SQL Server の視点で IOPS の必要性を分析する方法の詳細については、「Analyzing I/O Characteristics and Sizing Storage Systems for SQL Server Database Applications」(https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx) を参照してください。

コア ストレージおよび IOPS のニーズを見積もる

構成ストレージおよび IOPS とコンテンツ ストレージおよび IOPS は、SharePoint Server 2010 を展開する際に必ず計画しなければならない基底のレイヤーです。

構成ストレージおよび IOPS

構成データベースとサーバーの全体管理コンテンツ データベースに必要なストレージは大きくありません。構成データベースに 2 GB、サーバーの全体管理コンテンツ データベースに 1 GB のストレージを割り当てることをお勧めします。構成データベースは徐々に成長して 1 GB を超えることもありますが、その成長速度はそれほど速くなく、50,000 サイト コレクションごとにおよそ 40 MB ずつ成長します。

構成データベースのトランザクション ログは大きくなる可能性があるので、データベースの復旧モデルを完全復旧モデルから単純復旧モデルに変更することをお勧めします。

注意

SQL Server データベース ミラーリングを使用して構成データベースの可用性を高める場合には、完全復旧モデルを使用する必要があります。

構成データベースとサーバーの全体管理コンテンツ データベースに必要な IOPS はごくわずかです。

コンテンツ ストレージおよび IOPS

コンテンツ データベースに必要なストレージおよび IOPS は正確に見積もることができる性質のものではありません。以下に示す情報は、実際の展開の初期サイズを決める見積もりの基礎となるはずです。ただし、環境の運用中は現実の環境から得られるデータに基づいて必要な容量を適宜再検討する必要があります。

容量計画の全般的な手順の詳細については、「SharePoint Server 2010 での容量管理と規模設定」を参照してください。

コンテンツ データベースのストレージを見積もる

以下の手順は、ログ ファイルを考慮しないで、コンテンツ データベースに必要なおおよそのストレージを見積もる方法を示しています。

  1. ドキュメント数の推定値を計算します。この値は後述の式中の D に相当します。

    ドキュメント数の計算方法は、使用する機能によって決まります。たとえば、個人用サイトまたはグループ作業サイトでは、1 ユーザー当たりのドキュメント数を推定し、それにユーザー数を乗じて推定値を計算することをお勧めします。また、レコード管理サイトやコンテンツ発行サイトでは、ある特定のプロセスによって管理され生成されるドキュメントの数を計算することになるでしょう。

    現在のシステムから移行する場合は、現在の成長率と実績値に基づいてもっと簡単に値を推定できます。新しいシステムを作成する場合は、既存のファイル共有やその他のリポジトリを調査し、その使用率に基づいて値を推定してください。

  2. 保存するドキュメントの平均的なサイズを推定します。この値は後述の式中の S に相当します。種類ごとまたはサイト グループごとに平均値を推定すると効果的です。個人用サイト、メディア リポジトリ、各部門ポータルによって、平均ファイル サイズは大きく異なるからです。

  3. 環境内のリスト項目の数を見積もります。この値は後述の式中の L に相当します。

    リスト項目数を見積もるのはドキュメントの場合ほど簡単ではありません。一般に、ドキュメント数 (D) に 3 を乗じた値を推定値として使用しますが、これはサイトの使用状況によって変化します。

  4. バージョン数の概数を決定します。ライブラリ内のドキュメントが平均していくつのバージョンを持つかを推定してください (この値は、通常、最大許容バージョン数よりもかなり小さくなります)。この値は後述の式中の V に相当します。

    V の値はゼロよりも大きくする必要があります。

  5. 次の式に基づいてコンテンツ データベースのサイズを推定します。

    データベース サイズ = ((D × V) × S) + (10 KB × (L + (V × D)))

    式中の 10 KB という値は、SharePoint Server 2010 で必要とされるメタデータの大きさをざっと見積もった定数です。メタデータを多用するシステムでは、この定数の値をこれより大きくしたほうがよいこともあります。

たとえば、この式で以下の値に基づいてグループ作業環境におけるコンテンツ データベースのデータ ファイルに必要とされるストレージの大きさを見積もると、およそ 105 GB のストレージが必要であることがわかります。

入力 値

ドキュメント数 (D)

200,000

10,000 ユーザー × 20 ドキュメントと仮定して計算

平均ドキュメント サイズ (S)

250 KB

リスト項目数 (L)

600,000

最新版以外のバージョン数 (V)

2

最大許容バージョン数を 10 と仮定

データベース サイズ = (((200,000 x 2)) × 250) + ((10 KB × (600,000 + (200,000 x 2))) = 110,000,000 KB、すなわち 105 GB

コンテンツ データベースのサイズに影響する機能

SharePoint Server 2010 の以下の機能を使用すると、コンテンツ データベースのサイズに大きく影響することがあります。

  • ごみ箱   ドキュメントは、第 1 段階と第 2 段階の両方のごみ箱から完全に削除するまでは、コンテンツ データベース内の領域を消費します。毎月どれだけドキュメントが削除されるかを計算して、コンテンツ データベースのサイズに対するごみ箱の影響を判断してください。詳細については、「ごみ箱の設定を構成する (SharePoint Server 2010)」を参照してください。

  • 監査   監査データは、特に監査レポートの表示がオンの場合、急速に増加し、コンテンツ データベース内の領域を大量に消費することがあります。監査データが無制限に増えるのを放置しないで、規制や内部統制の条件を満たすイベントについてだけ監査を有効にすることをお勧めします。次のガイドラインに従って、監査データのために取っておく必要がある領域を見積もってください。

    • サイトに必要な新しい監査エントリの個数を見積もり、その値に 2 KB を乗じる (生成されるエントリのサイズは最大 4 KB で、平均サイズはおよそ 1 KB)。

    • 割り当てる領域の大きさに基づき、監査ログを保持しておく日数を計算する。

  • Office Web Apps。Office Web Apps を使用する場合は、Office Web Apps キャッシュがコンテンツ データベースのサイズに大きく影響することがあります。Office Web Apps キャッシュは、既定で 100 GB となるように構成されます。Office Web Apps キャッシュのサイズの詳細については、「Office Web Apps のキャッシュを管理する」を参照してください。

コンテンツ データベースに必要な IOPS を見積もる

コンテンツ データベースに必要な IOPS は、環境の利用状況と、所有するディスク領域の分量サーバー数によって大きく変化します。一般的には、実際の環境で予想されるワークロードを、Microsoft においてテストされたソリューションのいずれかと比較することをお勧めします。詳細については、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)」を参照してください。

重要

このセクションのコンテンツに関するテストはまだ完了していません。随時、追加情報をご確認ください。

サービス アプリケーションの必要なストレージと IOPS を見積もる

コンテンツ ストレージおよび IOPS のニーズを見積もった後、次に、実際の環境で使用するそれぞれのサービス アプリケーションについて必要なストレージと IOPS を決定する必要があります。

SharePoint Server 2010 サービス アプリケーションに必要なストレージと IOPS

システム内のサービス アプリケーションに必要なストレージを見積もるためには、最初に各サービス アプリケーションとその使用方法を確認する必要があります。次の表に、SharePoint Server 2010 で使用できるサービス アプリケーションのうち、データベースを持つものを示します。

サービス アプリケーション サイズの見積もりに関する推奨事項

Search Service

Search Service には 3 種類のデータベースが必要です。プロパティ データベースとクロール データベースは、環境によっては複数存在することもあります。

検索管理データベースは、通常は小規模です。これには 10 GB を割り当てます。

プロパティ データベースとクロール データベースに必要なストレージを見積もるには、以下の乗数を使用します。

  • クロール: 0.046 × (コンテンツ データベースの合計サイズ)

  • プロパティ: 0.015 × (コンテンツ データベースの合計サイズ)

Search Service で必要とされる IOPS は、かなり大きくなります。

  • クロール データベースでは、3,500 ～ 7,000 IOPS が必要です。

  • プロパティ データベースでは、2,000 IOPS が必要です。

Search Service に必要な容量を見積もる方法の詳細については、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)」を参照してください。

FAST Search Server 2010 for SharePoint のアーキテクチャは異なっています。クロール データベースの IOPS 要件は同じですが、プロパティ データベースは人の検索のみのために使用され、追加の検索管理データベースがあります。FAST Search Server 2010 for SharePoint の詳細については、「検索トポロジを計画する (FAST Search Server 2010 for SharePoint)」と「パフォーマンスと容量の管理 (FAST Search Server 2010 for SharePoint)」を参照してください。

User Profile Service

User Profile Service アプリケーションは、プロファイル、同期、ソーシャル タグの 3 つのデータベースと関係しています。

これらのデータベースに必要なストレージを見積もるには、次の情報を使用します。

  • プロファイル。既定の設定を使用すると、Active Directory を使用するように構成された環境では、ユーザー プロファイルごとに約 1 MB のストレージがプロファイル データベースで必要となります。

  • 同期。既定の設定を使用すると、1 ユーザー当たりのグループ数がほとんどゼロの環境では、ユーザー プロファイルごとに約 630 KB のストレージが同期データベースで必要となります。この領域の 90% はデータ ファイルによって使用されます。

  • ソーシャル タグ。既定の設定を使用すると、タグ、コメント、または評価の件数 1 件当たり約 0.009 MB のストレージがソーシャル タグ データベースで必要となります。ユーザーによって何件のタグやメモが作成されるか見積もるには、site del.icio.us に関する次の情報を参考にしてください。

    • 約 10% のユーザーがアクティブであると考えられる。

    • アクティブなユーザーは 1 か月当たり 4.5 件のタグと 1.8 件のコメントを作成する。

ユーザー プロファイル数 160,000、グループ数 5、タグ、コメント、評価数 79,000 (コメント 2,500 件、タグ 76,000 件、評価 800 件) で、既定の設定を使用するある共同作業環境では、これらのデータベースのために実際に次のサイズの領域が使用されていました。

 

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

プロファイル

155 GB

同期

96 GB

ソーシャル タグ

0.66 GB

Managed Metadata Service

Managed Metadata Service アプリケーションは 1 つのデータベースを持ちます。このデータベースのサイズは、システム内で使用されるコンテンツ タイプおよびキーワードの個数に影響されます。多くの環境では、Managed Metadata Service アプリケーションの複数のインスタンスが存在します。

Web Analytics Service

Web Analytics Service は、ステージングとレポートの 2 つのデータベースを持ちます。これらのデータベースのサイズに影響する要因は数多くあります。たとえば、データ保持期間や毎日追跡するデータ量、分析対象 Web アプリケーション内のサイト コレクション、サイト、およびサブサイトの個数などが影響します。これらに必要なサイズと IOPS を見積もる方法の詳細については、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)」を参照してください。

Secure Store Service

Secure Store Service アプリケーション データベースのサイズは、ストア内の資格情報の個数と監査テーブルの項目数で決まります。このデータベースには、資格情報 1,000 個当たり 5 MB を割り当てることをお勧めします。必要な IOPS はごくわずかです。

State Service

State Service アプリケーションは 1 つのデータベースを持ちます。このデータベースには、1 GB を割り当てることをお勧めします。必要な IOPS はごくわずかです。

Word Automation Service

Word Automation Service アプリケーションは 1 つのデータベースを持ちます。このデータベースには、1 GB を割り当てることをお勧めします。必要な IOPS はごくわずかです。

PerformancePoint Service

PerformancePoint Service アプリケーションは 1 つのデータベースを持ちます。このデータベースには、1 GB を割り当てることをお勧めします。必要な IOPS はごくわずかです。

可用性のニーズを決定する

可用性とは、ユーザーが SharePoint Server 2010 環境を利用可能であると感ずる度合いのことです。可用性の高いシステムは、回復力があるシステムです。つまり、サービスに影響するような出来事があまり起こらず、それが起きても迅速で効果的な処置が取られるシステムです。

可用性を高めようとすると、必要なストレージが大幅に増えることがあります。詳細については、「可用性を計画する (SharePoint Server 2010)」を参照してください。

SQL Server のバージョンとエディションを選択する

SharePoint 2010 Productsは、Microsoft SQL Server 2008 R2、SQL Server 2008、SQL Server 2005 のいずれでも動作しますが、パフォーマンス、可用性、セキュリティ、および各種管理機能の面でより高いレベルを望むなら、Enterprise Edition の SQL Server 2008 または SQL Server 2008 R2 で実行することを検討するよう強くお勧めします。SQL Server 2008 R2 Enterprise Edition を使用するメリットの詳細については、「SQL Server 2008 R2 と SharePoint 2010 製品: よりよい統合 (ホワイト ペーパー) (SharePoint Server 2010)」を参照してください。

特に、以下の機能について必要性を検討してください。

  • バックアップ圧縮   バックアップ圧縮は、SharePoint のバックアップを高速化する効果があり、SQL Server 2008 Enterprise Edition または SQL Server 2008 R2 Standard Edition で使用できます。使用するバックアップ スクリプト内で圧縮オプションを設定するか、SQL Server の実行サーバーを構成する際に圧縮を既定のオプションとして設定すれば、データベース バックアップと配布ログのサイズを大幅に削減できます。詳細については、「バックアップの圧縮 (SQL Server)」(https://go.microsoft.com/fwlink/p/?LinkId=129381) を参照してください。

    注意

    SQL Server のデータ圧縮は、SharePoint 2010 Productsではサポートされていません (Search Service アプリケーション データベースを除く)。

  • 透過的なデータ暗号化   透過的なデータ暗号化がセキュリティの要件に含まれている場合は、SQL Server Enterprise Edition を使用する必要があります。

  • Web Analytics Service アプリケーション   アプリケーションを重要な分析で使用することを計画している場合は、システムで表のパーティション作成機能を利用できるようにするために SQL Server Enterprise Edition を使用することを検討してください。

  • コンテンツ展開   コンテンツ展開機能を使用することを計画している場合は、システムで SQL Server データベース スナップショットを利用できるようにするために SQL Server Enterprise Edition を使用することを検討してください。

  • リモート BLOB ストレージ   各コンテンツ データベースに関連付けられているファイルとは別に特定のデータベースまたは場所を指すリモート BLOB ストレージを利用する場合は、SQL Server 2008 または SQL Server 2008 R2 Enterprise Edition を使用する必要があります。

  • リソース ガバナー   リソース ガバナーとは、SQL Server 2008 で導入された技術であり、送られてくる要求のリソース消費に一定の制限を設けることで、SQL Server のワークロードとリソースを管理できるようにするものです。リソース ガバナーを使用すると、ワークロードを峻別し、要求された CPU やメモリを自分で決めた制限に基づいて割り当てることができます。この機能は SQL Server 2008 または SQL Server 2008 R2 Enterprise Edition でのみ利用できます。リソース ガバナーの詳細については、「リソース ガバナーを使用した SQL Server ワークロードの管理」を参照してください。

    SharePoint Server 2010 では、次の目的でリソース ガバナーを使用することをお勧めします。

    • 検索クロール コンポーネントの対象となる Web サーバーが消費する SQL Server リソースの量を制限する。ベスト プラクティスとして、システムに負荷がかかっているときは、クロール コンポーネントの CPU 使用率を 10 パーセントに制限することをお勧めします。

    • システム内の各データベースで消費されるリソースの量を監視する。たとえば、リソース ガバナーを使用すると、SQL Server を実行している各コンピューターにデータベースをどう配置すればよいかを決めることができます。

  • PowerPivot for SharePoint 2010   この機能を使用すると、ユーザーはユーザーの生成したデータ モデルや分析を Excel またはブラウザーで共有して共同で作業しながら、それらの分析を自動的に更新できます。この機能は SQL Server 2008 R2 Enterprise Edition Analysis Services に含まれています。

容量および I/O の要件に基づいてストレージ アーキテクチャを設計する

実際の環境でどのストレージ アーキテクチャとディスク タイプを使用するかによって、システムのパフォーマンスが影響を受けることがあります。

このセクションの内容

  • ストレージ アーキテクチャを選択する

  • ディスク タイプを選択する

  • RAID タイプを選択する

ストレージ アーキテクチャを選択する

SharePoint Server 2010 では、DAS (Direct Attached Storage)、SAN (Storage Area Network)、NAS (Network Attached Storage) の各ストレージ アーキテクチャがサポートされていますが、コンテンツ データベースがリモート BLOB ストレージを利用するように構成されている場合には NAS のみを使用できます。どれを選択するかは、ビジネス ソリューションと現在のインフラストラクチャに含まれるさまざまな要因によって変化します。

どのストレージ アーキテクチャも必要な可用性を満たし、適切な IOPS と遅延で実行する必要があります。この条件を満たすためにシステムは常にデータの 1 バイト目を 20 ミリ秒以内に返す必要があります。

DAS (Direct Attached Storage)

DAS は、ストレージ ネットワークを介さないでサーバーまたはワークステーションに直に接続されるデジタル ストレージ システムです。DAS の物理ディスク タイプには、SAS (Serial Attached SCSI) と SATA (Serial Attached ATA) があります。

一般に、共有ストレージ プラットフォームが平均およびピーク時の IOPS で 20 ms の応答時間と十分な容量を保証できないときは、DAS アーキテクチャを選択することをお勧めします。

SAN (Storage Area Network)

SAN は、リモート コンピューターのストレージ デバイス (ディスク アレイやテープ ライブラリ) を接続して、オペレーティング システムにローカルに接続されたデバイス (たとえば、ブロック ストレージ) のように見せるためのアーキテクチャです。

一般に、共有ストレージのメリットが組織にとって意味があるときは、SAN を選択することをお勧めします。

共有ストレージには次のメリットがあります。

  • サーバー間のディスク ストレージの再配置が簡単になる。

  • 複数のサーバーに対応できる。

  • アクセスできるディスクの数に制限がない。

ネットワーク接続ストレージ (NAS)

NAS ユニットは、ネットワークに接続された自己完結的なコンピューターです。その唯一の目的は、ネットワーク上の他のデバイスにファイル ベースのデータ ストレージ サービスを提供することです。NAS ユニット上のオペレーティング システムとソフトウェアによって、データ ストレージ、ファイル システム、およびファイル アクセスの機能と、これらの機能 (ファイル ストレージなど) の管理が実現されます。

注意

コンテンツ データベースがリモート BLOB ストレージを利用するように構成されている場合には、NAS のみを使用できます。どのネットワークストレージ アーキテクチャも ping に 1 ms 以内に応答する必要があり、20 ms 以内にデータの 1 バイト目を返す必要があります。この制限はローカルの SQL Server FILESTREAM プロバイダーには適用されません。データが同じサーバー上にローカルにしか保存されないからです。

ディスク タイプを選択する

システム内で使用するディスク タイプが信頼性とパフォーマンスに影響することがあります。他の条件がすべて同じならドライブの容量が大きいほど平均シーク時間は長くなります。SharePoint Server 2010 は、以下のタイプのドライブをサポートしています。

  • SCSI (Small Computer System Interface)

  • SATA (Serial Advanced Technology Attachment)

  • SAS (Serial-attached SCSI)

  • FC (Fibre Channel)

  • IDE (Integrated Device Electronics)

  • SSD (Solid State Drive)/Flash Disk

RAID タイプを選択する

RAID (Redundant Array of Independent Disks) は、個々のディスクによるパフォーマンス特性を改善すること (これは複数のディスクにデータをストライピングすることで実現される) と同時に個々のディスクの故障への耐性を高める目的でよく使用されます。

SharePoint Server 2010 では、すべての RAID タイプがサポートされていますが、RAID 10 かそれと同等のパフォーマンスを持つベンダー固有の RAID ソリューションを使用することをお勧めします。

RAID アレイを構成するときは、ファイル システムをベンダー提供のオフセットに必ず合わせてください。ベンダーの指示がない場合は、「SQL Server の展開前 I/O のベスト プラクティス」(https://go.microsoft.com/fwlink/p/?LinkID=105583) を参照してください。

RAID と SQL Server I/O サブシステムの準備の詳細については、「SQL Server Best のベスト プラクティス記事」(https://go.microsoft.com/fwlink/p/?LinkId=168612) を参照してください。

必要なメモリを見積もる

SharePoint Server 2010 に必要なメモリは、SQL Server を実行するサーバー上でホストしているコンテンツ データベースのサイズと直接関係しています。

サービス アプリケーションや機能を追加すると、それに伴って要件も厳しくなるものです。次の表に、推奨するメモリ量のガイドラインを示します。

注意

展開の規模 (小規模と中規模) の意味は、記事「SharePoint Server 2010 での容量管理と規模設定の概要」の「基準となるアーキテクチャ」セクションで説明されています。

コンテンツ データベースの合計サイズが SQL Server を実行するコンピューターの推奨メモリ量

小規模の実稼働環境に展開する場合の最小値

8 GB

中規模の実稼働環境に展開する場合の最小値

16 GB

最大 2 テラバイトの場合の推奨値

32 GB

2 テラバイトから 5 テラバイトの範囲の推奨値

64 GB

5 テラバイトを超える場合の推奨値

64 GB を超える追加の RAM があれば、SQL Server のキャッシュ スピードが向上します

注意

これらの値が SQL Server の最小値として推奨されている値よりも大きいのは、SharePoint Server 2010 環境で必要とされるデータ分布のためです。SQL Server のシステム要件の詳細については、「SQL Server 2008 R2 のインストールに必要なハードウェアおよびソフトウェア」(https://go.microsoft.com/fwlink/p/?LinkId=129377) を参照してください。

必要メモリ量に影響するその他の要因には次のものがあります。

  • SQL Server ミラーリングを使用する。

  • 15 MB より大きいファイルを頻繁に使用する。

ネットワーク トポロジの要件を把握する

ファーム内とファーム間のネットワーク接続について計画してください。遅延の短いネットワークを使用することをお勧めします。

以下に、ベスト プラクティスと推奨方法を示します。

  • ファーム内のどのサーバーも SQL Server を実行しているサーバーに対して LAN 接続の帯域幅と遅延を持ちます。遅延が 1 ミリ秒を超えないようにしてください。

  • SQL Server を実行しているサーバーがファーム内の他のコンポーネントから遠く離れて展開され、そのネットワーク接続の遅延が 1 ms を超えるようなワイド エリア ネットワーク (WAN) トポロジは、お勧めしません。このトポロジはまだテストされていません。

  • SQL Server ミラーリングまたはログ配布を使用してリモート サイトを最新の状態に保つ場合は、適切な WAN ネットワークを計画してください。

  • Web サーバーやアプリケーション サーバーに 2 つのネットワーク アダプターを設けることをお勧めします。1 つのネットワーク アダプターでエンド ユーザーのトラフィックを処理し、もう 1 つのアダプターで SQL Server を実行しているサーバーとの通信を処理します。

SQL Server を構成する

以下のセクションでは、SharePoint Server 2010 の SQL Server についての構成計画を説明します。

このセクションの内容

  • 必要なサーバーの数を見積もる

  • ストレージとメモリを構成する

  • SQL Server のオプションを設定する

  • データベースを構成する

必要なサーバーの数を見積もる

一般的に、SharePoint Server 2010 は SQL Server のスケール アウトを利用するように設計されています。すなわち、SharePoint Server 2010 は、少数の大規模なサーバーが存在する環境よりも、SQL Server を実行している多数の中規模サーバーが存在する環境で高いパフォーマンスを発揮します。

システムをスタンドアロン サーバーに展開する場合以外は、常に SQL Server を専用のサーバーに配置してください。また、そこで他のファーム ロールを実行したり、他のアプリケーションのデータベースをホストしたりすることはしないでください。

次は、SQL Server を実行する追加サーバーを展開するときの一般的なガイダンスです。

  • 最大限の能力で稼働する Web サーバーが 4 台を超えたとき、もう 1 台のデータベース サーバーを追加する。

  • 現在のサーバーが RAM、CPU、ディスク IO スループット、ディスク容量、またはネットワーク スループットの実質のリソース上限に達したとき、もう 1 台のデータベース サーバーを追加する。

注意

Microsoft は、このガイダンスに従わないサーバー構成もサポートしています。

Secure Store Service アプリケーションを実行しているときは、資格情報ストレージのセキュリティを高めるために Secure Store データベースを独立したデータベース インスタンス上でホストして一人の管理者だけがそこにアクセスできるようにすることをお勧めします。

ストレージとメモリを構成する

SQL Server 2008 を実行しているサーバーでは、CPU ごとに 2 MB の L2 キャッシュを割り当ててメモリのアクセス速度を上げることをお勧めします。

ベンダーの推奨するストレージ構成方法に従う

物理ストレージ アレイを構成するときは、最適なパフォーマンスを得るため、オペレーティング システムの既定の値に頼らず、ストレージ ベンダーの推奨するハードウェア構成方法に従ってください。

ベンダーからガイダンスが提供されていない場合は、DiskPart.exe ディスク構成ユーティリティを使用して SQL Server 2008 のストレージを構成することをお勧めします。詳細については、「展開前 I/O のベスト プラクティス」(https://go.microsoft.com/fwlink/p/?LinkID=105583) を参照してください。

可能な限り多くのリソースを提供する

ディスクへの SQL Server I/O チャネルが他のアプリケーションで共用されないようにしてください。たとえば、ページング ファイルやインターネット インフォメーション サービス (IIS) ログで共用されないようにします。

バスの帯域幅を可能な限り広くしてください。帯域幅が大きいほど、信頼性とパフォーマンスを高める効果があります。バスの帯域幅を消費するのはディスクだけではありません。たとえば、ネットワーク アクセスも考慮する必要があります。

SQL Server のオプションを設定する

SharePoint Server を展開する前に SQL Server の以下の設定やオプションを構成してください。

  • SharePoint Server をサポートしている SQL Server では統計の自動作成を有効にしないでください。SharePoint Server では、準備とアップグレードで必要な設定を構成します。統計の自動作成を有効にすると、クエリの実行計画が大きく変更され、あるインスタンスの SQL Server から別のインスタンスの SQL Server に移ることがあります。そのため、すべての顧客が一貫したサポートを得られるように、SharePoint Server は必要に応じてクエリに暗号化されたヒントを提供して、どのようなシナリオでも最適なパフォーマンスが得られるようにしています。

  • 最適なパフォーマンスが得られるように、SharePoint Server 2010 データベースをホストする SQL Server インスタンスで、並列処理の最大限度 (MAXDOP) を 1 に設定することを強くお勧めします。並列処理の最大限度を設定する方法の詳細については、「max degree of parallelism オプション」(https://go.microsoft.com/fwlink/p/?LinkId=189030) を参照してください。

  • メンテナンスが簡単になるように、ファーム内のデータベース サーバーごとに SQL Server 接続エイリアスを構成してください。接続エイリアスとは、SQL Server のインスタンスに接続するための別名です。詳細については、「SQL Server の別名を設定する方法 (SQL Server Management Studio)」(https://go.microsoft.com/fwlink/p/?LinkId=132064) を参照してください。

データベースを構成する

次のガイダンスは、環境内の各データベースを構成するときのベスト プラクティスです。

データ別にディスクを分類して優先度を付ける

理想的には、tempdb データベース、コンテンツ データベース、利用状況データベース、検索データベース、SQL Server 2008 トランザクション ログをそれぞれ別の物理ハード ディスクに配置してください。

以下に、データの優先度を決めるベスト プラクティスと推奨方法を示します。

  • 優先度の高いデータをより高速のディスクに配置するときは、次のように順位を決めます。

    1. tempdb データ ファイルとトランザクション ログ

    2. データベースのトランザクション ログ ファイル

    3. 検索データベース (検索管理データベースは除く)

    4. データベースのデータ ファイル

    読み取りが非常に多いポータル サイトでは、ログよりもデータを優先します。

  • テストと顧客から得たデータによれば、tempdb のディスク I/O 能力が十分でないと、SharePoint Server 2010 ファームのパフォーマンスが大幅に低下することがわかっています。この問題を避けるため、tempdb に専用のディスクを割り当ててください。高いワークロードが予想されるか実際に観測されている場合は (具体的には、読み取りまたは書き込みに平均 20 ms 以上かかっている場合)、ファイルをディスクに分けて配置するか、より高速なディスクに交換することによって、この障害を軽減する必要があります。

  • 最適なパフォーマンスが得られるように、tempdb を RAID 10 アレイに配置します。tempdb データ ファイルの数は、コア CPU の個数と等しくしてください。また、tempdb データ ファイルはいずれも同じサイズに設定してください。この場合、デュアルコア プロセッサは 2 CPU と数えます。ハイパースレッディングをサポートする各プロセッサは、1 CPU と数えます。詳細については、「tempdb のパフォーマンスの最適化」(https://go.microsoft.com/fwlink/p/?LinkID=148537) を参照してください。

  • データベースのデータ ファイルとトランザクション ログ ファイルを別のディスクに配置します。専用のディスクまたはストライプを割り当てるには小さすぎるために (またはディスク スペースが足りないために) ディスクを共用しなければならないファイルについては、利用パターンの異なるファイルを同じディスクに配置して、できるだけアクセス要求が同時に発生しないようにしてください。

  • 特定のストレージ ソリューションでログおよび検索データベースの書き込みを最適化するには、その構成方法をストレージ ハードウェアのベンダーに問い合わせてください。

コンテンツ データベースで複数のデータ ファイルを使用する

最適なパフォーマンスが得られるように、次の推奨方法を使用してください。

  • データベースのプライマリ ファイル グループ内にのみファイルを作成する。

  • ファイルを別のディスクに分散する。

  • データ ファイルの数をコア CPU の個数以下にする。この場合、デュアルコア プロセッサは 2 CPU と数えます。ハイパースレッディングをサポートする各プロセッサは、1 CPU と数えます。

  • データ ファイルを同じサイズで作成する。

重要

SharePoint Server 2010 に組み込まれているバックアップおよび復元ツールを使用すれば、複数のデータ ファイルをバックアップしたり復元したりできますが、同じ場所に上書きした場合は、これらのツールで複数のデータ ファイルを異なる場所に復元することはできません。そのため、コンテンツ データベースで複数のデータ ファイルを使用するときは、SQL Server のバックアップおよび復元ツールを使用することを強くお勧めします。SharePoint Server 2010 のバックアップおよび復元の詳細については、「SharePoint Server 2010 でのバックアップと復元を計画する」を参照してください。

ファイル グループの作成と管理の詳細については、「ファイルとファイル グループのアーキテクチャ」(https://go.microsoft.com/fwlink/p/?LinkId=117909) を参照してください。

コンテンツ データベースのサイズを制限して管理性を高める

実際の環境に合わせて管理性とパフォーマンスが向上するように、またアップグレードが容易になるように、データベースのサイズを計画してください。

システム パフォーマンスを確保できるように、特定の使用シナリオや条件によって大きなサイズがサポートされるのでない限り、コンテンツ データベースのサイズを 200 GB に制限することをお勧めします。コンテンツ データベースのサイズ制限の詳細については、「SharePoint Server 2010 容量管理ソフトウェアの境界と制限」の「コンテンツ データベースの制限」セクションを参照してください。

一般的には、サイト コレクションのサイズが 100 GB を超えないようにすることをお勧めします。ただし、それがデータベースの唯一のサイト コレクションである場合はその限りでありません。この制限を満たしているときは、必要なら SharePoint Server 2010 の詳細バックアップ ツールでサイト コレクションを別のデータベースに移動できます。

大規模なドキュメント リポジトリの詳細については、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)」の「大規模なドキュメント リポジトリのパフォーマンスと容量の要件の見積もり」を参照してください。

データ ファイルやログ ファイルの成長を見越して管理する

データ ファイルやログ ファイルの成長を見越して管理するために以下の推奨方法に従うことをお勧めします。

  • できるだけ、すべてのデータ ファイルとログ ファイルを、予想される最終サイズまで事前に成長させておきます。

  • 安全上の理由で自動拡張を有効にしておくことをお勧めします。自動拡張の既定の設定に頼らず、自動拡張を構成するとき次のガイドラインを検討してください。

    • 推奨サイズ (200 GB) を超えるようなコンテンツ データベースを計画するときは、データベースの自動拡張値を比率ではなくメガバイト単位の固定値に設定します。これで SQL Server がファイルのサイズを拡張する頻度が小さくなります。ファイル サイズの拡張は、新たな領域を空のページで埋めるブロッキング操作です。

    • Search Service アプリケーションの Property Store データベースの自動拡張値を 10 パーセントに設定します。

    • コンテンツ データベースの計算上の大きさが翌年の間に最大推奨サイズの 200 GB に達しないと見込まれる場合は、ALTER DATABASE MAXSIZE プロパティを使用して、1 年以内に達すると見込まれる最大サイズに 20 パーセントの誤差を上乗せした値をデータベースのサイズとして設定します。この設定を定期的に見直し、過去の成長率と照らして値がまだ適切であることを確認するようにしてください。

  • 成長とピーク時の利用パターンに対応できるように、使用している各ディスクの全体で少なくとも 25 パーセント程度の空き領域を残すようにします。RAID アレイにディスクを追加するかストレージの割り当てを増やす方法で成長を管理している場合は、ディスク サイズを念入りに監視して領域が足りなくならないようにしてください。

ストレージと SQL Server のパフォーマンスを検証し監視する

使用しているハードウェアのパフォーマンスとバックアップ ソリューションがサービス レベル契約 (SLA) の要件を満たすことができるかテストしてください。特に、SQL Server を実行しているコンピューターの I/O サブシステムをテストして、十分なパフォーマンスが得られるか確認します。

使用しているバックアップ ソリューションをテストして、利用可能なメンテナンス時間の間にシステムのバックアップが可能か確認します。バックアップ ソリューションがビジネス上の SLA の要件を満たせない場合は、System Center Data Protection Manager (DPM) 2010 などの増分バックアップ ソリューションの使用を検討してください。

SQL Server を実行しているサーバーのリソース コンポーネントとして CPU、メモリ、キャッシュ/ヒット率、および I/O サブシステムを監視することが重要です。これらのコンポーネントの 1 つ以上で速度の低下や過負荷の状況が見られる場合には、現状および今後予想されるワークロードに基づいて適切な戦略を練ります。詳細については、「SQL Server 2008 でのパフォーマンスの問題のトラブルシューティング」(https://go.microsoft.com/fwlink/p/?LinkID=168448) を参照してください。

次のセクションでは、SharePoint Server 2010 環境で稼働する SQL Server データベースのパフォーマンスを監視するために推奨されているパフォーマンス カウンターを示します。各カウンターの望ましいおおよその値も示します。

パフォーマンスの監視とパフォーマンス カウンターの使用方法の詳細については、「ファースト ステップ ガイド - パフォーマンスの監視」(https://go.microsoft.com/fwlink/p/?LinkId=189032) を参照してください。

監視する SQL Server カウンター

サーバーの調子を確認するために SQL Server の以下のカウンターを監視します。

  • General Statistics\uc1\u160 ?\u160 ?\u160 ?このオブジェクトは、サーバーの全般的な活動を監視するためのカウンターを提供しています。たとえば、現在の接続数、SQL Server インスタンスを実行しているコンピューターに対する 1 秒間当たりのユーザー接続数/切断数などがあります。次のカウンターを監視することを検討してください。

    • User Connections   このカウンターは、SQL Server を実行しているコンピューターのユーザー接続数を表します。この値が基準値の 500 パーセントを超える場合は、パフォーマンスの低下が見られることがあります。

  • Databases   このオブジェクトは、一括コピー、バックアップと復元のスループット、およびトランザクション ログ活動を監視するためのカウンターを提供しています。トランザクションとトランザクション ログを監視することによって、データベース内でのユーザーの活動量とトランザクション ログの消費状況を調べます。ユーザーの活動量は、データベースのパフォーマンスのほか、ログ サイズ、ロック、およびレプリケーションに影響することがあります。ユーザーの活動およびリソースの利用状況の指標となる低レベルのログ活動を監視すると、パフォーマンスのボトルネックを見つけるのに役立ちます。次のカウンターを監視することを検討してください。

    • Transactions/sec   このカウンターは、特定のデータベースまたはサーバー全体における 1 秒間当たりのトランザクション数を表します。これは基準値としての意味合いが強く、問題の解決に利用されます。

  • Locks   このオブジェクトは、リソース タイプごとの SQL Server のロックに関する情報を提供します。以下のカウンターを監視することを検討してください。

    • Average Wait Time (ms)   このカウンターは、待ち状態となった各ロック要求の平均待機時間を表します。

    • Lock Wait Time (ms)   このカウンターは、この 1 秒間に生じたロックの待ち時間を表します。

    • Lock waits/sec   このカウンターは、直ちに解決されないためにリソース待ちとなる 1 秒間当たりのロック数を表します。

    • Number of deadlocks/sec   このカウンターは、SQL Server を実行しているコンピューター上の 1 秒間当たりのデッドロック数を表します。この値が 0 より大きくならないようにしてください。

  • Latches   このオブジェクトは、SQL Server 内部のラッチと呼ばれるリソース ロックを監視するためのカウンターを提供しています。ラッチを監視してユーザーの活動およびリソースの利用状況を調べると、パフォーマンスのボトルネックを見つけるのに役立ちます。以下のカウンターを監視することを検討してください。

    • Average Latch Wait Time (ms)   このカウンターは、待ち状態となったラッチ要求の平均ラッチ待機時間を表します。

    • Latch Waits/sec   このカウンターは、直ちに許可できなかったラッチ要求数を表します。

  • SQL Statistics   このオブジェクトは、コンパイルや特定の SQL Server インスタンスに対して送信された要求の種類を監視するためのカウンターを提供しています。クエリのコンパイルおよび再コンパイルの回数や特定の SQL Server インスタンスが受け取るバッチの数を監視すると、SQL Server におけるユーザー クエリの処理速度やクエリ オプティマイザーにおけるクエリの処理効率を示す指標を得ることができます。以下のカウンターを監視することを検討してください。

    • SQL Compilations/sec   このカウンターは、コンパイル コードのパスが入力された 1 秒間当たりの回数を表します。

    • SQL Re-Compilations/sec   このカウンターは、1 秒間当たりのステートメントの再コンパイル数を表します。

  • Buffer Manager   このオブジェクトは、SQL Server のデータ ページ、内部データ構造、プロシージャ キャッシュなどを格納するメモリを監視するカウンターや、SQL Server がデータベース ページを読み書きする際の物理 I/O を監視するカウンターを提供しています。次のカウンターを監視することを検討してください。

    • Buffer Cache Hit Ratio

    • このカウンターは、バッファー キャッシュ内で見つかったためにディスクから読み取らなくて済んだページの比率を表します。この比率は、ここ数千回のページ アクセスで得られたキャッシュ ヒット総数をキャッシュ検索総数で割ったものです。キャッシュからの読み取りはディスクからの読み取りよりも遙かに低負荷なので、この比率は大きいことが望まれます。一般に、SQL Server の使用可能なメモリを増やすことでバッファー キャッシュのヒット率を高めることができます。

  • Plan Cache   このオブジェクトは、SQL Server のストアド プロシージャや、その場限りの (または事前に準備された) Transact-SQL ステートメント、トリガーといったオブジェクトを格納するメモリを監視するカウンターを提供しています。次のカウンターを監視することを検討してください。

    • Cache Hit Ratio

    • このカウンターは、プランを検索したときキャッシュがヒットする比率を表します。

Physical server counters to monitor

SQL Server を実行しているコンピューターの調子を確認するために以下のカウンターを監視します。

  • Processor: % Processor Time: _Total   このカウンターは、プロセッサがアプリケーションや Idle 以外のオペレーティング システム プロセスを実行している時間の比率を表します。SQL Server を実行しているコンピューターでは、このカウンターの値が 50 ～ 75 パーセントの範囲に入るようにしてください。過負荷の状態が続く場合は、異常なプロセス活動がないか、またはサーバーが追加的な CPU を必要としていないか調査してください。

  • System: Processor Queue Length   このカンターは、プロセッサ キュー内のスレッド数を表します。このカウンターを監視して、値がコア CPU 数の 2 倍より小さくなるようにしてください。

  • Memory: Available Mbytes   このカウンターは、コンピューター上で実行されるプロセスで利用できる物理メモリ量 (MB) を表します。このカウンターを監視して、値が利用可能な全物理メモリ量の少なくとも 20 パーセント程度になるようにしてください。

  • Memory: Pages/sec   このカウンターは、ハード ページ フォルトを解決するためのディスク ページの読み書きの速度を表します。このカウンターを監視して、値が 100 より小さくなるようにしてください。

メモリに関する問題の解決などの詳細については、「メモリ使用率の監視」(https://go.microsoft.com/fwlink/p/?LinkID=105585) を参照してください。

監視するディスク カウンター

ディスクの調子を確認するために以下のカウンターを監視します。なお、以下の値は一定の時間の経過の中で計測されるものであり、ある瞬間に生じた値や 1 回限りの計測で求められる値ではありません。

  • Physical Disk: % Disk Time: DataDrive   このカウンターは、選択したディスク ドライブが読み取りまたは書き込み要求を処理していてビジー状態にある経過時間の比率を表します。これはディスクのビジー状況を示す一般的な指標です。PhysicalDisk: % Disk Time カウンターの値が大きい (90 パーセント以上) の場合は、PhysicalDisk: Current Disk Queue Length カウンターをチェックして、ディスク アクセス待ちのシステム要求がどれだけあるか調べます。待機状態の I/O 要求数が物理ディスクのスピンドル数の 1.5 倍から 2 倍を超えないようにしてください。

  • Logical Disk: Disk Transfers/sec   このカウンターは、ディスク上の読み取りと書き込みの速度を表します。このカウンターを使用して成長傾向を監視し、適宜予測を行います。

  • Logical Disk: Disk Read Bytes/sec、Logical Disk: Disk Write Bytes/sec   これらのカウンターは、読み取り時または書き込み時のバイト転送速度を表します。

  • Logical Disk: Avg. Disk Bytes/Read   このカウンターは、読み取り時にディスクから転送される平均バイト数を表します。この値はディスクの遅延を反映し、読み取り操作が多いと遅延がいくらか大きくなることがあります。

  • Logical Disk: Avg. Disk Bytes/Write   このカウンターは、書き込み時にディスクへ転送される平均バイト数を表します。この値はディスクの遅延を反映し、書き込み操作が多いと遅延がいくらか大きくなることがあります。

  • Logical Disk: Current Disk Queue Length   このカウンターは、パフォーマンス データの収集時にディスク上でまだ処理が行われていない要求の数を表します。このカウンターは、値が小さいほどよいことになります。1 ディスク当たりの値が 2 を超えた場合は、ボトルネックがあることを示唆するので調査が必要です。これは、4 台のディスクで構成される論理ユニット (LUN) では最大 8 までの値が許容されることを意味します。これらのボトルネックはバックログを生じさせ、ディスクにアクセスしている現在のサーバーを越えてその影響が伝播し、結局、ユーザー レベルの待機時間が長くなります。ボトルネックの解消策としては、RAID アレイにディスクを追加する、既存のディスクをより高速のものに取り替える、一部のデータを他のディスクに移動する、などの方法が考えられます。

  • Logical Disk: Avg. Disk Queue Length   このカウンターは、サンプル期間中に選択したディスクで待ち状態となっていた読み取りおよび書き込み要求の平均個数を表します。ここでのルールは、1 スピンドル当たりの未処理の読み取りおよび書き込み要求が 2 個以下であることですが、ストレージの仮想化や構成間での RAID レベルに違いによって、これを計測することが難しい場合があります。そこで、ディスク キュー長とディスク遅延がそれぞれ平均値よりも大きくなっていないか調べてください。この両方が平均値よりも大きいということは、ストレージ アレイ キャッシュが過負荷の状態か、他のアプリケーションとのスピンドルの共有がパフォーマンスに影響していることを示唆します。

  • Logical Disk: Avg. Disk sec/Read と Logical Disk: Avg.Disk sec/Write   これらのカウンターは、ディスクの読み取りまたは書き込み操作の平均時間 (秒) を表します。これらのカウンターを監視して、ディスク操作がディスク能力の 85 パーセント以下にとどまっていることを確認します。読み取りまたは書き込み操作がディスク能力の 85 パーセントを超えると、ディスク アクセス時間は指数的に増加します。使用しているハードウェアの固有の能力を調べるには、ベンダーの提供するドキュメントを参照するか、SQLIO ディスク サブシステム ベンチマーク ツールを使用してそれを計算します。詳細については、「SQLIO ディスク サブシステム ベンチマーク ツール」(https://go.microsoft.com/fwlink/p/?LinkID=105586) を参照してください。

    • Logical Disk: Avg. Disk sec/Read   このカウンターは、ディスクの読み取り操作の平均時間 (秒) を表します。よく調整されたシステムにおける理想的な値は、ログの場合は 1 ～ 5 ms (キャッシュ付きアレイでは 1 ms が理想的)、データの場合は 4 ～ 20 ms (10 ms 以下が理想的) です。ピーク時に遅延がより大きくなることもありますが、大きい値がいつも現れる場合には原因を調べる必要があります。

    • Logical Disk: Avg. Disk sec/Write   このカウンターは、ディスクの書き込み操作の平均時間 (秒) を表します。よく調整されたシステムにおける理想的な値は、ログの場合は 1 ～ 5 ms (キャッシュ付きアレイでは 1 ms が理想的)、データの場合は 4 ～ 20 ms (10 ms 以下が理想的) です。ピーク時に遅延がより大きくなることもありますが、大きい値がいつも現れる場合には原因を調べる必要があります。

    RAID 構成を使用しているときの Logical Disk: Avg. Disk Bytes/Read または Logical Disk: Avg. Disk Bytes/Write カウンターについては、次の表に示す式でディスクの入力および出力速度を計算してください。

    RAID レベル 式

    RAID 0

    1 ディスク当たりの I/O 数 = (読み取り数 + 書き込み数) / ディスク数

    RAID 1

    1 ディスク当たりの I/O 数 = [読み取り数 + (2 × 書き込み数)] / 2

    RAID 5

    1 ディスク当たりの I/O 数 = [読み取り数 + (4 × 書き込み数)] / ディスク数

    RAID 10

    1 ディスク当たりの I/O 数 = [読み取り数 + (2 × 書き込み数)] / ディスク数

    たとえば、2 台の物理ディスクで構成される RAID 1 システムがあって、カウンターの値が次の表に示すとおりであるとします。

    カウンター 値

    Avg. Disk sec/Read

    80

    Logical Disk: Avg. Disk sec/Write

    70

    Avg. Disk Queue Length

    5

    1 ディスク当たりの I/O 数は次のように計算されます: (80 + (2 × 70))/2 = 110

    ディスク キュー長は次のように計算されます: 5/2 = 2.5

    この状況は、I/O ボトルネックのボーダーラインにあります。

その他の監視ツール

SQL Server 2008 の sys.dm_io_virtual_file_stats 動的管理ビューでディスクの遅延を監視して傾向を分析することもできます。詳細については、「sys.dm_io_virtual_file_stats (Transact-SQL)」(https://go.microsoft.com/fwlink/p/?LinkID=105587) を参照してください。

See Also

Other Resources

リソース センター: パフォーマンスと容量の管理 (SharePoint Server 2010)
リソース センター: データベースの管理 (SharePoint Server 2010)