破損通知

ディレクトリに保存される破損通知については非常に複雑なため、ビジネスでうまく利用されていない場合があります。一部のディレクトリ製品とは異なり、eDirectoryではオブジェクト間の参照の整合性が確保されています。たとえば、グループAにユーザBというメンバーが登録されていて、後からユーザBが削除されると、ディレクトリはグループAからユーザBへの参照を自動的に削除します。破損通知は、eDirectoryによってオペレーショナル属性としてオブジェクトに保存されます。これにより、削除、移動、リネーム、復元、およびその他の操作中に、二重に参照整合性が確保されます。

破損通知は大きく分類して、プライマリ、セカンダリおよびトラッキングの3種類があります。プライマリ破損通知には、停止(0001)、復元(0000)、移動(0002)、新規RDN(0005)、およびツリーの新規RDN(0008)の各種類がありあます。セカンダリ破損通知は、一般的にプライマリ破損通知に関連付けられており、プライマリ破損通知で指定された操作の通知が必要なエージェントおよびパーティションを表します。セカンダリ破損通知には、バックリンク(0006)、使用中(000C)、およびツリーの移動(000a)の各種類があります。トラッキング破損通知には移動禁止(0003)、古いRDN(0004)、およびツリーの古いRDN(0007)の各種類があります。

トラッキング破損通知以外の破損通知は、次の同期ステータスのセットを使用して移動する必要があります。

ステータスは破損通知属性のフラグフィールドで記録されます。破損通知が次のステータスに進む前に、現在のステータスは必ず実オブジェクトのすべてのレプリカに同期されます。リング内のすべてのレプリカが破損通知ステータスを与えられているかどうかを判断するために、遷移ベクトルからベクトルが計算されます。eDirectory 8.6以降では、保存されていない破損通知ベクトルが使用されます。以前のバージョンのeDirectoryでは、パージベクトルが使用されます。破損通知の変更タイムスタンプ(MTS)が破損ベクトルよりも古い場合、担当サーバは該当する破損通知を次のステータスに進めることができます。

「バックリンク」のセカンダリ破損通知の場合、該当する破損通知を含むオブジェクトのマスタレプリカを持つエージェントがステータスを進めます。「使用中」のセカンダリ破損通知の場合、レプリカが存在している間は該当する破損通知を作成したエージェントがステータスを進めます。レプリカが存在しない場合、パーティションのマスタを保持しているエージェントが「使用中」の破損通知のステータスを進めます。「ツリーの移動」の破損通知の場合、ルートパーティションのマスタがステータスを進めます。

プライマリ破損通知は、すべてのセカンダリ破損通知が最後のステータスまで進められた後でのみ、ステータスを進めることができます。プライマリ破損通知が最後のステータスまで進んだ後で、そのステータスがリング内のすべてのサーバに同期されると、残っているのは属性を持たないオブジェクトであるオブジェクトハスクのみとなり、これらはシステムのパージプロセスによってパージされます。トラッキング破損通知は、プライマリ破損通知の削除の準備が完了した後か、Inhibit_moveの場合はプライマリ破損通知がマスタレプリカのOBF_NOTIFIEDステータスに移動された後で削除されます。

破損通知の処理を担当するレプリカは、指定したパーティションがインバウンド同期サイクルを終了した後で、パーティションごとにスケジュールされているバックグラウンドプロセス(破損通知処理)を実行します。パーティションにその他のレプリカがない場合、アウトバウンドレプリケーション処理がハートビート間隔でスケジュールされたままになります。その後、アウトバウンドレプリケーション処理によって破損通知処理が開始されます。破損通知処理は手動ではスケジュールできず、また、その必要もありません。同期化が実行されると、遷移ベクトルが更新され、パージベクトルおよびObitベクトルを進めます。これらのベクトルが進められると、破損通知のステータスを進めることができます。これと同時に、インバウンド同期に自動スケジュールが実行されると、破損通知処理サイクルが完了します。すなわち、破損通知処理の起動要因はオブジェクト同期です。

