Nuova funzionalità di disponibilità elevata e resilienza del sito

Si applica a: Exchange Server 2010 SP2

Ultima modifica dell'argomento: 2016-11-28

Microsoft Exchange Server 2010 riduce il costo e la complessità della distribuzione di una soluzione di posta elettronica che offre i livelli più alti di disponibilità del server e di resilienza del sito. Basandosi sulle funzionalità di replica native introdotte in Exchange Server 2007, la nuova architettura di elevata disponibilità in Exchange 2010 fornisce una struttura semplificata e unificata sia per l'elevata disponibilità che per il ripristino di emergenza. Exchange 2010 integra l'elevata disponibilità 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.

Risultati ottenuti da Exchange Server 2007

Exchange 2007 ha diminuito i costi dell'elevata disponibilità e ha reso molto più economica la resilienza del sito introducendo nuove tecnologie, ad esempio la replica continua locale (LCR), la replica continua cluster (CCR) e la replica continua in standby (SCR). Comunque, rimanevano alcune difficoltà:

• Alcuni amministratori erano intimiditi dalla complessità del clustering di failover di Windows.

• Il raggiungimento di un alto livello dei tempi di attività può 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.

• Le soluzioni di resilienza del sito presentavano dei problemi.

• La funzionalità dumpster di trasporto del server Trasporto Hub era in grado di proteggere solo i messaggi destinati alle cassette postali in un ambiente LCR o 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 importanti modifiche che integrano l'elevata disponibilità nell'architettura, rendendo ancora più economiche e semplici le operazioni di distribuzione e mantenimento rispetto a Exchange 2007. Le organizzazioni possono ora distribuire un'organizzazione di Exchange completamente ridondante con solo due server e trarre vantaggio dai failover a livello del database. I clienti possono trarre vantaggio dalle funzionalità di failover a livello del database automatiche senza dover essere esperti nel clustering di failover di Windows. Inoltre, è possibile aggiungere in modo più semplice la resilienza del sito alle distribuzioni di elevata disponibilità esistenti.

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

Inoltre, la gestione di una soluzione di elevata disponibilità di Exchange 2007 richiedeva agli amministratori di avere padronanza di alcuni concetti di clustering, ad esempio il concetto relativo allo spostamento delle identità di rete e alla gestione delle risorse del cluster. In aggiunta, quando si risolvevano i problemi relativi a un server Cassette postali in cluster, gli amministratori dovevano utilizzare gli strumenti di Exchange e del cluster per esaminare e correlare i registri e gli eventi da due origini diverse: una da Exchange e una dal cluster.

Due altri aspetti non soddisfacenti dell'architettura di Exchange 2007 sono stati rivalutati e riprogettati in base ai commenti 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, cioè, 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.

Resilienza della cassetta postale

