Replica continua di standby

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

Ultima modifica dell'argomento: 2008-10-21

La replica continua di standby (SCR, Standby Continuous Replication) è una nuova funzionalità introdotta in Microsoft Exchange Server 2007 Service Pack 1 (SP1). Come indicato dal nome, la replica continua di standby è stata progettata per scenari in cui vengono utilizzati o in cui è consentito l'utilizzo di server di ripristino di standby. La replica continua di standby estende le funzionalità di replica continua esistenti nella versione RTM (Release To Manufacturing) di Exchange Server 2007 e abilita nuovi scenari di disponibilità dei dati per i server Cassette postali dotati di SP1. La replica continua di standby utilizza la stessa tecnologia di log shipping e riesecuzione dei registri della replica continua locale (LCR) e della replica continua cluster (CCR) per offrire ulteriori opzioni e configurazioni di distribuzione.

La replica continua di standby consente di separare l'elevata disponibilità, comprensiva della disponibilità di dati e servizi, dalla resilienza del sito. È possibile, ad esempio, combinare le repliche SCR e CCR per realizzare la replica locale dei gruppi di archiviazione di un centro dati principale, utilizzando CCR per l'elevata disponibilità, e la replica remota di un centro dati secondario o di backup, utilizzando SCR per la resilienza del sito. Il centro dati secondario può contenere un nodo passivo in un cluster di failover nel quale risiedono le destinazioni SCR. Un cluster di questo tipo è denominato cluster di standby perché non contiene alcun server di cassette postali in cluster, ma è possibile predisporlo rapidamente con un server di cassette postali in cluster sostitutivo in uno scenario di ripristino. Se il centro dati principale subisce un guasto o una perdita dati di qualsiasi genere, le destinazioni SCR che risiedono in questo cluster di standby possono essere attivate velocemente.

Origini e destinazioni

Analogamente a quanto avviene con LCR e CCR, per la replica SCR vengono utilizzati i concetti di copia attiva e copia passiva del gruppo di archiviazione, definiti in questo caso origine e destinazione. Inoltre, analogamente a quanto avviene con la replica CCR, anche con la replica SCR è necessario che i percorsi del database e del file di registro dell'origine e della destinazione siano uguali.

Il punto di partenza di SCR è denominato origine ed è rappresentato da un qualsiasi gruppo di archiviazione in una delle posizioni seguenti:

• Server Cassette postali autonomo

• Server di cassette postali in cluster in un ambiente cluster a copia singola (SCC)

• Server di cassette postali in cluster in un ambiente replica continua cluster (CCR)

  Nota

  Non è possibile abilitare i gruppi di archiviazione di ripristino per la replica SCR.

Analogamente a quanto avviene con LCR e CCR, i gruppi di archiviazione abilitati per SCR non possono contenere più di un database. Non è possibile abilitare la replica SCR per un gruppo di archiviazione contenente più database, né aggiungere altri database a un gruppo di archiviazione abilitato per la replica SCR.

Se il computer di origine SCR non è in cluster, può anche ospitare altri ruoli del server, quali Trasporto Hub, Accesso client e Messaggistica unificata.

L'endpoint della replica SCR è denominato destinazione e può essere rappresentata da:

• Un server Cassette postali autonomo per il quale non è stata abilitata la replica LCR per alcun gruppo di archiviazione

• Un cluster autonomo, che è un cluster di failover in cui è installato un ruolo cassette postali in cluster passivo, ma non un server Cassette postali in cluster (ad esempio, un ruolo cassette postali in cluster attivo)

È necessario installare il ruolo del server Cassette postali nei computer di destinazione della replica SCR, anche se non vi risiedono cassette postali di produzione. Il ruolo del server Cassette postali è necessario perché include il servizio di replica di Microsoft Exchange e altri componenti indispensabili per la funzionalità SCR. Se il computer di destinazione SCR non è in cluster, può anche ospitare altri ruoli del server, quali Trasporto Hub, Accesso client e Messaggistica unificata.

SCR è disponibile nella versione Standard Edition di Exchange 2007 SP1. Se come origine SCR viene utilizzato un server Cassette postali in ambiente SCC o CCR, per la creazione di cluster Exchange 2007 è necessario disporre della versione Enterprise Edition di Exchange 2007 SP1. È necessario disporre della versione Enterprise Edition di Exchange 2007 SP1 anche per utilizzare un cluster di standby come destinazione SCR.

Confronto della replica SCR con la replica LCR e la replica CCR

La replica continua di standby (SCR) è simile alla replica continua locale (LCR) e alla replica continua cluster (CCR), ma presenta caratteristiche proprie:

• La replica SCR supporta più destinazioni di replica per gruppo di archiviazione. Le repliche LCR e CCR supportano una sola destinazione di replica per gruppo di archiviazione, ossia la copia passiva.

