次の方法で共有

Exchange パブリック フォルダに関するベスト プラクティス : スケーラビリティ

  • [アーティクル]

 

Microsoft® Exchange Server パブリック フォルダの展開を設計および実装するときは、スケーラビリティを最適化する方法を決定するために、以下の要因を検討してください。

  • パブリック フォルダ データベースの数
  • パブリック フォルダの階層の幅と深さ
  • パブリック フォルダごとのアイテム数
  • パブリック フォルダ データベースごとのユーザー数

ここでは、これらの要素について詳しく説明します。ディスク容量、パブリック フォルダ増加率、および一般的な容量の計画の詳細については、「Exchange パブリック フォルダに関するベスト プラクティス : データを管理する」を参照してください。

パブリック フォルダ データベースの数

展開するパブリック フォルダ データベースの数を計画するときは、次の 2 つのベスト プラクティスを検討してください。

まず、パブリック フォルダを頻繁に使用する大企業のトポロジでは、専用パブリック フォルダ サーバーを展開します。このベスト プラクティスは、サーバー機能を分離して CPU リソースとディスク リソースを専用に割り当てるという一般的なベスト プラクティスに基づいています。

次に、大量の小規模パブリック フォルダ データベースよりも、少量の大規模パブリック フォルダ データベースの方がスケーラビリティが優れており、管理しやすいということに注意します。パブリック フォルダ データベースの数を減らすことで、大量の小規模なデータベースのバックアップおよび復元に必要な時間を節約できます。また、バックグラウンドのレプリケーション トラフィック量も減らすことができます。さらに、オンライン保守についても、少量の大規模なデータベースの方が、大量の小規模なデータベースより迅速に行えます。最後に、アクセス許可とコンテンツへのアクセス権の付与、および効率的なレプリケーションと参照の実装という観点からも、少量のパブリック フォルダ データベースの方が管理が容易です。

少量の大規模なパブリック フォルダ データベースの方が大量の小規模なパブリック データベースよりスケーラビリティが優れ、簡単に管理できるというベスト プラクティスは、組織レベルからトポロジについて検討する場合に特に当てはまります。サーバー レベルから見ると、バックアップや復元のような管理および保守タスクの中には、大量の小規模なデータベースを展開した方が迅速に実行できるものもあります。最終的に、展開するパブリック フォルダ データベースの数は、ビジネス要件に対応したものである必要があります。展開するデータベースの数を決定するときは、レプリケーション トラフィックのコストと、データベースのバックアップ、保守、および復元時間のコストのバランスを取る必要があります。

階層の幅と深さ

パブリック フォルダ階層を設計するときは、環境における階層レプリケーションの影響について認識する必要があります。深いパブリック フォルダ階層は、幅の広い階層よりスケーラビリティが優れています。深い階層は、多数の上位レベル フォルダではなく、垂直方向に入れ子になった多数のフォルダで構成されます。幅の広い階層は、多数の上位レベルフォルダで構成され、垂直方向に入れ子になったサブフォルダの数が少なくなっています。

たとえば、250 個のフォルダが特定の階層でどのように構成されるかを考えてみます。幅の広い階層では、1 つの親フォルダの下に直接 250 個のサブフォルダがある構成が考えられます。深い階層では、5 つの最上位フォルダがあり、それぞれのフォルダに直接 5 つのサブフォルダがある構成が考えられます。それらのサブフォルダの内部に、それぞれ 10 個のサブフォルダがある構成が考えられます。

これらの両方の例でのフォルダ数は、250 (5 * 5 * 10 = 250) です。この場合に、深い階層が幅の広い階層より優れたパフォーマンスを実現しますが、その理由は 2 つあります。1 つ目の理由は、適用されているアクセス許可が異なるフォルダをレプリケーションで処理する方法にあります。2 つ目の理由は、並べ替え、検索、展開などのクライアントの処理は、250 個のサブフォルダを持つフォルダより、10 個のサブフォルダを持つフォルダに対して行った方がコストが低いためです。

