Pianificazione della 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-04

La pianificazione della replica continua locale (LCR, Local Continuous Replication) implica la progettazione di un gruppo di archiviazione e di una topologia di database, nonché la garanzia di un supporto adeguato per la soluzione di archiviazione e di un adeguato monitoraggio della replica continua locale.

Requisiti di archiviazione e consigli per la replica continua locale

La replica continua locale comprende alcuni requisiti di archiviazione e consigli, In fase di progettazione della soluzione di archiviazione LCR, includere l'utilizzo di input/output (I/O) aggiuntivo per la replica continua locale in quanto l'ambiente LCR coinvolge aggiornamenti dei registri da parte della copia attiva e letture di registri simili sulla copia passiva. Si consiglia di progettare l'archiviazione in modo che la copia passiva abbia una capacità e capacità di prestazioni simili alla copia attiva. Quando si utilizza la replica continua locale, è consigliabile seguire le procedure consigliate riportate di seguito:

• Utilizzare un singolo database per gruppo di archiviazione   Quando un gruppo di archiviazione è stato abilitato per LCR, può contenere solo un database. Inoltre, se un gruppo di archiviazione esistente dispone di più database, non sarà possibile abilitare LCR per tale gruppo finché attraverso un processo di rimozione non sarà rimasto che un unico database. Questa procedura crea una topologia di archiviazione Microsoft Exchange più gestibile che aumenta la recuperabilità.

• Utilizza i punti di montaggio dei volumi   È possibile utilizzare lettere di unità o punti di montaggio dei volumi per i numeri di unità logica dei dati di Exchange o dischi per definire la posizione di archiviazione dei file di database e dei file di registro delle transazioni. Si consiglia di utilizzare la funzionalità dei punti di montaggio dei volumi del file system NTFS per superare il limite delle 26 lettere di unità esistente per Exchange Server. Utilizzando i punti di montaggio del volume è possibile integrare o montare una partizione di destinazione in una cartella di un altro disco fisico. I punti di montaggio dei volumi sono trasparenti per i programmi, incluso Exchange Server. L'utilizzo di un punto di montaggio del volume semplifica il processo di ripristino quando viene rilevato un danneggiamento nei registri delle transazioni di produzione o nei file di database, consentendo di modificare rapidamente le assegnazioni e i percorsi delle lettere di unità. Per ulteriori informazioni sul ripristino in seguito a danneggiamento nel registro delle transazioni di produzione o nei file di database, vedere Gestione della replica continua locale.

• Esegui partizione dei dati per le prestazioni e il ripristino   In genere, il partizionamento dei dati in più dischi rigidi consente di migliorare le prestazioni e di ridurre la quantità dei dati da ripristinare. In base al tipo di errore, il salvataggio di database e dei file di registro delle transazioni su dischi separati può ridurre in modo significativo la perdita dei dati. Se, ad esempio, i file di database e di registro delle transazioni di Exchange sono archiviati sullo stesso disco rigido fisico e tale disco si danneggia, sarà possibile ripristinare solo i dati esistenti fino al backup più recente. In alternativa, considerare che i file di registro e di database sono stati archiviati su dischi separati. Se si verifica un errore sul disco che contiene i file di database, è possibile recuperare i dati dai file di registro presenti sul disco separato. Per ottimizzare le prestazioni, incrementare la tolleranza di errore e rendere più semplice la risoluzione dei problemi, è necessario partizionare i dati in modo che i seguenti file si trovino su dischi diversi:

  • File del sistema operativo Microsoft Windows

  • File dell'applicazione Exchange Server

  • File di database di Exchange sulla copia attiva

  • File di registro delle transazioni di Exchange sulla copia attiva

  • File di database di Exchange sulla copia passiva

  • File di registro delle transazioni di Exchange sulla copia passiva

  Inoltre, è necessario posizionare le copie passive dei gruppi di archiviazione abilitati a LCR in dischi isolati dalle copie attive di tali gruppi. Inoltre, è necessario accertarsi che i dischi contenenti i file della replica continua locale abbiano le stesse capacità di prestazioni dei dischi che contengono il gruppo di archiviazione di produzione. Questa equivalenza consente alla copia LCR di supportare il carico in caso di failover.

