SharePoint 2013/2016用のSQL Server 2012のチューニング。 パート1

こんにちは。 私の名前はリュウボフ・ボルコバです。ビジネスソリューション開発部門のシステムアーキテクトです。 Microsoftサーバー製品に関するアプリケーションの投稿を随時書いています（たとえば、 SharePointサーバーの監視や、このプラットフォームのコンテンツデータベース、サービス、およびコンポーネントに関連するデータベースの保守について）。



この投稿は、SharePointポータルの管理の観点から重要なトピック、つまり高いパフォーマンスを達成することを目的としたSQLサーバーの調整についてお話しする2つのうちの最初の記事です。 企業ポータルでホストされているデータを保存するために使用されるSQLサーバーの慎重な計画、正しいインストール、およびその後の構成を確保することは非常に重要です。



この投稿では、SQLサーバーのインストール計画について読むことができます。 少し後、2番目の部分は、SQLサーバーのインストールとその後の構成で公開されます。

SQL Serverのインストールの計画

SQL Server仮想化

なぜサーバー仮想化なのか？

サーバー仮想化が検討されている7つの主な理由は次のとおりです。

1. ハードウェア使用率の増加 。 統計によると、ほとんどのサーバーは日常のタスクを実行するときに15〜20％の負荷がかかります。 1台の物理サーバーで複数の仮想サーバーを使用すると、ハードウェアの購入を大幅に節約しながら80％に増加します。
   
   
   
   
2. ハードウェア交換コストの削減。 仮想サーバーは特定の機器から解放されているため、物理サーバー群を更新するためにソフトウェアを再インストールおよび構成する必要はありません。 仮想マシンは別のサーバーに簡単にコピーできます。
   
   
   
   
3. 仮想サーバーを使用する柔軟性を高めます。 負荷が変化する状況で複数のサーバーを使用する必要がある場合（製品環境でのテストや作業など）、仮想サーバーは最適なソリューションです。物理サーバーの負荷が増大している場合、他のプラットフォームにシームレスに転送できるためです。
   
   
   
   
4. サーバーインフラストラクチャの管理性の強化。 仮想サーバーを集中管理し、負荷分散とライブマイグレーションを提供できる多くの仮想インフラストラクチャ管理製品があります。
   
   
   
   
5. 高可用性を提供します。 仮想マシンのバックアップの準備と復元は、はるかに短い時間で済み、より簡単な手順です。 また、機器に障害が発生した場合、仮想サーバーのバックアップを別の物理サーバーですぐに起動できます。
   
   
   
   
6. スタッフの節約 。 長期的に見た仮想サーバー管理の簡素化は、会社のインフラストラクチャを提供する専門家の節約を伴います。 仮想サーバーを管理するためのツールを使用する2人が4つの機能を実行できる場合、少なくとも年間15,000ドルを受け取る2人の特別な専門家が必要なのはなぜですか？ それでも、仮想化の分野で有資格者を訓練するには、かなりの訓練も必要であることを念頭に置く必要があります。
   
   
   
   
7. 電気を節約します。 中小企業にとっては、この要因はもちろん重要ではありませんが、大規模なサーバー群を維持するためのコストに電気（電力、冷却システム）のコストが含まれる大規模なデータセンターでは、この点は非常に重要です。 1つの物理サーバーに複数の仮想サーバーを集中させると、これらのコストが削減されます。

SQL Server仮想化のサポート

SharePointファームの一部であるサーバーまたはユーザー認証、名前解決、PKI管理、およびその他の機能を提供するネットワークインフラストラクチャサーバーの仮想化を検討する場合、仮想化の可能性があることに注意する必要があります。

• Active Directoryドメインサービス
• WebサーバーとSharePointアプリケーションサーバー（フロントエンドWebサーバーとアプリケーションサーバー）。
• SQL Serverサービス
• SQL、ADS、SharePoint 2013のコンポーネント。

ゲストオペレーティングシステム、サポートされているSQLサーバーのバージョン、および仮想マシンのクラスタリングの概要を以下の表に示します。

