高可用性展開

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2008-01-17

Microsoft Exchange Server 2007 における高可用性に関する主な開発テーマの 1 つは、Exchange Server の以前のバージョンに存在していた高可用性の手法と構成オプションに取り組むことでした。Exchange 2007 を使用した構造化計画プロセスに従うことにより、展開および運用コストを抑えると同時に、エンド ユーザーに対してより多くのサービスを提供することができます。

Exchange Server 2003 の高可用性ソリューションは Microsoft と多くの顧客により運用環境への展開に成功し、高可用性を備えたメッセージング環境を実現しています。また、多くの顧客はパートナー レプリケーション テクノロジの展開に成功し、障害発生時にデータの 2 番目のコピーに自動的にフェールオーバーするソリューションを作成しています。Exchange 2007 には、Exchange 2003 に存在する高可用性ソリューションに対する機能拡張と、サード パーティのレプリケーション テクノロジが不要になり、ソリューション全体のコストおよび複雑性が軽減する新しい高可用性機能が装備されています。これらの改善点の背後にある主要な理由の一部は、次のような報告があった顧客からのフィードバックの直接的な結果でした。

• ソリューション用の共有記憶域の要件が、ソリューションのコストと複雑性を高めていました。たとえば、ソリューション全体用のハードウェアは、Windows Server Catalog of Tested Products のクラスタ ソリューションのカテゴリから選択する必要がありました。Exchange 2007 では、シングル コピー クラスタ (SCC) ではこの要件を維持する必要がありますが、クラスタ連続レプリケーション (CCR) 環境で構成されているクラスタ化メールボックス サーバーにはこの要件は必要ありません。
• メールボックス データのシングル コピーを使用することは、そのコピーまたはそのストレージの障害は非常に破壊的であり、多くの場合長期間の停止や、場合によってはデータ損失が生じることを意味していました。
• クラスタ サービスと Exchange Server との間でインストールと管理の統合がなかったことにより、Exchange の管理者はクラスタの概念と機能を理解する必要がありました。これは、一部の Exchange 管理者にとって重大な学習曲線となりました。
• 箱から出したばかりの既定の構成設定は、最適な回復動作用にはチューニングされていませんでした。管理者は、ベスト プラクティスの推奨事項を遵守するため、手動で既定のクラスタ リソースとクラスタ設定を再構成する必要がありました。
• すべての Exchange のサービス (クライアント アクセス、トランスポート、およびストレージ) は、異なる高可用性戦略を含め、それらの間にアーキテクチャの面で根本的な違いがある場合であっても、同じ可用性戦略を使用して処理されていました。
• メールボックス データの 2 つのコピーを維持するソリューションを実現するには、一部の顧客ではパートナー テクノロジが必要でした。これらのソリューションでは展開のコストと複雑性が高くなりました。

Exchange 2007 の高可用性ソリューションは、Exchange 2003 の高可用性アプローチの弱点すべてに対処するように設計されています。Exchange 2007 は、アーキテクチャ面での変更、新しい構成のサポート、管理モデルの変更、および高可用性への新しいアプローチの導入により弱点に対処しています。結果として、各組織に、その固有のニーズを満たすソリューションを選択する自由を提供する柔軟性の高いソリューションとなっています。

高可用性展開のオプション

高可用性は常に、個別コンポーネントのレベルと、システム全体またはソリューションのコンテキストの両方で設計される必要があります。通常、Exchange 2007 には、次の 2 種類の高可用性展開のオプションがあります。

• 短時間停止した後障害から自動的に回復できる冗長性を装備した、単一のデータセンター展開。サイトに障害が発生した場合、単一のデータセンター ソリューションは障害回復手順に依存して稼働状態に戻ります。
• 多くの独立した障害から自動的に回復できる冗長性を装備した、複数のデータセンター展開。複数のデータセンター ソリューションでは、組織は障害回復手順に頼ることなく 1 つのデータセンターの障害に耐えることができます。サイト全体の障害などの回復不可能な障害では、回復には手動による操作が必要です。

