パブリック フォルダーのレプリケーションについて

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2015-03-09

パブリック フォルダーのレプリケーションは、効率とフォールト トレランスの目的で、パブリック フォルダーの内容とパブリック フォルダー階層が複数のサーバーにわたってレプリケートされる処理です。別のサーバーにある複数のパブリック フォルダー データベースで 1 つのパブリック フォルダー ツリーをサポートしている場合、Microsoft Exchange はパブリック フォルダーのレプリケーションを利用してデータベースの同期を維持します。 パブリック フォルダーの内容は、特定のフォルダーのレプリカを持つように構成された Exchange ストアにのみ存在します。内容と階層の情報は別々にレプリケートされます。各パブリック フォルダー データベースは階層のコピーを保持し、これには各フォルダーの内容のレプリカを保持する他のパブリック フォルダー データベースの一覧が含まれています。内容のレプリカは、指定したパブリック フォルダー データベース上にのみ存在します。パブリック フォルダーのレプリケーションを構成する方法の詳細については、「パブリック フォルダーのレプリケーションの構成」を参照してください。

パブリック フォルダー データベースは、次の 2 種類のパブリック フォルダー情報をレプリケートします。

• 階層   階層のレプリケーションは、フォルダーのプロパティやフォルダーに関する組織上の情報が変更されたときに行われます。すべてのパブリック フォルダー データベースが階層情報のコピーを持ちます。以下のパブリック フォルダー情報を変更すると、階層のレプリケーションが発生します。

  • フォルダー名

  • レプリカ一覧

  • パブリック フォルダー ツリー内でのフォルダーの位置 (すべての親フォルダーと子フォルダーを含む)

  • アクセス許可

    注意

    階層のレプリケーションは、メールが有効なパブリック フォルダーの電子メール アドレスを変更したときには発生しません。電子メール アドレスは Active Directory のディレクトリ オブジェクトに格納されます。パブリック ストア データベース内のプロパティが変更された場合のみ、階層のレプリケーションが行われます。

• 内容   内容のレプリケーションは、メッセージがパブリック フォルダーに送信されたときや、データが追加されたときに行われます。たとえば、メールが有効なパブリック フォルダーに電子メール メッセージを送信した場合や、パブリック フォルダーに組織フォームを追加した場合に内容のレプリケーションが発生します。内容をレプリケートするには、特定のパブリック フォルダー データベースまたはデータベースの一覧に内容をレプリケートするようにフォルダーを構成する必要があります。指定したデータベースのみが、内容のコピーを持つことになります。内容を含むフォルダーのコピーは、"内容のレプリカ" と呼ばれます。

目次

パブリック フォルダーのレプリケーションの動作

レプリケーション メッセージ

バックフィル要求とバックフィル メッセージ

レプリケーション周期の例

レプリケーションを実装するためのベスト プラクティス

パブリック フォルダーに関連する管理タスクについては、「パブリック フォルダーの管理」を参照してください。

パブリック フォルダーのレプリケーションの動作

パブリック フォルダーまたはそのフォルダーの内容を変更すると、変更されたパブリック フォルダーのレプリカが含まれるパブリック フォルダー データベースから、そのパブリック フォルダーのレプリカをホストする他のパブリック フォルダー データベースに、変更内容を示す電子メール メッセージが送信されます。ネットワークのトラフィックを削減するため、Exchange は複数の変更に関する情報を 1 つの電子メール メッセージに含めます。これらのメッセージに含められる情報の量は、レプリケーション メッセージに対して設定したサイズ制限に応じて変化します。メッセージのサイズが指定した制限を超えると、そのメッセージは個別のレプリケーション メッセージとして送信されます。 Exchange は、他の電子メール メッセージをルーティングする場合と同じ方法でこれらのレプリケーション メッセージをルーティングします。

