高可用性とサイト復元に関する新しい機能

 

適用先: Exchange Server 2010 SP2

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

Microsoft Exchange Server 2010 は、最高レベルのサーバーの可用性とサイトの復元機能を提供する電子メール ソリューションを展開する際のコストと複雑さを軽減します。Exchange Server 2007 の新しい高可用性アーキテクチャは、Exchange 2010 に導入されているネイティブのレプリケーション機能の上に構築されており、高可用性と障害復旧の両方に対応する簡素化され統一されたフレームワークを提供します。Exchange 2010 では、高可用性を Exchange のコア アーキテクチャに統合して、あらゆる規模とあらゆるセグメントの顧客がその組織にメッセージング継続性サービスを経済的に展開できるようにします。

Exchange Server 2007 から得た教訓

Exchange 2007 では、ローカル連続レプリケーション (LCR)、クラスター連続レプリケーション (CCR)、スタンバイ連続レプリケーション (SCR) などの新しいテクノロジを導入することで、高可用性のコストを削減し、サイトの復元をはるかに経済的にしました。それでも、いくつかの課題が残りました。

  • 管理者の中には、Windows フェールオーバー クラスター化の複雑さに威圧された人もいました。

  • 高レベルの稼働時間を実現するには、管理者の高レベルの介入が必要になる可能性があります。

  • 連続レプリケーションは、種類ごとに異なる方法で別個に管理されました。

  • 大規模なメールボックス サーバーでの単一のデータベースの障害から回復するために、メールボックス サーバー上のすべてのユーザーに対してサービスが一時的に中断する結果になることもありました。

  • サイトの復元ソリューションはシームレスではありませんでした。

  • ハブ トランスポート サーバーのトランスポート収集機能は、LCR または CCR 環境のメールボックスに送信されるメッセージしか保護できませんでした。メッセージの処理中にハブ トランスポート サーバーに障害が発生して、回復できない場合、データ損失が発生する可能性がありました。

Exchange 2010 では、高可用性機能をアーキテクチャの深部にまで統合する大幅な革新的変更が行われており、すべての顧客にとってその展開と維持が Exchange 2007 に比べてはるかに低コストで簡単です。このため、組織では、2 台のサーバーだけで完全に冗長な Exchange 組織を展開し、データベースレベルのフェールオーバーを利用できるようになりました。顧客は、Windows フェールオーバー クラスター化の専門家にならなくても、自動的なデータベースレベルのフェールオーバー機能を利用できます。さらに、さほどの複雑さなしで既存の高可用性展開にサイトの復元を追加することもできます。

Exchange 2007 では、Exchange 対応の高可用性とサイトの復元ソリューションをより早く簡単に展開できるように設計された、新しいアーキテクチャ変更が導入されました。これらの機能強化には、統合セットアップ環境、最適化された独創的な構成設定、およびネイティブな Exchange 管理ツールによる高可用性ソリューションのほとんどの要素を管理する機能などがありました。

それでも、Exchange 2007 高可用性ソリューションを管理するために、管理者は、ネットワーク ID の移動やクラスター リソースの管理の概念など、いくつかのクラスター化の概念を習得しておく必要がありました。さらに、クラスター化メールボックス サーバーに関連する問題のトラブルシューティング時に、管理者は Exchange ツールとクラスター ツールを使用して、Exchange とクラスターの 2 つの異なるソースのログとイベントを確認し関連付ける必要がありました。

Exchange 2007 アーキテクチャの他の 2 つの制限要素も、顧客のフィードバックに基づいて再評価され、再設計されました。

  • クラスター化 Exchange 2007 サーバーでは、専用のハードウェアが必要になります。クラスターのノードには、メールボックス サーバーの役割のみをインストールできました。これは、展開の主要コンポーネントの完全な冗長性、つまり、中心的なサーバーの役割 (メールボックスの役割、ハブ トランスポート サーバーの役割、クライアント アクセスの役割) を実現するために、少なくとも 4 台の Exchange サーバーが必要となることを意味していました。

  • Exchange 2007 では、クラスター化メールボックス サーバーのフェールオーバーはサーバー レベルで発生します。結果として、単一データベースの障害が発生した場合、管理者は、クラスター化メールボックス サーバー全体をクラスターの別のノードにフェールオーバーするか (結果的に、影響を受けるデータベース上のメールボックスを使用しているユーザーだけでなく、サーバー上のすべてのユーザーに短いダウンタイムが発生)、データベースのバックアップからの復元中に障害が発生したデータベース上のユーザーをオフラインにしておく (数時間に及ぶ可能性) 必要がありました。

