Replica continua cluster

  • Articolo

 

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

Ultima modifica dell'argomento: 2008-03-21

La replica continua cluster (CCR, cluster continuous replication) è una funzione di Microsoft Exchange Server 2007 a elevata disponibilità, che combina il log shipping asincrono e la tecnologia di riproduzione incorporate in Exchange 2007 con le funzioni di failover e gestione del Servizio cluster.

La replica continua cluster è progettata per garantire una disponibilità elevata dei server Cassette postali Exchange 2007 offrendo una soluzione che:

  • Non presenta alcun singolo punto di errore.

  • Non presenta requisiti hardware particolari.

  • Non presenta requisiti di archiviazione condivisa.

  • Può essere distribuita in configurazioni di uno o due centri dati.

  • Può ridurre la frequenza dei backup completi, il volume totale dei dati di backup e il contratto di servizio per il recupero dal primo errore.

La replica continua cluster utilizza la funzionalità di recupero degli errori del database di Exchange 2007 per abilitare l'aggiornamento continuo e asincrono di una seconda copia di un database con le modifiche apportate alla copia attiva dello stesso. Durante l'installazione del nodo passivo in un ambiente con replica continua cluster, ciascun gruppo di archiviazione con il relativo database viene copiato dal nodo attivo a quello passivo. Questa operazione, denominata seeding, offre un database di riferimento per la replica. Una volta eseguito il seeding iniziale, vengono eseguite continuamente operazioni di copia e riproduzione del registro.

In un ambiente con replica continua cluster, le funzionalità di replica sono integrate nel Servizio cluster per offrire una soluzione a elevata disponibilità. Oltre a garantire la disponibilità di servizi e dati, la replica continua cluster consente di gestire le interruzioni pianificate. Quando è necessario installare gli aggiornamenti o eseguire interventi di manutenzione, l'amministratore può spostare manualmente un server di cassette postali in cluster (denominato Server virtuale di Exchange nelle versioni precedenti di Exchange Server) su un nodo passivo. Al termine dell'operazione di spostamento, l'amministratore può eseguire gli interventi necessari.

L'operazione di spostamento viene eseguita utilizzando il cmdlet Move-ClusteredMailboxServer in Exchange Management Shell. Microsoft Exchange Server 2007 Service Pack 1 (SP1) include anche una nuova procedura guidata per la gestione del server di cassette postali in cluster in Exchange Management Console che consente di spostare i server di cassette postali in cluster. La logica utilizzata da queste attività consente le operazioni necessarie a garantire che i dati delle cassette postali non vadano persi durante lo spostamento. Prima dello spostamento, vengono eseguite anche opportune verifiche per garantire che la replica sul nodo passivo sia pronta per una rapida attivazione.

