Exchange Serverでの高可用性とサイトの回復性

高可用性とサイトの回復性を確保するために Exchange サーバーとデータベースを構成することで、Exchange Serverメールボックス データベースとそのデータベースに含まれるデータを保護できます。 Exchange Serverは、高可用性で回復性の高いメッセージング ソリューションを展開するコストと複雑さを最小限に抑えながら、非常に大きなメールボックスに対して高レベルのサービスとデータの可用性とサポートを提供します。

Exchange Serverを使用すると、すべてのサイズのすべてのセグメントのお客様が、Exchange 2010 で導入されたネイティブ レプリケーション機能と高可用性アーキテクチャに基づいて構築することで、メッセージング継続性サービスを経済的に組織内に展開できます。 Exchange 2010 からの変更内容の一覧については、「以前のバージョンと比較した高可用性とサイト復元の変更点」を参照してください。

主要な関連用語

以下の主要な関連用語は、高可用性またはサイト復元を理解するうえで重要です。

アクティブ マネージャー

Exchange の内部コンポーネント。データベース可用性グループ (DAG) 内のフェールオーバーを通した障害の監視と修正措置を行う Microsoft Exchange レプリケーション サービスの内部で実行されます。

AutoDatabaseMountDial

メールボックス サーバーのプロパティの設定。パッシブ データベース コピーが新しいアクティブ コピーとして自動的にマウントするかどうかを、マウントするコピーで不足しているログ ファイルの数に基づいて判断します。

連続レプリケーション - ブロック モード

ブロック モードでは、各更新プログラムがアクティブ データベース コピーのアクティブ ログ バッファーに書き込まれる際に、ブロック モードの各パッシブ メールボックス コピーのログ バッファーにも配布されます。 ログ バッファーがいっぱいになると、各データベース コピーは生成シーケンスにおける次のログ ファイルをビルドし、検査し、作成します。

連続レプリケーション - ファイル モード

ファイル モードでは、閉じられたトランザクション ログ ファイルが、アクティブ データベース コピーから 1 つ以上のパッシブ データベース コピーにプッシュされます。

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

レプリケートされたデータベースのセットをホストする最大 16 台の Exchange サーバーのグループ。

データベース モビリティ

他の Exchange サーバーにレプリケートしてマウントするExchange Serverメールボックス データベースの機能。

Datacenter

通常、Active Directory サイトを示しますが、物理的なサイトを示すこともあります。 このドキュメントでは、データ センターは Active Directory サイトと同じです。

データセンターのアクティブ化調整モード

DAG 設定のプロパティ。有効にすると、Microsoft Exchange レプリケーション サービスが起動時にデータベースをマウントするアクセス許可を取得するよう強制します。

障害回復

障害から回復するための手動による処理です。 この障害には、1 つのアイテムに影響するものと、物理的な場所全体に影響するものとがあります。

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

DAG で、連続レプリケーションの代わりにサード パーティの同期レプリケーションを使用できるようにする Exchange の API です。

高可用性

サービスの可用性、データの可用性、およびサービスまたはデータに影響する障害 (ネットワーク、ストレージ、またはサーバーの障害など) からの自動回復を提供するソリューションです。

増分展開

Exchange Serverのインストール後に高可用性とサイトの回復性を展開する機能。

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

ログ再生ラグ タイムが 0 より大きい、パッシブなメールボックス データベース コピーです。

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

アクティブまたはパッシブのいずれかのメールボックス データベース (.edb ファイルとログ) です。

メールボックスの復元

Exchange Serverでの統合高可用性とサイトの回復性ソリューションの名前。

可用性管理

プローブ、モニター、レスポンダーからなる一連の内部プロセスで、すべてのサーバーの役割とすべてのプロトコルにわたって監視と高可用性を実現します。

*over ("star over" と発音)

切り替えおよびフェールオーバーの短縮名です。 切り替えとは、1 つ以上のデータベース コピーを手動でアクティブ化することです。 フェールオーバーとは、障害発生後に、1 つ以上のデータベース コピーを自動的にアクティブ化することです。

セーフティ ネット

以前はトランスポート ダンプと呼ばれ、これは X 日間のすべてのメッセージのコピーを格納するトランスポート サービスの機能です。 既定の設定は 2 日です。

シャドウ冗長

メッセージ送信中の期間全体にわたって冗長性を提供するトランスポート サーバーの機能です。

サイトの復元

メッセージング インフラストラクチャを複数の Active Directory サイトに拡張する構成です。サイトの 1 つに影響を及ぼす障害の発生時にメッセージング システムに対して運用の持続性を提供します。

データベース可用性グループ (DAG)

