次の方法で共有

高可用性とサイトの復元について

  • [アーティクル]

 

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

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

メールボックス データベースおよびそれに含まれるデータは、すべての Exchange 組織にとって最も重要なコンポーネントの 1 つ (おそらく最も重要) です。Microsoft Exchange Server 2010 では、メールボックス データベースの高可用性とサイト復元を構成することで、メールボックス データベースおよびそれに含まれるデータを保護できます。Exchange 2010 では、より高レベルのエンド ツー エンドの可用性を実現し、大容量のメールボックスをサポートすると同時に、可用性の高いサイト復元メッセージング ソリューションの展開におけるコストと複雑さを軽減しています。Exchange 2010 の新しい高可用性アーキテクチャは、Exchange Server 2007 に導入されているネイティブのレプリケーション機能の上に構築されており、高可用性とサイト復元に対応する簡素化され統一されたフレームワークを提供します。Exchange 2010 では、高可用性を Exchange のコア アーキテクチャに統合して、あらゆる規模とあらゆるセグメントの顧客がその組織にメッセージング継続性サービスを経済的に展開します。

高可用性とサイト復元に関連する管理タスクについては、「高可用性とサイト復元の管理」を参照してください。

目次

主要な関連用語

Exchange Server 2010 ソリューションの主な特性

データベース モビリティ

増分展開

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

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

Active Manager

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

メールボックス サーバー以外の役割に関する高可用性

サイトの復元

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

主要な関連用語

次の用語が適用されます。

  • アドレス帳サービス
    Microsoft Outlook クライアントのディレクトリ アクセス エンドポイントを提供するクライアント アクセス サーバーのサービスです。
  • 連続レプリケーション - ブロック モード
    SP1 での新しい連続レプリケーションの形式です。この形式で各更新プログラムがアクティブ データベース コピーのアクティブ ログ バッファーに書き込まれると、各パッシブ メールボックス コピーのログ バッファーにも配布されます。ログ バッファーがいっぱいの場合は、各データベース コピーが、生成シーケンスに次のログファイルを構築、検査、および作成します。
  • 連続レプリケーション - ファイル モード
    Exchange 2010 の RTM (Release To Manufacturing) 版での、連続レプリケーションの元の形式の名前です。これによって、閉じられたトランザクション ログファイルが、アクティブ データベース コピーから 1 つ以上のパッシブ データベース コピーにプッシュされます。
  • データベース可用性グループ (DAG)
    一連のレプリケーション データベースをホストする最大 16 台の Exchange 2010 メールボックス サーバーのグループです。
  • データベース モビリティ
    1 つの Exchange 2010 メールボックス データベースを、他の Exchange 2010 メールボックス サーバーにレプリケートおよびマウントする機能です。
  • 障害回復
    障害から回復するための手動による処理です。この障害には、1 つのアイテムに影響するものと、物理的な場所全体に影響するものとがあります。
  • Exchange サード パーティ レプリケーション API
    データベース可用性グループで、連続レプリケーションの代わりにサード パーティの同期レプリケーションを使用できるようにする Exchange の API です。
  • 高可用性
    サービスの可用性、データの可用性、およびサービスまたはデータに影響する障害 (ネットワーク、ストレージ、またはサーバーの障害など) からの自動回復を提供するソリューションです。
  • 増分展開
    Exchange 2010 のインストール後に高い可用性とサイト復元を展開する機能です。
  • 時間差メールボックス データベース コピー
    ログ再生ラグ タイムが 0 より大きい、パッシブなメールボックス データベース コピーです。
  • メールボックス データベース コピー
    アクティブまたはパッシブのいずれかのメールボックス データベース (.edb ファイルとログ) です。
  • メールボックスの復元
    Exchange 2010 の統合された高可用性とサイト復元ソリューションの名前です。
  • RPC クライアント アクセス サービス
    Microsoft Outlook クライアントの MAPI エンドポイントを提供するクライアント アクセス サーバーのサービスです。
  • サイトの復元
    プライマリ データセンターが組織の必要を満たすレベルの十分なサービスを提供することができなくなった場合に、代替またはスタンバイ データセンターをアクティブ化する際に使用する手動障害回復プロセス。これには、回復、復元、または再作成されたプライマリ データセンターを再アクティブ化するプロセスも含まれます。高可用性のメッセージング ソリューションを構成し、Exchange 2010 の組み込み機能を使用してサイトを復元できます。
  • シャドウ冗長
    メッセージ送信中の期間全体にわたって冗長性を提供するトランスポート サーバーの機能です。
  • *over (スター オーバーと読みます)
    切り替えおよびフェールオーバーの短縮名です。切り替えとは、1 つ以上のデータベース コピーを手動でアクティブ化することです。フェールオーバーとは、障害発生後に、1 つ以上のデータベース コピーを自動的にアクティブ化することです。