• Verificare di disporre di spazio su disco sufficiente   Le dimensioni dei dischi contenenti i file della replica continua locale devono essere adeguate ai volumi di produzione. L'archiviazione utilizzata per le copie passive deve essere equivalente all'archiviazione utilizzata per le copie attive. Inoltre, è necessario che entrambe le soluzioni di archiviazione dispongano di spazio sufficiente per contenere la dimensione del database esistente, nonché un'eventuale crescita anticipata del database.

• Garantire una larghezza di banda sufficiente e una latenza ridotta quando si utilizza l'archiviazione iSCSI con LCR   Sebbene sia sconsigliata, tale configurazione è supportata per configurare LCR quando si utilizza l'archiviazione Internet SCSI (iSCSI) connessa al server Cassette postali in un collegamento LAN (Local Area Network) o WAN (Wide Area Network). In questa configurazione, entrambe le attività di log shipping e riproduzione dei registi verranno eseguite sulla stessa rete di archiviazione. Questa configurazione è sconsigliata principalmente a causa del traffico di rete generato dal log shipping. Per fare in modo che LCR fornisca il livello di protezione previsto, è fondamentale che il log shipping rimanga aggiornato e che il traffico di rete a esso associato non utilizzi una larghezza di banda tale da creare un'interferenza con il traffico di rete associato all'attività di riproduzione dei registri. Non esiste un metodo per definire la priorità del traffico di replica. Inoltre, è necessario prendere in considerazione alcuni requisiti di archiviazione:

  • Nella versione di produzione (RTM, Release To Manufacturing) di Microsoft Exchange Server 2007, l'archiviazione per le copie passive dei database deve fornire un I/O al secondo (IOPS) che sia almeno doppio o triplo rispetto a quello dell'archiviazione utilizzata per le copie attive dei database.

  • In Microsoft Exchange Server 2007 Service Pack 1 (SP1), l'archiviazione per le copie passive può essere uguale a quella per le copie attive.

Consigli sul processore e sulla memoria per LCR

Per un server Cassette postali abilitato a LCR e con i servizi del ruolo del server Cassette postali di Microsoft Exchange Server 2007 e il servizio di replica di Microsoft Exchange in esecuzione sullo stesso server, è necessario che siano disponibili ulteriori risorse hardware per gestire tale carico aggiuntivo. La maggior parte del consumo di risorse supplementari è associato alle attività di verifica e riproduzione dei file di registro sul server Cassette postali abilitato a LCR. Questo costo di elaborazione aggiuntivo ammonta a circa il 20% (superiore alle indicazioni fornite in Pianificazione delle configurazioni dei processori) e deve essere preso in considerazione nella definizione delle dimensioni dei server Cassette postali abilitati a LCR. Inoltre, il servizio di replica di Microsoft Exchange funzionerà bene su un server LCR in base alle indicazioni fornite per le risorse di memoria. Tuttavia, per garantire che la cache del database Extensible Storage Engine (ESE) mantenga un'efficienza ottimale in LCR, si consiglia di fornire un 1 GB aggiuntivo di RAM fisica ai server Cassette postali di Exchange e ai server con più ruoli (quantità superiore alle indicazioni sulla memoria fornite in Pianificazione delle configurazioni di memoria).

Consigli sulle dimensioni dei database per LCR

La replica continua locale offre molta più flessibilità di ripristino in caso di gravi perdite di dati. La prima misura di difesa contro gli errori di archiviazione gravi o il danneggiamento dei database fisici con replica continua locale è l'attivazione della copia passiva dei dati e non il ripristino dal backup. Ricordare che la replica continua locale garantisce un rapido ripristino dei dati, ma non è una soluzione di backup. LCR rende molto meno importante avere obiettivi temporali di ripristino (RTO) brevi basati sul ripristino da archivio o nastro. Invece di eseguire il ripristino dal nastro, è possibile attivare la copia passiva e i dati saranno disponibili per i client dopo alcuni minuti anziché dopo alcune ore. In questo senso, la replica continua locale può essere considerata un meccanismo di ripristino rapido, alla stessa stregua dei cloni basati su hardware creati utilizzando il servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) in Exchange Server 2003.

