Informazioni sulla disponibilità elevata e sulla resilienza del sito

  • Articolo

 

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2016-11-28

I database delle cassette postali e i dati che contengono sono uno degli elementi più critici (forse il componente più critico) di ogni organizzazione Exchange. In Microsoft Exchange Server 2010, è possibile proteggere i database delle cassette postali e i dati che contengono configurando i database delle cassette postali per la disponibilità elevata e la resilienza del sito. Exchange 2010 riduce il costo e la complessità della distribuzione di una soluzione di messaggistica a disponibilità elevata e resilienza del sito fornendo al contempo livelli più elevati di disponibilità end-to-end e supportando cassette postali di grandi dimensioni. Basandosi sulle funzionalità di replica native introdotte in Exchange Server 2007, la nuova architettura a disponibilità elevata di Exchange 2010 fornisce un framework semplificato e unificato sia per la disponibilità elevata che per la resilienza del sito. Exchange 2010 integra la disponibilità elevata nell'architettura principale di Exchange, consentendo ai clienti di ogni dimensione e in tutti i segmenti di distribuire in modo economico un servizio continuo di messaggistica nella propria organizzazione.

Per ulteriori informazioni sulle attività di gestione relative alla disponibilità elevata e alla resilienza del sito, vedere Gestione della disponibilità elevata e della resilienza del sito.

Sommario

Terminologia chiave

Caratteristiche principali della soluzione Exchange Server 2010

Mobilità del database

Distribuzione incrementale

Gruppi di disponibilità del database

Copie del database delle cassette postali

Active Manager

Modifiche apportate alla disponibilità elevata rispetto alle versioni precedenti di Exchange

Disponibilità elevata per ruoli del server diversi da Cassette postali

Resilienza del sito

Disponibilità end-to-end

Terminologia chiave

Vengono impiegati i termini seguenti:

  • Servizio Rubrica
    Un servizio del server Accesso client che fornisce un endpoint di accesso alle directory per i client di Microsoft Outlook.
  • Replica continua - modalità di blocco
    Una nuova forma di replica continua in SP1 mediante la quale ogni singolo aggiornamento viene scritto nel buffer di registro attivo della copia di database attiva e viene anche inviato a un buffer di registro su ogni copia passiva delle cassette postali. Quando il buffer di registro è pieno, ogni copia del database compila, controlla e crea il file di log successivo nella sequenza di generazione.
  • Replica continua - modalità file
    Il nome del modulo originale di replica continua nella versione di produzione (RTM) di Exchange 2010, mediante il quale i file di log delle transazioni chiuse vengono spostati dalla copia attiva del database a una o più copie passive o attive del database.
  • Gruppo di disponibilità del database (DAG, Database Availability Group)
    Gruppo di un massimo di 16 server Cassette postali Exchange 2010 che ospita un insieme di database replicati.
  • Mobilità del database
    La capacità di un singolo database Cassette postali Exchange 2010 di essere replicato e montato su altri server Cassette postali Exchange 2010.
  • Ripristino d'emergenza
    Qualsiasi processo utilizzato per eseguire manualmente il ripristino da un errore. Può trattarsi di un errore che incide su un elemento singolo oppure di un errore che riguarda un'intera posizione fisica.
  • API di replica di terza parte Exchange
    API fornita da Exchange che consente l'utilizzo di qualsiasi replica sincrona di terza parte per un gruppo di disponibilità del database anziché la replica continua.
  • Disponibilità elevata
    Soluzione che fornisce la disponibilità del servizio, la disponibilità dei dati e il ripristino automatico dagli errori che incidono su servizio o dati (ad esempio errore di rete, archiviazione o server).
  • Distribuzione incrementale
    Possibilità di distribuire disponibilità elevata e resilienza del sito dopo l'installazione di Exchange 2010.
  • Copia del database delle cassette postali ritardata
    Copia passiva del database delle cassette postali che presenta un intervallo di riesecuzione registrazione superiore a zero.
  • Copia del database delle cassette postali
    Database delle cassette postali (file EDB e registri) attivo o passivo.
  • Resilienza delle cassette postali
    Nome di una soluzione unificata a disponibilità elevata e resilienza del sito in Exchange 2010.
  • Servizio Accesso client RPC
    Un servizio del server Accesso client che fornisce un endpoint MAPI per i client di Microsoft Outlook.
  • Resilienza del sito
    Un processo manuale di ripristino di emergenza utilizzato per attivare un data center alternativo o di standby quando il data center primario non è più in grado di fornire un livello di servizio sufficiente per le esigenze dell'organizzazione. Include anche il processo di riattivazione di un data center primario recuperato, ripristinato o ricreato. È possibile configurare la soluzione di messaggistica per la disponibilità elevata e abilitare la resilienza del sito utilizzando le funzionalità incorporate e la funzionalità di Exchange 2010.
  • Ridondanza shadow
    Funzionalità del server di trasporto che fornisce ridondanza per i messaggi per l'intero tempo di transito.
  • *over (pronunciato "star over")
    Abbreviazione di switchover e failover. Per switchover si intende l'attivazione manuale di una o più copie del database. Per failover si intende l'attivazione automatica di una o più copie del database dopo un errore.

Inizio pagina

Caratteristiche principali della soluzione Exchange Server 2010