いくつかのフォルダーに影響を与えるパブリック フォルダー階層を変更した場合は、レプリケーション処理に非常に多くのネットワーク帯域幅が必要になることがあります。たとえば、サーバー間でパブリック フォルダーを移動するには、パブリック フォルダーの移動先のサーバーにレプリカを作成し、階層の変更が元のサーバーにレプリケートされるのを待ち、それから内容が新しいレプリカにレプリケートされるのを待つ必要があります。レプリカが同期されたら、古いサーバーからレプリカを削除する必要があります。レプリカの削除は階層の変更としてレプリケートされる必要があるため、古いサーバーからレプリカを削除することからもネットワーク トラフィックが生成されます。パブリック フォルダー階層に対するこれらの変更がシステムに与える影響の詳細については、このトピックの「状態要求と状態メッセージ」を参照してください。

階層と内容の基本的なレプリケーション処理

次の図とその後の説明文で、パブリック フォルダーの階層と内容がレプリケートされる基本的な処理について説明します。

基本的なレプリケーション処理

この処理の詳細は、以下のとおりです。

1. ユーザーがパブリック フォルダーを変更します。

2. ローカルのパブリック フォルダー データベースに変更が記録されます。

3. パブリック フォルダー データベースに対して設定したレプリケーション間隔によって決定される、次に予定されているレプリケーション周期で、パブリック フォルダー データベースはフォルダーのプロパティを調査し、そのフォルダーのレプリカを格納している他のサーバーを特定します。他のレプリカが存在する場合、データベースはどの情報をレプリケートする必要があるかを特定します。この情報がレプリカに対する更新になります。

   パブリック フォルダーのレプリケーションはオブジェクト ベースです。オブジェクトの 1 つのプロパティが変更された場合は、オブジェクト全体をレプリケートする必要があります。変更をレプリケートするデータベースでは、受け取るレプリカのすべてが最新のものであると見なせないため、オブジェクト全体をレプリケートする必要があります。それぞれの種類のレプリケーションでは、以下を意味することになります。

   • 階層のレプリケーション   パブリック フォルダーが作成または削除されたときや、パブリック フォルダーのプロパティが変更されたとき (レプリカ一覧、クライアントのアクセス許可、説明、管理上のメモ、または格納域の制限に対する変更など) に、新しい階層の変更のレプリケーションが行われます。

   • 内容のレプリケーション   新しいメッセージが投稿されたり既存のメッセージが変更された場合、メッセージ全体とメッセージのプロパティが更新に含められます。

4. パブリック フォルダー データベースが更新に変更番号を割り当てます。

   フォルダーが更新を別のサーバーにレプリケートするときは、この変更番号が更新に含められます。受信側サーバーは次に、変更番号を使用して、更新が新しい変更を表しているかどうかを特定し、足りないデータがあるかどうかを確認します。

5. パブリック フォルダー データベースは更新をレプリケーション メッセージにパックします。メッセージに含まれるすべての更新の変更番号が、"変更番号セット" (CNSet*)* と呼ばれます。

   パブリック フォルダー データベースは更新と一緒に、レプリケーション状態テーブル内に格納されているフォルダーのエントリから得られる、レプリカに以前適用された CNSet などの情報をパックします。レプリケーション状態テーブルの詳細については、このトピックの「レプリケーション状態テーブル」を参照してください。

6. メール トラフィックを削減するため、パブリック フォルダー データベースは複数の階層の更新を 1 つのレプリケーション メッセージにパックします。同様に、同じフォルダーに対する複数の内容の更新を 1 つのレプリケーション メッセージにパックします。ただし、階層の更新を内容の更新と同じレプリケーション メッセージにパックすることはできないので、それぞれの内容のレプリケーション メッセージには 1 つのフォルダーについての更新が含まれます。

7. パブリック フォルダー データベースは、レプリケーション メッセージの宛先を、更新されたフォルダーのレプリカをホストする他のパブリック フォルダー データベースにします。そして、前のレプリケーション周期以降にパックされた他のメッセージと共に、このメッセージを送信します。

   レプリケーション メッセージを配信するため、パブリック フォルダー データベースは Exchange の内部ルーティング コンポーネントを利用します。データベースはトポロジの詳細に基づいてレプリケーション メッセージを分割しようとはしません。フォルダーの内容が変更され、そのフォルダーには他のレプリカが 5 つある場合、データベースは 1 つのレプリケーション メッセージを生成し、これらのレプリカをホストする 5 つのデータベースすべてをメッセージの宛先にします。ルーティング コンポーネントがメッセージのルーティングおよび配信の方法を決定します。