SQL Serverバージョン	サポートされているWindows Serverゲストオペレーティングシステム	Hyper-Vサポート	ゲストクラスタリングのサポート
SQL Server 2008 SP3	2003 SP2、2003 R2 SP2、2008 SP2、2008 R2 SP1、2012、2012 R2	はい	はい
SQL Server 2008 R2 SP2	2003 SP2、2008 SP2、2008 R2 SP1、2012、2012 R2	はい	はい
SQL Server 2012 SP1	2008 SP2、2008 R2 SP1、2012、2012 R2	はい	はい
SQL Server 2014	2008 SP2、2008 R2 SP1、2012、2012 R2	はい	はい

ゲストクラスタリングは、Windows Server 2008 SP2オペレーティングシステム以降のバージョンでサポートされていることに注意してください。



フェールオーバーゲストクラスターの目的とアーキテクチャの詳細な説明はここにあります。ハードウェア要件、SQLサーバーの特定のバージョンの仮想環境での作業のサポート機能は、次の表にあるリンクから取得できます。

SQL Serverバージョン	ドキュメントリンク
SQL Server 2008 SP3	ハードウェアおよびソフトウェア要件、ハードウェア仮想化およびゲストクラスタリングサポート
SQL Server 2008 R2 SP2	ハードウェアおよびソフトウェア要件、ハードウェア仮想化およびゲストクラスタリングサポート
SQL Server 2012 SP1	ハードウェアおよびソフトウェア要件、ハードウェア仮想化およびゲストクラスタリングサポート
SQL Server 2014	ハードウェアおよびソフトウェア要件、ハードウェア仮想化およびゲストクラスタリングサポート

仮想化SQL Serverのパフォーマンス

ESG Labsの調査によると、仮想サーバーでのSQL Server 2012 OLTPのパフォーマンスは、物理プラットフォームよりも約6.3％低いだけです。



Hyper-Vは、個別の仮想マシンごとに最大64個のプロセッサをサポートします。テストでは、パフォーマンスが6倍、トランザクション実行時間が5倍増加しました。 次の図は、テストの主な結果を示しています。 詳細なレポートはこちらにあります 。







Hyper-Vは、大規模なSQLサーバーデータベースの仮想化に使用でき、 SR-IOV 、 仮想ファイバーチャネル 、 仮想NUMAなどの追加機能の使用をサポートしています。

SQL Server仮想化のデメリット

SQL Server for SharePointが物理サーバーに展開される主な理由となる主な欠点をリストします。

1. システムの信頼性を操作するアプローチを再構築する必要性。 実際、複数の仮想マシンが同じ物理サーバー上で実行されているため、ホストに障害が発生すると、すべてのVMとそれらで実行されているアプリケーションに同時に障害が発生します。
   
   
   
   
2. 負荷分散。 仮想マシンの場合、SQLサーバーは通常プロセッサ（またはメモリ）の多くのコンピューティングリソースを使用します。これは、プロセッサ時間（メモリ）も必要とする他の仮想マシンおよびホストアプリケーションの動作に影響します。 SQLサーバーを備えた仮想マシンのみがホスト上にある場合でも、最適なレベルのパフォーマンスを調整するには、複雑なアクションが必要です。 詳細については、Michael Ootyの記事（こちら）をご覧ください。 管理者は、実行中の仮想マシンが負荷の少ないサーバーに自動的に移動するルールまたは負荷のかかったサーバーを「アンロード」するルールを確立して、負荷を分散する必要があります。

RAMおよびCPU

SQLサーバーが正常に機能するようにするには、十分な量のRAMを用意する必要があります。 SharePointデータベースの操作専用に割り当てられているSQLのインスタンスが1つだけ展開されている場合、要件は最小限です。

	SharePoint Small Farm（最大500 GBのコンテンツ）	中規模のSharePointファーム（501 GBから1 TBのコンテンツ）	大規模なSharePointファーム（1〜2 TBのコンテンツ）	非常に大規模なSharePointファーム（2〜5 TBのコンテンツ）	特別な場合
RAM	8 GB	16 GB	32 GB	64 GB	64 GB
CPU	4	4	8	8	8

SharePointのサイズ、配置、および一般的なデータベース要件を計画する

