論理アーキテクチャ コンポーネント (SharePoint Server 2010)

  • [アーティクル]

 

適用先: SharePoint Foundation 2010, SharePoint Server 2010

トピックの最終更新日: 2016-11-30

論理アーキテクチャ設計では、さまざまな方法でコンポーネントを管理できます。各コンポーネントには、異なる共有および分離の方法があります。論理アーキテクチャを設計する前に、次の点を確認してください。

  • 共有および分離の目的を把握していること。

  • それぞれのトレードオフを評価していること。

この記事の各セクションで、論理アーキテクチャ コンポーネントのそれぞれについて、コンポーネントに関する考慮事項を説明します。この考慮事項には、コンポーネントの容量、共有と分離、構成可能なアイテム、管理、および設計に関する推奨事項が含まれます。

この記事の内容:

  • サーバー ファーム

  • サービス アプリケーション

  • IIS アプリケーション プール

  • Web アプリケーション

  • 領域

  • Web アプリケーションのポリシー

  • コンテンツ データベース

  • サイト コレクション

  • サイト

  • ホスト名付きサイト コレクション

  • 個人用サイト

サーバー ファーム

サーバー ファームは設計における最上位の要素です。個々のサーバー ファームによって物理的な分離が可能になります。

組織で決定されたさまざまな基準によって、必要なサーバー ファームの数は変わる場合があります。その基準の例を次に示します。

  • サービスの負荷増大による 1 つ以上の専用サービス ファームの必要性の発生

  • 各事業部の業務の分離

  • 専用の資金ソース

  • データセンターの場所の分離

  • サイト間の物理的な分離に関する業界の要件

とはいえ、1 つのサーバー ファームで多数の分離要件を満たすことができます。たとえば、プロセス ID が異なる複数のインターネット インフォメーション サービス (IIS) アプリケーション プールを使用すれば、サイトとサービス アプリケーションの双方についてプロセス レベルの分離を実現できます。

複数のサーバー ファームが必要になる分離要件に加えて、パフォーマンスおよび規模に関する目標やライセンスの要件を満たしたり、公開環境を実現したりするためにも、組織は複数のサーバー ファームを実装する場合があります。

サービス アプリケーション

サービス アプリケーションは、同じファーム内の複数のサイト間や場合によっては複数のファーム間で共有できるリソースを提供します。

SharePoint Server 2010 では、サービスが共有サービス プロバイダー (SSP) に含まれなくなりました。その代わり、サービスをホストするためのインフラストラクチャが Microsoft SharePoint Foundation 2010 内に移されたので、提供サービスの構成が以前よりもずっと柔軟に行えます。個々のサービスを独立して構成したり、サードパーティがプラットフォームにサービスを追加したりできます。

必要なサービスだけをファームに展開できます。展開されたサービスをサービス アプリケーションといいます。

サービス アプリケーションは、Web アプリケーションと関連付けられます。次のように、サービス アプリケーションごとに構成を変えることができます。

  • Web アプリケーションは、展開されたサービスのセット全体ではなく、必要なサービスだけを使用するように構成できます。

  • 同じサービスの複数のインスタンスを 1 つのファームに展開して、結果として得られるサービス アプリケーションのそれぞれに固有の名前を割り当てることができます。

  • サービス アプリケーションは、同じファーム内にある複数の Web アプリケーション間で共有できます。

  • 一部のサービス アプリケーションを複数のファーム間で共有できます。

容量

1 つのファームに存在するサービス アプリケーションの数についての推奨上限値はありません。

共有と分離

サービス アプリケーションは、次の 2 つの方法で共有できます。

  • サービス アプリケーションとサービス データを共有します。これは、Web アプリケーション間で共有されるサービスに対する既定の動作です。たとえば、検索結果は、同じ検索アプリケーションを利用する Web アプリケーション間で共有されます。

  • サービス アプリケーションだけを共有し、データについてはサービスをパーティション分割モードで展開することによって分離します。ホストされた環境では、Windows PowerShell を使用してサービス アプリケーションをパーティション分割モードで展開できます。それぞれのテナントのデータは、サービス用データベースの別々のパーティションに格納されます。テナントのサービス データをそれぞれのサイトにマップするために、テナントの購読 ID が使用されます。たとえば、Search Service をパーティション分割モードで展開すると、それぞれのテナントで確認できるのは各自のコンテンツを対象とした検索結果だけになります。

    注意

    すべてのサービス アプリケーションがパーティション分割をサポートしているわけではありません。