8. パブリック フォルダー データベースがレプリケーション メッセージを受信します。

9. 受信側のパブリック フォルダー データベースは、レプリケーション メッセージから更新と状態情報をアンパックします。

10. データベースは、新しい更新の変更番号を、格納済みの変更番号の一覧と比較し、以前に受信していない更新を識別します。

11. データベースは、新しい更新を適切なフォルダーのレプリカに適用します。

12. 更新されたレプリカごとに、現在の更新の変更番号とレプリケーション メッセージからのフォルダー状態情報に基づいて、レプリケーション状態テーブルが更新されます。

    レプリケーション状態テーブルの情報から、他の CNSet がフォルダーの他のレプリカに適用されたのに、このデータベースのレプリカには適用されていないことがわかると、データベースは足りない CNSet を "バックフィル配列" と呼ばれる場所に記録し、バックフィル要求を送信する準備をします。バックフィル要求の詳細については、このトピックの「バックフィル要求とバックフィル メッセージ」を参照してください。

ページのトップへ

レプリケーション メッセージ

レプリケーション処理では、個々のパブリック フォルダーの Active Directory 属性ではなく、パブリック フォルダー データベースの Active Directory 属性が使用されます。個々のパブリック フォルダーの Active Directory 属性は、フォルダーとの間で通常の電子メール メッセージを送受信するためにのみ使用されます。パブリック フォルダー データベース オブジェクトは自動的に構成されて保持され、Active Directory の構成コンテナーに置かれます。

レプリケーション メッセージは他の電子メール メッセージとは異なり、Exchange ではシステム メッセージとして扱われます。このため、レプリケーション メッセージはユーザーの電子メール メッセージに適用される制限 (サイズ制限や配信制限など) を受けません。

次の表に、Exchange で使用されるさまざまな種類のレプリケーション メッセージの一覧を示します。

パブリック フォルダーのレプリケーション メッセージの種類と用途

レプリケーション状態テーブル

各パブリック フォルダー データベースは、レプリケーション状態テーブルを保持してデータベース内の各レプリカの状態を追跡します。レプリケーション状態テーブルには、以下の情報が格納されます。

• 各レプリカに対する更新を作成するために必要な基本的な情報。

• ローカル データベースで発生した、各レプリカに対する最後の更新に関する情報。更新の変更番号も含まれます。

• フォルダーの他の既知のレプリカすべてに適用された更新のグループ。変更番号によって各グループ内の更新が識別されます。グループ内のすべての更新を表す変更番号のセットは CNSet と呼ばれます。更新情報は、レプリケーション処理の一部として、1 つのデータベースから別のデータベースに渡されます。

次の表に、レプリケーション状態テーブルがどのように機能するかの例を示します。この例では、サーバー A とサーバー B の両方のパブリック フォルダー データベースに、Projects という名前のフォルダーのレプリカがあります。各サーバーのレプリケーション状態テーブルでは、そのサーバー上にあるレプリカの状態だけでなく、他のサーバー上にあるレプリカの状態も追跡されます。この情報を使用して、サーバー A は Projects フォルダーのそのレプリカがサーバー B の Projects フォルダーのレプリカと同期されているかどうかを判断します。サーバー B も同様にサーバー A に対する自身の状態を追跡できます。

サーバー A のレプリケーション状態テーブルのサンプル データ

サーバー B のレプリケーション状態テーブルのサンプル データ

各パブリック フォルダー データベースでは、内容のレプリカが含まれるパブリック フォルダー データベースの一覧と、レプリケーション状態テーブルの情報を組み合わせることで、パブリック フォルダー ツリーをサポートする他のパブリック フォルダー データベースと比較して、そのデータベースがどれだけ最新の状態になっているかを特定することができます。

ページのトップへ

バックフィル要求とバックフィル メッセージ

