高可用性とサイトの復元に関する Exchange 2010 SP1 の新しい機能

 

適用先: Exchange Server 2010 SP1

トピックの最終更新日: 2015-03-09

Microsoft Exchange Server 2010 Service Pack 1 (SP1) には、新機能と、RTM (Release To Manufacturing) 版の Exchange 2010 で導入された機能の強化が含まれています。 新機能および強化された機能は、Exchange 2010 環境に対してデータおよびサービスの可用性を実現できるシナリオを拡張します。

Exchange 2010 SP1 では、次の高可用性の新機能および既存の高可用性機能の強化が利用できます。

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

  • アクティブなメールボックス データベースの再配布

  • データセンター アクティブ化調整モードのサポートの強化

  • 管理および監視スクリプトの追加および拡張

  • Exchange 管理コンソールのユーザー インターフェイスの拡張

  • フェールオーバーのパフォーマンスの向上

  • I/O ハング時の Extensible Storage Engine の回復

これらの機能について、以下で詳細を説明します。

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

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

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

アクティブなメールボックス データベースの再配布

Exchange 2010 SP1 には、RedistributeActiveDatabases.ps1 というスクリプトが含まれています。このスクリプトは、管理者が構成するアクティブ化優先順位に基づいて、データベース可用性グループ (DAG) 全体でアクティブ データベースのコピーの配布のバランスを取るために、管理者が定期的に実行できるものです。 さらに、コピー配布認識機能がアクティブ マネージャーの最適なコピー選択プロセスに追加されています。 具体的には、ロスレス切り替えにおける最適なコピー選択の最初のパスで、最小ロスの代わりに優先順位によって可能性のあるターゲットが並べ替えられるようになっています。

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

Exchange 2010 RTM には、データセンター アクティブ化調整 (DAC) モードという、DAG サイトの復元性サポートのための構成モードが含まれています。 DAC モードでは、Exchange のコマンドレットを使用して、データ センターの切り替えを実行できます。 RTM 版では、DAC モードの使用は、プライマリ データ センターに 2 メンバー以上が存在する、少なくとも 3 メンバーの DAG に制限されます。

Exchange 2010 SP1 では、DAC モードは別々のデータセンターに各メンバーが存在する 2 メンバーの DAG をサポートするように拡張されました。 2 メンバー DAG の DAC モード サポートでは、ミラーリング監視サーバーを使用して追加の調停を実施します。 さらに、DAC モードは、すべてのメンバーが単一の Active Directory サイトに展開される DAG をサポートするように拡張されました。これには、複数の場所に拡張された単一の Active Directory サイトが含まれます。

管理および監視スクリプトの追加および拡張

Exchange 2010 SP1 には、管理および監視の操作性を大幅に向上させる、いくつかの新しいスクリプトと拡張スクリプトが含まれています。

  • CheckDatabaseRedundancy.ps1 (新規)   このスクリプトを使用して、レプリケートされたデータベースの冗長性を検査できます。データベースの復元が危険な状態 (たとえば、レプリケートされたデータベースの正常なコピーが 1 つしかない場合) であると判断される場合は、イベントが生成されます。 このスクリプトには、冗長性のないデータベースの監視に使用できる Microsoft System Center Operations Manager 2007 管理パックの変更が含まれています。これは特に、非 RAID 環境で役に立ちます。

  • StartDagServerMaintenance.ps1 および StopDagServerMaintenance.ps1 (新規)   StartDagServerMaintenance.ps1 を使用して、保守のために DAG メンバーのサービスを停止できます。 このスクリプトは、アクティブ データベースをサーバーの外部に移動し、さらに、そのサーバーへのデータベースの移動を防ぎます。 また、そのサーバーに存在する可能性のある、プライマリ アクティブ マネージャー (PAM) の役割などの重要なすべての DAG サポート機能も他のサーバーに移動し、さらに元のサーバーへの再移動を防ぎます。 もう一方の StopDagServerMaintenance.ps1 スクリプトは、この運用を完了し、ブロックを解除するために使用します。

  • CollectOverMetrics.ps1 (拡張)   このスクリプトを使用して、切り替えとフェールオーバーに関するデータを収集できます。 このスクリプトは、連続レプリケーション - ブロック モードの測定値と、レプリケーションおよび再生のパイプラインの詳細情報を含めるように、Exchange 2010 SP1 で拡張されました。 さらに、レポート機能が拡張されています。

  • CollectReplicationMetrics.ps1 (拡張)   このスクリプトは、スクリプトの実行中に連続レプリケーション関連の測定値をリアルタイムで収集するので、アクティブな監視を実現します。 スクリプトの動作と出力をカスタマイズできるパラメーターがサポートされています。

Exchange 管理コンソール ユーザー インターフェイスの拡張