逆にいうと、サービス アプリケーションの分離には、次の 2 つの方法があります。

  • 複数のサービス アプリケーションを別々のアプリケーション プールに展開して、サービスおよびサービス データのプロセス分離を実現します。たとえば、財務チームでは分離された専用の Business Data Connectivity アプリケーションが必要になる場合があります。

  • パーティション分割モードでサービスを展開します。この方法は、テナントどうしが決してサービス データを共有しないホストされた環境でうまく機能します。ただし、サービス データの共有と分離の各ニーズが混在する環境では、実用的でない場合があります。

必要であれば、サービス アプリケーション間の分離を強化するためにそれらを別々のアプリケーション プールに展開して、プロセスの分離を実現できます。ただし、アプリケーション プールは限られたリソースなので、多用しすぎるとファームのパフォーマンスに影響します。詳細については、この記事の「アプリケーション プール」を参照してください。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明

既定のグループ

既定では、すべてのサービス アプリケーションが既定のグループに含まれています。既定のグループに対するサービス アプリケーションの追加や削除は、サービス アプリケーションの作成時を含めていつでも行えます。

Web アプリケーションの作成時には、既定のグループを選択することも、サービスのカスタム グループを作成することもできます。サービスのカスタム グループを作成する場合は、Web アプリケーションで使用するサービス アプリケーションだけを選択します。

接続 (プロキシ)

サービス アプリケーションを作成すると、そのサービス アプリケーションのための接続が同時に作成されます。接続とは、Web アプリケーションとサービス アプリケーションを接続する仮想的なエンティティです。Managed Metadata Service のような一部のサービス アプリケーションは、設定を接続内に格納します。Windows PowerShell では、接続のことをプロキシと呼びます。

サービス アプリケーションのアクセス許可

サービス アプリケーションの管理を委任するには、他のユーザーに対して 1 つ以上のサービス アプリケーションへのアクセス許可を与えます。

信頼できる個人用サイトのホストの場所

複数の User Profile Service アプリケーションが展開されている組織では、この機能によって、ユーザーが確実に自分のプロファイル用の場所に個人用サイトを作成することになります。この機能は、ユーザーが 1 つの組織に複数の個人用サイトを作成する事態を防ぎます。

管理

サービス アプリケーションの構成と管理は、検索、ユーザー プロファイル、管理されたメタデータなど、個々のサービスを管理する専任の管理者に委任できます。

ホストされた環境では、テナントが自らの組織向けのサービス設定の一部を管理できます。

計画の推奨事項

サービス アプリケーションを構成する目的は、複数の Web アプリケーション間でのリソースの共有か、コンテンツの分離のどちらかです。

たとえば、別々の Web アプリケーションおよびアプリケーション プールに属する複数のサイトは、既定のプロキシ グループ内にあるサービスを共有することによって統合でき、その結果、分類、コンテンツの種類、およびプロファイルをイントラネット全体で共有できます。これにより、個人用設定および企業全体の標準化が多数のサイトおよびアプリケーション間で可能になります。この選択は、(別々の Web アプリケーションおよびアプリケーション プールの実装による) プロセス分離と、情報を共有してアプリケーション間でプロファイル データを活用するというビジネス ニーズとのバランスをとる例です。

また、サービス アプリケーションの構成によって、全体的な分離を実現することもできます。たとえば、パートナーとのグループ作業に専用のサービスのセットを使用することで、パートナーのユーザーがイントラネット環境内で機密情報を検索したり、それらの情報にアクセスしたりすることを防げます。個々のサービスを構成すれば、コンテンツをさらにサイト コレクション間で分離できます。たとえば、次のようなことができます。

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

  • Active Directory ドメイン サービス (AD DS) 内の同じ組織単位に属するユーザーだけを表示するように、User Profile Service を構成します。

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

組織のサービス戦略を設計する場合に、個々のサービスの構成方法を検討して、全体的なコンテンツの共有または分離を実現できるようにします。

ホスティング環境のサービス戦略を設計する場合に、どのサービスが使用可能でパーティション分割されるかを決定します。

アプリケーション プール

インターネット インフォメーション サービス (IIS) 7.0 におけるアプリケーション プールとは、1 つのワーカー プロセスまたは一連のワーカー プロセスによって処理される 1 つ以上の URL のグループです。

SharePoint 2010 製品でサイト コレクションやサービスを作成する際には、使用するアプリケーション プールを選択する以外に、新しいアプリケーション プールを作成することもできます。それぞれのアプリケーション プロセスは、独自のワーカー プロセスを持っており、別々の ID を持たせることで 2 つのプロセス間の相互作用を防ぐことができます。