ページのトップへ

Exchange Server 2010 ソリューションの主な特性

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

  • Windows フェールオーバー クラスタリングは複雑で、混乱を招く可能性がありました。

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

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

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

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

Exchange 2010 では、高可用性をアーキテクチャに統合するという大幅で重要な変更が行われています。これにより、以前のバージョンの Exchange に比べて展開と保守が低コストで簡単に行えるようになっています。Exchange 2010 には、高可用性とサイト復元の両方を実現するための、新しい統合プラットフォームが含まれています。

Exchange 2010 での大幅で重要な変更によって、連続レプリケーション使用時のメールボックス データベースの推奨最大サイズは、Exchange 2007 では 200 GB だったのが、Exchange 2010 では 2 TB にまで増加しています。大容量のメールボックス (2 ～ 10 GB) を重視する企業が増えるにつれ、非常に大きなデータベース サイズが早期に実現する可能性があります。大容量データベースをサポートするには、バックアップと復元などの従来の回復機構から、データ レプリケーションとサーバーの冗長性などのより新しい高速な保護方法へと移行していくことが必要となります。最終的に、メールボックス データベースのサイズは、Exchange 2010 計画プロセス時に導き出される多くの要因によって決まります。メールボックスおよびメールボックス サーバーの詳細な計画ガイダンスについては、「メールボックス サーバーの記憶域設計」を参照してください。

Exchange 2010 は CCR と SCR の重要な機能である可用性と復元を 1 つのソリューションに結合し、サイト内外のデータ レプリケーションを処理します。メールボックス サーバーを DAG の一部として定義すると、サーバー レベルでなく、メールボックス データベース レベルで自動回復機能を提供できます。Exchange 2010 には、データベース モビリティや増分展開などの他の新しい高可用性概念が導入されています。

ページのトップへ

データベース モビリティ

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

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

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

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

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

Exchange 2010 は、データベース モビリティという概念に基づいて設計されています。データベース モビリティでは、グループ化されている複数の異なるサーバーにデータベースをレプリケートすることで、システムの連続レプリケーションの用途を拡大します。このモデルにより、データベースの保護と可用性が向上します。このモデルでは、サーバー レベルでなくメールボックス データベース レベルで、自動フェールオーバー保護と手動切り替え制御が提供されています。

障害が発生した場合、データベースのコピーを持つ他のサーバーがデータベースをマウントできます。この機能およびその他のアーキテクチャ変更により、フェールオーバー動作は以前のバージョンの Exchange に比べてはるかに短時間で完了するようになりました。たとえば、Exchange 2007 Service Pack 1 を実行している CCR 環境でのクラスター化メールボックス サーバーのフェールオーバーは、(クラスター化メールボックス サーバーの IP アドレスが変更されないサイト内の障害の場合) 完了に約 2 分間かかります。それに対して、Exchange 2010 環境のメールボックス データベースのフェールオーバーは、30 秒 (障害が検出された時点からデータベース コピーがマウントされた時点までの測定で、正常でログ再生を含む最新の状態のコピーがあるものと仮定) で完了します。データベースレベルのフェールオーバーと大幅に早いフェールオーバー時間が相まって、組織の稼働時間全体が向上します。

