論理アーキテクチャ コンポーネント
この記事の内容 :
サーバー ファーム
共有サービス プロバイダ
IIS アプリケーション プール
Web アプリケーション
領域
Web アプリケーションのポリシー
コンテンツ データベース
サイト コレクション
サイト
ホスト名付きサイト コレクション
個人用サイト
論理アーキテクチャ設計では、さまざまな方法でコンポーネントを管理できます。各コンポーネントには、異なる共有および分離の方法があります。論理アーキテクチャを設計する前に、次の点を確認してください。
共有および分離の目的を把握していること。
それぞれのトレードオフを評価していること。
この記事の各セクションで、論理アーキテクチャ コンポーネントのそれぞれについて、コンポーネントに関する考慮事項を説明します。この考慮事項には、コンポーネントの容量、共有と分離、構成可能なアイテム、管理、および設計に関する推奨事項が含まれます。
サンプル設計に論理アーキテクチャ コンポーネントを実装する方法については、「論理アーキテクチャ モデル : 企業展開」を参照してください。
サーバー ファーム
厳密にいえば、サーバー ファームは論理アーキテクチャ コンポーネントではありません。とはいえ、サーバー ファームは設計で最上位の要素です。
組織で決定されたさまざまな基準によって、必要なサーバー ファームの数は変わる場合があります。その基準の例を次に示します。
各事業部の業務の分離
専用の資金ソース
データセンターの場所の分離
サイト間の物理的な分離に関する業界の要件
とはいえ、1 つのサーバー ファームで、多数の分離要件を満たすことができます。たとえば、別々のプロセス ID を持つ異なるインターネット インフォメーション サービス (IIS) アプリケーション プールを使用して、プロセス レベルで分離を実現できます。さらに、別々の Web アプリケーションを使用して、Web アプリケーション レベルで分離を実現することもできます。
複数のサーバー ファームが必要になる分離要件に加えて、組織はパフォーマンスおよび容量の目標を実現するために複数のサーバー ファームを実装する場合があります。
Microsoft Office SharePoint Server 2007 では、他の要因によって複数サーバー ファームの展開が必要になる場合があります。たとえば、ライセンスの要件を満たすため、または公開環境を実装するために、複数のサーバー ファームが必要になる場合があります。詳細については、「サーバー ファームを計画する」を参照してください。
共有サービス プロバイダ
共有サービス プロバイダ (SSP) は、Web アプリケーションの論理グループとそれらに関連するサイトに、一連の共通サービスとサービス データを提供します。サービスとサービス データには次のものがあります。
個人用サイトを含む個人用設定サービス
対象ユーザー
ビジネス データ カタログ
Excel Services
Office SharePoint Server Search
利用状況レポート
SSP は、Web アプリケーションに関連付けられています。Web アプリケーション内にある全サイトは、その Web アプリケーションに割り当てられている SSP からサービスを受けています。SSP は、複数の Web アプリケーションに対するサービスをホストできます。
容量
ファームにつき、最大 20 の SSP を作成できます。許容範囲のパフォーマンスを得るため、ファームごとに 3 つ以下の SSP を使用するようお勧めします。
共有と分離
SSP を分離することで、プロファイル、コンテンツ、および検索結果のプロセスを分離できます。プロセスの分離は、次の方法で実現できます。
各 SSP を、個別の IIS アプリケーション プールに配置します。
各 SSP で一意のサービス アカウント セットを使用し、SSP で提供されるサービス (検索、コンテンツ クロール、プロファイルのインポートなど) を実行します。
論理アーキテクチャ内の SSP の数を決定する最も重要な要素は、次のとおりです。
異なる Web アプリケーションおよび IIS アプリケーション プールに存在するサイト間で、コンテンツおよびプロファイル データを共有する必要があるかどうか。たとえば、イントラネット間で個人用サイト、チーム サイト、および公開コンテンツを共有する場合は、これらのサイトを 1 つの SSP 下に配置できます。
コンテンツおよび対象ユーザーを、特定のサイトに分離する必要があるかどうか。たとえば、サーバー ファームで複数のユーザー クラス用アプリケーションをホストする場合は、個別の SSP を使用することにより、それらのクラスを分離できます。
構成可能なアイテム
次の表に、共有と分離に使用される構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
共有サービス アクセス許可 |
1 つ以上の共有サービスへのアクセス許可を付与することで、共有サービスの管理を他のユーザーに委任できます。ユーザーが共有サービスを表示および管理するには、共有サービス管理 Web サイトへのアクセス許可も必要です。 |
信頼できる個人用サイトの場所 |
複数の SSP によって個人用サイトが提供されている組織では、この機能によって、ユーザーが自分のプロファイル用 SSP でのみ個人用サイトを作成できるようになります。これにより、ユーザーが組織内で複数の個人用サイトを作成することはなくなります。詳細については、「個人用サイト アーキテクチャを設計する」の「組織全体で個人用サイトを調整する」を参照してください。 |
管理
SSP の構成と管理は、検索、対象ユーザーなどの共有サービスの提供を専門とする管理者に委任できます。
ホスト環境では、管理者は顧客ごとに 1 つの SSP を構成し、顧客が自分の共有サービスを管理できるようにすることができます。
SSP 管理者ロールの設計の詳細については、「セキュリティ ロールを計画する (Office SharePoint Server)」を参照してください。
計画の推奨事項
SSP の構成には、2 つの目的があります。1 つ目は複数の Web アプリケーション間で情報の共有を促進すること、2 つ目は単一の Web アプリケーション内でコンテンツをさらに分離することです。
たとえば、異なる Web アプリケーションおよびアプリケーション プールに存在する複数のサイトを 1 つの SSP に統合し、イントラネット全体でコンテンツとプロファイルの共有を実現できます。これにより、多数のサイトおよびアプリケーション間で、個人用設定および企業全体の検索が可能になります。これは、プロセス分離 (異なる Web アプリケーションとアプリケーション プールの実装) と、アプリケーション間で情報を共有したい、プロファイル データを活用したいというビジネス ニーズとのバランスをとる例です。
SSP を構成することで、全体的な分離を実現することもできます。たとえば、パートナーとのグループ作業で専用の SSP を使用することで、パートナーのユーザーがイントラネット環境内で機密情報を検索したり、それらの情報にアクセスしたりすることを防げます。次の方法で SSP を構成し、サイト コレクション間でコンテンツをさらに分離できます。
検索範囲を個別のサイト コレクションに制限します。
対象ユーザーを使用して、コンテンツの対象を特定のユーザー グループに限定します。
Stsadm コマンド ライン ツールを使用して、サイト コレクションのメンバであるユーザーだけを表示するように、ユーザー選択ウィンドウを構成します。
SSP 戦略を計画する際は、全体的なコンテンツの共有または分離を実現するために、各サービスを 1 つの SSP 内で構成できないか検討してください。
アプリケーション プール
アプリケーション プールとは、ワーカー プロセスによって処理される 1 つ以上の URL (IIS では Web サイトと呼ばれる) をグループ化したものです。各アプリケーション プールには、専用のワーカー プロセスと ID (セキュリティ アカウント) が割り当てられ、他のプロセスとは切り離されています。
容量
アプリケーション プールのメモリ オーバーヘッドは、アプリケーション プール プロセス空間で実行されているアプリケーションのメモリ使用量に、30 ～ 50 MB (メガバイト) を足したものになります。使用できるアプリケーション プールの数は、システムで利用可能なメモリ量によって制限されます。つまり、アプリケーション プールの数は次の 2 つの要因によって決まります。
使用できるアドレス可能なメモリ
アプリケーション プールで実行されるアプリケーションのサイズ
許容範囲のパフォーマンスを実現するため、目安として 8 以下のアプリケーション プールを使用してください。
共有と分離
IIS アプリケーション プールにより、複数のサイトが同じサーバー コンピュータ上で動作しながらも、専用のワーカー プロセスと ID を保持することが可能になります。これにより、攻撃者があるサイトの脆弱性を突いて悪意のあるコードを送り込んだとしても、別のアプリケーション プールにある他のサイトがその影響を受けないようにすることができます。
構成可能なアイテム
各アプリケーション プールに、異なるアプリケーション プール ID を使用します。
管理
管理には、各アプリケーション プールに、異なるアプリケーション プール ID が割り当てられていることを確認することが含まれます。
計画の推奨事項
実例として、次の目的に専用のアプリケーション プールを使用できます。
匿名コンテンツと認証コンテンツを区別する。
外部ビジネス アプリケーションのパスワードの保存と外部ビジネス アプリケーションとの通信 (ビジネス データ カタログとの接続など) を行うアプリケーションを分離する。
サイトの作成、管理、およびコンテンツのグループ作業をユーザーが自由に行えるようアプリケーションを分離する。
Web アプリケーション
Web アプリケーションは、SharePoint 製品とテクノロジによって作成、使用される IIS Web サイトです。各 Web アプリケーションは、IIS で個別の Web サイトとして表されます。各 Web アプリケーションには一意のドメイン名を割り当てます。これにより、クロスサイト スクリプト攻撃を防ぐことができます。
容量
各 ASP.NET ページは、Web アプリケーションそれぞれに個別のダイナミックリンク ライブラリ (DLL) を生成します。各 DLL はメモリを消費するので、サーバー上で実行可能な Web アプリケーション数は限られます。許容範囲のパフォーマンスを得るため、目安として SSP ごとに 99 以下の Web アプリケーションを実装してください。
共有と分離
ギャラリーとテンプレートは、サーバー ファームの構成データベースに登録されています。これらのギャラリーとテンプレートを使用する Web アプリケーションを指定できます。
各 Web アプリケーションには一意のドメイン名が割り当てられています。これにより、クロスサイト スクリプト攻撃を防いでいます。
構成可能なアイテム
次の表に、共有と分離に使用される構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
共有サービス プロバイダ |
SSP は、Web アプリケーションに関連付けられています。Web アプリケーション内の全サイトは、同じ SSP のサービスを使用します。SSP は、複数の Web アプリケーションに対してサービスを提供できるので、Web アプリケーション間でコンテンツとプロファイル データを共有します。 |
領域 |
Web アプリケーション内で、最大 5 つの領域を作成できます。領域を使用することで、大規模なユーザー クラスに対して、異なるアクセスおよびポリシー条件を適用できます。 |
Web アプリケーションのポリシー |
Web アプリケーション内のすべての領域にポリシー条件を適用するには、"すべての領域" ポリシーを作成します。 |
管理
Web アプリケーションの継続的な管理は必要ありません。
計画の推奨事項
一般的に、専用の Web アプリケーションは次の目的で使用します。
匿名ユーザーに対するコンテンツと、認証ユーザーに対するコンテンツとを区別する。
ユーザーを隔離する。たとえば、別の Web アプリケーションにパートナー サイトを配置することで、パートナーがイントラネットのコンテンツにアクセスできないようにします。
アクセス許可を適用する。専用の Web アプリケーションを使用すると、ポリシーによるアクセス許可の適用が可能になります。ポリシーによるアクセス許可の適用は、全体管理の [Web アプリケーションのポリシー] ページで行います。たとえば、1 つ以上のユーザー グループに対して、書き込みアクセスを明示的に拒否するポリシーを作成できます。Web アプリケーションのポリシーは、Web アプリケーション内の各サイトまたはドキュメントに対して構成されたアクセス許可にかかわらず適用されます。
データベース パフォーマンスを最適化する。アプリケーションは、類似するデータ特性を持つ他のアプリケーションと共に Web アプリケーションに配置した方が、パフォーマンスが高くなります。たとえば、一般的に個人用サイトには、サイトの規模は小さいが、数が多いという特性があります。一方、チーム サイトには、サイトの規模がきわめて大きく、数が少ないという特性があります。これら 2 種類のサイトをそれぞれの Web アプリケーションに配置することにより、データベースは特性の類似するデータで構成されるようになり、データベースのパフォーマンスが最適化されます。
管理性を最適化する。別々の Web アプリケーションを作成すると、サイトとベータベースも別々になるため、サイトごとに異なるごみ箱、有効期限、およびサイズの制限を実装し、異なるサービス レベルを適用できます。たとえば、ビジネスにクリティカルではないサイトの復元には、さらに多くの時間を許可できます。
領域
領域は、1 つの Web アプリケーションにアクセスするためのさまざまな論理パス (URL) を表します。各 Web アプリケーションでは、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のどちらかを使用して、最大 5 つの領域を作成できます。各領域は、IIS で個別の Web サイトとして表されます。
既定の領域は、Web アプリケーションを作成する際に最初に作成される領域です。
容量
Web アプリケーション内で、最大 5 つの領域を作成できます。通常、同じ名前の領域が同じユーザーに対して構成されるように、領域は Web アプリケーション全体にわたって調整されます。
共有と分離
領域では、次の方法でユーザーを分類します。
認証の種類 各領域は、異なる認証プロバイダを使用するよう構成できます。これにより、パートナー企業間で同じコンテンツを共有することが可能になります。
ネットワーク領域 各領域は、エクストラネットまたはインターネットなどの異なるネットワーク領域からアクセスするユーザーを受け入れるよう構成できます。
ポリシーのアクセス許可 ユーザー アカウントまたはグループ アカウントに基づいて、各領域のコンテンツへの読み取り/書き込みアクセスを明示的に許可/拒否することができます。
構成可能なアイテム
次の表に、共有と分離に使用される構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
認証プロバイダ |
各領域は、異なる認証プロバイダを使用するよう構成できます。 |
Secure Sockets Layer (SSL) |
領域ごとに SSL をオン、オフにします。 |
負荷分散される URL および代替アクセス マッピング |
ユーザーが Web アプリケーションのコンテンツにアクセスする際に入力するドメイン名を指定します。または、代理アクセス マッピングを使用し、わかりやすいまたは領域に適した URL を各領域の既定の URL (サーバー名とポート) にマッピングします。代替アクセス マッピングは、SSL のオフボックス ターミネーションをサポートします。SSL のオフボックス ターミネーションとは、プロキシ サーバーが SSL 要求を終了し、その後 HTTP を使用してその要求を Web サーバーに転送することです。この場合、SSL を使用してこれらの要求を返すように代替アクセス マッピングを構成することで、クライアントとプロキシ サーバー間でセキュリティ保護された通信を維持できます。 |
Web アプリケーションのポリシー |
Web アプリケーション内の各領域に、一意のポリシー セットを作成します。全体的なセキュリティ ポリシーに該当しない特殊なユーザー グループが存在する場合は、それらのユーザー用に個別の領域を使うことを検討してください。 |
管理
代替アクセス マッピングを使用する場合、パブリック URL をファームのロード バランサ IP アドレスにマッピングするため、すべてのパブリック URL にドメイン ネーム システム (DNS) エントリが必要になることに注意してください。
計画の推奨事項
領域を設計するときには、いくつかの重要な決定が展開の成功を左右します。これらの決定事項の中に、次の領域のデザインと構成に関する決定があります。
既定領域
外部アクセス用の領域
次に、領域の計画の推奨事項と要件を説明します。
既定領域の構成要件
最も慎重な考慮を要する領域は既定領域です。既定領域の構成方法には、次の要件が適用されます。
既定領域は最も安全な領域である必要があります。これは、ユーザーの要求を領域と関連付けることができない場合、既定領域の認証とポリシーが適用されるためです。
インデックス コンポーネントには、コンテンツをクロールするために、少なくとも 1 つの領域を経由したコンテンツへのアクセスが必要です。既定では、インデックス コンポーネントは NTLM 認証を使用します。検索サービス管理者は、特定の範囲の URL をクロールする際に基本認証またはクライアント証明書を使用するように、クロール ルールを構成できます。したがって、コンテンツをクロールするには、少なくとも 1 つの領域を、NTLM 認証、基本認証、または証明書を使用するように構成する必要があります。また、クローラは、認証に使用できる領域が見つかるまで、既定領域、イントラネット領域、インターネット領域、ユーザー設定領域、エクストラネット領域の順に領域をポーリングします。ただし、Kerberos 認証を使用するが、標準ポート (ポート 80 または 443 のどちらか) を使用するように構成されていない領域が最初に見つかった場合、クローラは認証を行わず、次の領域へのアクセスを試みません。このため、Kerberos 認証を使用する領域の構成が、インデックス コンポーネントによるコンテンツのクロールを妨げないようにしてください。コンテンツのクロールに関連する認証要件の詳細については、「認証方法を計画する (Office SharePoint Server)」を参照してください。
管理用電子メールは、既定領域からのリンクを付けて送信されます。その一例が、クォータ制限に近づいているサイトの所有者に対する電子メールです。したがって、管理者用の電子メールや通知を受信するユーザーは、既定領域を経由してリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。
ホスト名付きサイト コレクションは、既定領域を経由してのみ利用できます。ホスト名付きサイト コレクションにアクセスするすべてのユーザーには、既定領域を経由したアクセスが必要です。
エクストラネット環境用の領域を構成する
エクストラネット環境では、次の 2 つの理由から、領域のデザインがきわめて重要になります。
ユーザーの要求は、内部ネットワーク、パートナー企業ネットワーク、またはインターネットなど、さまざまなネットワークから開始できます。
ユーザーは複数の Web アプリケーションでコンテンツを使用します。たとえば、イントラネット環境には、複数の Web アプリケーションにホストされているサイトが含まれる場合があります。また、従業員はイントラネット コンテンツとパートナー グループ作業コンテンツ両方にアクセスできる場合もあります。
エクストラネット環境では、次のデザイン原則に従ってください。
複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。
各領域と各リソースについて、代替アクセス マッピングを適切かつ正確に構成します。
Web アプリケーションのポリシー
Web アプリケーションのポリシーは、Web アプリケーション内のすべてのコンテンツに対してアクセス許可を適用します。これにより、ユーザーに対して、Web アプリケーション レベルでセキュリティ ポリシーを設定できます。ポリシーのアクセス許可は、サイトとコンテンツに対して構成された他のすべてのセキュリティ設定より優先されます。
ポリシーはユーザーまたはユーザー グループに基づいて構成できますが、SharePoint グループに基づいて構成することはできません。ポリシーは、Web アプリケーション全体に対して、または特定の領域のみに対して定義できます。
容量
Web アプリケーションのポリシーに適用される容量の制限はありません。
共有と分離
Web アプリケーションのポリシーにより、ユーザー ベース、およびユーザーがコンテンツにアクセスする際に経由する領域ベースでアクセス許可を設定できます。
たとえば、ポリシーを使用することで次のことが可能になります。
ヘルプ デスク スタッフがすべてのコンテンツにアクセスすることを許可する。
パートナーまたはベンダに対し、書き込みアクセスを拒否する。
サイト所有者がどのようにアクセス許可を構成しているかにかかわらず、ユーザー クラスに対してセキュアなデータへのアクセスを拒否する。
クロール アカウントがすべてのコンテンツをクロールするためにアクセスできるようにする。
構成可能なアイテム
次の表に、共有と分離に使用される構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
領域 |
Web アプリケーション内の特定の領域 (イントラネット領域など)、または Web アプリケーション内のすべての領域に対してポリシーを適用します。 |
ユーザー |
次のいずれかを使用して、ポリシーの適用対象ユーザーを指定します。
|
アクセス許可 |
ユーザーに適用するアクセス許可を選択します。
これらのアクセス許可は、Web アプリケーション内で割り当てられるすべてのアクセス許可 (サイト コレクション、サイト、リスト、ドキュメントなどに設定されているアクセス許可) に優先して適用されます。 |
管理
Web アプリケーション ポリシーの継続的な管理は必要ありません。
計画の推奨事項
ポリシーは一元管理されるため、個々のユーザーではなく、大規模なユーザー クラスを管理するために使用するようお勧めします。
コンテンツ データベース
既定で、Web アプリケーションのコンテンツは、すべて 1 つのコンテンツ データベースに保存されます。ただし、サイト コレクション レベルで、コンテンツを複数のコンテンツ データベースに分けることができます。コンテンツ データベースには、1 つ以上のサイト コレクションを含めることができます。1 つのサイト コレクションを、複数のデータベースに分けることはできません。サイトのバックアップおよび復元は、コンテンツ データベース レベルで実行されます。
容量
許容範囲のパフォーマンスを得るため、目安として Web アプリケーションごとに 99 以下のコンテンツ データベースを実装してください。
共有と分離
データベースの設計には、複数のサイト コレクションでデータベースを共有して効率を高める方法と、サイト コレクションそれぞれに 1 つのデータベースを使用してデータベースを分離する方法があります。
規模の効率を高めるには、データベースを最大目標サイズまで使用します。これは、サイト コレクションの最大数に達するまで、既存のデータベースに新しいサイト コレクションを追加するよう、データベース設定を構成することで実現できます。サイト コレクションの最大数は、データベースの最大目標サイズまで分割されるサイト コレクションの平均または最大サイズを見積もることで計算できます。この方法は、個人用サイトのように、多数の小規模サイト コレクションを使用する場合に効果的です。
チームまたはプロジェクト間のコンテンツを分離するには、サイト コレクションのデータベースの数を 1 つに制限します。この方法により、各チームのコンテンツを個別に管理できます。たとえば、各チーム データベースのバックアップ、復元、および移行を個別に管理できます。これにより、チームやプロジェクトごとに、異なるサービス レベルを適用できます。さらに、プロジェクトのライフ サイクルまでコンテンツを管理することもできます。たとえば、プロジェクトが完了した際に、データベースをアーカイブできます。
構成可能なアイテム
次の表に、共有と分離に使用される構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
データベース サーバー |
コンテンツ データベースが作成される SQL Server コンピュータを指定します。 |
容量設定 |
|
管理
管理可能なデータベース管理計画では、データベースの数と、データベースの管理に必要なリソースのバランスをとります。
データベースの管理には、次の作業が含まれます。
新しいチーム サイト、または専用データベースを必要とするサイト コレクションに対して、新しいデータベースを作成する。
データベース サイズを監視し、サイズ目標値に達しそうになると、新しいデータベースを作成する。
データベースをバックアップし、復元する。
計画の推奨事項
次の 2 つの方法のどちらかを選択します。
適切なサイズの警告しきい値を使用して、コンテンツ データベースの目標サイズを設定します。サイズが警告しきい値に達したら、新しいデータベースを作成します。この方法では、サイト コレクションは、サイズ目標のみに基づいて利用可能なデータベースに自動的に追加されます。
サイト コレクションを特定のコンテンツ データベースに関連付けます。この方法では、1 つ以上のサイト コレクションを、他のデータベースとは別に管理できる専用のデータベースに配置できます。
サイト コレクションを特定のコンテンツ データベースに関連付ける場合は、次の方法を使用します。
Stsadm コマンド ライン ツールを使用して、特定のデータベースにサイト コレクションを作成します。
SharePoint サーバーの全体管理 Web サイトの [コンテンツ データベース設定の管理] ページで、次のデータベース容量設定を適用して、1 つのデータベースを単一のサイト コレクションだけに使用します。
[警告イベントが生成される前のサイト数] = 1
[このデータベースに作成できるサイトの最大数] = 1
次の手順を実行して、専用のデータベースにサイト コレクションのグループを追加します。
Web アプリケーション内でデータベースを作成し、全体管理の [コンテンツ データベース設定の管理] ページでデータベースの状態を [使用可能] に設定します。
他のすべてのデータベースの状態を [オフライン] に設定します。コンテンツ データベースがオフラインである間は、新しいサイト コレクションを作成できません。ただし、オフライン データベースの既存のサイト コレクションには、読み取り処理と書き込み処理の両方を実行できます。
サイト コレクションを作成します。作成したサイト コレクションは、自動的にデータベースに追加されます。
他のすべてのデータベースの状態を [準備完了] に戻します。
サイト コレクション
サイト コレクションとは、所有者が同じで、管理の設定を共有する Web サイトの集合のことです。各サイト コレクションにはトップレベル Web サイト以外に、1 つ以上のサブサイトが含まれることもあります。
容量
許容範囲のパフォーマンスを得るため、目安として Web アプリケーションごとに 50,000 未満のサイト コレクションを実装してください。複数のデータベース サーバーにサイト コレクションを分散することでスケール アウトすると、ストレージの容量とスループットを向上できます。
共有と分離
サイト コレクションにより、いくつかの方法で、アクセス許可、ナビゲーション、および機能の展開を制御する共有と分離を実現できます。
次のアイテムは 1 つのサイト コレクション内で共有できますが、複数のサイト コレクション間で共有することはできません。
マスタ ページ
ページ レイアウト
イメージ
サイト テンプレート
さらに、次の方法で、アクセス許可とナビゲーションがサイト コレクション レベルで分離されます。
サイト コレクション内のサブサイトは、トップ レベルのサイトからアクセス許可を継承します。
サイト コレクションは、他のサイト コレクションからアクセス許可を継承することはできません。
あるサイト コレクションから別のサイト コレクションへのビルトイン ナビゲーションはありません。
Office SharePoint Server 2007 は、サイト コレクションまたはデータベースの数 (検索範囲によって異なります) にかかわらず、ユーザーのアクセス許可に基づいて、サイト コレクション全体の検索結果を集約します。
アクセス許可は各サイトに適用されますが、ドメイン内の他のサイトからクロスサイト スクリプト攻撃にさらされる危険がなくなるわけではありません。
構成可能なアイテム
次の表に、共有と分離に使用される、全体管理で構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
サイト コレクションの管理者 |
1 人のユーザーをサイト コレクションの管理者として指定し、もう 1 人のユーザーを代理の管理者として指定できます。全体管理で、これらのロールに対して複数のアカウントやグループ アカウントを入力することはできません。 |
クォータ テンプレート |
サイト コレクションで使用されるリソースを制限するために、クォータ テンプレートを適用できます。次のテンプレートが用意されています。
|
次の表に、共有と分離に使用される、サイト コレクション内で構成可能なアイテムを示します。
| アイテム | 説明 |
|---|---|
サイト コレクション管理者 |
複数のユーザー アカウントをサイト コレクションの管理者として指定できます。グループ アカウントは追加できません。 |
アクセス許可レベル |
ユーザー アカウントとグループ アカウントをサイト コレクションに追加し、それぞれにアクセス許可レベルを指定します。 |
管理
サイト コレクションの作成には、DNS エントリが不要なので、サイト コレクションの作成を簡単に自動化したり、ユーザーに委任したりできます。チーム サイトのサイト コレクションを一元的に作成することも、[Self-Service Site の管理] を使用し、ユーザーが自分のサイト コレクションを作成できるよう許可することもできます。サイト コレクションを単一のデータベースに割り当てると、サイト コレクション レベルでバックアップおよび復元を実行できます。
計画の推奨事項
サイト コレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。サイト コレクションの設計には、次の 2 つの設計タスクが含まれます。
組織全体で一貫した URL を設計する。
コンテンツの論理的な区分を作成する。
ホスト名付きサイト コレクションを使用していない限り、各 Web アプリケーションには単一のルートレベル サイト コレクションが必要です。これにより、Web アプリケーション内に存在するサイトへの単一の URL パスが提供されます。これは、Web アプリケーション内に複数の領域を実装する場合の要件でもあります。
多くの組織は、Web アプリケーション内に複数のサイト コレクションを実装し、組織内のさまざまなチームや部署がそれらのサイト コレクションを使用できるようしたいと考えています。一般的な設計目標には、次が含まれます。
各チームに、分離した個別のサイト コレクションを保持する。
各チームに一意の URL を作成する。
これらの目標を達成するには、管理対象パスを使用して、Web アプリケーション内に複数のトップレベル サイト コレクションを実装できます。管理対象パスを定義することにより、Web アプリケーションの URL 名前空間のどのパスを、サイト コレクションに使用するかを指定できます。1 つまたは複数のサイト コレクションが、ルート サイトより下位の特定のパスに存在するよう指定できます。管理対象パスなしの場合、ルート サイト コレクションより下位に作成されるすべてのサイトは、ルート サイト コレクションに属します。
作成できる管理対象パスには、次の 2 種類があります。
明示的な管理対象パス 割り当てた明示的な URL を持つサイト コレクションです。明示的な管理対象パスは、単一のサイト コレクションに適用されます。サイト コレクションの拡大を管理し、これらのサイトを個別にバックアップおよび復元できるようにするには、これらのサイト コレクションそれぞれに、異なるコンテンツ データベースを関連付けることができます。この方法で作成されるサイト コレクションの URL の例は、http://fabrikam/hr です。明示的な管理対象パスを使用して作成されるサイト コレクション数の制限は、約 100 サイト コレクションです。さらに多くのサイト コレクションが必要な場合は、ワイルド カードを使用した管理対象パスを使用します。
ワイルド カードを使用した管理対象パス URL に追加されるパスです。このパスは、パス名の直後に指定されるすべてのサイトが、一意のサイト コレクションであることを示します。通常この方法は、個人用サイト、パートナーとのグループ作業で作成されたサイトなど、Self-Service Site 管理をサポートするために使用します。この方法で作成されるサイト コレクションの URL の例は、http://partnerweb/sites/project1 および http://partnerweb/sites/project2 です。これらの例で、"http://partnerweb" はルートレベルのサイト コレクションを表し、"/sites" はワイルド カードを使用した管理対象パスを表しています。
URL の設計および管理対象パスの使用の詳細については、計画に関する「論理アーキテクチャ モデル : 企業展開」という記事の「領域と URL」を参照してください。
サイト
サイトとは、サイト コレクション内にホストされている 1 つ以上の関連 Web ページのことです。
容量
許容範囲のパフォーマンスを得るため、目安としてサイト コレクションごとに 250,000 未満のサイトを実装してください。サブサイトを入れ子にすることで、大量の Web サイトを作成できます。たとえば、1,000 のサブサイトを含むサイトを 100 作成すると、100,000 の Web サイトを作成できます。サイトおよびサブサイトの推奨最大数はそれぞれ 125 サイトと 2,000 サブサイトで、合計は 250,000 サイトです。
共有と分離
サイトには、サイト コレクション内で、あるサブサイトから別のサブサイトへのビルトイン ナビゲーションがあります。あるサイト コレクションから別のサイト コレクションへのビルトイン ナビゲーションはありません。
サイト コレクションの場合と同様に、サイトを分離しても、ドメイン内の他のサイトからクロスサイト スクリプト攻撃にさらされる危険がなくなるわけではありません。
構成可能な要素
各サイトから、そのサイトの所有者グループにユーザー アカウントまたはグループ アカウントを追加できます。
管理
Microsoft Office SharePoint Designer 2007 を使用し、各サイトをバックアップおよび復元できます。サイト管理の詳細については、次の記事を参照してください。
計画の推奨事項
計画の推奨事項については、次の記事を参照してください。
ホスト名付きサイト コレクション
Web アプリケーション内に複数のルートレベル サイト コレクションを作成する場合は、ホスト名付きのサイト コレクションを使用できます。たとえば組織のホスト管理者は、ホスト名付きサイト コレクションを使用して、複数のドメイン名付きサイトを作成できます。
ホスト名付きサイト コレクションの作成に、ホスト ヘッダー モードなどの特殊なモードは必要ありません。ホスト名付きサイト コレクションは、Stsadm コマンド ライン ツールを使用して作成します。
ホスト名付きサイト コレクションを使うと、さらに詳細に URL を制御できます。ただし、トレードオフもあります。ホスト名付きサイト コレクションには、次の注意事項があります。
ホスト名付きサイト コレクションは、既定領域を経由してのみ利用できます。他の領域を経由して認証されるよう構成されているユーザー アカウントは、ホスト名付きサイト コレクションにアクセスできません。
代替アクセス マッピング機能は、ホスト名付きサイト コレクションでは機能しません。代替アクセス マッピング機能は SSL のオフボックス ターミネーションをサポートしています。これにより、リモートおよびパートナーの従業員が SSL (HTTPS) を使用してアクセスすることが可能になっています。
容量
単一の IIS Web サイト内で、最大 100,000 のホスト名付きサイト コレクションを作成できます。
共有と分離
ホスト名付きサイト コレクションを使用することで実現されるドメイン名の分離により、他のサイトからのクロスサイト スクリプト攻撃を防ぐことができます。
管理
ホスト名付きサイト コレクションの管理タスクには、次の内容が含まれます。
Stsadm コマンド ライン ツールを使用して、ホスト名付きサイト コレクションを追加する。
各ホスト名付きサイト コレクションに、個別の DNS エントリを作成する。
計画の推奨事項
Stsadm コマンド ライン ツールを使用してホスト名付きサイトを作成する方法、およびホスト環境でホスト名付きサイト コレクションを使用する方法については、「White paper: Create shared hosting solutions on Windows SharePoint Services」を参照してください。
個人用サイト
Office SharePoint Server 2007 で、個人用サイトはユーザーごとに個人用設定された特殊な SharePoint サイトです。個人用サイトは既定で有効になっており、組織内のユーザーはだれもが専用の個人用サイトを持っています。容量、共有と分離、および管理については、前述の「サイト」を参照してください。
個人用サイトの計画の推奨事項については、次のリソースを参照してください。
このブックをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。
入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。