メールボックスの復元

Exchange 2010 は、メールボックスの復元という概念の下で再設計されました。この概念の下では、自動フェールオーバー保護機能がサーバー レベルでなく、個々のメールボックス データベース レベルで提供されるようにアーキテクチャが変更されました。Exchange 2010 では、これをデータベース モビリティと呼びます。この機能およびその他のデータベース キャッシュ アーキテクチャの変更により、フェールオーバー動作は以前のバージョンの Exchange に比べてはるかに短時間で完了するようになりました。たとえば、CCR 環境で Exchange 2007 Service Pack 2 (SP2) を実行しているクラスター化メールボックス サーバーのフェールオーバーは、約 2 分で完了します。それに対して、 Exchange 2010 環境のメールボックス データベースのフェールオーバーは、30 秒以下 (障害が検出された時点からデータベース コピーがマウントされた時点までの測定で、正常でログ再生を含む最新の状態の利用可能なコピーがあるものと仮定) で完了します。データベースレベルのフェールオーバーと大幅に早いフェールオーバー時間が相まって、組織の稼動時間全体が向上します。

Exchange 2010 に組み込まれているメールボックスの復元アーキテクチャによって、組織とそのメッセージング管理者に次のような新たな利点が提供されます。

  • 複数のサーバーの役割を、高可用性を提供するサーバー上に共存させることができます。これにより、小規模な組織では、メールボックス データとサービスの冗長性を提供する 2 台のサーバー構成を展開する一方で、冗長なクライアント アクセスとハブ トランスポート サービスも提供できます。

  • 管理者は、高可用性を実現するために、フェールオーバー クラスターを構築する必要がなくなりました。フェールオーバー クラスターは、管理者には不可視な状態で、Exchange 2010 によって作成されるようになりました。Exchange によって提供された ExRes.dll という名前のクラスター リソース DLL を使用する、以前のバージョンの Exchange クラスターとは異なり、Exchange 2010 はクラスター リソース DLL を必要としたり、使用したりすることはなくなりました。Exchange 2010 はクラスター化アプリケーションではありません。フェールオーバー クラスター コンポーネントの一部だけ、つまり、ハートビート機能とクラスター データベースを使用してデータベース モビリティを提供します。

  • 管理者は、Exchange 2010 の展開後に、Exchange をアンインストールしてから高可用性構成を再展開せずに、Exchange 環境に高可用性を追加できます。

  • Exchange 2010 には、オペレーティング システムのイベントを Exchange のイベントとまとめて組み合わせるイベント ストリームのビューが用意されています。

  • Exchange 2010 にはストレージ グループ オブジェクトが存在せず、すべての Exchange 2010 メールボックス サーバー間でメールボックス データベースを移動できるため、必要に応じて簡単にデータベースを移動できます。

詳細については、「高可用性とサイト復元」を参照してください。

柔軟なメールボックスの保護

Exchange 2010 には、いくつかの新機能と革新的変更が含まれており、これらを正しい展開および構成すると、柔軟なメールボックスの保護機能が得られ、データを従来のようにバックアップする必要がなくなります。Exchange 2010 に組み込まれている高可用性機能を使用して、障害の発生時にダウンタイムとデータ損失を最小限に抑えると、メッセージング システムの総保有コストも削減できます。これらの機能を法的情報保留など他の組み込みの機能と組み合わせると、組織では、従来の時刻を指定したバックアップへの依存度を削減または排除し、それによるコスト削減を実現できます。

Exchange 2010 によって従来の時刻を指定したバックアップから移行できるかどうかを判断すると共に、現在のバックアップ インフラストラクチャのコストを評価することもお勧めします。既存のバックアップ インフラストラクチャを使用して障害からの回復を試みる場合の、エンドユーザーのダウンタイムとデータ損失のコストを考慮してください。また、ハードウェア、インストール、ライセンスの各コスト、およびデータの回復とバックアップの維持に関連する管理コストも含めます。組織の要件によっては、少なくとも 3 つのメールボックス データベース コピーを使用する純粋な Exchange 2010 環境の総保有コストの方が、バックアップを使用する環境の総保有コストより少ない可能性があります。