ページのトップへ

増分展開

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

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

ページのトップへ

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

DAG は、Exchange 2010 に組み込まれている、高可用性およびサイト復元のフレームワークの基本コンポーネントです。DAG とは、一連のデータベースをホストし、個々のデータベースに影響を与える障害からのデータベース レベルでの自動回復を提供する、最大 16 台のメールボックス サーバーからなるグループのことです。DAG 内のサーバーは、DAG 内の他のサーバーからのメールボックス データベースのコピーをホストできます。サーバーは DAG に追加されると、DAG 内の他のサーバーと連動して、ディスク障害やサーバー障害などのメールボックス データベースに影響を与える障害からの自動的な回復を提供します。

Exchange 2007 では連続レプリケーションと呼ばれる組み込みのデータ レプリケーション テクノロジが導入されました。連続レプリケーションは、ローカル、クラスター、スタンバイの 3 つの形式で使用可能でした。高可用性を備えた Exchange インフラストラクチャの展開コストが大幅に軽減され、以前のバージョンの Exchange の展開および管理の方法が大きく改善されました。このようにコスト削減効果と改良点はありましたが、Exchange 2007 の高可用性インフラストラクチャの実行には、依然として多くの時間と専門知識が必要でした。これは、Exchange と Windows のフェールオーバー クラスター化の統合が、シームレスではなかったためです。またお客様からは、電子メール データの遠隔地へのレプリケート、および Exchange 環境のサイト レベルの障害からの保護に関して、より簡単な方法が求められていました。

Exchange 2010 では、Exchange 2007 と同じ連続レプリケーション テクノロジが使用されています。Exchange 2010 では、サイト内データ レプリケーション (CCR) とサイト外データ レプリケーション (SCR) が、データベース可用性グループ (DAG) という 1 つのフレームワークに結合されています。サーバーを DAG に追加した後、レプリケートされたデータベース コピーを段階的に (全部で 16 個まで) 追加できます。Exchange 2010 はこれらのコピーを自動的に切り替えて可用性を維持します。

Exchange 2007 ではクラスター化メールボックス サーバーに専用のハードウェアが必要でしたが、DAG 内のメールボックス サーバーでは、2 台のサーバーだけで Exchange のサービスとデータの完全な冗長性を持ちつつ、他の Exchange の役割 (クライアント アクセス、ハブ トランスポート、およびユニファイド メッセージング) をホストできます。

また、この新しい高可用性アーキテクチャによって、(ディスク レベル、サーバー レベル、データセンター レベルなど) さまざまな障害からの回復が簡単になり、アーキテクチャがさまざまな種類のストレージに展開可能となっています。

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

ページのトップへ

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

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

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

データベース コピーをアクティブなメールボックス データベースとして設定することは、切り替えと呼ばれます。データベースに影響する障害が発生して新しいデータベースがアクティブ コピーとなる場合、このプロセスはフェールオーバーと呼ばれています。またこのプロセスは、障害の発生したサーバー上でオンラインの状態にあったデータベースが、1 つ以上のサーバーでオンラインとなるサーバー障害も意味します。切り替えまたはフェールオーバーのいずれかが発生すると、他の Exchange 2010 サーバーの役割がほぼ即座に切り替えを検知し、クライアントとメッセージング トラフィックを新しいアクティブ データベースにリダイレクトします。

たとえば、基礎記憶域の障害が原因で DAG 内のアクティブ データベースに障害が発生すると、Active Manager によって DAG 内の別のメールボックス サーバー上のデータベース コピーにフェールオーバーされ、自動的に回復します。データベースが自動マウントの条件から外れており、自動的にマウントできない場合は、データベースのフェールオーバーを手動で実行できます。

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

ページのトップへ

Active Manager