SharePointは、モジュラーアーキテクチャを備えたポータルソリューションを構築するための強力なプラットフォームです。 企業ポータルの動作を保証するサービスとコンポーネントのセットにより、ストレージを計画する必要があるデータベースのリストを強調表示できます。 推奨される計画の時期が異なる3つのグループのデータベースがあります。

1. SQLサーバーをインストールする前に。 このグループには、SQLサーバーのすべてのシステムデータベース、SharePointコンテンツデータベース（既定では1つ）が含まれます。
2. SharePointサーバーをインストールする前に。 このグループには、SharePoint構成データベース、SharePointサーバーの全体管理コンテンツデータベースが含まれます。
3. データベースにデータを保存するサービスアプリケーションを展開する前。 例：管理されたメタデータサービス、ユーザープロファイルサービス、検索など
4. 追加のSharePointコンテンツデータベースを作成する前に。

このMicrosoftの記事では、グループにリストされているすべてのデータベースの主要な機能について詳しく説明しています。 次の表は、SharePointデータベースの技術サポート、移行、および復元における長年の経験を考慮して、それぞれの復旧モードを設定するための推奨事項を示しています。

データベース	デフォルトの 復旧モード	推奨される復旧モードとコメント
マスターデータベース	シンプル	シンプル
モデルデータベーステンプレート	フルアクセス	シンプル。 通常、チューニングは1回実行されるか、非常にまれに実行されます。 変更を加えた後にバックアップするだけで十分です
MSDBデータベース	シンプル	シンプル
tempdbデータベース	シンプル	シンプル
サーバーの全体管理コンテンツデータベース	フルアクセス	シンプル。
構成データベース	フルアクセス	通常、変更はSharePointファームのサービスおよびコンポーネントの初期構成またはポイントツーポイント構成中に積極的に行われます。これには、明確で短いスケジュールがあります。 完了した変更ブロックの完了後にバックアップする方が効率的です。
アプリケーション管理サービスデータベース	フルアクセス	シンプル。 通常、SharePointファームは0から少数（1〜5）のSharePointアプリケーションをインストールします。 通常、アプリケーションのインストールは時間的にかなりの間隔があります。 別のアプリケーションをインストールした後、データベースの完全バックアップを実行する方が合理的です
サブスクリプション設定サービスデータベース	フルアクセス	シンプル。 通常、SharePointアプリケーションは少数のサイト（1〜5）にインストールされます。 通常、アプリケーションのインストールは時間的にかなりの間隔があります。 別のアプリケーションをインストールした後、データベースの完全バックアップを実行する方が合理的です。 いっぱい。 無制限の数のWebサイトにアプリケーションをインストールする場合、インストールが頻繁に実行されます
ビジネスデータ接続サービス	フルアクセス	シンプル。 このサービスの操作に関連する構成と変更は通常短時間で行われ、1回または数回実行されます。 データモデル、外部コンテンツタイプ、外部データリストの作成/編集の完了したブロックの後に、データベース全体のバックアップを実行する方が合理的です。
Managed Metadata Serviceアプリケーションデータベース	フルアクセス	コンテンツをほとんど変更しないディレクトリを使用する場合は簡単です。 定期的に用語セットが変更された場合のフルアクセス（階層ディレクトリのアクティブな作成と編集、リストおよびドキュメントの要素のタグ付け）。
SharePoint Translation Servicesアプリケーションデータベース	フルアクセス	シンプル。
パワーピボットデータベース	フルアクセス	フルアクセス
PerformancePoint Servicesデータベース	フルアクセス	設定がほとんど変更されないインジケーターパネルのセットを使用する場合は簡単です。 インジケーターパネルの集中的な作成/変更の場合のフルアクセス
検索管理データベース	シンプル	シンプル。 このサービスの操作に関連する構成と変更は通常短時間で行われ、1回または数回実行されます。 設定ブロックの完了後、データベースの完全バックアップ、検索スキームの変更を実行する方が合理的です
分析レポートデータベース	シンプル	シンプル、検索結果の分析と検索結果のインテリジェントな適応、検索の提案は重要ではありません。 ポータル検索とその常時パーソナライズされた作業がビジネスにとって重要な場合のフルアクセス
クロールデータベース	シンプル	シンプル。 このデータベースをバックアップから復元するか、回復ウィザードを使用して復元する場合、ほとんどの場合、インデックスをリセットしてコンテンツを完全にクロールするよりもはるかに長くなります。
リンクデータベース	シンプル	単純な、検索結果の分析と検索結果のインテリジェントな適応、検索の提案は重要ではありません。 ポータル検索とその常時パーソナライズされた作業がビジネスにとって重要な場合のフルアクセス
セキュアストアデータベース	フルアクセス	シンプル。 このサービスの操作に関連する構成と変更は通常、短時間で行われ、1回または数回実行されます。 構成ブロックの完了後にデータベース全体のバックアップを実行する方が合理的です。
State Serviceアプリケーションデータベース	フルアクセス	シンプル。 このデータベースは、InfoPathフォーム、Visio Webパーツの一時的な状態のストレージを提供するという事実により、この情報の長期保存を目的としていません。 このデータベースのデータの正確性は、ユーザーがWebパーツを介してInfoPathまたはVisio図の特定のフォームを表示するときに重要です。
使用状況と正常性のデータ収集データベース	シンプル	シンプルまたはフルアクセス。 組織のデータ損失の許容レベルの要件に依存します。
プロファイルデータベース	シンプル	シンプル、ビジネスクリティカルな機能がない場合、その作業にはユーザープロファイルの最も関連性の高いデータを操作する必要がある 状況が逆の場合は、フルアクセス。
プロファイル同期データベース	シンプル	接続の再構成と完全なプロファイル同期の実行よりも復旧時間が短い場合は簡単 状況が逆の場合、フルアクセス
ソーシャルタグデータベース	シンプル	ソーシャルコンテンツを扱うことがビジネスに不可欠な機能でない場合はシンプル 状況が逆の場合、フルアクセス
Word Automation Database	フルアクセス	フルアクセス