Di seguito sono riepilogate le informazioni essenziali sulla replica continua cluster:

  • La replica continua è asincrona   I registri non vengono copiati finché non risultano chiusi e non utilizzati dal server Cassette postali. Ciò significa che il nodo passivo in genere non dispone di una copia di tutti i file di registro presenti sul nodo attivo. L'unica eccezione è rappresentata dall'avvio di un'interruzione pianificata del nodo attivo da parte dell'amministratore per installare un aggiornamento o eseguire altri interventi di manutenzione.

  • Con la replica continua il carico di input/output (I/O) e della CPU sul nodo attivo durante il normale funzionamento è quasi nullo   La replica si serve del nodo passivo per copiare e riprodurre i registri. I registri sono disponibili dal nodo passivo tramite una condivisione file protetta.

  • Le modifiche del nodo passivo e del nodo attivo per tutta la durata del cluster sono automatiche   Ad esempio, in seguito a un failover, la designazione di nodo passivo e nodo attivo viene invertita. Ciò significa che anche la "direzione" della replica viene invertita senza che sia richiesto alcun intervento da parte dell'amministratore. L'inversione viene, difatti, gestita automaticamente dal sistema.

  • Failover e interruzioni pianificate sono simmetrici per funzionamento e prestazioni   Ad esempio, il failover dal Nodo 1 al Nodo 2 richiede lo stesso tempo del failover dal Nodo 2 al Nodo 1. In genere, occorrono meno di due minuti. Su server di grandi dimensioni, tuttavia, le interruzioni pianificate richiedono in genere meno di quattro minuti. La differenza tra failover e interruzioni pianificate dipende dal tempo necessario per eseguire l'arresto del nodo attivo per l'interruzione pianificata. Tale differenza di prestazioni potrebbe essere ridotta in un Service Pack futuro.

  • Sono supportati i backup del servizio Copia Shadow del volume (VSS) sul nodo passivo   In questo modo, gli amministratori possono distribuire i backup dal nodo attivo e ampliare l'intervallo di backup. Inoltre, nelle configurazioni di dimensioni maggiori non sarà necessario, in base ai requisiti sulle prestazioni, disporre di supporto VSS hardware per utilizzare i backup VSS. Il carico di lavoro sul nodo passivo consiste principalmente nelle operazioni di copia e riproduzione dei registri, le quali non sono vincolate in alcun modo all'esecuzione in tempo reale come avviene, invece, per il server di cassette postali in cluster sul nodo attivo. Ad esempio, il nodo attivo deve rispondere tempestivamente alle richieste dei client. È possibile utilizzare un intervallo di backup più ampio, in quanto il nodo passivo non ha vincoli di risposta in tempo reale e pertanto consente di utilizzare database e cassette postali di dimensioni maggiori.

  • Il volume totale di dati presenti sui supporti di backup è ridotto   La copia passiva della replica continua cluster offre il primo livello di difesa contro la perdita e il danneggiamento dei dati. Pertanto, perché sia necessario ricorrere ai backup, si devono verificare ben due errori. Il recupero dal primo errore può richiedere un contratto di servizio relativamente breve in quanto non è necessario il ripristino. Il recupero dal secondo errore, invece, può richiedere un contratto di servizio molto più lungo. Di conseguenza, è possibile eseguire backup completi ogni settimana con una strategia di backup incrementale giornaliero. In questo modo si riduce il volume totale dei dati che devono essere copiati sui supporti di backup.

  • La replica continua cluster (CCR, Continuous Cluster Replication) può essere combinata con la replica continua di standby (SCR, Standby Continuous Replication)   La CCR può essere combinata con la SCR per replicare gruppi di archiviazione in un centro dati primario (utilizzando CCR per assicurare l'elevata disponibilità) e in remoto in un centro dati secondario o di backup (utilizzando la 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.

Architettura principale della replica continua cluster

La replica continua cluster combina gli elementi seguenti:

  • Funzioni di failover e virtualizzazione fornite dai cluster di failover di Microsoft

  • Un modello di quorum di cluster di failover basato sulla maggioranza che utilizza una condivisione file come witness per l'attività di cluster

  • Funzioni di replica e riproduzione del registro delle transazioni in Exchange 2007

  • Funzione della coda di messaggi del server Trasporto Hub, denominata dumpster del trasporto

Cluster di failover Windows

Come illustrato nella seguente figura, in Exchange 2007 CCR utilizza due computer (denominati nodi) riuniti in un unico cluster di failover che esegue Windows Server 2003 Service Pack 2 o Windows Server 2008. I nodi nel cluster di failover ospitano un singolo server di cassette postali in cluster. Un nodo in cui è in esecuzione un server di cassette postali in cluster è un nodo attivo, mentre un nodo in cui non è in esecuzione un server di cassette postali in cluster e che viene utilizzato come destinazione per la replica, è un nodo passivo. Come risultato dei periodi di inattività pianificati e non pianificati, lo stato attivo o passivo del nodo cambierà più volte durante il ciclo di vita del cluster di failover.

Distribuzione di base di CCR

Architettura di replica continua cluster

Il cluster di failover viene creato utilizzando il servizio Cluster e uno specifico tipo di modello di quorum del cluster:

Witness di condivisione file

Entrambi i modelli di quorum precedenti utilizzano una condivisione file su un terzo computer come witness. In questi modelli di quorum viene utilizzata una condivisione di file su un terzo computer per evitare che si verifichi una partizione di rete all'interno del cluster, nota anche come split brain syndrome. La split brain syndrome si verifica quando tutte le reti designate per le comunicazioni cluster interne si arrestano e i nodi non possono ricevere i segnali heartbeat. La split brain syndrome viene evitata richiedendo sempre la disponibilità e l'interazione della maggioranza dei due nodi e della funzione di condivisione di file affinché il server di cassette postali in cluster sia operativo. Quando la maggioranza dei computer comunica, il cluster raggiunge il cosiddetto quorum. La condivisione di file per il witness di condivisione file può essere ospitata su qualsiasi computer su cui è in esecuzione Windows Server. Non è richiesto che la versione del sistema operativo Windows Server che ospita la condivisione di file corrisponda al sistema operativo dell'ambiente CCR. Tuttavia si consiglia di utilizzare un server Trasporto Hub nel sito del servizio directory di Active Directory contenente il server di cassette postali in cluster per ospitare la condivisione di file, in quanto consente all'amministratore del sistema di messaggistica di mantenere il controllo sulla condivisione di file.

Nota

La condivisione file utilizzata dal witness di condivisione file share non può essere ospitata in un ambiente di file system distribuito (DFS, Distributed File System).

Il witness di condivisione file utilizza la condivisione di file su un computer al di fuori del cluster perché agisca in qualità di testimone delle attività dei due nodi che formano il cluster. Il witness viene utilizzato dai due nodi per verificare quale nodo sta controllando il cluster. Il taccuino elettronico è necessario solo quando i due nodi non possono comunicare tra loro. Consideriamo un server di cassette postali in cluster a due nodi, formato da un Nodo1 e da un Nodo2. In questo caso, il Nodo1 è il nodo che può prendere il controllo del taccuino elettronico e pertanto è in grado di controllare il cluster e di visualizzare il server di cassette postali in cluster. Se il Nodo2 è operativo, ma non è in grado di comunicare con il Nodo1, il Nodo2 tenterà di prendere il controllo del taccuino elettronico senza riuscirci. L'incapacità del Nodo2 di controllare il taccuino elettronico indica che non sarà in grado di visualizzare un server di cassette postali in cluster.

Quando i due nodi sono in grado di comunicare e interagire, il taccuino elettronico non è necessario e può anche rimanere fuori rete. Tuttavia, se non è disponibile il witness di condivisione file, un problema successivo di uno dei due nodi impedirà al server di cassette postali in cluster di essere in linea.

La condivisione di file non mantiene altro stato che quello descritto in precedenza. Pertanto, tutte le informazioni riguardanti la configurazione del cluster vengono scambiate direttamente tra i due nodi stessi. È importante capirlo, perché ciò significa che se il Nodo1 è disponibile e il Nodo2 non lo è, il Nodo2 non può diventare disponibile fino a quando comunica con il Nodo1, anche se è in grado di comunicare con il witness di condivisione file.

Il supporto del witness di condivisione file fornisce una verifica di accesso periodico alla funzione stessa. Se la verifica di accesso fallisce, viene generato un evento. L'evento può essere rilevato, raccolto e segnalato dal sistema di monitoraggio. Ciò consente al personale operativo di correggere il problema, prima che causi un'interruzione provocata da un secondo problema concomitante.

È possibile accedere alla condivisione di file nei seguenti casi:

  • Quando si verifica un nodo nel cluster ed è disponibile solo un nodo del cluster.

  • Quando un problema di connessione di rete non consente a un nodo precedentemente raggiungibile di comunicare con il cluster.

  • Quando un nodo esce da un cluster.

  • Periodicamente a fini di convalida. La frequenza è configurabile.

Per queste ragioni il carico sulla condivisione file è leggero. Come risultato, un singolo server è in grado di fornire la condivisione per più ambienti di replica continua cluster. Tuttavia, ciascun ambiente di replica continua cluster deve disporre di una propria condivisione file e cartelle su questo server.

Considerazioni sul il witness di condivisione file

CCR è un ambiente a due nodi che utilizza un quorum MNS con il witness di condivisione file o un quorum di tipo Maggioranza dei nodi e delle condivisioni file anziché un terzo nodo (o più nodi) nel cluster richiesto nei cluster MNS tradizionali. Un ambiente CCR dislocato geograficamente è una distribuzione con due centri dati in cui il nodo attivo viene distribuito nel centro dati primario, mentre quello passivo nel centro dati secondario. Pertanto, in un ambiente CCR dislocato geograficamente, è possibile posizionare la condivisione file in due modi: nel centro dati primario oppure in un terzo centro dati.

La prima opzione prevede la configurazione della condivisione file su un server Trasporto Hub nel centro dati primario. Un server Trasporto Hub risulta consigliato in quanto consente a un amministratore della messaggistica di gestire e monitorare le interruzioni della condivisione file. La nostra esperienza e i suggerimenti dei clienti rivelano che i tipi più comuni di interruzioni del servizio di rete si verificano nelle topologie WAN (Wide Area Network). Posizionare la condivisione file in un centro dati primario è utile in quanto impedisce le interruzioni del servizio dovute a errori di rete tra i due centri dati. Se si utilizza questa configurazione, non si verificherà alcun failover automatico nel caso di un'interruzione del centro dati primario. Tuttavia, garantisce che non vi siano ripercussioni sulla maggioranza nel cluster di failover nel caso di un errore di rete tra il centro dati primario e quello secondario.

La seconda opzione prevede la configurazione della condivisione file su un ruolo del server gestito in un terzo sito fisico. Un ruolo del server gestito è un server supportato e gestito in modo simile agli altri server di importanza critica per il recapito del servizio di messaggistica. Un esempio di ruolo del server gestito è un server Trasporto Hub nel centro dati primario. Questo terzo sito fisico potrebbe essere una filiale o un terzo centro dati. Un requisito di questa configurazione è la necessità che il terzo sito abbia un'infrastruttura di rete per il centro dati primario e per quello secondario con latenza ridotta ed elevata disponibilità.

Replica e riproduzione del registro delle transazioni

La replica e la riproduzione del registro delle transazioni vengono utilizzate per copiare i dati modificati e aggiornare il database della copia passiva. La replica utilizza la cronologia delle modifiche generata dal motore ESE (Extensible Storage Engine). La cronologia delle modifiche è rappresentata come una sequenza di file di registro di dimensioni fisse (1 MB). La funzionalità di replica consente di copiare i file di registro nel nodo passivo quando ciascun file di registro viene generato. Il meccanismo di replica è asincrono rispetto al database in linea. Dopo essere stati copiati nel nodo passivo, i registri vengono verificati per riscontrare eventuali danneggiamenti e poi riprodotti nella copia del database memorizzata nel nodo passivo. Il processo di riproduzione apporta le modifiche descritte nel registro delle modifiche nel database del nodo passivo, in modo tale che il database del nodo passivo corrisponda al database di produzione con un lieve tempo di attesa.

Poiché i dati vengono replicati tra i nodi, il server di cassette postali in cluster può operare su uno qualsiasi dei due nodi del cluster. Questa capacità garantisce una maggiore disponibilità poiché le interruzioni pianificate e gli errori di un singolo nodo non causano interruzioni estese nel server di cassette postali in cluster. Le interruzioni di servizio dell'archiviazione su un nodo inoltre non avranno effetto sulla disponibilità dell'altro nodo e del server di cassette postali in cluster. Se la condivisione file è ancora disponibile e può comunicare con il nodo passivo, un'interruzione del nodo attivo provoca lo spostamento del server di cassette postali in cluster su un nodo rimanente, perché esso possa continuare a funzionare.

In un ambiente di replica continua cluster, la cartella dei file di registro delle transazioni del nodo attivo viene condivisa utilizzando la condivisione standard dei file di Windows. L'identificatore univoco globale (GUID, Globally Unique Identifier) oggetto del gruppo di archiviazione viene utilizzato come nome della condivisione e alla fine della condivisione viene aggiunto il simbolo del dollaro ($). Il servizio Replica di Microsoft Exchange presente sul nodo passivo si connette alla condivisione del nodo attivo e copia, o estrae, i file di registro utilizzando il protocollo SMB (Server Message Block). Il nodo passivo verifica quindi il file di registro e lo riproduce nella copia del database presente sul nodo passivo.

Nota

Il traffico SMB relativo alla replica del file di registro della transazione non è crittografato. Se necessario, per crittografare questo traffico si può utilizzare il protocollo IPsec (Internet Protocol Security). Il protocollo SMB viene utilizzato solo per la replica dei file di registro della transazione. Se si utilizza la comunicazione non crittografata tramite l'API di backup ESE, si verifica un reseeding della copia passiva. Se necessario, è possibile utilizzare IPSec per crittografare i dati.

Replica continua sulle reti di cluster ridondanti

Nella versione di produzione (RTM, Release To Manufacturing) di Microsoft Exchange Server 2007, tutte le operazioni di copia e seeding del file di registro delle transazioni in un ambiente CCR vengono eseguite sulla rete pubblica. Questa configurazione presenta i seguenti limiti:

  • Quando il nodo passivo non è disponibile per diverse ore, è possibile che venga compilato un numero significativo di registri da trasferire. Lo spostamento di tali registri dovrebbe avvenire nel modo più veloce possibile quando il nodo passivo è disponibile. Attraverso la copia dei registri sulla rete pubblica, lo spostamento dei registri diventa correlato al traffico client. In effetti, incide sul traffico client e rallenta la risincronizzazione.

  • In caso di errore della rete pubblica, il failover avverrà con perdita di dati, anche se i dati dei registri sono disponibili.

  • L'utilizzo di una rete isolata per la comunicazione dei registri consente di fornire protezione per i dati dei messaggi senza dover utilizzare la crittografia con corrispondente riduzione delle prestazioni.

  • In alcune circostanze, potrebbero verificarsi "tempeste di registri". In questi casi, il sistema deve sostenere un insolito carico di repliche. Ciò potrebbe causare problemi per i client se i dati dei registri devono essere comunicati sulla stessa rete utilizzata per la comunicazione con i client.

Non tutti questi problemi si verificheranno con la stessa frequenza. Tuttavia, è praticamente certo che il primo problema si verifica a intervalli di qualche mese in quanto i nodi passivi vengono portati non in linea per le normali attività di manutenzione.

Exchange 2007 SP1 riduce al minimo gli effetti dei problemi menzionati, consentendo all'amministratore di creare una o più reti miste nel cluster (una rete mista è una rete di cluster che supporta sia il traffico heartbeat cluster interno che il traffico client) per il log shipping. Exchange 2007 SP1 consente anche all'amministratore di specificare una rete mista da utilizzare per il seeding.

Nota

È necessario che le reti di cluster utilizzate per il seeding e il log shipping vengano configurate come reti miste. Una rete mista è una rete di cluster configurata sia per il traffico di accesso client che cluster (heartbeat). Inoltre, sulla scheda di rete che viene configurata con un nome host di replica continua, l'amministratore deve deselezionare la casella di controllo Registra nel DNS gli indirizzi di questa connessione nella finestra di dialogo delle proprietà TCP/IP avanzate e utilizzare voci DNS statiche o file degli host in ciascun nodo per consentire la risoluzione dei nomi per i nuovi nomi host creati da ciascun nodo. Il server DNS utilizzato dalla scheda di rete può trovarsi sulla rete pubblica o su quella privata; tuttavia, indipendentemente dalla sua posizione, è necessario che sia accessibile da entrambi i nodi per consentire la risoluzione del nome host. Inoltre, in Windows Server 2008 le schede di rete utilizzate per il log shipping o il seeding richiedono che sia abilitato NetBIOS.

È possibile configurare il supporto per la copia dei file di registro utilizzando un nuovo cmdlet denominato Enable-ContinuousReplicationHostName. In modo analogo, è possibile disattivare questa funzione utilizzando il cmdlet Disable-ContinuousReplicationHostName.

In presenza di un server di cassette postali in cluster in un ambiente CCR, un amministratore può eseguireEnable-ContinuousReplicationHostName su entrambi i nodi del cluster e specificare nomi host e indirizzi IP aggiuntivi, che verranno quindi creati nei gruppi di cluster dedicati e associati a ogni nodo. Dopo aver eseguito questa attività, il servizio Replica di Microsoft Exchange inizierà a utilizzare la rete appena creata per la copia dei registri subito dopo la riuscita della configurazione e aver verificato che la nuova rete è operativa. Se le nuove reti create sono numerose, il servizio Replica di Microsoft Exchange ne selezionerà una casualmente. Se la rete specifica diventa non disponibile, il servizio Replica di Microsoft Exchange inizierà automaticamente a utilizzare altre reti di replica o, se non vi sono reti disponibili, inizierà a utilizzare la rete pubblica per il log shipping entro 5 minuti. (L'individuazione della rete del servizio Replica di Microsoft Exchange avviene ogni 5 minuti.) Quando la rete di replica diventa nuovamente disponibile, il servizio Replica di Microsoft Exchange riprenderà a utilizzarla per il log shipping.

Per ulteriori informazioni su questi cmdlet, vedere Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName.

Il supporto per il seeding su una rete di cluster ridondante viene configurato utilizzando il cmdlet Update-StorageGroupCopy, aggiornato in Exchange 2007 SP1 per includere un nuovo parametro denominato DataHostNames. Questo paramero viene utilizzato per specificare quale rete di cluster deve essere utilizzata per il seeding. Per ulteriori informazioni sulle modifiche al cmdlet Update-StorageGroupCopy in Exchange 2007 SP1, vedere Update-StorageGroupCopy.

Dopo aver creato una rete di cluster per la replica continua, è possibile utilizzare il cmdlet Get-ClusteredMailboxServerStatus per visualizzare informazioni aggiornate sulle reti di cluster abilitate per l'attività di replica continua. I dettagli del nuovo output includono:

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Per ulteriori informazioni sulle modifiche al cmdlet Get-ClusteredMailboxServerStatus in Exchange 2007 SP1, vedere Get-ClusteredMailboxServerStatus.

Dumpster del trasporto

L'insieme dei dati perduti durante un ripristino automatico in seguito viene recuperato automaticamente tramite una funzione del server Trasporto Hub denominata dumpster del trasporto. Il dumpster del trasporto per un database specifico può risiedere in tutti i server Trasporto Hub presenti nel sito Active Directory contenente il server di cassette postali in cluster. Quando un messaggio passa attraverso i server Trasporto Hub verso un server di cassette postali in cluster in un ambiente di replica continua cluster, viene conservata una copia del messaggio nella coda di trasporto (mail.que) fino a quando non è stata passata la finestra di replica. Il dumpster del trasporto è un componente richiesto per le distribuzioni CCR. Il dumpster del trasporto trae vantaggio dalla ridondanza dell'ambiente per recuperare alcuni 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. Quando si verifica un failover con perdita di dati, la replica continua cluster sul server di cassette postali in cluster richiede automaticamente a ogni server Trasporto Hub del sito di Active Directory di inviare nuovamente la posta elettronica a partire dalla coda del dumpster del trasporto. L'archivio informazioni elimina automaticamente i duplicati e inoltra nuovamente la posta andata perduta.

Il dumpster del trasporto viene abilitato per CCR e, in Exchange 2007 SP1, anche per la replica continua locale (LCR). Il dumpster del trasporto non è abilitato per la replica continua di standby (SCR, Standby Continuous Replication) o per i cluster a copia singola (SCC, Single Copy Cluster). Per CCR, la condizione necessaria affinché un messaggio di posta elettronica venga mantenuto in un dumpster del trasporto è che abbia almeno uno dei destinatari la cui cassetta postale si trova su un server di cassette postali in cluster in un ambiente CCR o, in SP1, in un database di cassette postali abilitato per LCR.

Il dumpster del trasporto è progettato per favorire la protezione da perdite di dati, fornendo all'amministratore la possibilità di configurare la replica continua cluster in modo tale che il server di cassette postali in cluster entri automaticamente in linea su un altro nodo, con una perdita di dati limitata. In questo caso, il sistema inoltra di nuovo automaticamente tutti i messaggi di posta elettronica inviati recentemente a utenti del server, traendo vantaggio dal dumpster del trasporto in cui tali messaggi risultano ancora archiviati. Nella maggior parte dei casi, ciò è sufficiente per prevenire la perdita di dati. In un ambiente di replica continua cluster, la richiesta del nuovo invio dal dumpster del trasporto su tutti i server Trasporto Hub nel sito viene eseguita automaticamente. In Exchange 2007 RTM, l'intervallo tra i tentativi è hardcoded e impostato su sette giorni. In Exchange 2007 SP1, l'intervallo tra i tentativi è uguale al valore impostato per MaxDumpsterTime. In un ambiente di replica continua locale, la richiesta del nuovo invio da tutti i server Trasporto Hub nel sito si verifica come parte dell'attività Restore-StorageGroupCopy.

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

  • Cartelle bozze di client di 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.

Distribuzione di una replica continua cluster

La distribuzione di una replica continua cluster è simile alla distribuzione di un server Exchange autonomo ed è anche simile a una distribuzione di cluster a copia singola. Per ulteriori informazioni sui cluster a copia singola, vedere Cluster a copia singola. Tuttavia, quando si esegue la distribuzione di una replica continua cluster occorre tenere presenti alcune differenze significative. Prima di progettare e distribuire una replica continua cluster nel proprio ambiente, si consiglia di rivedere i seguenti argomenti:

Quando si è pronti per la distribuzione di CCR, è possibile avviare il processo eseguendo i passaggi delle varie fasi di installazione descritte nei seguenti argomenti:

Miglioramenti apportati alla replica continua cluster (CCR, Continuous Cluster Replication) in Exchange 2007 SP1

Exchange 2007 SP1 include diversi miglioramenti per CCR, inclusi elementi aggiuntivi dell'interfaccia utente di Exchange Management Console e stato, monitoraggio e prestazioni migliorati.

Miglioramenti di Exchange Management Console

In Exchange 2007 SP1 sono stati aggiuntivi diversi nuovi elementi dell'interfaccia utente che ottimizzando l'esperienza di gestione per funzioni a elevata disponibilità, tra cui CCR. 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.

  • 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.

Miglioramenti dello stato e del monitoraggio

Exchange 2007 SP1 introduce anche diverse modifiche progettate per migliorare la gestibilità di Exchange 2007. Tali modifiche si basano sulle funzioni di segnalazione cluster in Exchange 2007 RTM e includono la funzionalità aggiuntiva progettata 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.

Miglioramenti del cmdlet Get-StorageGroupCopyStatus

In Exchange 2007 RTM esistono numerose condizioni in cui lo stato segnalato da Get-StorageGroupCopyStatus e i contatori delle prestazioni della replica continua sono imprecisi 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 per gli ambienti CCR:

  • 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 riporta un valore di SummaryCopyStatus pari a Sincronizzazione se non ha completato un nuovo seeding 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.

Cmdlet Test-ReplicationHealth

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 di 3-5 registri.

  • Errore   Lunghezza della coda di 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.

Miglioramenti delle prestazioni

In Exchange 2007 SP1, sono stati apportati miglioramenti delle prestazioni a vantaggio di distribuzioni a elevata disponibilità. Tali miglioramenti includono:

  • Riduzioni dell'I/O sui dischi contenenti copie dei gruppi di archiviazione in ambienti di replica continua   In Exchange 2007 SP1, la struttura dell'architettura di replica continua è stata modificata affinché la cache del database continui sul nodo passivo nei batch intermedi dell'attività di riproduzione dei registri. La persistenza della cache del database nei batch intermedi dell'attività di riproduzione dei registri consente al servizio Replica di Microsoft Exchange di utilizzare le funzioni di memorizzazione nella cache di ESE, con conseguente riduzione dell'attività di 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 sul nodo passivo di dimensioni doppie o triple rispetto a quelle dell'I/O nel nodo attivo.

  • Spostamento più rapido dei server di cassette postali in cluster tra i nodi in un ambiente CCR   Tali miglioramenti consentono lo spostamento dei server di cassette postali in cluster tra i nodi in un tempo pari o inferiore a due minuti. Sono inclusi i miglioramenti apportati da un amministratore (attraverso il cmdlet Move-ClusteredMailboxServer) e i failover gestiti dal servizio Cluster. Per ottenere spostamenti rapidi in un ambiente CCR, i database vengono portati non in linea senza lo svuotamento della cache del database. Ciò riduce il tempo di inattività al momento dello spostamento in un altro nodo del server di cassette postali in cluster.

Utilizzo della replica continua di standby con la replic continua cluster

La replica continua di standby è una nuova funzione 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 in un ambiente di cluster a copia singola o di replica continua cluster.

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 (e 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) oppure, 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.

Ulteriori informazioni

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