これらの展開オプションの両方については、後で詳しく説明します。

単一のデータセンター構成

ユニファイド メッセージング、ハブ トランスポート、クライアント アクセス、およびエッジ トランスポート サーバーの役割用の単一のデータセンター構成のすべてには、同様に構成された冗長化されたサーバーが含まれます。メールボックス サーバーでは、単一のデータセンター内でデータとサービスの可用性を提供する高可用性構成として SCC、CCR、およびローカル連続レプリケーション (LCR) の 3 つがあります。次の図に、完全に冗長化された単一のデータセンター構成の一般的な展開を示します。

上の図では、メールボックス サーバーの役割の冗長性構成が抽象化されています。これは、SCC と CCR を使用したさまざまな構成を含め、ある組織には複数のオプションが使用できるためです。

シングル コピー クラスタ

Exchange 2007 の共有記憶域クラスタ構成は、シングル コピー クラスタ (SCC) と呼ばれます。SCC は、クラスタ サービスと共有記憶域を使用してクラスタ化メールボックス サーバーをホストします。クラスタ化メールボックス サーバーは論理コンピュータであり、その存在中は物理ノード間を移動することができます。これは、クラスタ サービスが、浮動ネットワーク ID を作成および管理できる機能により実現されています。浮動ネットワーク ID は、クラスタ化メールボックス サーバーのネットワーク ID として使用されます。Exchange のセットアップでは、管理者が入力するホスト名と IP アドレスを使用して、このネットワーク ID が自動的に作成されます。浮動ネットワーク ID は、ノードの可用性と保守のニーズに基づいて、クラスタ内のノード間を移動します。これらのメカニズムにより、ストレージが使用可能であり、2 つのノードの少なくとも 1 つが稼働している場合、ユーザーはメールボックス データにアクセスできます。障害回復が機能するよう、Exchange とクラスタ サービスが連携して、障害発生後は使用可能なノード上でクラスタ化メールボックス サーバーをオンラインにします。

次に示すのは、Exchange Server の以前のリリースに存在していた共有記憶域クラスタリングに対する Exchange 2007 での主要な改善点です。

• メールボックス サーバーの役割のみがクラスタ対応で、これがフェールオーバー クラスタにインストール可能な唯一の役割です。
• 箱から出したばかりのフェールオーバーの動作は、フェールオーバーが可用性を改善する可能性が高い場合にのみフェールオーバーを行うよう最適化されています。完全なノード障害、またはノードがクライアントと通信できない場合のみがフェールオーバーの原因になります。
• 管理の大部分は、クラスタ アドミニストレータから、Exchange 管理シェルなどの Exchange のツールに移されています。これにより、SCC 管理者の学習曲線が軽減されています。
• クラスタ化メールボックス サーバーのインストールはセットアップに統合され、スタンドアロン インストールと同じようになっています。

次の図に SCC の典型的な構成を示します。1 つの SCC は、少なくとも 1 つのパッシブ ノードを持つノード クラスタを、8 つまでサポートしています。

図 2   シングル コピー クラスタの基本的なアーキテクチャ

上の図では、2 つのノードが 1 つのフェールオーバー クラスタに参加しています。共有ディスクは、ディスク "Quorum" によって表されているクラスタ クォーラム リソースを管理するために、クラスタにより使用されています。現在、アクティブ ノードは、クラスタ化メールボックス サーバーのログとデータベース ファイルを保持するディスク リソースを所有しています。この所有権は、アクティブ ノードからディスクへの青い線によって示されています。この構成では、ディスクはアクティブ ノードによりアクセス可能ですが、パッシブ ノードから同時にアクセスすることはできません。

アクティブ ノードとパッシブ ノードは、少なくとも 2 つのネットワーク (プライベートと混合) によって接続されています。クライアント通信には 2 つのネットワークの 1 つのみが使用されます (混合ネットワーク)。クラスタ サービスは、定期的に両方のネットワークの通信状態をチェックします。

