Esporta (0) Stampa
Espandi tutto

Replica continua locale

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2008-01-17

La replica continua locale (LCR, Local Continuous Replication) è una soluzione per i singoli server che utilizza la tecnologia di riesecuzione e distribuzione asincrona dei registri incorporata per creare e mantenere una copia di un gruppo di archiviazione su un secondo gruppo di dischi connessi allo stesso server del gruppo di archiviazione di produzione. Il gruppo di archiviazione di produzione è definito come copia attiva, e la copia del gruppo di archiviazione mantenuta su dischi separati è definita come copia passiva. Nella figura seguente viene illustrata una distribuzione di base della replica continua locale.

Distribuzione di base della replica continua locale

Architettura di base di replica continua cluster

La replica continua locale consente la distribuzione e la riproduzione dei registri, nonché un rapido passaggio manuale (definito come attivazione) a una copia secondaria dei dati. La replica continua locale è stata progettata per ridurre il costo di proprietà complessivo di Microsoft Exchange Server 2007, come illustrato di seguito:

  • Riduzione dei tempi di ripristino dei dati necessari mediante l'abilitazione del passaggio a una copia online secondaria dei dati.

  • Riduzione del numero di backup completi regolari necessari per la protezione dei dati. I backup dei dati sono fondamentali quando si verifica un'emergenza. Sebbene la replica continua locale non elimini la necessità di eseguire i backup, riduce significativamente la necessità di backup giornalieri completi.

  • Abilitazione della funzionalità di distribuzione dei backup del servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) dalla copia attiva di un gruppo di archiviazione a una copia passiva del gruppo di archiviazione. Ciascun tipo di backup del servizio Copia Shadow del volume (completo, copia, incrementale e differenziale) può essere eseguito dalla copia passiva. La ripartizione dei backup dalla copia attiva a quella passiva consente di preservare un buon livello di I/O dei dischi nei valori dell'unità logica della copia attiva (LUN).

La replica continua locale consente la configurazione, l'utilizzo, la verifica, la rimozione e l'attivazione di una copia di un gruppo di archiviazione. Se necessario, è possibile attivare una copia passiva come database di produzione, quindi montarlo e renderlo disponibile ai client. In genere, è possibile eseguire questa attività analogamente a una modifica di configurazione, modificando il gruppo di archiviazione attivo e i percorsi del database oppure tramite un'azione del sistema operativo di livello inferiore (ad esempio, la modifica dei punti di montaggio associati al volume del database o del registro).

Non sono necessari requisiti di archiviazione particolari per LCR. È infatti possibile utilizzare qualsiasi tipo di archiviazione supportato da Windows Server 2003 o Windows Server 2008, incluse le soluzioni DAS (Direct Attached Storage), SAS (Serially Attached SCSI) e iSCSI. Per visualizzare un elenco di soluzioni di archiviazione certificate, vedere Windows Server Catalog of Tested Products.

La replica continua locale è un'opzione eccellente per i clienti che necessitano di un ripristino veloce in seguito a errori nei dati delle cassette postali ma si possono permettere interruzioni del server per motivi pianificati e non pianificati. Questa funzionalità prevede:

  • Ripristino rapido, in due fasi, in seguito a danni o errori del database di produzione.

  • Protezione per gli utenti che ne hanno più bisogno.

  • Impatto minimo sul database di produzione e sull'I/O del disco di registro.

  • Possibilità di ripartire i backup del servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) nella copia passiva del database e dei registri.

  • Possibilità di ridurre la quantità totale di dati spostati nei supporti di backup, estendendo l'intervallo di backup.

  • Funzioni di amministrazione disponibili tramite Exchange Management Console o Exchange Management Shell.

Microsoft Exchange Server 2007 Service Pack 1 (SP1) include numerosi miglioramenti per LCR, tra cui l'utilizzo del dumpster del trasporto, ulteriori elementi dell'interfaccia utente della Exchange Management Console, miglioramenti delle opzioni di stato e monitoraggio e prestazioni ottimizzate.