DAG は、Exchange Serverに組み込まれている高可用性とサイトの回復性フレームワークの基本コンポーネントです。 DAG は、一連のデータベースをホストし、個々のデータベース、ネットワーク、またはサーバーに影響を与えるエラーからのデータベース レベルの自動復旧を提供する最大 16 台の Exchange サーバーのグループです。 DAG 内のサーバーは、DAG 内の他のサーバーからのメールボックス データベースのコピーをホストできます。 サーバーは DAG に追加されると、DAG 内の他のサーバーと連動して、ディスク障害やサーバー障害などのメールボックス データベースに影響を与える障害からの自動的な回復を提供します。 DAG の詳細については、「データベース可用性グループ (DAG)」を参照してください。

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

Exchange 2010 で最初に導入された高可用性とサイトの回復性機能は、Exchange Serverでデータベース コピーを作成および管理するために使用されます。 Exchange Serverでは、Exchange で管理されるデータベース レベルのフェールオーバーであるデータベース モビリティの概念も活用されています。

データベース モビリティは、データベースをサーバーから切り離し、1 つのデータベースで最大 16 個のコピーのサポートを追加します。 データベースのコピーを作成できるネイティブな環境も提供します。

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

たとえば、基になるストレージ障害が原因で DAG 内のアクティブ データベースが失敗した場合、Active Manager は DAG 内の別のサーバー上のデータベース コピーにフェールオーバーすることで自動的に復旧します。 Exchange Serverでは、マネージド可用性は、アプリケーション ワーカー プールのリサイクル、サービスとサーバーの再起動、データベース フェールオーバーの開始など、データベースへのプロトコル アクセスの損失から復旧するための動作を提供します。

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

アクティブ マネージャー

Exchange Serverでは、Active Manager を利用して、データベースとデータベースのコピーの正常性、状態、継続的レプリケーション、およびその他の高可用性の側面を管理します。 Active Manager の詳細については、「 アクティブ マネージャー」を参照してください。

サイトの復元

Exchange 2010 では、2 つのデータセンターにまたがって DAG を展開して、3 番目のデータセンターでホストを監視することで、いずれかのデータセンターのメールボックス役割のフェールオーバーを有効にできました。 ただし、ソリューション自体のフェールオーバーは行われませんでした。これは、メールボックス サーバー以外の役割に対して名前空間を手動で変更する必要があるためです。

Exchange 2016 と Exchange 2019 では、名前空間を DAG で移動する必要はありません。 Exchange はフォールト トレランスを利用して、複数の IP アドレス、負荷分散 (および必要に応じて、サーバーをサービスに組み込んだり外したりする機能) を通して名前空間に組み込んでいます。 最新の HTTP クライアントはこの冗長性で自動的に動作します。 HTTP スタックは完全修飾ドメイン名 (FQDN) に対する複数の IP アドレスを受け付けることができ、最初の IP アドレスの失敗が重大な場合 (接続できないなど)、一覧の次の IP アドレスを試行します。 軽微な失敗 (デバイスがパケットを取りこぼしたためサービスを中断する必要があるなどの、サービスの断続的な障害が原因により、セッションの確立後に接続が失われた) では、ユーザーはブラウザーを更新する必要があるかもしれません。

つまり、名前空間は Exchange 2010 の場合と同様に単一障害点ではなくなりました。 Exchange 2010 では、おそらくメッセージング システムの最大の単一障害点は、ユーザーに移動する場所を伝えるため、ユーザーに付与する FQDN です。 Exchange 2010 パラダイムでは、DNS を変更し、世界の一部の部分で困難な DNS 待機時間を処理する必要があるため、その FQDN の行く場所の変更は簡単ではありません。 また、通常は約 30 分以上の名前キャッシュがブラウザーに存在し、これも処理する必要があります。

Exchange Serverでは、クライアントには複数の場所があります。 Exchange Server内のほぼすべてのクライアント アクセス プロトコルは HTTP ベースです。 Outlook、EAS、EWS、Outlook on the web、EAC など)。 サポートされているすべての HTTP クライアントで複数の IP アドレスを使用できるため、クライアント側でフェールオーバーが提供されます。 名前解決中にクライアントに複数の IP アドレスを渡すように DNS を構成できます。 クライアントが mail.contoso.com について問い合わせると、たとえば 2 つの IP アドレスまたは 4 つの IP アドレスが返ってきます。 しかし、クライアントが受け取る多くの IP アドレスは信頼できるものとしてクライアントから使用されます。 これにより、いずれかの IP アドレスに障害が発生した場合、クライアントには 1 つ以上の代替 IP アドレスが接続を試みるため、クライアントの方が大幅に優れています。 クライアントが 1 つの IP アドレスに接続しようとして失敗すると、約 20 秒間待機してから一覧の次の IP アドレスに対して試行します。 したがって、クライアント アクセス サービスアレイの VIP が失われると、クライアントの復旧が自動的に行われ、約 21 秒で復旧されます。

これによって次のような利点が得られます。