柔軟性を備えたメールボックス保護の詳細については、「バックアップ、復元、および障害復旧について」を参照してください。

以前のバージョンの Exchange から高可用性に変更する

Exchange 2010 では、そのコア アーキテクチャに数多くの変更が加えられています。Exchange 2010 は、CCR と SCR の主要な可用性機能と復元機能を組み合わせて、オンサイト データ レプリケーションとオフサイト データ レプリケーションの両方を処理する 1 つの高可用性ソリューションを実現しています。メールボックス サーバーをデータベース可用性グループ (DAG) の一部として定義すると、サーバー レベルでなく、個々のメールボックス データベース レベルで自動回復機能を提供できます。各メールボックス データベースには、最大 16 個のコピーを設定できます。Exchange 2010 には、データベース モビリティ増分展開などの他の新しい高可用性概念が導入されています。バックアップや RAID なしの組織の概念も、Exchange 2010 には導入されています。

要約すると、メールボックス サーバーの役割とメールボックス データベースのデータとサービスの可用性の主要な要素は、次のとおりです。

  • Exchange 2010 では、Exchange 2007 で導入された同じ連続レプリケーション テクノロジの強化されたバージョンを使用しています。詳細については、後の「Exchange Server 2007 から連続レプリケーションへの変更」を参照してください。

  • Exchange 2010 には、ストレージ グループは存在しません。代わりに、メールボックス データベース、メールボックス データベースのコピー、およびパブリック フォルダー データベースがあるだけです。Exchange データベースの主要な管理インターフェイスは、Exchange 管理コンソール内で、[サーバーの構成] のメールボックス ノードから [組織の構成] のメールボックス ノードに移動しました。

  • 一部の Windows フェールオーバー クラスター化テクノロジは、Exchange 2010 で使用されていますが、現在 Exchange によって完全に管理されています。高可用性メールボックス サーバーの展開時に、管理者はフェールオーバー クラスター化のいかなる要素もインストール、構築、または構成する必要はありません。

  • 各メールボックス サーバーは、最大 100 個のデータベースをホストでき、各データベースには、最大 16 個のコピーを設定できます。

  • トランスポート収集機能に加えて、シャドウ冗長という新しいハブ トランスポート サーバー機能が追加されました。シャドウ冗長では、メッセージ送信中の期間全体にわたって、メッセージの冗長性が提供されます。このソリューションには、トランスポート収集と同様の手法が採用されています。シャドウ冗長では、トランスポート データベースからのメッセージの削除は、そのメッセージの次ホップすべてが配信を完了するまで、遅延されます。配信の成功が報告されるまでにいずれかの次ホップが失敗した場合、メッセージはその次ホップに対する配信のために再送信されます。シャドウ冗長の詳細については、「シャドウ冗長について」を参照してください。

増分展開

以前のバージョンの Exchange では、メールボックス サーバーの役割のサービス可用性は、Exchange を Windows フェールオーバー クラスターに展開することで実現されていました。クラスターに Exchange を展開するには、最初にフェールオーバー クラスターを構築してから、Exchange プログラム ファイルをインストールする必要がありました。このプロセスでは、クラスター化メールボックス サーバー (以前のバージョンの Exchange では Exchange 仮想サーバー) と呼ばれる特別なメールボックス サーバーが作成されました。Exchange プログラム ファイルを既に非クラスター化サーバーにインストールしていて、クラスター化メールボックス サーバーを導入する場合、新しいハードウェアを使用してクラスターを構築するか、既存のサーバーから Exchange を削除し、フェールオーバー クラスター化をインストールしてから、Exchange を再インストールする必要がありました。

Exchange 2010 には、増分展開という概念が導入されています。この機能を使用すると、Exchange をインストールした後に、すべてのメールボックス サーバーとデータベースのサービスとデータの可用性を展開できます。サービスとデータの冗長性は、Exchange 2010 の DAG やデータベース コピーなどの新機能を使用して実現されます。

データベース可用性グループ