Exchange 2010 è stato riprogettato in base al concetto di resilienza della cassetta postale, in cui l'architettura è stata modificata per fornire la protezione di failover automatica a livello del database della cassetta postale invece che a livello del server. In Exchange 2010, questo è noto come mobilità database. Come risultato di questa e di altre modifiche dell'architettura della cache del database, 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 con Service Pack 2 (SP2) viene completato in due minuti. A confronto, il failover di un database delle cassette postali in un ambiente di Exchange 2010 viene completato in 30 secondi o in un tempo inferiore (dal momento in cui viene rilevato l'errore al momento in cui una copia del database viene installata, partendo dal presupposto che sia disponibile una copia integra e aggiornata con la riproduzione del registro). La combinazione di failover a livello del database e tempi di failover più brevi migliora incredibilmente i tempi di attività dell'organizzazione.

L'architettura della resilienza della cassetta postale incorporata in Exchange 2010 offre nuovi vantaggi per le organizzazioni e gli amministratori di messaggistica:

• Più ruoli server possono coesistere sui server che offrono elevata disponibilità. Ciò consente alle organizzazioni di piccole dimensioni di distribuire una configurazione a due server che offre la ridondanza del servizio e dei dati della cassetta postale, fornendo nello stesso tempo servizi ridondanti di Trasporto Hub e Accesso client.

• Non è più necessario che un amministratore crei un cluster di failover per raggiungere l'elevata disponibilità. I cluster di failover ora vengono creati da Exchange 2010 in un modo invisibile all'amministratore. A differenza delle versioni precedenti di Exchange i cluster che hanno utilizzato una risorsa di cluster DLL fornita da Exchange denominata ExRes.dll, Exchange 2010 non necessitano più o non utilizzano più risorse cluster DLL. Exchange 2010 non è una applicazione cluster e utilizza solo una piccola parte di componenti del cluster di failover, cioè, le funzionalità heartbeat e il database del cluster, per fornire la mobilità del database.

• Gli amministratori possono aggiungere l'elevata disponibilità all'ambiente di Exchange 2010 dopo aver distribuito Exchange, senza dover disinstallare Exchange ed eseguire nuovamente la distribuzione in una configurazione di elevata disponibilità.

• Exchange 2010 fornisce una vista del flusso di eventi che assegna e combina gli eventi dal sistema operativo con gli eventi da Exchange.

• Dal momento che gli oggetti del gruppo di archiviazione non esistono più in Exchange 2010 e dal momento che i database delle cassette postali possono essere spostati in tutti i server Cassette postali di Exchange 2010, lo spostamento dei database è un'operazione semplice.

Per ulteriori informazioni, vedere Disponibilità elevata e resilienza del sito.

Protezione della cassetta postale flessibile

Exchange 2010 include diverse nuove funzionalità e modifiche principali che, quando vengono distribuite e configurate correttamente, possono fornire la protezione della cassette postale flessibile. Perciò, non sarà più necessario eseguire operazioni di backup dei dati. L'utilizzo delle funzionalità di elevata disponibilità incorporate in Exchange 2010 per ridurre i tempi di inattività e la perdita dei dati in caso di emergenza può ridurre anche il costo totale di proprietà del sistema di messaggistica. Combinando queste funzionalità con altre funzionalità incorporate, come Sospensione legale, le organizzazioni possono evitare di eseguire i backup temporizzati e possono abbassare notevolmente i costi.

Oltre a determinare se Exchange 2010 consente di non eseguire i backup tradizionali temporizzati, si consiglia di valutare il costo dell'infrastruttura di backup corrente. Considerare il costo dei tempi di inattività dell'utente finale e la perdita dei dati quando si cerca di eseguire il ripristino da un'infrastruttura di backup esistente. Inoltre, includere i costi relativi alla licenza, all'installazione e all'hardware, così come i costi associati al recupero dei dati e al mantenimento dei backup. In base ai requisiti dell'organizzazione, è probabile che un ambiente Exchange 2010 puro con almeno tre copie del database delle cassette postali fornirà costi totali di proprietà inferiori rispetto a uno con backup.

Per ulteriori informazioni sulla protezione della cassetta postale flessibile, vedere Informazioni su backup, ripristino e ripristino di emergenza.

Modifiche apportate all'elevata disponibilità rispetto alle versioni precedenti di Exchange

Exchange 2010 include molte modifiche alla sua architettura principale. Exchange 2010 unisce le funzionalità chiave di disponibilità e resilienza di CCR e SCR in un'unica soluzione di elevata disponibilità che gestisce la replica dei dati sia in sede che fuori sede. 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. Ciascun database delle cassette postali può avere fino a 16 copie. In Exchange 2010 vengono introdotti altri nuovi concetti di elevata disponibilità, ad esempio mobilità del database e distribuzione incrementale. Anche i concetti relativi a un'organizzazione senza backup e RAID vengono introdotti in Exchange 2010.

Per riassumere, gli aspetti chiave relativi alla disponibilità dei servizi e dei dati per il ruolo del server Cassette postali e i database delle cassette postali sono i seguenti:

• Exchange 2010 usa una versione migliorata della stessa tecnologia di replica continua introdotta con Exchange 2007. Per ulteriori informazioni, vedere Modifiche alla replica continua rispetto a Exchange Server 2007 più avanti in questo argomento.

• I gruppi di archiviazione non esistono più in Exchange 2010. Invece, esistono semplici database delle cassette postali, copie del database delle cassette postali e database delle cartelle pubbliche. Le interfacce di gestione principali per i database di Exchange sono state spostate all'interno di Exchange Management Console dal nodo Cassette postali in Configurazione server al nodo Cassette postali in Configurazione dell'organizzazione.

• La tecnologia Clustering di failover di Windows viene utilizzata da Exchange 2010, ma ora è gestita completamente da Exchange. Non è necessario che gli amministratori installino, creino o configurino uno qualsiasi degli aspetti del clustering di failover durante la distribuzione dei server Cassette postali a elevata disponibilità.

• Ogni server Cassette postali è in grado di ospitare fino a un massimo di 100 database e ogni database può avere fino a 16 copie.

• Oltre alla funzionalità Dumpster di trasporto, è 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 include 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. Nel caso di errore negli hop successivi prima che venga segnalato il completamento del recapito, il messaggio viene inviato nuovamente all'hop successivo. Per ulteriori informazioni sulla ridondanza shadow, vedere Informazioni sulla ridondanza shadow.

Distribuzione incrementale

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.

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.

Gruppi di disponibilità del database

Un gruppo di disponibilità del database (DAG) è composto da un massimo di 16 server Cassette postali che forniscono il ripristino automatico a livello del database da errori che hanno un impatto su singoli database. Qualsiasi server in un DAG è in grado di ospitare una copia del database delle cassette postali da qualsiasi altro server nel DAG. Quando un server viene aggiunto al DAG, funziona con altri server nel DAG 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.

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

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 nuovo 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 consente di aggiungere 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 con la mobilità del database, tutte le copie di un database hanno lo stesso GUID.

Di seguito sono riportate altre caratteristiche principali della mobilità del database:

• Dal momento che i gruppi di archiviazione sono stati rimossi da Exchange 2010, la replica continua ora funziona a livello del database. In Exchange 2010, i registri di transazioni vengono replicati su uno o più server Cassette postali e riprodotti in una copia di un database delle cassette postali archiviato su tali server.

• Un failover è un processo di attivazione automatico che può verificarsi a livello del database o a livello del server. Lo switchover è un processo di attivazione manuale che è possibile eseguire a livello di datacenter (sito), di server o di database.

• I nomi del database per Exchange 2010 devono essere univoci all'interno dell'organizzazione di Exchange.

• Quando un database delle cassette postali viene configurato con una o più copie del database, il percorso completo di tutte le copie del database deve essere identico su tutti i server Cassette postali che ospitano una copia.

• È possibile eseguire il backup di qualsiasi copia del database delle cassette postali (la copia attiva o qualsiasi copia passiva) utilizzando un'applicazione di backup basata su Copia shadow del volume (VSS) compatibile con Exchange.

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

Modifiche alla replica continua rispetto a Exchange Server 2007

La tecnologia di replica continua individuata in precedenza in CCR e SCR rimane in Exchange 2010 e viene sviluppata ulteriormente per supportare le nuove funzionalità di elevata disponibilità, ad esempio copie del database, mobilità del database e DAG. Di seguito sono descritte in breve alcune di queste nuove modifiche all'architettura:

• Dal momento che i gruppi di archiviazione sono stati rimossi da Exchange 2010, la replica continua ora funziona a livello del database. Exchange 2010 utilizza ancora un database ESE (Extensible Storage Engine) che produce i registri di transazioni replicati su uno o più percorsi e riprodotti in una o più copie di un database delle cassette postali.

• Dal momento che la funzionalità di riproduzione dei registri, eseguita dal servizio di replica di Microsoft Exchange in Exchange 2007 è stata spostata nella versione Exchange 2010 del servizio Archivio informazioni di Microsoft Exchange (store.exe), non esisteranno più le informazioni sulle prestazioni associate ai failover e agli switchover (perché viene utilizzata la nuova cache del database). Quando si verifica un failover o uno switchover, il database attivato presenta una cache operativa pronta per essere utilizzata.

• Il seeding e il log shipping non utilizza più Server Message Block (SMB) per il trasferimento dei dati. La replica continua di Exchange 2010 utilizza un'unica 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 log shipping non utilizza più un modello pull, in cui la copia passiva estrae i file di registro chiusi dalla copia attiva. Al contrario, la copia attiva inserisce i file di registro in ogni copia passiva configurata.

• 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 l'elevata disponibilità per i database delle cartelle pubbliche, si consiglia l'utilizzo della replica delle cartelle pubbliche. A differenza di CCR, dove non possono esistere più copie di un database di cartelle pubbliche nello stesso cluster, ciascun membro DAG può ospitare un database di cartelle pubbliche, ed è possibile usare la replica delle cartelle pubbliche per replicare cartelle pubbliche tra database di cartelle pubbliche ospitati nei membri DAG.

• Il componente LogReplayer del servizio Replica di Microsoft Exchange include una nuova logica di sospensione della riesecuzione del registro se la lunghezza della coda di copia supera un limite specifico. Se il numero dei registri nella coda di copia e maggiore del numero di file di registro copiati nella copia del database passiva, ma non ispezionato nella copia passiva, il servizio Replica di Microsoft Exchange sospenderà la riesecuzione del registro per la copia passiva e registrerà un evento di avviso 4110 nel registro eventi. Quando il numero dei file di registro nella coda di copia scende sotto il numero di file di registro copiati non ispezionati, il servizio Replica di Microsoft Exchange riprende la riesecuzione e registra un evento informativo 4111 nel registro eventi.

Anche diversi concetti utilizzati nella replica continua di Exchange 2007 rimangono in Exchange 2010. Sono compresi i concetti di gestione del failover, divergenza, l'utilizzo del dial di installazione automatica del database e l'utilizzo delle reti pubbliche e private.

Modifiche apportate al comportamento di routing quando il server Cassette postale e il server Trasporto Hub si trovano nello stesso DAG

Quando il server Trasporto Hub si trova nella stessa posizione di un server Cassette postali membro di un DAG, 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 DAG 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 su un server Trasporto Hub diverso.

Ad esempio, EX1 ospita il ruolo Cassette postali e Trasporto Hub ed è un membro di un DAG. Quando un messaggio arriva al server di trasporto EX1 per un destinatario la cui cassetta postale si trova anche sul server EX1, il trasporto reindirizzerà 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 in relazione al servizio Invio posta di Microsoft Exchange. Questo servizio è stato modificato. In questo modo i messaggi non verranno inviati al ruolo Trasporto Hub locale quando il server Trasporto Hub e Cassette postali è un membro di un DAG. 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.

Disponibilità end-to-end

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

• Resilienza di trasporto

• Spostamento cassetta postale online

• Protezione dei dati nativi di Exchange

• Risincronizzazione incrementale

• API di replica di terze parti

Resilienza di trasporto

Exchange 2007 ha introdotto la funzionalità Dumpster di trasporto del server Trasporto Hub. Il dumpster di trasporto mantiene una coda dei messaggi recapitati ai destinatari la cui cassetta postale si trovava in un ambiente CCR (e in Exchange 2007 SP1, in un ambiente LCR). Questa funzionalità era stata progettata per evitare la perdita di dati fornendo all'amministratore la possibilità di avere un server Cassette postali in cluster che entri automaticamente in modalità online su un altro nodo con una perdita di dati limitata. Ciò viene denominato failover con perdita di dati. Quando si verifica un failover con perdita di dati, il sistema automaticamente invia di nuovo i messaggi di posta elettronica inviati recentemente agli utenti sul server di cassette postali in cluster in errore utilizzando il dumper di trasporto dove verranno archiviati i messaggi di posta elettronica. Sebbene questa soluzione sia di aiuto nel ridurre la quantità di dati persi in failover, la soluzione protegge solo i dati persi nel sito e non fornisce una protezione per i messaggi in transito.

Exchange 2010 introduce specifiche modifiche all'architettura che consentono di risolvere entrambi i problemi. Dal momento che i DAG possono essere estesi nei siti di Active Directory, è possibile per un singolo database delle cassette postali di spostarsi tra i siti di Active Directory. A causa di questa modifica, la richiesta del dumpster di trasporto relativa a un nuovo recapito dopo un failover del database con perdita di dati viene ora inoltrata ai server Trasporto Hub sia nei nuovi siti di Active Directory che nei siti originali del database.

Un'altra modifica importante al dumpster di trasporto riguarda la capacità di ricevere il feedback dalla pipeline di replica. Quando i messaggi nel dumpster di trasporto sono stati replicati in tutte le copie del database delle cassette postali, vengono rimossi dal dumpster di trasporto. Ciò garantisce che solo i dati non replicati vengano mantenuti nel dumpster di trasporto.

Oltre alla funzionalità Dumpster di trasporto, è 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. Nel caso di errore negli hop successivi prima che venga segnalato il completamento del recapito, il messaggio viene inviato nuovamente all'hop successivo. 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 dei comandi utilizzata per eseguire il cmdlet Move-Mailbox era chiusa, lo spostamento veniva terminato e doveva essere riavviato dall'inizio.

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

I nuovi cmdlet per le richieste di spostamento in Exchange 2010 possono essere utilizzati per eseguire gli 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. Per ulteriori informazioni sullo spostamento online delle cassette postali, vedere Informazioni sulle richieste di spostamento.

Protezione dei dati nativi di Exchange

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 registri, rappresentato da una serie di file di registro 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 registro 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 registro 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.

Il reseeding incrementale forniva la capacità di correggere le divergenze nel flusso di registri 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.

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 registro 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

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 registro 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 registro 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 registro necessari nella copia del database.

API di replica di terze parti

Exchange 2010 include anche un nuovo 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. Per informazioni sui prodotti partner per Exchange 2010, vedere il sito Web Partner di Exchange 2010. Se si è un partner alla ricerca di informazioni su API di replica di terze parti, contattare il rappresentante Microsoft.

Funzionalità eliminate da Exchange Server 2007

Le seguenti funzionalità di Exchange 2007 e Exchange 2007 SP1 non esistono più in Exchange 2010. Le sostituzioni sono indicate nella tabella.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.