ディスク数

理想的には、次のファイルをホストするために、SQLサーバーに6つのディスクを用意することをお勧めします。

1. Tempdbデータベースデータファイル。
2. Tempdbデータベーストランザクションログファイル。
3. SharePointデータベースデータファイル
4. SharePointデータベーストランザクションログファイル
5. オペレーティングシステム
6. 他のアプリケーションのファイル。

ディスクサブシステムの準備

SharePointは、独自のデータストレージ機能を備えたSQLサーバーを使用してデータを保存します。 この点で、これらの機能を考慮して、物理レベルと論理レベルの両方でディスクサブシステムを準備すると、企業ポータルの最終的なパフォーマンスに大きな影響があります。



Microsoft SQL Serverが保存するデータは8 KBページに分割され、ページはいわゆる64 KBエクステントにグループ化されます。 詳細については、 こちらをご覧ください。 これに応じて、ディスクサブシステムの構成は、ディスクサブシステムのすべての物理レベルおよび論理レベルでのエクステントの一貫した配置を確保することです。



最初に開始することは、RAIDの初期化です。 同時に、データベースが配置されるアレイのストライプサイズは64 KBの倍数にする必要があります（できれば正確に64 KBである場合）。

ハードドライブまたはSSDのパーティションの位置合わせ

SQL Serverのパフォーマンスを改善する問題を考慮する場合、ディスクアレイ上の物理的な配置に関してファイルシステムを調整する手順は非常に重要です。 ここで詳細に説明されます 。 ハードディスクまたはSSDでは、512バイトの最初の63セクターは、オペレーティングシステムのインストール中またはディスク管理操作中に作成されたファイルを配置するため、および特別なプログラム（ハードディスクのパーティションマネージャー）を使用するために予約されています。 整列手順の本質は、整数個のファイルシステムクラスターが1つのストリップアレイディスクアレイに収まるように、開始パーティションオフセットを選択することです。 そうしないと、ファイルシステムからデータの1つのクラスターを読み取る操作を実行する状況が発生する可能性があり、ディスクアレイから物理読み取りの2つの操作を実行する必要があり、ディスクサブシステムのパフォーマンスが大幅に低下します（パフォーマンスの損失は最大30％になる可能性があります）。 ソリッドステートドライブの場合、パフォーマンスの損失はわずかに低くなりますが、読み取り/書き込み操作の頻度が増えるため、寿命がすぐに尽きます。