DAG とは、個々のデータベースに影響を与える障害からの自動的なデータベースレベルの回復を提供する、最大 16 台のメールボックス サーバーからなるセットのことです。DAG 内のサーバーは、DAG 内の他のサーバーからのメールボックス データベースのコピーをホストできます。サーバーは DAG に追加されると、DAG 内の他のサーバーと連動して、ディスク障害やサーバー障害などのメールボックス データベースに影響を与える障害からの自動的な回復を提供します。

DAG の詳細については、「データベース可用性グループについて」を参照してください。

メールボックス データベース コピー

Exchange 2007 で初めて導入された高可用性とサイト復元の機能は、Exchange 2010 ではデータベース コピーの作成と保持に使用されます。これにより、Exchange 2010 での可用性の目標が達成できます。また Exchange 2010 では、Exchange によってデータベース レベルのフェールオーバーが管理されるという、データベース モビリティの概念が導入されています。

データベース モビリティは、データベースをサーバーから切断し、1 つのデータベースで最大 16 個のコピーのサポートを追加し、データベース コピーをデータベースにネイティブで追加できる環境を提供します。Exchange 2007 では、データベースの移植性と呼ばれる機能によって、サーバー間でメールボックス データベースを移動することもできました。ただし、データベースの移植性とデータベース モビリティの大きな違いは、データベース モビリティでは、データベースのすべてのコピーに同じ GUID が設定されることです。

データベース モビリティの他の主要な特徴は次のとおりです。

  • Exchange 2010 からストレージ グループが削除されたため、連続レプリケーションはデータベース レベルで動作するようになりました。Exchange 2010 では、トランザクション ログは、1 つ以上のメールボックス サーバーにレプリケートされ、これらのサーバーに格納されているメールボックス データベースのコピーに再生されます。

  • フェールオーバーは、データベース レベルまたはサーバー レベルで発生する可能性がある自動アクティブ化プロセスです。スイッチオーバーは、データベース、サーバー、またはセンター (サイト) レベルで実行できる手動アクティブ化プロセスです。

  • Exchange 2010 のデータベース名は、Exchange 組織内で一意である必要があります。

  • 1 つ以上のデータベース コピーでメールボックス データベースを構成した場合、すべてのデータベース コピーの完全パスは、コピーをホストしているすべてのメールボックス サーバーで同一である必要があります。

  • Exchange 対応のボリューム シャドウ コピー サービス (VSS) ベースのバックアップ アプリケーションを使用すると、任意のメールボックス データベース コピー (アクティブ コピーまたは任意のパッシブ コピー) をバックアップできます。

メールボックス データベース コピーの詳細については、「メールボックス データベース コピーについて」を参照してください。

Exchange Server 2007 から連続レプリケーションへの変更

以前 CCR および SCR に備わっていた基盤となる連続レプリケート テクノロジは、Exchange 2010 にも残り、さらに進化して、データベース コピー、データベース モビリティ、DAG などの新しい高可用性機能をサポートできるようになりました。これらの新しいアーキテクチャ変更のいくつかについて、次に簡単に説明します。

  • Exchange 2010 からストレージ グループが削除されたため、連続レプリケーションはデータベース レベルで動作するようになりました。Exchange 2010 では、引き続き Extensible Storage Engine (ESE) データベースが使用されています。このデータベースは、1 つ以上の他の場所にレプリケートされ、メールボックス データベースの 1 つ以上のコピーに再生されるトランザクション ログを生成します。

  • Microsoft Exchange の Exchange 2007 レプリケーション サービスによって実行されていたログ再生機能は、Exchange 2010 バージョンの Microsoft Exchange Information Store サービス (store.exe) に移動されたため、フェールオーバーとスイッチオーバーによるパフォーマンスへの影響はなくなりました (新しいデータベース キャッシュが使用されるようになったため)。フェールオーバーまたはスイッチオーバーが発生すると、アクティブ化されたデータベースにすぐに使用できるウォーム キャッシュが設定されます。

  • ログ配布とシードでは、データ転送にサーバー メッセージ ブロック (SMB) を使用しないようになりました。Exchange 2010 連続レプリケーションでは、データ転送に 1 人の管理者が定義した TCP ポートを使用します。また、Exchange 2010 には、データ ストリームに対するネットワーク暗号化と圧縮の組み込みオプションが含まれています。

  • ログ配布では、パッシブ コピーがアクティブ コピーから閉じられたログ ファイルをプルするプル モデルを使用しないようになりました。代わりに、アクティブ コピーがログ ファイルを構成済みの各パッシブ コピーにプッシュします。

  • シードは、データベースのアクティブ コピーのみ使用するように制限されなくなりました。メールボックス データベースのパッシブ コピーは、データベース コピーのシードおよび再シードのソースとして指定できるようになりました。

  • データベースのコピーは、メールボックス データベースにのみ提供されます。パブリック フォルダー データベースの冗長性と高可用性を達成するために、パブリック フォルダー レプリケーションを使用することをお勧めします。同じクラスター内にパブリック フォルダー データベースの複数のコピーが存在できなかった CCR とは異なり、各 DAG メンバーがパブリック フォルダー データベースをホストすることが可能で、パブリック フォルダー レプリケーションを使用して、DAG メンバー上にホストされたパブリック フォルダー データベース間で、パブリック フォルダー レプリケーションを使用してパブリック フォルダーをレプリケートできます。

  • Microsoft Exchange Replication サービスの LogReplayer コンポーネントには、コピー キューの長さが指定されたしきい値を超えて増加した場合にログの再生を中断する新しいロジックが含まれています。コピー キューのログの数が、パッシブ データベース コピーにコピー済みのログ ファイルの数よりも多くなっているにもかかわらず、パッシブ コピーによって検査されていない場合、Microsoft Exchange Replication Service はパッシブ コピーに対するログの再生を中断して、イベント ログに警告イベント 4110 を記録します。コピー キューのログ ファイルの数が、未検査のコピー済みログ ファイルの数を下回ると、Microsoft Exchange Replication Service はパッシブ コピーの再生を再開し、イベント ログに情報イベント 4111 を記録します。

