適用対象: 
2016 2019 サブスクリプション エディション
Exchange Server では、Exchange 管理コンソール (EAC) または Exchange 管理シェルを使用して、データベース可用性グループ (DAG) を作成、構成、およびメールボックス サーバー メンバーで設定した後で、メールボックス データベースのコピーを追加できます。
データベース コピーの管理
データベースの複数のコピーが作成された後、EAC または Exchange 管理シェルを使用して、次のタスクを実行できます。
- 各コピーの正常性と状態を監視します。
- データベース コピーに関連するその他の管理タスクを実行します。 例:
- データベース コピーを一時停止または再開します。
- データベース コピーをシードします。
- データベース コピーを監視します。
- データベース コピー設定の構成
- データベース コピーを削除します。
データベース コピーの中断と再開
計画的保守の実行など、さまざまな理由で、データベース コピーの継続的レプリケーション アクティビティの一時停止と再開が必要になる場合があります。 さらに、シード処理などのいくつかの管理タスクでは、先にデータベース コピーを中断する必要があります。 データベースのパス、またはデータベースのログ ファイルを変更する場合には、すべてのレプリケーション活動を中断することをお勧めします。 EAC を使用するか、Exchange 管理シェルで Suspend-MailboxDatabaseCopy コマンドレットおよび Resume-MailboxDatabaseCopy コマンドレットを実行すると、データベース コピー活動を中断して再開できます。 データベース コピーの連続レプリケーション活動の中断または再開に関する詳しい手順については、「 メールボックス データベース コピーを中断または再開する」を参照してください。
データベース コピーのシード
シード処理 ( 更新とも呼ばれる) は、空のデータベースまたは運用データベースのコピーが、アクティブなデータベースと同じ DAG 内の別のメールボックス サーバー上のターゲット コピーの場所に追加されるときです。 このデータベースは、そのサーバーによって管理されるコピーのベースライン データベースになります。
状況に応じて、自動プロセスを使用するか、または管理者が開始する手動プロセスを使用して、データベースをシード処理することができます。 データベース コピーが追加されると、ターゲット サーバーとそのストレージが適切に構成されていれば、コピーが自動的にシードされます。 データベース コピーを手動でシードし、コピーの作成時に自動シード処理が行われないようにするには、Add-MailboxDatabaseCopy コマンドレットの SeedingPostponed パラメーターを使用できます。
最初のシード処理の後に、データベース コピーを再シードする必要はほとんどありません。 ただし、再シードが必要な場合、またはシステムでコピーを自動的にシードする代わりに手動でデータベース コピーをシードする場合は、次の 2 つのオプションがあります。
- EAC でメールボックス データベース コピーの更新ウィザードを使用します。
- Exchange 管理シェルで Update-MailboxDatabaseCopy コマンドレットを使用します。
データベース コピーをシード処理する前に、先にメールボックス データベース コピーを中断する必要があります。 データベース コピーをシード処理する方法の詳しい手順については、「 メールボックス データベース コピーの更新」を参照してください。
手動シード操作が完了すると、シードされたメールボックス データベース コピーのレプリケーションは自動的に再開されます。 レプリケーションを自動的に再開したくない場合は、Update-MailboxDatabaseCopy コマンドレットの ManualResume パラメータを使用できます。
シード対象の選択
シード操作を実行するときには、次のことを選択できます。
- メールボックス データベース コピーをシードします。
- メールボックス データベース コピーのコンテンツ インデックス カタログをシードします。
- データベース コピーとコンテンツ インデックス カタログ コピーの両方をシードします。
メールボックス データベース コピーの更新ウィザードと Update-MailboxDatabaseCopy コマンドレットの既定の動作では、メールボックス データベース コピーとコンテンツ インデックス カタログ コピーの両方をシード処理します。
コンテンツ インデックス カタログをシードせず、メールボックス データベース コピーのみをシードするには、Update-MailboxDatabaseCopy コマンドレットの DatabaseOnly パラメーターを使用します。
コンテンツ インデックス カタログ コピーのみをシードするには、Update-MailboxDatabaseCopy コマンドレットの CatalogOnly パラメーターを使用します。
シード元の選択
正常なデータベース コピーを、そのデータベースの別のコピーのシード ソースとして使用できます。 このオプションは、DAG が複数の物理的な場所に拡張されている場合に特に便利です。
たとえば、次の 4 つのメンバーによる DAG 展開について考えてみましょう。
- MBX1 と MBX2 は、オレゴン州ポートランドにあります。
- MBX3 および MBX4 は、ニューヨーク州ニューヨークにあります。
- DB1 という名前のメールボックス データベースが MBX1 でアクティブになっています。
- MBX2 および MBX3 上には DB1 のパッシブ コピーがあります。
DB1 のコピーを MBX4 に追加する場合、MBX3 上のコピーをシードのソースとして使用できます。 このオプションは、ポートランドとニューヨークの間のワイド エリア ネットワーク (WAN) リンク経由でのシード処理を回避します。
新しいデータベース コピーを追加するときに、シードのソースとして特定のコピーを使用するには、次の手順を実行します。
Add-MailboxDatabaseCopy コマンドレットの SeedingPostponed パラメーターを使用して、データベース コピーを追加します。 それ以外の場合、データベース コピーは、データベースのアクティブなコピーをソースとして使用して明示的にシードされます。
EAC の更新メールボックス データベース コピー ウィザードで使用するソース サーバーを指定するか、Update-MailboxDatabaseCopy コマンドレットの SourceServer パラメーターを使用して、シード処理を行うソース サーバーを指定できます。
前の例では、ソース サーバーとして MBX3 を指定します。 それ以外の場合、データベース コピーは、データベースのアクティブなコピーから明示的にシードされます。
シードとネットワーク
メールボックス データベース コピーをシード処理するための特定のシード元サーバーを選択することに加え、Exchange 管理シェルを使用して、使用する DAG ネットワークも指定できます。 シード操作中に DAG ネットワークの圧縮と暗号化の設定をオーバーライドできます。
Update-MailboxDatabaseCopy コマンドレットのネットワーク パラメーターを使用して、シードに使用するネットワークを指定し、使用する DAG ネットワークを指定できます。 Network パラメーターを使用しない場合、システムは次の既定の動作を使用して、シード処理に使用するネットワークを選択します。
ソース サーバーとターゲット サーバーが同じサブネット上にあり、サブネットを含むレプリケーション ネットワークが構成されている場合は、レプリケーション ネットワークが使用されます。
ソース サーバーとターゲット サーバーが異なるサブネット上にある場合、それらのサブネットを含むレプリケーション ネットワークが構成されている場合でも、シード処理にはクライアント (MAPI) ネットワークが使用されます。
ソース サーバーとターゲット サーバーが異なるデータセンターにある場合は、シード処理にクライアント (MAPI) ネットワークが使用されます。
DAG レベルで暗号化と圧縮に関して DAG ネットワークが構成されます。 既定の設定では、異なるサブネット上での通信にのみ、暗号化と圧縮が使用されます。 ソースとターゲットが異なるサブネット上にあり、DAG が NetworkCompression と NetworkEncryption の既定値で構成されている場合は、Update-MailboxDatabaseCopy コマンドレットの NetworkCompressionOverride パラメーターと NetworkEncryptionOverride パラメーターを使用してこれらの値をオーバーライドできます。
シード処理
Add-MailboxDatabaseCopy または Update-MailboxDatabaseCopy コマンドレットを使用してシード処理を開始すると、以下のタスクが実行されます。
Active Directory からのデータベース プロパティは、指定したデータベースとサーバーを検証し、ソース サーバーとターゲット サーバーが Exchange Server を実行していること、どちらも同じ DAG のメンバーであること、および指定したデータベースが回復データベースではないことを確認するために読み取られます。 データベース ファイルのパスも読み取られます。
シード先サーバーの Microsoft Exchange レプリケーション サーバーから、再シード チェックの準備が行われます。
シード先サーバーの Microsoft Exchange レプリケーション サービスが、ステップ 1 で Active Directory チェックによって読み取られたファイル ディレクトリにデータベースとトランザクション ログ ファイルが存在することをチェックします。
Microsoft Exchange レプリケーション サービスが、コマンドレットが実行された管理インターフェイスに、シード先サーバーからの状態情報を返します。
すべての予備チェックに合格すると、続行する前に操作の確認を求めるメッセージが表示されます。 操作を確認すると、処理が続行します。 事前チェック中にエラーが発生すると、エラーが報告され、操作は異常終了します。
シード操作は、シード先サーバーの Microsoft Exchange レプリケーション サービスから開始します。
Microsoft Exchange レプリケーション サービスは、アクティブ データベース コピーのデータベース レプリケーションを中断します。
Microsoft Exchange レプリケーション サービスは、シード処理の状態を反映するようにデータベースの状態情報を更新します。
ターゲット サーバーにターゲット データベースとログ ファイルのディレクトリがまだない場合は、それらが作成されます。
データベースをシードするための TCP 要求は、ターゲット サーバー上の Microsoft Exchange レプリケーション サービスからソース サーバー上の Microsoft Exchange レプリケーション サービスに渡されます。 この要求と、データベースをシードするための後続の通信は、レプリケーション ネットワークとして構成された DAG ネットワーク上で行われます。
シード先 Microsoft Exchange レプリケーション サービスが、Microsoft Exchange インフォメーション ストア サービス インターフェイス経由で、Extensible Storage Engine (ESE) ストリーミング バックアップを開始します。
Microsoft Exchange インフォメーション ストア サービスが、Microsoft Exchange レプリケーション サービスにデータベース データをストリームします。
シード元サーバーの Microsoft Exchange レプリケーション サービスから、シード先サーバーの Microsoft Exchange レプリケーション サービスまで、データベース データが移動します。
ターゲット サーバー上の Microsoft Exchange レプリケーション サービスは、 一時シードと呼ばれるメイン データベース ディレクトリにある一時ディレクトリにデータベース コピーを書き込みます。
データベースの最後に到達すると、シード元サーバー上のストリーミング バックアップ操作が終了します。
シード先サーバーの書き込み操作が完了し、temp-seeding ディレクトリから最終的な場所までデータベースが移動します。 temp-seeding ディレクトリが削除されます。
シード先サーバー上で Microsoft Exchange レプリケーション サービスが Microsoft Exchange 検索サービスに要求を転送し、データベース コピーのコンテンツ インデックス カタログをマウントします (存在する場合)。 データベース コピーの以前のインスタンスの最新ではないカタログ ファイルが存在する場合、マウント操作は失敗し、結果としてシード元サーバーからのカタログの複製が必要になります。 同様に、シード先サーバーのデータベース コピーの新しいインスタンスにカタログが存在しない場合、カタログのコピーが必要になります。 Microsoft Exchange レプリケーション サービスが Microsoft Exchange 検索サービスを検出し、シード元から新しいカタログをコピーしている間、データベース コピーのインデックス処理を中断します。
シード先サーバーの Microsoft Exchange レプリケーション サービスがシード元サーバーの Microsoft Exchange レプリケーション サービスに、シードカタログ要求を送信します。
ソース サーバーでは、Microsoft Exchange レプリケーション サービスは Microsoft Exchange Search Service にディレクトリ情報を要求し、インデックス作成を中断するように要求します。
シード元サーバーの Microsoft Exchange 検索サービスが、Microsoft Exchange レプリケーション サービスに検索カタログ ディレクトリ情報を返します。
シード元サーバーの Microsoft Exchange レプリケーション サービスが、ディレクトリからのカタログ ファイルを読み取ります。
シード元サーバーの Microsoft Exchange レプリケーション サービスが、レプリケーション ネットワークにわたる接続を使用して、シード先サーバーの Microsoft Exchange レプリケーション サービスにカタログ データを移動します。 読み取りが完了すると、Microsoft Exchange レプリケーション サービスが Microsoft Exchange 検索サービスにシード元データベースのインデックス処理を再開する要求を送信します。
シード先サーバーのディレクトリに何らかの既存ファイルが存在する場合、シード先サーバーの Microsoft Exchange レプリケーション サービスがそれらのファイルを削除します。
ターゲット サーバー上の Microsoft Exchange レプリケーション サービスは、データが完全に転送されるまで、 カタログ データを CiSeed.Temp という一時ディレクトリに書き込みます。
Microsoft Exchange レプリケーションサービスが、最終的な場所にまで完全なカタログ データを移動します。
シード先サーバーの Microsoft Exchange レプリケーションサービスが、シード先データベースの検索インデックス処理を再開します。
シード先サーバーの Microsoft Exchange レプリケーションサービスが完了状態を返します。
オペレーションの最終結果が、コマンドレットの呼び出し元である管理インターフェイスに返されます。
データベース コピーの構成
データベース コピーが作成されると、必要なときにデータベース コピーの構成設定を表示して変更できるようになります。 EAC で、データベース コピーの [プロパティ] ページを確認すると、いくつかの構成情報を表示できます。 また、Exchange 管理シェルで Get-MailboxDatabase コマンドレットと Set-MailboxDatabaseCopy コマンドレットを使用して、データベース コピーの設定を表示および構成することもできます。 たとえば、再生ラグ タイム、切り捨てラグ タイム、アクティブ化の基本設定順序などです。 データベース コピー設定の表示と構成に関する詳しい手順については、「 メールボックス データベースのコピーのプロパティを構成する」を参照してください。
再生の時間差オプションと切り捨ての時間差オプションの使用
メールボックス データベース コピーは、再生の時間差と切り捨ての時間差 (両者とも分単位で構成する) の使用をサポートします。 再生の時間差を設定することで、データベース コピーを特定の時点にまで戻すことができるようになります。 切り捨ての時間差を設定することで、パッシブ データベース コピーのログを使用して、アクティブ データベース コピーのログ ファイルの損失を復元できるようになります。 これらの機能はどちらもログ ファイルが一時的に蓄積されるため、いずれかを使用するとストレージの設計に影響します。
再生の時間差
再生の時間差とは、メールボックス データベース コピーのプロパティであり、データベース コピーのログ再生を遅らせる時間を分で指定します。 再生ラグ タイマーは、ログ ファイルがパッシブ コピーにレプリケートされ、検査に合格したときに開始されます。 データベース コピーへのログの再生を遅らせて、データベースを過去の特定時点にまで復元できるようになります。 再生ラグタイムが 0 より大きいように構成されたメールボックス データベース コピーは、 ラグ メールボックス データベース コピー、または単に ラグ コピーと呼ばれます。
データベース コピーと Exchange Server の訴訟ホールド機能を使用する戦略は、通常はデータ損失の原因となるさまざまな障害から保護できます。 ただし、これらの機能では、論理的な破損によるデータ損失を防ぐことはできません。 論理的な破損はまれですが、データ損失の原因になる可能性があります。 時間遅れコピーは、論理的な破損によるデータの損失を防ぐために設計されています。 一般的に、論理的な破損には以下の 2 種類が存在します。
データベースの論理的破損: データベース ページのチェックサムは一致していますが、ページ上のデータは論理的に間違っています。 この状況は、ESE がデータベース ページの書き込みを試みたときに発生します。 オペレーティング システムは成功メッセージを返しますが、データがディスクに書き込まれないか、間違った場所に書き込まれます。 この状態は 、フラッシュ損失と呼ばれます。 ロスト フラッシュによりデータを失わないようにするため、ESE により、ページ パッチ機能 (単一ページの復元) と一緒に、ロスト フラッシュ検出機構がデータベースに組み込まれています。
ストアの論理的な破損: ユーザーが予期しない方法でデータの追加、削除、または操作が行われる。 通常、Microsoft 以外のアプリケーションでこのようなケースが発生します。 これは、ユーザーがこれを破損と見なすという意味で、一般に破損と見なされます。 Exchange ストアは、論理的破損を引き起こすトランザクションを一連の有効な MAPI 操作として見なします。 Exchange Server の訴訟ホールド機能は、ストアの論理的破損から保護します (ユーザーまたはアプリケーションによってコンテンツが完全に削除されないようにするため)。 ただし、ユーザー メールボックスの破損がひどくなって、データベースを破損前の時点に復元し、ユーザー メールボックスをエクスポートして破損していないデータを取得する方が簡単になるシナリオもあります。
データベース コピー、情報保留ポリシー、および ESE 単一ページ復元を組み合わせることで、まれに発生する壊滅的なストアの論理的破損以外の破損に対処できます。 リプレイ ラグ (タイムラグ コピー) のあるデータベース コピーを使用するかどうかの決定は、使用する Microsoft 以外のアプリケーションと、ストアの論理的破損に関する organization の履歴によって異なります。
時間差コピーを使用する場合、以下の点に注意してください。
リプレイのラグ時間は管理者が構成する値です。 既定では、リプレイ ラグ タイムは無効になっています。
リプレイのラグ時間の設定には、0 日の既定の設定と 14 日の最大設定があります。
時間差コピーは高可用コピーとは見なされません。 代わりに、ストアの論理的破損から保護するために、ディザスター リカバリー目的で設計されています。
再生の時間差設定が大きくなればなるほど、データベースの復旧処理も長くなります。 次の理由により、データベースの回復に数時間かかる場合があります。
- 再生するログ ファイルの数。
- ハードウェアがそれらを再生できる速度。
全体的な障害復旧戦略にとって、時間差コピーが必要不可欠であるかどうかを判断することを推奨します。 時間差コピーの使用が戦略上必要不可欠であれば、複数の時間差コピーを使用するか、複数の時間差コピーを使用しないのであれば RAID (Redundant Array of Independent Disks) を使用して単一の時間差コピーを保護することを推奨します。 ディスクを失うか、破損が発生しても、すぐに時間差コピーを失うことはありません。
ESE シングル ページ復元機能では、遅れたコピーにパッチを適用することはできません。 遅延したコピーでデータベース ページの破損 (-1018 エラーなど) が発生した場合は、コピーを再シードする必要があります。 再シードすると、コピーの遅延の側面が失われます。
データベースですべてのログ ファイルを再生し、データベース コピーを最新の状態にしたい場合、遅れているメールボックス データベース コピーのアクティブ化と回復は簡単なプロセスです。 特定の時点までのログ ファイルを再生する場合は、手動でログ ファイルを操作して Exchange Server Database Utilities (Eseutil.exe) を実行する必要があるため、このプロセスはより困難になります。
時間差のあるメールボックス データベース コピーをアクティブ化する方法の詳細については、「 時間遅れのメールボックス データベース コピーをアクティブ化する」を参照してください。
切り捨ての時間差
切り捨てラグ タイムとは、ログ ファイルがデータベース コピーに再生された後、データベース コピーのログ削除を遅延させる時間 (分単位) を指定するメールボックス データベース コピーのプロパティです。 切り捨ての時間差タイマーは、ログ ファイルがパッシブ コピーに複製され、検査に合格し、データベースのコピーに正常に再生された時点から開始します。 データベース コピーからログ ファイルの切り捨てを遅らせることで、データベースのアクティブ コピーのログ ファイルに影響を与える障害から復旧できるようになります。
データベース コピーとログの切り捨て
ログ切り捨ては、Exchange 2010 の場合と同じように Exchange 2016 および Exchange 2019 でも動作します。 切り捨て動作は、コピーの再生の時間差と切り捨ての時間差設定によって決定します。
時間差設定が既定値である 0 (無効) に設定されている場合、データベース コピーのログ ファイルが切り捨てられるには、以下の基準に一致する必要があります。
- ログ ファイルは正常にバックアップされているか、循環ログが有効になっています。
- ログ ファイルがデータベースのチェックポイント (復旧に必要な最小ログ ファイル) 未満である必要があります。
- 他のすべての時間差コピーは、ログ ファイルを調べました。
- 他のすべてのコピー (遅延コピーを除く) がログ ファイルを再生しました。
時間差データベース コピーで切り捨てが行われるには、以下の基準に一致する必要があります。
- ログ ファイルがデータベースのチェックポイント未満である必要があります。
- ログ ファイルが ReplayLagTime + TruncationLagTime より古い必要があります。
- アクティブなコピーではログ ファイルが切り捨てられます。
Exchange Server では、1 つ以上のパッシブ コピーが一時停止されている場合、アクティブ メールボックス データベース コピーでログ切り捨ては発生しません。 計画メンテナンス アクティビティに長時間 (数日など) かかる場合は、かなりのログ ファイルが蓄積される可能性があります。 ログ ドライブがトランザクション ログで満杯になることを防止するには、影響を受けたパッシブ データベース コピーを中断するのではなく削除します。 計画された保守が完了したら、パッシブ データベース コピーをもう一度追加できます。
Exchange Server には、既定で無効になっているルース トランケーションと呼ばれる機能があります。 通常の操作では、データベースのすべてのコピーで確認が完了するまで、各データベース コピーには他のデータベース コピーに出荷する必要があるログが保持されます。
- ログ ファイル (パッシブ コピー) を再生しました。
- ログ ファイル (遅延コピー) を受け取りました。
この動作は、既定のログ切り捨て動作です。 あるデータベース コピーが何らかの理由でオフラインになると、他のデータベース コピーで使用されるディスク上でログ ファイルが蓄積されていきます。 当該データベース コピーが長期にわたってオフラインのままになると、他のデータベース コピーがディスク領域を使い尽くす可能性があります。
ルース 切り捨てと循環ログが有効になっている場合、切り捨て動作は異なります。 各データベース コピーは、それ自身のディスク空き領域を追跡して、空き領域が少なくなった場合に緩やかな切り捨て動作を適用します。
アクティブ コピーの場合は、最も古い残存コピー (ログ再生が最も後回しのパッシブ データベース コピー) が無視され、切り捨てで残りの最も古いパッシブ コピーが尊重されます。 アクティブ データベース コピーでは、グローバル切り捨てが計算されます。
パッシブ コピーの場合、領域が少なくなると、レジストリ値の表で後述する構成されたパラメーターを使用してログ ファイルが個別に切り捨てられます。 パッシブ コピーは、アクティブなコピーに対して行われた切り捨ての決定を尊重しようとします。 MinCopiesToProtect という名前が示唆しているにもかかわらず、Exchange は、切り捨ての実行時点で、既知の最も古い落伍者のみを無視します。
オフライン データベースがオンラインに戻ると、その存在しないログ ファイルは他の正常なコピーから削除され、データベース コピーの状態が FailedAndSuspended になる。 この場合、自動再シードが構成されている場合、影響を受けるコピーは自動的に再シードされます。 自動再シードが構成されていない場合は、管理者がデータベース コピーを手動でシードする必要があります。
循環ログが無効になっている場合、ルース切り捨てでは、作成されたバックアップが考慮されます。 ルース トランケーションでは、バックアップされていないログ ファイルは削除されません。
切り捨ては、バックアップを使用せず、循環ログが有効になっている推奨アーキテクチャに推奨される機能です。
必要な正常コピーの数、空きディスク スペースのしきい値、保持されるログの数は、すべて構成可能パラメーターです。 既定で、ディスクの空き領域のしきい値は 204800 MB (200 GB) で、保持されるログの数はパッシブ コピーが 100,000 (100 GB)、アクティブ コピーが 10,000 (10 GB) です。
緩やかな切り捨てを有効にし、緩やかな切り捨てパラメーターを構成するには、各 DAG メンバー上で Windows レジストリを編集します。 構成できるレジストリ値は 3 つあり、すべて HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation の下に格納されています。 BackupInformation キー: 次の DWORD 値は既定では存在しないため、手動で作成する必要があります。 以下の表で、BackupInformation の下の DWORD レジストリ値について説明します。
| レジストリ値 | 説明 | 既定値 |
|---|---|---|
| LooseTruncation_MinCopiesToProtect | このキーは緩やかな切り捨てを有効にするために使用されます。 データベースのアクティブ コピーに対する緩やかな切り捨てから保護されるパッシブ コピーの数を表しています。 このキーの値を 0 に設定すると、緩やかな切り捨てが無効になります。 | 0 |
| LooseTruncation_MinDiskFreeSpaceThresholdInMB | 緩やかな切り捨てのトリガーに使用可能なディスク領域 (MB) のしきい値。 空きディスク スペースがこの値より小さくなると、切り詰めがトリガーされます。 | このレジストリ値が構成されていない場合、ルース 切り捨てで使用される既定値は 200 GB です。 |
| LooseTruncation_MinLogsToProtect | ログが切り捨てられる正常なコピーに関して保持されるログ ファイルの最小数。 このレジストリ値が構成されている場合は、構成された値がアクティブ コピーとパッシブ コピーの両方に適用されます。 | このレジストリ値が構成されていない場合、パッシブ データベース コピーの場合は既定値である 100,000、アクティブ データベース コピーの場合は 10,000 が使用されます。 |
LooseTruncation_MinLogsToProtect レジストリ値を使用する場合、アクティブ データベース コピーとパッシブ データベース コピーの動作は異なります
- アクティブ: 保護されたパッシブ コピーで必要なログの前に保持される追加ログの数、およびアクティブ コピーの必要な範囲。
- パッシブ: 使用可能な最新のログから保持されるログの数。 この数値の 10 分の 1 は、このパッシブ コピーの必要な範囲より前のログを維持するためにも使用されます。
この 2 つの制限は、必要な範囲が一般に非常に大きいため、遅延したデータベース コピーが領域を占有しすぎないようにするためのものです。
データベースのアクティブ化ポリシー
メールボックス データベース コピーを作成して、システムがそのコピーを自動的にアクティブ化しないようにしたい場合があります。 たとえば、障害後:
- 1 つ以上のメールボックス データベースのコピーを代替データセンターまたはスタンバイ データセンターに展開します。
- リカバリ目的でラグ データベース コピーを構成します。
- メンテナンスまたはサーバーのアップグレードを行っています。
上記の各シナリオでは、データベース コピーを自動的にアクティブにすることはできません。 メールボックス データベース コピーが自動的にアクティブにならないようにするため、アクティベーションを禁止 (中断) するようにコピーを構成できます。
この構成により、システムはログ配布と再生を通じてデータベースの最新性を維持できますが、システムがコピーを自動的にアクティブ化して使用することはできません。 管理者は、アクティブ化がブロックされているコピーを手動でアクティブ化する必要があります。
次の場合は、 DatabaseCopyAutoActivationPolicy パラメーターを Blocked に設定できます。
- Set-MailboxServer コマンドレットを使用したサーバー全体。
- Set-MailboxDatabaseCopy コマンドレットを使用した個々のデータベース コピー。
データベースのアクティベーション ポリシーの構成の詳細については、「メールボックス データベースのコピーのライセンス認証ポリシーを構成する」を参照してください。
メールボックスの移動の連続レプリケーションへの影響
アクセス回数が非常に多く、ログ生成率の高いメールボックス データベースでは、パッシブ データベース コピーのレプリケーションがログ生成に間に合わない場合に、データが損失する可能性が高くなります。 ログ生成率が高くなるシナリオの 1 つにメールボックスの移動があります。 Exchange Server には、Exchange メールボックス レプリケーション サービス (MRS) などのサービスで使用されるデータ保証 API が含まれており、システムまたは管理者によって設定された DataMoveReplicationConstraint パラメーターの値に基づいてデータベース コピー アーキテクチャの状態をチェックします。 具体的には、データ保証 API を使用すると、以下のような作業が可能になります。
レプリケーションの正常性を確認する: 前提条件となる数のデータベース コピーが利用可能であることを確認します。
レプリケーションのフラッシュを確認する: 必要なログ ファイルが前提条件のデータベース コピー数に対して再生されることを確認します。
実行すると、API は呼び出し元のアプリケーションに次の状態情報を返します。
再試行: データベースに対して条件をチェックできない一時的なエラーが存在することを示します。
満足: データベースが必要な条件を満たしているか、データベースがレプリケートされていないことを示します。
NotSatisfied: データベースが必要な条件を満たしていないことを示します。 さらに、 NotSatisfied 応答が返された理由に関する情報を、呼び出し元のアプリケーションに提供します。
メールボックス データベースの DataMoveReplicationConstraint パラメーターの値によって、要求の一部として評価するデータベース コピーの数が決まります。 DataMoveReplicationConstraint パラメーターには、次の値を指定できます。
None: メールボックス データベースの作成時に、この値は既定で設定されます。 この値を設定すると、データ保証 API の条件は無視されます。 この設定は、レプリケートされないメールボックス データベースにのみ使用します。SecondCopy: これは、メールボックス データベースの 2 つ目のコピーを追加するときの既定値です。 この値を設定する場合、少なくとも 1 つのパッシブ データベース コピーがデータ保証 API の条件を満たしている必要があります。SecondDatacenter: この値を設定すると、別の Active Directory サイトにある少なくとも 1 つのパッシブ データベース コピーがデータ保証 API の条件を満たしている必要があります。AllDatacenters: この値を設定すると、各 Active Directory サイトで少なくとも 1 つのパッシブ データベース コピーがデータ保証 API の条件を満たしている必要があります。AllCopies: この値を設定すると、メールボックス データベースのすべてのコピーがデータ保証 API の条件を満たしている必要があります。
レプリケーションの正常性の確認
データベース コピーのインフラストラクチャの正常性を評価するためにデータ保証 API が実行されると、いくつかのアイテムが評価されます。
すべてのシナリオで、パッシブ データベース コピーは次の条件を満たしている必要があります。
正常である。
再生キューの再生ラグ タイムが 10 分以内である。
コピー キューの長さが 10 ログ未満である。
コピー キューの平均の長さが 10 ログ未満である。 コピー キューの平均長は、アプリケーションがデータベースの状態を照会した回数に基づいて計算されます。
| DataMoveReplicationConstraint パラメーターが次の値に設定されている場合... | 次に、特定のデータベースに対して... |
|---|---|
SecondCopy |
レプリケートされたデータベースに対して少なくとも 1 つのパッシブ データベース コピーは、前述の条件を満たしている必要があります。 |
SecondDatacenter |
別の Active Directory サイトにある少なくとも 1 つのパッシブ データベース コピーが、前述の条件を満たしている必要があります。 |
AllDatacenters |
アクティブ コピーをマウントする必要があり、各 Active Directory サイト内のパッシブ コピーは、前述の条件を満たしている必要があります。 |
AllCopies |
アクティブ コピーをマウントする必要があり、すべてのパッシブ データベース コピーが前述の条件を満たしている必要があります。 |
レプリケーション フラッシュの確認
データ保証 API は、必要な数のデータベース コピーが必要なトランザクション ログを再生したことを検証するためにも使用できます。 これは、最後に再生されたログのタイムスタンプと、呼び出し元サービスのコミット タイムスタンプ (ほとんどの場合、これは必要なデータを含む最後のログ ファイルのタイムスタンプ) に (システム時刻時計のずれやドリフトに対処するため) 追加の 5 秒を加えたタイムスタンプと比較することによって検証されます。 再生タイムスタンプがコミット タイムスタンプより大きい場合、 DataMoveReplicationConstraint パラメーターが満たされます。 再生タイムスタンプがコミット タイムスタンプより小さい場合、 DataMoveReplicationConstraint は満たされません。
DAG 内のレプリケーション データベースとの間で大量のメールボックスを移動する前に、次の表に従って、各メールボックス データベースで DataMoveReplicationConstraint パラメーターを構成することをお勧めします。
| デプロイ中の場合... | DataMoveReplicationConstraint を以下に設定します... |
|---|---|
| データベース コピーを持たないメールボックス データベース | None |
| 1 つの Active Directory サイト内の DAG | SecondCopy |
| 分散されている Active Directory サイトを使用する複数のデータセンター内の DAG | SecondCopy |
| 2 つの Active Directory サイトにまたがり、各サイトに高可用性データベース コピーがある DAG | SecondDatacenter |
| 2 つの Active Directory サイトにまたがっていて、2 つ目のサイトに遅れているデータベース コピーのみがある DAG | SecondCopy データ保証 API では、ログ ファイルがデータベース コピーに再生されるまで、データがコミットされることは保証されません。 データベース コピーの遅延の性質上、遅延したデータベース コピーの ReplayLagTime 値が 30 分未満でない限り、この制約は移動要求は失敗します。 |
| 3 つ以上の Active Directory サイトにまたがり、各サイトに高可用性データベース コピーが含まれている DAG | AllDatacenters |
データベース コピーのバランス維持
DAG 固有の特性により、データベースの切り替えとフェールオーバーの結果として、アクティブなメールボックス データベース コピーは、DAG の有効期間の間にホストを数回変更します。 この結果、アクティブなメールボックス データベース コピー配布の点で DAG のバランスがくずれる可能性があります。 次の表に、アクティブなデータベース コピーが不均等に配布された、それぞれに各データベースの 4 つのコピーを持つ 4 つのデータベースがある DAG (各サーバーに合計 16 個のデータベース) の例を示します。
| サーバー | アクティブなデータベースの数 | パッシブなデータベースの数 | マウントされたデータベースの数 | マウント解除されたデータベースの数 | 優先順位カウント一覧 |
|---|---|---|---|---|---|
| EX1 | 5 | 11 | 5 | 0 | 4, 4, 3, 5 |
| EX2 | 1 | 15 | 1 | 0 | 1, 8, 6, 1 |
| EX3 | 12 | 4 | 12 | 0 | 13, 2, 1, 0 |
| EX4 | 1 | 15 | 1 | 0 | 1, 1, 5, 9 |
前の例では、各データベースの 4 つのコピーがあるため、アクティブ化優先順位に指定できる値は 4 つ (1、2、3、または 4) しかありません。 「優先順位カウント一覧」 列は、アクティブ化優先順位の値ごとにデータベース数のカウントを示したものです。 たとえば、EX3 には、アクティブ化優先順位が 1 のデータベース コピーが 13 個、アクティブ化優先順位が 2 のコピーが 2 個、アクティブ化優先順位が 3 のコピーが 1 個あり、アクティブ化優先順位が 4 のコピーはありません。
ご覧のとおり、この DAG は、各 DAG メンバーによってホストされているアクティブなデータベースの数、各 DAG メンバーによってホストされているパッシブなデータベースの数、またはホストされているデータベースのアクティブ化優先順位カウントの点でバランスがくずれています。
RedistributeActiveDatabases.ps1 スクリプトを使用すると、DAG 全体にわたってアクティブなメールボックス データベース コピーのバランスを維持できます。 このスクリプトは、DAG 内の各サーバーにマウントされているデータベースの数を均等にするために、データベースをコピー間で移動します。 必要に応じて、サイト全体でアクティブなデータベースのバランスをとることも試行します。
このスクリプトには、DAG 内でアクティブなデータベース コピーのバランスをとるために、次の 2 つのオプションが用意されています。
BalanceDbsByActivationPreference: このオプションを指定すると、スクリプトは、Active Directory サイトに関係なく、データベースを (アクティブ化の設定に基づいて) 最も優先されるコピーに移動しようとします。
BalanceDbsBySiteAndActivationPreference: このオプションが指定されている場合、スクリプトは、アクティブなデータベースを最も優先されるコピーに移動しようとすると同時に、各Active Directoryサイト内のアクティブなデータベースのバランスを取りようとします。
最初のオプションでスクリプトを実行すると、次の表に示すように、前述のバランスがくずれた DAG のバランスが調整されます。
| サーバー | アクティブなデータベースの数 | パッシブなデータベースの数 | マウントされたデータベースの数 | マウント解除されたデータベースの数 | 優先順位カウント一覧 |
|---|---|---|---|---|---|
| EX1 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX2 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX3 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX4 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
前の表に示したように、この DAG は、各サーバー上のアクティブとパッシブなデータベースの数、およびサーバー全体にわたるアクティブ化優先順位の点でバランスがとれた状態になりました。
次の表に、RedistributeActiveDatabases.ps1 スクリプトで使用可能なパラメーターを示します。
| パラメーター | 説明 |
|---|---|
| DagName | 再度バランスをとる DAG の名前を指定します。 このパラメーターを省略すると、ローカル サーバーがメンバーになっている DAG が使用されます。 |
| BalanceDbsByActivationPreference | Active Directory サイトを無視してデータベースをその最も優先されるコピーに移動するようにスクリプトに指定します。 |
| BalanceDbsBySiteAndActivationPreference | Active Directory サイト内のアクティブなデータベースのバランスをとる一方で、アクティブなデータベースをその最も優先されるコピーに移動するようにスクリプトに指定します。 |
| ShowFinalDatabaseDistribution | 再配布が完了した後に、現在のデータベース配布のレポートを表示することを指定します。 |
| AllowedDeviationFromMeanPercentage | サイト全体におけるアクティブなデータベースの許容変化量を割合で指定します。 既定値は 20% です。 たとえば、3 つのサイト間に 99 個のデータベースが配布されている場合、最適な配布は各サイトで 33 個のデータベースとなります。 許容変化量が 20% の場合、各サイトでこの個数の上下 10% を超えないように、スクリプトはデータベースのバランスをとろうとします。 33 の 10% は 3.3 で、切り上げて 4 になります。 したがって、スクリプトは各サイトでデータベースの数を 29 ～ 37 にしようとします。 |
| ShowDatabaseCurrentActives | 各データベースについて、データベースがどのように移動したか、データベースがその最も優先されるコピーでアクティブであるかどうかを詳細に示すレポートを生成するようにスクリプトに指定します。 |
| ShowDatabaseDistributionByServer | 各サーバーについて、そのデータベース配布を示すレポートを生成するようにスクリプトに指定します。 |
| RunOnlyOnPAM | 現在 PAM 役割を持つ DAG メンバー上でのみスクリプトを実行するように指定します。 スクリプトは、PAM から実行されていることを確認します。 PAM から実行されていない場合、スクリプトは終了します。 |
| LogEvents | アクションの概要を含むイベント (MsExchangeRepl イベント 4115) をログに記録するようにスクリプトに指定します。 |
| IncludeNonReplicatedDatabases | アクティブなデータベースの再配布方法の決定時に、レプリケートされていないデータベース (コピーを持たないデータベース) を含めるようにスクリプトに指定します。 レプリケートされていないデータベースは移動できませんが、レプリケートされたデータベースの分散に影響を与える可能性があります。 |
| 確認 | Confirm スイッチは、このスクリプトの実行時に既定で表示される確認プロンプトの表示の抑制に使用できます。 確認プロンプトの表示を抑制するには、syntax -Confirm:$False を使用します。 構文にコロン (:) を含める必要があります。 |
RedistributeActiveDatabases.ps1 の例
この例は、優先順位カウント一覧を含む DAG の現在のデータベース配布を示します。
RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table
この例では、入力を促すメッセージを表示しないで、アクティブ化優先順位を使用して、DAG 内のアクティブなメールボックス データベース コピーを再配布しバランスをとります。
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False
この例では、アクティブ化優先順位を使用して、DAG 内のアクティブなメールボックス データベース コピーを再配布しバランスをとり、配布の概要を生成します。
RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution
データベース コピーの監視
EAC でデータベース コピーの詳細を確認すると、コピー キューの長さ、再生キューの長さ、状態とコンテンツ インデックス状態情報などのさまざまな情報を表示できます。 さらに、 Get-MailboxDatabaseCopyStatus コマンドレットを Exchange 管理シェル で使用して、データベース コピーのさまざまな状態情報を表示することもできます。
注:
データベース コピーは、データベースのアクティブ コピーに影響を与える障害が発生した場合の、第一の防御です。 そのため、データベース コピーの正常性と状態を監視して、必要なときに使用できるようにすることが重要です。
データベース コピーの監視の詳細については、「 データベース可用性グループの監視」を参照してください。
データベース コピーの削除
EAC を使用するか、Exchange 管理シェルで Remove-MailboxDatabaseCopy コマンドレットを使用すれば、いつでもデータベース コピーを削除できます。 データベース コピーを削除した後、データベース コピーを削除するサーバーからすべてのデータベースとトランザクション ログ ファイルを手動で削除する必要があります。 データベース コピーを削除する方法の詳しい手順については、「 メールボックス データベース コピーを削除する」を参照してください。
データベース切り替え
データベースのアクティブ コピーをホストするメールボックス サーバーはメールボックス データベース マスターと呼ばれます。 パッシブ データベース コピーをアクティブにする処理により、データベースのメールボックス データベース マスターが変更され、パッシブ コピーが新しいアクティブ コピーに変わります。 この処理をデータベースの切り換えと呼びます。 データベースの切り替えでは、1 つのメールボックス サーバー上のデータベースのアクティブ コピーがマウント解除され、そのデータベースのパッシブ コピーが別のメールボックス サーバー上で新しいアクティブ メールボックス データベースとしてマウントされます。 切り替え実行時には、オプションで新しいメールボックス データベース マスターのデータベース マウント ダイヤル設定を上書きできます。
EAC の [データベース コピー] タブの下にある右側の列を確認すると、どのメールボックス サーバーが現在のメールボックス データベース マスターであるかをすばやく特定することができます。 EAC で [アクティブにする] リンクを使用するか、 Move-ActiveMailboxDatabase で Exchange 管理シェル コマンドレットを使用すると、切り替えを実行できます。
パッシブ コピーをアクティブ化する前に、いくつかの内部チェックが実行されます。 場合によっては、データベースの切り替えは禁止またはキャンセルされます。 その他の場合には、コマンドレットを使用して、いくつかのチェックを移動またはスキップすることができます。
データベース コピーの状態がチェックされます。 データベース コピーが障害状態にあると、切り替えは禁止されます。 この動作を無効にし、Move-ActiveMailboxDatabase コマンドレットの SkipHealthChecks パラメーターを使用して正常性チェックをバイパスできます。 このパラメーターを使用すると、障害状態にあるデータベース コピーにアクティブ コピーを移動できます。
アクティブ データベース コピーが、現在、データベースのいずれかのパッシブ コピーのシード元であるかどうかを確認するためにチェックされます。 アクティブ コピーが現在シード元として使用されている場合は、切り替えはブロックされます。 この動作を上書きし、Move-ActiveMailboxDatabase コマンドレットの SkipActiveCopyChecks パラメーターを使用してシード ソース チェックをバイパスできます。 このパラメーターを使用して、シード元として使用されているアクティブ コピーを移動できます。 このパラメーターを使用すると、シード処理操作が取り消され、失敗したと見なされます。
データベース コピーのコピー キューと再生キューの長さがチェックされ、これらの値が構成された基準の範囲内にあることが確認されます。 また、データベース コピーが確認され、現在シードのシード元として使用されていないことが確認されます。 キューの長さの値が構成された範囲外にある場合、またはデータベースが現在シードのシード元として使用されている場合、切り替えは禁止されます。 Move-ActiveMailboxDatabase コマンドレットの SkipLagChecks パラメーターを使用して、この動作を無効にし、これらのチェックをバイパスできます。 このパラメーターは、アクティブ化され、再生とコピーのキューを持つコピーが、構成された条件外になることを許可します。
データベース コピーの検索カタログ (コンテンツ インデックス) の状態がチェックされます。 検索カタログが最新ではない場合、異常な状態にある場合、または破損している場合、切り替えは禁止されます。 この動作を上書きし、Move-ActiveMailboxDatabase コマンドレットの SkipClientExperienceChecks パラメーターを使用して検索カタログ チェックをバイパスできます。 このパラメーターを使用すると、この検索はカタログの正常性チェックをスキップします。 アクティブ化するデータベース コピーの検索カタログが異常または使用不能な状態にあり、このパラメーターを使用してカタログ正常性チェックをスキップし、データベース コピーをアクティブ化する場合は、検索カタログを再度クロールまたはシードする必要があります。
データベース切り替えを実行するとき、アクティブにするパッシブ データベース コピーをホストするサーバーに構成されているマウント ダイヤル設定を上書きする方法もあります。 Move-ActiveMailboxDatabase コマンドレットの MountDialOverride パラメーターを使用すると、ターゲット サーバーは独自のマウント ダイヤル設定をオーバーライドし、MountDialOverride パラメーターで指定された設定を使用するように指示されます。
データベース コピーの切り替え方法の詳細な手順については、「メールボックス データベース コピーをアクティブにする」を参照してください。