• La replica SCR include un ritardo incorporato per l'attività di riesecuzione e consente all'amministratore di specificare un ritardo aggiuntivo. Questa caratteristica si rivela utile in numerosi scenari. Ad esempio, in caso di danneggiamento logico del database attivo, il ritardo incorporato e quello aggiuntivo configurato dall'amministratore possono impedire il danneggiamento logico del database di destinazione della replica SCR. Per le repliche LCR e CCR, questi ritardi non sono disponibili.

• La replica SCR viene gestita interamente mediante Exchange Management Shell. Exchange Management Console consente di gestire molti aspetti di LCR e CCR, ma non consente di abilitare o gestire alcun aspetto di SCR.

Attivazione della copia SCR

Il processo per utilizzare un database di destinazione SCR è definito attivazione e il modo in cui il database viene attivato dipende dalla natura dell'errore. Se uno o più database nell'origine SCR sono interessati, è possibile utilizzare la funzione di portabilità del database in Exchange 2007 come parte del processo di attivazione per i database di destinazione SCR. Se tutti i database in un'origine SCR sono interessati oppure se è in corso il ripristino di un intero server o di un server di cassette postali in cluster, è possibile utilizzare le funzionalità di ripristino del server fornite dal programma di installazione (Setup /m:RecoverServer per un server autonomo e Setup /RecoverCMS per un server di cassette postali in cluster) come parte del processo di attivazione.

Per ulteriori informazioni sull'attivazione e il ripristino in un ambiente SCR, vedere Attivazione delle destinazioni della replica continua di standby.

Scenari di distribuzione della replica continua di standby

la replica continua di standby consente la replica continua dei dati del server Cassette postali da un server di cassette postali autonomo o da un server di cassette postali in cluster in un ambiente SCC o CCR. Nelle figure seguenti vengono illustrate alcune delle possibili opzioni di configurazione della replica continua di standby.

Utilizzo di SCR per la replica di un gruppo di archiviazione da un server Cassette postali autonomo a un altro server Cassette postali

Nella figura precedente viene illustrato l'utilizzo di SCR per la replica di più gruppi di archiviazione da un server Cassette postali a un altro. In questo esempio, i server di cassette postali non sono in cluster e si comportano entrambi come origini e destinazioni SCR. In questo esempio, ogni server si trova in un centro dati e in un sito Active Directory diverso. In base alla natura dell'errore, è possibile eseguire il ripristino di un gruppo di archiviazione in ciascun server mediante la portabilità del database o con l'opzione di installazione /RecoverServer.

Utilizzo di CCR per la replica locale dei gruppi di archiviazione e di SCR per la replica di un gruppo di archiviazione in una posizione remota

Nella figura precedente viene illustrato un modello di replica da CCR a SCR di tipo "uno a uno". In questo esempio, EXCLUS1 è un server di cassette postali in cluster in ambiente CCR situato nel sito Active Directory REDMOND. EXCLUS1DR è un cluster di standby situato nel sito Active Directory QUINCY. In questo caso, è possibile eseguire il ripristino di tutti i gruppi di archiviazione della destinazione SCR mediante il comando Setup /RecoverCMS. Se non è necessario ripristinare tutti i gruppi di archiviazione, per ripristinare uno o più gruppi è possibile utilizzare la portabilità del database.

Utilizzo di CCR per la replica locale dei gruppi di archiviazione e di SCR per la replica dei gruppi di archiviazione in più posizioni remote

Nella figura precedente viene illustrato un modello di replica da CCR a SCR di tipo "uno a molti". I computer sulla sinistra rappresentano i due nodi fisici CCR del medesimo centro dati. I computer sulla destra rappresentano le due destinazioni SCR di un secondo centro dati. In questo esempio, un singolo gruppo di archiviazione viene replicato in più destinazioni SCR di due diversi computer. È possibile ripristinare il gruppo di archiviazione in una delle destinazioni SCR con uno dei due metodi seguenti:

• Per il ripristino dei gruppi di archiviazione solo da una singola origine CCR, è possibile utilizzare il parametro /RecoverCMS.

• Per il ripristino dei gruppi di archiviazione da più origini CCR, è possibile utilizzare la portabilità del database.

Utilizzo di più destinazioni SCR remote per un cluster SCC

Nella figura precedente viene illustrato un modello da SCC a SCR di tipo "uno a molti". I computer sulla sinistra rappresentano i due nodi SCC fisici di un singolo centro dati. I computer sulla destra rappresentano le destinazioni SCR di un centro dati distinto. In questo esempio, un singolo gruppo di archiviazione viene replicato in due destinazioni autonome di un secondo centro dati. Per ottenere il ripristino di questo gruppo di archiviazione della destinazione SCR utilizzare l'opzione Setup /RecoverCMS.

Aggiornamenti dei cmdlet per la replica continua di standby

La replica continua di standby viene gestita mediante Exchange Management Shell. SP1 include un nuovo parametro denominato StandbyMachine per numerosi cmdlet di Exchange Management Shell relativi alla gestione e alla configurazione della replica continua. In particolare, i seguenti cmdlet includono il supporto per la replica continua di standby e il parametro StandbyMachine:

