SSP のアーキテクチャを計画する

ここでは、共有サービス プロバイダ (SSP) について説明し、Microsoft Office SharePoint Server 2007 での SSP 用の総合的なソリューション設計のアーキテクチャに SSP を組み込む方法の例を示します。

この記事の内容:

• SSP について

• ソリューション設計への SSP の組み込み

• 単一ファーム SSP の例

• ファーム間環境用の SSP の計画

• ファーム間 SSP の例

• SSP に関する容量計画

• SSP の管理者ロールの計画

この記事では、次のポスターサイズ モデルも使用できます。

• Office SharePoint Server 2007 の共有サービス (https://go.microsoft.com/fwlink/?linkid=73166&clcid=0x411)

• Office SharePoint Server 2007 ファーム間共有サービス (https://go.microsoft.com/fwlink/?linkid=73155&clcid=0x411)

SSP について

Office SharePoint Server 2007 には、Office SharePoint Server Web アプリケーション間で共有できる一連のサービスが含まれます。これらのサービスは、SSP に格納されており、SSP によって提供されます。共有サービスを使用することで、これらのサービスを複数のサイト間で提供するために必要なリソースを大幅に減らすことができます。既定では、これらのサービスは、単一の SSP によってサーバー ファーム内のすべてのサイト間で共有されます。

次の表は、SSP によって提供されるサービスの一覧です。

共有サービス	説明
個人用設定サービス	ディレクトリ サービスからインポートしたデータに基づくユーザー プロファイル、SSP 内のすべてのユーザーが共有でき、プライバシー ポリシーで管理される、個人情報を含む個人用サイト、および対象ユーザーごとのコンテンツ配信、Office クライアント アプリケーション、または個人用設定サイト リンクを提供します。
ビジネス データ カタログ	基幹業務アプリケーションに格納されたデータに対して単一の統合スキーマを提供します。
Excel Services	共有ワークシート、およびダッシュボード ページのレポートを使用してデータ接続ライブラリからのビジネス データを分析する手段を提供します。
Office SharePoint Server Search	SSP を使用して Web アプリケーションのすべてのサイトをクロールし、すべてのコンテンツ、データ、メタデータを含む 1 つのインデックスを作成します。
ポータルおよび検索利用状況レポート	共有サービス管理者がサイト階層全体のサイトの利用状況に関する集約された情報を表示できるようにします。共有サービス管理者は、個別のサイトとサイト コレクションの管理者に対して利用状況レポートを有効にすることもできます。
Project Server	このサービスは、Microsoft Office Project Server 2007 がファームにインストールされている場合に使用できます。1 つ以上の Project Web Access インスタンスをホストし、Office Project データ上でのスケジュール機能およびその他の中間層計算を公開し、Office Project データを対話的に操作する Web サービスを公開します。Project Web Access インスタンスを作成して、この共有サービスを使用する Web アプリケーションのエンド ユーザーに Office Project Server 機能を公開します。

ソリューション設計への SSP の組み込み

ファームを初めてインストールする時に、最初のセットアップ後のタスクの 1 つとして既定の SSP を作成します。SSP は次のように機能します。

• 各 SSP には、利用可能な (インストール済みの) 共有サービスがすべて含まれています。

• ユーザーが、SSP と特定の Office SharePoint Server Web アプリケーションを関連付けます。

• 1 つの Web アプリケーションと関連付けることができる SSP は 1 つのみです。

• 1 つの Web アプリケーション内のサイト コレクションとサイトはすべて、同じ SSP のサービスを使用します。

追加 SSP の作成

ソリューションの要件に基づき、必要に応じて、追加の SSP を作成できます。SSP を分離することで、プロファイル、コンテンツ、および検索結果のプロセスを分離できます。プロセスの分離は、次の方法で実現できます。

• 各 SSP を、個別の IIS アプリケーション プールに配置します。

• 各 SSP で一意のサービス アカウント セットを使用し、SSP で提供されるサービス (検索、コンテンツ クロール、プロファイルのインポートなど) を実行します。

論理アーキテクチャ内の SSP の数を決定する最も重要な要素は、次のとおりです。

• 異なる Web アプリケーションおよび IIS アプリケーション プールに存在するサイト間で、コンテンツおよびプロファイル データを共有する必要があるかどうか。たとえば、イントラネット間で個人用サイト、チーム サイト、および公開コンテンツを共有する場合は、これらのサイトを 1 つの SSP 下に配置できます。

• コンテンツおよび対象ユーザーを、特定のサイトに分離する必要があるかどうか。たとえば、サーバー ファームで複数のユーザー クラス用アプリケーションをホストする場合は、個別の SSP を使用することにより、それらのクラスを分離できます。

既定では、新しく作成した Web アプリケーションは、既定の SSP と関連付けられます。Web アプリケーションを別の SSP と関連付ける場合は、手動で関連付けを変更する必要があります。

次の図は、2 つの SSP を含むサーバー ファームの論理アーキテクチャを示しています。

図には示されていませんが、単一のアプリケーション プール内の複数の Web アプリケーションが、異なる SSP のサービスを利用してもかまいません。たとえば、前の図で、Application Pool A 内の 2 つの Web アプリケーションが異なる SSP の共有サービスを利用することは、技術的には制限されません。ただし、通常、同じアプリケーション プールにグループ化されている Web アプリケーションでは、分離およびセキュリティの要件は似ているので、同じ SSP のサービスを利用する方が普通です。

SSP のアーキテクチャ

各 SSP は、次の 3 種類の共有サービス リソースを使用します。

• データベース (SSP データベース、検索データベース)

• 共有サービス管理サイト (サイトのコンテンツ データベースを含む)

• Web サービスをホストしているサイト (SSP の共有 Web サービスをホストする IIS Web サイト)

SSP データベースには、次の種類のデータが含まれます。

• SSP 構成データおよびサイト使用状況データ

• ユーザー プロファイルおよび対象ユーザー データ

• ビジネス データ カタログ メタデータ

各 SSP には、検索に関連するすべての構成およびデータを含む検索データベースも含まれます。

次の図はファームの論理アーキテクチャであり、SSP が使用するファーム リソースを強調して示してあります。

単一ファーム SSP の例

ここでは、単一のファームに SSP を組み込むためのアーキテクチャの例、および計画に関する追加の推奨事項を示します。

例 1: 単一ファーム、単一 SSP

単一の SSP は、1 つのファームで多数のサイトをホストする組織で問題なく動作します。

説明

単一の SSP をファーム全体で使用します。

• すべてのサイトが、同じ共有サービスのセットを使用します。

• すべてのサイトを単一の Web アプリケーション内に作成することも、複数の Web アプリケーションに作成することもできます (図)。

• 複数の Web アプリケーションを、同じアプリケーション プールと関連付けることも (図)、異なるアプリケーション プールと関連付けることもできます。

推奨事項

これは、ほとんどの会社に推奨される構成です。次の場合にこの構成を使用します。

• ファーム内で共有サービスを実行するために必要なリソースを最適化したい場合。

• ファームが、Web アプリケーションの分離を必要としない場合。

例 2: 単一ファーム、複数 SSP

場合によっては、追加の SSP を実装することで満たすことのできる分離要件があります。

説明

複数の SSP を使用することで、共有と分離の両方の目標が向上します。

• 単一の SSP が、複数の Web アプリケーションに分散するサイトにサービスを提供します。この戦略を使用すると、コンテンツとサービスを共有しながら、異なる Web アプリケーションに存在するサイト間のプロセス分離を維持できます。

• 対象となるサイトに専用の SSP を使用することで、プロセス、コンテンツ、およびサービスの分離を実現します。

推奨事項

この構成は次のようなシナリオで推奨されます。

• パフォーマンスまたはセキュリティのため、コンテンツとプロファイル データはサイト間で共有し、それ以外についてはプロセスの分離が必要な場合。

• 企業内のグループや部門で、セキュリティによって保護されて分離されたデータが必要な場合。

• パートナーによる外部アクセス用のサイトを、内部のグループ作業サイトと同じファームでホストする場合。

例 3: 単一ファームでのホスト

複数の顧客または部門を同じファームでホストし、データの分離は顧客ごとに専用の SSP を使用することで実現できます。また、専用の SSP を使用すると、サービスの所有権や構成を特定の組織に委任することもできます。たとえば、検索構成またはプロファイル データの所有権を必要とする部門に対して、専用の SSP を構成できます。

説明

単一のファーム内のサービスを分離するには、複数の SSP を使用します。

• 各企業または部門は、専用の SSP を受け取ります。

• 異なるアプリケーション プールを使用して個別の部門または企業をホストすると、(共有サービスの分離に加えて) アプリケーション プール レベルでプロセスを分離できます。

• 1 つのアプリケーション プールには、1 つまたは複数の Web アプリケーションを入れることができます。

• 共有サービスの管理は、SSP がサービスを提供する対象の組織に委任できます。

推奨事項

この構成は次のようなシナリオで推奨されます。

• 複数の企業または単一の組織内の独立した複数の部門に対するサイトをホストする場合。

• 複数の Web アプリケーションまたはアプリケーション プールを使用することで、さらにコンテンツを分離したり、パフォーマンスを最適化したりできるように、各企業または各部門に柔軟性を提供する場合。

• サービスの管理を委任する場合。

• 大量のデータに対応する場合。単一 SSP の検索サービスが対応できるデータの量に適用される容量のガイドラインがいくつかあります。たとえば、単一の SSP によってインデックスを作成されるドキュメントの数は、50,000,000 に制限することが推奨されます。容量ガイドラインの詳細については、後の「SSP に関する容量計画」を参照してください。

例 4: 複数のファームでのホスト

場合によっては、プロセスの分離に加えて、データの物理的な分離が必要になります。そのような組織では、異なるファームが解決策になる可能性があります。

さらに、組織によっては、前に示した例 2 と同様に、複数の SSP がファームで必要になることもあります。

説明

複数のファームを使用して、次のように部門または会社間を物理的に分離します。

• 各部門または企業は、専用のファームと SSP を受け取ります。

• すべてのハードウェアは、部門または会社ごとの専用になります。

• 各ファームは完全に分離され、ポータル間のデータ アクセスは不可能になります。

推奨事項

この構成は次のようなシナリオで推奨されます。

• ハードウェア、データ、またはアプリケーションの物理的な分離を必要とする、1 つの組織内の複数の部門を分離する場合。

• 複数の企業に対する SharePoint サイトをホストし、以下の目的で物理的な分離が必要な場合。

  • リソースの使用率を追跡する

  • アプリケーションとデータをセキュリティで保護する

  • パフォーマンスを最適化する

  • ライセンスの要件を満たす

SSP の計画に関するその他の推奨事項

SSP の構成には、2 つの目的があります。1 つ目は複数の Web アプリケーション間で情報の共有を促進すること、2 つ目は単一の Web アプリケーション内でコンテンツをさらに分離することです。 たとえば、異なる Web アプリケーションおよびアプリケーション プールに存在するサイトを 1 つの SSP に統合し、イントラネット全体でコンテンツとプロファイルを共有できます。これにより、多数のサイトおよびアプリケーション間で、個人用設定および企業全体の検索が可能になります。この構成は、(異なる Web アプリケーションとアプリケーション プールの実装による) プロセス分離と、アプリケーション間で情報を共有したい、プロファイル データを活用したいというビジネス ニーズとのバランスをとる例です。

SSP を構成することで、全体的な分離を実現することもできます。たとえば、パートナーのサイトに専用の SSP を使用することで、パートナーのユーザーが環境内の他のサイトを検索またはアクセスすることを防ぐことができます。次の方法で SSP を構成し、サイト コレクション間でコンテンツをさらに分離できます。

• 検索範囲を個別のサイト コレクションに制限します。

• 対象ユーザーを使用して、コンテンツの対象を特定のユーザー グループに限定します。

• Stsadm コマンド ライン ツールを使用して、サイト コレクションのメンバであるユーザーだけを表示するように、ユーザー選択ウィンドウを構成します。

SSP 戦略を計画するときは、全体的なコンテンツの共有または分離を実現するために、各サービスを 1 つの SSP 内で構成できる方法を検討してください。このような戦略の例については、「論理アーキテクチャ モデル : 企業展開」の設計サンプルを参照してください。

ファーム間環境用の SSP の計画

複数の Office SharePoint Server 2007 ファームにサービスを提供するように、単一の SSP を構成できます。1 つの SSP を複数のファームで使用すると、サービスを集中管理することができ、同じロールを提供するサービスの数を減らすこともできます。また、サービスの提供に必要なハードウェアと他のリソースの量を大幅に減らすこともできます。

この後のガイダンスは、次の図を基にして説明します。この図では、それぞれが異なる目的に構成されている 3 つの子ファームとサービスを共有する親ファームが示されています。各子ファームについては後で説明します。

親ファームと子ファーム

親ファームを使用して、1 つ以上の子ファームにファーム間共有サービスを提供します。

• 親ファームは、他の子ファームに共有サービスを提供するように構成します。

• 子ファームは、親ファームの共有サービスを使用するように構成します。

• 1 つのファームが親ファームと子ファームの両方になることはできません。

• ファーム間共有サービスに参加できる SSP は、ファームごとに 1 つだけです。

  • 親ファームが子ファームと共有できる SSP は 1 つだけです。ただし、親ファームは、自身が使用するために、複数の SSP を含むことができます (前の図の Parent Farm を参照)。

  • 子ファームは、1 つの親 SSP のサービスのみを使用できます。ただし、子ファームは、自身が使用するために、複数の SSP を提供できます (前の図の Child Farm 2 を参照)。

ファーム間 SSP とスタンドアロン SSP の切り替え

子ファームでの共有サービスの使用は、いつでも再構成できます。

• 子ファームは、親ファームとの関連付けを解除し、別の親ファームの共有サービスを使用するように、または自身のローカルな SSP を使用するように構成できます。

• 子ファームでは、中央のネットワークに接続しているときには親ファームの共有サービスを使用し、接続していないときには自身のローカル SSP サービスを使用するように切り替えることができます。Child Farm 3 (前の図) では、ファームの接続が切断されたときに使用されるローカルなスタンバイ SSP を含むファームが示されています。

• 親ファームは、いつでもスタンドアロン ファームとして再構成できます。親ファームの管理者は、SSP をスタンドアロン SSP として再構成する前に、影響を受ける子ファームの子ファーム管理者に通知する必要があります。

ファーム間 SSP の制限事項

ファーム間共有サービスには次のような制限があります。

• 親ファームと子ファームが異なるドメインまたはフォレストに存在している場合は、ドメイン間またはフォレスト間で信頼関係が構成されている必要があります。また、2 つのファームが別のフォレストに存在している場合は、個々のフォレストと信頼されたフォレストとの間の Active Directory レプリケーションが正しく動作している必要があります。

• ファーム間 SSP は、WAN 経由ではサポートされていません。2 つのファームが WAN リンクによって分離されている場合、子ファームを親ファームの SSP に関連付けることはできません。

• 親ファームには、子ファームで使用されるすべての Office サーバー製品をインストールする必要があります。たとえば、子ファームに Office Project Server が含まれている場合、共有サービスが正しく機能するには、親ファームにも Office Project Server をインストールする必要があります。子ファームが Client Access License (CAL) の Enterprise Edition を使用している場合は、親ファームでも、Standard Edition ではなく Enterprise Edition の CAL を使用する必要があります。この設計要件に対する 1 つの例外は Excel Services サービスです。

• Excel Services サービスは、親ファームの SSP では提供できず、子ファームのローカルな SSP で提供する必要があります。Web アプリケーションは、Excel Services だけはローカルな SSP のものを使用し、それ以外のすべてのサービスは親ファームのものを使用するように構成できます。Web アプリケーションが 2 つの異なる SSP のサービスを使用できるのは、この場合だけです。このシナリオの図については、後の「ファーム間 SSP とローカル SSP の組み合わせ (Child Farm 2)」を参照してください。

ファーム間 SSP 構成のスクリプト

スクリプトを作成して、子ファームを親ファームに関連付けるために必要な手動処理を複製できます。セットアップ処理をスクリプトにすると、次のような利点があります。

• 複数のファームに共有サービスを展開するための時間を短縮できます。

• ファーム全体で一貫性のある構成設定 (ディレクトリ、構成、検索インデックスなど) を適用できます。

詳細については、「共有サービス プロバイダ : Stsadm 操作 (Office SharePoint Server)」を参照してください。

ファーム間 SSP の例

ここでは、前の図で示されている 3 つの子ファームについて説明します。

ファーム間共有サービスのみ (Child Farm 1)

説明

Child Farm 1 は、親ファームによってホストされる共有サービスのみを使用します。このシナリオでは、ファーム全体に共有サービスを提供するためのハードウェア、ネットワーク、および管理リソースを最適化できます。既存のファームを親ファームとして指定するか、共有サービスをホストするために専用のファームを作成することができます。

推奨事項

この構成は次のようなシナリオで推奨されます。

• 企業内の複数のファームに共有サービスを提供する場合。

• ファームの分離は必要だが、サービスの分離は必要でない企業用に、Office SharePoint Server ソリューションをホストする場合。

ファーム間 SSP とローカル SSP の組み合わせ (Child Farm 2)

説明

Child Farm 2 は、2 つの異なる SSP のサービスを使用します。

• 親ファームのファーム間共有サービスを使用します。

• 独自の SSP をホストし、その SSP のサービスを使用します。

このような構成のファームは、企業全体の共有サービスを利用できますが、必要に応じて、個別に機能することもできます。子ファームは、ファーム間共有サービスの使用から、自身の共有サービスの使用に切り替えることができます。

ファーム間 SSP とローカル SSP を組み合わせる構成は、子ファームが Excel Services を使用する場合にも必要です。ファームで Excel Services が必要な場合、ファームは共有サービスをローカルにホストする必要があります。次の図に示すように、この構成では、子ファームの Web アプリケーションは、Excel Services はローカル SSP のものを使用し、他のすべてのサービスは親 SSP のものを使用します。

推奨事項

この構成は次のようなシナリオで推奨されます。

• 企業内のある部門で、機密データの保護や物理リソースの専用使用のためにファームを分離する必要があり、同時に、企業全体のポータルおよびサイトに組み込まれる必要もある場合。

• 企業または部門が買収され、ファームを分裂させることなく、企業全体のリソースへのアクセスを提供する場合。このシナリオでは、子ファームは、検索やクロールなど、企業全体で使用可能な共有サービスを利用できます。

• 企業内の部門やグループが売却されたり、別の Office SharePoint Server 環境に割り当てられたりして、ファームを新しい環境に移行する際のステップとして、独立して機能するようにファームを構成する必要がある場合。

• 子ファームで Excel Services が必要な場合。

スタンバイ SSP (Child Farm 3)

説明

Child Farm 3 は、ファーム間共有サービスの使用と、自身の共有サービスの使用を切り替えることができるように構成されています。子ファーム内の SSP が、スタンバイ プロバイダとして機能します。子ファームが親ファームから切断されると、スタンバイ SSP に切り替わります。

推奨事項

一時的に複数の地理的な場所に分散しているファームの展開では、この構成をお勧めします。

SSP に関する容量計画

SSP のアーキテクチャを計画するときは、論理アーキテクチャ要素に推奨されるソフトウェア境界、およびそれが SSP の構成に与える影響について考慮します。

次の表は、論理アーキテクチャ コンポーネントの推奨ガイドラインの一覧です。

論理アーキテクチャ オブジェクト	許容範囲のパフォーマンスを得るためのガイドライン	注
共有サービス プロバイダ (SSP)	ファームあたり 3 (最大ファームあたり 20)
Web アプリケーション	SSP ごとに 99	この制限値には、この SSP のリソースを消費する子ファームの Web アプリケーション数も含まれます。
インターネット インフォメーション サービス (IIS) アプリケーション プール	Web サーバーあたり 8	最大数はハードウェア性能によって異なります。
サイト コレクション	Web アプリケーションあたり 50,000

論理アーキテクチャ コンポーネントに加えて、検索サービスにも、環境内の SSP の数と構成に影響を与える可能性のある推奨されるソフトウェア境界があります。次の表では、特定の検索オブジェクトと、SSP の計画に影響のある推奨される境界を示します。

検索オブジェクト	許容範囲のパフォーマンスを得るためのガイドライン	注
検索インデックス	SSP ごとに 1 つ、ファームごとに最大 20	Office SharePoint Server 2007 では、SSP ごとに 1 つのコンテンツ インデックスがサポートされます。推奨ファームごとの SSP の最大数は 20 なので、最大で 20 のコンテンツ インデックスがサポートされます。 1 つの SSP には、1 台のインデックス サーバーと 1 つのコンテンツ インデックスのみを関連付けることができます。ただし、インデックス サーバーには複数の SSP を関連付けられ、各 SSP に 1 つのコンテンツ インデックスを配置できます。
インデックス付きドキュメント	コンテンツ インデックスごとに 50,000,000 (SSP ごとに 1 インデックス)	Office SharePoint Server 2007 では、インデックス サーバーごとに 5,000 万のドキュメントがサポートされます。これらのドキュメントは、インデックス サーバーに関連付けられている SSP の数に基づいて、複数のコンテンツ インデックスに分けることができます。
コンテンツ ソース	SSP ごとに 500	これはシステムによるハードウェア上の制限です。
通知	SSP ごとに 1,000,000	これは、テストで得られた制限値です。
クロール ルール	SSP ごとに 10,000	種類に関係なく、クロール ルールは最大で 10,000 にすることを推奨します。
クロール対象プロパティ	SSP ごとに 500,000	これらは、クロール中に発見されるプロパティです。
管理プロパティ	SSP ごとに 100,000	これらは、クエリの検索システムによって使用されるプロパティです。クロール対象プロパティは、管理プロパティにマッピングされます。管理プロパティごとに最大 100 のマッピングにすることをお勧めします。

ソフトウェア境界の詳細については、「ソフトウェア境界を計画する (Office SharePoint Server)」を参照してください。

SSP の管理者ロールの計画

Office SharePoint Server 2007 の共有サービス モデルでは、サービス全体をまとめて集中的に管理しながら、必要に応じて特定のサービスの管理を委任できます。次の表では、主要な SSP ロールを示します。

ロール	職責
ファームの管理者	SSP を作成または削除します。
共有サービスの管理者 (共有サービス管理サイト コレクションの管理者)	特定のサービスの権限を構成したり、共有サービスの管理を他のユーザーに割り当てます。
共有サービスの管理者	検索サービスや Excel Services など、特定の共有サービスを構成および管理します。

1 人でこれらすべてのロールを実行できます。ただし、中規模から大規模の組織では、特定のサービスの管理を委任することがよくあります。次の表は、委任できるサービス管理ロールの一覧です。

Web サーバー ロール	責務
検索サービス管理者	SSP 内のすべての検索設定を管理します。
ユーザー プロファイル管理者	インポート接続の追加、ユーザー プロファイルの管理、および個人用サイトの設定の構成を行います。
対象ユーザー管理者	SSP での対象ユーザーの設定を管理します。
ビジネス データ カタログの管理者	ビジネス データ カタログにアプリケーション定義をインポートし、SharePoint サイトおよびリストで使用するエンティティとプロパティを選択し、必要に応じてエンティティ インスタンスに対してメソッドを実行します。
ビジネス データ カタログの権限管理者	ビジネス データ カタログの権限を管理します。
プロファイル サービスの権限管理者	プロファイル サービスの権限を管理します。
Excel Services 管理者	SSP でのすべての Excel Services の設定を管理します。
利用状況レポート管理者	SSP での利用状況レポートの設定を管理します。

これらのロールおよびその構成方法の詳細については、「セキュリティ ロールを計画する (Office SharePoint Server)」を参照してください。

ファーム間 SSP の管理

ファーム間共有サービスが実装されている環境では、ファーム管理者の責務は、ファームが親ファームか子ファームかによって異なります。次の図は、ファーム間 SSP 環境で各管理者が実行する管理タスクをまとめたものです。

ファームの管理者	責務
親ファーム管理者	SSP を作成し、設定を変更します。 親ファームの共有サービスの設定を構成します。 SSP データベースなど、親ファームの共有リソースを管理します。 SSP に関連付けられた資格情報を管理します。 親の SSP を使用するすべてのファームおよびサイトに影響する共有サービスの設定を管理します。
子ファーム管理者	親ファームの共有サービスを使用するように子ファームを構成します。 子ファームの Web アプリケーションを親の SSP に関連付けます。 親ファームとの関連付けを解除します。

このドキュメントをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。

• Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2

入手可能なドキュメントの詳細な一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。

関連項目

概念

共有サービス プロバイダを計画する
論理アーキテクチャ コンポーネント
論理アーキテクチャ モデル : 企業展開
共有サービス プロバイダを作成および構成する