SCC の詳細については、「シングル コピー クラスタ」を参照してください。

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

名前が意味するように、シングル コピー クラスタにはメールボックス データのシングル コピーが含まれています。メールボックス データをホストするストレージに障害が生じても、自動回復は行われません。事実、一般的にそのような障害が生じると、大規模な停止とデータ損失が生じます。以前のクラスタ ソリューションに対する SCC の改善点では、以前の高可用性ソリューションに関して顧客から寄せられたフィードバックの多くに対処しています。ただし、SCC にはまだ、共有記憶域を使用することによる複雑性が存在します。SCC には、未設定の段階で少なくとも 2 つの単一障害点、つまりシングル クォーラム ディスク、および Exchange データのシングル コピーがあります。Exchange 2007 には、Windows Server Catalog of Tested Products のクラスタ ソリューションのカテゴリのハードウェアを必要とすることなく完全な冗長性を実現する、第 2 の種類の高可用性構成があります。このソリューションは、クラスタ連続レプリケーション (CCR) と呼ばれます。

CCR は、組み込みの非同期のログ配布を使用して、フェールオーバー クラスタ内の 2 つのサーバー間でメールボックス データをレプリケートします。レプリケーションとクラスタリングの統合により、単一障害点がなく、サーバー障害からの自動回復を実現するソリューションが実現されました。また、共有記憶域が不要になったため、展開のコストが削減され複雑性が軽減されています。CCR は、2 ノード クラスタと、データの 2 つのコピー (アクティブ コピーとパッシブ コピー) のみをサポートしています。次の図に典型的な CCR 環境を示します。

上の図で示されている 2 つの重要な変更点として、共有クォーラム ディスクが存在しないことと、クラスタ外部の 3 つ目のコンピュータ上にファイル共有が存在することが挙げられます。ファイル共有は、マイクロソフト サポート技術情報の記事 921181「Windows Server 2003 Service Pack 1-based サーバー クラスタにファイル共有監視機能と構成可能なクラスタ ハートビート機能を追加するアップデートが入手できます。」で説明されている更新プログラムで導入された新しいクラスタ クォーラム機能の一部です。この更新プログラムにより、クラスタ サービスは、クラスタの投票者ノードの代わりにファイル共有を使用するクォーラム リソースを使用することができます。この更新プログラムがないと、クォーラムのオプションは、共有ディスクまたは従来のマジョリティ ノード セット構成のいずれかを使用することに限定され、次のようにこの両方には欠点があり、コストが高くなります。

• 共有ディスクを使用することで、ソリューションに共有記憶域の複雑性が復活してしまいます。
• マジョリティ ノード セット クォーラムには 3 つ以上のノードが必要です。この構成では、投票者ノードと呼ばれる余分なノードが、クラスタで投票者ノードとして動作するために必要です。

CCR の詳細については、「クラスタ連続レプリケーション」を参照してください。

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

CCR はデータとサービスの完全な冗長性を実現し、SCC はサービスの冗長性を実現します。サービスの冗長性が存在しないデータの冗長性を必要とする組織向けには、ローカル連続レプリケーション (LCR) があります。LCR はクラスタ化ソリューションではないため、サービス可用性は実現しません。次の図に典型的な LCR 環境を示します。

LCR は、前述の CCR のセクションで説明されている組み込みの連続レプリケーション テクノロジを使用して、ローカル コンピュータ上のストレージ グループの (パッシブ コピーと呼ばれる) 2 つ目のコピーを作成します。コンピュータは、スタンドアロンの (クラスタ化されていない) メールボックス サーバーである必要があります。LCR 環境では、管理者はどのストレージ グループでパッシブ コピーを保持するかを決定し、同じサーバー上でパッシブ コピーの 2 つ目の場所を構成します。

