Gestione della replica continua di standby
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Ultima modifica dell'argomento: 2008-11-19
Oltre alle attività di gestione e amministrazione quotidiane di un'organizzazione di Microsoft Exchange, esistono attività specifiche per la replica continua di standby (SCR, Standby Continuous Replication). Le attività di amministrazione per la replica SCR sono in genere le seguenti:
Configurazione dello spazio su disco per la replica SCR e la gestione dei volumi disco.
Abilitazione e disabilitazione della replica SCR.
Monitoraggio dell'attività di replica.
Installazione, disinstallazione, creazione e rimozione di database.
Spostamento della posizione in cui vengono memorizzati i file del gruppo di archiviazione o del database quando un gruppo di archiviazione viene abilitato per la replica SCR.
Verifica dell'integrità della destinazione SCR.
Gestione dell'attività di replica e riproduzione.
Ripristino a seguito di danneggiamento.
Queste attività vengono descritte più avanti in questo argomento.
La replica SCR viene abilitata e gestita interamente mediante Exchange Management Shell. Non è possibile utilizzare Exchange Management Console per abilitare o disabilitare la replica SCR, visualizzarne lo stato o gestirne qualsiasi aspetto.
Configurazione dello spazio su disco per la replica continua di standby
Sebbene per la replica SCR non sia richiesta alcuna configurazione particolare dello spazio su disco, è necessario tuttavia disporre di una capacità adeguata. È necessario configurare soluzioni di archiviazione equivalenti per tutte le destinazioni SCR configurate per lo stesso gruppo di archiviazione. Per completare la configurazione, è opportuno attenersi alle procedure specificate dal fornitore della soluzione di archiviazione.
Gestione dei volumi disco in un ambiente SCR
Durante la gestione di un ambiente SCR, potrebbe essere necessario gestire i volumi del disco connessi al server Exchange. Ad esempio, potrebbe essere necessario scollegare temporaneamente il volume dal sistema per eseguire la manutenzione e per altre motivazioni. Se le attività di manutenzione interessano un volume del disco contenente la copia attiva del gruppo di archiviazione, il database di quest'ultima dovrà essere disinstallato. Per eseguire la manutenzione dei volumi del disco contenenti la copia passiva del gruppo di archiviazione, è necessario interrompere tutte le operazioni di I/O (Input/Output) del volume arrestando il processo di replica. Per ulteriori informazioni sulla gestione dei volumi disco, vedere Come preparare attività di gestione disco quando si utilizza la replica continua di standby.
Abilitazione della replica continua di standby
La replica continua di standby (SCR) si abilita soltanto utilizzando Exchange Management Shell ed eseguendo il cmdlet New-StorageGroup oppure il cmdlet Enable-StorageGroupCopy. Entrambi i cmdlet includono alcuni nuovi parametri che sono stati introdotti con Microsoft Exchange Server 2007 Service Pack 1 (SP1):
-StandbyMachine Questo parametro consente di specificare il nome del computer che conterrà la destinazione SCR. Il valore di questo parametro viene impostato come parte del valore dell'attributo msExchStandbyCopyMachines del gruppo di archiviazione abilitato per la replica SCR. L'attributo msExchStandbyCopyMachines è una stringa Unicode a più valori aggiunta allo schema del servizio directory di Active Directory quando nell'organizzazione di Exchange viene introdotto Exchange 2007 SP1.
-ReplayLagTime Questo parametro consente di specificare il tempo di attesa del servizio di replica di Microsoft Exchange prima della riesecuzione dei file di registro copiati nel computer di destinazione SCR. Il formato di questo parametro è giorni.ore:minuti:secondi. Il valore predefinito per questa impostazione è 24 ore. L'impostazione massima consentita per questo valore è 7 giorni. L'impostazione minima consentita è 0 secondi, sebbene questa impostazione non influisca sul ritardo predefinito dell'attività di riesecuzione dei registri pari a 50 file di registro. Dopo aver impostato il valore di questo parametro, non è possibile modificarlo senza disabilitare e riabilitare la replica SCR.
-TruncationLagTime Questo parametro indica il tempo in cui il servizio di replica di Microsoft Exchange rimane in attesa prima di troncare i file di registro copiati nel computer di destinazione SCR e rieseguiti nella copia del database. Il periodo di tempo ha inizio successivamente alla riesecuzione del registro nella copia del database. Il formato di questo parametro è giorni.ore:minuti:secondi. L'impostazione massima consentita per questo valore è 7 giorni. L'impostazione minima consentita è 0 secondi, sebbene questa impostazione elimini efficacemente tutti i ritardi nell'attività di troncamento dei registri. Dopo aver impostato il valore di questo parametro, non è possibile modificarlo senza disabilitare e riabilitare la replica SCR.
-SeedingPostponed Questo parametro consente di ignorare il seeding iniziale della destinazione SCR. Se si utilizza questo parametro, è necessario che l'amministratore esegua il seeding manuale della destinazione SCR mediante il cmdlet Update-StorageGroupCopy. Questo parametro è disponibile solo con il cmdlet Enable-StorageGroupCopy. Non è disponibile con il cmdlet New-StorageGroup, perché in questa fase non esiste alcun database di origine.
Importante
Per modificare le impostazioni di ritardo di replica o di troncamento, è innanzitutto necessario disabilitare e abilitare SCR utilizzando i nuovi valori per tali impostazioni.
Oltre al ritardo configurato dall'amministratore per la riesecuzione mediante il parametro ReplayLagTime, Exchange impedisce anche la riesecuzione di un determinato numero di file di registro nella destinazione SCR, indipendentemente dal valore di ReplayLagTime, in base alla formula seguente:
Massimo tra ("valore di ReplayLagTime" e "X file di registro")
in cui X = 50. Questa caratteristica rappresenta un'ulteriore salvaguardia rispetto all'esigenza di eseguire nuovamente il seeding del gruppo di archiviazione nei casi in cui, nell'origine SCR in ambiente di replica continua, ad esempio LCR o CCR, si verifichi un failover con perdita dei dati e tale origine venga riportata in linea mediante il cmdlet Restore-StorageGroupCopy. Con il ritardo dell'attività di riesecuzione nelle destinazioni SCR, quando si verifica un failover con perdita di dati in un'origine SCR la necessità di un nuovo seeding delle copie di SCR viene ridotta al minimo perché la perdita dei dati nell'origine SCR determina un riavvicinamento temporale delle due copie.
Importante
Il tempo di attesa preimpostato di 50 file di registro e il valore del parametro ReplayLagTime influiscono sulla creazione del database di destinazione SCR iniziale. Il database di destinazione SCR non viene creato fino alla replica di 50 file di registro delle transazioni nel computer di destinazione SCR e alla scadenza del periodo di tempo indicato dal parametro ReplayLagTime che, per impostazione predefinita, è di 24 ore.
Quando si abilita la replica SCR per un gruppo di archiviazione, viene creata automaticamente una copia del gruppo di archiviazione con i relativi file di sistema, file di registro e file di database, che viene gestita nel computer di destinazione SCR utilizzando gli stessi percorsi del gruppo di archiviazione dell'origine SCR.
Dopo aver abilitato SCR, è consigliabile verificare l'integrità e lo stato di tutti i gruppi di archiviazione utilizzando il cmdlet Test-ReplicationHealth. Per la procedura dettagliata sulle modalità di abilitazione della replica SCR, vedere Come abilitare la replica continua di standby di un gruppo di archiviazione esistente e Abilitazione della replica continua di standby per un nuovo gruppo di archiviazione.
La replica SCR e il troncamento dei registri
Poiché non è possibile eseguire copie di backup di un database di destinazione SCR, il troncamento dei registri SCR non è basato sui tempi di backup. Il troncamento dei registri è, invece, determinato dal punto di arresto dell'origine SCR e dal valore del parametro TruncationLagTime.
Se l'origine SCR è un server di cassette postali in cluster (CMS) in ambiente CCR, la logica di troncamento dei registri include la copia e l'ispezione dei file di registro da parte di tutte le destinazioni SCR. Di conseguenza, se una destinazione SCR non è disponibile, il troncamento dei registri dell'origine SCR non ha luogo anche se vengono eseguite copie di backup.
In un ambiente SCR può non essere necessario eseguire il nuovo seeding di una destinazione SCR disabilitata e, successivamente, abilitata se tutti i necessari file di registro sono disponibili, in base a quanto segue:
Se si abilita la registrazione circolare per il gruppo di archiviazione, l'eliminazione del registro determina l'esigenza di un nuovo seeding della destinazione SCR abilitata, a causa di intervalli nella sequenza dei registri.
Se si esegue una copia di backup che include il troncamento dei file di registro, l'eliminazione del registro determina l'esigenza di un nuovo seeding della destinazione SCR abilitata, a causa di intervalli nella sequenza dei registri.
Se i file di registro non vengono troncati con una delle modalità precedenti, non è necessario eseguire un nuovo seeding dopo aver disabilitato e abilitato nuovamente SCR. In questo caso è necessario eliminare i file di registro della destinazione SCR che, tuttavia, verranno nuovamente replicati dall'origine SCR.
Per abilitare nuovamente una destinazione SCR precedentemente disabilitata, è consigliabile non eseguire operazioni di troncamento dei registri, ad esempio abilitando la registrazione circolare o eseguendo copie di backup del troncamento dei registri, fino alla nuova abilitazione della destinazione SCR e alla replica delle relative modifiche di configurazione in Active Directory.
Disabilitazione della replica continua di standby
È possibile disabilitare SCR solo utilizzando il cmdlet Disable-StorageGroupCopy e il parametro StandbyMachine. Nella disabilitazione della replica SCR, è importante includere il valore appropriato del parametro StandbyMachine. Se anche per il gruppo di archiviazione dell'origine SCR è stata abilitata la replica LCR e non si include il parametro StandbyMachine come parte di questo comando, la replica LCR viene disabilitata per il gruppo di archiviazione.
La disabilitazione della replica SCR è necessaria per modificare il valore di uno dei parametri ReplayLagTime o TruncationLogDelay. Se la replica SCR è abilitata, non è possibile modificare questi valori. Per modificare le impostazioni del ritardo di riesecuzione o di troncamento, quindi, è necessario innanzitutto disabilitare la replica SCR e abilitarla utilizzando i nuovi valori di queste impostazioni.
Per la procedura dettagliata di disabilitazione di SCR per un gruppo di archiviazione, vedere Disaboilitazione della replica continua di standby per un gruppo di archiviazione.
Monitoraggio dell'attività di replica.
Sebbene SCR non richieda un monitoraggio particolare, si consiglia di monitorare regolarmente i singoli gruppi di archiviazione per assicurarsi che i file di registro vengano replicati correttamente. Microsoft Exchange Server 2007 Management Pack per Microsoft Operations Manager 2005 include avvisi per vari problemi critici relativi agli ambienti SCR:
Il servizio di replica di Microsoft Exchange non è in esecuzione. Va sottolineato che l'evento che ha generato questo avviso non viene visualizzato ripetutamente dopo l'interruzione del servizio, quindi tutti gli avvisi associati saranno persi se quell'avviso viene cancellato.
Lo stato della copia di destinazione SCR è Non riuscito.
Lo stato della copia della destinazione SCR è Integro, ma le attività di copia del registro non sono aggiornate.
Gli avvisi precedenti, generati da Exchange 2007 Management Pack, richiedono un'analisi approfondita e una risoluzione rapida.
Cmdlet Test-ReplicationHealth
In Exchange 2007 SP1 è stato introdotto un nuovo cmdlet denominato Test-ReplicationHealth. Questo cmdlet è progettato per il monitoraggio proattivo della replica continua (LCR, CCR e SCR) e della relativa pipeline. Il cmdlet Test-ReplicationHealth verifica tutti gli aspetti della replica, dei servizi Cluster, della replica del gruppo di archiviazione e dello stato della riesecuzione per offrire una panoramica completa del sistema di replica. In particolare, il cmdlet Test-ReplicationHealth esegue i test descritti nella seguente tabella.
Test eseguiti dal cmdlet Test-ReplicationHealth
| Prova | Descrizione |
|---|---|
Stato della rete cluster |
Il cmdlet verifica che tutte le reti gestite da cluster nel nodo locale siano in esecuzione. Questo test è applicabile solo ad ambienti CCR. |
Stato del gruppo di quorum |
Il cmdlet verifica l'integrità del gruppo di cluster contenente la risorsa quorum. Questo test è applicabile solo ad ambienti CCR. |
Stato del quorum della condivisione di file |
Verifica che il valore di FileSharePath utilizzato dal quorum della maggioranza dei nodi con il witness di condivisione file sia raggiungibile. Questo test è applicabile solo ad ambienti CCR. |
Stato del gruppo di server di cassette postali in cluster |
Verifica che il CMS sia integro controllando che tutte le risorse del gruppo siano in linea. Questo test è applicabile solo ad ambienti CCR. |
Stato del nodo |
Il cmdlet verifica che nessuno dei nodi del cluster sia In pausa. Questo test è applicabile solo ad ambienti CCR. |
Stato della registrazione DNS |
Verifica che tutte le interfacce di rete gestite da cluster con l'opzione La registrazione DNS deve riuscire impostata abbiano superato la registrazione DNS. Questo test è applicabile solo ad ambienti CCR. |
Stato del servizio di replica |
Il cmdlet verifica l'integrità del servizio di replica di Microsoft Exchange nel nodo locale. |
Copia del gruppo di archiviazione sospesa |
Il cmdlet verifica l'eventuale sospensione della replica continua per uno dei gruppi di archiviazione. |
Copia del gruppo di archiviazione non riuscita |
Il cmdlet verifica se lo stato di una delle copie dei gruppi di archiviazione è Non riuscito. |
Lunghezza della coda della replica del gruppo di archiviazione |
Il cmdlet verifica se la lunghezza della coda della copia di replica di un gruppo di archiviazione è superiore alle soglie consigliate. Le soglie attuali sono:
|
Database non montati a seguito di un failover |
Il cmdlet verifica l'eventuale presenza, a seguito di un failover, di database non montati o danneggiati. Questo test verifica solo l'eventuale presenza di database danneggiati a seguito di un failover. |
Montaggio e smontaggio di database
In alcuni casi può essere necessario montare o smontare i database presenti in un ambiente SCR. Per eseguire la manutenzione o per riconfigurare il gruppo di archiviazione o il database dell'origine SCR, è necessario bloccare i servizi che interagiscono con entrambi mentre l'attività è in corso. Ciò potrebbe richiedere l'esecuzione di una riconfigurazione o la risoluzione di problematiche relative al server o al database. Non è possibile accedere a un database smontato.
Spostamento del percorso dei file del gruppo di archiviazione e del database
È possibile modificare il percorso di un database di un gruppo di archiviazione abilitato per SCR. In un ambiente SCR, esistono due file di database, uno per ogni copia. Quando si spostano i file del gruppo di archiviazione o il file del database, è necessario modificare i percorsi di entrambe le copie insieme.
Nota
È necessario che esista una corrispondenza del percorso completo dei file del gruppo di archiviazione e del database con l'origine e con tutte le destinazioni SCR.
In un ambiente SCR le procedure utilizzate per riconfigurare il percorso dei file di sistema e di registro di un gruppo di archiviazione e il percorso dei file del database sono analoghe. Per la procedura dettagliata sulla modifica del percorso dei file di registro e dei file di sistema di un gruppo di archiviazione abilitato per la replica SCR, vedere Come spostare un gruppo di archiviazione in un ambiente di replica continua di standby. Per le procedure dettagliate sulla modifica del percorso dei file del database in un ambiente SCR, vedere Spostamento di un database in un ambiente di replica continua di standby.
Importante
Non è possibile inserire i database nella directory radice di un volume.
Visualizzazione delle informazioni relative allo stato
I monitoraggi e le variazioni di stato vengono eseguiti mediante Exchange Management Shell. In Exchange Management Console non viene visualizzato lo stato della copia, né altre informazioni sulla replica SCR. Dopo aver abilitato la replica SCR per un gruppo di archiviazione, è possibile utilizzare Exchange Management Shell per visualizzare le impostazioni di configurazione specifiche per la replica SCR del gruppo di archiviazione e del relativo database.
Informazioni sullo stato della replica continua di standby
In Exchange 2007 vengono pubblicate diverse informazioni sullo stato delle copie della replica SCR. Nella tabella seguente vengono descritte le informazioni sullo stato disponibili per i gruppi di archiviazione abilitati per la replica SCR. Per informazioni dettagliate su come ottenere informazioni relative allo stato, vedere Visualizzazione dello stato della replica continua di standby.
Nota
Nella tabella seguente vengono elencate le proprietà, nell'ordine in cui sono visualizzate nell'output completo del cmdlet Get-StorageGroupCopyStatus.
Informazioni sullo stato disponibili per i gruppi di archiviazione abilitati per la replica continua di standby
| Proprietà | Descrizione |
|---|---|
Identity |
Server e nome del gruppo di archiviazione per il quale è stata eseguita la query. |
StorageGroupName |
Nome del gruppo di archiviazione per il quale è stata eseguita la query. |
SummaryCopyStatus |
Stato generale corrente della copia della replica continua di standby. I valori possibili sono:
|
Failed |
Il processo di verifica ha rilevato un'incoerenza del database o dei registri che impedisce la replica oppure si è verificato un problema di accesso o di configurazione nella copia attiva o passiva. I valori possibili sono True e False. |
FailedMessage |
Il messaggio di testo indica il motivo dell'esito negativo della replica. È comunque possibile che, oltre quello descritto, si siano verificati altri problemi. |
Seeding |
È in corso il seeding del database. I valori possibili sono True e False. |
Suspend |
La replica e la riproduzione relative alla copia passiva sono state interrotte. L'avanzamento del database verrà quindi sospeso e i registri non potranno essere copiati. I valori possibili sono True e False. |
SuspendComment |
Un commento facoltativo specificato dall'amministratore come motivo o nota per l'interruzione dell'attività di replica. |
CopyQueueLength |
Numero dei file di registro delle transazioni in attesa di essere copiati nella cartella dei file di registro della copia passiva. Una copia viene considerata completata solo dopo che ne è stato eseguito un controllo per il rilevamento di eventuali danni. |
ReplayQueueLength |
Numero dei file di registro delle transazioni già copiati e in attesa di essere rieseguiti 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 gruppo di archiviazione. |
LatestFullBackupTime |
Ora dell'ultimo backup completo. |
LatestIncrementalBackupTime |
Ora dell'ultimo backup incrementale. |
SnapshotBackup |
Il backup è stato eseguito utilizzando le API del flusso legacy o il servizio Copia Shadow del volume (Volume Shadow Copy Service, VSS). I valori possibili sono True e False. |
È possibile valutare rapidamente lo stato di una copia della replica SCR esaminando i valori di SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Tali proprietà indicano se la copia SCR funziona correttamente e se è relativamente aggiornata sia in relazione alla copia che alla riesecuzione dei registri. Se si verificano le seguenti condizioni, è necessario determinare la causa e correggere il problema:
La copia rimane per lungo tempo in stato di non integrità.
La lunghezza della coda delle copie è maggiore di 5.
La lunghezza della coda delle riproduzioni è maggiore di 20.
L'ora associata all'ultimo registro di cui è stata eseguita la verifica non è recente. È probabile che si verifichi questa situazione se il gruppo di archiviazione non è interessato da modifiche significative o se il servizio di replica viene interrotto.
Il valore della lunghezza della coda delle riproduzioni e il valore della lunghezza della coda delle copie possono essere utilizzati come contatori delle prestazioni. Questi contatori delle prestazioni, ovvero CopyQueueLength e ReplayQueueLength, sono controllati dall'oggetto prestazioni MSExchange Replication.
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 il gruppo di archiviazione sta eseguendo la replica.
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à. La dimensione delle code di riesecuzione e di copia continua ad aumentare.
In alcuni casi molto rari, il registro può essere correttamente verificato ma non è tuttavia possibile rieseguirlo. In questo caso, durante il tentativo di ripristino il sistema passa alternativamente dallo stato di errore a quello di integrità e viceversa. La dimensione delle code di riesecuzione e di copia continua ad aumentare.
Verifica dell'integrità di una destinazione SCR
Durante l'utilizzo della funzionalità SCR, è opportuno verificare periodicamente l'integrità della copia di destinazione SCR 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. Per eseguire il controllo utilizzare la versione a riga di comando dello strumento servizio Copia Shadow del volume di Microsoft (VSSAdmin.exe) e le Utilità database di Exchange Server (Eseutil.exe). Per la procedura dettagliata relativa all'utilizzo di VSSAdmin ed Eseutil per il rilevamento di eventuali danni fisici nei registri delle transazioni e nei file del database, vedere Come verificare una copia della replica continua locale di standby.
Nota
Prima di eseguire un controllo della coerenza fisica nel database, è necessario sospendere temporaneamente tutte le attività di riproduzione nel gruppo di archiviazione. È possibile sospendere l'attività di replica mediante il cmdlet Suspend-StorageGroupCopy di 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. È consigliabile eseguire le verifiche durante le ore di inattività e di ridurre al minimo la sospensione dell'attività di riesecuzione. La sospensione della copia del gruppo di archiviazione interrompe infatti tutti gli aggiornamenti della copia SCR e può quindi aumentare le probabilità che in alcuni contenuti si verifichino errori.
Gestione della replica e della riproduzione
La gestione della replica e della riesecuzione dei file di registro in un ambiente SCR interessa le seguenti attività principali:
Interruzione della replica nella copia del gruppo di archiviazione.
Riavvio della replica nella copia del gruppo di archiviazione.
Nuovo seeding di un gruppo di archiviazione
Interruzione e riavvio delle modifiche in una copia del gruppo di archiviazione e nel relativo database
In alcuni casi potrebbe essere necessario interrompere e riavviare l'attività di replica dei registri delle transazioni. La replica dei registri delle transazioni ha luogo quando è in esecuzione il servizio di replica di Microsoft Exchange, un gruppo di archiviazione è stato abilitato per la replica SCR e sia l'origine che la destinazione SCR sono operative. Se l'origine o la destinazione non è più disponibile, è necessario interrompere la replica. Inoltre, alcune attività amministrative, ad esempio il seeding, possono richiedere la sospensione della replica di un gruppo di archiviazione abilitato per SCR. Se è necessario interrompere ogni accesso ai file di dati della destinazione, è necessario sospendere il processo di replica.
Talvolta è necessario controllare le attività della destinazione SCR. ad esempio per eseguire una riconfigurazione o per risolvere problemi relativi al server o al database. L'interruzione della riesecuzione dei registri è necessaria anche per eseguire un controllo della coerenza fisica della destinazione SCR. Per controllare gli aggiornamenti delle copie del database, è necessario interrompere la replica relativamente alla destinazione SCR. È necessario interrompere la replica anche nel caso di eventuali modifiche dei registri della destinazione SCR.
Per ulteriori informazioni sull'interruzione delle modifiche alla replica nelle copie SCR, vedere Come sospendere le modifiche a una destinazione della replica continua di standby. Per ulteriori informazioni sul riavvio delle modifiche alla replica nelle copie SCR, vedere Ripresa della replica in una destinazione della replica continua di standby. Per ulteriori informazioni su come eseguire un controllo di integrità sui file di registro delle transazioni della copia passiva e sui file del database, vedere Come verificare una copia della replica continua locale di standby.
Esecuzione del seeding e del nuovo seeding di una copia del gruppo di archiviazione
Il seeding e il nuovo seeding di una copia del gruppo di archiviazione in ambiente SCR vengono eseguiti mediante il cmdlet Update-StorageGroupCopy e il parametro StandbyMachine (introdotto nella versione Exchange 2007 SP1).
Per la procedura dettagliata relativa al seeding o al nuovo seeding della destinazione SCR, vedere Come eseguire il seeding di una destinazione della replica continua di standby.
Ripristino di un danneggiamento mediante valutazione dello stato della replica al momento del danneggiamento
Dopo un errore o un danneggiamento di una copia del database, è necessario decidere se continuare immediatamente le operazioni utilizzando la destinazione SCR. Nella replica SCR sono disponibili informazioni importanti in base alle quali prendere questa decisione:
Integrità della copia al momento dell'errore
Code delle copie e delle riproduzioni al momento dell'errore
Ora dell'ultimo registro di cui è stata eseguita la verifica al momento dell'errore
Per ottenere queste informazioni, utilizzare il cmdlet Get-ClusteredMailboxServerStatus. La procedura dettagliata è descritta in Visualizzazione dello stato della replica continua di standby.
Nota
Esaminando l'ora dell'ultimo registro di cui è stata eseguita la verifica è possibile ottenere informazioni sulle modifiche apportate più di recente dall'origine SCR. Queste informazioni sono utili per individuare eventuali errori che si verificano quando il servizio di replica di Microsoft Exchange non viene avviato, poiché, quando il servizio di replica di Microsoft Exchange viene interrotto, le lunghezze delle code non sono accurate.
La lunghezza della coda delle copie consente di ottenere le informazioni più accurate sullo stato dell'origine SCR al momento dell'errore. In base a queste informazioni e alla stima del tempo di ripristino del database danneggiato, decidere se attivare la destinazione SCR disponibile:
Una lunghezza significativa delle code di riesecuzione implica che il processo di ripristino richiederà tempo, ma non indica che si verificherà necessariamente una perdita importante di dati.
Se la lunghezza della coda delle copie è significativa, potrebbero risultare persi molti registri. Se il database è stato attivato, verrà ripristinato fino a un intervallo di tempo approssimativamente pari a quello dell'ultimo registro copiato. È possibile ottenere questa informazione anche eseguendo il cmdlet Get-StorageGroupCopyStatus.
Se l'ultimo registro è stato esaminato molto prima che si verificasse l'errore, il servizio di replica di Microsoft Exchange è probabilmente interrotto e le informazioni sulle altre code non risulteranno accurate.
Nota
A causa della natura della replica SCR, nonché delle latenze esterne e degli errori di comunicazione, è possibile che la lunghezza della coda delle copie non sia accurata. Lo stato corrente della copia attiva viene infatti aggiornato in modo asincrono. In genere, l'imprecisione riguarda le attività eseguite approssimativamente un minuto prima e un minuto dopo l'errore.
Nota
Non è possibile utilizzare un database con errori per il seeding di una destinazione SCR.