以下の図は、例として64 Kbストライプを使用して、アライメントされていないセクションの読み取り/書き込み操作を実行する機能を反映しています。







以下の図は、例として64 Kbのストライプを使用して、アライメントされたセクションの読み取り/書き込み操作を実行する機能を反映しています。



Windows Server 2008/2012のデフォルトでは、パーティションオフセットは1024 KBであり、64 KB、128 KB、256 KB、512 KB、および1024 KBのディスク上のストライプディスクのサイズとよく相関しています。



ディスクパーティションを管理するためのさまざまなソフトウェアを使用して、イメージからオペレーティングシステムをセットアップする場合、パーティションアライメントの違反に関連する状況が発生する可能性があります。 この点で、追加の保険としてSQLサーバーをインストールする前に、次のセクションで説明する相関関係を再確認することをお勧めします。

重要な相関関係：パーティションオフセット、ファイル割り当てユニットサイズ、ストライプユニットサイズ

パーティションオフセット



ベーシックディスクのパーティションオフセットをチェックする最も正しい方法は、 wmic.exeコマンドラインユーティリティを使用することです 。



wmicパーティションはBlockSize、StartingOffset、Name、Indexを取得します







ダイナミックディスクのパーティションの配置を確認するには、 diskdiag.exeを使用する必要があります（その使用方法の説明については、「 ダイナミックディスクパーティションオフセット 」を参照してください）。



ストライプユニットサイズ



Windowsには、ディスクに書き込むための最小データブロックのサイズ（ストライプユニットサイズ）を決定するための標準ツールはありません。 このパラメーターの値は、ハードドライブに関するベンダーのドキュメントまたはSAN管理者から確認する必要があります。 ほとんどの場合、ストライプユニットサイズインジケーターは、64 Kb、128 Kb、256 Kb、512 Kb、または1024 Kbです。 前に説明した例では、64 Kbの値が使用されました。



ファイル割り当てユニットのサイズ



このインジケーターの値を決定するには、ディスクごとに個別に次のコマンドを使用する必要があります（クラスターあたりのバイト数プロパティの値）。



fsutil fsinfo ntfsinfo c：







データファイルとSQL Serverトランザクションログファイルを格納するパーティションの場合、メトリック値は65.536バイト（64 Kb）である必要があります。 「ファイルシステムレベルでのファイルストレージの最適化」を参照してください。



ディスクI / Oパフォーマンスを最適化するための基礎となる2つの重要な相関関係。 次の式の計算結果は整数でなければなりません。

• Partition_Offset÷Stripe_Unit_Size
• Stripe_Unit_Size÷File_Allocation_Unit_Size

最も重要なのは最初の相関です。



位置合わせされていない値の例。 パーティションオフセットは32.256バイト（31.5 Kb）で、ディスクにデータを書き込むための最小ブロックサイズは65.536バイト（64 Kb）です。 32,256バイト/ 65,536バイト= 0.4921875。 除算の結果は整数ではないため、Partition_OffsetとStripe_Unit_Sizeの値が揃っていません。



パーティションオフセット（パーティションオフセット）が1,048,576バイト（1 Mb）に等しく、データをディスクに書き込むための最小ブロックのサイズが65,536バイト（64 Kb）である場合、除算結果は8-整数です。

ファイルシステムレベルのストレージ最適化

エクステントの最適なストレージを編成する次のレベルは、ファイルシステムです。 ここでの最適な設定は、クラスターサイズが65.536バイト（64 KB）のNTFSファイルシステムです。 この点に関して、SQLサーバーをインストールする前に、ディスクをフォーマットし、クラスターサイズをデフォルトの4096バイト（4K）ではなく65.536バイト（64 KB）に設定することを強くお勧めします。



次のコマンドを使用して、ディスクの現在の値を確認できます。

chkdsk c：



出力例：