バックフィルは、パブリック フォルダー データベースで、レプリケート対象のフォルダー (または階層) の更新をすべて受信していないため、不足している更新を別のパブリック フォルダー データベースから取得する必要があると判断されたときに発生します。

バックフィル処理を効率化するため、Exchange は不足している更新に関する情報をバックフィル配列に格納します。

以下のイベントは、パブリック フォルダー データベースにとって、バックフィル処理が必要な足りない更新があることの警告になる場合があります。

• 受信レプリケーション メッセージの状態情報が、メッセージを送信したパブリック フォルダー データベース上のレプリカには、受信側データベース上にない更新が存在することを示している。受信側データベースは、不足している変更番号を識別して、その番号をバックフィル配列に格納します。

• パブリック フォルダー データベースが初めて起動された。新しいデータベースは、階層内の他のデータベースに関する情報を得るために状態要求を送信します。対応する状態メッセージが到着すると、データベースはレプリケーション状態テーブルと、必要に応じてバックフィル配列にデータを格納します。バックフィル配列には、階層のエントリと、データベースでホストする必要がある内容のレプリカのエントリの両方が含まれる可能性があります。

• 受信階層メッセージが、パブリック フォルダー データベースに新しい内容のレプリカを置く必要があることを示している。新しいデータベースは、階層内の他のデータベースにある、このレプリカで使用可能になる可能性がある内容についての情報を得るため、状態要求を送信します。対応する状態メッセージが到着すると、データベースはレプリケーション状態テーブルと、必要に応じてバックフィル配列にデータを格納します。

バックフィル配列には、指定された期間 ("バックフィル タイムアウト" と呼ばれます)、この情報が格納されます。この期間中に後続のレプリケーション メッセージで足りない更新が到着した場合、それらの更新はバックフィル配列から削除されます。次の表に、既定のバックフィル タイムアウト値の一覧を示します。タイムアウト値は、足りない更新がどこに存在するかと、以前に要求した更新かどうかによって異なります。

バックフィル要求で使用される既定のタイムアウト

バックフィルがタイムアウトしても更新が不足している場合、Exchange は 1 つ以上のバックフィル要求を作成し、バックフィルのソースとして使用するサーバーを決定します。

バックフィル ソースとして使用するサーバーを選択するため、Exchange は最初に、そのフォルダーのレプリカがあるすべてのサーバーの一覧を作成し、以下に示す一連の基準に従って一覧を並べ替えます。

1. サーバーの状態に従って並べ替えます。停止していたり、使用できないサーバーは一覧の最後になります。

2. 優先するバックフィル サーバーによって並べ替えます (設定されている場合)。 Exchange は、優先するバックフィル サーバーがないか、Active Directory のパブリック フォルダー データベース オブジェクトを調べます。この設定はあまり使用されません。ほとんどの状況では、バックフィル処理が最も効率的に動作するのは Exchange がバックフィル サーバーを自動的に選択する場合です。ほとんどの Exchange の展開では、優先するバックフィル サーバーは不要です。マイクロソフト カスタマー サービスおよびサポートでは、実際の展開で必要な場合は、優先するバックフィル サーバーを設定するスクリプトを提供できます。

3. トランスポート コストに従って並べ替えます (最低から最高へ)。同じルーティング グループ内のサーバーは、リモートの Active Directory サイトのサーバーより優先されます。

4. Exchange のバージョンに従って並べ替えます (最新バージョンから古いバージョンへ)。

5. そのサーバーで入手できる必要な変更の数に従って並べ替えます (最大から最小へ)。不足している変更がないサーバーは一覧から削除されます。

必要なすべての変更が 1 つのサーバー上にない場合、Exchange は並べ替えられた一覧の次のサーバーを選択し、そのサーバーにもバックフィル要求を送信します。すべての変更が要求されるまで、この手順が繰り返されます。

選択したサーバーがバックフィル要求に応答しない場合、データベースはそのサーバーを使用不可とマークし、選択処理を繰り返します。使用不可としてマークされたサーバーは、一覧の最後に記載されます。

状態要求と状態メッセージ