容量

アプリケーション プールのメモリ オーバーヘッドは、アプリケーション プール プロセス空間で実行中のアプリケーションによるメモリ使用量に、30 ～ 50 MB (メガバイト) を足したものになります。アプリケーションのさまざまな要求によって、1 つのアプリケーション プールのメモリ使用量が短時間で 800 MB 以上に達することも少なくありません。アプリケーション プール数の上限は、システムで利用可能なメモリ量によって左右されます。具体的には、次の 2 つの要因によってアプリケーション プール数が決まります。

  • 使用できるアドレス可能なメモリ

  • アプリケーション プールで実行中のアプリケーションによって消費されるメモリの容量

許容範囲のパフォーマンスを実現するため、目安として 8 以下のアプリケーション プールを使用してください。

共有と分離

IIS アプリケーション プールでは、複数のサイトが同じサーバー コンピューター上で動作しながらも独自のワーカー プロセスと ID を保持できます。これにより、攻撃者があるサイトの脆弱性を突いて悪意のあるコードを送り込んだとしても、別のアプリケーション プールにある他のサイトがその影響を受けないようにすることができます。さらに重要なのは、この戦略によって、メモリなどに関する問題を発生させるコードが分離され、そうした問題のあるコードがアプリケーションのすべてに影響を及ぼすことがなくなる点です。

構成可能なアイテム

セキュリティや分離の理由から、必要に応じて、アプリケーション プールごとに別のアプリケーション プール ID を使用することをお勧めします。

管理

アプリケーション プールごとに異なる ID を使用する場合は、それぞれの ID の管理が必要になります。

計画の推奨事項

実例として、次の目的に専用のアプリケーション プールを使用できます。

  • 基本的に匿名のコンテンツと認証コンテンツを区別する場合

  • Business Data Connectivity 接続のような外部ビジネス アプリケーションのパスワードを格納したり、そうしたアプリケーションとのやりとりを行ったりするアプリケーションどうしを分離する場合

Web アプリケーション

Web アプリケーションは、SharePoint 2010 製品によって作成され、使用される IIS Web サイトです。1 つの Web アプリケーションは 4 回まで拡張でき、SharePoint 2010 製品の追加領域を 4 つ作成できるので、1 つの Web アプリケーションに関連付けられる IIS Web サイトの数は最大で 5 つになります (それぞれの IIS Web サイトを別々の領域に関連付けた場合)。Web アプリケーションのそれぞれには、固有のドメイン名を割り当てることができます。詳細については、この記事の「領域」を参照してください。

共有と分離

各 Web アプリケーションには一意のドメイン名が割り当てられています。これにより、クロスサイト スクリプト攻撃を防いでいます。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明

サービス アプリケーション

サービス アプリケーションは、Web アプリケーションと関連付けられています。Web アプリケーションの作成時には、既定のプロキシ グループ (サービス アプリケーションの既定のセット) を選択することも、Web アプリケーションに対してサービス アプリケーションのカスタム セットを指定することもできます。1 つの Web アプリケーション内のすべてのサイトは、同じサービス アプリケーションのサービスを利用します。1 つのサービス アプリケーションは複数の Web アプリケーションにサービスを提供できるので、コンテンツとプロファイル データをそれらの Web アプリケーション間で共有できます。

領域

1 つの Web アプリケーション内には、最大 5 つの領域を作成できます。適用するアクセスおよびポリシー条件を多数のユーザーから成るグループ間で変えるには、領域を使用します。

Web アプリケーションのポリシー

Web アプリケーション内の 1 つ以上の領域にわたってアクセス許可を適用するには、ポリシーを作成します。ポリシーは、特定のユーザーまたはユーザー グループに対して作成できます。詳細については、この記事の「Web アプリケーションのポリシー」を参照してください。

管理

Web アプリケーションの継続的な管理は必要ありません。

計画の推奨事項

