高可用性とサイトの復元

[アーティクル]
04/04/2023

製品: Exchange Server 2013

高可用性およびサイトの復元に対応するようにメールボックスサーバーとデータベースを構成することで、Exchange Server 2013 メールボックスデータベースおよびそれに含まれるデータを保護できます。 Exchange 2013 は、より高レベルのサービスおよびデータの可用性を実現し、大容量のメールボックスをサポートすると同時に、可用性の高い復元メッセージングソリューションの展開におけるコストと複雑さを軽減しています。

Exchange 2013 は、Exchange 2010 で導入されたネイティブレプリケーション機能および高可用性アーキテクチャに基づき、あらゆる規模のお客様が、その所属部門を問わずに組織内のメッセージング継続性サービスを低コストで展開することを可能にします。 Exchange 2010 および Exchange 2007 からの変更内容の一覧については、以前のバージョンと比較した高可用性とサイト復元の変更点を参照してください。

主要な関連用語

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

Active Manager: Microsoft Exchange レプリケーションサービス内で実行される内部 Exchange コンポーネント。データベース可用性グループ (DAG) 内でのフェールオーバーによる障害監視と是正措置を担当します。
AutoDatabaseMountDial: マウントされるコピーで見つからないログファイルの数に基づいて、パッシブデータベースコピーが新しいアクティブコピーとして自動的にマウントされるかどうかを決定するメールボックスサーバーのプロパティ設定。
連続レプリケーション - ブロックモード: ブロックモードでは、各更新プログラムがアクティブなデータベースコピーのアクティブなログバッファーに書き込まれると、ブロックモードのパッシブメールボックスコピーごとにログバッファーにも送信されます。ログバッファーがいっぱいになると、各データベースコピーは生成シーケンスにおける次のログファイルをビルドし、検査し、作成します。
継続的レプリケーション - ファイルモード: ファイルモードでは、閉じられたトランザクションログファイルがアクティブなデータベースコピーから 1 つ以上のパッシブデータベースコピーにプッシュされます。
データベース可用性グループ: レプリケートされたデータベースのセットをホストする最大 16 台の Exchange 2013 メールボックスサーバーのグループ。
データベースモビリティ: Exchange 2013 メールボックスデータベースを他の Exchange 2013 メールボックスサーバーにレプリケートしてマウントする機能。
データセンター: 通常、これは Active Directory サイトを指します。ただし、物理サイトを参照することもできます。このドキュメントでは、データセンターは Active Directory サイトと同じです。
データセンターのアクティブ化調整モード: DAG 設定のプロパティ。有効にすると、起動時にデータベースをマウントするためのアクセス許可を Microsoft Exchange レプリケーションサービスが強制的に取得します。
ディザスターリカバリー: 障害から手動で復旧するために使用されるプロセス。この障害には、1 つのアイテムに影響するものと、物理的な場所全体に影響するものとがあります。
Exchange サードパーティレプリケーション API: 継続的レプリケーションの代わりに DAG にサードパーティの同期レプリケーションを使用できるようにする Exchange 提供の API。
高可用性: サービスまたはデータ (ネットワーク、ストレージ、サーバーの障害など) に影響を与える障害からのサービスの可用性、データの可用性、自動復旧を提供するソリューション。
増分展開: Exchange 2013 のインストール後に高可用性とサイトの回復性を展開する機能。
ラグドメールボックスデータベースコピー: ログ再生ラグタイムが 0 より大きいパッシブメールボックスデータベースコピー。
メールボックスデータベースのコピー: アクティブまたはパッシブのいずれかのメールボックスデータベース (.edb ファイルとログ)。
メールボックスの回復性: Exchange 2013 の統合された高可用性とサイトの回復性ソリューションの名前。
マネージド可用性: すべてのサーバーロールとすべてのプロトコルにわたって監視と高可用性を組み込んだプローブ、モニター、レスポンダーで構成される一連の内部プロセス。
*over ("star over" と発音): 切り替え と フェールオーバーの短い。切り替えとは、1 つ以上のデータベースコピーを手動でアクティブ化することです。フェールオーバーとは、障害発生後に、1 つ以上のデータベースコピーを自動的にアクティブ化することです。
Safety Net: 以前はトランスポートダンプと呼ばれ、これは X 日間のすべてのメッセージのコピーを格納するトランスポートサービスの機能です。既定の設定は 2 日です。
シャドウ冗長性: 転送中のメッセージの冗長性を提供するトランスポートサーバー機能。
サイトの回復性: メッセージングインフラストラクチャを複数の Active Directory サイトに拡張して、いずれかのサイトに影響を与える障害が発生した場合にメッセージングシステムの運用継続性を提供する構成。

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

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

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

Exchange 2010 で初めて導入された高可用性とサイトの復元は、Exchange 2013 ではデータベースコピーの作成と維持に使用されています。 Exchange 2013 では、Exchange によって管理されるデータベースレベルのフェールオーバーであるデータベースモビリティの概念も利用しています。

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

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

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

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

アクティブマネージャー

Exchange 2013 では、Exchange 2010 に導入されているアクティブマネージャーのコンポーネントを利用して、データベースとデータベースコピーの正常性、状態、連続レプリケーション、およびメールボックスサーバーの高可用性のその他の面を管理します。アクティブマネージャーの詳細については、「アクティブマネージャー」を参照してください。

サイトの復元