Exchange 2007 連続レプリケーションで使用されていたいくつかの概念も、Exchange 2010 に残ります。これらの中には、フェールオーバー管理分岐データベース自動マウント ダイヤルの使用、およびパブリック ネットワークとプライベート ネットワークの使用といった概念も含まれています。

DAG 内でハブ トランスポートとメールボックスが共存している場合のルーティング動作の変更

ハブ トランスポート サーバーが DAG のメンバーであるメールボックス サーバーと共存している場合、両方のサーバーの役割の復元機能によって、そのサーバーのユーザーが送受信するメッセージに必要な保護が提供されるようにルーティング動作が変更されています。ハブ トランスポート サーバーの役割は、ハブ トランスポート サーバーが DAG メンバーでもあり、そのサーバーにローカルにマウントされたメールボックス データベースのコピーがある場合、ローカル メールボックス サーバー宛のメッセージを同じサイトの別のハブ トランスポート サーバーに再ルーティングするように変更されました。メッセージを異なるハブ トランスポート サーバーのトランスポート収集に配置するために、この余分なホップが追加されました。

たとえば、EX1 がハブ トランスポートとメールボックスの役割をホストしていて、DAG のメンバーであるとします。EX1 のトランスポートに、そのメールボックスも EX1 上にある受信者宛のメッセージが到着した場合、トランスポートでは、メッセージをサイト内の別のハブ トランスポート サーバー (たとえば、EX2) に再ルーティングし、そのサーバーがメッセージを EX1 上のメールボックスに配信します。

Microsoft Exchange メール発信サービスに関しても、第 2 の同様の動作変更があります。このサービスは、メールボックスとハブ トランスポート サーバーが DAG のメンバーである場合、メッセージをローカルのハブ トランスポートの役割に発信しないように変更されました。このシナリオでのトランスポートの動作としては、同じ Active Directory サイト内の他のハブ トランスポート サーバー全体で発信要求を負荷分散し、同じサイトに他の利用可能なハブ トランスポート サーバーがない場合、ローカルのハブ トランスポート サーバーにフォールバックします。

エンド ツー エンドの可用性

Exchange 2010 には、システムのエンド ツー エンドの可用性を向上させるように設計された多くの機能も含まれています。これらの機能には以下のものがあります。

  • トランスポートの復元

  • オンライン移動メールボックス

  • Exchange ネイティブ データ保護

  • 増分再同期

  • サードパーティ レプリケーション API

トランスポートの復元