一般的に、専用の Web アプリケーションは次の目的で使用します。

  • 匿名ユーザーに対するコンテンツと、認証ユーザーに対するコンテンツとを区別する。

  • ユーザーを隔離する。たとえば、別の Web アプリケーションにパートナー サイトを配置することで、パートナーがイントラネットのコンテンツにアクセスできないようにします。

  • ポリシーの使用によってアクセス許可を適用する。たとえば、1 つ以上のユーザーのグループに対して書き込みアクセスを明示的に拒否するポリシーを作成できます。Web アプリケーションのポリシーは、Web アプリケーション内の個々のサイトまたはドキュメントに対して構成されたアクセス許可の有無に関係なく、適用されます。

  • データベースのパフォーマンスを最適化する。アプリケーションのパフォーマンスは、データ特性が類似した他のアプリケーションと一緒にコンテンツ データベースに配置することで向上します。たとえば、個人用サイトには、規模は小さいがサイト数が多いというデータ特性が一般的にあります。反対に、チーム サイトには、数は少ないが規模が非常に大きいという傾向があります。これら 2 種類のサイトを別々の Web アプリケーションに配置することにより、データベースは特性の類似するデータで構成されるようになり、データベースのパフォーマンスが最適化されます。

  • 管理性を最適化する。別々の Web アプリケーションを作成すると、サイトとベータベースも別々になるため、サイトごとに異なるごみ箱、有効期限、およびサイズの制限を実装し、異なるサービス レベルを適用できます。たとえば、ビジネスにクリティカルではないサイトの復元には、さらに多くの時間を許可できます。

領域

領域は、同じ Web アプリケーションにアクセスするためのさまざまな論理パス (URL) を表します。1 つの Web アプリケーションには、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のいずれかを使用して、最大 5 つの領域を作成できます。それぞれの名前は、1 つの Web アプリケーションにつき一度しか選択できません。各領域は、IIS における別々の Web サイトによって表されます。

既定領域は、Web アプリケーションを作成する際に最初に作成される領域です。他の領域は、Web アプリケーションを拡張することによって作成されます。

容量

Web アプリケーション内で、最大 5 つの領域を作成できます。通常、同じ名前の領域が同じユーザーに対して構成されるように、領域は Web アプリケーション全体にわたって調整されます。

共有と分離

領域では、次の方法でユーザーを分類します。

  • 認証の種類 : 異なる認証プロバイダーを使用するように各領域を構成でき、パートナー企業間で同じコンテンツを共有することができます。

  • ネットワーク領域 : エクストラネットやインターネットのような別のネットワーク領域からアクセスするユーザーを受け入れるように各領域を構成できます。

  • ポリシーのアクセス許可 : ユーザー アカウントまたはグループ アカウントに基づいて、領域ごとにコンテンツへの読み取り/書き込みアクセスを明示的に許可したり拒否したりできます。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明

認証プロバイダー

各領域は、異なる認証プロバイダーを使用するよう構成できます。

匿名アクセス

領域ごとに匿名アクセスを有効または無効にします。

Secure Sockets Layer (SSL)

領域ごとに SSL をオン、オフにします。

パブリック URL と代替アクセス マッピング

ユーザーが Web アプリケーションのコンテンツにアクセスする際に入力するドメイン名を指定します。または、代理アクセス マッピングを使用し、わかりやすい URL あるいは領域に適した URL を各領域の既定の URL (サーバー名とポート) にマッピングします。代替アクセス マッピングは、SSL のオフボックス ターミネーションをサポートします。SSL のオフボックス ターミネーションとは、プロキシ サーバーが SSL 要求を終了し、その後 HTTP を使用してその要求を Web サーバーに転送することです。この場合、SSL を使用してこれらの要求を返すように代替アクセス マッピングを構成することで、クライアントとプロキシ サーバー間でセキュリティ保護された通信を維持できます。

Web アプリケーションのポリシー

Web アプリケーション内の各領域に、一意のポリシー セットを作成します。全体的なセキュリティ ポリシーに該当しない特殊なユーザー グループが存在する場合は、それらのユーザー用に個別の領域を使うことを検討してください。

管理

代替アクセス マッピングを使用する場合、パブリック URL をファームのロード バランサー IP アドレスにマッピングするため、すべてのパブリック URL にドメイン ネーム システム (DNS) エントリが必要になることに注意してください。

計画の推奨事項

領域を設計するときには、いくつかの重要な決定が展開の成功を左右します。これらの決定事項の中に、次の領域のデザインと構成に関する決定があります。

  • 既定領域

  • 外部アクセス用の領域

以降のセクションでは、計画の推奨事項と、領域 (既定領域など) の要件について説明します。

  • 管理用電子メールは、既定領域からのリンクを付けて送信されます。その一例が、クォータ制限に近づいているサイトの所有者に対する電子メールです。したがって、管理者用の電子メールや通知を受信するユーザーは、既定領域を経由してリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。

  • ホスト名付きサイト コレクションは、既定領域を経由してのみ利用できます。ホスト名付きサイト コレクションにアクセスするすべてのユーザーには、既定領域を経由したアクセスが必要です。

  • 既定領域は最も安全な領域である必要があります。これは、ユーザーの要求を領域と関連付けることができない場合、既定領域の認証とポリシーが適用されるためです。