削除されたオブジェクトの場合、「停止」のプライマリ破損通知に関連するすべての破損通知が最後のステータス(パージ可能)まで進められ、そのステータスがすべてのレプリカに同期された後で、新しい処理がデータベースに残っているエントリハスクの削除を担当します。これらのハスクを削除するために、パージ処理が自動的に実行されます。パージプロセスのスケジュールおよび自動スケジュール間隔の調整は、iMonitorのエージェント環境設定ページを使用して手動で設定することができます。

このセクションでは、次の例を紹介します。

オブジェクトの削除

  1. プライマリ破損通知OBT_DEADを追加します。
  2. バックリンクの属性には、このオブジェクトに関連し、このエントリに対する変更を通知する必要のあるサーバのリストが含まれています。バックリンク属性のリストに含まれる各DNと、エントリのパーティションレプリカ属性のリストに含まれるすべてのサーバに対して、eDirectoryはバックリンク破損通知を追加します。プライマリ破損通知(OBT_DEAD)の作成時刻は、セカンダリ破損通知に保存されます。
  3. 使用中の属性には、このオブジェクトに関連し、このエントリに対する変更を通知する必要のあるパーティションのリストが含まれています。使用中の属性のリストに含まれているすべてのDNに対して、eDirectoryは使用中の破損通知を追加します。プライマリ破損通知(OBT_DEAD)の作成時刻は、セカンダリ破損通知に保存されます。
  4. 破損通知以外のすべての属性を削除します。
  5. 次に、アウトバウンドレプリケーションプロセスによって、レプリカリング内にある他のすべてのサーバに変更が同期されます。
  6. このパーティションの次回のインバウンド同期が実行されるときに、破損通知処理が開始され、次の処理が実行されます。

    該当する破損通知が「プライマリ」破損通知で、「セカンダリ」破損通知がなく、破損通知の属性の変更タイムスタンプ(MTS)がパージベクトルよりも古い場合は、すべてのサーバが変更を確認済みであり、この破損通知は削除されます。

    該当する破損通知がバックリンク破損通知で、このサーバがマスタの場合、このサーバが破損通知の処理を担当します。

    ステータスが完了していない場合、このステータスに必要な操作を実行します。これは外部参照を通知するときに最も頻繁に実行されます。

    該当する破損通知が「使用中」の破損通知で、このサーバで削除が発生している場合(破損通知のMTSのレプリカ番号とローカルのレプリカ番号の比較から判断して)、このサーバがこの破損通知の処理を担当します。

オブジェクトの移動

移動は削除と非常によく似ていますが、次に挙げる操作が違います。

  1. プライマリ破損通知が移動元に配置される前に、エントリの一部が移動先のコンテナに作成され、そのエントリの一部にトラッキング破損通知(OBT_INHIBIT_MOVE)が配置されます。このトラッキング破損通知は、エントリが移動元から完全に移動される前にエントリが移動されたり、パーティション操作に加わるのを防ぐために配置されます。
  2. ソースエントリでは、プライマリ破損通知はOBT_MOVEDです。
  3. プライマリ破損通知OBT_MOVEDのステータスが通知済み(ソースのすべてのレプリカにエントリが移動されたことを通知した状態)になり、すべての外部参照に通知が完了すると、トラッキング破損通知(OBT_INHIBIT_MOVE)が移動先エントリから削除されます。

停止および孤立した破損通知の影響

破損通知を含むオブジェクトは、エージェントのアウトバウンド同期の実行時、およびインバウンド同期サイクルの最後に実行されるようにスケジュールされている破損通知処理の実行時に調査の対象となります。

予防策

定期的にiMonitorサーバ情報レポートを実行してください。このレポートは、ツリー全体を調べて、検索可能な各NCPサーバと通信し、検知したすべてのエラーをレポートします。このレポートを使用して、時刻同期およびリンバの問題を診断できます。また、現在のサーバ自体が他のすべてのサーバと通信可能であると認識しているかどうかも知ることができます。環境設定ページで選択されている場合、このサーバはツリー内にある各サーバのNDSエージェントヘルス情報を生成することもできます。サーバ情報レポートの実行の詳細については、[レポートの環境設定]を参照してください。