Exchange 2007 では、ハブ トランスポート サーバーのトランスポート収集機能が導入されました。このトランスポート収集では、そのメールボックスが CCR (および Exchange 2007 SP1 と LCR) 環境にあった受信者に配信されたメッセージのキューが維持されます。この機能は、データ損失の量を抑えながら、別のノード上のクラスター化メールボックス サーバーを自動的にオンラインにするオプションを管理者に提供することで、データ損失を防止するように設計されていました。これは、損失を伴うフェールオーバーと呼ばれます。損失を伴うフェールオーバーが発生すると、システムは、これらの電子メール メッセージがまだ格納されているトランスポート収集を利用して、フェールオーバーしたクラスター化メールボックス サーバー上のユーザーに最近送信された電子メール メッセージを自動的に再配信します。このソリューションは損失を伴うフェールオーバーで失われるデータの量を最小化するのに役立ちましたが、このソリューションではサイト内のデータ損失だけが保護され、転送中のメッセージに対する保護は提供されませんでした。

Exchange 2010 では、両方の問題に対処するコア アーキテクチャの変更が導入されています。DAG は Active Directory サイト全体に分散できるため、個々のメールボックス データベースを Active Directory サイト間で移動できます。この設計変更のため、損失を伴うデータベース フェールオーバー時のトランスポート収集の再配信要求は、データベースの元の Active Directory サイトと新しいサイトの両方のハブ トランスポート サーバーに発行されるようになりました。

トランスポート収集に対する他の大幅な変更点の 1 つとして、レプリケーション パイプラインからのフィードバックの受信が挙げられます。トランスポート収集内のメッセージがすべてのメールボックス データベース コピーにレプリケートされると、トランスポート収集から削除されます。これにより、トランスポート収集には、レプリケートされていないデータのみ保持されるようになります。

トランスポート収集機能に加えて、シャドウ冗長という新しいハブ トランスポート サーバー機能が追加されました。シャドウ冗長では、メッセージ送信中の期間全体にわたって、メッセージの冗長性が提供されます。このソリューションでは、トランスポート収集と同様の手法が使用されています。シャドウ冗長では、トランスポート データベースからのメッセージの削除は、そのメッセージの次ホップすべてが配信を完了するまで、遅延されます。配信の成功が報告される前にいずれかの次ホップが失敗した場合、メッセージはその次ホップに対する配信のために再送信されます。シャドウ冗長の詳細については、「シャドウ冗長について」を参照してください。

オンライン移動メールボックス

Exchange 2010 には、メールボックスを非同期的に移動できる新しい機能が含まれています。Exchange 2007 では、Move-Mailbox コマンドレットを使用してメールボックスを移動した場合、このコマンドレットはソース データベースとターゲット データベースの両方にログインして、あるメールボックスから別のメールボックスに内容を移動していました。コマンドレットに移動操作を実行させる場合、次のようにいくつかの欠点がありました。

  • メールボックスの移動は、通常、完了までに数時間かかり、移動中、ユーザーはメールボックスにアクセスできませんでした。

  • Move-Mailbox コマンドレットの実行に使用したコマンド ウィンドウを閉じた場合、移動は終了し、最初からやり直す必要がありました。

  • 移動の実行に使用するコンピューターがデータ転送に参加していました。管理者がワークステーションからコマンドレットを実行した場合、メールボックス データは、ソース サーバーから管理者のワークステーション、次にターゲット サーバーへとフローしました。

Exchange 2010 の新しい移動要求コマンドレットを使用すると、非同期移動を実行できます。Exchange 2007 とは異なり、このコマンドレットは、実際の移動を実行しません。移動は、クライアント アクセス サーバー上で実行される新しいサービスである、Microsoft Exchange Mailbox Replication Service によって実行されます。New-MoveRequest コマンドレットが要求を Mailbox Replication Service に送信します。オンライン移動メールボックスの詳細については、「移動要求について」を参照してください。

Exchange ネイティブ データ保護

Exchange 2010 のコア アーキテクチャに対する変更には、メールボックス データベースとそれに含まれるメールボックスの保護方法に直接的な影響を与えるものがいくつかあります。

1 つの大幅な変更は、ストレージ グループの削除です。Exchange 2010 では、各データベースは、一連の 1 MB (メガバイト) ログ ファイルで表される単一ログ ストリームに関連付けられます。各サーバーは、最大 100 個のデータベースをホストできます。