Exchange 2007 以前のバージョンでは、Exchange はメールボックス サーバーの高可用性ソリューションのインストール、実装、および管理にクラスター リソース管理モデルを使用していました。従来、高可用性メールボックス サーバーの構築には、まず Windows フェールオーバー クラスターを構築し、次に Exchange セットアップをクラスター化モードで実行する必要がありました。このモードでは、Exchange クラスター リソースの DLL ファイルである exres.dll が登録され、クラスター化メールボックス サーバー (従来のバージョンでは Exchange 仮想サーバーと呼ばれます) の作成が許可されます。従来の共有ストレージ クラスターまたはシングル コピー クラスターを展開する際、ストレージの構成には、フェールオーバー クラスターの形成の前後と、クラスター化メールボックス サーバーとストレージ グループの形成後に追加の手順が必要でした。

Exchange 2010 には Active Manager という新しいコンポーネントが含まれ、以前のバージョンの Exchange ではクラスター サービスとの統合によって提供されていたリソース モデルとフェールオーバー管理機能の代わりとなる機能が提供されます。Active Manager の詳細については、「アクティブ マネージャーについて」を参照してください。

ページのトップへ

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

Exchange 2010 のコア アーキテクチャには、Exchange での高可用性の構成方法、およびサイト回復の実行方法に直接影響を与える変更がいくつか加えられています。主な変更の 1 つに、クラスター化メールボックス サーバーの削除および Windows フェールオーバー クラスター リソース モデルの使用があります。その他の主な変更としては、データベースのグローバリゼーション、および Exchange 2007 で最初に導入された組み込みの連続レプリケーション テクノロジへの拡張があります。

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

Exchange 2010 では、Exchange はもはやクラスター化されたアプリケーションではなく、Exchange の高可用性のためにクラスター リソース モデルが使用されることはありません。Exres.dll およびすべての Exchange クラスター リソースも、クラスター化メールボックス サーバーも含め、存在しなくなっています。代わりに、Exchange 2010 では独自の内部の高可用性モデルが使用されます。Windows フェールオーバー クラスター化のコンポーネントの一部は使用されていますが、Exchange 2010 の他の機能に統合されています。

データベースのグローバリゼーション

Exchange 2010 では、データベースは、順番に名前の付けられた一連の 1 MB (メガバイト) のログ ファイルで表される、単一の専用ログ ストリームに関連付けられます。ストレージ グループという概念も、Exchange 2010 からなくなりました。以上の変更の結果、Exchange データベースは専用ログ ストリームを持ち、他のデータベースとログ ストリームを共有しなくなっています。

以前のバージョンの Exchange とは異なり、データベースが特定のメールボックス サーバーと緊密に関連しなくなっています。また、データベースの存在するメールボックス サーバーによってそのデータベースが識別されることも、サーバー名がデータベース ID の一部となることもありません。以上の変更の結果、データベースは Active Directory および各 Exchange 組織内のグローバル オブジェクトとなりました。Exchange 管理コンソールを使用する場合、データベースは [組織の構成] ノードの下の [メールボックス] ノードで管理されます。

各メールボックス サーバーは、最大 100 個のデータベース (アクティブ データベースとパッシブ データベースの合計数) をホストできます。データベースの合計数は、サーバー上のアクティブ データベースとパッシブ データベースを合わせた数となります。回復用データベースはデータベース制限の 100 にカウントされません。

Exchange 2010 RTM での連続レプリケーションの変更