エクストラネット環境では、次の 2 つの理由から、領域のデザインがきわめて重要になります。

  • ユーザーの要求は、内部ネットワーク、パートナー企業ネットワーク、インターネットなど、さまざまなネットワークから開始できます。

  • ユーザーは複数の Web アプリケーションでコンテンツを使用します。たとえば、イントラネット環境には、複数の Web アプリケーションにホストされているサイトが含まれる場合があります。また、従業員はイントラネット コンテンツとパートナー グループ作業コンテンツ両方にアクセスできる場合もあります。

エクストラネット環境では、次のデザイン原則に従ってください。

  • 複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。

  • 各領域と各リソースについて、代替アクセス マッピングを適切かつ正確に構成します。

Web アプリケーションのポリシー

Web アプリケーションのポリシーは、Web アプリケーション内のすべてのコンテンツに対してアクセス許可を適用します。これにより、ユーザーに対して、Web アプリケーション レベルでセキュリティ ポリシーを設定できます。ポリシーのアクセス許可は、サイトとコンテンツに対して構成された他のすべてのセキュリティ設定より優先されます。

ポリシーは AD DS のユーザーまたはユーザー グループに基づいて構成できますが、SharePoint グループに基づいて構成することはできません。ポリシーの定義は、Web アプリケーション全体に対して、または特定の領域のみに対して行えます。

容量

Web アプリケーションのポリシーに適用される容量の制限はありません。

共有と分離

Web アプリケーションのポリシーにより、ユーザー ベース、およびユーザーがコンテンツにアクセスする際に経由する領域ベースでアクセス許可を設定できます。

たとえば、ポリシーを使用することで次のことが可能になります。

  • ヘルプ デスク スタッフがすべてのコンテンツにアクセスすることを許可する。

  • パートナーまたはベンダーに対し、書き込みアクセスを拒否する。

  • サイト所有者がアクセス許可をどのように構成しているかにかかわらず、ユーザーのグループに対してセキュアなデータへのアクセスを拒否する。

  • クロール アカウントがすべてのコンテンツをクロールするためにアクセスできるようにする。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明
   

ユーザー ポリシー

ユーザーまたはユーザー グループに適用されるポリシーを作成します。

  • ポリシーはすべての領域または 1 つの領域に適用できます。

  • ユーザー名、グループ名、または電子メール アドレスを入力できます。

  • ポリシーに適用するアクセス許可を指定します。

サーバーの全体管理でポリシーを作成する際にアクセス許可ポリシーをクリックすることで、既定のアクセス許可レベルの変更や新しいアクセス許可レベルの作成ができます。

匿名ポリシー

Web アプリケーションまたは 1 つ以上の領域で匿名アクセスが有効な場合は、すべての匿名ユーザーに適用されるポリシーを作成できます。既定のポリシー設定は次のようになっています。

  • なし: ポリシーがない

  • 書き込みの拒否: 書き込みアクセス権がない

  • すべて拒否: アクセス権がない

匿名ユーザーのポリシー レベルは変更できません。

アクセス許可ポリシー

既定のアクセス許可レベルの 1 つに関連付けられた特定のアクセス許可を編集するか、新しいアクセス許可ポリシー レベルを作成します。また、サイト コレクションやサイトで許可または拒否される特定のアクセス許可を指定できます。

新しいアクセス許可ポリシー レベルを作成した場合は、そのアクセス許可ポリシーを使用するユーザー ポリシーを作成できます。

管理

Web アプリケーション ポリシーの継続的な管理は必要ありません。

計画の推奨事項

ポリシーは一元管理されるので、個々のユーザーではなく、大規模なユーザーのグループを管理する場合はポリシーの使用を検討します。

コンテンツ データベース

既定で、Web アプリケーションのコンテンツは、すべて 1 つのコンテンツ データベースに保存されます。ただし、サイト コレクション レベルで、コンテンツを複数のコンテンツ データベースに分けることができます。コンテンツ データベースには、1 つ以上のサイト コレクションを含めることができます。1 つのサイト コレクションを、複数のデータベースに分けることはできません。サイトのバックアップおよび復元は、コンテンツ データベース レベルで実行されます。

容量

パフォーマンスを許容範囲に収めるには、実装するコンテンツ データベースを Web アプリケーションあたり 100 以下にすることをお勧めします。

共有と分離

データベースの設計には、複数のサイト コレクションでデータベースを共有して効率を高める方法と、サイト コレクションそれぞれに 1 つのデータベースを使用してデータベースを分離する方法があります。

