メールボックス データベースのコピーの管理
製品: Exchange Server 2013
データベース可用性グループ (DAG) が作成され、構成され、メールボックス サーバー メンバーが設定されたら、Exchange 管理センター (EAC) または Exchange 管理シェルを使用して、柔軟かつきめ細かい方法でメールボックス データベース のコピーを追加できます。
データベース コピーの管理
データベースの複数のコピーが作成されたら、EAC またはシェルを使用して、各コピーの正常性と状態を監視したり、データベース コピーに関連付けられている他の管理タスクを実行したりできます。 実行の必要な可能性があるいくつかの管理タスクとして、データベース コピーの中断と再開、データベース コピーのシード処理、データベース コピーの監視、データベース コピー設定の構成、データベース コピーの削除があります。
データベース コピーの中断と再開
計画メンテナンスの実行など、さまざまな理由で、データベース コピーの継続的なレプリケーション アクティビティを一時停止して再開することが必要になる場合があります。 さらに、シード処理などの一部の管理タスクでは、最初にデータベース コピーを中断する必要があります。 データベースまたはそのログ ファイルのパスが変更されている場合は、すべてのレプリケーション アクティビティを中断することをお勧めします。 EAC を使用するか、シェルで Suspend-MailboxDatabaseCopy コマンドレットと Resume-MailboxDatabaseCopy コマンドレットを実行して、データベース コピー アクティビティを中断および 再開 できます。 データベース コピーの連続レプリケーション活動の中断または再開に関する詳しい手順については、「 メールボックス データベース コピーを中断または再開する」を参照してください。
データベース コピーのシード
シード処理 ( 更新) は、データベース (空のデータベースまたは運用データベースのコピー) が、アクティブ なデータベースと同じ DAG 内の別のメールボックス サーバー上のターゲット コピーの場所に追加されるプロセスです。 このデータベースは、そのサーバーで維持されるコピーのベースライン データベースとなります。
状況に応じて、シード処理は、自動プロセスまたは手動プロセスで開始できます。 データベース コピーが追加されると、シード先サーバーとそのストレージが適切に構成されていれば、コピーは自動的にシード処理されます。 データベース コピーを手動でシード処理し、コピーの作成時に自動シード処理を行いたくない場合は、Add-MailboxDatabaseCopy コマンドレットを実行するときに SeedingPostponed パラメーターを使用できます。
最初のシード処理が行われた後、データベース コピーを再シードする必要はほとんどありません。 ただし、再シード処理が必要な場合、またはシステムにコピーを自動的にシード処理するのではなく、データベース コピーを手動でシードする場合は、EAC のメールボックス データベース コピーの更新ウィザードを使用するか、シェルの Update-MailboxDatabaseCopy コマンドレットを使用して、これらのタスクを実行できます。 データベース コピーをシード処理する前に、先にメールボックス データベース コピーを中断する必要があります。 データベース コピーをシード処理する方法の詳しい手順については、「 メールボックス データベース コピーの更新」を参照してください。
手動シード操作が完了すると、シードされたメールボックス データ ベースのコピーは自動的に再開します。 複製を自動的に再開しない場合、Update-MailboxDatabaseCopy コマンドレットを実行するときに ManualResume パラメーターを使用します。
シード対象の選択
シード操作を実行する場合は、メールボックス データベースのコピー、メールボックス データベース コピーのコンテンツ インデックス カタログ、またはデータベース コピーとコンテンツ インデックス カタログのコピーの両方をシードできます。
メールボックス データベース コピーの更新ウィザードと Update-MailboxDatabaseCopy コマンドレットの既定の動作では、メールボックス データベース コピーとコンテンツ インデックス カタログ コピーの両方をシード処理します。 コンテンツ インデックス カタログをシードせずにメールボックス データベースのコピーだけをシードするには、Update-MailboxDatabaseCopy コマンドレットを実行するときに DatabaseOnly パラメーターを使用します。 コンテンツ インデックス カタログ コピーのみをシード処理するには、Update-MailboxDatabaseCopy コマンドレット使用時に、CatalogOnly パラメーターを使用します。
シード元の選択
あらゆる正常なデータベース コピーを、そのデータベースの追加コピー用のシード元として使用できます。 これは、DAG が複数の物理的な場所にまたがる場合などに特に便利です。 例として、2 メンバー (MBX1 と MBX2) がオレゴン州のポートランドに配置され、2 メンバー (MBX3 と MBX4) がニューヨーク州のニューヨークに配置されている 4 メンバーの DAG 展開を考えます。 メールボックス データベース DB1 が MBX1 上でアクティブであり、DB1 のパッシブ コピーが MBX2 と MBX3 にあるとします。 DB1 のコピーを MBX4 に追加する場合、MBX3 上でそのコピーをシード元として使用することができます。 こうすることで、ポートランドとニューヨーク間の広域ネットワーク (WAN) リンクを介してシードすることを回避できます。
新しいデータベース コピーを追加するときにシード処理のソースとして特定のコピーを使用するには、次の操作を行います。
データベース コピーを追加するには、Add-MailboxDatabaseCopy コマンドレットを実行するときに SeedingPostponed パラメーターを使用します。 SeedingPostponed パラメーターが使用されていない場合、データベースのアクティブなコピーをソースとして使用して、データベースのコピーが明示的にシードされます。
EAC でメールボックス データベースのコピーの更新ウィザードの一部として使用するソース サーバーを指定することも、Update-MailboxDatabaseCopy コマンドレットを実行するときに SourceServer パラメーターを使用してシード処理に必要なソース サーバーを指定することもできます。 上記の例では、MBX3 をシード元サーバーとして指定します。 SourceServer パラメーターが使用されていない場合、データベースのコピーは、データベースのアクティブなコピーから明示的にシード処理されます。
シードとネットワーク
メールボックス データベース のコピーをシード処理するための特定のソース サーバーを選択するだけでなく、シェルを使用して使用する DAG ネットワークを指定し、必要に応じてシード操作中に DAG ネットワークの圧縮と暗号化の設定をオーバーライドすることもできます。
注:
コンテキスト インデックス カタログのシード処理は、MAPI ネットワーク経由でのみ可能です。 これは、Update-MailboxDatabaseCopy コマンドレットで パラメーターを -Network 使用する場合でも当てはまります。
シード処理に使用するネットワークを指定するには、Update-MailboxDatabaseCopy コマンドレットを実行するときに Network パラメーターを使用し、使用する DAG ネットワークを指定します。 Network パラメーターを使用しない場合、システムはシード処理に使用するネットワークを選択するために、次の既定の動作を使用します。
シード元サーバーとシード先サーバーが同一サブネット上にあり、そのサブネットを含むレプリケーション ネットワークが構成済みの場合は、レプリケーション ネットワークが使用されます。
シード元サーバーとシード先サーバーが異なるサブネットに存在する場合、それらのサブネットを含むレプリケーション ネットワークが構成されていたとしても、シードにはクライアント (MAPI) ネットワークが使用されます。
シード元サーバーとシード先サーバーが異なるデータセンターに存在する場合、シードにはクライアント (MAPI) ネットワークが使用されます。
DAG レベルで暗号化と圧縮に関して DAG ネットワークが構成されます。 既定の設定では、異なるサブネット上の通信にのみ暗号化と圧縮を使用します。 シード元とシード先が異なるサブネット上に存在し、DAG に NetworkCompression および NetworkEncryption の既定値が構成されている場合、Update-MailboxDatabaseCopy コマンドレットを実行中にそれぞれ NetworkCompressionOverride と NetworkEncryptionOverride パラメーターを使用すると、これらの値を上書きできます。
シード処理
Add-MailboxDatabaseCopy コマンドレットまたは Update-MailboxDatabaseCopy コマンドレットを使用してシード処理を開始すると、次のタスクが実行されます。
Active Directory のデータベース プロパティは、指定されたデータベースとサーバーを検証し、ソース サーバーとターゲット サーバーが Exchange 2013 を実行していることを確認するために読み取られます。これらはどちらも同じ DAG のメンバーであり、指定されたデータベースが復旧データベースではないことを確認します。 データベース ファイルのパスも読み取られます。
シード先サーバーの Microsoft Exchange レプリケーション サーバーから、再シード チェックの準備が行われます。
シード先サーバーの Microsoft Exchange レプリケーション サービスが、ステップ 1 で Active Directory チェックによって読み取られたファイル ディレクトリにデータベースとトランザクション ログ ファイルが存在することをチェックします。
Microsoft Exchange レプリケーション サービスが、コマンドレットが実行された管理インターフェイスに、シード先サーバーからの状態情報を返します。
すべての事前チェックに合格すると、続行する前に操作を確認するように求められます。 操作を確認すると、処理が続行します。 事前チェック中にエラーが発生すると、エラーが報告され、操作は異常終了します。
シード操作は、シード先サーバーの Microsoft Exchange レプリケーション サービスから開始します。
Microsoft Exchange レプリケーション サービスは、アクティブ データベース コピーのデータベース レプリケーションを中断します。
データベースの状態情報が Microsoft Exchange レプリケーション サービスによって更新され、シードの状態が反映されます。
シード先サーバーにシード先データベースとログ ファイルのディレクトリが存在しない場合、作成されます。
シード先サーバーの Microsoft Exchange レプリケーション サーバーから、シード元サーバーの Microsoft Exchange レプリケーション サービスに、TCP を使用してデータベースをシードする要求が渡されます。 この要求とその後のデータベースをシードするための通信が、レプリケーション ネットワークとして構成された 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 検索サービスからのディレクトリ情報を要求し、インデックス処理の中断を要求します。
シード元サーバーの 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 で、データベース コピーの [プロパティ] ページを確認すると、いくつかの構成情報を表示できます。 シェルの Get-MailboxDatabase コマンドレットと Set-MailboxDatabaseCopy コマンドレットを使用して、再生ラグ タイム、切り捨てラグ時間、アクティブ化優先順序などのデータベース コピー設定を表示および構成することもできます。 データベース コピー設定の表示と構成に関する詳しい手順については、「 メールボックス データベースのコピーのプロパティを構成する」を参照してください。
再生の時間差オプションと切り捨ての時間差オプションの使用
メールボックス データベース コピーは、再生の時間差と切り捨ての時間差 (両者とも分単位で構成する) の使用をサポートします。 再生の時間差を設定することで、データベース コピーを特定の時点にまで戻すことができるようになります。 切り捨ての時間差を設定することで、パッシブ データベース コピーのログを使用して、アクティブ データベース コピーのログ ファイルの損失を復元できるようになります。 これらの機能の両方ともログ ファイルが一時的に増加するため、どちらの機能を使用するにしても、ストレージの設計に影響します。
再生の時間差
再生ラグ タイムは、データベース コピーのログ再生を遅延させる時間 (分単位) を指定するメールボックス データベース コピーのプロパティです。 再生の時間差タイマーは、ログ ファイルがパッシブ コピーに複製され、検査に合格した時点から開始します。 データベース コピーへのログの再生を遅らせて、データベースを過去の特定時点にまで復元できるようになります。 0 よりも大きい再生ラグ タイムで構成されたメールボックス データベース コピーは、遅延メールボックス データベース コピー、または単に時間差コピーと呼ばれます。
Exchange 2013 でデータベース コピーと訴訟ホールド機能を使用する戦略では、通常、データ損失の原因となるさまざまな障害に対する保護を提供できます。 ただしこれらの機能では、まれに発生し、データ損失の原因となる論理的な破損の場合、データ損失に対する保護は得られません。 時間差コピーは、論理的な破損の場合のデータの損失を防ぐことを目的としています。 一般的に、論理的な破損には以下の 2 種類が存在します。
データベースの論理的な破損: データベース ページのチェックサムが一致しますが、ページ上のデータが論理的に間違っています。 これは、ESE がデータベース ページに書き込もうとして、オペレーティング システムが成功メッセージを返したものの、データがディスクに書き込まれていないか、間違った場所に書き込まれた場合に発生します。 これは、ロスト フラッシュと呼ばれます。 ロスト フラッシュによりデータを失わないようにするため、ESE により、ページ パッチ機能 (単一ページの復元) と一緒に、ロスト フラッシュ検出機構がデータベースに組み込まれています。
ストアの論理的な破損: ユーザーが予期しない方法でデータを追加、削除、または操作します。 これらの場合は通常、サード パーティ製のアプリケーションによって引き起こされます。 これは通常、ユーザーの観点から見た意味での破損にすぎません。 Exchange ストアは、論理的破損を引き起こすトランザクションを一連の有効な MAPI 操作として見なします。 Exchange 2013 の訴訟ホールド機能は、ストアの論理的な破損からの保護を提供します (ユーザーまたはアプリケーションによってコンテンツが完全に削除されないようにするため)。 ただし、ユーザー メールボックスの破損の程度が激しい場合、データベースを破損前の時点にまで復元してから、ユーザー メールボックスをエクスポートして破損していないデータを取得する方が容易なシナリオも考えられます。
データベース コピー、情報保留ポリシー、および ESE 単一ページ復元を組み合わせることで、まれに発生する壊滅的なストアの論理的破損以外の破損に対処できます。 再生に時間差があるデータベース コピー (時間差コピー) を使用するかどうかは、どのサードパーティ製アプリケーションを使用するか、および組織でストアの論理的破損がこれまでにあったかどうかによって異なります。
特定のシナリオでログ ファイルを再生するために自動ログ再生を呼び出すと、遅延コピーは Exchange 2013 で自身を処理できます。
- 低ディスク容量のしきい値に達した場合
- 時間差コピーに物理的な破損があり、ページ パッチが必要な場合
- 24 時間を超える期間、正常なコピー (アクティブまたはパッシブのみ - 時間差データベース コピーは含まれません) が 3 つ未満の場合
ページ修正プログラムは、この自動再生ダウン機能を使用して、遅延コピーに使用できます。 時間差コピーに対してページ パッチが必要であることが検知されると、ログが自動的に時間差コピーに対して再生され、ページ パッチが実行されます。 時間差コピーでは、低ディスク容量のしきい値に達した場合、および時間差コピーが特定の時間帯において唯一の利用可能なコピーであると検知された場合にも、この自動再生機能が呼び出されます。
遅延コピーのログ再生動作は既定では無効で、有効にするには次のコマンドを実行します。
Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true
有効にすると、コピーが 3 つ未満の場合にログ再生が発生します。 次の DWORD レジストリ値を変更することで、既定値の 3 を変更できます。
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies
低ディスク容量のしきい値に対するログ再生を有効にするには、次のレジストリ エントリを構成する必要があります。
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB
これらのレジストリ設定を構成した後、Microsoft Exchange DAG 管理サービスを再開して、変更を有効にします。
たとえば、特定のデータベースに 4 つのコピー (3 つの高可用性コピーと 1 つの遅延コピー) があり、既定の設定が ReplayLagManagerNumAvailableCopies に使用されている環境を考えてみましょう。 何らかの理由 (一時停止など) により時間差でないコピーのサービスが停止していると、自動的に時間差コピーが 24 時間内のログ ファイルを再生します。
パラメーターを有効にせずに遅延コピーを使用する ReplayLagManagerEnabled 場合は、次の影響に注意してください。
再生の時間差は管理者によって構成され、既定では無効です。
再生の時間差設定は既定で 0 日で、最大値は 14 日です。
時間差コピーは高可用コピーとは見なされません。 時間差コピーは障害復旧を目的としていて、ストアの論理的破損に対する保護を行います。
再生の時間差設定が大きくなればなるほど、データベースの復旧処理も長くなります。 復旧時に再生が必要となるログ ファイルの個数、およびハードウェアがログ ファイルを再生する速度に応じて、データベースの復旧には数時間からそれより長い時間を要します。
全体的な障害復旧戦略にとって、時間差コピーが必要不可欠であるかどうかを判断することを推奨します。 時間差コピーの使用が戦略上必要不可欠であれば、複数の時間差コピーを使用するか、複数の時間差コピーを使用しないのであれば RAID (Redundant Array of Independent Disks) を使用して単一の時間差コピーを保護することを推奨します。 ディスクを失うか、破損が発生しても、すぐに時間差コピーを失うことはありません。
ESE シングル ページ復元機能では、遅延コピーに修正プログラムを適用できません。 遅延コピーでデータベース ページの破損 (-1018 エラーなど) が発生した場合は、再シードする必要があります (コピーの遅延の側面が失われます)。
データベースですべてのログ ファイルを再生し、データベースのコピーを最新の状態にする場合は、遅延メールボックス データベースのコピーをアクティブ化して回復するのは簡単なプロセスです。 ログ ファイルを特定の時点まで再生する場合は、ログ ファイルを手動で操作し、データベース ユーティリティ (Eseutil.exe) Exchange Server実行するため、より困難な操作になります。
遅延メールボックス データベースのコピーをアクティブ化する方法の詳細な手順については、「ラグド メールボックス データベース の コピーをアクティブ化する」を参照してください。
切り捨ての時間差
切り捨てラグタイムは、ログ ファイルがデータベース コピーに再生された後にデータベース コピーのログ削除を遅延させる時間 (分単位) を指定するメールボックス データベース コピーのプロパティです。 切り捨ての時間差タイマーは、ログ ファイルがパッシブ コピーに複製され、検査に合格し、データベースのコピーに正常に再生された時点から開始します。 データベース コピーからログ ファイルの切り捨てを遅らせることで、データベースのアクティブ コピーのログ ファイルに影響を与える障害から復旧できるようになります。
データベース コピーとログの切り捨て
ログの切り捨ては、Exchange 2010 と同じように Exchange 2013 で機能します。 切り捨て動作は、コピーの再生の時間差と切り捨ての時間差設定によって決定します。
時間差設定が既定値である 0 (無効) に設定されている場合、データベース コピーのログ ファイルが切り捨てられるには、以下の基準に一致する必要があります。
- ログ ファイルが正常にバックアップされている必要があるか、循環ログが有効になっている必要があります。
- ログ ファイルがデータベースのチェックポイント (復旧に必要な最小ログ ファイル) 未満である必要があります。
- すべてのその他の時間差コピーが、ログ ファイルを検査している必要があります。
- 他のすべてのコピー (遅延コピーではない) は、ログ ファイルを再生している必要があります。
時間差データベース コピーで切り捨てが行われるには、以下の基準に一致する必要があります。
- ログ ファイルがデータベースのチェックポイント未満である必要があります。
- ログ ファイルが ReplayLagTime + TruncationLagTime より古い必要があります。
- ログ ファイルがアクティブ コピーで切り捨てられている必要があります。
Exchange 2013 では、1 つ以上のパッシブ コピーが一時停止されている場合、アクティブなメールボックス データベースのコピーでログの切り捨てが発生しません。 計画された保守作業に長期間 (数日など) かかる場合は、ログ ファイルが大量に蓄積することがあります。 ログ ドライブがトランザクション ログで満杯になることを防止するには、影響を受けたパッシブ データベース コピーを中断するのではなく削除します。 計画された保守が完了したら、パッシブ データベース コピーをもう一度追加できます。
Exchange 2013 Service Pack 1 (SP1) では、 緩やかな切り捨てと呼ばれる新しい機能が導入され、既定で無効になっています。 通常の運用では、各データベース コピーが他のデータベース コピーに移す必要があるログを、すべてのデータベースのコピーがログ ファイルを再生 (パッシブ コピー) または受信 (時間差コピー) したことが確認されるまで保持します。 これは、既定のログの切り詰めの動作です。 あるデータベース コピーが何らかの理由でオフラインになると、他のデータベース コピーで使用されるディスク上でログ ファイルが蓄積されていきます。 当該データベース コピーが長期にわたってオフラインのままになると、他のデータベース コピーがディスク領域を使い尽くす可能性があります。
緩やかな切り捨てが有効になっている場合、切り捨ての動作は異なります。 各データベース コピーは、それ自身のディスク空き領域を追跡して、空き領域が少なくなった場合に緩やかな切り捨て動作を適用します。 アクティブ コピーの場合は、最も古い残存コピー (ログ再生が最も後回しのパッシブ データベース コピー) が無視され、切り捨てで残りの最も古いパッシブ コピーが尊重されます。 アクティブ データベース コピーでは、グローバル切り捨てが計算されます。 パッシブ コピーは、アクティブコピーに対して行われた切り捨て決定を尊重しようとします。 MinCopiesToProtect という名前が影響を受けるにもかかわらず、Exchange は切り捨てが実行された時点で最も古い既知のストラグラーのみを無視します。 パッシブ コピーの場合、領域が不足すると、以下で説明する構成済みのパラメーターを使用して、ログ ファイルが個別に切り捨てられます。
オフラインのデータベースがオンラインに戻ると、他の正常なコピーから削除されたログ ファイルがないので、そのデータベース コピーの状態は FailedAndSuspended になります。 この場合、Autoreseed が構成されていると、当該コピーは自動的に再シードされます。 Autoreseed が構成されていない場合は、管理者がデータベース コピーを手動でシードする必要があります。
必要な正常コピーの数、空きディスク スペースのしきい値、保持されるログの数は、すべて構成可能パラメーターです。 既定で、ディスクの空き領域のしきい値は 204800 MB (200 GB) で、保持されるログの数はパッシブ コピーが 100,000 (100 GB)、アクティブ コピーが 10,000 (10 GB) です。
緩やかな切り捨てを有効にし、緩やかな切り捨てパラメーターを構成するには、各 DAG メンバー上で Windows レジストリを編集します。 構成できるレジストリ値は 3 つあり、すべて に HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation格納されます。 次の DWORD 値を持つ BackupInformation キーは既定で存在しないため、手動で作成する必要があります。 以下の表で、BackupInformation の下の DWORD レジストリ値について説明します。
| レジストリ値 | 説明 | 既定値 |
|---|---|---|
| LooseTruncation_MinCopiesToProtect | このキーは緩やかな切り捨てを有効にするために使用されます。 データベースのアクティブ コピーに対する緩やかな切り捨てから保護されるパッシブ コピーの数を表しています。 このキーの値を 0 に設定すると、緩やかな切り捨てが無効になります。 | 0 |
| LooseTruncation_MinDiskFreeSpaceThresholdInMB | 緩やかな切り捨てのトリガーに使用可能なディスク領域 (MB) のしきい値。 空きディスク スペースがこの値より小さくなると、切り詰めがトリガーされます。 | このレジストリ値が構成されていない場合は、緩やかな切り捨てに使用される既定値が 200 GB になります。 |
| LooseTruncation_MinLogsToProtect | ログが切り捨てられる正常なコピーに関して保持されるログ ファイルの最小数。 このレジストリ値が構成されている場合は、構成された値がアクティブ コピーとパッシブ コピーの両方に適用されます。 | このレジストリ値が構成されていない場合は、パッシブ データベース コピーには 100,000 という既定値が、アクティブ データベース コピーには 10,000 という既定値が使用されます。 |
レジストリ値を使用する LooseTruncation_MinLogsToProtect 場合は、アクティブデータベースコピーとパッシブデータベースコピーの動作が異なる点に注意してください。 アクティブ なデータベース コピーでは、保護されたパッシブ コピーとアクティブ コピーの必要な範囲で必要なログの前に保持される追加のログの数です。パッシブ データベース コピーでは、最新の使用可能なログから保持されるログの数です。 この数の 10 分の 1 は、このパッシブ コピーの必要な範囲より前にログを維持するためにも使用されます。 必要な範囲は通常非常に大きいため、遅れたデータベース コピーが領域を占有しすぎないように、2 つの制限が設定されています。
データベースのアクティブ化ポリシー
次の例のように、メールボックス データベース コピーを作成し、障害時にそのコピーを自動的にアクティブにしないようにするシナリオが存在します。
- 1 つまたは複数のメールボックス データベース コピーを代替のデータ センターまたはスタンバイのデータ センターに展開する場合。
- 回復用に時間差データベース コピーを構成する場合。
- 保守やサーバーのアップグレードを実行している場合。
上記の各シナリオでは、データベース コピーを自動的にアクティブにすることはできません。 メールボックス データベース コピーが自動的にアクティブにならないようにするため、アクティベーションを禁止 (中断) するようにコピーを構成できます。 これにより、ログの配布と再生を通じてデータベースを最新に保ちつつ、システムがコピーを自動的にアクティブにして使用することを防ぐことができます。 アクティベーションが禁止されたコピーは、管理者が手動でアクティブにする必要があります。 Set-MailboxDatabaseCopy コマンドレットを使用して、Set-MailboxServer コマンドレットまたは個々のデータベース コピーを使用して、サーバー全体のデータベース ライセンス認証ポリシーを構成し、DatabaseCopyAutoActivationPolicy パラメーターを [ブロック] に設定できます。
データベースのアクティベーション ポリシーの構成の詳細については、「メールボックス データベースのコピーのライセンス認証ポリシーを構成する」を参照してください。
メールボックスの移動の連続レプリケーションへの影響
アクセス回数が非常に多く、ログ生成率の高いメールボックス データベースでは、パッシブ データベース コピーのレプリケーションがログ生成に間に合わない場合に、データが損失する可能性が高くなります。 ログ生成率が高くなるシナリオの 1 つにメールボックスの移動があります。 Exchange 2013 には、システムまたは管理者によって設定された DataMoveReplicationConstraint パラメーターの値に基づいてデータベース コピー アーキテクチャの正常性を確認するために、Microsoft Exchange メールボックス レプリケーション サービス (MRS) などのサービスで使用されるデータ保証 API が含まれています。 具体的には、データ保証 API を使用すると、以下のような作業が可能になります。
- レプリケーションの正常性を確認する: データベース コピーの前提条件の数が使用可能であることを確認します。
- レプリケーション フラッシュの確認: 必要なログ ファイルが、前提条件のデータベース コピー数に対して再生されたことを確認します。
実行すると、API は呼び出し元のアプリケーションに次の状態情報を返します。
- 再試行: 条件がデータベースに対してチェックされるのを妨げる一時的なエラーがあることを示します。
- 満足: データベースが必要な条件を満たしているか、データベースがレプリケートされていないことを示します。
- NotSatisfied: データベースが必要な条件を満たしていないことを示します。 さらに、 NotSatisfied 応答が返された理由に関する情報を、呼び出し元のアプリケーションに提供します。
メールボックス データベースの DataMoveReplicationConstraint パラメーターの値によって、要求の一部として評価する必要があるデータベース コピーの数が決まります。 DataMoveReplicationConstraint パラメーターには、次の可能な値があります。
-
None: メールボックス データベースを作成する場合、この値は既定で設定されます。 この値を設定すると、データ保証 API の条件は無視されます。 この設定は、レプリケートされないメールボックス データベースにのみ使用します。 -
SecondCopy: メールボックス データベースの 2 番目のコピーを追加する場合の既定値です。 この値を設定する場合、少なくとも 1 つのパッシブ データベース コピーがデータ保証 API の条件を満たしている必要があります。 -
SecondDatacenter: この値が設定されている場合、別の Active Directory サイト内の少なくとも 1 つのパッシブ データベース コピーが Data Guarantee API の条件を満たしている必要があります。 -
AllDatacenters: この値が設定されている場合、各 Active Directory サイト内の少なくとも 1 つのパッシブ データベース コピーが Data Guarantee API の条件を満たしている必要があります。 -
AllCopies: この値を設定すると、メールボックス データベースのすべてのコピーが Data Guarantee API の条件を満たす必要があります。
レプリケーションの正常性の確認
データベース コピーのインフラストラクチャの正常性を評価するためにデータ保証 API が実行されると、いくつかのアイテムが評価されます。
| 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 サイトにまたがる DAG。2 つ目のサイトに時間差データベース コピーのみを保存する。 | SecondCopy これは、データ保証 API は、ログ ファイルがデータベース コピーに再生されるまでコミット中のデータを保証しないためであり、遅延中のデータベース コピーの性質上、時間差データベース コピーの ReplayLagTime 値が 30 分未満でない場合、この制約により移動要求は失敗します。 |
| 3 つ以上の Active Directory サイトにまたがる DAG。各サイトには高可用性データベース コピーが保存される。 | AllDatacenters |
データベース コピーのバランス維持
DAG 本来の性質から、データベースの切り替えとフェールオーバーの結果として、アクティブなメールボックス データベース コピーによって DAG の有効期間内に何回かホストが変更されます。 この結果、アクティブなメールボックス データベース コピー配布の点で DAG のバランスがくずれる可能性があります。 次の表に、アクティブなデータベース コピーが不均等に配布された、それぞれに各データベースの 4 つのコピーを持つ 4 つのデータベースがある DAG (各サーバーに合計 16 個のデータベース) の例を示します。
バランスがくずれたアクティブなコピー配布を持つ DAG
| サーバー | の数 アクティブ なデータベース |
の数 パッシブ データベース |
の数 マウントされたデータベース |
の数 マウント解除されたデータベース |
優先順位カウント一覧 |
|---|---|---|---|---|---|
| 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 のバランスが調整されます。
バランスがとれたアクティブなコピー配布を持つ 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 スクリプトで使用可能なパラメーターを示します。
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 | 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 コマンドレットを使用して、データベース コピーのさまざまな状態情報を表示することもできます。
データベース コピーの監視の詳細については、「データベース可用性グループの監視」を参照してください。
データベース コピーの削除
データベース コピーは、EAC を使用するか、シェルの Remove-MailboxDatabaseCopy コマンドレットを使用して、いつでも削除できます。 データベース コピーを削除した後、データベース コピーを削除するサーバーからすべてのデータベースとトランザクション ログ ファイルを手動で削除する必要があります。 データベース コピーを削除する方法の詳しい手順については、「 メールボックス データベース コピーを削除する」を参照してください。
データベース切り替え
データベースのアクティブ コピーをホストするメールボックス サーバーはメールボックス データベース マスターと呼ばれます。 パッシブ データベース コピーをアクティブにする処理により、データベースのメールボックス データベース マスターが変更され、パッシブ コピーが新しいアクティブ コピーに変わります。 この処理をデータベースの切り換えと呼びます。 データベースの切り替えでは、1 つのメールボックス サーバー上のデータベースのアクティブ コピーがマウント解除され、そのデータベースのパッシブ コピーが別のメールボックス サーバー上で新しいアクティブ メールボックス データベースとしてマウントされます。 切り替え実行時には、オプションで新しいメールボックス データベース マスターのデータベース マウント ダイヤル設定を上書きできます。
EAC の [データベース コピー] タブの下にある右側の列を確認すると、どのメールボックス サーバーが現在のメールボックス データベース マスターであるかをすばやく特定することができます。 切り替えを実行するには、EAC の [アクティブ化 ] リンクを使用するか、シェルの Move-ActiveMailboxDatabase コマンドレットを使用します。
パッシブ コピーをアクティブ化する前に実行される内部チェックがいくつかあります。
データベース コピーの状態がチェックされます。 データベース コピーが障害状態にあると、切り替えは禁止されます。 この動作をオーバーライドし、Move-ActiveMailboxDatabase コマンドレットの SkipHealthChecks パラメーターを使用して正常性チェックをバイパスできます。 このパラメーターを使用すると、アクティブなコピーを失敗状態のデータベース コピーに移動できます。
アクティブ データベース コピーが、現在、データベースのいずれかのパッシブ コピーのシード元であるかどうかを確認するためにチェックされます。 アクティブ コピーが現在シード元として使用されている場合は、切り替えはブロックされます。 Move-ActiveMailboxDatabase コマンドレットの SkipActiveCopyChecks パラメーターを使用して、この動作をオーバーライドし、シード ソース チェックをバイパスできます。 このパラメーターを使用して、シード元として使用されているアクティブ コピーを移動できます。 このパラメーターを使用すると、シード処理がキャンセルされ、失敗となります。
データベース コピーのコピー キューと再生キューの長さがチェックされ、これらの値が構成された基準の範囲内にあることが確認されます。 また、データベース コピーが確認され、現在シードのシード元として使用されていないことが確認されます。 キューの長さの値が構成された範囲外にある場合、またはデータベースが現在シードのシード元として使用されている場合、切り替えは禁止されます。 Move-ActiveMailboxDatabase コマンドレットの SkipLagChecks パラメーターを使用して、この動作をオーバーライドし、これらのチェックをバイパスできます。 このパラメーターは、アクティブ化され、再生とコピーのキューを持つコピーが、構成された条件外になることを許可します。
データベース コピーの検索カタログ (コンテンツ インデックス) の状態がチェックされます。 検索カタログが最新ではない場合、異常な状態にある場合、または破損している場合、切り替えは禁止されます。 この動作をオーバーライドし、Move-ActiveMailboxDatabase コマンドレットの SkipClientExperienceChecks パラメーターを使用して、検索カタログ チェックをバイパスできます。 このパラメーターを使用すると、この検索はカタログの正常性チェックをスキップします。 アクティブにするデータベース コピーの検索カタログが異常、または使用不可能な状態にあり、このパラメーターを使用してカタログの正常性チェックをスキップしてデータベース コピーをアクティブにする場合、検索カタログを再度クロールするか、シードする必要があります。
データベースの切り替えを実行する場合は、アクティブ化されているパッシブ データベース コピーをホストするサーバー用に構成されたマウント ダイヤル設定をオーバーライドすることもできます。 Move-ActiveMailboxDatabase コマンドレットの MountDialOverride パラメーターを使用すると、ターゲット サーバーに独自のマウント ダイヤル設定をオーバーライドし、MountDialOverride パラメーターで指定されたものを使用するように指示します。
データベース コピーの切り替え方法の詳細な手順については、「メールボックス データベース コピーをアクティブにする」を参照してください。