Exchange 2007 ha diminuito i costi della disponibilità elevata e ha reso molto più economica la resilienza del sito introducendo nuove tecnologie, ad esempio la replica continua cluster (CCR) e la replica continua in standby (SCR). Restavano comunque alcuni problemi:

  • Il clustering di failover di Windows poteva generare confusione a causa della sua complessità.

  • Il raggiungimento di un alto livello dei tempi di attività poteva richiedere numerosi interventi da parte dell'utente.

  • Ogni tipo di replica continua era gestita in modo diverso e separatamente.

  • La risoluzione dei problemi di un unico database su un server Cassette postali di grandi dimensioni poteva causare un'interruzione temporanea del servizio per tutti gli utenti sul server Cassette postali.

  • La funzionalità dumpster di trasporto del server Trasporto Hub era in grado di proteggere solo i messaggi destinati alle cassette postali in un ambiente CCR. Se si verificava un errore nel server Trasporto Hub durante l'elaborazione dei messaggi che non poteva essere ripristinato, era possibile perdere i dati.

Exchange 2010 include notevoli modifiche essenziali che integrano la disponibilità elevata nell'architettura, rendendo più agevoli e meno costose la distribuzione e la gestione, rispetto alle versioni precedenti di Exchange. Exchange 2010 include una nuova piattaforma unificata per la disponibilità elevata e la resilienza del sito.

Grazie ai notevoli miglioramenti essenziali apportati a Exchange 2010, la dimensione massima consigliata per il database delle cassette postali durante l'uso della replica continua è stata portata da 200 GB in Exchange 2007 a 2 TB in Exchange 2010. Via via che un numero sempre crescente di società comprenderà il grande vantaggio offerto da cassette postali di grandi dimensioni (da 2 GB a 10 GB), database di dimensioni notevolmente più grandi potranno presto divenire una realtà. Per supportare database più grandi sarà necessario passare da meccanismi di ripristino precedenti, quali backup e ripristino, a forme di protezione innovative e più veloci quali la replica dei dati e la ridondanza del server. Alla fine, le dimensioni dei database delle cassette postali dipendono da molti fattori derivati durante il processo di pianificazione di Exchange 2010. Per indicazioni di pianificazione dettagliate per le cassette postali e i server Cassette postali vedere Progettazione dell'archiviazione del server Cassette postali.

Exchange 2010 combina le funzionalità chiave di disponibilità e resilienza di CCR e SCR in un'unica soluzione che gestisce la replica dei dati sia nel sito che all'esterno del sito. I server Cassette postali possono essere definiti come parte di un gruppo di disponibilità del database per fornire il ripristino automatico a livello del database delle cassette postali invece che a livello del server. In Exchange 2010 vengono introdotti altri nuovi concetti di disponibilità elevata, ad esempio mobilità del database e distribuzione incrementale.

Inizio pagina

Mobilità del database

Exchange 2007 ha introdotto molte nuove modifiche relative all'architettura progettate per semplificare e velocizzare la distribuzione delle soluzioni di disponibilità elevata e resilienza del sito per Exchange. Questi miglioramenti includevano un programma di installazione integrato, opzioni di configurazione ottimizzate e la capacità di gestire la maggior parte degli aspetti della soluzione di disponibilità elevata utilizzando gli strumenti di gestione di Exchange nativi.

Tuttavia, la gestione di una soluzione di disponibilità elevata di Exchange 2007 richiedeva agli concetti di clustering complessi, quale il concetto relativo allo spostamento delle identità di rete e alla gestione delle risorse cluster. Inoltre, quando si risolvevano i problemi relativi a un server Cassette postali in cluster, venivano utilizzati gli strumenti di Exchange e gli strumenti del cluster per esaminare e correlare i registri e gli eventi da due origini diverse: una da Exchange e una dal cluster.

Altri due aspetti limitanti dell'architettura di Exchange 2007 sono stati valutati e rivisti in base ai suggerimenti dei clienti:

  • I server Exchange 2007 in cluster richiedono un hardware apposito. Solo il ruolo del server Cassette postali poteva essere installato su un nodo nel cluster. Perciò, erano necessari almeno quattro server Exchange per raggiungere la ridondanza completa dei componenti principali di una distribuzione, ad esempio, i ruoli del server principale (Cassette postali, Trasporto Hub e Accesso client).

  • In Exchange 2007, il failover di un server Cassette postali in cluster si verifica a livello di server. Di conseguenza, se si verificava nel database un unico errore, l'amministratore doveva eseguire il failover dell'intero server Cassette postali in cluster a un altro nodo nel cluster (ciò causava brevi tempi di inattività per tutti gli utenti sul server e non solo per gli utenti con una cassetta postale sul database coinvolto) o lasciare gli utenti in modalità offline sul database che presentava l'errore (per ore) durante il ripristino del database dal backup.

Exchange 2010 è stato progettato sulla base del concetto di mobilità del database. La mobilità del database consente di espandere l'utilizzo da parte del sistema della replica continua, eseguendo la replica di un database su più server diversi raggruppati insieme. Questo modello fornisce una migliore protezione del database e una maggiore disponibilità. In questo modello, la protezione di failover automatica e il controllo di switchover manuale vengono forniti a livello di database delle cassette postali anziché a livello di server.