深い階層が幅の広い階層よりスケーラビリティが優れていますが、1 つのフォルダで 250 個のサブフォルダを超えないのがベスト プラクティスであるということに注意してください。サブフォルダ数が 250 を超えると、クライアント要求のアクセス時に、許容できないクライアントの動作が発生する可能性が高くなります。

前述したように、階層を実装するときに検討する要因は、ユーザーがパブリック フォルダにアクセスするときに、アクセス許可がクライアントの動作に与える影響です。パブリック フォルダのサブフォルダごとにアクセス制御リスト (ACL) エントリが定義されている場合には、Exchange Server コンピュータがパブリック フォルダのレプリケーションに関する新しいメッセージを受け取るごとに、親パブリック フォルダの ACL を評価して、親パブリック フォルダへの変更を表示できる権限を持っているユーザーを判断する必要があります。親パブリック フォルダに大きな随意アクセス制御リスト (DACL) エントリが存在する場合は、パブリック フォルダの購読側ごとのビューを更新するのに長時間かかることがあります。

note注 :
親フォルダの DACL は、パブリック フォルダのすべてのサブフォルダの DACL の合計で構成されます。

次の条件に当てはまる場合は、解析する必要がある DACL データが何 MB にも及ぶ可能性があります。

  • 1 つの親パブリック フォルダの下に多くのサブフォルダがある。
  • 各サブフォルダには、それぞれ ACL が定義されている。

パブリック フォルダのレプリケーション メッセージが受信されるたびに、パブリック フォルダのすべての購読側の表示を更新するため、この DACL データを解析する必要があります。

したがって、親フォルダにアクセスするユーザー セットに基づいて、パブリック フォルダ階層を構成することをお勧めします。また、複雑なアクセス許可モデルをパブリック フォルダ階層に実装しないでください。ツリーのさまざまなノードで異なるアクセス許可を持つ深いフォルダ階層を既に実装している場合は、クライアントのパフォーマンスを向上させる可能性がある修正プログラムについて、マイクロソフト サポート技術情報の文書「Exchange Server 2003 を実行しているコンピュータでのパブリック フォルダにアクセスする場合、低速応答がユーザーに発生します。」を参照してください。Exchange 2000 Server の同様の修正プログラムについては、サポート技術情報の文書「ユーザーには、Exchange 2000 Server パブリック フォルダ サーバーからの低速応答が発生します。」を参照してください。

また、階層の設計を検討する場合、階層内の内容をレプリケートする方法も検討します。ほとんどの場合、できる限り内容を分散してレプリカの数を減らすのが効果的です。詳細については、「Exchange パブリック フォルダに関するベスト プラクティス : レプリケーションを実装する」を参照してください。

フォルダあたりの項目

ベスト プラクティスとして、パブリック フォルダごとのアイテム数は、5,000 を超えないようにします。フォルダあたりの項目数を管理するには、適宜、期限を構成する必要があります。期限スケジュールを厳しく設定しても、フォルダあたり 5,000 項目という制限に恒常的に達する場合は、パブリック フォルダの件名をサブトピックに分割して、各サブトピックに複数のパブリック フォルダを作成することを検討します。

詳細については、「Exchange パブリック フォルダに関するベスト プラクティス : データを管理する」を参照してください。

パブリック フォルダ データベースごとのユーザー数

1 つのパブリック フォルダ データベースにアクセスできるユーザー数の制限は設定されていませんが、ユーザー数を 10,000 に制限することをお勧めします。この制限を推奨する主な理由は、10,000 人を超えるユーザーが 1 つのデータベースにアクセスすると、Exchange Server の仮想メモリまたはカーネル メモリが不足する可能性があるためです。

特定のサーバー上のパブリック フォルダにアクセスするユーザー数を把握するには、[パフォーマンス] Microsoft 管理コンソール (MMC) スナップイン管理ツールの MSExchangeIS Public パフォーマンス オブジェクトの [クライアント ログオン] と [ピーク クライアント ログオン] を監視します。

負荷の監視、パフォーマンスのチューニング、およびスケーラビリティの詳細については、「Exchange Server 2003 パフォーマンスとスケーラビリティ ガイド」を参照してください。

詳細情報

Exchange Server のパブリック フォルダの詳細については、以下のリソースを参照してください。