Exchange 2007 で導入された連続レプリケーション テクノロジは、Exchange 2010 でも使用できます。ただしこの機能は、新たに高可用性機能とスケーラビリティの向上をサポートするため、大幅に進化しました。以下のようなアーキテクチャ上の変更が行われています。

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

  • ログ配布にサーバー メッセージ ブロック (SMB) と Windows ファイル システム通知が使用されなくなりました。ログ配布では、パッシブ コピーがアクティブ コピーから閉じられたログ ファイルをプルするプル モデルを使用しないようになりました。代わりに、パッシブ コピーは TCP ベースの通知を使用して、パッシブ コピーがどのログ ファイルを必要とするかについて、アクティブ コピーに通知します。次にアクティブ コピーは、TCP ソケット経由でログ ファイルを各構成済みパッシブ コピーにプッシュします。

  • Exchange 2010 の連続レプリケーションは、データ転送に 1 人の管理者が定義した TCP ポートを使用します。また、Exchange 2010 には、データ ストリームに対するネットワーク暗号化と圧縮の組み込みオプションが含まれています。

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

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

  • Exchange 2007 では、Microsoft Exchange Replication サービスが、ログのパッシブ データベース コピーへの再生を実行していました。パッシブ コピーがアクティブ化されると、再生処理の結果 Microsoft Exchange Replication サービスによって構築されたデータベース キャッシュは、Microsoft Exchange Information Store サービスがデータベースをマウントする時に失われます。これにより、データベース キャッシュはいわゆるコールド状態となります。この状態では、キャッシュの読み取り/書き込み操作に使用されるデータベース キャッシュのサイズが小さいので (コールド状態)、読み取り操作 (I/O) を減らす能力は非常に低くなります。Exchange 2010 では、従来は Microsoft Exchange Replication サービスが実行していたパッシブ コピーの再生機能が Microsoft Exchange Information Store サービスに移動しています。この結果、フェールオーバーまたは切り替えが発生しても、ウォーム データベース キャッシュが存在しているため、すぐに使用できます。

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

Exchange 2010 SP1 での連続レプリケーションの変更

Exchange 2010 の RTM 版と Exchange Server 2007 のすべてのバージョンでは、アクティブ データベース コピーが生成したログ ファイルのコピーをパッシブ データベース コピーに配布することで、連続レプリケーションが動作します。Exchange 2010 SP1 以降、この連続レプリケーションの形式は連続レプリケーション - ファイル モードとして知られています。SP1 では、連続レプリケーション - ブロック モードという新しい連続レプリケーションの形式も導入されています。ブロック モードでは、各更新プログラムがアクティブ データベース コピーのアクティブ ログ バッファーに書き込まれる際に、各パッシブ メールボックス コピーのログ バッファーにも配布されます。ログ バッファーがいっぱいの場合は、各データベース コピーが、生成シーケンスに次のログファイルを構築、検査、および作成します。アクティブ コピーに影響を与える障害が発生すると、最新の更新プログラムの大部分または全部を使用してパッシブ コピーが更新されます。アクティブ コピーはレプリケーションが完了するまで待機することはありません。これは、レプリケーションの問題がクライアントに影響を与えないようにするためです。

ブロック モードによって、アクティブ コピーが変更されてからこの変更がパッシブ コピーにレプリケートされるまでの待ち時間が、大幅に削減されます。ブロック モードによって、個々のログ ファイルの書き込みのレプリケートのほか、パッシブ コピーのアクティブ化プロセスも変更されています。障害発生時にコピーがブロック モードであれば、アクティブ化プロセスの間に、使用可能なログ内容が部分的に使用されます。この結果、アクティブ コピー上の現在のログ ファイルが単一障害点ではなくなります。

動作の初期モードは、常にファイル モードです。ブロック モードは、ファイル モードで連続レプリケーションが最新の状態である場合にのみアクティブとなります。ブロック モードへの移行、およびブロック モードからの移行は、ログ コピー ツールによって自動的に実行されます。パッシブ コピーが現在のログ ファイルを要求すると、連続レプリケーションを最新の状態 (コピー キューの長さ = 0) にするよう指示が出されるため、ファイル モードからブロック モードへ自動的に切り替える必要があります。

パッシブ データベース コピーがブロック モードであるかどうかは、MSExchange Replication パフォーマンス オブジェクトの下にある Continuous replication – block mode Active パフォーマンス カウンターを監視することで判断できます。各データベース コピーは、このカウンターの独自のインスタンスを持っています。カウンターの値は、パッシブ コピーがブロック モードの場合は 1、ファイル モードの場合は 0 に設定されます。次の例のように、Get-Counter コマンドレットまたは Get-WMIObject コマンドレットを使用して、このカウンターの値を確認することもできます。

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Exchange 2007 からのトランスポート収集の変更