• Suspend-StorageGroupCopy

• Resume-StorageGroupCopy

• Update-StorageGroupCopy

• Restore-StorageGroupCopy

• Get-StorageGroup

• Get-StorageGroupCopyStatus

Oltre ai precedenti aggiornamenti dei cmdlet, sono stati aggiornati per il supporto della replica SCR anche i cmdlet New-StorageGroup e Enable-StorageGroupCopy. In Exchange 2007 SP1, New-StorageGroup consente di creare un nuovo gruppo di archiviazione abilitato per la replica continua di standby e Enable-StorageGroupCopy consente di abilitare la replica continua di standby per un gruppo di archiviazione esistente. Questi cmdlet includono i seguenti parametri aggiornati:

• -StandbyMachine   Questo parametro consente di specificare il nome del computer della destinazione SCR.

• -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. L'impostazione predefinita è 24 ore (1.0:0:0). 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 riesecuzione dei registri al di sopra del ritardo predefinito relativo a 50 file di registro. Dopo aver impostato il valore di questo parametro, non è possibile modificarlo senza disabilitare e abilitare la replica continua di standby.

• -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 abilitare la replica continua di standby.

Oltre al ritardo di replica configurato dall'amministratore e specificato mediante il parametro ReplayLagTime, Exchange impedisce anche la riesecuzione in una destinazione SCR di un numero stabilito di file di registro, indipendentemente dal valore di ReplayLagTime, in base alla formula 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. Grazie al 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.

Aggiornamenti dell'installazione per la replica continua di standby

La replica continua di standby è ideata prevalentemente per ovviare a danni molto rilevanti, ad esempio a carico di un intero sito. Questi tipi di scenario implicano attività manuali, quali l'attivazione di un centro dati di backup, nonché il ripristino del centro dati principale.

Considerando a titolo esemplificativo la figura Utilizzo di più destinazioni SCR remote per un cluster SCC illustrata in precedenza, è possibile valutare quanto accade in caso di errore del centro dati principale, ossia il sito in cui si trova il cluster SCC, e di attivazione di un secondo centro dati in sostituzione di quello principale. Quando viene attivato il centro dati secondario, la configurazione del centro dati originale rimane in Active Directory e tale configurazione viene utilizzata dal secondo centro dati dopo l'attivazione. Anche la configurazione del server di cassette postali in cluster di SCC rimane nel cluster originale. Per riportare in linea il cluster originale, è necessario rimuovere la configurazione del server di cassette postali in cluster dai nodi cluster senza modificare la configurazione del server Cassette postali in Active Directory, utilizzata dal centro dati secondario.

Al fine di agevolare questo e altri scenari di resilienza del sito, l'installazione di Exchange 2007 SP1 è stata modificata. L'installazione, in particolare, include una nuova opzione della riga di comando denominata /ClearLocalCMS, utilizzata per cancellare le informazioni di configurazione del server di cassette postali in cluster dei nodi cluster originali senza modificare le informazioni archiviate in Active Directory. Ad esempio, per cancellare i dati di configurazione locali di un server di cassette postali in cluster denominato EXCLUS1, è necessario eseguire localmente il seguente comando in ciascun nodo del cluster originale da cui si desidera rimuovere un server di cassette postali in cluster:

Setup /ClearLocalCMS

Quando si utilizza l'opzione /ClearLocalCMS, è necessario tenere presenti i requisiti e le restrizioni seguenti:

• È possibile utilizzare questa opzione solo in modalità locale e non remota.

• È possibile utilizzare questa opzione solo sui nodi che ospitano un server cassette postali in cluster (ad esempio, i nodi attivi) ma non sui nodi passivi.

• Utilizzando questa opzione non vengono rimossi i file di programma di Microsoft Exchange e non vengono aggiornate le informazioni di configurazione di Active Directory.

• È possibile utilizzare questa opzione solo quando il server di cassette postali in cluster non è in linea e il nodo locale non è presente nell'elenco RedundantMachines del server di cassette postali in cluster locale.

• È necessario che l'account utilizzato per cancellare la configurazione del server di cassette postali in cluster locale disponga delle autorizzazioni di amministratore di Exchange Server per il server di cassette postali in cluster.

• Se nei nodi del cluster viene eseguito Windows Server 2008, dopo aver eseguito Setup /ClearLocalCMS, l'oggetto computer virtuale verrà disattivato. È necessario abilitare nuovamente l'oggetto computer virtuale.

Ulteriori informazioni

Per ulteriori informazioni sulla pianificazione per la replica continua di standby, vedere Pianificazione di una replica continua di standby. Per ulteriori informazioni sulla gestione della replica continua di standby, inclusa la descrizione dettagliata delle procedure di abilitazione o di disabilitazione della replica per un gruppo di archiviazione, vedere Gestione della replica continua di standby.