Nel caso di errori, gli altri server che dispongono delle copie del database possono montarlo. Come risultato di questa e di altre modifiche dell'architettura, le azioni di failover vengono ora completate molto più velocemente rispetto alla versioni precedenti di Exchange. Ad esempio, il failover di un server Cassette postali in cluster in un ambiente CCR che esegue Exchange 2007 Service Pack 1 viene completata in circa 2 minuti (presupponendo un errore interno al sito in cui l'indirizzo IP del server Cassette postali in cluster non cambia). A confronto, il failover di un database delle cassette postali in un ambiente Exchange 2010 viene completato in 30 secondi (dal momento in cui viene rilevato l'errore al momento in cui una copia del database viene montata, partendo dal presupposto che la copia sia integra e aggiornata con la riproduzione del registro). La combinazione di failover a livello del database e tempi di failover più brevi migliora i tempi di attività dell'organizzazione.

Inizio pagina

Distribuzione incrementale

Exchange 2010 introduce il concetto di distribuzione incrementale, che consente di distribuire la disponibilità dei servizi e dei dati per tutti i database e i server Cassette postali dopo l'installazione di Exchange. La ridondanza dei dati e dei servizi viene raggiunta utilizzando le nuove funzionalità in Exchange 2010, ad esempio le copie del database e i gruppi di disponibilità del database.

Nelle versioni precedenti di Exchange, la disponibilità dei servizi per i ruoli del server Cassette postali era stata raggiunta distribuendo Exchange in un cluster di failover di Windows. Per distribuire Exchange in un cluster, era necessario prima creare un cluster di failover, quindi installare i programmi di Exchange. Questo processo creava un server Cassette postali speciale denominato server Cassette postali in cluster (o server virtuale di Exchange nelle versioni precedenti di Exchange). Se i programmi di Exchange erano già stati installati su un server non in cluster e si desiderava un server Cassette postali in cluster, era necessario creare un cluster utilizzando un nuovo hardware o rimuovere Exchange dal server esistente, installare il clustering di failover e reinstallare Exchange.

Inizio pagina

Gruppi di disponibilità del database

Un gruppo di disponibilità del database è il componente di base del framework a disponibilità elevata e resilienza del sito integrata in Exchange 2010. Un gruppo di disponibilità del database (DAG, Database Availability Group) è un gruppo di un massimo di 16 server Cassette postali che ospita un insieme di database e fornisce il ripristino automatico a livello del database da errori che hanno un impatto su singoli database. Qualsiasi server in un gruppo di disponibilità del database è in grado di ospitare una copia del database delle cassette postali da qualsiasi altro server nel gruppo di disponibilità del database. Quando un server viene aggiunto al gruppo di disponibilità del database, funziona con altri server nel gruppo di disponibilità del database per fornire il ripristino automatico da errori che hanno un impatto sui database delle cassette postali, ad esempio un errore nel server o nel disco.

Exchange 2007 ha introdotto una tecnologia di replica di dati incorporata denominata replica continua. La replica continua, disponibile in tre forme: locale, cluster e standby, ha ridotto notevolmente il costo di distribuzione di un'infrastruttura Exchange a disponibilità elevata e ha fornito un livello di distribuzione e gestione decisamente migliore rispetto alle versioni precedenti di Exchange. Nonostante questi miglioramenti risparmi sui costi, tuttavia, l'esecuzione di un'infrastruttura Exchange 2007 a disponibilità elevata richiedeva ancora molto tempo ed esperienza poiché l'integrazione tra clustering di failover Windows e Exchange non era immediata. Inoltre, i clienti desideravano un mezzo più semplice per replicare i loro dati di posta elettronica in una posizione remota, per proteggere il loro ambiente Exchange da errori irreversibili a livello di sito.

Exchange 2010 utilizza la stessa tecnologia di replica continua presente in Exchange 2007. Exchange 2010 combina la replica dei dati del sito (CCR) e la replica dei dati all'esterno del sito (SCR) in un unica framework denominato gruppo di disponibilità del database (DAG, Database Availability Group). Dopo che i server sono stati aggiunti a un gruppo di disponibilità del database, è possibile aggiungere copie di database replicate in modo incrementale (fino a un totale di 16) e Exchange 2010 passerà automaticamente da una all'altra di queste copie per mantenere la disponibilità.

A differenza di Exchange 2007, dove i server Cassette postali in cluster richiedono hardware dedicato, i server Cassette postali in un gruppo di disponibilità del database possono ospitare altri ruoli di Exchange (Accesso client, Trasporto Hub e Messaggistica unificata), fornendo ridondanza completa dei servizi e dati di Exchange con appena due server.

La nuova architettura a disponibilità elevata consente inoltre il ripristino semplificato da una vasta gamma di errori (a livello di disco, di server e di centro dati) e può essere distribuita su diversi tipi di archiviazione.

Per ulteriori informazioni sui gruppi di disponibilità del database, vedere Informazioni sui gruppi di disponibilità del database.

Inizio pagina

Copie del database delle cassette postali

Le funzionalità di disponibilità elevata e di resilienza del sito introdotte in Exchange 2007 sono utilizzate in Exchange 2010 per creare e mantenere copie del database, in modo che sia possibile ottenere gli obiettivi di disponibilità desiderati in Exchange 2010. Exchange 2010 introduce inoltre il concetto di mobilità del database, costituito da failover a livello di database gestiti da Exchange.

La mobilità del database consente di disconnettere i database dai server, di aggiungere il supporto per un massimo di 16 copie di un singolo database e fornisce un sistema nativo per l'aggiunta di copie di database a un database. In Exchange 2007, una funzionalità denominata portabilità del database consentiva anche di spostare un database delle cassette postali tra i server. Ciò che differenzia in modo particolare la portabilità del database dalla mobilità del database è che tutte le copie di un database hanno lo stesso GUID.

L'impostazione di una copia del database come database delle cassette postali attivo è definita switchover. Quando si verifica un errore che incide su un database e un nuovo database diviene la copia attiva, il processo è denominato failover. Questo processo si riferisce inoltre a un errore server in cui uno o più server portano in linea i database precedentemente in linea sul server che ha presentato l'errore. Quando si verifica uno switchover o un failover, gli altri ruoli server di Exchange 2010 vengono a conoscenza dello switchover pressoché immediatamente e reindirizza il traffico di messaggistica e client al nuovo database attivo.

Ad esempio, se un database attivo in un gruppo di disponibilità del database presenta un problema a causa di un errore dell'archiviazione sottostante, Active Manager effettua immediatamente il ripristino mediante failover su una copia del database in un altro server Cassette postali del gruppo di disponibilità del database. Se il database non rientra nei criteri di montaggio automatico e non può essere montato automaticamente, è possibile eseguire manualmente un failover del database.

Per ulteriori informazioni sulle copie del database delle cassette postali, vedere Informazioni sulle copie del database delle cassette postali.

Inizio pagina

Active Manager

In Exchange 2007 e nelle versioni precedenti, Exchange utilizzava il modello di gestione delle risorse per installare, implementare e gestire la soluzione a disponibilità elevata del server Cassette postali. Storicamente, la creazione di un server Cassette postali a disponibilità elevata richiedeva innanzitutto la creazione di un cluster di failover Windows e quindi l'esecuzione dell'installazione di Exchange in modalità cluster. In questa modalità, il file DLL di risorse cluster Exchange, exres.dll, veniva registrato e consentiva la creazione di un server Cassette postali in cluster (denominato server virtuale di Exchange nelle versioni precedenti). Quando si distribuiscono cluster di archiviazione condivisi precedenti o singoli cluster di copie, sono richiesti passaggi aggiuntivi per la configurazione dell'archiviazione prima e dopo la formazione di cluster di failover e dopo la formazione di server Cassette postali in cluster e gruppi di archiviazione.

Exchange 2010 include un nuovo componente denominato Active Manager che fornisce funzionalità che sostituiscono le funzionalità di modello di risorse e di gestione failover fornite dall'integrazione con il servizio Cluster delle versioni precedenti di Exchange. Per ulteriori informazioni su Active Manager, vedere Informazioni su Active Manager.

Inizio pagina

Modifiche apportate alla disponibilità elevata rispetto alle versioni precedenti di Exchange

Vi sono varie modifiche dell'architettura principale di Exchange 2010 che hanno effetto diretto su come si configura Exchange per la disponibilità elevata, nonché effetto diretto su come si esegue il ripristino del sito. Una modifica significativa è la rimozione dei server Cassette postali in cluster e l'utilizzo del modello di risorse cluster di failover di Windows. Altre notevoli modifiche includono la globalizzazione di database e i miglioramenti apportati alla tecnologia di replica continua incorporata, introdotta in Exchange 2007.

Rimozione del server Cassette postali in cluster

In Exchange 2010, Exchange non è più un'applicazione in cluster e il modello di risorse cluster non è più utilizzato per la disponibilità elevata di Exchange. Exres.dll e tutte le risorse cluster di Exchange fornite non esistono più, inclusi i server Cassette postali in cluster. Exchange 2010 utilizza invece il proprio modello interno a disponibilità elevata. Alcuni componenti del clustering di di Windows sono ancora utilizzati ma ora sono integrati in altre funzionalità di Exchange 2010.

Globalizzazione dei database

In Exchange 2010, un database viene associato a un unico flusso di registrazione dedicato, rappresentato da un flusso di file di log da 1 MB denominati in modo sequenziale. Anche il concetto di gruppi di archiviazione è stato rimosso da Exchange 2010. Come risultato di queste modifiche, i database di Exchange hanno un flusso di registrazione dedicato e non condividono più i flussi di registrazione con altri database.

A differenza delle versioni precedenti di Exchange, i database non sono più strettamente legati a un server Cassette postali specifico. Inoltre, i database non sono più identificati dai server Cassette postali in cui risiedono e i nomi server non fanno più parte delle identità dei database. Come risultato di queste modifiche, i database sono ora oggetti globali in Active Directory e in ogni organizzazione Exchange. Quando si utilizza Exchange Management Console, i database vengono ora gestiti dal nodo Cassette postali nel nodo Configurazione dell'organizzazione.

Ogni server Cassette postali può ospitare un massimo di 100 database (numero totale di database attivi e passivi). Il numero totale di database è pari al numero combinato di database attivi e passivi su un server. Il database di ripristino non conta per il limite di 100 database.

Modifiche alla replica continua in Exchange Server 2010 RTM

La tecnologia di replica continua introdotta in Exchange 2007 è disponibile anche in Exchange 2010. La funzionalità, tuttavia, si è evoluta notevolmente per supportare le nuove funzionalità a elevata disponibilità e una maggiore scalabilità. Alcune di queste modifiche dell'architettura includono:

  • Poiché i gruppi di archiviazione vengono rimossi in Exchange 2010, la replica continua ora funziona a livello di database. Exchange 2010 utilizza ancora un database Extensible Storage Engine (ESE) che produce log delle transazioni replicati in una o più posizioni diverse e rieseguiti in una o più copie di database delle cassette postali. Ogni database delle cassette postali può contenere un massimo di 16 copie.

  • Il log shipping non utilizza più Server Message Block (SMB) e notifiche del file system Windows. Il log shipping non utilizza più un modello pull, in cui la copia passiva estrae un file di log chiuso dalla copia attiva. La copia passiva utilizza invece notifiche basate su TCP per notificare alla copia attiva quali file di log sono richiesti dalla copia passiva. La copia attiva, quindi, effettua il push dei file di log in ogni copia passiva configurata tramite il socket TCP.

  • La replica continua di Exchange 2010 utilizza una porta TCP definita dall'amministratore per il trasferimento dei dati. Inoltre, Exchange 2010 include opzioni incorporate per la crittografia di rete e la compressione del flusso di dati.

  • Il seeding non si limita più a utilizzare solo la copia attiva del database. Le copie passive dei database delle cassette postali ora possono essere specificate come origini per il seeding e il reseeding della copia del database.

  • Le copie del database sono solo per i database delle cassette postali. Per ottenere la ridondanza e la disponibilità elevata per i database delle cartelle pubbliche, si consiglia l'utilizzo della replica delle cartelle pubbliche. A differenza di CCR, in cui non potevano esistere nello stesso cluster più copie di un database delle cartelle pubbliche, è possibile utilizzare la replica delle cartelle pubbliche per replicare i database delle cartelle pubbliche tra i server in un gruppo di disponibilità del database.

  • In Exchange 2007, il servizio di replica di Microsoft Exchange era responsabile della riesecuzione dei registri in copie del database passive. Quando la copia passiva veniva attivata, la cache del database creata dal servizio di replica di Microsoft Exchange come risultato dell'attività di riesecuzione andava persa quando il servizio Archivio informazioni di Microsoft Exchange montava il database. In questo modo la cache del database veniva portata nello stato definito come successivo all'avvio. La cache del database, utilizzata per la memorizzazione di operazioni di lettura/scrittura, è di dimensioni ridotte (successiva all'avvio) durante questo intervallo. Ha quindi capacità notevolmente più limitate per la riduzione delle operazioni I/O di lettura. In Exchange 2010, la funzionalità di riesecuzione della copia passiva precedentemente eseguita dal servizio di replica di Microsoft Exchange è stata spostata nel servizio Archivio informazioni di Microsoft Exchange. Di conseguenza, è presente una cache del database operativa e immediatamente disponibile per l'uso dopo che si è verificato un failover o uno switchover.

Anche diversi concetti utilizzati nella replica continua di Exchange 2007 rimangono in Exchange 2010. Sono compresi i concetti di gestione del failover, divergenza, utilizzo del dial di montaggio automatico del database e l'utilizzo delle reti di replica e accesso client (MAPI).

Modifiche alla replica continua in Exchange Server 2010 SP1

Nella versione RTM di Exchange 2010 e in tutte le versioni di Exchange Server 2007, la replica continua funziona inviando copie dei file di log generati dalla copia attiva del database alle copie passive del database. A partire da Exchange 2010 SP1, questa forma di replica continua è nota come replica continua - modalità file. In SP1 è stata introdotta anche una nuova forma di replica continua denominata replica continua - modalità di blocco. Nella modalità di blocco, ogni singolo aggiornamento viene scritto nel buffer di registro attivo della copia di database attiva e viene anche inviato a un buffer di registro in ognuna delle copie passive delle cassette postali. Quando il buffer di registro è pieno, ogni copia del database compila, controlla e crea il file di log successivo nella sequenza di generazione. Nel caso di un errore relativo alla copia attiva, le copie passive saranno aggiornate con la maggior parte degli ultimi aggiornamenti. La copia attiva non attende il completamento della replica per evitare che i problemi di replica influenzino l'esperienza del client.

La modalità di blocco riduce drasticamente la latenza tra il momento in cui viene apportata una modifica alla copia attiva e il momento in cui la modifica viene replicata nelle copie passive. Oltre a replicare le singole operazioni di scrittura nel file di log, la modalità di blocco consente anche di modificare il processo di attivazione di una copia passiva. Se una copia è in modalità di blocco quando si verfica un errore, il sistema utilizza qualsiasi contenuto parziale del log disponibile durante il processo di attivazione. In questo modo, il file di log corrente della copia attiva non costituisce più un singolo punto di errore.

La modalità operativa iniziale è sempre la modalità file. La modalità di blocco è attiva solo quando la replica continua è aggiornata in modalità file. La transizione in entrata e in uscita dalla modalità di blocco viene eseguita automaticamente dal log copier. Quando la copia passiva richiede il file di log corrente, la replica continua è aggiornata (la lunghezza della coda di copia è 0) e il sistema passerà automaticamente dalla modalità file alla modalità di blocco.

Per determinare se una copia passiva del database si trova in modalità di blocco, è sufficiente monitorare il contatore delle prestazioni Replica continua – modalità di blocco Attiva nell'oggetto prestazioni Replica di MSExchange. Ogni copia del database ha una propria istanza del contatore. Il valore del contatore è impostato su 1 quando la copia passiva è in modalità di blocco e su 0 quando la copia passiva è in modalità file. È possibile determinare il valore del contatore utilizzando i cmdlet Get-Counter o Get-WMIObject, come illustrato negli esempi seguenti:

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Modifiche apportate al dumpster di trasporto rispetto a Exchange 2007

Il ruolo del server Trasporto Hub Exchange 2010 include una funzionalità denominata dumpster di trasporto, introdotta in Exchange 2007. Il dumpster di trasporto è progettato per consentire la protezione contro la perdita di dati grazie al mantenimento di una coda di tutti i messaggi di posta elettronica recenti inviati agli utenti le cui cassette postali sono protette da CCR o LCR. Quando si verifica un errore con perdita di dati in uno di questi ambienti, la maggior parte dei dati che normalmente andrebbe persa a causa dell'errore viene automaticamente ripristinata dal dumpster di trasporto.

Il dumpster di trasporto è utilizzato esclusivamente per i database delle cassette postali replicati. Non protegge i messaggi inviati a cartelle pubbliche né i messaggi inviati a destinatari su database di cassette postali non replicati. La coda del dumpster di trasporto per un database delle cassette postali specifico è presente su tutti i server Trasporto Hub nei siti Active Directory contenenti un gruppo di disponibilità del database.

In Exchange 2007, i messaggi vengono mantenuti nel dumpster di trasporto finché non viene raggiunto il limite di tempo o di dimensione definito dall'amministratore. In Exchange 2010, il dumpster di trasporto riceve feedback dalla pipeline di replica per determinare quali messaggi devono essere recapitati e replicati. Quando un messaggio passa attraverso i server Trasporto Hub verso un server Cassette postali replicato in un gruppo di disponibilità del database, ne viene conservata una copia nella coda di trasporto (mail.que) fino a quando i log delle transazioni che rappresentano il messaggio non sono stati correttamente replicati e analizzati da tutte le copie del database delle cassette postali. Dopo aver replicato i log e dopo aver analizzato tutte le copie del database, i messaggi nei log vengono troncati dal dumpster di trasporto. In questo modo la coda del dumpster di trasporto viene mantenuta entro dimensioni più ridotte, conservando solo le copie dei messaggi i cui registri delle transazioni non sono ancora stati replicati.

Ogni Active Manager del DAG tiene traccia del valore dell'ultimo file di log controllato in ogni copia passiva del database. Il client Active Manager in esecuzione sul server Trasporto Hub ottiene tali informazioni da Active Manager di standby (SAM) del DAG e le converte in una soglia basata sul tempo. Il server Trasporto Hub confronta quindi con la soglia il tempo di recapito dei messaggi nel dumpster di trasporto. Se il tempo di recapito di un messaggio è antecedente alla soglia, il messaggio viene troncato dal dumpster di trasporto.

Il dumpster di trasporto è inoltre stato migliorato per tenere conto delle modifiche apportate al ruolo del server Cassette postali che consente lo spostamento di un unico database delle cassette postali tra siti Active Directory. I gruppi di disponibilità del database possono essere estesi a più siti Active Directory e, come risultato, un unico database delle cassette postali in un sito Active Directory può eseguire il failover su un altro sito Active Directory. In questo caso, qualsiasi richiesta di nuovo recapito del dumpster di trasporto verrà inviata a entrambi i siti Active Directory: il sito originale e il nuovo sito.

Modifiche apportate al comportamento di routing quando il server Cassette postale e il server Trasporto Hub si trovano nello stesso gruppo di disponibilità del database

Quando il server Trasporto Hub si trova nella stessa posizione di un server Cassette postali membro di un gruppo di disponibilità del database, esistono delle modifiche nel comportamento di routing per garantire che le funzionalità di resilienza in entrambi i ruoli del server forniranno la protezione necessaria per i messaggi inviati e ricevuti dagli utenti su tale server. Il ruolo del server Trasporto Hub è stato modificato. In questo modo, ora tenta di instradare nuovamente il messaggio per un server Cassette postali locale su un altro server Trasporto Hub nello stesso sito se anche il server Trasporto Hub è membro del gruppo di disponibilità del database e dispone di una copia del database delle cassette postali installato localmente. Questo ulteriore hop è stato aggiunto per inserire il messaggio nel dumpster di trasporto in un server Trasporto Hub diverso.

Ad esempio, EX1 ospita il ruolo del server Cassette postali e il ruolo del server Trasporto Hub ed è un membro di un gruppo di disponibilità del database. Quando un messaggio arriva al server di trasporto EX1 per un destinatario la cui cassetta postale si trova anch'essa sul server EX1, il trasporto instraderà nuovamente il messaggio a un altro server Trasporto Hub nel sito (ad esempio, EX2) e tale server recapiterà il messaggio alla cassetta postale su EX1.

Esiste una seconda modifica simile relativa al comportamento relativa al servizio Invio posta di Microsoft Exchange. Questo servizio è stato modificato. In questo modo i messaggi non verranno inviati al ruolo del server Trasporto Hub locale quando il server Cassette postali o Trasporto Hub è un membro di un gruppo di disponibilità del database. In questo scenario, il comportamento del trasporto è quello di bilanciare il carico delle richieste di invio tra altri server Trasporto Hub nello stesso sito di Active Directory e di passare al server Trasporto Hub locale se non esistono altri server Trasporto Hub disponibili nello stesso sito.

Inizio pagina

Disponibilità elevata per ruoli del server diversi da Cassette postali

L'elevata disponibilità per i ruoli del server Trasporto Hub, Trasporto Edge, Accesso client e Messaggistica unificata viene ottenuta attraverso una combinazione di ridondanza dei server, bilanciamento del carico, round robin DNS (Domain Name System) e funzionalità di gestione attiva di server, servizi e infrastruttura. In genere è possibile ottenere un'elevata disponibilità per i ruoli del server Accesso client, Trasporto Hub, Trasporto Edge e Messaggistica unificata utilizzando le seguenti strategie e tecnologie:

  • Trasporto Edge   È possibile distribuire più server Trasporto Edge e utilizzare più record di risorse DNS MX per il bilanciamento del carico tra i server in questione. È inoltre possibile utilizzare NLB (Network Load Balancing) per il bilanciamento del carico e la disponibilità elevata dei server Trasporto Edge.

  • Accesso client   È possibile utilizzare NLB o un dispositivo di bilanciamento del carico di rete basato su hardware di terze parti per assicurare la disponibilità elevata del server Accesso client.

  • Trasporto Hub   È possibile distribuire più server Trasporto Hub per garantire la disponibilità elevata del trasporto interno. Nel ruolo del server Trasporto Hub la resilienza è stata progettata nei modi seguenti:

    • Da server Trasporto Hub a server Trasporto Hub (all'interno dell'organizzazione) Per la comunicazione tra server Trasporto Hub e server Trasporto Hub all'interno di un'organizzazione, il carico viene automaticamente bilanciato tra i server Trasporto Hub disponibili nel sito di Active Directory di destinazione.

    • Da server Cassette postali a server Trasporto Hub (all'interno del sito Active Directory)   Il servizio Invio posta di Microsoft Exchange nei server Cassette postali bilancia automaticamente il carico tra tutti i server Trasporto Hub disponibili all'interno dello stesso sito Active Directory.

    • Da server Messaggistica unificata a server Trasporto Hub   Il server Messaggistica unificata bilancia automaticamente il carico delle connessioni tra tutti i server Trasporto Hub disponibili all'interno dello stesso sito Active Directory.

    • Da server Trasporto Edge a server Trasporto Hub   Il server Trasporto Edge bilancia automaticamente il carico del traffico SMTP in ingresso tra tutti i server Trasporto Hub disponibili nel sito Active Directory al quale è sottoscritto il server Trasporto Edge.

    Per ottenere una maggiore ridondanza (ad esempio applicazioni che richiedono l'inoltro SMTP), è possibile creare un record DNS (ad esempio inoltro.azienda.com), assegnare un indirizzo IP e utilizzare un dispositivo hardware di bilanciamento del carico per reindirizzare tale indirizzo IP a più server Trasporto Hub. È anche possibile utilizzare il bilanciamento del carico di rete per i connettori client sui server Trasporto Hub. Quando si utilizza un dispositivo di bilanciamento del carico hardware, è necessario assicurarsi che il traffico all'interno dell'organizzazione non passerà attraverso tale dispositivo di bilanciamento del carico hardware perché, come descritto in precedenza, il traffico all'interno dell'organizzazione utilizza algoritmi di bilanciamento del carico incorporati.

  • Messaggistica unificata   Le distribuzioni di messaggistica unificata possono avere una resilienza maggiore se si distribuiscono più server Messaggistica unificata e almeno due si trovano in un singolo dial plan. I gateway Voice over IP (VoIP) supportati dalla messaggistica unificata possono essere configurati in modo che instradino le chiamate a server Messaggistica unificata in modo round robin. Inoltre questi gateway possono recuperare l'elenco di server per un dial plan da DNS. In entrambi i casi i gateway VoIP presenteranno una chiamata a un server Messaggistica unificata e tale chiamata, se non viene accettata, verrà presentata a un altro server. Nel momento in cui la chiamata viene stabilita, si ottiene ridondanza.

Inizio pagina

Resilienza del sito

Exchange 2010 include una piattaforma unificata per l'elevata disponibilità e la resilienza del sito. Combinando il supporto di resilienza di un sito nativo in Exchange 2010 con una pianificazione appropriata, è possibile attivare rapidamente un secondo data center da utilizzare con i client di data center in cui si è verificato un errore. Gli errori di un data center o di un sito vengono gestiti in modo diverso rispetto ai tipi di errore che potrebbero provocare un failover del server o del database. In una configurazione ad elevata disponibilità, il ripristino automatico viene avviato dal sistema e l'errore lascia, generalmente, il sistema di messaggistica in uno stato completamente funzionante. Un errore del data center viene invece considerato un'operazione di ripristino di emergenza. Il ripristino deve essere eseguito e completato manualmente per il servizio client da ripristinare e per l'interruzione da terminare. Tale processo viene definito switchover del centro dati. Come per molti scenari di ripristino di emergenza, la pianificazione e preparazione anticipata di uno switchover del data center può semplificare il processo e ridurre la durata dell'interruzione.

Per ulteriori informazioni sulla pianificazione e sulla distribuzione della resilienza del sito, vedere Pianificazione della disponibilità elevata e della resilienza del sito, Distribuzione della disponibilità elevata e della resilienza del sito e Passaggi centro dati.

Inizio pagina

Disponibilità end-to-end

Exchange 2010 include anche molte funzionalità progettate per aumentare la disponibilità end-to-end del sistema. Queste funzionalità comprendono:

  • Ridondanza shadow

  • Spostamento cassetta postale online

  • Protezione della cassetta postale flessibile

  • Risincronizzazione incrementale

  • API di replica di terze parti

Ridondanza shadow

Oltre alla funzionalità dumpster di trasporto e a miglioramenti del comportamento di routing precedentemente descritti, è stata aggiunta una nuova funzionalità del server Trasporto Hub denominata Ridondanza shadow. Questa funzionalità fornisce la ridondanza ai messaggi per l'intera fase di transito. La soluzione richiede una tecnica simile al dumpster di trasporto. Con la ridondanza shadow, l'eliminazione di un messaggio dal database di trasporto viene ritardata finché il server di trasporto non verifica che è stato completato il recapito di tutti gli hop successivi per quel messaggio. Se uno degli hop successivi restituisce un risultato negativo prima di segnalare il completamento corretto del recapito, il messaggio viene inviato nuovamente a tale hop per il recapito. Per ulteriori informazioni sulla ridondanza shadow, vedere Informazioni sulla ridondanza shadow.

Spostamento cassetta postale online

Exchange 2010 include una nuova funzionalità che consente di spostare le cassette postali in modo asincrono. In Exchange 2007, quando si utilizzava il cmdlet Move-Mailbox per spostare una cassetta postale, tale cmdlet accedeva sia al database di origine che a quello di destinazione e spostava il contenuto da una cassetta postale a un'altra. Erano molti gli svantaggi riscontrati:

  • Il completamento degli spostamenti della cassetta postale richiedeva in genere diverse ore e durante lo spostamento gli utenti non erano in grado di accedere alla propria cassetta postale.

  • Se la finestra del prompt dei comandi utilizzata per eseguire il cmdlet Move-Mailbox era chiusa, lo spostamento veniva terminato e doveva essere riavviato.

  • Il computer utilizzato per eseguire lo spostamento partecipava al trasferimento dei dati. Se un amministratore eseguiva i cmdlet dalla workstation, i dati della cassetta postale passavano dal server di origine alla workstation dell'amministratore, quindi al server di destinazione.

Il cmdlet New-MoveRequest in Exchange 2010 può essere utilizzato per per eseguire spostamenti asincroni. A differenza di Exchange 2007, i cmdlet non eseguono lo spostamento effettivo. Lo spostamento viene eseguito dal servizio di replica delle cassette postali di Microsoft Exchange, un nuovo servizio che viene eseguito sul server Accesso client. Il cmdlet New-MoveRequest invia le richieste al servizio di replica delle cassette postali di Microsoft Exchange. Per ulteriori informazioni sugli spostamenti delle cassette postali online, vedere Informazioni sulle richieste di spostamento.

Protezione della cassetta postale flessibile

Esistono diverse modifiche all'architettura principale di Exchange 2010 che hanno un impatto diretto sulla modalità di protezione dei database delle cassette postali e delle cassette postali che contengono.

Una modifica importante è la rimozione dei gruppi di archiviazione. In Exchange 2010, ogni database viene associato a un unico flusso di log, rappresentato da una serie di file di log da 1 MB. Ogni server può ospitare un massimo di 100 database.

Un'altra importante modifica per Exchange 2010 è che i database non sono più strettamente legati a un server Cassette postali specifico. La mobilità del database consente di espandere l'utilizzo da parte del sistema della replica continua, eseguendo la replica di un database in più server diversi. Ciò fornisce una migliore protezione del database e una maggiore disponibilità. Nel caso di errori, gli altri server che dispongono delle copie del database possono installarlo.

La possibilità di avere diverse copie di un database ospitato su più server, indica che se si dispone di un numero sufficiente di copie del database, è possibile utilizzare tali copie come backup. Per ulteriori informazioni su questa strategia, vedere Informazioni su backup, ripristino e ripristino di emergenza.

Risincronizzazione incrementale

Exchange 2007 ha introdotto i concetti di resilienza dei registri persi e di reseeding incrementale. La resilienza dei registri persi è un componente interno di ESE che consente di ripristinare i database delle cassette postali di Exchange anche se uno o più file di log delle transazioni più recenti è stato perso o danneggiato. La resilienza dei registri persi consente di installare un database delle cassette postali anche quando i file di log appena creati non sono disponibili. La funzionalità di resilienza dei registri persi funziona ritardando le scritture nel database fino a quando non è stato creato il numero specificato di registri. Questa funzionalità ritarda gli aggiornamenti recenti del file di database per un breve tempo. Il periodo di ritardo delle operazioni di scrittura dipende dalla rapidità con cui vengono generati i registri.

Exchange 2007 ha inoltre introdotto il concetto di reseeding incrementale che forniva la capacità di correggere le divergenze nel flusso di registrazione delle transazioni tra un gruppo di archiviazione di origine e uno di destinazione, basandosi sulle funzionalità di riproduzione ritardata della resilienza dei registri persi. Il reseeding incrementale non forniva i mezzi necessari a correggere le divergenze nella copia passiva di un database dopo la riproduzione dei registri di divergenza. Per questo motivo era necessario eseguire un reseeding completo. Diversamente da Exchange 2007, non vi è una quantità tale di registri persi che richiede un reseeding completo in Exchange 2010.

In Exchange 2010, Risincronizzazione incrementale è il nuovo nome della funzionalità che corregge automaticamente le divergenze nelle copie del database in base alle seguenti condizioni:

  • Dopo un failover automatico di tutte le copie configurate di un database

  • Quando viene abilitata una nuova copia e alcuni file di log e del database già esistono nel percorso della copia

  • Quando la replica viene ripresa a seguito di una sospensione o del riavvio del servizio di replica di Microsoft Exchange

Come risultato di queste modifiche, la resilienza dei registri persi è hardcoded in un file di log per tutti i database delle cassette postali di Exchange 2010.

Quando viene rilevata una divergenza tra un database attivo e una copia di tale database, la risincronizzazione incrementale esegue queste attività:

  • Esegue la ricerca nel flusso dei file di log per individuare il punto di divergenza.

  • Individua le pagine del database modificate sulla copia diversa.

  • Legge le pagine modificate dalla copia attiva, quindi copia i file di log necessari dalla copia attiva.

  • Applica le modifiche della pagina del database alla copia diversa.

  • Esegue il ripristino sulla copia diversa e riproduce nuovamente i file di log necessari nella copia del database.

API di replica di terze parti

Exchange 2010 include anche una nuova API di replica di terze parti che consente alle organizzazioni di utilizzare le soluzioni di replica sincrone di terze parti invece della funzionalità di replica continua incorporata. Microsoft supporta soluzioni di terze parti che utilizzano l'API, purché la soluzione offra la funzionalità necessaria per sostituire tutte le funzionalità di replica continua native disabilitate in seguito all'utilizzo dell'API. Le soluzioni sono supportate solo quando l'API viene utilizzata in un DAG per gestire e attivare le copie del database delle cassette postali. L'uso dell'API di fuori di questi confini non è supportato. Inoltre, la soluzione deve soddisfare i requisiti di supporto hardware di Windows applicabili (la convalida dei test non è necessaria per il supporto).

Quando si distribuisce una soluzione che utilizza l'API di replica di terze parti integrata, è necessario tenere presente che il fornitore della soluzione è responsabile del supporto principale della soluzione. Microsoft supporta i dati di Exchange sia per le soluzioni replicate che per quelle non replicate. Le soluzioni che utilizzano la replica dei dati devono attenersi ai criteri di supporto di Microsoft per la replica dei dati, come descritto nell'articolo 895847 della Microsoft Knowledge Base, Supporto della replica dei dati con più siti per Exchange Server. Inoltre, le soluzioni che utilizzano il modello di risorse cluster di failover di Windows devono soddisfare i requisiti di supportabilità dei cluster di Windows, come descritto nell'articolo 943984 della Microsoft Knowledge Base, Criteri del Servizio Supporto Tecnico Microsoft per cluster di failover di Windows Server 2008.

I criteri di supporto per il backup e il ripristino di Microsoft per le distribuzioni che utilizzano soluzioni basate su API per le repliche di terze parti sono analoghi ai criteri delle distribuzioni delle repliche continue native.

Se si è un partner alla ricerca di informazioni su API di terze parti, contattare il rappresentante Microsoft. Per informazioni sui prodotti partner per Exchange 2010, vedere Microsoft Exchange Partners (informazioni in lingua inglese).

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.