次の方法で共有


高可用性とサイトの復元

製品: 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 の営業担当者にお問い合わせください。

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

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

トピック 説明
データベース可用性グループ (DAG) DAG、アクティブ マネージャー、データセンターのアクティブ化調整 (DAC) モード、およびメールボックス データベースのコピーについて説明します。
高可用性とサイトの復元計画 全般、ハードウェア、ネットワーク、ソフトウェア、監視サーバーおよびその他の要件および DAG のベスト プラクティスについて説明します。
高可用性とサイト復元の展開 DAG の展開および構成のための展開シナリオの例を検討します。
高可用性とサイト復元の管理 DAG の管理タスク、スイッチ オーバーとフェールオーバー、およびメンテナンス モードについて説明します。
データベース可用性グループの監視 DAG およびデータベース コピーを監視するための、組み込みのコマンドレットとスクリプトについて説明します。
バックアップ、復元、および障害回復 Exchange データベース、回復用データベース、およびサーバー回復のバックアップと復元について説明します。