Exchange 2013 はメールボックスサーバー役割の高可用性およびサイト復元のために、引き続き DAG および Windows フェールオーバークラスタリングを使用しますが、Exchange 2013 ではサイト復元は同じではありません。サイト復元は、Exchange 2013 では簡略化されて大幅に改良されています。 Exchange 2013 で行われた基礎的なアーキテクチャ変更は、サイト復元構成の回復の点で大きな影響があります。

Exchange 2010 では、メールボックス (DAG) とクライアントアクセス (クライアントアクセスサーバー配列) の回復は合わせて行われていました。クライアントアクセスサーバーのすべて、配列の VIP、または DAG の重要な部分を失った場合、データセンターの切り替えを行う必要がありました。これは文書化されていて一般的によく理解されている処理ですが、実行するには時間がかかり、処理を開始するために人間の手による介入を必要とします。

Exchange 2013 では、何らかの理由でクライアントアクセスサーバーアレイを失った場合 (ロードバランサーが失敗するなど)、データセンターの切り替えを実行する必要はありません。適切な構成では、クライアントレベルでフェールオーバーが行われ、クライアントはクライアントアクセスサーバーを運用している 2 つ目のデータセンターに自動的にリダイレクトされます。また、クライアントアクセスサーバーを運用しているクライアントアクセスサーバーは、(切り替えを行わないため) 停止の影響を受けず、ユーザーのメールボックスサーバーに通信をプロキシバックします。サービスの復旧に取り組む代わりに、サービスはそれ自体を復旧し、コアの問題の修正 (失敗したロードバランサーの置き換えなど) に集中できます。

さらに、名前空間の単純化、サーバー役割の統合、Active Directory サイトサーバー役割要件の分離、クライアントアクセスサーバー配列と DAG 回復の分離、および負荷分散の変更によって、Exchange 2013 では、クライアントアクセスサーバーと DAG 両方の回復を分離してサイト全体で自動化できるようになりました。その結果、場所が 3 つある場合のデータセンターのフェールオーバーのシナリオに対応できるようになりました。

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

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

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

Exchange 2013 における変更の 1 つは、クライアントが複数の場所にアクセスできるようにすることです。クライアントが複数の場所を使用できると仮定して (Exchange 2013 のほとんどすべてのクライアントアクセスプロトコルは HTTP ベース (Outlook、Outlook Anywhere、EAS、EWS、OWA、EAC など) で、サポートされているすべての HTTP クライアントが複数の IP アドレスに複数の IP アドレスを設定できます)、クライアント側でフェールオーバーを提供します。名前解決中にクライアントに複数の IP アドレスを渡すように DNS を構成できます。クライアントが mail.contoso.com について問い合わせると、たとえば 2 つの IP アドレスまたは 4 つの IP アドレスが返ってきます。ただし、クライアントが数多く受け取る IP アドレスは確実にクライアントによって使用されます。これにより、IP アドレスの 1 つに障害が発生しても、他に 1 つ以上の IP アドレスへの接続を試すことができるためクライアントが改善されます。クライアントが 1 つの IP アドレスに接続しようとして失敗すると、約 20 秒間待機してから一覧の次の IP アドレスに対して試行します。したがって、クライアントアクセスサーバー配列用の VIP が失われると約 21 秒でクライアントの回復が自動的に発生します。

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

Exchange 2010 では、プライマリのデータセンターで負荷分散装置が失われて、そのサイトに別の負荷分散装置がない場合、データセンターの切り替えを行う必要がありました。 Exchange 2013 では、プライマリサイトで負荷分散装置を失った場合、単に負荷分散装置をオフにし (または VIP をオフにし)、修理または交換します。セカンダリデータセンターでまだ VIP を使用していないクライアントは、名前空間や DNS の変更なしにセカンダリの VIP に自動的にフェールオーバーします。つまり、切り替えを実行する必要がないというだけでなく、通常データセンターの切り替えの回復に関連する時間がすべて不要になるということです。 Exchange 2010 では、DNS 遅延を処理する必要がありました (そのため、TTL (Time to Live) を 5 分に設定し、フェールバック URL の導入が推奨されていました)。 Exchange 2013 では、VIP (データセンター) 間で名前空間のフェールオーバーが高速で行われる (20 秒) ためにその必要がありません。
データセンター間で名前空間をフェールオーバーできるので、データセンターのフェールオーバーを実現するために必要なのは、複数のデータセンター間でメールボックス役割をフェールオーバーするメカニズムだけです。 DAG のフェールオーバーが自動的に行われるようにするには、単に 2 つのデータセンター間で DAG が均等に分割されたソリューションを設計し、第 3 の場所に監視サーバーを配置して、DAG メンバーが含まれるデータセンター間のネットワークの状態に関係なく、いずれかのデータセンターの DAG メンバーによって調停できるようにすることです。 2 つのデータセンターのみがあり、3 番目の物理的な場所が使用できない場合、Microsoft Azure 仮想マシンにミラーリング監視サーバーを配置することができます。詳細は「DAG ミラーリング監視サーバーとしての Microsoft Azure VM の使用」を参照してください。
このシナリオでは、管理者は問題の解決に集中することができ、サービスの回復には時間を費やしません。単に障害を修復するだけで、サービス全体は継続して実行中でデータの整合性も維持されています。破損したデバイスを修理するときに感じる切迫感とストレスは、サービスの復元作業で感じる切迫感とストレスとはまるで違います。エンドユーザーにとっても良いことですし、管理者のストレスも低減されます。

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

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

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

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

Exchange 2013 には、サードパーティレプリケーション 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 の営業担当者にお問い合わせください。