Come risolvere i problemi relativi alla replica continua cluster
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Ultima modifica dell'argomento: 2008-01-14
In questo argomento viene descritta la risoluzione dei problemi relativi alla replica continua cluster (CCR, Cluster Continuous Replication). Per ulteriori informazioni sugli strumenti utili alla risoluzione dei problemi della replica continua cluster, vedere Strumenti per la risoluzione dei problemi con distribuzioni a disponibilità elevata.
Le procedure descritte in questo argomento riguardano i seguenti problemi in un ambiente di replica continua cluster:
Get-StorageGroupCopyStatus segnala che lo stato del database è “Non riuscito” e il seeding non è stato eseguito.
Get-StorageGroupCopyStatus segnala che lo stato del database è “Non riuscito”. Il valore FailedMessage indica che si è verificata una divergenza nella copia del gruppo di archiviazione.
Get-StorageGroupCopyStatus segnala che lo stato del database è “Non riuscito”. Il valore FailedMessage fornisce informazioni specifiche sull'origine dell'errore.
Avvisi, contatori delle prestazioni o Get-StorageGroupCopyStatus indicano che è stato eseguito il backup delle code di copia o di riesecuzione per una copia del gruppo di archiviazione.
Get-StorageGroupCopyStatus segnala un orario non aggiornato per LastInspectedLogTime.
Failover o Move-ClusteredMailboxServer è stato eseguito correttamente, ma i database non sono stati montati.
Il failover è stato eseguito correttamente, ma alcuni database non sono stati montati né automaticamente né manualmente. In alternativa, Get-ClusteredMailboxServerStatus segnala uno o più database con errori.
Un database non viene montato all'avvio in un ambiente di replica continua cluster.
Viene registrato l'evento MSExchangeRepl 2073 con l'indicazione che il servizio di replica di Microsoft Exchange non è stato in grado di trovare una directory.
Move-ClusteredMailboxServer non avvia un'interruzione pianificata a causa di un problema di replica.
La replica non viene sincronizzata nuovamente dopo il failover di uno o più gruppi di archiviazione.
Seeding non riuscito.
Quando si verificano degli errori diversi da quelli elencati qui, esaminare il registro eventi di entrambi i nodi per stabilire la causa e utilizzare le informazioni nei registri per determinare le azioni di ripristino da intraprendere. Quando si identifica l'ora in cui si è verificato l'errore, gli altri registri eventi possono consentire una migliore comprensione del problema. Se le informazioni sono insufficienti, può essere utile conoscere l'ora in cui si è verificato il problema per restringere l'analisi e la dimensione della finestra di verifica in cluster.log. Il registro del cluster fornisce informazioni a livello di traccia per le azioni eseguite dal sistema di gestione del cluster.
Informazioni preliminari
Per eseguire questa procedura, è necessario utilizzare un account che disponga della delega del ruolo Exchange Server Administrator e dell'appartenenza al gruppo Administrators locale del server di destinazione. Per ulteriori informazioni sulle autorizzazioni, sulla delega dei ruoli e sui diritti necessari per l'amministrazione di Microsoft Exchange Server 2007, vedere Considerazioni sulle autorizzazioni.
Procedura
Get-StorageGroupCopyStatus segnala che lo stato del database è "Non riuscito" e che il seeding non è stato eseguito
Cause possibili Un problema di configurazione o la copia della replica non dispone di un database di riferimento valido. Questo problema potrebbe essere stato causato dalla mancata esecuzione del seeding della copia del gruppo di archiviazione quando è stato aggiunto il nodo passivo.
Soluzione
Verificare che l'archiviazione per la copia sia configurata correttamente e che funzioni. Se si individua un errore, è possibile avviare un nuovo controllo della copia sospendendo e riprendendo il gruppo di archiviazione.
Verificare che i percorsi del gruppo di archiviazione e del database siano stati configurati correttamente in relazione all'archiviazione nel server passivo. È possibile eseguire questa operazione utilizzando il cmdlet Get-StorageGroup in Exchange Management Console.
Il cmdlet Update-StorageGroupCopy consente la sospensione della copia del gruppo di archiviazione.
Get-StorageGroupCopyStatus segnala che lo stato del database è "Non riuscito" e il valore FailedMessage indica che si è verificata una divergenza nella copia del gruppo di archiviazione
Cause possibili Si verifica in caso di failover e se è andato perduto un numero sufficiente di registri per cui non è possibile sincronizzare nuovamente il database nel server attivo precedente con il database attivo corrente senza eseguire di nuovo un seeding completo. Questa situazione non può verificarsi nella replica continua locale.
Soluzione Il cmdlet Update-StorageGroupCopy consente di eseguire il seeding della copia del gruppo di archiviazione.
Get-StorageGroupCopyStatus segnala che lo stato del database è "Non riuscito" e il valore FailedMessage fornisce informazioni specifiche sull'origine dell'errore
Cause possibili Le cause potenziali dell'errore in una copia del gruppo di archiviazione sono molte. I due casi precedenti sulla mancata esecuzione del seeding e sulla divergenza ne sono un esempio. Il valore FailedMessage identifica in particolare il problema rilevato.
Soluzione Eseguire il cmdlet Get-StorageGroupCopyStatus per ottenere il valore FailedMessage completo che identifica il problema specifico rilevato. Analizzare le informazioni fornite dal valore FailedMessage e risolvere la condizione segnalata. Se la condizione segnalata è un registro mancante o danneggiato, cercare di individuare un registro non danneggiato con il numero di generazione corretto. Se non è possibile trovare il registro corretto, utilizzare il cmdlet Update-StorageGroupCopy per eseguire di nuovo il seeding. Se nel messaggio viene indicato che i registri di origine non sono disponibili, rimuovere la condivisione nella directory del registro di origine e riavviare il servizio di replica su quel nodo.
Avvisi, contatori delle prestazioni o Get-StorageGroupCopyStatus indicano che è stato eseguito il backup delle code di copia o di riesecuzione per una copia del gruppo di archiviazione
Cause possibili Un backlog della copia o della riesecuzione del registro potrebbe indicare un problema o una situazione temporanea in un processo di ripristino. Una situazione temporanea si verifica quando un nodo passivo precedentemente non in linea viene portato in linea, o quando la copia di un gruppo di archiviazione è stata ripresa di recente dopo essere stata sospesa per un periodo di tempo significativo. L'arresto del servizio di replica di Microsoft Exchange sul nodo passivo ha un effetto simile alla sospensione di tutte le copie del gruppo di archiviazione sul nodo. Se la situazione non è temporanea, il problema potrebbe essere dovuto a una delle seguenti cause:
Problema di configurazione.
Copia di archiviazione sospesa.
Arresto del servizio di riesecuzione.
Archiviazione non riuscita o non in linea.
Nodo passivo non in linea.
Soluzione Determinare se esiste un problema effettivo o una situazione temporanea:
Determinare se il servizio di replica di Microsoft Exchange è in esecuzione su entrambi i nodi. A tale scopo, utilizzare lo snap-in Servizi. Se il servizio è stato arrestato in uno dei nodi, è necessario avviarlo.
Eseguire il cmdlet di Exchange Management Shell Get-StorageGroupCopyStatus con l'opzione fl (formatted list, elenco formattato) e quindi determinare se la copia passiva è stata sospesa. Se è stata sospesa, verificare che i file della copia passiva siano presenti in modo corretto e riprendere la copia del gruppo di archiviazione utilizzando il cmdlet Resume-StorageGroupCopy.
Eseguire il cmdlet Get-StorageGroupCopyStatus con l'opzione fl e determinare se lo stato della copia è "Integro". Se lo stato della copia è “Non riuscito”, esaminare l'elenco dei campi di stato per adottare le misure di correzione necessarie.
Esaminare i contatori delle prestazioni della replica per diversi minuti per determinare se l'avanzamento è in corso. In particolare, esaminare il numero di generazione della riesecuzione e il numero di generazione dell'ispezione. Se la lunghezza della coda di copia continua ad aumentare ma la lunghezza della coda di riesecuzione è breve o in diminuzione, potrebbe essersi verificato un problema nella condivisione file di rete nel server attivo o un problema del server attivo. Utilizzare il comando "net share", Esplora risorse o lo snap-in Gestione computer per verificare che la directory di registro della copia del gruppo di archiviazione attivo disponga di una condivisione file di rete definita. Per determinare il GUID del gruppo di archiviazione, utilizzare il cmdlet Get-StorageGroup con l'opzione fl in Exchange Management Shell.
Get-StorageGroupCopyStatus segnala un orario non aggiornato per LastInspectedLogTime
Cause possibili Questo problema può essere dovuto a tre possibili cause:
Il database della copia del gruppo di archiviazione attivo è smontato.
La copia del gruppo di archiviazione attivo è montata ma non cambia a una velocità significativa. Di conseguenza, i registri non vengono prodotti dalla copia del gruppo di archiviazione attivo.
Il servizio di replica di Microsoft Exchange non è in esecuzione sul nodo passivo.
Soluzione Per determinare quale delle tre è la causa del problema, procedere come segue:
Determinare se il database è smontato utilizzando Exchange Management Console o eseguendo il cmdlet Get-StorageGroupStatus in Exchange Management Shell. Se è smontato, montare il database e apportarvi le necessarie modifiche (ad esempio, l'attività all'interno del database) prima che LastInspectedLogTime cambi.
Verificare che il servizio di replica di Microsoft Exchange non sia in esecuzione sul nodo passivo. Se il servizio è stato arrestato, è necessario avviarlo.
Una volta determinato che il database è montato, verificare se il database sta generando i registri. Esaminare la directory del registro del database attivo e identificare il file di registro con il numero di generazione più alto. Controllare il timestamp del registro: dovrebbe corrispondere al valore LastInspectedLogTime.
Il failover o il cmdlet Move-ClusteredMailboxServer è stato eseguito correttamente, ma i database non sono stati montati
Cause possibili In genere questo problema si verifica quando l'account del Servizio cluster non dispone dell'autorità necessaria per montare il database. In alternativa, il failover ha causato la perdita di un numero di registri maggiore rispetto a quanto consentito dalle impostazioni di configurazione del montaggio automatico. L'altra causa tipica in caso di failover è la mancata integrità delle copie passive nel momento in cui si è verificato l'errore.
Soluzione Durante l'installazione si verificano spesso problemi relativi alle autorizzazioni dell'account del Servizio cluster. Se al termine dell'installazione i database non sono stati montati, è probabile che all'account del Servizio cluster non siano state concesse le autorizzazioni appropriate. Per risolvere il problema, concedere le autorizzazioni appropriate all'account del Servizio cluster, quindi eseguire regolarmente l'arresto e riavviare l'intero cluster. È possibile eseguire l'operazione mediante la seguente procedura: (1) portare non in linea il server di cassette postali in cluster, (2) chiudere il nodo passivo, (3) chiudere il nodo attivo; (4) avviare il nodo attivo; (5) avviare il nodo passivo e (6) portare in linea il server di cassette postali in cluster.
- Esaminare il registro eventi per determinare se il failover ha causato la perdita di un numero di registri maggiore rispetto a quanto consentito dalle impostazioni di configurazione del montaggio automatico. Una volta determinato lo stato del database di copia del gruppo di archiviazione, è possibile montarlo esplicitamente eseguendo il cmdlet Restore-StorageGroupCopy in Exchange Management Shell. Infine, eseguire il cmdlet Get-StorageGroupCopy ed esaminare il valore SummaryCopyStatus per rilevare eventuali problemi nella copia precedentemente attiva che ne hanno impedito il montaggio. Se si verificano dei problemi, esaminare il registro eventi per identificarne la causa e quindi eseguire i passaggi necessari a risolvere il problema.
Il failover è stato eseguito correttamente, ma alcuni database non sono stati montati né automaticamente né manualmente. In alternativa, Get-ClusteredMailboxServerStatus segnala uno o più database con errori
Cause possibili Un failover recente ha causato la perdita di un numero di registri maggiore rispetto a quanto consentito dalle impostazioni di configurazione del montaggio automatico. L'altra causa tipica in caso di failover è la mancata integrità della copia passiva nel momento in cui si è verificato l'errore.
Nota
È possibile che i database vengano contrassegnati sinteticamente come "non riuscito" o "non in linea" durante un'interruzione pianificata o non pianificata. Questo stato è temporaneo e si verifica quando il servizio di replica tenta di eseguire la copia finale di tutti i registri disponibili.
Soluzione Esaminare il registro eventi per determinare la causa del mancato montaggio del database. Il database potrebbe non essere stato montato perché i registri o i file di database sono danneggiati. In questo caso, ripristinare l'accesso al database spostando il server attivo sull'altro nodo. È possibile determinare se si è verificato un errore nel database esaminando il registro eventi. Una volta determinato lo stato del database di copia del gruppo di archiviazione, è possibile montarlo esplicitamente eseguendo il cmdlet Restore-StorageGroupCopy in Exchange Management Shell. Infine, eseguire il cmdlet Get-StorageGroupCopyStatus ed esaminare il valore SummaryCopyStatus per rilevare eventuali problemi nella copia precedentemente attiva che ha impedito il montaggio. Se dallo stato si deduce che la copia del gruppo di archiviazione è decisamente obsoleta e non è possibile attivarla, il database può essere ripristinato quando il nodo danneggiato è di nuovo operativo e sono disponibili più registri. I registri vengono copiati automaticamente senza alcuna azione particolare.
Un database non viene montato all'avvio in un ambiente di replica continua cluster
Cause possibili Il mancato montaggio del database potrebbe essere il risultato di un'azione esplicità dell'amministratore. Se un database viene esplicitamente smontato e quindi il server di cassette postali in cluster viene portato non in linea, il database non verrà portato in linea all'avvio successivo, oppure durante il failover è andato perduto un numero di registri maggiore rispetto al numero massimo consentito.
Soluzione Eseguire il cmdlet Get-ClusteredMailboxServerStatus in Exchange Management Shell per verificare se l'archivio è operativo sul nodo. Utilizzare Exchange Management Console o Exchange Management Shell per tentare un'operazione di montaggio della copia di database interessata. Per ulteriori informazioni sul montaggio della copia di database, vedere Come installare un database in un ambiente di replica continua cluster. Dopo l'operazione di montaggio esaminare il registro eventi per determinare se sono stati segnalati degli errori.
Viene registrato l'evento cluster MSExchangeRepl 2073, indicante che il servizio di replica di Microsoft Exchange non è stato in grado di trovare una directory specificata
Cause possibili L'evento di errore indica che il servizio di replica di Microsoft Exchange non è stato in grado di creare la directory specificata dall'evento. Se non sono ancora presenti, il servizio di replica di Microsoft Exchange tenta di creare diverse directory richieste, inclusi percorsi di directory per file di registro di origine e di destinazione, file di sistema di destinazione e il percorso per il controllo dei file di registro.
Il servizio di replica di Microsoft Exchange potrebbe non essere in grado di creare la directory specificata a causa di un problema di autorizzazioni, di un errore hardware o di un errore di configurazione.
Soluzione Esaminare il codice di errore restituito dall'evento. Verificare che il percorso della directory sia disponibile e accessibile. Controllare le autorizzazioni del file system. Verificare la configurazione dell'archivio e il corretto funzionamento dell'hardware.
Move-ClusteredMailboxServer non avvia un'interruzione pianificata a causa di un problema di replica
Cause possibili Il cmdlet di Exchange Management Shell Move-ClusteredMailboxServer include i controlli di convalida per impedire l'interruzione pianificata in un nodo passivo se la replica non è completamente integra in tutte le copie del gruppo di archiviazione. In questo modo le interruzioni pianificate non si protraggono per un periodo di tempo troppo lungo.
Soluzione Identificare i gruppi di archiviazione che hanno un problema e risolverlo. Il messaggio di errore del cmdlet Move-ClusteredMailboxServer consente di identificare la copia del gruppo di archiviazione problematica. Se si desidera eseguire lo spostamento e ignorare il controllo della convalida, assicurarsi che sia stato smontato solo il database della copia del gruppo di archiviazione danneggiata. Riprovare l'operazione di spostamento e utilizzare il parametro -IgnoreDismounted. Il parametro IgnoreDismounted indica che i gruppi di archiviazione smontati devono essere ignorati per i controlli di integrità della replica.
La replica non viene sincronizzata nuovamente dopo il failover di uno o più gruppi di archiviazione
Cause possibili Il messaggio di errore restituito dal cmdlet Get-StorageGroupCopyStatus indica che nel database esiste una divergenza. Questa situazione si è verificata in quanto il server attivo precedente non disponeva di un numero sufficiente di registri replicati prima del failover.
Soluzione Eseguire di nuovo il seeding del database utilizzando il cmdlet Update-StorageGroupCopy in Exchange Management Shell.
Seeding non riuscito
Cause possibili È in corso un backup sul server attivo o esiste un problema di comunicazione.
Soluzione Verificare che non sia in corso un backup della copia del gruppo di archiviazione interessata o del database. Assicurarsi che il nodo attivo sia in linea.
Ulteriori informazioni
Per ulteriori informazioni sui cmdlet di Exchange Management Shell descritti in precedenza, vedere i seguenti argomenti:
Per informazioni sulla risoluzione dei problemi relativi alla replica continua locale, vedere Come risolvere i problemi relativi alla replica continua locale.