iMonitor 2.0以降のバージョンを使用する場合は、[Errors and Health sub-report]のレポートオプションが有効になっていることを確認してください。レポートでは次の項目が確認されます。レポートを参照し、エラーがないことを確認してください。

iMonitor 1.5を使用する場合はエラーレポートオプションを選択します。レポートでは次の項目が確認されます。レポートを参照し、エラーがないことを確認してください。

iMonitor破損通知リスティングレポートまたはiMonitorオブジェクト統計情報レポートを使用して、システムにある破損通知を検索できます。処理が実行されていないと思われる破損通知を見つけた場合は、「トラブルシューティングのヒント」を参照してください。

トラブルシューティングのヒント

破損通知が処理されない一般的な理由が2つあります。1つは、破損通知が孤立している場合(破損通知がすべてのサーバではなく一部のサーバにのみ存在する場合)、もう1つは、破損通知が停止している場合(破損通知がすべてのサーバに存在するが、ステータスが何らかの理由で進まない場合)です。

次の項目を使用して、孤立または停止した破損通知の問題を解決してください。

解決方法

トラブルシューティングのヒント」を参照して、適切な解決方法を使用してください。

これらの解決方法を使用する前に、データが安全であることを確認してください。ディレクトリデータベースファイル、サーバ環境設定、およびトラスティのバックアップが必要となる場合があります。成功率を高め、今後生じる問題を最小限に抑えるためには、最新のeDirectoryサポートパックにアップグレードしてください。

孤立した破損通知の解決

外部参照の孤立した破損通知の解決

OBT_INHIBIT_MOVE破損通知の解決

以前の操作

過去には、停止した破損通知をクリーンアップするためにいくつかの異なる手段をとりました。これらの手段の一部は、費用のかかるパーティション操作、または将来的に問題の原因となる可能性のあるドキュメント化されていない機能の使用に関連しています。次に挙げる手段の多くは、使用をお勧めしていません。

1つ目に使用されていたのは、マスタを保持しているレプリカを切り替える方法です。マスタはさまざまなステータスを通じてバックリンクの破損通知の移動を担当しているエージェントなので、この手段が有効な場合もあります。レプリカに矛盾がありマスタが削除されたオブジェクトを保持していない場合、該当するマスタを、破損通知と一緒に削除されたエントリを保持していたエージェントに切り替えると、新規エージェントに破損通知のステータスを次に進めてパージすることのできるライセンスが与えられます。[Send Single Entry]を選択すると、より確実で危険性の低い方法で、レプリカの矛盾が原因で停止している破損通知の問題を解決します。

2つ目はすべての破損通知を削除するスイッチを使用してDSRepairを実行する手段です。(DSRepairを起動して、停止している破損通知をクリーンアップするサードパーティ製のアプリケーションがあります)。eDirectoryの開発チームはこの手段をお勧めしていません。これらのスイッチを使用すると、このエージェントにあるすべての破損通知が削除されます。したがって停止していない破損通知も削除される可能性があり、レプリカの矛盾性がさらに深まり、より多くの停止している破損通知が作成される場合があります。これは分散された操作ではないので、停止している破損通知のあるすべてのサーバでDSRepairを実行する必要があります。この操作は、これらのサーバの1つで処理未了のまま削除されてしまうパーティションの破損通知を取得する可能性を高めます。処理未了のまま破損通知を削除すると、孤立した破損通知を新たに生み出す可能性があり、その結果として数年後にレプリカタイプの変更、新規レプリカの追加、またはその他のパーティション操作を実行したときに問題が生じる場合があります。

3つ目は、カスタムモード操作でDSBrowseを使用してエントリにタイムスタンプを設定するか、またはDSRepairで-0Tスイッチを使用して、オブジェクトを信頼されたオブジェクトに指定する手段です。この操作によりエントリは信頼されたエントリに指定され、他のすべてのレプリカにこのエントリを同期します。タイムスタンプの設定およびオブジェクトを信頼されたオブジェクトに指定すると、他のサーバで変更されたデータが消失する可能性があるので注意が必要です。eDirectory開発チームでは、破損通知のクリーンアップにはできるかぎりこの方法を使用しないことをお勧めします。

NetIQの商標については、http://www.netiq.com/company/legal/を参照してください。