各レプリケーション メッセージの状態情報に加え、Exchange は状態要求と状態メッセージを使用して、パブリック フォルダーからバックフィル要求を発行する必要があるかどうかを判断します。

パブリック フォルダー データベースは、以下の状況で状態要求を送信します。

• データベースが、フォルダーのレプリカを保持するデータベースの一覧に対する変更を通知された。たとえば、一覧にデータベースを追加したり、一覧からデータベースを削除すると、Exchange は階層の更新メッセージを使用してこの変更をレプリケートします。この場合、データベースは状態要求を送信して、フォルダーのレプリカがあるすべてのデータベースに応答するよう要求します。

• 新しいデータベースが初めて起動された。この場合、データベースはパブリック フォルダーの階層の状態を要求します。データベースは状態要求を送信して、パブリック フォルダー ツリーをサポートするすべてのデータベースに応答するよう要求します。

• Windows Server バックアップ プログラムを使用して復元されたデータベースが復元後に初めて起動した場合。この場合データベースは、パブリック フォルダーの階層と、データベースに内容のレプリカが含まれるすべてのフォルダーの状態を要求します。この状態要求には、必要な応答側として、2 つまたは 3 つのデータベースが指定されます。必要な応答側は、この階層をサポートしているデータベースであり、内部の選択処理に従ってフォルダーの内容を確実に取得できると判断されたソースです。

送信側データベースの特定のフォルダーに関する現在の状態を示すため、パブリック フォルダー データベースは以下の状況で別のデータベースに状態メッセージを送信します。

• 別のデータベースによって送信された状態要求に応答する場合。状態メッセージは以下に該当する場合のみ、要求しているデータベースにのみ送信されます。

  • 状態要求を受信したデータベースが、その要求の必要な応答側の一覧に指定されている。

  • レプリケーション状態テーブルが、状態要求を受信したデータベースに、要求を送信したデータベースに足りない更新があることを示している。

• 後続の更新が存在しない場合に、フォルダーに対する最新の更新を受信してから 24 時間後。データベースが特定のフォルダーの更新を受信するたびに、タイマーは 24 時間にリセットされます。この状態メッセージは、更新されたフォルダーのレプリカを格納している別のパブリック フォルダー データベースに送信されます。

パブリック フォルダー データベースが受信した状態メッセージで、送信側データベースにはフォルダーに関するより新しい情報があることが示されている場合、受信側データベースはバックフィル要求を作成します。変更番号が同じである (または受信側サーバーの変更番号の方が新しい) ことが示されている場合、処理は行われません。たとえば、新しいパブリック フォルダー データベースが初めて起動されると、データベースはパブリック フォルダーの階層をサポートする各データベースに状態要求メッセージを送信します。各データベースは、そのデータベースで追跡していた階層の状態に関する情報を使って応答します。新しいデータベースは、この情報を使用して、保持する必要があるレプリカがあればそれを識別します。これで新しいデータベースは、必要に応じてバックフィル要求を送信し、レプリカの内容を格納することができます。

ページのトップへ

レプリケーション周期の例

次の図は、簡略化した 2 台のサーバーによるシナリオで、パブリック フォルダー データベースに内容のレプリカを追加したときに発生するイベントの順序を示します。この操作によって、パブリック フォルダー データベースがフォルダーのレプリカ一覧に追加されます。各手順の順序は、レプリケーション間隔のタイミングやルーティング トポロジなどの要因に左右されることに注意してください。

パブリック フォルダー データベースにレプリカを追加するときのイベントの順序

この処理の詳細は、以下のとおりです。

1. ExServ01 で作業している管理者が、ExServ01 をフォルダーのレプリカ一覧に追加します。

2. ExServ01 は階層メッセージを送信します。

3. ExServ02 は、フォルダーのレプリカ一覧のローカル コピーに ExServ01 を追加します。

4. ExServ01 は、状態要求を ExServ02 に送信します。

5. ExServ02 は、フォルダーの完全な CNSet が含まれる状態メッセージを ExServ01 に送信します。

6. ExServ01 は、すべてのフォルダーの内容がないことを特定し、バックフィル配列に適切なエントリを記録します。