規模効率を得るには、データベースを最大目標サイズに基づいて管理します。この場合は、データベース設定の構成によって、サイト コレクションの最大数に達するまで新しいサイト コレクションを既存のデータベースに追加するようにします。サイト コレクションの最大数を計算するには、サイト コレクションの平均または最大サイズを見積もり、その値でデータベースの最大目標サイズを割ります。この方法が有効なのは、個人用サイトのように、小さなサイト コレクションが数多く存在すると予想されるときです。

チームまたはプロジェクト間でコンテンツの分離を実現するには、データベースを 1 つのサイト コレクションに制限します。この方法によって、個々のチームのコンテンツを別々に管理できるようになります。たとえば、バックアップ、復元、および移行用に各チームのデータベースを別々に管理できます。この方法を使用すれば、異なるチームまたはプロジェクトに対して別々のサービス レベル契約を実施できます。また、プロジェクトのライフサイクルに合わせてコンテンツを管理できます。たとえば、プロジェクトの完了時にデータベースをアーカイブすることができます。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明

データベース サーバー

コンテンツ データベースが作成される SQL Server コンピューターを指定します。

フェールオーバー サーバー

コンテンツ データベースは、SQL Server のデータベース ミラーリングと連携する形で使用される特定のフェールオーバー サーバーと関連付けることができます。

容量設定

警告イベントが生成されるまでに作成できるサイトの数や、データベースごとに作成できるサイトの最大数を指定できます。

管理

管理可能なデータベース管理計画では、データベースの数と、データベースの管理に必要なリソースのバランスをとります。

データベースの管理には、次の作業が含まれます。

  • 新しいチーム サイト、または専用データベースを必要とするサイト コレクションに対して、新しいデータベースを作成する。

  • データベース サイズを監視し、目標サイズに達しそうになると新しいデータベースを作成する。

  • データベースをバックアップし、復元する。

計画の推奨事項

次の 2 つの方法のどちらかを選択します。

  • 適切なサイズの警告しきい値を使用して、コンテンツ データベースの目標サイズを設定します。サイズが警告しきい値に達したら、新しいデータベースを作成します。この方法では、利用可能なデータベースへのサイト コレクションの自動的な追加が目標サイズのみに基づいて行われます。

  • サイト コレクションを特定のコンテンツ データベースに関連付けます。この方法では、1 つ以上のサイト コレクションを、他のデータベースとは別に管理できる専用のデータベースに配置できます。

サイト コレクションを特定のコンテンツ データベースに関連付ける場合は、次の方法を使用します。

  • Windows PowerShell を使用して、特定のデータベースにサイト コレクションを作成します。

  • SharePoint サーバーの全体管理 Web サイトの [コンテンツ データベース設定の管理] ページで、次のデータベース容量設定を適用します。

    • [警告イベントが生成される前のサイト数] = 0

    • [このデータベースに作成できるサイトの最大数] = 1

  • 次の手順を実行して、専用のデータベースにサイト コレクションのグループを追加します。

    1. Web アプリケーションのコンテンツ データベースを追加し、このデータベースの状態を [準備完了] に設定します。

    2. 他のすべてのデータベースの状態を [オフライン] に設定します。コンテンツ データベースがオフラインである間は、新しいサイト コレクションを作成できません。ただし、オフライン データベースの既存のサイト コレクションに対しては、読み取りと書き込みのどちらの操作でも実行できます。

    3. サイト コレクションを作成します。作成したサイト コレクションは、自動的にオンライン データベースに追加されます。

    4. 他のすべてのデータベースの状態を [準備完了] に戻します。

サイト コレクション

サイト コレクションとは、所有者が同じで、管理の設定を共有する Web サイトの集合のことです。各サイト コレクションにはトップレベル Web サイト以外に、1 つ以上のサブサイトが含まれることもあります。

容量

パフォーマンスを許容範囲に収めるには、実装するサイト コレクションを 1 つのコンテンツ データベースにつき 50,000 以下にすることをお勧めします。ただし、サイト コレクションの数が 10,000 程度になると、パフォーマンスへの影響が生じる可能性があります。複数のデータベース サーバーにサイト コレクションを分散させてスケール アウトすれば、記憶容量とスループットが増加します。

共有と分離

サイト コレクションにより、いくつかの方法で、アクセス許可、ナビゲーション、および機能の展開を制御する共有と分離を実現できます。