Non è raro per gli amministratori dover effettuare operazioni di database non in linea, quali ripristini dovuti a backup non validi (ad esempio nel caso in cui un nastro sia danneggiato o un ripristino fallisca). Sebbene la percentuale dei casi in cui è necessario il ripristino di un database venga notevolmente ridotta, alcune situazioni richiedono comunque questo tipo di intervento. Quando si decidono le dimensioni dei database, è opportuno valutare attentamente il massimo tempo di inattività accettabile.

Poiché la replica continua locale consente di eseguire un backup dalla copia passiva di un gruppo di archiviazione, è possibile estendere il periodo di esecuzione della manutenzione in linea alla copia attiva. In molti casi, è possibile raddoppiare il periodo di esecuzione della manutenzione in linea, il che consente di avere cassette postali e database di dimensioni maggiori.

Pertanto, potrebbe sembrare che la replica continua locale consente di ingrandire i database quanto si vuole senza rischi. Ma non è così. La manutenzione in linea che deve essere eseguita in tempi ragionevoli per ogni database rappresenta ancora un fattore limitante per le dimensioni dei database. Con LCR, la possibilità di dover eseguire il reseeding dei database è un altro fattore limitante. La replica continua locale offre ridondanza dei database per cui, se la copia attiva di un database è andata persa o si è corrotta, il ripristino può essere eseguito rapidamente attivando manualmente la copia passiva del database.

Una volta effettuata l'attuazione, rimane solo una copia del database, la nuova copia attiva. Poiché la copia passiva non esiste più, la ridondanza del database può risultare compromessa. Tuttavia, si dovrebbe comunque disporre del backup. Per abilitare la resilienza, è necessario rimuovere i database con perdita o danneggiamento dei dati, nonché creare una nuova copia passiva del database a partire dalla copia attiva ed eseguirne il reseeding. A seconda delle dimensioni del database, ciò potrebbe richiedere molto tempo. La peggiore delle ipotesi è la perdita o il danneggiamento di tutte le copie attive, caso in cui deve essere eseguito di nuovo il seeding di tutte le copie passive.

Con l'utilizzo della replica continua è possibile aumentare la dimensione massima consentita del database. Per Exchange 2007 si consigliano le seguenti dimensioni massime di database:

• Database ospitati su un server Cassette postali senza replica continua locale: 100 GB

• Database ospitati su un server Cassette postali con replica continua locale: 200 GB

  Importante

  La dimensione massima effettiva per i propri database dovrebbe essere dettata dal contratto di servizio (SLA, service level agreement) in vigore presso la propria organizzazione. Determinando il database più grande di cui è possibile eseguire un backup e un ripristino nei tempi specificati dal contratto di servizio (SLA) dell'organizzazione, vengono determinate anche le dimensioni massime dei database.

Replica continua locale (LCR, Local Continuous Replication) e database delle cartelle pubbliche

La replica continua locale e la replica delle cartelle pubbliche sono due forme di replica ben distinte incorporate in Exchange. Per via delle limitazioni di interoperabilità tra la replica continua e la replica delle cartelle pubbliche, se nell'organizzazione di Exchange vi sono più server Cassette postali con un database di cartelle pubbliche, la replica delle cartelle pubbliche è abilitata e i database delle cartelle pubbliche non devono essere ospitati in un gruppo di archiviazione abilitato per la replica continua locale.

Di seguito sono elencate alcune configurazioni consigliate per l'utilizzo di database delle cartelle pubbliche e della replica continua locale nell'organizzazione di Exchange:

• Se nell'organizzazione di Exchange è presente un server Cassette postali singolo che è un server autonomo, tale server è in grado di ospitare un database delle cartelle pubbliche in un gruppo di archiviazione abilitato per la replica continua locale. In questa configurazione, nell'organizzazione di Exchange è presente un singolo database delle cartelle pubbliche, pertanto la replica delle cartelle pubbliche è disabilitata.

• Se si dispone di più server Cassette postali e soltanto uno di essi contiene un database delle cartelle pubbliche, tale server Cassette postali è in grado di ospitare un database delle cartelle pubbliche in un gruppo di archiviazione abilitato alla replica continua locale. In questa configurazione, nell'organizzazione di Exchange è presente un singolo database delle cartelle pubbliche, pertanto la replica delle cartelle pubbliche è disabilitata.

