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