ディレクトリに保存される破損通知については非常に複雑なため、ビジネスでうまく利用されていない場合があります。いくつかのディレクトリ製品とは異なり、Novell eDirectoryではオブジェクト間の参照整合性が確保されています。たとえば、グループAにユーザBというメンバが登録されている場合、ユーザBが削除されるとディレクトリでは自動的にグループAからユーザBへの参照が削除されます。破損通知は、eDirectoryによってオペレーショナル属性としてオブジェクトに保存されます。これにより、削除、移動、名前の変更、復元、およびその他の操作中に、二重に参照整合性が確保されます。
破損通知には大きく分類して3つの種類があります。
トラッキング破損通知以外の破損通知は、次の同期ステータスのセットを使用して移動する必要があります。
ステータスは破損通知属性のフラグフィールドで記録されます。破損通知が次のステータスに進む前に、現在のステータスは必ず実オブジェクトのすべてのレプリカに同期されます。リング内のすべてのレプリカが破損通知ステータスを与えられているかどうかを判断するために、遷移ベクトルからベクトルが計算されます。eDirectory 8.6以降では、保存されていない破損通知ベクトルが使用されます。以前のバージョンのeDirectoryでは、パージベクトルが使用されます。破損通知の変更タイムスタンプ(MTS)が破損ベクトルよりも古い場合、担当サーバは該当する破損通知を次のステータスに進めることができます。
「バックリンク」のセカンダリ破損通知の場合、該当する破損通知を含むオブジェクトのマスタレプリカを持つエージェントがステータスを進めます。「使用中」のセカンダリ破損通知の場合、レプリカが存在している間は該当する破損通知を作成したエージェントがステータスを進めます。レプリカが存在しない場合、パーティションのマスタを保持しているエージェントが「使用中」の破損通知のステータスを進めます。「ツリーの移動」の破損通知の場合、ルートパーティションのマスタがステータスを進めます。
プライマリ破損通知は、すべてのセカンダリ破損通知が最後のステータスまで進められた後でのみ、ステータスを進めることができます。プライマリ破損通知が最後のステータスまで進んだ後で、そのステータスがリング内のすべてのサーバに同期されると、残っているのは属性を持たないオブジェクトであるオブジェクトハスクのみとなり、これらはシステムのパージプロセスによってパージされます。トラッキング破損通知は、プライマリ破損通知の削除の準備が完了した後か、Inhibit_moveの場合はプライマリ破損通知がマスタレプリカのOBF_NOTIFIEDステータスに移動された後で削除されます。
破損通知の処理を担当するレプリカは、指定したパーティションがインバウンド同期サイクルを終了した後で、パーティションごとにスケジュールされているバックグラウンド処理(破損通知処理)を実行します。パーティションにその他のレプリカがない場合、アウトバウンドレプリケーション処理がハートビート間隔でスケジュールされたままになります。その後、アウトバウンドレプリケーション処理によって破損通知処理が開始されます。破損通知処理は手動ではスケジュールできず、また、その必要もありません。同期化が実行されると、遷移ベクトルが更新され、パージベクトルおよびObitベクトルを進めます。これらのベクトルが進められると、破損通知のステータスを進めることができます。これと同時に、インバウンド同期に自動スケジューリングが実行されると、破損通知処理サイクルが完了します。すなわち、破損通知処理の起動要因はオブジェクト同期です。
削除されたオブジェクトの場合、「停止」のプライマリ破損通知に関連するすべての破損通知が最後のステータス(パージ可能)まで進められ、そのステータスがすべてのレプリカに同期された後で、新しい処理がデータベースに残っているエントリハスクの削除を担当します。これらのハスクを削除するために、パージ処理が自動的に実行されます。パージ処理のスケジュールおよび自動スケジュール間隔の調整は、iMonitorのエージェント環境設定ページを使用して手動で設定することができます。
このセクションでは、次の例を紹介します。
プライマリ破損通知OBT_DEADを追加します。
バックリンクの属性には、このオブジェクトに関連し、このエントリに対する変更を通知する必要のあるサーバのリストが含まれています。バックリンクの属性のリストに含まれる各DNおよびエントリのパーティションレプリカ属性のリストに含まれるすべてのサーバに対して、eDirectoryはバックリンク破損通知を追加します。プライマリ破損通知(OBT_DEAD)の作成時刻は、セカンダリ破損通知に保存されます。
使用中の属性には、このオブジェクトに関連し、このエントリに対する変更を通知する必要のあるパーティションのリストが含まれています。使用中の属性のリストに含まれているすべてのDNに対して、eDirectoryは使用中の破損通知を追加します。プライマリ破損通知(OBT_DEAD)の作成時刻は、セカンダリ破損通知に保存されます。
破損通知以外のすべての属性を削除します。
次に、アウトバウンドレプリケーションプロセスによって、レプリカリング内にある他のすべてのサーバに変更が同期されます。
このパーティションの次回のインバウンド同期が実行されるときに、破損通知処理が開始され、次の処理が実行されます。
該当する破損通知がプライマリ破損通知で、セカンダリ破損通知がなく、破損通知の属性変更タイムスタンプ(MTS)がパージベクトルよりも古い場合、すべてのサーバが変更を確認済みとしてこの破損通知は削除されます。
該当する破損通知がバックリンク破損通知で、このサーバがマスタの場合、このサーバが破損通知の処理を担当します。
重要: ステータスが完了していない場合、このステータスに必要な操作を実行します。これは外部参照を通知するときに最も頻繁に実行されます。
該当する破損通知が使用中の破損通知で、(破損通知のMTSのレプリカ番号とローカルのレプリカ番号の比較から判断して)このサーバで削除が発生している場合、このサーバがこの破損通知の処理を担当します。
移動は削除と非常によく似ていますが、次に挙げる操作が違います。
破損通知を含むオブジェクトは、エージェントのアウトバウンド同期の実行時、およびインバウンド同期サイクルの最後に実行されるようにスケジュールされている破損通知処理の実行時に調査の対象となります。
定期的にiMonitorサーバ情報レポートを実行してください。このレポートは、ツリー全体を調べて、検索可能な各NCPサーバと通信し、検知したすべてのエラーをレポートします。このレポートを使用して、時刻同期およびリンバの問題を診断できます。また、現在のサーバ自体が他のすべてのサーバと通信可能であると認識しているかどうかも知ることができます。環境設定ページで選択されている場合、サーバはツリー内にある各サーバのNDSエージェントヘルス情報を生成することもできます。サーバ情報レポートの実行の詳細については、レポートの設定と表示を参照してください。
iMonitor2.0以降のバージョンを使用する場合は、[Errors and Health sub-report]のレポートオプションが有効になっていることを確認してください。レポートでは次の項目が確認されます。レポートを参照し、エラーがないことを確認してください。
iMonitor1.5を使用する場合はエラーレポートオプションを選択します。レポートでは次の項目が確認されます。レポートを参照し、エラーがないことを確認してください。
iMonitor破損通知リスティングレポートまたはiMonitorオブジェクト統計情報レポートを使用して、システムにある破損通知を検索できます。処理が実行されていないと思われる破損通知を見つけた場合は、トラブルシューティングのヒントを参照してください。
破損通知が処理されない場合、大きく分けて次の2つの原因が考えられます。それは、破損通知が孤立している場合(破損通知がすべてのサーバではなく一部のサーバにのみ存在する場合)、または破損通知が停止している場合(破損通知がすべてのサーバに存在するが、ステータスが何らかの理由で進まない場合)です。
次の項目を参照して、孤立または停止した破損通知の問題を解決してください。
破損通知を含むエントリを参照しながら、エントリ同期リンクをクリックします。すべてのレプリカに同期されていない属性がすべて表示されます。
破損通知属性値の中で、最も古いタイムスタンプを検索します。検索されたタイムスタンプの時刻と現在時刻の差が、［パーティション同期］ページの最大リングデルタフィールドの間隔よりも大きい必要があります。
遷移ベクトルを調査します。
-625、-622、-634、および-635の通信エラー。詳細については、「サーバ情報レポート」を参照してください。
-601および-603は、適切に削除されていないサーバ、またはサーバオブジェクトに不明なベースクラスが含まれるサーバを示します。
トラブルシューティングのヒントを参照して、適切な解決方法を使用してください。
これらの解決方法を使用する前に、データが安全であることを確認してください。ディレクトリデータベースファイル、サーバ環境設定、およびトラスティのバックアップが必要となる場合があります。成功率を高め、今後生じる問題を最小限に抑えるためには、最新のeDirectoryサポートパックにアップグレードしてください。
推奨される方法:レプリカリング内のサーバのいずれかにeDirectory 8.6以降のバージョンを使用する場合、iMonitorのオブジェクトを参照し、［Send Single Entry(単一エントリを送信)］を選択します。これにより、その他のすべてのレプリカに非委任の送信が実行されます。
避けるべき方法: 孤立した破損通知のコピーを持つレプリカリングにあるすべてのサーバがeDirectory 8.6よりも前のバージョンの場合に、DSBrowseを-aオプションでロードして、オブジェクトを参照し、エントリにタイムスタンプを設定します。これにより、このサーバに存在するオブジェクトがそのまま委任されたコピーとなります。Novellでは、実際にはオブジェクトを委任されたものと設定することはお勧めしません。
推奨されない方法:実レプリカをサーバに移動し、使用可能な状態になってから破損通知が処理されるのを待ちます。破損通知が処理されない場合は、トラブルシューティングのヒントにある情報を参照して実レプリカに移動されたオブジェクトの問題を解決してください。破損通知が処理されたら、レプリカは削除してもかまいません。
過去には、停止した破損通知を解決するためにいくつかの異なる手段をとりました。これらの手段の一部は、費用のかかるパーティション操作、または将来的に問題の原因となる可能性のあるドキュメント化されていない機能の使用に関連しています。
1つ目に使用されていたのは、マスタを保持しているレプリカを切り替える方法です。マスタはさまざまなステータスを通じてバックリンクの破損通知の移動を担当しているエージェントなので、この手段が有効な場合もあります。レプリカに矛盾がありマスタが削除されたオブジェクトを保持していない場合、該当するマスタを、破損通知と一緒に削除されたエントリを保持していたエージェントに切り替えると、新規エージェントに破損通知のステータスを次に進めてパージすることのできるライセンスが与えられます。［Send Single Entry(単一エントリを送信)］を選択すると、より確実で危険性の低い方法で、レプリカの矛盾が原因で停止している破損通知の問題を解決します。
2つ目に使用されていたのは、DSRepairを実行してすべての破損通知を削除するスイッチを使用する方法です(DSRepairを起動して、停止している破損通知を解決するサードパーティ製のアプリケーションがあります)。この方法はお勧めできません。これらのスイッチを使用すると、このエージェントにあるすべての破損通知が削除されます。したがって停止していない破損通知も削除される可能性があり、レプリカの矛盾性がさらに深まり、より多くの停止している破損通知が作成される場合があります。これは分散された操作ではないので、停止している破損通知のあるすべてのサーバでDSRepairを実行する必要があります。この操作は、これらのサーバの1つで処理未了のまま削除されてしまうパーティションの破損通知を取得する可能性を高めます。処理未了のまま破損通知を削除すると、孤立した破損通知を新たに生み出す可能性があり、その結果として数年後にレプリカタイプの変更、新規レプリカの追加、またはその他のパーティション操作を実行したときに問題が生じる場合があります。
3つ目に使用されていたのは、カスタムモード操作でDSBrowseを使用してエントリにタイムスタンプを設定するか、またはRSRepairで-0Tスイッチを使用してオブジェクトを委任されたものと設定する方法です。この操作によりエントリは委任されたものと設定され、他のすべてのレプリカにこのエントリを同期します。その他のサーバで変更されたデータを失う可能性があるので、この操作の実行には細心の注意を払う必要があります。破損通知のクリーンアップの方法としては、なるべく使用しないことをお勧めします。