Exchange 2010 SP1 では、DAG 管理のために Exchange 管理コンソール (EMC) が強化されています。 たとえば、EMC には IP アドレスおよび DAG 用の代替監視サーバー設定を管理するためのサポートが含まれています。 Exchange 管理シェルを使用してこれらの設定を構成する必要はもうありません。

フェールオーバーのパフォーマンスの向上

Exchange 2010 SP1 には、フェールオーバーおよび切り替えのパフォーマンスと動作を向上させるための変更が含まれています。 RTM 版の Exchange 2010 では、フェールオーバーと切り替えのいずれかが発生すると、アクティブ化対象のパッシブ コピーが、パッシブ コピーにコピーされたログ ファイルの再生を直ちに停止します。 この後、(まだ実行されていない場合に) アクティブ コピーのマウントが解除され、残るログ ファイルはすべてアクティブ化対象のパッシブ コピーにコピーされます。 消失したデータがすべて自動データベース マウント ダイヤル設定内にあると想定し、パッシブ コピーが新しいアクティブ コピーとなり、データベースがダーティ シャットダウンの状態でマウントされます。 この時点で、これまでのパッシブ コピー (かつ現在のアクティブ コピー) にコピーされたすべてのログ ファイルが再生され、データベースの整合性を確保します。

Exchange 2010 SP1 では、フェールオーバーと切り替えのいずれかが発生すると、アクティブ化対象のパッシブ コピー上の Microsoft Exchange レプリケーション サービスが、アクティブ コピーが生成した最新のログ ファイルがコピーされるまで、パッシブ コピーにこれまでコピーされたログ ファイルの再生を継続します。 これによって、整合性の取れた状態に近いデータベースに対するマウント操作が可能になります。

その他のパフォーマンス向上に関する変更には、フェールオーバーのパフォーマンスやフェールオーバー後の I/O パフォーマンスを向上させるためのタイムアウトなどのアルゴリズム詳細が含まれます。

I/O ハング時の Extensible Storage Engine の回復

Exchange 2010 SP1 には、特定の状態になったときにビルトイン Windows バグチェック動作を活用する新しい回復ロジックが組み込まれています。 具体的には、I/O のハングを検出し、サーバーを自動的に回復させる修正操作を実行するように、Extensible Storage Engine (ESE) が更新されています。 ESE は、I/O が一定の期間未解決になっていることを検出する I/O 監視スレッドを保持します。 既定では、データベースの I/O が 1 分より長く未解決になっていると、ESE によってイベントが記録されます。 データベースに 4 分を超えて未解決の I/O がある場合は、可能であれば ESE により、特定の障害イベントが記録されます。 ESE イベント 507、508、509、または 510 は、ハング I/O の性質に応じて、記録されることも記録されないこともあります。オペレーティング システム ボリュームが影響を受けていたり、イベント ログに書き込む機能が影響を受けていたりするなどの問題の場合、イベントは記録されません。 イベントが記録されると、Microsoft Exchange Replication サービス (MSExchangeRepl.exe) が wininit.exe プロセスを意図的に終了することにより、Windows のバグチェックが起動されます。

場合によっては、ストレージ スタック全体がハングの影響を受け、クリムゾン チャネルまたは Windows イベント ログのその他の領域に障害イベントを書き込むのが不可能になることもあります。 ESE は、イベント ログに書き込み可能かどうかを検証することによって、クリムゾン チャネルを監視します。 長期間にわたってイベント ログへの書き込みに失敗すると、MSExchangeRepl は、wininit.exe を終了することによって Windows のバグチェックを意図的に実行します。オペレーティング システム I/O がハングすると、システムは当然、どのような ESE イベントでもイベント ログに書き込むことができなくなります。

注意

アプリケーションとサービス ログは、Windows Server 2008 のイベント ログの新しいカテゴリです。 これらのログには、システム全体に影響を及ぼす可能性のあるイベントよりも、1 つのアプリケーションやコンポーネントからのイベントが保存されます。 イベント ログのこの新しいカテゴリは、アプリケーションのクリムゾン チャネルといいます。 詳細については、「高可用性とサイト復元の監視」を参照してください。

Exchange 2010 SP1 でのこの新しいバグチェックベースの回復機能は、再試行したり、記憶域スタックでフェールオーバーの原因となったエラーが報告されるまで待機したりするのではなく、ハングした I/O またはコントローラーから迅速に回復できるように設計されています。 バグチェックが発生した場合のエラー コードは次のとおりです。

CRITICAL_OBJECT_TERMINATION (f4)

システム操作に不可欠なプロセスまたはスレッドが、予期せず終了したか強制終了しました。

警告

このバグチェック エラー コードが表示されるとしても、エラーの原因が Exchange にあったとは限りません。 タスク マネージャーや他のタスク管理ツールを使用して管理者が実行した場合を含め、wininit.exe を終了すると、同じバグチェック エラー コードが生成されます。

 © 2010 Microsoft Corporation.All rights reserved.