7. バックフィルのタイムアウトが経過しても内容が不足している場合、ExServ01 はバックフィル要求を作成し、ExServ02 に送信します。

8. ExServ02 は内容のメッセージをまとめて、ExServ01 に送信します。

9. ExServ01 は、受信した内容のメッセージを使用して、フォルダーの内容および関連する追跡情報を更新します。

10. 変更番号がまだ不足しているようであれば、ExServ01 は 24 時間待機してから、更新したバックフィル要求を送信します。ExServ02 以外のサーバーを使用できる場合、ExServ01 はそのサーバーに要求を送信することがあります。

次の図は、簡略化した 2 台のサーバーによるシナリオで、パブリック フォルダー データベースからレプリカを削除したときに発生するイベントの順序を示します。この操作によって、フォルダーのレプリカ一覧からパブリック フォルダー データベースが削除されます。各手順の順序は、トポロジ内のサーバー数などの要因に左右されることに注意してください。

パブリック フォルダー データベースからレプリカを削除するときのイベントの順序

この処理の詳細は、以下のとおりです。

1. ExServ01 で作業している管理者が、ExServ01 をフォルダーのレプリカ一覧から削除します。

2. ExServ01 はそのレプリカ (ExServ01 にあったフォルダーのコピー) に、削除保留 というマークを付けます。

   クライアントは、このデータベースを使用してフォルダーにアクセスできなくなります。

3. ExServ01 は階層メッセージを送信します。

4. ExServ02 は、そのフォルダーが ExServ01 で削除保留の状態にあることを示すため、フォルダーのレプリカ一覧のコピーを更新します。

   ExServ02 は、このフォルダーを探しているクライアントが ExServ01 を参照しないようにします。

5. ExServ01 は、状態要求を ExServ02 に送信します。

6. ExServ02 は、状態メッセージを ExServ01 に送信します。ExServ02 上のレプリカが最新のものではない場合、ExServ02 はバックフィル配列に適切なエントリを格納します。ExServ02 は 5 分以内に、対応するバックフィル要求を ExServ01 に送信します。

7. ExServ01 は、ExServ02 上のフォルダー レプリカに、削除保留のレプリカに含まれるすべての情報が含まれていることを確認します。含まれていない場合、ExServ01 は該当する内容の更新を送信してから手順 5. に戻ります。含まれている場合は手順 8. に進みます。

   この処理により、他のレプリカが存在する限り、1 つのレプリカを削除しても内容が失われないことが保証されます。

8. ExServ01 は、レプリカに 今すぐ削除 というマークを付けます。次の保守サイクルで、このレプリカは ExServ01 から削除されます。

9. ExServ01 は階層メッセージを送信します。

10. ExServ02 は、フォルダーのレプリカ一覧のコピーから ExServ01 を削除します。

ページのトップへ

レプリケーションを実装するためのベスト プラクティス

Exchange のパブリック フォルダーのレプリケーションは、大量のリソースが消費されることがある操作です。レプリケーションを実行するには、ネットワーク、CPU、およびディスクのリソースが必要です。パブリック フォルダーをよく使用する組織では特に、効率的なパブリック フォルダーのレプリケーションを可能にするソリューションを実装することで、Exchange 組織のネットワーク、CPU、およびディスクの負荷が大幅に軽減される可能性があります。

一般的には、組織をまたぐレプリケーションを最小限に抑えることをお勧めします。レプリケーションを最小限にすることで、ネットワーク上を移動するデータの量を最小限に抑えます。さらに、レプリケーションを最小限にすることで、複数のユーザーが複数のレプリカ上にある異なるバージョンのデータにアクセスする可能性を減らす助けになります。ただし、レプリケーションを最小限にすると、パブリック フォルダー データベースで障害が発生した場合にクライアントが使用できるフォルダーのレプリカの数が少なくなるため、パブリック フォルダーのデータの可用性が低下します。特定のパブリック フォルダーにあるデータについては高い可用性が必要であれば、より多くのレプリケーションが必要な場合もあります。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.