Exchange 2010 に関するもう 1 つの大幅な変更は、データベースが特定のメールボックス サーバーに密接に結び付けられなくなったことです。データベース モビリティでは、データベースを複数の異なるサーバーにレプリケートすることで、システムの連続レプリケーションの用途が拡張されます。これにより、データベースの保護と可用性が向上します。障害が発生した場合、データベースのコピーを持つ他のサーバーがデータベースをマウントできます。

データベースの複数のコピーを複数のサーバーでホストできることは、十分な数のデータベース コピーがある場合、これらのコピーをバックアップとして使用できることを意味します。この方法の詳細については、「バックアップ、復元、および障害復旧について」を参照してください。

増分再同期

Exchange 2007 では、消失ログの復元 (LLR) と増分再シードという概念が導入されました。LLR は ESE の内部コンポーネントで、これにより、最後に生成されたトランザクション ログ ファイルが 1 つ以上失われたり破損したりした場合でも、Exchange メールボックス データベースを回復することができます。LLR により、最近生成されたログ ファイルを使用できない場合でも、メールボックス データベースをマウントできます。LLR は、指定した世代数のログが作成されるまでデータベースへの書き込みを遅らせることによって機能します。LLR はデータベース ファイルに対する最新の更新を短時間遅らせます。書き込みを遅らせる時間は、ログが生成される速度によって異なります。

注意

LLR は、すべての Exchange 2010 メールボックス データベースに対して 1 つのログ ファイルにハードコードされます。

増分再シードでは、LLR の遅延再生機能に依存することで、ソースとターゲットのストレート グループ間のトランザクション ログ ストリームでの分岐を修正できました。増分再シードでは、分岐ログの再生後に、データベースのパッシブ コピーの分岐を修正する方法がなく、強制的に完全再シードを行う必要がありました。

Exchange 2010 では、次の状況でデータベース コピーの分岐を自動的に修正する機能の新しい名前として、増分再同期が採用されています。

  • データベースのすべての構成済みコピーの自動フェールオーバーの後

  • 新しいコピーを有効にし、そのコピーの場所に一部のデータベースとログ ファイルが既に存在している場合

  • Microsoft Exchange Replication Service の中断または再開後に、レプリケーションを再開する場合

アクティブなデータベースとそのデータベースのコピー間に分岐が検出された場合、増分再同期は次のタスクを実行します。

  • ログ ファイル ストリームを履歴順に検索し、分岐点を見つけます。

  • 分岐されたコピーの変更されたデータベース ページを見つけます。

  • アクティブ コピーの変更されたページを読み取り、アクティブ コピーから必要なログ ファイルをコピーします。

  • 分岐されたコピーに対してデータベース ページの変更を適用します。

  • 分岐されたコピーで回復を実行し、必要なログ ファイルをデータベース コピーに再生します。

サードパーティ レプリケーション API

Exchange 2010 には、組織で組み込みの連続レプリケーション機能の代わりに、サードパーティ同期レプリケーション ソリューションを使用できる、新しいサード パーティ レプリケーション API も備わっています。Exchange 2010 のパートナー製品の詳細については、Exchange 2010 パートナー Web サイトを参照してください (このサイトは英語の場合があります)。サード パーティ レプリケーション API の情報が必要なパートナーの場合、マイクロソフトの営業担当者にお問い合わせください。

Exchange Server 2007 から削除された機能

Exchange 2007 および Exchange 2007 SP1 の次の機能は、Exchange 2010 ではなくなりました。置き換え機能は、表中で指摘しています。

機能

置き換え機能

クラスター連続レプリケーション (CCR)

データベース可用性のグループおよびメールボックス データベース コピー

スタンバイ連続レプリケーション (SCR)

データベース可用性のグループおよびメールボックス データベース コピー

ローカル連続レプリケーション (LCR)

データベース可用性のグループおよびメールボックス データベース コピー

シングル コピー クラスター (SCC)

データベース可用性のグループおよびメールボックス データベース コピー、SCC で使用されていたサードパーティー データ レプリケーションを置き換えられる、組み込みのサードパーティー同期 API

クラスター化メールボックス サーバー

データベース可用性のグループおよびメールボックス データベース コピー

ストレージ グループ

データベース

回復用ストレージ グループ

回復用データベース

 © 2010 Microsoft Corporation.All rights reserved.