提示された例では、クラスターサイズは4096バイト/ 1024 = 4 Kbであり、これは推奨事項に対応していません。 変更するには、ディスクを再フォーマットする必要があります。 クラスタサイズは、Windowsオペレーティングシステムを使用したディスクフォーマットの構成中に設定できます。







その後、クラスターサイズが推奨事項（65536バイト/ 1024 = 64 kb）に準拠していることを確認します。

ディスクの読み取り/書き込み速度のランキング

SQL ServerおよびSharePointデータベースのシステムデータベースファイルの場所を設計する場合、読み取り/書き込み速度に関する情報に基づくランクに基づいたディスクの最適な選択が重要になります。



CrystalDiskMarkに似たソフトウェア（ SQLI Oなど）を使用して、ランダムアクセスファイルおよびシーケンシャルアクセスファイルの読み取り/書き込み速度に関する正確なデータをテストおよび決定できます。 通常、アプリケーションでは、少なくとも次の基本的なテストパラメーターを入力できます。

• テストの数。 より正確な平均値を取得するには、いくつかのテストが必要です。
• テストの実行中に使用されるファイルのサイズ。 キャッシュのみの使用を避けるために、サーバーRAMの量を超える値を設定することをお勧めします。 さらに、取得した数値により、大きなファイルサイズの処理に関する統計を取得できます。これは、コンテンツに関するユーザーの集中的なコラボレーションを行う多くの企業ポータルに関連しています。
• 読み取り/書き込み操作が実行されるディスクの名前。
• 実行するテストのリスト。

以下は、得られたテスト結果の例です。







以下は、実行されたテストの内容の説明です。

• Seq Q32-順次アクセスでのファイルの読み取り/書き込みの速度。 SQLサーバーの場合、これらは、バックアップ、テーブルのスキャン、インデックスの最適化、トランザクションファイルの読み取り/書き込みなどの操作です。
  
  
  
  
• 4K QD32-小さいデータ（4 Kb）で同時に多数のランダムな読み取り/書き込み操作を行う速度。 テスト結果により、高負荷のOLTPサーバーの動作中のトランザクション中のディスクパフォ​​ーマンスを判断できます。
  
  
  
  
• 512K-大きなデータ（4 Kb）で多数の読み取り/書き込み操作を同時に実行する速度。 このテストの結果は、次のように無視できます。 SQLサーバーの操作自体とは関係ありません。
  
  
  
  
• 4K-同時に小さなデータ（4 KB）を使用した少数のランダムな読み取り/書き込み操作の速度。 テスト結果により、OLTPサーバーの動作中のトランザクション中のディスクパフォ​​ーマンスを小さな負荷で判断できます。

テストでは4 KBの記録単位サイズを使用しますが、これはSQLサーバーによる実際のデータストレージスキームと完全には一致せず、64 KBの要素を含む8 KBページで動作します。 実行された場合、取得された結果がSQLサーバーによって実行される同じ操作に関する実際のデータと完全に一致することを保証するという目標はありません。 主な最終目標は、読み取り/書き込み操作の速度でディスクをランク付けし、最終テーブルを取得することです。



SQLサーバーのインストール中に迅速に決定を下し、データベースファイルを配置するためのパラメーターを構成するには、テストの種類ごとに個別にテーブルのテスト結果をフォーマットすると便利です。そのテンプレートを以下に示します。

読み取り/書き込み操作の速度でソートされたディスクを最速から最速まで<テスト名>	割り当てられた名前	大きさ	コメント
0	私：	20GB	VHD固定サイズ
1	H：	20GB	VHD固定サイズ
2	G：	50GB
3	F：	200GB
4	C：	80GB	オペレーティングシステム
5	E：	2TB
6	D：	100GB

CrystalDiskMarkのテスト結果を解釈する方法は？

磁気ディスク（単一またはRAIDの一部）の場合、シーケンシャル操作（Seq Q32テスト）は、他のテストの結果を10x-100x回上回ることがよくあります。 これらのメトリックは、多くの場合、リポジトリへの接続方法に依存します。 ベンダーが主張するMb / sの数は理論上の制限であることを覚えておく必要があります。 実際には、それらは通常、主張されているよりも5〜20％少ないです。