次のアイテムは 1 つのサイト コレクション内では共有できますが、複数のサイト コレクション間では共有できません (_layouts ディレクトリの機能のように、ファイル システム内に格納されているアイテムを除きます)。

  • マスター ページ

  • ページ レイアウト

  • イメージ

  • サイト テンプレート

さらに、次の方法で、アクセス許可とナビゲーションがサイト コレクション レベルで分離されます。

  • サイト コレクション内のサブサイトは、トップ レベルのサイトからアクセス許可を継承します。

  • サイト コレクションは、他のサイト コレクションからアクセス許可を継承することはできません。

  • あるサイト コレクションから別のサイト コレクションへのビルトイン ナビゲーションはありません。

また、SharePoint Server 2010 は、サイト コレクションまたはデータベースの数 (検索範囲によって異なります) にかかわらず、ユーザーのアクセス許可に基づいてサイト コレクション全体の検索結果を集約します。

アクセス許可は各サイトに適用されますが、ドメイン内の他のサイトからクロスサイト スクリプト攻撃にさらされる危険がなくなるわけではありません。

構成可能なアイテム

次の表に、分離と共有に影響する構成可能なアイテムを示します。

アイテム

説明

サイト コレクションの管理者

1 人のユーザーをサイト コレクションの管理者として指定し、もう 1 人のユーザーを代理の管理者として指定できます。全体管理で、これらのロールに対して複数のアカウントやグループ アカウントを入力することはできません。

サイト テンプレート

サイト テンプレートは、新しいサイトで使用可能になるリストおよび機能を決定します。サイトの多くの機能は、作成後にカスタマイズできます。ただし、サイト テンプレートは、サイトの作成が済むと変更できなくなります。

クォータ テンプレート

サイト コレクションで使用されるリソースを制限するために、クォータ テンプレートを適用できます。次のテンプレートが用意されています。

  • 個人用サイト (100 MB)

  • チーム サイト (2,000 MB)

次の表に、分離と共有に影響する、サイト コレクション内の構成可能なアイテムを示します。

アイテム

説明

サイト コレクション管理者

複数のユーザー アカウントをサイト コレクションの管理者として指定できます。グループ アカウントは追加できません。

アクセス許可レベル

ユーザー アカウントとグループ アカウントをサイト コレクションに追加し、それぞれにアクセス許可レベルを指定します。

管理

サイト コレクションの作成は、(ホスト名付きサイト コレクションの場合を除いて) DNS エントリを必要としないので、自動化やユーザーへの委任が容易に行えます。チーム サイトのサイト コレクションを一元的に作成することも、[Self-Service Site の管理] を使用してユーザー自身にサイト コレクションを作成させることもできます。

サイト コレクションに対して専用のデータベースを使用すれば、サイト コレクションのレベルでバックアップおよび復元を実行できるようになります。

計画の推奨事項

サイト コレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。サイト コレクションの設計には、次の 2 つの設計タスクが含まれます。

  • 組織全体で一貫した URL を設計する。

  • コンテンツの論理的な区分を作成する。

ホスト名付きサイト コレクションを使用しない場合は、Web アプリケーションごとに 1 つのルートレベル サイト コレクションが必要になります。これにより、Web アプリケーション内に存在するサイトまでの単一の URL パスが得られます。このことは、Web アプリケーション内に複数の領域を実装するときの要件でもあります。詳細については、この記事の「ホスト名付きサイト コレクション」を参照してください。

多くの組織では、Web アプリケーション内に複数のサイト コレクションが実装され、組織内のさまざまなチームや部署がそれらのサイト コレクションを使用できるようになることが望まれています。一般的な設計目標には、次が含まれます。

  • 各チームに、分離した個別のサイト コレクションを保持する。

  • 各チームに一意の URL を作成する。

  • チーム間でコンテンツを分離する。

これらの目標を達成するには、管理対象パスを使用して、Web アプリケーション内に複数のトップレベル サイト コレクションを実装できます。管理対象パスを定義することにより、Web アプリケーションの URL 名前空間のどのパスを、サイト コレクションに使用するかを指定できます。1 つまたは複数のサイト コレクションが、ルート サイトより下位の特定のパスに存在するよう指定できます。管理対象パスなしの場合、ルート サイト コレクションより下位に作成されるすべてのサイトは、ルート サイト コレクションに属します。

