In seguito alla mancanza di informazioni precise sull'uso dei necrologi in eDirectory, sono state sviluppate pratiche aziendali inadeguate alla gestione di questi attributi. A differenza di alcuni prodotti per la gestione di directory, eDirectory assicura l'integrità dei riferimenti tra gli oggetti. Ad esempio, se Gruppo A accountene un membro (Utente B) e quest'ultimo viene successivamente cancellato, eDirectory rimuove automaticamente il riferimento a Utente B da Gruppo A. I necrologi sono attributi operativi applicati agli oggetti da eDirectory per garantire l'integrità dei riferimenti durante le operazioni di cancellazione, spostamento, ridenominazione, ripristino e così via.
Vi sono tre classificazioni generali per i necrologi: primari, secondari e di controllo. I necrologi primari comprendono i necrologi di tipo Cessato (0001), Ripristinato (0000), Spostato (0002), Nuovo RDN (0005) e Nuovo RDN albero (0008). I necrologi secondari sono in genere associati a un necrologio primario e rappresentano gli agenti e le partizioni a cui deve essere notificata l'operazione specificata nel necrologio primario. I necrologi secondari comprendono i tipi Back Link (0006), Usato da (000C) e Sposta l'albero (000a). I necrologi di controllo comprendono Impedisci spostamento (0003), RDN precedente (0004) e RDN precedente albero (0007).
I necrologi, ad eccezione di quelli di controllo, devono passare attraverso una serie di stati di sincronizzazione:
Gli stati sono registrati nel campo Flag nell'attributo del necrologio. Affinché un necrologio possa passare allo stato successivo, è necessario che lo stato attuale sia stato sincronizzato in tutte le repliche dell'oggetto reale. Per stabilire se tutte le repliche nell'anello si trovano in un determinato stato del necrologio, viene calcolato un vettore a partire dal vettore transitivo. In eDirectory 8.6 e versioni successive viene utilizzato un vettore dei necrologi non memorizzato. Nelle versioni precedenti, invece, veniva utilizzato il vettore di eliminazione. Se l'orario di modifica (MTS, Modification Timestamp) sul necrologio è antecedente a quello del vettore danneggiato, il server responsabile di tale necrologio può farlo passare allo stato successivo.
Per i necrologi secondari di tipo Back Link, il responsabile dell'avanzamento degli stati è l'agente contenente la replica master dell'oggetto con il necrologio. Per i necrologi secondari di tipo Usato da, il responsabile dell'avanzamento degli stati del necrologio è l'agente di replica che ha creato il necrologio, a condizione che tale replica esista. Se la replica non esiste, il responsabile è l'agente contenente il master della partizione. Per i necrologi di tipo Sposta l'albero, il responsabile dell'avanzamento degli stati è il master della partizione radice.
I necrologi primari possono essere passati allo stato successivo solo dopo che tutti i necrologi secondari hanno superato tutti gli stati disponibili. Una volta che il necrologio primario ha raggiunto l'ultimo stato e che quest'ultimo è stato sincronizzato in tutti i server dell'anello, rimane soltanto l'involucro dell'oggetto, ovvero un oggetto senza attributi che può essere successivamente eliminato definitivamente dal sistema. I necrologi di controllo vengono rimossi nel momento in cui è possibile rimuovere il necrologio primario oppure, nel caso di INHIBIT_MOVE, dopo che il necrologio primario è passato allo stato OBF_NOTIFIED sulla replica master.
La replica responsabile dell'elaborazione dei necrologi utilizza un processo in background (processo di necrologia), che viene pianificato per ogni singola partizione dopo che una determinata partizione ha terminato un ciclo di sincronizzazione in entrata. Se non esistono altre repliche della partizione, il processo di replica in uscita viene comunque pianificato in base all'intervallo di hearbeat. Il processo di replica in uscita avvia quindi il processo di necrologia. Non è possibile, né necessario, pianificare manualmente il processo di necrologia. Quando si verifica una sincronizzazione, i vettori transitivi vengono aggiornati, con conseguente avanzamento del vettore di eliminazione e di quello dei necrologi. Man mano che questi vettori si spostano in avanti, gli stati dei necrologi possono avanzare. Questa operazione, unitamente alla pianificazione automatica eseguita sulla sincronizzazione in entrata, completa il ciclo di elaborazione dei necrologi. Pertanto, l'obiettivo del processo di necrologia è la sincronizzazione degli oggetti.
Quando un oggetto viene rimosso, dopo che tutti i necrologi cui è associato un necrologio primario di tipo Cessato hanno raggiunto l'ultimo stato (Eliminazione consentita) e quest'ultimo è stato sincronizzato in tutte le repliche, un nuovo processo si occupa della rimozione del relativo involucro dal database. Per la rimozione di questi involucri, viene eseguito automaticamente il processo di eliminazione definitiva. È possibile pianificare manualmente il processo di eliminazione definitiva e modificarne il relativo intervallo di pianificazione automatica utilizzando
la pagina Configurazione dell'agente di iMonitor.In questa sezione sono riportati i seguenti esempi:
Se il necrologio è di tipo primario, senza necrologi secondari, e l'orario di modifica (MTS) dell'attributo sul necrologio è precedente a quello del vettore di eliminazione, tutti i server avranno già rilevato la modifica apportata e il necrologio verrà rimosso.
Se il necrologio è di tipo Back Link e questo è il server master, sarà questo l'agente responsabile dell'elaborazione del necrologio.
Eseguire l'operazione richiesta per questo stato, se non è stato già fatto. Nella maggior parte dei casi, è sufficiente notificare un riferimento esterno.
Se il necrologio è di tipo Usato da e questo è il server in cui è stata eseguita l'eliminazione (confrontando il numero della replica nell'MTS del necrologio e il numero della replica attuale), sarà questo il server responsabile dell'elaborazione del necrologio.
L'operazione di spostamento è simile a quella di cancellazione, con le seguenti differenze:
Gli oggetti con necrologi vengono considerati ogni volta che un agente esegue una sincronizzazione in uscita e durante il processo di necrologia di cui è pianificata l'esecuzione al termine di un ciclo di sincronizzazione in entrata.
A intervalli regolari, eseguire il rapporto informativo sul server di iMonitor. Durante questo processo, viene eseguita la scansione dell'intero albero, comunicando con tutti i server NCP rilevati, e vengono segnalati gli errori riscontrati. È possibile utilizzare questo rapporto per diagnosticare problemi relativi alla sincronizzazione dell'orario e al limber oppure per determinare se il server attuale è in grado di comunicare con tutti gli altri server dalla prospettiva di questo server. Se selezionato nella pagina di configurazione, questo server può generare anche informazioni sullo stato dell'agente NDS per ogni server dell'albero. Per ulteriori informazioni sull'esecuzione del rapporto informativo sul server, vedere la sezione Configurazione rapporto.
Se si utilizza iMonitor 2.0 o versione successiva, accertarsi che siano abilitate le seguenti opzioni di rapporto: Errori e Rapporto secondario sullo stato. Verranno verificati gli elementi riportati di seguito. Si consiglia di esaminare il rapporto e verificare che non siano presenti errori.
Se si utilizza iMonitor 1.5, selezionare l'opzione di rapporto Errori. Verranno verificati gli elementi riportati di seguito. Si consiglia di esaminare il rapporto e verificare che non siano presenti errori.
Se si utilizza il rapporto Elenco necrologi o Statistiche dell'oggetto di iMonitor, è possibile cercare qualsiasi necrologio nel proprio sistema. Se si rilevano necrologi che si ritiene non siano stati elaborati, consultare la sezione Suggerimenti per la soluzione dei problemi.
I motivi per cui i necrologi non vengono elaborati sono in genere due: il necrologio è stato reso orfano, ossia esiste in alcuni server ma non in tutti, oppure è bloccato, ossia esiste in tutti i server ma, per qualche motivo, non avanza di stato.
Utilizzare i seguenti elementi per risolvere il problema dei necrologi orfani o bloccati:
Problemi di comunicazione –625, -622, -634 e -635. Vedere la sezione Rapporto informativo sul server per ulteriori informazioni.
Problemi –601 e -603, che indicano che i server sono stati rimossi in modo errato oppure che l'oggetto Server potrebbe disporre di una classe di base sconosciuta.
Utilizzare la soluzione appropriata tra quelle descritte nella sezione Suggerimenti per la risoluzione dei problemi.
Prima di utilizzare una di queste soluzioni, è necessario accertarsi che i propri dati siano sicuri. È possibile che sia necessario eseguire il backup dei file del database di directory, della configurazione del server e dei trustee. Per aumentare la probabilità di riuscita e ridurre al minimo la possibilità di problemi futuri, eseguire l'upgrade ai Support Pack più aggiornati di eDirectory.
Risoluzione dei necrologi orfani
- Metodo preferito: se su uno qualsiasi dei server dell'anello di replica è in esecuzione eDirectory 8.6 o versione successiva, individuare l'oggetto in iMonitor e selezionare l'invio di una singola voce. Verrà eseguito un invio senza autorità a tutte le altre repliche.
- Metodo non consigliato: abilitare la modalità avanzata in iMonitor, individuare l'oggetto e selezionare Opzioni avanzate, quindi Immissione della registrazione dell'orario. In questo modo, l'oggetto presente su questo server diventerà la copia con autorità. Generalmente, non è consigliato attribuire autorità agli oggetti.
- Metodo altamente sconsigliato: se su tutti i server dell'anello di replica che dispongono di una copia del necrologio orfano è in esecuzione una versione di eDirectory precedente alla 8.6, effettuare l'upload di DSBrowse con l'opzione -a, individuare l'oggetto, quindi selezionare Resend Selected Object (Invia di nuovo oggetto selezionato) per registrare l'orario della voce. In questo modo, l'oggetto presente su questo server diventerà la copia con autorità. Generalmente, non è consigliato attribuire autorità agli oggetti.
Risoluzione dei necrologi orfani sui riferimenti esterni
- Metodo preferito: eseguire la versione DSRepair più attuale con l'opzione -XK3 selezionata. In ogni caso, verificare innanzitutto che tutte le operazioni eseguite da -XK3 siano accettabili.
- Metodo sconsigliato: spostare una replica reale sul server, attenderne l'attivazione, quindi attendere l'elaborazione del necrologio. Se il necrologio non viene elaborato, utilizzare le informazioni contenute nella sezione Suggerimenti per la soluzione dei problemi per risolvere il problema ora che l'oggetto si trova su una replica reale. Se lo si desidera, è possibile rimuovere la replica dopo l'elaborazione del necrologio.
Risoluzione dei necrologi OBT_INHIBIT_MOVE
- Metodo preferito: se l'oggetto di destinazione è completo, verificare che l'oggetto di origine sia ancora presente. Se tale oggetto esiste e contiene ancora l'attributo OBT_MOVED, cercare di risolvere il problema che ha impedito il completamento di OBT_MOVED. Se l'oggetto di origine non esiste, utilizzare le opzioni della modalità avanzata di iMonitor per eliminare l'attributo OBT_MOVE_INHIBIT sulla replica master dell'oggetto di destinazione. Se l'oggetto di destinazione è incompleto, eliminare l'attributo OBT_MOVE_INHIBIT e quindi rimuovere l'oggetto di destinazione.
In passato, sono state sviluppate diverse strategie per eseguire la pulizia dei necrologi bloccati. Alcune di queste strategie richiedono costose operazioni di partizionamento o l'uso di funzioni non documentate che possono causare problemi anche in futuro. Molte delle strategie riportate di seguito non devono essere adottate.
La prima strategia consiste nell'assegnare la replica master a un altro agente. Questa strategia funziona solo in alcuni casi poiché l'agente della replica master è responsabile dell'avanzamento dei necrologi di tipo Back Link. Se la replica non è coerente e la replica master non contiene l'oggetto eliminato, il passaggio delle repliche master a un agente che contiene la voce eliminata con i relativi necrologi, consentirebbe a tale agente di far avanzare i necrologi e infine di eliminarli definitivamente. L'invio di una singola voce rappresenta un metodo molto più corretto e meno rischioso di risolvere i problemi di necrologi bloccati a causa di una replica incoerente.
La seconda strategia consiste nell'eseguire DSRepair con determinati commutatori per cancellare tutti i necrologi. Esiste infatti un'applicazione di terze parti che esegue la pulizia dei necrologi bloccati mediante l'avvio di DSRepair. Questa strategia è sconsigliata dal team di sviluppo di eDirectory. L'uso di questi commutatori comporta la cancellazione di tutti i necrologi su questo agente, con conseguente rimozione anche dei necrologi non bloccati, nonché la creazione di ulteriori necrologi bloccati e incoerenze tra le repliche. Inoltre, poiché questa operazione non viene effettuata in maniera distribuita, è necessario eseguire DSRepair su tutti i server che presentano necrologi bloccati, aumentando così il rischio che vengano prematuramente cancellati i necrologi relativi a un'altra partizione presenti su uno di questi server. La cancellazione prematura dei necrologi può generare ulteriori necrologi orfani e quindi causare problemi anche dopo molto tempo, quando si modificheranno i tipi di replica, si aggiungeranno nuove repliche o si eseguiranno altre operazioni di partizionamento.
La terza strategia utilizzata consiste nell'attribuire autorità agli oggetti utilizzando DSBrowse in modalità avanzata e registrando l'orario della voce oppure eseguendo DSRepair con il commutatore –0T. In questo modo, la voce a cui è attribuita l'autorità viene sincronizzata con tutte le altre repliche. È necessario prestare molta attenzione quando si effettua la registrazione dell'orario e si attribuisce autorità agli oggetti poiché si rischia di perdere i dati modificati sugli altri server. Il team di sviluppo di eDirectory consiglia di non utilizzare spesso questo metodo di pulizia dei necrologi.
Per informazioni sui marchi di fabbrica di NetIQ, vedere http://www.netiq.com/company/legal/.