Exchange 2010 ハブ トランスポートサーバーの役割には、Exchange 2007 で最初に導入されたトランスポート収集という機能が含まれます。トランスポート収集は、メールボックスが CCR または LCR で保護されているユーザーに最近送信されたすべての電子メール メッセージのキューを保持して、データ損失を防ぐことを目的として設計されています。いずれかの環境でデータ損失障害が発生しても、障害の結果失われたデータ群が、トランスポート収集によって自動的に回復します。

トランスポート収集は、レプリケートされたメールボックス データベースに対してのみ使用されます。パブリック フォルダーに送信されるメッセージや、レプリケートされていないメールボックス データベース上の受信者宛に送信されるメッセージは保護されません。特定のメールボックス データベース用のトランスポート収集キューは、DAG を含む Active Directory サイト内のすべてのハブ トランスポート サーバーにあります。

Exchange 2007 では、管理者の定義する時間制限またはサイズ制限に達するまでは、メッセージはトランスポート収集内に保持されていました。Exchange 2010 では、トランスポート収集がレプリケーション パイプラインからフィードバックを受信し、配信およびレプリケートされたメッセージを判断するようになりました。メッセージが DAG 内のレプリケートされたメールボックス データベースに到達する途中にハブ トランスポート サーバーを経由する際、コピーがトランスポート キュー (mail.que) 内に保持されます。保持される期間は、メッセージのトランザクション ログがメールボックス データベースのすべてのコピーに問題なくレプリケートされ、検査されたことが通知されるまでです。ログがすべてのデータベース コピーに問題なくレプリケートされ検査が完了すると、そのログ中のメッセージはトランスポート収集から切り捨てられます。こうしてトランザクション ログがレプリケートされていないメッセージのコピーのみを保持することで、トランスポート収集キューのサイズを小さくしておくことができます。

各 DAG のアクティブ マネージャーが、各パッシブ データベース コピーでログが最後に検査された時刻の値を追跡します。ハブ トランスポート サーバーで実行されるアクティブ マネージャー クライアントが、この情報を DAG のスタンバイ アクティブ マネージャー (SAM) から取得し、時間ベースのウォーターマークに変換します。次に、ハブ トランスポート サーバーが、トランスポート収集内のメッセージの配信時刻とウォーターマークを比較します。メッセージの配信時刻がウォーターマークより前である場合は、メッセージがトランスポート収集から切り捨てられます。

またトランスポート収集は、メールボックスサーバーの役割の変更向けに拡張されました。これにより、1 つのメールボックス データべースを Active Directory サイト間で移動できるようになりました。DAG を複数の Active Directory サイトに拡張でき、この結果、1 つの Active Directory サイト内の 1 つのメールボックス データべースを、他の Active Directory サイトにフェールオーバーできます。この場合、トランスポート収集の再配信要求は、Active Directory サイトの元のサイトと新しいサイトの両方に送信されます。

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

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

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

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

ページのトップへ

メールボックス サーバー以外の役割に関する高可用性