• Exchange Serverでは、プライマリ サイトでロード バランサーを紛失した場合は、単にオフにして (または VIP をオフにする)、修復または交換するだけです。 セカンダリ データセンターでまだ VIP を使用していないクライアントは、名前空間や DNS の変更なしにセカンダリの VIP に自動的にフェールオーバーします。 つまり、切り替えを実行する必要がないというだけでなく、通常データセンターの切り替えの回復に関連する時間がすべて不要になるということです。 Exchange 2010 では、DNS 遅延を処理する必要がありました (そのため、TTL (Time to Live) を 5 分に設定し、フェールバック URL の導入が推奨されていました)。 Exchange 2016 と Exchange 2019 では、VIP (データセンター) 間の名前空間の高速フェールオーバー (20 秒) を取得するため、これを行う必要はありません。

• データセンター間で名前空間をフェールオーバーできるので、データセンターのフェールオーバーを実現するために必要なのは、複数のデータセンター間でメールボックス役割をフェールオーバーするメカニズムだけです。 DAG のフェールオーバーが自動的に行われるようにするには、単に 2 つのデータセンター間で DAG が均等に分割されたソリューションを設計し、第 3 の場所に監視サーバーを配置して、DAG メンバーが含まれるデータセンター間のネットワークの状態に関係なく、いずれかのデータセンターの DAG メンバーによって調停できるようにすることです。 2 つのデータセンターのみがあり、3 番目の物理的な場所が使用できない場合、Microsoft Azure 仮想マシンにミラーリング監視サーバーを配置することができます。 詳細は「DAG ミラーリング監視サーバーとしての Microsoft Azure VM の使用」を参照してください。

• このシナリオでは、管理者は問題の解決に集中することができ、サービスの回復には時間を費やしません。 単に障害を修復するだけで、サービス全体は継続して実行中でデータの整合性も維持されています。 破損したデバイスを修理するときに感じる切迫感とストレスは、サービスの復元作業で感じる切迫感とストレスとはまるで違います。 エンド ユーザーにとっても良いことですし、管理者のストレスも低減されます。

スイッチバック (フェールバックと間違えられることがあります) を実行することなしに、フェールオーバーを発生させることができます。 プライマリのデータセンターでサーバーを喪失し、結果としてクライアントに対してサービスが 20 秒中断しても、フェールバックに気が付かないかもしれません。 この時点で、一番の関心は問題の根本を解決することです (たとえば、故障した負荷分散装置の交換)。 修理したデバイスがオンラインになって機能が回復すると、一部のクライアントは使用を開始し、残りのクライアントは第 2 のデータセンターを通して作業を続けます。

Exchange Serverには、管理者が断続的なエラーに対処できる機能も用意されています。 断続的なエラーは、たとえば、最初の TCP 接続を行うことができますが、その後は何も起こりません。 断続的な障害では、交換デバイスがサービスに投入された結果である可能性があるため、何らかの追加の管理アクションを実行する必要があります。 この修復プロセスが発生している間、デバイスの電源がオンになり、一部の要求が受け入れられる可能性がありますが、必要な構成手順が実行されるまでクライアントにサービスを提供する準備ができていない可能性があります。 このシナリオでは、管理者は、DNS から置き換えられるデバイスの VIP を削除するだけで、名前空間の切り替えを実行できます。 その後、そのサービス期間中、クライアントは接続を試行しません。 交換プロセスが完了すると、管理者は VIP を DNS に追加し直すことができます。クライアントは最終的に使用を開始します。

サイトの回復性の計画と展開の詳細については、「 高可用性とサイトの回復性を計画 する」および「 高可用性とサイトの回復性の展開」を参照してください。

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

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

組み込みのサード パーティのレプリケーション API を使用するソリューションをデプロイする場合は、ソリューション ベンダーがソリューションのプライマリ サポートを担当することに注意してください。 Microsoft では、レプリケートされたソリューションとレプリケートされていないソリューションの両方の Exchange データをサポートしています。 データ レプリケーションを使用するソリューションは、データ レプリケーションの Microsoft サポート ポリシーに準拠している必要があります。 さらに、Windows フェールオーバー クラスター リソース モデルを利用するソリューションは、Microsoft サポート技術情報の記事 943984、Windows Server 2008 または Windows Server 2008 R2 フェールオーバー クラスターのMicrosoft サポート ポリシー、または Windows Server 2008 フェールオーバー クラスターのMicrosoft サポート ポリシーに関する記事で説明されているように、Windows クラスターのサポート要件を満たす必要があります。フェールオーバー クラスターをWindows Server 2012します。

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

サードパーティ API の情報が必要なパートナーの場合、Microsoft の営業担当者にお問い合わせください。

高可用性とサイトの復元のドキュメント

次の表は、DAG、メールボックス データベースのコピー、Exchange Serverのバックアップと復元について学習および管理するのに役立つトピックへのリンクを示しています。