• Se si esegue la migrazione dei dati delle cartelle pubbliche a un gruppo di archiviazione abilitato per la replica continua locale, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuti di un database delle cartelle pubbliche in un gruppo di archiviazione abilitato per la replica continua locale. Dopo aver creato il database delle cartelle pubbliche in un gruppo di archiviazione abilitato alla replica continua locale, i database delle cartelle pubbliche aggiuntivi dovrebbero essere presenti soltanto fino a quando non è stata completata la replica dei dati delle cartelle pubbliche nel database delle cartelle pubbliche nel gruppo di archiviazione abilitato alla replica continua locale. Una volta completata la replica, tutti i database delle cartelle pubbliche all'esterno del gruppo di archiviazione abilitato alla replica continua locale devono essere rimossi e nell'organizzazione di Exchange non devono essere ospitati altri database delle cartelle pubbliche.

• Se si esegue la migrazione dei dati delle cartelle pubbliche da un gruppo di archiviazione abilitato per la replica continua locale, è possibile utilizzare la replica delle cartelle pubbliche per spostare il contenuto di un database delle cartelle pubbliche da un gruppo di archiviazione abilitato per la replica continua locale. Dopo aver creato il database delle cartelle pubbliche aggiuntivo all'esterno del gruppo di archiviazione abilitato alla replica continua locale, il database delle cartelle pubbliche nel gruppo di archiviazione abilitato alla replica continua locale dovrebbe essere presente solo fino a quando non è stata completata la replica dei dati delle cartelle pubbliche nei database delle cartelle pubbliche aggiuntivi. Una volta completata la replica, tutti i database delle cartelle pubbliche all'interno del gruppo di archiviazione abilitato alla replica continua locale devono essere rimossi e tutti i database delle cartelle pubbliche creati successivamente non devono essere ospitati in gruppi di archiviazione abilitati per la replica continua locale.

Durante un intervallo di tempo in cui nell'organizzazione di Exchange esistono più database delle cartelle pubbliche e uno o più database sono ospitati in un gruppo di archiviazione abilitato alla replica continua locale, se si verifica un errore nel gruppo di archiviazione attivo e abilitato alla replica continua locale ed è necessario attivare la copia passiva del gruppo di archiviazione con un database delle cartelle pubbliche, esso può essere montato soltanto se sono disponibili tutti i registri per il gruppo di archiviazione che ospita il database delle cartelle pubbliche. Se alcuni registri risultano mancanti o non disponibili come risultato di un errore della copia attiva, non sarà possibile attivare la copia passiva del database delle cartelle pubbliche. In questo caso, la copia attiva deve essere portata in linea al fine di evitare una perdita di dati, oppure il database delle cartelle pubbliche deve essere ricreato nella copia attiva del gruppo di archiviazione e il relativo contenuto deve essere recuperato utilizzando la replica delle cartelle pubbliche da uno o più database delle cartelle pubbliche diversi da quello della copia passiva.

Consigli sul monitoraggio per LCR

La replica continua locale è una soluzione per la disponibilità dei dati. Deve essere monitorata in modo proattivo. In Exchange 2007 viene pubblicata un'ampia serie di informazioni sullo stato delle copie LCR. Una volta abilitata la replica continua locale per un gruppo di archiviazione, è possibile utilizzare Exchange Management Console o Exchange Management Shell per visualizzare le impostazioni dello stato e della configurazione per le copie della replica continua locale. Per la procedura dettagliata relativa alla visualizzazione delle informazioni su stato e configurazione, vedere Come visualizzare lo stato di una copia della replica continua locale.

Per il monitoraggio proattivo e automatico, si consiglia di utilizzare Microsoft Operations Manager (MOM) ed Exchange 2007 Management Pack for MOM. Per ulteriori informazioni sul monitoraggio della replica continua locale, vedere Monitoraggio e gestione delle operazioni.