ソリッドステートドライブの場合、シーケンシャルな読み取り操作と任意の読み取り/書き込み操作の速度の差は、互いに大きく異なることはなく、通常は2〜3倍です。 3Gb SATA、1Gb iSCSI、または2 / 4Gb FCなどの接続方法は速度に影響します。



サーバーがローカルディスクから起動し、SQLサーバーデータを別のディスクに保存する場合、これらのディスクの両方をテスト計画に含める必要もあります。 変数が格納されているディスクのCrystalDiskMarkベンチマークテスト結果と、オペレーティングシステムがインストールされているディスクのパフォーマンスのデータの比較は、2番目のパフォーマンスの利点を示しています。 この状況では、システム管理者はディスクまたはSANストレージの設定が正しいことを確認し、最適なパフォーマンスインジケーターを取得する必要があります。

ディスクの優先順位付け

ポータルの目的に関する情報は、SharePointデータベースを保存するディスクの選択に正しく優先順位を付けるために使用されます。



ユーザーが企業ポータルを主にコンテンツの読み取りに使用し、コンテンツのアクティブな毎日の増加がない場合（たとえば、企業の外部Webサイト）、生産性の最も高いディスクをデータストレージに割り当て、生産性の低いディスクをトランザクションログファイルに保存する必要があります：

速度/使用シナリオ	編集よりもコンテンツの表示の優位性が重要です（外部Webサイト）
最高のパフォーマンス	データファイルとTempdbデータベーストランザクションログファイル
...	データベースファイル
...	管理データベースを除く検索サービスデータファイル
最も低い性能	SharePointコンテンツデータベースのトランザクションログファイル

企業ポータルを使用して、毎日多数のドキュメントを積極的にダウンロードするユーザーのコラボレーションを整理する場合、優先順位は異なります。

速度/使用シナリオ	コンテンツの読み取りよりもコンテンツの編集の優位性（外部Webサイト）
最高のパフォーマンス	データファイルとTempdbデータベーストランザクションログファイル
...	SharePointコンテンツデータベースのトランザクションログファイル
...	管理データベースを除く検索サービスデータファイル
最も低い性能	コンテンツデータベースデータファイル

SharePointファームのデータベースドライブの種類に関する考慮事項

tempdbの推奨ディスク

tempdb SQL Serverシステムデータベースの読み取り/書き込み操作の速度が遅いと、SharePointファームの全体的なパフォーマンスに深刻な影響を与え、その結果、企業ポータルのパフォーマンスに影響を与えます。 RAID 10を使用してこのデータベースにファイルを保存することをお勧めします。

頻繁に使用されるコンテンツデータベースの推奨事項を推進する

連携して動作するように、または大量のアップグレード操作を実行するように設計されたサイトでは、SharePointコンテンツデータベースファイルを保存するディスクの選択に特別な注意を払う必要があります。 次の推奨事項を考慮する必要があります。

• コンテンツデータベースのデータファイルとトランザクションログを異なる物理ディスクに配置する
• ポータルソリューションの設計では、コンテンツサイズの増加を考慮してください。 最も最適なのは、各コンテンツベースのサイズを最大200 GBまでサポートすることです。
• 頻繁に使用されるSharePointコンテンツデータベースの場合は、複数のデータファイルを使用して、それらを別々のディスクに配置することをお勧めします。 データベースの突然のシステムクラッシュを避けるために、データベースサイズの制限設定を使用しないことを強くお勧めします。

コンテンツデータベースの予想サイズを計算する

コンテンツデータベースの予想サイズを計算する一般的な式は次のとおりです。



（（D * V）* S）+（10Kb *（L +（V * D）））、ここで：

• D-個人のサイト、ライブラリ内のドキュメントおよびページを考慮したドキュメントの数、来年の増加の予測。
• V-カウント—ドキュメントのバージョン。
• S-文書の平均サイズ（見つけられる場合）;
• 10 Kb-定数、SharePoint 2013で予想される1つのドキュメントのメタデータの数。
• Lは、来年の数の増加の予測を考慮した、リスト項目の予想数です。

追加のストレージコストを考慮する必要があります。

