サービス アーキテクチャの計画 (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事では、サービス アプリケーションを共有するサービス アーキテクチャについて説明し、Microsoft SharePoint Server 2010 のアーキテクチャの例を示します。
この記事の内容:
サービス アプリケーションについて
サービス インフラストラクチャとデザイン原則
複数のファームにサービス アプリケーションを展開する
外部データ ソースにアクセスするサービスの計画に関する考慮事項
アーキテクチャの例
単一ファームの単一サービス アプリケーション グループ
単一ファームの複数サービス アプリケーション グループ
企業サービス ファーム
専用サービス ファーム
組織全体ファーム
サービスのアーキテクチャを計画するときは、以下の質問を考慮してください。
組織ではどのようなサービス アプリケーションが必要とされるか
専用サービス アプリケーションを必要とするチームはあるか
組織に必要なファームはいくつか
複数のファームでサービスを共有できるか
集中管理型のサービス ファームを使用するニーズが組織にあるか
この記事では、次のポスターサイズ モデルも使用できます。
Microsoft SharePoint 2010 製品 のサービス
SharePoint 2010 Products のファーム間サービス
サービス アプリケーションについて
SharePoint Server 2010 には、Web アプリケーション間で共有できる一連のサービスが含まれます。これらのサービスは、サービス アプリケーションと呼ばれます。一部のサービス アプリケーションは、ファーム間で共有できます。Web アプリケーション間およびファーム間でサービス アプリケーションを共有すると、これらのサービスを複数のサイトに提供するのに必要なリソースを大幅に削減できます。
次の表に、SharePoint 2010 Products に含まれるサービス アプリケーションを示します。
サービス アプリケーション |
説明 |
SharePoint Foundation 2010 |
SharePoint Server 2010 Standard |
SharePoint Server 2010 Enterprise |
Access Services |
Web ブラウザーで Access 2010 データベースの表示、編集、および対話形式での操作を行えます。 |
X |
||
Business Data Connectivity service |
基幹業務データ システムへのアクセスを提供します。 |
X |
X |
X |
Excel Services アプリケーション |
Web ブラウザーで Excel 2013 ファイルの表示および対話形式での操作を行えます。 |
X |
||
Managed Metadata Service |
複数のサイト コレクションで分類法の階層、キーワード、およびソーシャル タグ インフラストラクチャを管理し、コンテンツ タイプを発行します。 |
X |
X |
|
PerformancePoint Service アプリケーション |
PerformancePoint の機能を提供します。 |
X |
||
Search Service |
コンテンツのクロール、インデックス パーティションの生成、および検索クエリの実行を行います。 |
X |
X |
|
Secure Store Service |
複数のアプリケーションまたはサービスにアクセスするシングル サインオン認証を提供します。 |
X |
X |
|
State Service |
SharePoint Server コンポーネントのユーザー セッション データを一時的に格納する記憶域を提供します。 |
X |
X |
|
Usage and Health Data Collection Service |
ファームレベルの利用状況と正常性に関するデータを収集し、各種の利用状況と正常性のレポートを表示できます。 |
X |
X |
X |
User Profile Service |
個人用サイト、プロファイル ページ、ソーシャル タグ、およびその他のソーシャル コンピューティング機能のサポートを追加します。 |
X |
X |
|
Visio Graphics Service |
発行済みの Visio 2013 ダイアグラムを Web ブラウザー上で表示および更新します。 |
X |
||
Web Analytics Service |
Web サービス インターフェイスを提供します。 |
X |
X |
|
Word Automation Services |
ドキュメントの一括自動変換を実行します。 |
X |
X |
|
Microsoft SharePoint Foundation Subscription Settings Service |
サービス アプリケーションのマルチテナント機能を提供します。パーティション分割モードで展開されたサービスの購読 ID と設定を追跡します。展開には Windows PowerShell を使用する必要があります。 |
X |
X |
X |
次の表に示すサービスを含め、一部のサービスは他の Microsoft 製品によって提供されます。
サービス アプリケーション |
説明 |
Office Web Apps サービス:
|
Office Web Apps は、Microsoft Office 2010 スイートの新しい Web ベース版です。Microsoft Word 2010、Microsoft Excel 2010、Microsoft PowerPoint 2010、および Microsoft OneNote 2010 のそれぞれに対応した Office Web Apps サービスがあります。Web ベースのこれらのアプリケーションはスタンドアロン アプリケーションであり、複数のプラットフォームの任意のブラウザーから Word 2010、PowerPoint 2010、Excel 2010、および OneNote 2010 の各ドキュメントにアクセスでき、標準形式での軽量な作成と編集の機能、ブラウザーを介するドキュメントの共有とコラボレーション、および多様な Web 対応シナリオがサポートされます。Office Web Apps で作成されたドキュメントと、対応するデスクトップ アプリケーションで作成されたドキュメントの間に違いはありません。対応するサービスは、ドキュメントを Web ブラウザーで表示および編集できるように準備するために使用されます。 |
Microsoft Project Server 2010 |
Microsoft Project Server 2010 は、1 つ以上の Microsoft Project Web Access インスタンスをホストし、Microsoft Project データ用のスケジュール機能とその他のミドル層計算を公開し、Office Project 2010 データを対話形式で操作する Web サービスを公開します。 |
サービス アプリケーションと、個々のサーバーで開始/停止され、SharePoint サーバーの全体管理 Web サイトの [サーバーのサービス] ページにリストされるサービスとは異なります。このページにリストされるサービスの中にはアプリケーションに関連付けられているものがありますが、サービス アプリケーションはサービスの個別インスタンスを表しており、それぞれ特定の方法で構成し共有できます。
サービス インフラストラクチャとデザイン原則
SharePoint 2010 Products では、前のバージョンで導入されたサービス インフラストラクチャが改良されています。SharePoint 2010 Products では、サービスをホストするインフラストラクチャが SharePoint Foundation 2010 内に移されたので、サービス内容を以前よりずっと柔軟に構成できます。各サービスを個別に構成でき、サード パーティがサービスをプラットフォームに追加することもできます。
サービスの共有は、SharePoint Server に限定された機能ではなくなり、共有サービス プロバイダー (SSP) にも含まれなくなりました。
サービスの展開
以下の方法のうちの 1 つを使用して、サービス アプリケーションをファーム内に展開します。
SharePoint 製品構成ウィザードを実行するときにサービスを選択します。
サーバーの全体管理 Web サイトの [サービス アプリケーションの管理] ページで、サービスを 1 つずつ追加します。
Windows PowerShell を使用します。
サービスのきめ細かな構成
サービス インフラストラクチャが更新され、展開するサービスとサービス アプリケーションを共有する方法を、より厳密に制御できるようになりました。
必要なサービス アプリケーションだけをファームに展開できます。
展開された全部のサービスではなく、必要なサービス アプリケーションだけを使用するように、Web アプリケーションを構成できます。
同じサービスの複数のインスタンスを 1 つのファームに展開して、結果として得られるサービス アプリケーションのそれぞれに固有の名前を割り当てることができます。
サービス アプリケーションは、同じファーム内にある複数の Web アプリケーション間で共有できます。
Web アプリケーションを作成するときに、その Web アプリケーションのサービス アプリケーションを選択できます。Web アプリケーションに関連付けたサービス アプリケーションを後で変更することもできます。
サービス アプリケーション グループ
既定では、すべてのサービス アプリケーションが既定のグループに含まれます。ただし、サービス アプリケーションの作成時にこの設定を変更した場合は別です。既定のグループに対してサービス アプリケーションをいつでも追加/削除できます。
Web アプリケーションの作成時には、既定のグループを選択することも、サービス アプリケーションのカスタム グループを作成することもできます。サービス アプリケーションのカスタム グループを作成するときは、その Web アプリケーションで使用するサービス アプリケーションだけを選択します。
次のスクリーン ショットは、Web アプリケーションの作成時に [カスタム] を選択した場合にサンプル ファームで選択可能なサービス アプリケーションの一覧を示しています。この画像には、先頭部分の少数のサービス アプリケーションだけが見えています。
.png "既定のサービス グループを選択するか、新規に作成する")
サーバーの全体管理で作成されるカスタム グループは、複数の Web アプリケーションで再利用することはできません。Web アプリケーションの作成時に [カスタム] を選択した場合、その Web アプリケーションに適用するサービス アプリケーションだけを選択します。
論理アーキテクチャ
サービス アプリケーションは、単一のインターネット インフォメーション サービス (IIS) Web サイト内に展開されます。これは既定の動作であり、変更できません。ただし、サービス アプリケーション グループの構成および Web アプリケーションとサービス アプリケーション グループとの関連付けをカスタマイズすることはできます。
次の図は、一般的なファーム展開の論理アーキテクチャを示しています。
.gif "Web アプリケーションがカスタムまたは既定のサービス グループに接続する")
この図に示してあるファームの以下の特性に注目してください。
すべてのサービス アプリケーションが同じ IIS Web サイト内に含まれます。
サービス アプリケーションには、既定のグループとカスタム グループの 2 種類のグループがあります。すべてのサービス アプリケーションが既定のグループに含まれるわけではありません。前の図では、サービス アプリケーション F は既定のグループに含まれません。このサービス アプリケーションは 1 つの Web アプリケーションでのみ使用されます。
Web アプリケーションは既定のグループまたはカスタム グループのサービス アプリケーションに接続します。この図にはカスタム グループが 1 つあります。
サービス アプリケーションを別々のアプリケーション プールに分けて展開すれば、プロセス分離を実現できます。ただし、ファームのパフォーマンスを最適化を重視するなら、サービス アプリケーションを 1 つのアプリケーション プールに展開することをお勧めします。
サービス アプリケーションを物理的に分離するには、次の図のように、サービス アプリケーションごとに異なるアプリケーション プールを選択または作成します。
.gif "サービス アプリケーションが独自のアプリケーション プールを保持できる")
サービス アプリケーションの接続
サービス アプリケーションを作成すると、そのサービス アプリケーションの接続が同時に作成されます。接続とは、Web アプリケーションとサービス アプリケーションを接続する仮想的なエンティティです。Windows PowerShell では、これらの接続を "プロキシ" と呼びます。プロキシは、サーバーの全体管理の [サービス アプリケーションの管理] ページに、接続の種類についての説明の最後に表示されます。一部の接続には、変更可能な設定があります。たとえば、Managed Metadata Service アプリケーション用の接続には、用語ストア管理者、既定の言語の設定があります。
サービス アプリケーションの管理
サービス アプリケーションは、サーバーの全体管理で直接管理されます。別の管理サイトで管理されるわけではありません。必要なら、サービス アプリケーションをリモートから監視し管理することもできます。また、Windows PowerShell を使用して、サービス アプリケーションを管理しスクリプト処理することもできます。
複数のファームにサービス アプリケーションを展開する
一部のサービス アプリケーションは、複数のサーバー ファーム間で共有できます。それ以外のサービス アプリケーションは、単一サーバー ファーム内でのみ共有できます。
次の図に、ファーム間で共有できるサービス アプリケーションと、単一ファームに限定されるサービス アプリケーションを示します。
.gif "一部のサービス アプリケーションを複数のファーム間で共有できる")
設計ガイダンス
次のガイダンスは、ファーム間で共有されるサービス アプリケーションについて適用されます。
ファーム間での共有に対応しているサービス アプリケーションは、中央ファームで実行され、他のファームから使用できます。
Web アプリケーションを個別に構成すると、別のファームにあるサービス アプリケーションを使用できます。たとえば、User Profile Service を複数のサーバー ファームにある Web アプリケーション間で共有すると同時に、Business Data Connectivity Service のようなサービス アプリケーションをローカルで使用するように構成できます。
大規模な環境では、コンピューティング リソースを大量に消費するサービス アプリケーションを中央ファームで実行すると、管理のオーバーヘッドを最小限に抑え、要件の拡大に伴って効率よく簡単にスケール アウトできます。詳細については、後の「企業サービス ファーム」を参照してください。
WAN 環境
いくつかのクロスファーム アプリケーション サービスは、ワイド エリア ネットワーク (WAN) 環境で使用することが推奨されません。以下の表は、これらの環境で、サービス アプリケーションを展開する際の、現時点での推奨事項を示します。
| サービス アプリケーション | WAN 環境での使用が推奨されるか | メモ |
|---|---|---|
Search |
はい |
|
Managed Metadata |
はい |
|
Business Data Connectivity |
Business Data Connectivity 環境に依存 |
データキャッシュが作成された後、WAN リンクは不要です。初回のページ表示は遅く、タイムアウトすることがあります。それ以降の、キャッシュされたデータの要求への反応はより速くなります。 |
User Profile |
サポートされていない |
現在、複数の WAN リンク間で User Profile Service アプリケーションを使用することはサポートされません。このサービスは直接的なデータベース アクセスを必要とします。このような WAN 環境では、User Profile Replication Engine (UPRE) が推奨されます。 |
Secure Store Service |
いいえ |
Secure Store Service は複数 WAN リンク間で使用できますが、WAN リンク上のその他のサービスのパフォーマンスを低下させることがあることから、推奨されません。 |
Web Analytics |
いいえ |
WAN 環境でサービス アプリケーションを展開する方法の詳細については、「SharePoint 2010 製品のグローバル ソリューション (モデル)」を参照してください。
ファーム間サービスを展開する
サービス アプリケーションをファーム間で共有するには、次の手順を行う必要があります。
ファームの設定を構成します。
ファームが証明書を交換して互いに信頼関係を確立するようにします。ファーム間サービスに接続する前に、証明書をファイルにエクスポートし、そのファイルをバックアップしてください。
サービス アプリケーションを発行します。
サービス アプリケーションをファーム間で共有するには、最初にサービスを発行します。
ファーム間サービス アプリケーションに接続します。
リモート ファームから発行されたサービスを使用するには、そのサービスへの接続を作成します。このプロセスでは、発行済みサービスの URL (発行プロセス中に表示される) を入力する必要があります。ローカル ファーム上の接続が、リモート ファーム上のサービス アプリケーションに接続するために作成されます。
サーバー ファームが 2 つのドメインに存在する場合、User Profile Service アプリケーションが動作するには両方のドメインに相互の信頼関係が成立している必要があります。Business Data Connectivity Service および Secure Store Service アプリケーションの管理機能は使用側ファームから操作されるので、発行元ファームのドメインが使用側ファームを信頼している必要があります。他のファーム間サービス アプリケーションは、ドメイン間の信頼関係がなくても機能します。
ファーム間で使用するためにサービスを構成する方法については、「リモート ファーム上のサービス アプリケーションに接続する (SharePoint Server 2010)」を参照してください。
外部データ ソースにアクセスするサービスの計画に関する考慮事項
一部のサービス アプリケーションは、外部データ ソースにアクセスできます。委任された Windows ID を使用して外部データ ソースにアクセスするサービス アプリケーションでは、環境に対して追加の要件が加わります。これらのサービス アプリケーションでは、サービス アプリケーションの存在する SharePoint Server 2010 ファームと同じドメイン内に外部データ ソースが存在するか、またはサービス アプリケーションが Secure Store Service を使用するように構成されている必要があります。
次のサービス アプリケーションは、委任された Windows ID を使用して外部データ ソースにアクセスします。
Excel Services
PerformancePoint Services
InfoPath Forms Services
Visio Services
委任された Windows ID を使用して外部データ ソースにアクセスするサービス アプリケーションは、1 つの選択肢として、Secure Store Service を使用するように構成することができます。Secure Store Service は、ユーザーまたはサービスの資格情報を格納および保持します。サービス アプリケーションは、格納された資格情報を使用してデータ ソースへの認証を直接行うことができます。
Secure Store Service が使用されておらず、外部データ ソースが同じドメイン内に存在しない場合は、外部データ ソースに対する認証が失敗します。ファーム サーバーが 2 つのドメインに分かれている場合、アプリケーション サーバーは外部データ ソースと同じドメインに存在する必要があります。
次のサービス アプリケーションと製品は、これらの要件の影響を受けません。
Business Data Connectivity Service と Microsoft Business Connectivity Services
Access Services
Microsoft SQL Server PowerPivot for Microsoft SharePoint
Microsoft SQL Server Reporting Services (SSRS)
Microsoft Project Server 2010
アーキテクチャの例
この記事の残りの部分では、一般的な展開シナリオのアーキテクチャ例を示します。
単一ファームの単一サービス アプリケーション グループ
単一ファームと単一サービス アプリケーション グループから成るアーキテクチャでは、既定のサービス アプリケーション グループがファーム内のすべての Web アプリケーションで使用されます。すべてのサイトは、ファームに展開されたすべてのサービス アプリケーションにアクセスできます。
.gif "単一のファーム、単一のサービス グループ")
利点
このアーキテクチャには、以下の利点があります。
最も簡単な展開アーキテクチャです。
すべてのサービス アプリケーションをすべての Web アプリケーションで使用できます。
ファームのリソースが最も効率よく使用されます。
すべてのサービス アプリケーションが集中管理されます。
欠点
このアーキテクチャには、懸念されるいくつかのトレードオフがあります。
サービス アプリケーションのデータを分離できません。
部署またはチームのレベルでサービス アプリケーションを個別に管理できません。
推奨事項
単一ファームと単一サービス アプリケーション グループから成るアーキテクチャは、ほとんどの組織で、少なくとも初期段階では推奨されます。この構成は、同一ファーム上の 1 つの会社の多数のサイトをホストする場合に適切に機能します。
次の目標を達成するには、この構成を使用します。
ファーム内でサービス アプリケーションを実行するために必要なリソースを最適化する場合。
パフォーマンスまたはセキュリティのため、コンテンツとプロファイル データはサイト間で共有し、それ以外についてはプロセスの分離が必要な場合。
単一ファームの複数サービス アプリケーション グループ
チームが専用のサービス アプリケーションを必要とする場合、サービス アプリケーションの 1 つ以上のカスタム グループを作成してアーキテクチャを構築します。次のガイドラインに従ってください。
特定のサービス アプリケーションを組織の 1 つ以上のチームで専用に使用するために展開します。
専用サービス アプリケーションが既定のグループに含まれないことを確認します。
サービス アプリケーションのグループを使用する 1 つ以上の Web アプリケーションを作成します。SharePoint 管理者は、カスタム グループに含まれるサービス アプリケーションを選択します。
次の図では、ファーム B はサービス アプリケーションの 2 つのグループがあるアーキテクチャの例を示しています。この例では、財務チームが専用 Excel Services アプリケーションを必要としています。Access Services もこのチーム用に展開されます。
.gif "単一のファーム、複数のサービス グループ")
1 つ以上のカスタム サービス アプリケーション グループを作成できます。次の図では、ファーム C に 2 つのカスタム グループを作成します。ファーム B のアーキテクチャを基盤として、専用の Managed Metadata Service および Business Data Connectivity Service アプリケーションを人事部門で使用するためにファームに展開します。その結果、財務チーム用に作成した最初の専用サービス アプリケーション グループに加えて、第 2 のカスタム サービス アプリケーション グループが作成されます。
.gif "単一のファーム、複数のカスタム サービス グループ")
専用サービス アプリケーションとして展開されたサービス アプリケーションは、同じアプリケーション プールを共有するか、さらに分離するために別のアプリケーション プールに展開できます。ファーム B の設計 (2 つ前の図) では、財務チーム用に展開したサービス アプリケーションのプロセス分離を提供するために、これらのサービス アプリケーションを専用のアプリケーション プールに配置します。前の図に示したファーム C の場合は、1 つのアプリケーション プールがすべてのサービス アプリケーションに使用されます。このアーキテクチャでは、パフォーマンスの最適化を優先してサービス アプリケーションを展開します。
複数の Managed Metadata Service アプリケーションに接続する
サービス アプリケーション グループに複数の Managed Metadata Service アプリケーションを含めることができます。たとえば、ファーム C の図では、緑色の破線で囲まれたカスタム グループに 2 つの Managed Metadata Service アプリケーションが含まれています。
このシナリオでは、Web アプリケーション内のサイトは、両方の Managed Metadata Service アプリケーションの分類法、ソーシャル タグ、およびその他の機能を表示します。他のファーム間サービスとは異なり、既定で Web パーツには複数の Managed Metadata Service アプリケーションのデータが含まれます。
Managed Metadata Service アプリケーションの管理方法については、「メタデータ サービス アプリケーションについて」を参照してください。
利点
複数のサービス アプリケーション グループを含むアーキテクチャには、以下の利点があります。
組織の複数の目標を 1 つのファームで追及できます。
サービス データを分離できます。
チームまたは部署のレベルで、専用のサービス アプリケーションを個別に管理できます。
サービス アプリケーションのサブセットを使用するようにサイトを構成できます。
欠点
複数のサービス アプリケーション グループを使用するアーキテクチャには、以下のトレードオフがあります。
構成および管理が、より複雑になります。
サービス アプリケーションの複数のインスタンスをサポートするためにファームのリソースが消費されるので、パフォーマンスに影響する可能性があります。
推奨事項
複数のサービス アプリケーション グループを含むアーキテクチャは、部署またはチームが専用のサービス アプリケーションまたは分離されたサービス データを必要とする企業や、パートナーとのグループ作業のような狭い範囲で設定されているサイトに適しています。
また、複数のサービス アプリケーション グループが構成されていると、チームおよびサイトは、企業全体に提供されるプロファイル、検索のようなサービスを使用する一方で、対象のサービスをセキュリティやパフォーマンスのために分離できます。
一般に、特定のチームまたは部署で専用に使用するように展開されるのは、次のサービス アプリケーションです。
Excel Services 対象のチームのパフォーマンスを最適化するか、機密性の高いデータを分離します。
Managed Metadata チームまたは部署が独自の分類法、階層、キーワードなどを管理できるようにします。SharePoint Server 2010 では、複数の Managed Metadata Service アプリケーションの結果が結合されるので、分類法、コンテンツ タイプ、およびその他の要素を組織全体で共有できます。
Business Data Connectivity チームまたは部署は、各自の固有の基幹業務データ システムを統合し、データを組織の他の部分から分離できます。
場合によっては、専用のサービス アプリケーション グループを構成して、Web アプリケーションで使用されるサービスを絞り込むこともできます。たとえば、パートナーとのグループ作業用のサイトを構成して、ファームから提供されるサービス アプリケーションのサブセットを使用するように指定できます。
企業サービス ファーム
企業サービス ファームは、組織のホスト サービス アプリケーション専用のサーバー ファームです。次の図に、使用頻度の最も高いファーム間サービス アプリケーションをホストする企業サービス ファームを示します。ここでは、サービスを企業サービス ファームから利用する一般的な種類のファームもいくつか示しています。
.gif "企業サービス ファーム")
以降では、この図の他のファームについて説明します。ファーム 2、3、および 4 は、サービスを企業サービス ファームから使用することが多い種類のファームを表しています。
公開コンテンツのみのファーム (すべてのサービス アプリケーションはリモート)
サービス アプリケーションをローカルに展開せずにサーバー ファームを展開できます。ファーム 2 には、ローカルでホストされるサービス アプリケーションはありません。すべてのサービス アプリケーションは、別のファームから利用されます。
この構成は、公開済みのコンテンツに使用することをお勧めします。公開コンテンツ ファームをホストするために必要な管理タスクが少なくなり、集中管理型のサービス アプリケーションの利点を組織で活用できます。
以下を目標とする場合に、この構成を使用してください。
サービス アプリケーションを実行するのではなく、ファームのリソースをコンテンツのホスト処理用に最適化したい。
組織全体のプロファイル、メタデータ、検索、およびその他の集中管理型リソースとの統合を進めている。
グループ作業ファーム (ローカルおよびリモートのサービス アプリケーションが混在)
ファーム 3 は、グループ作業用に最適化されたファームです。ファーム間で共有できるすべてのサービス アプリケーションは、ローカルにホストされます。グループ作業にとって重要な役割を担うクライアント関連サービス アプリケーションもこれに含まれます。ファーム間サービス アプリケーションは、企業サービス ファームから使用されます (ファーム 1)。
ファームは、複数のリモート ファームからサービスを使用できます。前の図では、ファーム 3 は、部署専用ファーム (ファーム 4) から Managed Metadata Service を使用して、この部署で自律的に管理されている分類法、ソーシャル タグ、およびその他の機能も使用します。
複数の Managed Metadata Service アプリケーションがある場合、サービス アプリケーションの 1 つを、企業の分類法をホストするプライマリ サービス アプリケーションとして指定する必要があります。このサービス アプリケーション以外のすべてのインスタンスはセカンダリであり、プライマリ サービス アプリケーション データへの追加データを提供します。他のファーム間サービスとは異なり、既定で Web パーツには複数の Managed Metadata Service アプリケーションからのデータが含まれます。
この構成は、ビジネス ニーズを満たすために複数のファームをホストする企業で使用することをお勧めします。次の目標を達成するには、この構成を使用します。
サービスをホストするために管理リソースとファーム リソースを企業全体のレベルで最適化する (ファーム 1)。
グループ作業サイトをホストするためにリソースをファーム レベルで最適化する (ファーム 3)。
組織全体でプロファイル、メタデータ、検索、およびその他の集中管理型リソースを統合する。
専門のチームまたは部署で生成されたメタデータを統合する (ファーム 4)。
部署専用ファーム (ローカルとリモートのサービス アプリケーションが混在)
組織内のチームによっては、以下の理由から特定のサービスを個別に展開することが必要とされます。
データを確実に分離する (たとえば Business Data Connectivity データ)。
サービス アプリケーションを自律的に管理する機能を提供する (たとえば Managed Metadata)。
ファーム 4 がこのようなファームの例です。このファームには、以下の特徴があります。
Managed Metadata のような集中管理型サービス アプリケーションを使用します。
独自の Managed Metadata Service アプリケーションも持つので、このチームは固有のメタデータを自律的に管理できます。このサービス アプリケーションは共有されるので、組織の他の部分に含まれるメタデータもこのメタデータに統合されます。
次の目標を達成するには、この構成を使用します。
専門のチームまたは部署が各自でメタデータを管理できるようにする。
特定のサービス データを組織の他の部分から分離して別個に管理する。
専用サービス ファーム
特定のサービス アプリケーション用にファーム リソースを最適化する場合は、専用サービス ファームを展開することをお勧めします。これにより、特定のサービス アプリケーションのパフォーマンスを最適化するためにサーバー ファームをスケール アウトし、ハードウェアをスケール アップできます。
専用サービス ファームに適したプライマリ サービス アプリケーションは Search です。Search には、特有のパフォーマンスと容量の要件があります。Search Service アプリケーションの負荷を専用ファームに移すことで、リソースを残りのファーム間サービス アプリケーション用に最適化できます。
次の図に、2 つの集中型のサービス ファームを示します。一方のファームは Search 用に最適化されています。もう一方は、その他のすべてのファーム間サービス アプリケーションをホストするファームです。
.gif "2 つの集中管理型ファーム: 1 つは検索用に最適化済み")
組織全体ファーム
サービス アプリケーションは、企業サービス ファームだけでなく、どのファームでも共有できます。ファーム間でサービス アプリケーションを共有することは、以下のシナリオの場合にお勧めします。
シナリオ A: 専用の企業サービス ファームを使用せずに企業全体にサービス アプリケーションを提供します (以下の図を参照)。
.gif "企業全体サービスを提供する")
シナリオ B: ファーム間でリソースを共有し、冗長なサービス アプリケーションの展開を回避します (以下の図を参照)。
.gif "冗長なサービスを展開しない")
See Also
Other Resources
Resource Center: Architecture Design for SharePoint Server 2010 (英語)
Resource Center: Security and Authentication for SharePoint Server 2010 (英語)