In Exchange 2007 SP1, è anche possibile utilizzare un nuovo cmdlet denominato Test-ReplicationHealth per verificare l'integrità e lo stato dei gruppi di archiviazione abilitati a LCR. Per ulteriori informazioni sul cmdlet Test-ReplicationHealth, vedere Test-ReplicationHealth.

Backup, ripristino e replica continua locale

La replica continua locale consente il log shipping, la riproduzione dei registri e un rapido passaggio manuale a una copia secondaria dei dati. Queste funzionalità consentono di ridurre il tempo di ripristino necessario in seguito a emergenze a livello di dati. La replica continua locale riduce anche il numero di backup necessari per una sufficiente protezione dei dati. Anche se la replica continua locale non elimina la necessità di eseguire backup, riduce la necessità di eseguire backup completi giornalieri. Inoltre, la replica continua locale consente di distribuire i backup del servizio Copia Shadow del volume (VSS, Volume Shadow Copy Service) dal gruppo di archiviazione attivo al gruppo di archiviazione passivo. Ciascun tipo di backup (completo, copia, incrementale e differenziale) può essere eseguito dalle posizioni di copia passiva mantenendo un buon livello di I/O dei dischi per quanto riguarda i LUN della copia attiva in modo da servire i client.

Oltre a ridurre il costo totale di proprietà, la replica continua locale fornisce vantaggi aggiuntivi rispetto alle soluzioni di backup precedenti. La replica continua locale consente di ottenere copie aggiuntive dei propri database di Exchange, con i seguenti vantaggi:

• Riduzione della frequenza dei backup dei database   La copia della replica continua locale è la prima misura di difesa contro un errore del database di produzione. Si dovrebbe verificare un errore sia del gruppo di archiviazione di produzione che della copia del gruppo di archiviazione, prima di dover ricorrere alle copie di backup. Ne consegue che è consigliabile un contratto di livello di servizio (SLA, Service Level Agreement) che preveda tempi lunghi. In caso di uno SLA più lungo, si consiglia di eseguire backup completi settimanali e backup incrementali giornalieri.

• Rapidità del ripristino d'emergenza   In genere, il ripristino avviene in meno di dieci minuti, con perdita dei dati minima o nulla.

• Supporto per quote di cassette postali più grandi   Questo supporto si ottiene come risultato del ripristino rapido, indipendente dalla dimensione del database.

Per ulteriori dettagli e istruzioni specifiche relative al backup e al ripristino, vedere Ripristino d'emergenza.

Backup di Exchange e replica continua locale

I backup basati su Exchange sono supportati dai i gruppi di archiviazione e i database attivi, nonché dalle copie di database passive.

I backup basati su Exchange in questa configurazione possono essere eseguiti utilizzando soluzioni di backup di flusso o VSS. Mentre i backup di flusso possono essere eseguiti solo dalla copia attiva, i backup VSS possono essere eseguiti dalla copia attiva o dalla copia passiva.

Ripristini di Exchange e replica continua locale

I ripristini basati su Exchange possono essere eseguiti utilizzando il flusso o le soluzioni di backup VSS (Volume Shadow Copy Service, Servizio Copia Shadow del volume). È possibile destinare i ripristini alle posizione del database attivo e del file di registro. I ripristini di backup di database basati su Exchange direttamente nel percorso di copia passiva non sono supportati in modalità nativa. È possibile ottenere ripristini in posizioni di copia passiva manualmente con un ripristino a livello di file.

Prima di ripristinare un database da un gruppo di archiviazione configurato per la replica continua locale, si consiglia di sospendere la replica per il gruppo di archiviazione. Al termine del ripristino è possibile riprendere la replica continua locale, che dovrebbe essere sospesa per i database con ripristino in corso.

Dopo il ripristino di un database da un backup in un gruppo di archiviazione in un ambiente di replica continua locale, è necessario sospendere e riprendere la replica continua per il gruppo di archiviazione, utilizzando rispettivamente Suspend-StorageGroupCopy e Resume-StorageGroupCopy. Questo processo è necessario per aggiornare il servizio di replica di Microsoft Exchange con le informazioni di generazione del registro corrette. Se la replica continua non viene sospesa e ripresa, il servizio di replica di Microsoft Exchange disporrà di informazioni di generazione del registro obsolete e interromperà la replica dei file di registro.