作成できる管理対象パスには、次の 2 種類があります。

  • 明示的な管理対象パス : 明示的な URL が割り当てられたサイト コレクションです。1 つの明示的な管理対象パスは、1 つのサイト コレクションにしか適用されません。データベースの拡大を管理したり、各サイトのバックアップおよび復元を独立して行えるようにしたりする場合は、こうしたサイト コレクションのそれぞれに別々のコンテンツ データベースを関連付けることができます。この方法で作成されるサイト コレクションの URL の一例は、http://fabrikam/hr です。明示的な管理対象パスを使用して 1 つの Web アプリケーション内に作成できるサイト コレクション数の上限は、およそ 100 です。ただし、運用上の適切な最大値は 20 です。より多くのサイト コレクションが必要なときは、ワイルド カードを使用した管理対象パスを使用します。

  • ワイルド カードを使用した管理対象パス : URL に追加されるパスです。このパスは、パス名の直後に指定されるすべてのサイトが、固有のサイト コレクションであることを示します。この方法は、通常、個人用サイト、パートナーとのグループ作業で作成されたサイトなど、Self-Service Site 管理をサポートするために使用されます。この方法で作成されるサイト コレクションの URL の例は、http://partnerweb/sites/project1 および http://partnerweb/sites/project2 です。これらの例で、"http://partnerweb" はルートレベルのサイト コレクションを表し、"/sites" はワイルド カードを使用した管理対象パスを表しています。

サイト

サイトは、サイト コレクション内にホストされている 1 つ以上の関連 Web ページとその他のアイテム (リスト、ライブラリ、ドキュメントなど) で構成されます。

容量

パフォーマンスを許容範囲に収めるには、実装するサイトを 1 つのサイト コレクションにつき 250,000 以下にすることをお勧めします。サブサイトを入れ子にすれば、大量の Web サイトを作成できます。ただし、入れ子になったサブサイトの多用は、サイトのアップグレードの所要時間に大きな影響を及ぼす可能性があります。

共有と分離

サイトには、サイト コレクション内で、あるサブサイトから別のサブサイトへのビルトイン ナビゲーションがあります。あるサイト コレクションから別のサイト コレクションへのビルトイン ナビゲーションはありません。

サイト コレクションの場合と同様に、サイトを分離しても、ドメイン内の他のサイトからクロスサイト スクリプト攻撃にさらされる危険がなくなるわけではありません。

構成可能な要素

各サイトから、そのサイトの所有者グループにユーザー アカウントまたはグループ アカウントを追加できます。

管理

さまざまなツールを使用して、個々のサイトのバックアップおよび復元が行えます。

ホスト名付きサイト コレクション

Web アプリケーション内に複数のルートレベル サイト コレクションを作成する場合は、ホスト名付きのサイト コレクションを使用できます。たとえば組織のホスト管理者は、ホスト名付きサイト コレクションを使用して、複数のドメイン名付きサイトを作成できます。

ホスト名付きサイト コレクションの作成に、ホスト ヘッダー モードのような特殊なモードは必要ありません。ホスト名付きサイト コレクションの作成には、Windows PowerShell を使用します。また、Windows PowerShell の使用によって、管理パスとホスト名付きサイト コレクションの併用が可能になります (New-SPManagedPath –HostHeader)。

ホスト名付きサイト コレクションを使用すると、さらに詳細に URL を制御できます。ただし、ホスト名付きサイト コレクションは、既定領域を通じてしか利用できません。他の領域を通じて認証するように構成されたユーザー アカウントは、ホスト名付きサイト コレクションにアクセスできません。

SharePoint 2010 製品では、ホスト名付きサイト コレクションによってオフボックス SSL ターミネーションがサポートされています。ただし、オフボックスで変更できるのはプロトコル スキームだけです (http:// または https://)。リバース プロキシ サーバーは、ホスト名もポート番号も変更できません (既定の SSL ポートから既定の HTTP ポートへの切り替えを除きます)。

容量

単一の IIS Web サイト内で、最大 100,000 のホスト名付きサイト コレクションを作成できます。

共有と分離

ホスト名付きサイト コレクションから生成される独立したドメイン名は、2 つのサイト間でのクロスサイト スクリプト攻撃の防止に役立ちます。

管理

ホスト名付きサイト コレクションの管理タスクには、次の内容が含まれます。

  • Windows PowerShell を使用してホスト名付きサイト コレクションを追加する。

  • 各ホスト名付きサイト コレクションに、個別の DNS エントリを作成する。

個人用サイト

個人用サイトは、ユーザーごとに個人用設定が行われる特殊な SharePoint サイトです。個人用サイトは User Profile Service の一部として既定で有効になっており、組織内のすべてのユーザーが固有の個人用サイトを作成できます。容量、共有と分離、および管理については、前述の「サイト」を参照してください。