ハブ トランスポート、エッジ トランスポート、クライアント アクセス、およびユニファイド メッセージングの各サーバーの役割における高可用性は、サーバー、サービス、およびインフラストラクチャの予防的な管理と、サーバーの冗長性、負荷分散、およびドメイン ネーム システム (DNS) ラウンド ロビンとを組み合わせることで実現されます。通常、クライアント アクセス、ハブ トランスポート、エッジ トランスポート、およびユニファイド メッセージングの各サーバーの役割の高可用性は、以下の戦略やテクノロジを使用することで実現できます。

  • エッジ トランスポート   複数のエッジ トランスポート サーバーを展開して複数の DNS MX リソース レコードを使用することにより、これらのサーバー間で処理の負荷を分散できます。また、ネットワーク負荷分散 (NLB) を使用してエッジ トランスポート サーバーの負荷分散と高可用性を実現することもできます。

  • クライアント アクセス   NLB またはサード パーティのハードウェア ベースのネットワーク負荷分散デバイスを使用することで、クライアント アクセス サーバーの高可用性を実現できます。

  • ハブ トランスポート   複数のハブ トランスポート サーバーを展開することで、内部トランスポートの高可用性を実現できます。ハブ トランスポート サーバーの役割に対する復元性の設計は、次の方法で行われています。

    • ハブ トランスポート サーバーからハブ トランスポート サーバーへ (組織内)   組織内のハブ トランスポート サーバーからハブ トランスポート サーバーへの通信は、ターゲット Active Directory サイト内で使用可能なハブ トランスポート サーバー間で自動的に負荷分散されます。

    • メールボックス サーバーからハブ トランスポート サーバーへ (Active Directory サイト内)   メールボックス サーバーでの Microsoft Exchange メール発信サービスは、同じ Active Directory サイト内で使用可能なすべてのハブ トランスポート サーバー間で自動的に負荷分散されます。

    • ユニファイド メッセージング サーバーからハブ トランスポート サーバーへ   ユニファイド メッセージング サーバーでは、同じ Active Directory サイト内で使用可能なすべてのハブ トランスポート サーバー間の接続が自動的に負荷分散されます。

    • エッジ トランスポート サーバーからハブ トランスポート サーバーへ   エッジ トランスポート サーバーでは、エッジ トランスポート サーバーを購読する Active Directory サイト内のすべてのハブ トランスポート サーバーに対する受信 SMTP トラフィックが自動的に負荷分散されます。

    さらに冗長性を必要とする場合 (SMTP 中継が必要なアプリケーションなど)、DNS レコード (relay.company.com など) の作成、IP アドレスの割り当て、およびハードウェア負荷分散装置の使用などにより、該当 IP アドレスを複数のハブ トランスポート サーバーにリダイレクトします。ハブ トランスポート サーバーのクライアント コネクタに NLB を使用することもできます。ハードウェア負荷分散装置を使用する場合、前述したように組織内トラフィックでは組み込みの負荷分散アルゴリズムが使用されるため、組織内トラフィックがハードウェア負荷分散装置を通らないことを確認する必要があります。

  • ユニファイド メッセージング   ユニファイド メッセージングの展開では、複数のユニファイド メッセージング サーバーを展開し、そのうち 2 つ以上のサーバーを 1 つのダイヤル プラン内に構成することで、復元性を高めることができます。ユニファイド メッセージングでサポートされる VoIP (Voice over IP) ゲートウェイを構成することで、ユニファイド メッセージング サーバーに対する呼び出しをラウンド ロビン方式でルーティングすることができます。さらにこれらのゲートウェイでは、DNS からダイヤル プランのサーバーの一覧を取得できます。いずれの場合も、VoIP ゲートウェイは呼び出しをユニファイド メッセージング サーバーに転送します。呼び出しが受け付けられない場合、その呼び出しが別のサーバーに転送されることで、呼び出し確立時の冗長性が確保されます。

ページのトップへ

サイトの復元

Exchange 2010 には、高可用性とサイトの復元のための統合プラットフォームが含まれます。Exchange 2010 のネイティブ サイト復元サポートと適切な計画を組み合わせることで、障害が発生したデータセンターのクライアントに対応するため第 2 データセンターをすぐにアクティブ化できます。データセンターまたはサイトの障害は、サーバーまたはデータベースのフェールオーバーが行われる障害とは異なる方法で管理されます。高可用性構成では、システムによって自動復旧が開始され、通常は障害が発生してもメッセージング システムは完全に機能した状態にあります。反対に、データセンターの障害は障害復旧イベントであると見なされます。クライアント サービスを復元して停止を終了するには、復旧を手動で実行および完了する必要があります。実行するプロセスは、データセンター切り替えと呼ばれます。多くの障害復旧シナリオの場合と同様、データセンター切り替えに対する事前の計画と準備により、回復プロセスを簡略化し、停止の期間を短くできます。