La funzionalità di dumpster del trasporto del ruolo del server Trasporto Hub è stata ampliata in Exchange 2007 SP1 per supportare la funzionalità LCR. Nella versione di produzione (RTM, Release To Manufacturing) di Microsoft Exchange Server 2007, il dumpster del trasporto era disponibile solo per ambienti a replica continua cluster. Diversamente da quanto accade in modalità di replica continua del cluster, in cui la richiesta di invio del dumpster del trasporto è una funzionalità automatica del processo di ripristino, in un ambiente di replica continua locale il processo viene eseguito manualmente. Il cmdlet Restore-StorageGroupCopy è stato aggiornato in Exchange 2007 SP1 in modo da includere la nuova richiesta di invio. Pertanto, quando un amministratore attiva una copia passiva di un gruppo di archiviazione in un ambiente LCR mediante il cmdlet Restore-StorageGroupCopy, la richiesta di invio del dumpster del trasporto viene effettuata nel corso del processo di attivazione.

Il dumpster del trasporto trae vantaggio dalla ridondanza dell'ambiente per recuperare alcuni dei dati danneggiati dal failover. In modo specifico, i server Trasporto Hub memorizzano una coda dei messaggi di posta elettronica inoltrati di recente. Questa coda è associata al periodo di tempo in cui la posta viene conservata e al totale dello spazio utilizzato. Sono state aggiunte nuove funzionalità a Restore-StorageGroup e quando vengono utilizzate da un amministratore per attivare la copia passiva di un gruppo di archiviazione, il servizio di replica di Microsoft Exchange richiede di inviare nuovamente i messaggi nel dumpster del trasporto per ogni server Trasporto Hub nel sito del server Cassette postali. L'archivio delle informazioni elimina automaticamente i duplicati e inoltra nuovamente la posta andata perduta.

In Exchange 2007 SP1, la condizione necessaria per conservare un messaggio di posta nel dumpster del trasporto è che sia disponibile almeno un destinatario dotato di cassetta postale su server di cassette postali in cluster in un ambiente CCR oppure in un server autonomo in un gruppo di archiviazione configurato per la replica continua locale (LCR, local continuous replication).

Di seguito vengono indicate alcune situazioni nelle quali la perdita di dati non è mitigata dal dumpster del trasporto:

  • Cartelle bozze di client Microsoft Outlook in modalità in linea.

  • Appuntamenti, aggiornamenti di contatti, aggiornamenti di proprietà, attività e aggiornamenti di attività.

  • Posta in uscita che sta transitando dal client al server Trasporto Hub. Per un certo periodo di tempo il messaggio di posta elettronica esiste solo nel server Cassette postali del mittente.

Per istruzioni dettagliate su come configurare il dumpster del trasporto, vedere Come configurare il dumpster di trasporto per la replica continua locale.

In Exchange 2007 SP1 sono stati aggiunti diversi nuovi elementi dell'interfaccia utente che ottimizzano la gestione per funzioni a disponibilità elevata, tra cui LCR. Tali miglioramenti includono:

  • Interfaccia utente del dumpster del trasporto   È stata aggiunta una nuova scheda Impostazioni globali al nodo Trasporto Hub nell'area di lavoro Configurazione organizzazione. Questa scheda include la pagina Proprietà impostazioni di trasporto che consente di configurare le impostazioni del dumpster del trasporto per l'organizzazione:

    • Dimensione massima per gruppo di archiviazione (MB)   Consente di specificare la dimensione massima del dumpster del trasporto per ogni gruppo di archiviazione.

    • Periodo massimo di mantenimento (giorni)   Consente di specificare il tempo di permanenza di un messaggio di posta elettronica nella coda del dumpster del trasporto.

  • Gestione della replica continua   Ulteriori controlli dell'interfaccia utente sono stati aggiunti a Exchange Management Console per consentire a un amministratore di sospendere, riprendere, aggiornare e ripristinare la replica continua. Tali controlli hanno la stessa funzione dei seguenti cmdlet di Exchange Management Shell:

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    È possibile utilizzare questi cmdlet e le corrispondenti attività di Exchange Management Console per gestire la replica continua sia in un ambiente LCR che CCR.

