Risoluzione dei problemi relativi alla replica delle cartelle pubbliche – Parte 2: Risoluzione dei problemi relativi alla replica di dati esistenti
Articolo originale pubblicato lunedì 28 novembre 2011
Post originale su US blog: 20 gennaio 2006
Questo è il secondo post di blog sulla risoluzione dei problemi relativi alla replica delle cartelle pubbliche. Il primo post era dedicato alla risoluzione dei problemi relativi alla replica delle nuove modifiche. Questo post di blog è dedicato alla risoluzione dei problemi relativi alla replica di dati esistenti, mentre l'ultimo tratterà della risoluzione dei problemi comuni e di quelli relativi all'eliminazione di una replica. Per un quadro completo, leggete tutto il materiale di riferimento.
Risoluzione dei problemi relativi alla replica di dati esistenti
Quando si replicano le nuove modifiche, ma non gli elementi precedenti non modificati, si ha un problema di recupero. La situazione più tipica in cui si verifica il recupero della gerarchia è la creazione di un nuovo archivio pubblico. Lo scenario più tipico di recupero di contenuto è l'aggiunta di un archivio pubblico all'elenco di repliche di una cartella.
Nel caso di un problema di recupero analogo, è possibile aggirare l'ostacolo facilmente apportando una modifica a tutti gli elementi. In questo modo si evita il processo di recupero interrotto e si esegue la replica di tutti gli elementi come nuove modifiche. Nonostante abbia scritto entrambi gli strumenti generalmente utilizzati a questo scopo (PFDAVAdmin e ModifyItems), è di solito consigliabile risolvere il problema del processo di recupero e correggere la causa radice. Se si modificano tutti gli elementi per consentire la replica, lo stesso problema di recupero potrebbe ripresentarsi in futuro quando le repliche non sono nuovamente sincronizzate. Per comprendere il processo di recupero, è innanzitutto necessario comprendere in che modo si tiene traccia delle modifiche.
A ogni cartella e a ogni messaggio nell'archivio viene assegnato un numero revisione al momento della creazione e a ogni modifica. Quando si esegue la replica, i numeri revisione di ogni oggetto vengono utilizzati per determinare se l'oggetto richiede la replica. Un gruppo di numeri revisione è detto CNSet. I CNSet delle cartelle specifiche in un determinato server sono anche detti informazioni sullo stato. Queste informazioni sono incluse in ogni messaggio di replica. Ogni messaggio di tipo 0x2 contiene lo stato della gerarchia per il server di invio. In modo analogo, ogni messaggio di tipo 0x4 contiene le informazioni sullo stato per tale cartella specifica per il server di invio. Tutti gli altri tipi di messaggi di replica contengono informazioni sullo stato per le rispettive cartelle.
Al primo montaggio di un archivio pubblico, viene inviata una richiesta di stato (tipo 0x20) per la gerarchia a tutti gli archivi pubblici esistenti. In modo analogo, quando si aggiunge un nuovo archivio all'elenco di replica di una cartella, da tale archivio verrà inviato un messaggio 0x20 a tutte le altre repliche di tale cartella. Come ogni messaggio di replica, una richiesta di stato contiene un CNSet di tutti i numeri revisione per la cartella in questione (o la gerarchia) contenuti nell'archivio di origine e permette di chiedere agli altri archivi se dispongono di numeri revisione che non sono presenti nell'origine. Nelle versioni precedenti a Exchange 2003 SP2, non viene chiesto a ogni replica di rispondere alla richiesta di stato, pertanto in alcuni archivi la richiesta di stato verrebbe ignorata anche se sono presenti modifiche non contenute nell'origine. In un server 2003 SP2 verranno richieste risposte da tutte le repliche e inviate risposte anche quando non vengono specificamente richieste dal server di origine, purché siano presenti modifiche non contenute in quest'ultimo. Questa condizione migliora notevolmente le decisioni prese durante il processo di recupero. La caratteristica unica di una richiesta di stato è che non contiene dati da replicare, ma solo un elenco di numeri revisione. Gli altri archivi rispondono con messaggi di stato (0x10), in cui sono elencati i CNSet per tale cartella (o gerarchia). Quando il server di origine riceve i messaggi 0x10, confronta il CNSet che contengono con il proprio. Se il messaggio 0x10 contiene modifiche che non sono già presenti nell'archivio, viene avviato il processo di recupero.
Il primo passaggio del processo di recupero consiste nell'aggiunta di voci alla matrice di recupero per la cartella in questione. In queste voci è presente un CNSet che descrive le modifiche mancanti e un valore di timeout che indica quando verranno richiesti i dati mancanti dall'archivio. Il timeout di recupero varia a seconda della situazione. Nel caso di un archivio pubblico portato online o di una nuova replica di una cartella aggiunta, il timeout iniziale è di 15 minuti.
È possibile aggiungere voci di recupero alla matrice di recupero anche nel corso del normale funzionamento. Considerate una situazione in cui siano state trasmesse due modifiche in due messaggi 0x2 separati da un determinato archivio pubblico. L'amministratore elimina il primo messaggio 0x2 dalla coda, ma il secondo viene inviato. Quando gli altri server ricevono questo messaggio 0x2, viene rilevato che il CNSet nelle informazioni sullo stato contiene CN non presenti nei server. Di conseguenza, vengono create voci di recupero per tali dati. Il timeout iniziale delle voci di recupero per i dati mancanti rilevati durante il normale corso della replica è di 6 ore se i dati sono disponibili nello stesso gruppo di routing o di 12 se sono disponibili solo in un altro gruppo di routing. Ogni volta che viene generata una richiesta di recupero, il timeout successivo sarà di 12 e 24 ore per le richieste nello stesso gruppo di routing o di 24 e 48 ore per le richieste in diversi gruppi di routing.
Ogni cinque minuti nell'archivio viene effettuato un controllo per verificare se le voci di recupero hanno raggiunto il timeout. In caso positivo, viene generata una richiesta di recupero (tipo 0x8) per i CN mancanti e il timeout viene impostato sull'intervallo successivo. Una richiesta di recupero non è una trasmissione, ma è diretta a un solo server, uno dei server per cui in precedenza erano stati segnalati numeri revisione mancanti nelle informazioni sullo stato inviate al server richiedente. Quando il messaggio 0x8 in ingresso viene ricevuto dal server, viene immediatamente elaborata la richiesta e vengono inviate una o più risposte di recupero (0x80000002 per la gerarchia o 0x80000004 per il contenuto) che contengono i dati effettivi per i numeri revisione mancanti. Come le richieste di recupero, le risposte di recupero non sono trasmissioni, ma vengono inviate solo al server richiedente.
Se la risposta di recupero in ingresso viene elaborata correttamente nel server richiedente, i numeri revisione che contiene vengono cancellati dalla matrice di recupero in tale archivio. In realtà, qualsiasi messaggio in ingresso che contiene numeri revisione in sospeso nella matrice di recupero causerà la cancellazione di tali numeri revisione dalla matrice.
Risoluzione dei problemi
Di seguito vengono riportate alcune risposte alle molte domande inerenti la risoluzione dei problemi relativi al processo di recupero.
1. L'archivio è in grado di rilevare la mancanza di dati?
Innanzitutto, è necessario determinare se il server è in grado di rilevare che in altri archivi sono presenti modifiche da richiedere. Purtroppo, non sono attualmente disponibili strumenti o utilità supportate che consentano di visualizzare direttamente la matrice di recupero per verificarne il contenuto. Tuttavia è possibile ottenere indirettamente tale risultato in vari modi.
Un metodo consiste nell'attendere. Se il server rileva la mancanza di dati, li richiede almeno una volta ogni 24 o 48 ore. È pertanto sufficiente attivare la registrazione e verificare se viene generato un messaggio 0x8. Se non viene mai generato un messaggio 0x8 per la cartella in questione, ma tali messaggi sono presenti per altre cartelle è possibile che sia stato raggiunto il limite di recupero informazioni in sospeso, che verrà presentato più avanti.
Un'altra opzione consiste nel verificare che il server riceva le informazioni sullo stato più aggiornate. È importante ricordare che la richiesta di stato viene inviata dal server solo una volta, dopo l'aggiunta della nuova replica. Successivamente riceve le informazioni sullo stato unicamente nel normale corso della replica. Se pertanto il tentativo iniziale di ottenere lo stato viene perso perché il messaggio 0x20 o 0x10 di risposta è stato perso o eliminato, la mancanza di dati potrebbe non essere rilevata. Sono disponibili diversi modi per verificare che il server abbia ricevuto le informazioni sullo stato per una cartella.
- Accedere a un server che contiene tutti i dati e apportare una modifica alla cartella aggiungendo, eliminando o modificando un messaggio. Nel caso della gerarchia, creare, eliminare o modificare le proprietà di una cartella. I messaggi 0x4 o 0x2 risultanti conterranno informazioni sullo stato per tale cartella o gerarchia, rispettivamente. Quando il messaggio di replica in ingresso viene elaborato dal server in cui mancano i dati, si saprà che eventuali voci appropriate sono state aggiunte alla matrice di recupero informazioni.
- Utilizzare l'opzione Sincronizza contenuto di Exchange 2003 ESM. Si tratta di un'opzione poco nota, ma molto utile. Per trovarla, accedere all'albero Cartelle pubbliche e andare alla cartella in questione. Evidenziare la cartella nel riquadro sinistro. Nel riquadro destro fare clic sulla scheda Stato. Fare clic con il pulsante destro del mouse sul server che contiene tutti i dati e scegliere Sincronizza contenuto. Si ottengono due risultati: il server genera una richiesta di stato 0x20 per la cartella e viene attivato il timeout immediato per qualsiasi voce di recupero informazioni. Si tenga presente che occorre utilizzare Sincronizza contenuto dal server che già contiene i dati, nonostante sia l'altro server a contenere voci di recupero informazioni di cui attivare il timeout. Ciò è dovuto al fatto che si intende verificare che il server in cui mancano i dati sia a conoscenza della necessità di recuperare informazioni. A tal fine, è possibile utilizzare Sincronizza contenuto dal server in cui sono presenti i dati per inviare un messaggio 0x20 al server in cui i dati sono mancanti. In questo caso, non vi è interesse nella risposta 0x10 sullo stato al messaggio 0x20, ma solo che l'archivio in cui manca il contenuto riceva un messaggio di replica per la cartella da un archivio con il contenuto, per consentire l'aggiunta delle voci appropriate alla matrice di recupero informazioni. Tramite il messaggio 0x20 dal server con i dati è possibile raggiungere il risultato. In Exchange 2003 SP2 l'opzione Sincronizza contenuto è ora disponibile per la gerarchia facendo clic con il pulsante destro del mouse sul nodo Cartelle pubbliche.
- Utilizzare il valore del Registro di sistema dei flag di replica (KB813629). L'inserimento di questo valore, unitamente al valore Abilitazione messaggi di replica delle cartelle pubbliche all'avvio da KB321082, causerà l'invio di una richiesta di stato 0x20 dall'archivio per ogni cartella all'avvio. Anche in questo caso occorre utilizzare il valore nel server che dispone del contenuto, poiché l'obiettivo consiste nell'ottenere l'invio delle informazioni sullo stato del server che dispone del contenuto al server in cui il contenuto è mancante.
- Utilizzare 2003 ESM per inviare una risposta di recupero informazioni. In 2003 SP1 è possibile utilizzare l'opzione relativa all'invio della gerarchia per inviare una risposta di recupero informazioni sulla gerarchia e l'opzione relativa all'invio di contenuti per inviare la risposta di recupero informazioni sul contenuto di una cartella. In 2003 SP2 entrambe le opzioni servono a reinviare le modifiche. In questo modo viene inviata una risposta di recupero informazioni per l'intervallo di dati specificato, ma è probabilmente preferibile non specificare l'intero intervallo di dati poiché in tal modo verrebbero soddisfatte tutte le voci di recupero informazioni in sospeso con il conseguente aggiramento del problema originale. È invece opportuno specificare un intervallo di un giorno o due. In questo modo verrà inviato un messaggio 0x80000002 o 0x80000004 al server di destinazione, che ha anche in questo caso lo scopo di fornire informazioni sullo stato per l'archivio che contiene i dati.
Una volta utilizzata una di queste opzioni per forzare le informazioni sullo stato e dopo avere verificato nel registro applicazioni che l'archivio in cui mancano i dati ha ricevuto il messaggio in ingresso, si ha la certezza che la mancanza di dati è nota.
2. L'archivio richiede i dati mancanti?
Dopo avere verificato che la necessità di recuperare informazioni per alcuni dati è nota all'archivio, viene generata una richiesta di recupero informazioni? È importante ricordare che dopo un paio di tentativi di recuperare informazioni, potrebbe essere necessario attendere 24 o 48 ore per la successiva richiesta di recupero informazioni, poiché tale sarà l'intervallo di timeout più lungo per i recuperi informazioni all'interno e all'esterne del sito, rispettivamente. È possibile velocizzare questa operazione utilizzando nuovamente Sincronizza contenuto, questa volta dal server in cui mancano i dati. In questo modo verrà immediatamente attivato il timeout delle voci di recupero informazioni per tale cartella. possibile, tuttavia, che l'archivio non generi ancora una richiesta di recupero informazioni per la cartella in questione. In tal caso, consultare il registro applicazioni per le successive 24 - 48 ore. Se vengono inviate richieste di recupero informazioni dall'archivio per altre cartelle, ma non per la cartella in questione, è possibile che sia stato raggiunto il limite di recupero informazioni in sospeso.
Quando si aggiungono repliche di un numero elevato di cartelle in un nuovo archivio e l'operazione sembra procedere correttamente, ma si interrompe uno o due giorni dopo, è stato probabilmente raggiunto il limite di recupero informazioni in sospeso. Tale limite è un meccanismo di limitazione della replica. Per impostazione predefinita, nell'archivio sono consentite al massimo 50 richieste di recupero informazioni in sospeso contemporaneamente. Quando viene raggiunto il limite di 50 richieste in sospeso, esse vengono di nuovo richieste finché non vengono soddisfatte. Una volta soddisfatta una voce in sospeso, viene liberato uno spazio in OBL per il nuovo set di dati da richiedere. Pertanto, se per un qualsiasi motivo non vengono soddisfatte 50 richieste, la replica non può continuare.
Se si verifica questo comportamento, consultare il registro applicazioni per verificare le richieste dell'archivio. Saranno presenti messaggi 0x8 periodici per le 50 richieste correnti di recupero informazioni in sospeso, ma non saranno state ricevute risposte di recupero informazioni, motivo per cui le richieste sono ancora in sospeso. A questo punto, è necessario risolvere i problemi di una delle cartelle da cui l'archivio sta attualmente tentando di recuperare informazioni, poiché la risoluzione del problema consentirà di passare ad altre cartelle.
Un'altra opzione disponibile consiste nell'aumentare il limite di recupero informazioni in sospeso (OBL, Oustanding Backfill Limit). È possibile creare un valore del Registro di sistema denominato Limite recupero informazioni in sospeso replica sotto la chiave del Registro di sistema per l'archivio in questione. Il valore massimo è di 5000 decimali. In questo caso, tuttavia, sarà difficile determinare quali 50 cartelle hanno causato l'arresto della replica. Sarà necessario posticipare la risoluzione dei problemi finché la situazione non torna alla normalità. È in genere consigliabile lasciare il limite impostato su 50 e correggere il problema, anziché aggirare l'ostacolo aumentando il limite.
Se il limite non costituisce un problema e vengono ancora visualizzati messaggi 0x8 per la cartella in questione, vedere la sezione relativa ai problemi comuni nell'ultimo post di questa serie.
3. L'altro archivio risponde alla richiesta?
Se è presente una richiesta di recupero informazioni di cui occuparsi, è necessario determinare se la destinazione del recupero informazioni ha ricevuto tale richiesta. Verificare se nel registro applicazioni sul server è presente il messaggio 0x8 in ingresso. È inoltre possibile cercare nel registro applicazioni l'ID messaggio riportato nell'evento in uscita dal lato mittente. Se non è presente nel registro applicazioni, utilizzare la verifica dei messaggi per controllare il tempo trascorso. Quando viene ricevuto il messaggio 0x8, la risposta deve essere quasi immediata con uno o più messaggi 0x80000002 o 0x80000004 (sono spesso spesso presenti molte risposte di recupero informazioni a una singola richiesta di recupero informazioni, poiché le modifiche non vengono inviate tutte in uno solo messaggio). Ovviamente il tempo impiegato per generare i messaggi di risposta di recupero informazioni varierà in base ai dati presenti nella cartella e al limite massimo delle dimensioni dei messaggi di replica. Ad esempio, se si impostano le dimensioni massime dei messaggi di replica su 1 GB, è possibile che dal server di risposta venga inviata una sola risposta di recupero informazioni con l'intera gerarchia, operazione che potrebbe richiedere anche più di un'ora solo per la creazione del pacchetto.
4. Il server richiedente riceve la risposta?
A questo punto è opportuno controllare nel registro applicazioni del server richiedente se è stata ricevuta la risposta di recupero informazioni. In caso contrario, verificare a che punto si trova il messaggio. Se la risposta di recupero informazioni è stata ricevuta e registrata nel registro applicazioni, la richiesta di recupero informazioni dovrebbe essere stata soddisfatta e dovrebbe essere possibile procedere.
Come indicato in precedenza, se dalla verifica dei messaggi si rileva che un messaggio è stato recapitato all'archivio e tuttavia nel registro applicazioni non è presente il messaggio di replica in ingresso, consultare la sezione relativa ai problemi comuni nell'ultimo post della serie.
Nel post di blog successivo: Risoluzione dei problemi comuni e di quelli relativi all'eliminazione di una replica.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data