サイトの復元の計画および展開の詳細については、「高可用性とサイト復元の計画」、「高可用性とサイト復元を展開する」および「データセンターの切り替え」を参照してください。

ページのトップへ

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

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

  • シャドウ冗長

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

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

  • 増分再同期

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

シャドウ冗長

前に説明したトランスポート収集とルーティング動作拡張に加えて、シャドウ冗長という新しいハブ トランスポート サーバー機能が追加されました。シャドウ冗長では、メッセージ送信中の期間全体にわたって、メッセージの冗長性が提供されます。このソリューションでは、トランスポート収集と同様の手法が使用されています。シャドウ冗長では、トランスポート データベースからのメッセージの削除は、そのメッセージの次ホップすべてが配信を完了するまで、遅延されます。ネクスト ホップのいずれかに失敗して、配信が正常に行われたことを示すレポートが届かなかった場合は、そのネクスト ホップに配信されるようにメッセージが再送信されます。シャドウ冗長の詳細については、「シャドウ冗長について」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

増分再同期

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

また Exchange 2007 では増分再シードという概念が導入されました。増分再シードでは、消失ログの復元の遅延再生機能に依存することで、ソースとターゲットのストレート グループ間のトランザクション ログ ストリームでの分岐を修正できました。増分再シードでは、分岐ログの再生後に、データベースのパッシブ コピーの分岐を修正する方法がなく、強制的に完全再シードを行う必要がありました。Exchange 2010 の場合、Exchange 2007 とは異なり、完全な再シードが必要な大量のログ損失がありません。

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

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

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

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

これらの変更の結果、消失ログの復元は、すべての Exchange 2010 メールボックス データベースで、1 つのログ ファイルにハードコードされるようになっています。

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

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

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

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

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

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

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

Exchange 2010 には、組織で組み込みの連続レプリケーション機能の代わりに、サードパーティ同期レプリケーション ソリューションを使用できる、新しいサードパーティ レプリケーション API も備わっています。Microsoft では、この API を使用するサードパーティ ソリューションをサポートします。ただし、API を使用した結果無効となるネイティブの連続レプリケーション機能の代わりとなる必要機能を、そのソリューションがすべて提供することが条件となります。ソリューションがサポート対象となるのは、この API が DAG 内でメールボックス データベース コピーの管理とアクティブ化目的で使用される場合に限定されます。この範囲外で API を使用した場合は、サポート対象外となります。また、ソリューションが Windows ハードウェア サポートの適用可能要件を満たしている必要があります (テスト検証はサポートでは不要です)。

組み込みのサードパーティ製レプリケーション API を使用するソリューションを展開する場合は、主にソリューション ベンダーがソリューションのサポートを担当します。Microsoft は、レプリケートされたソリューションおよびレプリケートされていないソリューションの Exchange データについてサポートします。 データ レプリケーションを使用するソリューションは、データ レプリケーションに関する Microsoft のサポート ポリシーに従う必要があります。このサポート ポリシーについては、マイクロソフト サポート技術情報の記事 895847「Exchange Server での複数サイト データ レプリケーションのサポート」に記載されています。また、Windows フェールオーバー クラスター リソース モデルを利用するソリューションは、マイクロソフト サポート技術情報の記事 943984「Windows Server 2008 フェールオーバー クラスタに関するマイクロソフト サポート ポリシー」に記載されている Windows クラスターのサポート可能要件を満たす必要があります。

サードパーティ製レプリケーション API ベースのソリューションを使用した展開に関する Microsoft のバックアップおよび復元のサポート ポリシーは、ネイティブの連続レプリケーション展開に関するサポート ポリシーと同じです。

サードパーティ API の情報が必要なパートナーの場合、マイクロソフトの営業担当者にお問い合わせください。Exchange 2010 のパートナー製品の詳細については、「Microsoft Exchange パートナー」を参照してください。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.