Exchange 2007 SP1 introduce anche diverse modifiche progettate per migliorare la gestibilità di Exchange 2007. Tali modifiche determinano un miglioramento delle funzionalità di creazione di rapporti cluster in Exchange 2007 RTM e includono funzionalità aggiuntive progettate per il monitoraggio proattivo degli ambienti di replica continua. Nello specifico, le modifiche e i miglioramenti correggono le vulnerabilità con il cmdlet Get-StorageGroupCopyStatus, introducono un nuovo cmdlet denominato Test-ReplicationHealth e forniscono maggiore visibilità nella finestra delle perdite del dumpster del trasporto.

In Exchange 2007 RTM, esistono numerose condizioni in cui lo stato segnalato da Get-StorageGroupCopyStatus e i contatori delle prestazioni della replica continua sono non accurati o fuorvianti:

  • Un gruppo di archiviazione non attivo (ad esempio, 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 viene smontato il database nel gruppo di archiviazione.

  • Nel caso di uno o più registri mancanti nel corso di un flusso di registri, la copia passiva continua a tentare il ripristino e lo stato della replica passa dallo stato di errore allo stato di integrità. In questo caso, le code di riproduzione e copia continueranno a crescere.

  • In alcuni casi molto rari, è possibile che la verifica di un registro abbia esito positivo ma non sia comunque possibile riprodurre il registro. In questa situazione, il sistema passerà alternativamente dallo stato di errore a quello di integrità durante il tentativo di ripristino. In questo caso, le code di riproduzione e copia continueranno a crescere.

Anche il cmdlet Get-StorageGroupCopyStatus è stato migliorato con l'aggiunta di nuove informazioni sullo stato:

  • Il cmdlet Get-StorageGroupCopyStatus segnala un valore SummaryCopyStatus di ServiceDown quando il servizio di replica di Microsoft Exchange sul computer di destinazione non è accessibile in rete.

  • Il cmdlet Get-StorageGroupCopyStatus segnala il valore Initializing per SummaryCopyStatus quando il servizio di replica di Microsoft Exchange sul computer di destinazione non ha completato le verifiche iniziali dell'avvio. È stato anche creato un nuovo contatore delle prestazioni per rappresentare questo stato come valore booleano.

  • Il cmdlet Get-StorageGroupCopyStatus segnala un valore SummaryCopyStatus di sincronizzazione quando non ha ancora completato il reseeding incrementale.

I nuovi stati per il valore SummaryCopyStatus sono visibili solo quando si utilizza la versione Exchange 2007 SP1 degli strumenti di gestione di Exchange. Quando si utilizza la versione Exchange 2007 RTM degli strumenti di gestione di Exchange, lo stato degli eventuali stati precedenti verrà segnalato come non riuscito.

Exchange 2007 SP1 introduce un nuovo cmdlet denominato Test-ReplicationHealth. Questo cmdlet è stato progettato per il monitoraggio proattivo della replica continua e della relativa pipeline. Il cmdlet Test-ReplicationHealth verifica tutti gli aspetti inerenti a replica, servizi cluster e stato di riproduzione e replica dei gruppi di archiviazione per fornire una panoramica completa del sistema di replica. Nello specifico, quando si esegue un nodo nel cluster, il cmdlet Test-ReplicationHealth esegue i test descritti nella seguente tabella.

Test eseguiti dal cmdlet Test-ReplicationHealth

Prova Descrizione

Stato della rete di cluster

Verifica che tutte le reti gestite da cluster nel nodo locale siano in esecuzione. Questo test viene eseguito solo in un ambiente CCR.

Stato del gruppo quorum

Verifica che il gruppo di cluster contenente la risorsa quorum sia integro. Questo test viene eseguito solo in un ambiente CCR.

Stato del quorum di condivisione file

Verifica che il valore di FileSharePath utilizzato dal quorum maggioranza dei nodi con il witness di condivisione file sia raggiungibile. Questo test viene eseguito solo in un ambiente CCR.

Stato del gruppo di server di cassette postali in cluster

Verifica che il server di cassette postali in cluster sia integro controllando che tutte le risorse del gruppo siano in linea. Questo test viene eseguito solo in un ambiente CCR.

Stato dei nodi

Verifica che nessuno dei nodi del cluster siano in uno stato di pausa. Questo test viene eseguito solo in un ambiente 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 viene eseguito solo in un ambiente CCR.

Stato del servizio di replica

Verifica che il servizio di replica di Microsoft Exchange sul computer locale sia integro.

Copia di gruppi di archiviazione sospesa

Verifica se la replica continua per eventuali gruppi di archiviazione a essa abilitati è stata sospesa.

Copia di gruppi di archiviazione non riuscita

Verifica se eventuali copie di gruppi di archiviazione sono in uno stato Non riuscito.

Lunghezza coda delle repliche dei gruppi di archiviazione

Verifica se eventuali gruppi di archiviazione hanno una coda di copia delle repliche di lunghezza maggiore alle soglie consigliate. Attualmente, le soglie sono le seguenti:

  • Avviso   Lunghezza della coda pari a 3-5 registri.

  • Errore   Lunghezza della coda pari 6 o più registri.

Database smontati a seguito di failover

Verifica se eventuali database sono stati smontati o hanno registrato un errore dopo il verificarsi di un failover. Vengono presi in considerazione solo i database in cui si è verificato un errore a seguito di un failover.

In Exchange 2007 SP1, sono stati apportati miglioramenti delle prestazioni a vantaggio di distribuzioni a disponibilità elevata. Tali miglioramenti includono la riduzione di I/O sui dischi contenenti copie passive dei gruppi di archiviazione in ambienti di replica continua. In Exchange 2007 la struttura dell'architettura di replica continua è stata modificata affinché la cache del database continui per la copia del gruppo di archiviazione delle istanze intermedie dell'attività di riproduzione del registro. La persistenza della cache del database nelle istanze intermedie dell'attività di riproduzione dei registri consente al servizio di replica di Microsoft Exchange di utilizzare le funzioni di memorizzazione del database nella cache di Extensible Storage Engine (ESE), con conseguente riduzione dell'attività di input/output (I/O) del disco che si verifica nei numeri di unità logica (LUN) della copia passiva. Al contrario, in Exchange 2007 RTM, è stata creata una nuova cache del database per ogni batch dell'attività di riproduzione dei registri, che in alcuni casi ha reso un'attività di I/O del disco nei LUN passivi di dimensioni doppie o triple rispetto a quelle dell'I/O nel LUN attivo.

La replica continua di standby (SCR) è una nuova funzionalità che è stata introdotta in Exchange 2007 SP1. La replica continua di standby estende le funzioni di replica continua esistenti e consente nuovi scenari di disponibilità di dati per i server Cassette postali di Exchange 2007. Utilizza la stessa tecnologia di distribuzione e riproduzione dei registri utilizzata dalla replica continua locale e dalla replica continua cluster per fornire ulteriori opzioni e configurazioni di distribuzione.

La replica continua di standby consente di utilizzare la replica continua per replicare i dati dei server Cassette postali da un server Cassette postali autonomo (con o senza replica continua locale) o da un server di cassette postali in cluster a copia singole in un ambiente SCC o CCR.

Il processo di attivazione delle copie dei dati dei server Cassette postali creati e gestiti dalla replica continua di standby è manuale ed è stato appositamente progettato per l'utilizzo nei casi di errori gravi, non al verificarsi di semplici interruzioni dei server, risolvibili attraverso un riavvio o con altri metodi altrettanto veloci. È possibile attivare una destinazione SCR utilizzando la portabilità del database, l'opzione di ripristino del server (Setup /m:RecoverServer) o, se il server Cassette postali è in cluster, l'opzione di ripristino del server di cassette postali in cluster (Setup /RecoverCMS). L'opzione selezionata dipenderà dalla configurazione e dal tipo di errore.

Per ulteriori informazioni sulla replica continua di standby, vedere Replica continua di standby.

Nei seguenti argomenti viene illustrato quando e come utilizzare la replica continua locale come parte integrante di un piano per garantire la disponibilità elevata e la resilienza dei dati:

 
Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2014 Microsoft