• 監査の実施、監査データの保管時間+監査データの成長予測。
• ごみ箱、サイトバスケット内のデータ保存時間、およびサイトコレクション。

RAIDの推奨事項

RAID 5のパフォーマンスとコストの比率は最高ですが、特にユーザーコラボレーションにエンタープライズポータルを積極的に使用する場合は、SharePointデータベースにRAID 10を使用することを強くお勧めします。 RAID 5のディスクへの書き込み速度はそれほど高くありません。

ネットワークデータの最適化

SQLサーバーとSharePointサーバーの間で高速接続が構成されていることを確認する必要があります。

専用のネットワークアダプターとそのグループ化

2つのネットワークアダプターをインストールすることをお勧めします。1つはSQLとSharePoint間のトラフィックの転送専用で、2つ目はクライアントリクエストとのやり取り専用です。SharePointファームの各サーバーでネットワーク通信パフォーマンスを向上させるための最初のステップとして。



Windows Server 2012に基づいてSQLおよびSharePointサーバーをインストールし、アダプターをグループにグループ化する機能を使用すると、追加の利点が得られ、SharePointの構成設定を最適化する2番目の重要なステップになります。

• ネットワークアダプターのレベルでのフォールトトレランスと、それに応じたネットワークトラフィック。グループネットワークアダプターに障害が発生しても、ネットワーク接続が失われることはなく、サーバーはネットワークトラフィックをワーキンググループアダプターに切り替えます。
• グループ内のアダプターの帯域幅集約。ファイルのコピーなどのネットワーク操作を実行する場合、システムはグループのすべてのアダプターを潜在的に使用できるため、ネットワークとの対話の生産性が向上します。

.



, SharePoint :

• 64- Windows Server 2008 R2 1 (SP1) Standard, Enterprise Datacenter
• 64- Windows Server 2012 Standard Datacenter
• Microsoft SharePoint Server 2013 SharePoint 2013 64- Windows Server 2012 R2 .

Scalable Networking Pack

2007 Windows Server 2003 SP2 , Scalable Networking Pack (SNP). . SNP , Receive Side Scaling (RSS), TCP/IP Chimney Offload ( TOE) Network Direct Memory Access (NetDMA). , TCP/IP .



- SNP Server 2003 SP2 - . Server 2003 . Server 2008, Server 2008 R2 . Server 2008 R2 ( SP1 ). , - , .

Receive Side Scaling

RSS .



RSS, , , . , , , , .



Server 2008 R2 RSS . , , :



netsh interface tcp show global







, RSS :







RSS , TCP Checksum Offload, IP Checksum Offload, Large Send Offload UDP Checksum Offload ( IPv4 IPv6). , , RSS .











, , , RSS, RSS.







RSS . , , .

TCP/IP Chimney Offload

TCP Chimney Offload ( TCP/IP Offloading , — TOE) TCP , TOE. TCP , . TOE TCP/IPv4, TCP/IPv6 , .



- , TCP/IP ( ), TOE , . , , , , , TOE.



, - SharePoint . TCP Chimney Offload.



TCP :



netsh interface tcp show global







TOE TCP :



netsh int tcp set global chimney=disable



TOE TOE TCP :



Netsh netsh interface tcp show chimneystats



IP



netsh int ip set global taskoffload=disable d



IP :



netsh int ip show global

Network Direct Memory Access

NetDMA – . , TOE . NetDMA CPU , CPU .



, NetDMA, , , – Windows Intel I/O Acceleration Technology (I/OAT). NetDMA AMD , , .



, TOE NetDMA , .



NetDMA Windows 2008 R2 :



netsh interface tcp set global netdma=enabled



:



netsh interface tcp show global

SNP

Windows Server 2008 R 2

パラメータ
TCP Chimney Offload	automatic
RSSフィード	enabled
NetDMA	enabled

«Automatic» TCP Chimney Offload , , «TCP Chimney Offload» , 10 GB Ethernet.



Windows Server 2012, Windows Server 2012 R2 2

パラメータ
TTCP Chimney Offload	disable
RSSフィード	enabled
NetDMA	サポートされていません