LCR を使用する場合、管理者はどのストレージ グループでパッシブ コピーを保持するかを明示的に決定する必要があります。管理者は、既存のストレージ グループのパッシブ コピーを作成することを決定するか、作成プロセスの間に新しいストレージ グループ用に LCR を有効にすることができます。管理者は、LCR が有効であるストレージ グループ用に、ログおよびデータベース ファイルの 2 つ目の場所を構成する必要があります。

LCR では、2 番目のコピーのアクティブ化は手動で行います。LCR ではフェールオーバーは行われません。フェールオーバーはクラスタ操作であり、LCR はクラスタ化ソリューションではないためです。その代わりに、管理者はアクティブ コピーが無効になる時点を決定し、パッシブ コピーを手動でアクティブ化し、それを新しいアクティブ コピーにする必要があります。パッシブ コピーをアクティブ化するプロセスは、簡単ですばやく行えます。

任意の時点で、管理者は LCR を有効にして既存のデータベースのパッシブ コピーを作成することを決定でき、また管理者はデータベースの新規作成時に直ちに LCR を有効にすることができます。LCR が有効になると、シードと呼ばれるプロセスを使用してベースライン コピーが作成され、レプリケーション (ログ配布) が始まります。ディスク、またはアクティブ コピーから分離されたストレージ エンクロージャ上でパッシブ コピーを特定することをお勧めします。これにより、同時に複数の障害が発生する可能性が最小限になります。LCR には、メールボックス サーバーへのリソースの影響が存在します。メールボックス サーバーは連続レプリケーションに関連するすべての処理を実行しているため、サーバーに関する容量計画ではこの点を考慮する必要があります。アクティブ コピーに対する入出力 (I/O) 負荷は制限されていますが、これはパッシブ コピーに関する I/O 動作がパッシブ コピーのログおよびデータベース ファイルに関連付けられているためです。

LCR は、Exchange 対応のボリューム シャドウ コピー サービス (VSS) を使用したパッシブ コピーのバックアップをサポートしています。アクティブ コピーを含むディスク ボリュームがパッシブ コピーから適切に分離されている場合は、ハードウェア ベースの VSS サポートを使用しない VSS バックアップをお勧めします。パッシブ コピーからのバックアップは、アクティブ コピーのディスク ボリュームからバックアップ I/O をオフロードします。パッシブ コピーはクライアントに対するリアルタイムの応答を必要としないため、ソフトウェア ベースの VSS ライターを使用することに関連するコストを調整できます。また、使用する容量計画に応じて、LCR を使用したサーバー上のバックアップの時間枠を拡大することが実用的な場合があります。重要な要素は、バックアップの時間枠全体でのバックアップ エージェントの CPU 負荷を維持することです。

パッシブ コピーは、破損やデータの障害に対する第一の対応策です。LCR を使用すると、最初の障害からの回復はサービス レベル契約 (SLA) を比較的短くできます。二重障害では、バックアップからの回復が必要です。このモデルでは、二重障害に対する SLA は大幅に長くなる可能性があります。結果的には、毎週の完全バックアップと毎日の増分バックアップの計画が有効で推奨される方式です。またこの方式では、バックアップ メディアに移動される総コンテンツも減少します。

要するに、データの障害または破損を迅速に回復する必要のある組織にとって LCR は優れたオプションですが、スケジュールされた理由およびスケジュールされていない理由からサーバーの機能停止が発生する場合もあります。LCR には、以下のような利点があります。

• アクティブ データベースの破損またはエラーからの迅速な 2 ステップの回復
• 必要性の高いユーザーを保護する管理者の選択性
• 任意のサイズのメールボックス サーバー上およびすべての製品における可用性
• アクティブ データベースおよびログ I/O への影響を最小限にとどめる機能
• アクティブ データベースおよびログ ボリュームからバックアップ I/O をオフロードする機能
• バックアップの時間枠を拡大しながら、バックアップ メディアに移動される総データを削減する機能
• Exchange 管理コンソールまたは Exchange 管理シェルの使用による Exchange レベルでの管理の抽象化

LCR の詳細については、「ローカル連続レプリケーション」を参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。