Gestione della 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: 2009-06-10
Oltre alle attività di gestione e amministrazione quotidiane di un'organizzazione di Exchange, esistono attività specifiche di un ambiente di replica continua cluster (CCR, Cluster Continuous Replication). In genere, le attività amministrative per la CCR sono raggruppate in due categorie:
Attività relative a un server di cassette postali in cluster
Attività relative a gruppi di archiviazione e database in un server di cassette postali in cluster
Attività relative a un server di cassette postali in cluster
Le attività amministrative associate a un server di cassette postali in cluster in una configurazione CCR includono:
Gestione dei volumi disco
Visualizzazione delle impostazioni di configurazione
Monitoraggio dell'attività di replica
Visualizzazione e raccolta dei dati sulle prestazioni
Gestione dei server di cassette postali in cluster, incluse le operazioni necessarie per portare in linea e non in linea tali server, nonché per spostarli tra i nodi
Gestione della replica e della riproduzione dei file di registro
Gestione dei volumi del disco
Durante la gestione di un ambiente CCR, può essere necessario gestire volumi disco associati al cluster CCR. È ad esempio possibile che per eseguire la manutenzione o per altri motivi il volume debba essere scollegato temporaneamente dal sistema. Se è necessario che ciò avvenga su un database o un gruppo di archiviazione attivo, è necessario smontare i database nel gruppo di archiviazione. Qualora tale operazione dovesse essere eseguita sulla copia passiva del gruppo di archiviazione o del database, tutte le operazioni di input/output (I/O) di replica effettuate sul volume dovranno essere arrestate interrompendo la replica.
Per ulteriori informazioni sulla gestione dei volumi disco, vedere Come preparare attività di gestione del volume disco per una copia della replica continua cluster.
Visualizzazione delle impostazioni di configurazione
Dopo aver abilitato la CCR per un server, è possibile utilizzare Exchange Management Console ed Exchange Management Shell per visualizzare le impostazioni di configurazione per i gruppi di archiviazione e i database sul server.
Le informazioni sulla configurazione includono la posizione del gruppo di archiviazione e dei file del database. Inoltre, è possibile controllare la configurazione correlata al server di cassette postali in cluster utilizzando Exchange Management Shell.
Per informazioni dettagliate su come visualizzare le informazioni sulla configurazione del controllo dei failover CCR, vedere Come visualizzare la configurazione del controllo dei failover.
Monitoraggio delle attività di replica
La copia passiva di un database è utile solo se viene mantenuta aggiornata. Sebbene la CCR non richieda alcun monitoraggio particolare, si consiglia di monitorare regolarmente ogni gruppo di archiviazione per verificare che i file di registro siano replicati correttamente. Microsoft Exchange Server 2007 Management Pack per Microsoft Operations Manager 2005 include avvisi per vari problemi critici relativi agli ambienti di replica continua cluster:
Il servizio di replica di Microsoft Exchange non è in esecuzione sul nodo passivo. L'evento che genera questo avviso non viene visualizzato in modo ripetitivo dopo l'interruzione del servizio, pertanto tutti gli avvisi ad esso associati andrebbero persi nel caso in cui questo venisse cancellato.
La copia passiva è in stato "Non riuscito".
La copia passiva è in stato Integro ma le attività di copia e riproduzione del registro non sono aggiornate.
Si consiglia inoltre di aggiungere una regola eventi personalizzata a Microsoft Operations Manager che viene attivata quando un nodo passivo non viene rilevato come in esecuzione e fa parte del cluster che contiene un nodo attivo. Quando si verifica questa condizione, tramite il servizio cluster viene registrato un evento nel registro eventi di sistema. Si consiglia di utilizzare i seguenti criteri per la regola di evento che fa parte dell'evento registrato dal servizio Cluster.
Origine evento: ClusSvc
ID evento: 1135
Per ulteriori informazioni sulla creazione di regole degli eventi in Microsoft Operations Manager, vedere Monitoraggio degli eventi di sistema con MOM.
Si consiglia di esaminare e risolvere quanto prima tutti gli avvisi precedenti generati da Exchange 2007 Management Pack o da una regola eventi personalizzata.
Un'alternativa all'utilizzo di Exchange 2007 Management Pack per Microsoft Operations Manager 2005 è l'esecuzione regolare di uno script che esegua il cmdlet Get-StorageGroupCopyStatus in Exchange Management Shell. Il cmdlet Get-StorageGroupCopyStatus fornisce le lunghezze delle code in cui è compreso il numero di registri generati dal nodo attivo. Per motivi legati alle prestazioni, i contatori delle prestazioni della lunghezza della coda forniscono soltanto le informazioni note al servizio di replica di Microsoft Exchange. Solo in rari casi questi dati possono essere incoerenti con lo stato del nodo attivo. Per ulteriori informazioni sul cmdlet Get-StorageGroupCopyStatus, vedere "Visualizzazione dello stato delle copie del gruppo di archiviazione" più avanti in questo argomento.
Visualizzazione e raccolta dei dati sulle prestazioni
È possibile determinare lo stato della replica utilizzando i contatori delle prestazioni. Per ulteriori informazioni sull'utilizzo dei contatori delle prestazioni per la CCR, vedere Come visualizzare i contatori delle prestazioni per la replica continua cluster.
Gestione dei server di cassette postali in cluster
Le tre attività amministrative principali per la gestione di un server di cassette postali in cluster riguardano le operazioni necessarie per portarlo in linea e non in linea e per spostarlo tra i nodi nel cluster. Possono però anche riguardare l'arresto o il riavvio di uno dei nodi del cluster come parte della gestione degli aggiornamenti o di altre operazioni di manutenzione.
Avvio e arresto dei server di cassette postali in cluster
Lo strumento Gestione cluster di failover (Windows Server 2008), Amministrazione cluster (Windows Server 2003) e lo strumento della riga di comando Cluster.exe (in entrambi i sistemi operativi) sono in grado di portare le risorse in linea e non in linea. L'operazione tramite cui un server di cassette postali in cluster viene portato non in linea viene definita arresto, l'operazione inversa viene definita avvio. Per avviare un server di cassette postali in cluster, si consiglia di utilizzare il cmdlet Start-ClusteredMailboxServer. Per arrestare correttamente un server di cassette postali in cluster, utilizzare il cmdlet Stop-ClusteredMailboxServer. In Exchange 2007 Service Pack 1 (SP1), per avviare o arrestare un server di cassette postali in cluster, è inoltre possibile utilizzare la procedura guidata per la gestione del server di cassette postali in cluster in Exchange Management Console.
Per la procedura dettagliata di connessione di un server di cassette postali in cluster, vedere Come avviare un server Cassette postali di cluster. Per la procedura dettagliata di disconnessione di un server di cassette postali in cluster, vedere Come arrestare un server Cassette postali di cluster.
Spostamento di un server di cassette postali in cluster tra i nodi
Lo spostamento manuale di un server di cassette postali in cluster tra i nodi viene definito handoff o interruzione pianificata. Per spostare un server di cassette postali in cluster, utilizzare il cmdlet Move-ClusteredMailboxServer. In Exchange 2007 SP1, per eseguire il passaggio (handoff) di un server di cassette postali in cluster, è inoltre possibile utilizzare la procedura guidata per la gestione del server di cassette postali in cluster in Exchange Management Console. Sebbene per spostare un server di cassette postali in cluster tra i nodi sia possibile utilizzare lo strumento Gestione cluster di failover (Windows Server 2008), Amministrazione cluster (Windows Server 2003) e lo strumento della riga di comando Cluster.exe (in entrambi i sistemi operativi), si consiglia di utilizzare uno degli strumenti di gestione di Exchange per spostare un server di cassette postali in cluster dal nodo attivo al nodo passivo, in quanto consentono di specificare un motivo per il passaggio (handoff). Inoltre:
Quando si utilizzano gli strumenti di gestione del cluster, non viene eseguito il controllo dell'integrità o dello stato della copia passiva, che viene invece eseguito dagli strumenti di gestione di Exchange. Pertanto, il loro utilizzo può determinare un'interruzione estesa durante l'esecuzione da parte del nodo delle operazioni necessarie a rendere il database montabile.
Con tali strumenti, inoltre, è possibile che un database venga lasciato non in linea per un tempo indefinito in quanto la replica non è integra; gli strumenti di gestione del cluster, a differenza degli strumenti di gestione di Exchange, non sono in grado di determinare lo stato della replica prima di spostare il gruppo di risorse.
Nota
Lo spostamento di un server di cassette postali in cluster da un nodo all'altro determinerà una breve interruzione del servizio. Inoltre, verranno annullati tutti i backup di tutti i gruppi di archiviazione in corso sul server di cassette postali in cluster.
Se la replica non è integra o se in seguito alle verifiche lo stato del nodo passivo risulta non accettabile per un handoff, gli strumenti di gestione di Exchange non eseguiranno l'handoff. In tale caso, se è necessario spostare il server di cassette postali in cluster sul nodo passivo, è possibile utilizzare gli strumenti di gestione del cluster.
Si consiglia di eseguire dal nodo passivo l'operazione di spostamento di un server di cassette postali in cluster in un cluster di failover in cui è presente una latenza di rete tra i nodi.
Per la procedura dettagliata di spostamento un server di cassette postali in cluster tra i nodi, vedere Come spostare un server di cassette postali in cluster in un ambiente di replica continua cluster.
Manutenzione del cluster
Le operazioni di manutenzione devono essere eseguite sempre sul nodo passivo del cluster. In genere, si consiglia di non installare aggiornamenti, aggiornamenti rapidi e altre applicazioni nel nodo attivo, ovvero il nodo su cui è correntemente presente un server di cassette postali in cluster. Per la procedura dettagliata di installazione degli aggiornamenti cumulativi di Exchange in un ambiente di replica continua cluster, vedere Applicazione degli aggiornamenti cumulativi di Exchange 2007 a server di cassette postali in cluster.
Se è necessario eseguire operazioni di manutenzione sul nodo attivo, è consigliabile innanzitutto spostare il server di cassette postali in cluster su un nodo passivo utilizzando il cmdlet Move-ClusteredMailboxServer. Dopo aver spostato il server di cassette postali in cluster, il nodo precedentemente attivo diventa passivo e quello precedentemente passivo diventa attivo. Potranno quindi essere eseguite le operazioni di manutenzione e l'handoff per lo spostamento del server di cassette postali in cluster nella direzione opposta.
L'ambiente di replica continua cluster consente di pianificare un'interruzione del sistema di un determinato nodo senza un'interruzione del server di cassette postali in cluster. In un ambiente di replica continua cluster è possibile portare non in linea un solo nodo per volta. Se più nodi sono portati non in linea contemporaneamente, il servizio viene interrotto.
Un'interruzione pianificata viene avviata tramite il cmdlet Move-ClusteredMailboxServer di Exchange Management Shell. Nell'argomento Come spostare un server di cassette postali in cluster in un ambiente di replica continua cluster viene fornita una procedura per eseguire un'interruzione pianificata.
Prima di arrestare o riavviare un nodo in un ambiente di replica continua cluster, si consiglia di verificare quale nodo stia correntemente ospitando il server di cassette postali in cluster. A tale scopo, utilizzare il cmdlet Get-ClusteredMailboxServerStatus.
Manutenzione del cluster
Le operazioni di manutenzione devono essere eseguite sempre sul nodo passivo del cluster. In genere, si consiglia di non installare aggiornamenti, aggiornamenti rapidi e altre applicazioni nel nodo attivo, ovvero il nodo su cui è correntemente presente il server di cassette postali in cluster. Per la procedura dettagliata di installazione degli aggiornamenti cumulativi di Exchange in un ambiente di replica continua cluster, vedere Applicazione degli aggiornamenti cumulativi di Exchange 2007 a server di cassette postali in cluster.
Se è necessario eseguire operazioni di manutenzione sul nodo attivo, è consigliabile innanzitutto spostare il server di cassette postali in cluster su un nodo passivo utilizzando il cmdlet Move-ClusteredMailboxServer. Dopo aver spostato il server di cassette postali in cluster, il nodo precedentemente attivo diventa passivo e quello precedentemente passivo diventa attivo. Potranno quindi essere eseguite le operazioni di manutenzione e il passaggio che sposta il server di cassette postali in cluster nella direzione opposta.
Arresto dei nodi del cluster
Per arrestare tutti i nodi del cluster, incluso il nodo attivo, è necessario innanzitutto interrompere il server di cassette postali in cluster. Il processo di arresto di Windows non è basato su Exchange. Si consiglia, pertanto, di arrestare solo i nodi passivi. Se è necessario arrestare o riavviare un nodo attivo, si consiglia di spostare il server di cassette postali in cluster su un altro nodo disponibile. Per la procedura dettagliata di spostamento di un server di cassette postali in cluster da un nodo all'altro, vedere Come spostare un server di cassette postali in cluster in un ambiente di replica continua cluster.
Se il server di cassette postali in cluster non può essere spostato sul nodo passivo, poiché, ad esempio, il nodo è già stato arrestato, sarà necessario arrestare il server prima di arrestare il nodo attivo.
Se è necessario riavviare o arrestare il nodo attivo e non è possibile spostare il server di cassette postali in cluster sul nodo passivo, si consiglia di utilizzare Criteri di gruppo per assicurarsi che il server di cassette postali in cluster venga interrotto prima di riavviare o arrestare un nodo attivo. Tramite Windows Server viene fornito un insieme di script di arresto del computer basato su criteri che è possibile gestire utilizzando lo snap-in Criteri di gruppo. Nello snap-in Criteri di gruppo sono presenti estensioni che consentono di specificare lo script da eseguire quando si arresta il computer.
È possibile, ad esempio, creare uno script di arresto che esegua il cmdlet Move-ClusteredMailboxServer o Stop-ClusteredMailboxServer con i parametri appropriati. Si consiglia, inoltre, di utilizzare uno script di arresto poiché riduce al minimo le possibilità di arresto o di riavvio del sistema da parte di un amministratore che non è a conoscenza della necessità di spostare o interrompere il server di cassette postali in cluster prima di arrestare il nodo attivo.
Importante
Questi script vengono eseguiti con l'account di sistema locale. Prima di poter eseguire correttamente questi script, è necessario concedere l'autorizzazione di gestione del server di cassette postali in cluster all'account di sistema locale (l'account computer del nodo locale).
Gestione della replica e della riproduzione di file di registro
La gestione della replica in un ambiente CCR comprende le seguenti attività principali:
Gestione dei failover in caso di interruzione della replica
Interruzione e riavvio della replica sulle copie del gruppo di archiviazione
Configurazione di una o più reti ridondanti per la replica
Gestione dei failover in caso di interruzione della replica
L'interruzione della replica interrompe la propagazione delle modifiche dal gruppo di archiviazione attivo alla copia per il periodo di sospensione. Qualora si verificasse un failover in questo intervallo di tempo, la copia del gruppo di archiviazione non conterrà le ultime modifiche. In base al volume delle modifiche verificatesi sul nodo attivo, la mancanza delle ultime modifiche potrebbe impedire il montaggio della copia nel computer passivo. Pertanto, è possibile utilizzare la versione disponibile del gruppo di archiviazione sul nodo passivo o attendere il ripristino del server originale. È importante ridurre il tempo di interruzione della replica per ridurre la relativa esposizione.
Se la versione dei dati non viene montata nel nodo passivo nel momento in cui il computer originale diventa disponibile, mediante il sistema di replica verranno copiati i registri mancanti e verrà automaticamente montata la copia del database nel nuovo nodo attivo.
Un failover successivo alla ripresa della replica può verificarsi quando dalla copia passiva risultino ancora assenti i registri oppure siano tutti presenti, ma non ancora riprodotti. Se i registri vengono copiati, ma non riprodotti, un failover attiverà la riproduzione dei registri in attesa nel database. Pertanto, per il gruppo di archiviazione si verificherà un periodo di ripristino prolungato come parte del failover, sebbene ciò non influirà su altri gruppi di archiviazione. Tuttavia, in presenza di un numero sufficiente di registri che soddisfi i criteri di montaggio automatico configurati, il database verrà infine montato con i dati disponibili più recenti. Questo processo comporta un unico rischio: uno dei registri da riprodurre potrebbe essere danneggiato e impedire una corretta riproduzione. In questo caso, la riproduzione provocherà un errore e qualsiasi ulteriore attività di riproduzione verrà bloccata. Se ciò accade, la copia del gruppo di archiviazione si troverà nello stato di errore Non riuscito, ma sarà possibile recuperare la copia utilizzando la versione del database aggiornata fino a quel momento. In alternativa, sarà necessario attendere la disponibilità del server originale e la nuova copia del registro non danneggiato.
Interruzione e riavvio della replica sulle copie del gruppo di archiviazione
È possibile che in alcuni casi le attività della copia passiva debbano essere sottoposte a controllo, ad esempio nel caso si desideri interrompere e riavviare la replica. L'operazione di replica viene controllata a livello del gruppo di archiviazione ed è localizzata su un unico database dal momento che un gruppo di archiviazione può contenere un solo database.
La replica si verifica quando entrambi i nodi nel cluster sono operativi, il servizio di replica di Microsoft Exchange è in esecuzione sul nodo di destinazione e la copia del gruppo di archiviazione ha la funzione di copia abilitata. Se la posizione di origine o di destinazione per la CCR non è disponibile, è necessario interrompere la replica. Inoltre, alcune attività di amministrazione della CCR, ad esempio il seeding, l'esecuzione di controlli di integrità o la riconfigurazione dell'archiviazione, necessitano della copia di un gruppo di archiviazione affinché ne venga interrotta la replica. Se si desidera arrestare ogni accesso ai file di registro di destinazione e alla directory di registro, sarà necessario interrompere la replica.
Exchange 2007 richiede che ogni attività di replica venga interrotta quando la posizione del gruppo di archiviazione o del database viene modificata.
Per ulteriori informazioni sull'interruzione degli aggiornamenti della copia di database, vedere Interruzione della replica di una copia della replica continua cluster. Per ulteriori informazioni sul riavvio degli aggiornamenti della copia di database, vedere Riavvio della replica di una copia della replica continua cluster.
Per ulteriori informazioni sull'esecuzione di controlli di integrità sui file di registro delle transazioni CCR e sui file di database, vedere Come verificare una copia della replica continua cluster mediante ESEUTIL.
Configurazione di una o più reti ridondanti per la replica
Exchange 2007 SP1 consente di configurare reti di cluster ridondanti utilizzabili per il seeding e il log shipping in un ambiente di replica continua cluster. La rete ridondante deve essere configurata come rete cluster mista. Per rete cluster mista si intende qualunque rete cluster configurata per il traffico di accesso sia cluster (heartbeat) che client.
Se una rete di cluster misti è stata configurata con nomi host di replica continua e indirizzi IP, Exchange 2007 utilizzerà tale rete per il log shipping. Inoltre, la rete configurata è disponibile per il seeding avviato dall'amministratore con il cmdlet Update-StorageGroupCopy. È possibile specificare più reti miste; sono disponibili più reti, Exchange 2007 ne seleziona una in modo casuale. Se la rete in uso non è più disponibile, Exchange 2007 seleziona automaticamente un'altra rete disponibile.
Il supporto per il log shipping in una rete mista viene configurato utilizzando il cmdlet Enable-ContinuousReplicationHostName. In modo analogo, è possibile disattivare questa funzione utilizzando il cmdlet Disable-ContinuousReplicationHostName. Se un server di cassette postali in cluster è presente in un ambiente di replica continua cluster, l'amministratore può eseguire Enable-ContinuousReplicationHostName su entrambi i nodi del cluster e specificare due indirizzi IP e nomi host. Quindi il sistema seleziona in modo casuale una rete mista per la copia dei registri dopo che la configurazione è stata eseguita correttamente e dopo la conferma che la rete mista è operativa.
Il seeding e il reseeding in un ambiente di replica continua cluster vengono eseguiti utilizzando il cmdlet Update-StorageGroupCopy. In Exchange 2007 SP1 questo cmdlet è stato esteso per includere un nuovo parametro denominato DataHostNames. Tale parametro consente di specificare la rete da utilizzare per il seeding o il reseeding. Il valore è un elenco di due nomi a più valori: un nome di dominio completo (FQDN, Fully Qualified Domain Name) o un nome host. Uno di questi nomi deve identificare il nodo passivo.
Per ulteriori informazioni su come configurare le reti ridondanti per il log shipping e il seeding, vedere i seguenti argomenti:
CCR in Windows Server 2008:
CCR in Windows Server 2003:
Attività relative a gruppi di archiviazione e database in un server di cassette postali in cluster
Le attività amministrative associate ai gruppi di archiviazione e ai database in un server di cassette postali in cluster in un ambiente di replica continua cluster includono:
Modifica della posizione dei file del gruppo di archiviazione o di un database
Visualizzazione dello stato delle copie del gruppo di archiviazione
Montaggio e smontaggio di database
Verifica dell'integrità di una copia del gruppo di archiviazione
Ripristino di un gruppo di archiviazione di produzione danneggiato o di una copia del gruppo di archiviazione danneggiata
Ripristino della replica continua cluster dopo un errore o in caso di dati danneggiati
Tutti i gruppi di archiviazione, ad eccezione di quello di ripristino che costituisce un tipo speciale di gruppo, e i database in un ambiente CCR vengono automaticamente abilitati per la replica continua. Sebbene le operazioni di replica e riproduzione possano essere sospese, non è possibile disabilitare la replica continua per uno o più gruppi di archiviazione in un ambiente CCR poiché l'interruzione impedirebbe l'accesso a database specifici.
Quando si crea un nuovo gruppo di archiviazione in un ambiente CCR, il seeding della copia del database sul nodo passivo avviene automaticamente. In caso contrario, è necessario effettuare manualmente il seeding della copia del database. Per la procedura dettagliata di esecuzione del seeding di una copia di database, vedere Come eseguire il seeding di una copia della replica continua cluster.
Spostamento della posizione dei file del gruppo di archiviazione o di un database
Talvolta è necessario spostare la posizione dei file del gruppo di archiviazione o di un database in un ambiente CCR. L'intervallo di tempo richiesto per spostare le posizioni dei file dipende dalla dimensione del database e dal numero di file di registro delle transazioni da spostare, nonché dalle caratteristiche in termini di prestazioni dell'archivio. Durante gli spostamenti, il database verrà smontato.
In un ambiente di replica continua cluster, la rilocazione di un gruppo di archiviazione richiede lo spostamento coerente di entrambe le copie poiché la posizione dei file sul nodo attivo e sul nodo passivo deve essere la stessa. Prima di spostare un gruppo di archiviazione o il relativo database, è necessario smontare il database e sospendere la replica. È possibile eseguire la copia attiva utilizzando il cmdlet Dismount-Database in Exchange Management Shell. Per il servizio di replica di Microsoft Exchange, utilizzare i cmdlet Suspend-StorageGroupCopy e Resume-StorageGroupCopy.
Nota
Il servizio di replica di Microsoft Exchange consente di monitorare costantemente sia i file nella posizione di copia che i registri sul nodo attivo. Pertanto, in caso di una qualunque manipolazione dei registri attivi, sarà necessario sospendere l'attività di quel gruppo di archiviazione utilizzando il cmdlet Suspend-StorageGroupCopy che interrompe la replica.
Per la procedura dettagliata di spostamento della posizione dei file di un gruppo di archiviazione in un ambiente di replica continua cluster, vedere Come spostare un gruppo di archiviazione in un ambiente di replica continua cluster. Per la procedura dettagliata di spostamento della posizione di un database in un ambiente di replica continua cluster, vedere Come spostare un database in un ambiente di replica continua cluster.
Visualizzazione dello stato delle copie del gruppo di archiviazione
Nella versione di produzione (RTM) di Microsoft Exchange 2007 è possibile visualizzare soltanto le informazioni sullo stato della replica continua cluster utilizzando Exchange Management Shell. In Exchange 2007 SP1 alcune delle informazioni sullo stato elencate nella tabella riportata di seguito possono essere visualizzate in Exchange Management Console.
In Exchange 2007 vengono pubblicate diverse informazioni sullo stato delle copie dei gruppi di archiviazione. Nella tabella riportata di seguito vengono illustrate le informazioni sullo stato disponibili. Nella seguente tabella gli attributi vengono elencati secondo l'ordine in cui sono visualizzati nell'intero output del cmdlet Get-StorageGroupCopyStatus. Per la procedura dettagliata di visualizzazione dello stato delle informazioni, vedere Come visualizzare lo stato di una copia di replica continua cluster utilizzando Exchange Management Shell.
Informazioni sullo stato disponibili per i gruppi di archiviazione abilitati alla CCR
| Attributo | Descrizione |
|---|---|
Identity |
Identità del gruppo di archiviazione per il quale è stata eseguita la query. Questo attributo fornisce il <ServerName>\<StorageGroupName>. |
StorageGroupName |
Nome del gruppo di archiviazione per il quale è stata eseguita la query. Questo attributo fornisce il nome al gruppo di archiviazione. |
SummaryCopyStatus |
Stato generale corrente della copia passiva. I valori possibili sono:
In Exchange 2007 SP1 vengono aggiunti i seguenti ulteriori valori di stato:
|
Failed |
Il processo di verifica ha rilevato un'incoerenza del database o dei registri che impedisce la replica In alternativa, sussiste un problema di configurazione o di accesso con la copia attiva o passiva. I valori possibili sono True e False. |
FailedMessage |
Messaggio di testo che indica il motivo dell'esito negativo della replica. È comunque possibile che, oltre quello descritto, si siano verificati altri problemi. |
Seeding |
Indica che il seeding è in corso. I valori possibili sono True e False. |
Suspend |
Indica che è stata interrotta la replica per la copia passiva. Questo stato impedisce l'avanzamento della replica del database e della copia dei registri. I valori possibili sono True e False. |
SuspendComment |
L'area di commento facoltativo nella quale un amministratore può fornire una ragione o inserire una nota esplicativa all'interruzione dell'attività di replica. |
CopySuspend |
Indica che è stata interrotta la copia dei registri per la copia passiva. Ciò impedisce la modifica della directory di copia dei registri. I valori possibili sono True e False. |
CopySuspendComment |
Il commento facoltativo dell'amministratore che fornisce una ragione o una nota esplicativa all'interruzione dell'attività di copia dei registri. |
CopyQueueLength |
Numero dei file di registro delle transazioni in attesa di essere copiati nella cartella dei file di registro della copia passiva. Una copia non viene considerata completata finché non viene controllata per rilevare eventuali danneggiamenti. |
ReplayQueueLength |
Numero dei file di registro delle transazioni in attesa di essere riprodotti nella copia passiva. |
LatestAvailableLogTime |
Data e ora nel gruppo di archiviazione di origine del nuovo file di registro delle transazioni rilevato più recentemente. |
LastCopyNotificationedLogTime |
Ora associata all'ultimo nuovo registro generato dal gruppo di archiviazione attivo e noto alla copia. |
LastCopiedLogTime |
Data e ora nel gruppo di archiviazione di origine dell'ultima copia con esito positivo di un file di registro delle transazioni. |
LastInspectedLogTime |
Data e ora nel gruppo di archiviazione di destinazione dell'ultima verifica con esito positivo di un file di registro delle transazioni. |
LastReplayedLogTime |
Data e ora nel gruppo di archiviazione di destinazione dell'ultima riproduzione con esito positivo di un file di registro delle transazioni. |
LastLogGenerated |
Numero di generazione dell'ultimo registro creato nella copia attiva del gruppo di archiviazione. |
LastLogCopied |
Numero di generazione dell'ultimo registro correttamente copiato nella cartella dei registri della copia passiva. |
LastLogNotified |
Numero di generazione dell'ultimo registro creato dal gruppo di archiviazione attivo e noto alla copia. |
LastLogInspected |
Numero di generazione dell'ultimo registro di cui sono state verificate la coerenza e l'integrità. |
LastLogReplayed |
Numero di generazione dell'ultimo registro riprodotto correttamente nella copia passiva del database. |
LatestFullBackupTime |
Ora dell'ultimo backup completo. |
LastestIncrementalBackupTime |
Ora dell'ultimo backup incrementale. |
SnapshotBackup |
Indica se l'ultimo backup completo eseguito è stato un backup di flusso legacy o un backup snapshot del servizio Copia Shadow del volume (VSS). |
SnapshotLatestFullBackup |
Ora dell'ultimo backup snapshot completo. |
SnapshotLatestIncrementalBackup |
Ora dell'ultimo backup snapshot incrementale. |
SnapshotLatestDifferentialBackup |
Ora dell'ultimo backup snapshot differenziale. |
SnapshotLatestCopyBackup |
Ora dell'ultimo backup snapshot di copia. |
OutstandingDumpsterRequests |
Richieste in attesa e intervallo di tempo (basso-alto) per le richieste in attesa. |
DumpsterStatistics |
Statistiche sul dumpster di trasporto da tutti i server Trasporto Hub accessibili. Il valore viene visualizzato solo quando il parametro DumpsterStatistics viene utilizzato con il comando Get-StorageGroupCopyStatus. |
DumpsterStatisticsNotAvailable |
Elenco dei server Trasporto Hub inaccessibili. |
È possibile valutare velocemente lo stato della copia di un gruppo di archiviazione analizzando i valori relativi a SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Questi attributi indicano se la copia del gruppo di archiviazione funziona correttamente e se essa risulta relativamente aggiornata nella copia come nella riproduzione dei registri. Se si verificano i problemi elencati di seguito, sarà necessario determinarne la causa e correggerli.
Lo stato della copia non è integro.
La lunghezza della coda delle copie è maggiore di 5.
La lunghezza della coda di riproduzione è maggiore di 20.
L'ora dell'ultima verifica del registro non è recente. È possibile che una tale situazione si sia verificata in seguito all'inattività del gruppo di archiviazione oppure in seguito a un arresto del servizio di replica di Microsoft Exchange.
È possibile calcolare il valore temporale delle due code nel modo seguente:
Valore temporale della coda delle copie = LatestAvailableLogTime – LastCopiedLogTime
Valore temporale della coda delle riproduzioni = LatestCopiedLogTime – LastInspectedLogTime
Il valore della lunghezza della coda delle riproduzioni e il valore della lunghezza della coda delle copie possono essere utilizzati come contatori delle prestazioni. Tali contatori delle prestazioni, ovvero CopyQueueLength e ReplayQueueLength, sono controllati dall'oggetto prestazioni del servizio di replica di Microsoft Exchange.
Esistono alcuni rari scenari in cui lo stato della replica può essere fuorviante. Di seguito viene riportato un elenco di tali scenari:
Un gruppo di archiviazione non attivo (ovvero che non subisce alcuna modifica) viene segnalato come integro quando non dovrebbe esserlo. Ciò si verifica in quanto non è possibile rilevare la condizione di errore fino a quando il registro non viene riprodotto.
Durante l'inizializzazione della replica, lo stato della replica viene rivalutato e potrebbe non essere corretto. Quando l'inizializzazione viene completata, lo stato viene aggiornato.
Il valore del campo LastLogGenerated può risultare errato quando un database viene smontato. Tuttavia, tutti i registri con contenuto per l'utente finale vengono replicati se è in corso la replica della copia del gruppo di archiviazione.
Nel caso di uno o più registri mancanti al centro di un flusso di registri, la copia passiva continua a tentare il ripristino. In tal caso, lo stato della replica passa dallo stato di errore allo stato di integrità. Le code di riesecuzione e di copia continueranno ad aumentare.
In alcuni casi molto rari, il registro può essere correttamente verificato, tuttavia non è possibile rieseguirlo. In questo caso, il sistema passerà alternativamente dallo stato di errore a quello di integrità durante il tentativo di ripristino. Le code di riesecuzione e di copia continueranno ad aumentare.
Nota
In Exchange 2007 SP1, è inoltre possibile utilizzare un nuovo cmdlet denominato Test-ReplicationHealth per verificare l'integrità e lo stato dei gruppi di archiviazione abilitati per la replica continua. Per ulteriori informazioni sul cmdlet Test-ReplicationHealth, vedere Test-ReplicationHealth.
Montaggio e smontaggio di database
Può essere necessario montare o smontare database in ambiente CCR. Questa operazione potrebbe essere necessaria per eseguire una riconfigurazione o per risolvere i problemi relativi al server o al database. Se il database è smontato, non è possibile modificarlo. Se il database è smontato non è possibile apportare modifiche né al database né ai file di registro.
Per ulteriori informazioni sul montaggio dei database in un ambiente CCR, vedere Come installare un database in un ambiente di replica continua cluster. Per ulteriori informazioni su come smontare database in un ambiente CCR, vedere Come disinstallare un database in un ambiente di replica continua cluster.
Verifica dell'integrità di una copia di un gruppo di archiviazione
Durante l'utilizzo della funzionalità di replica continua cluster, è opportuno verificare periodicamente l'integrità della copia passiva eseguendo un controllo della coerenza fisica dei file del database e dei file di registro delle transazioni. I file di database e i registri delle transazioni vengono sottoposti a una verifica di coerenza fisica per il rilevamento di eventuali danni. È possibile eseguire la verifica utilizzando Utilità database Exchange Server (Eseutil.exe). Per la procedura dettagliata relativa all'utilizzo di Eseutil per il rilevamento di eventuali danni fisici nei registri delle transazioni e nei file di database, vedere Come verificare una copia della replica continua cluster mediante ESEUTIL.
Nota
Prima di eseguire una verifica di coerenza fisica in un database, è necessario sospendere temporaneamente l'attività di replica della copia del gruppo di archiviazione. Per sospendere la riproduzione del registro delle transazioni, utilizzare il cmdlet Suspend-StorageGroupCopy in Exchange Management Shell. Una volta completata la verifica della coerenza, è possibile riprendere l'attività di riproduzione del registro delle transazioni utilizzando il cmdlet Resume-StorageGroupCopy.
Ripristino da danneggiamenti in un ambiente CCR
La CCR consente il ripristino in seguito a danneggiamento o errori in un gruppo di archiviazione di produzione avviando un'interruzione pianificata. Se i file di registro non sono danneggiati, non dovrebbe essersi verificata alcuna perdita dei dati a causa del ripristino. Tuttavia, se i file di registro non sono disponibili, il ripristino può riportare il gruppo di archiviazione solo allo stato in cui si trovava al momento dell'ultima serie di modifiche non danneggiate apportate alla copia. Come ulteriore limitazione, non possono esistere dati modificati danneggiati o mancanti prima di quel momento specifico.
Per le procedure dettagliate in cui viene illustrato come eseguire il ripristino da danneggiamenti o errori in un ambiente di replica continua cluster, vedere i seguenti argomenti:
Come ripristinare l'accesso ai database di produzione dopo un errore in un singolo database
Come ripristinare l'accesso ai database di produzione dopo un errore del server
Ripristino della CCR dopo un errore o un danneggiamento
La CCR fornisce le funzionalità per eseguire un ripristino automatico dopo un errore. Tuttavia, è ancora necessario eseguire manualmente tale ripristino nei casi elencati di seguito.
Il file del database è danneggiato sulla copia passiva Per la procedura dettagliata di ripristino della replica continua cluster in seguito al danneggiamento del database, vedere Come ripristinare un database danneggiato.
La copia passiva del database o del volume del registro non è riuscita Per la procedura dettagliata di ripristino della copia continua cluster in seguito a un errore nel volume, vedere Come eseguire il ripristino dopo un errore di volume.
Errore o divergenza del database La copia continua cluster individua e segnala un'eventuale divergenza dei database causata da un errore. In genere, ciò accade quando è disponibile una copia del database e la copia non riuscita subisce più modifiche di quelle consentite dai criteri di montaggio automatico. Per la procedura dettagliata di ripristino della CCR dopo una divergenza o un errore del database, vedere Come ripristinare la funzionalità CCR a seguito di un errore o divergenza.