Comunicazioni

Replica continua di standby in Exchange Server 2007 Service Pack 1

Scott Schnoll

Panoramica:

• Configurazione della replica continua di standby
• Importanza della ridondanza
• Riduzione dei tempi di inattività con SCR

Con il Service Pack 1 vengono introdotte molte nuove funzioni e alcuni miglioramenti per Exchange 2007. Una delle nuove funzionalità, la replica continua di standby (SCR, Standby Continuous Replication), è stata progettata per fornire alle organizzazioni ridondanza nel centro dati e resilienza del sito. Come indicato dal nome, la replica SCR è ideata

per scenari che utilizzano o abilitano l'utilizzo dei server di ripristino di standby.

Chi ha già lavorato con la versione RTM (Release To Manufacturing) di Exchange 2007, sa che l'applicazione fornisce ridondanza all'interno del centro dati e resilienza del sito tramite le funzionalità di distribuzione dei log e il supporto per i cluster di failover di Windows®. Nella versione RTM, la distribuzione dei log, nota ufficialmente come replica continua, è disponibile in due forme: replica continua locale (LCR, Local Continuous Replication), come illustrato nella Figura 1 e replica continua cluster (CCR, Cluster Continuous Replication), come illustrato nella Figura 2.

Figura 1** Replica continua locale **

Figura 2** Distribuzione dei log su un secondo server in un cluster di failover di Windows tramite la replica CCR **

La replica continua fornisce disponibilità e ridondanza dei dati consentendo agli amministratori di attivare e tenere in linea una seconda copia di ciascun database delle cassette postali. Questa copia dei database rappresenta una prima linea di difesa da errori, perdita o danneggiamento di un database di produzione. Invece di sprecare tempo prezioso per recuperare un nastro di backup per il ripristino dei dati, è possibile attivare una copia di database e trasformarla in pochi minuti in un database di produzione.

SCR estende gli scenari in cui è possibile ottenere la disponibilità di dati e servizi per l'organizzazione. I nuovi scenari consentono di separare le topologie per la disponibilità elevata dalle tipologie per la resilienza del sito, nonché di distribuire configurazioni personalizzate in base alle esigenze specifiche dell'organizzazione in ciascuna area.

La versione RTM di Exchange 2007 garantisce ridondanza all'interno del centro dati e resilienza del sito ma, poiché le repliche LCR e CCR forniscono solo una singola copia aggiuntiva di ciascun database, è necessario scegliere tra resilienza e ridondanza. Si considerino, ad esempio, le funzionalità per la disponibilità di dati e servizi fornite dalla replica CCR. La distribuzione dei nodi attivi e passivi in un singolo centro dati garantisce la disponibilità di dati e servizi all'interno del centro dati, ma non la resilienza del sito, poiché entrambi i nodi si trovano nello stesso sito fisico. La distribuzione del nodo attivo in un centro dati e del nodo passivo in un centro dati secondario garantisce la resilienza del sito ma non la disponibilità nel centro dati, poiché il nodo passivo, che fornisce queste funzionalità, si trova in un centro dati secondario.

Grazie alla funzionalità SCR inclusa nel Service Pack 1, la possibilità di creare copie aggiuntive di ogni database implica che la disponibilità elevata e la resilienza del sito non siano reciprocamente esclusive. Come illustrato nella Figura 3, è possibile ad esempio combinare SCR con CCR per realizzare la replica locale dei gruppi di archiviazione in un centro dati principale (utilizzando CCR per la disponibilità elevata) e la replica remota in un centro dati secondario o di backup (utilizzando SCR per la resilienza del sito). Il centro dati secondario contiene un cluster di standby che è possibile attivare e predisporre rapidamente con un server cassette postali cluster sostitutivo in uno scenario di ripristino del sito.

Figura 3** Distribuzione di CCR nel centro dati di Redmond e di SCR nel centro dati di Quincy **(Fare clic sull'immagine per ingrandirla)

Nella Figura 3 viene illustrata una distribuzione aziendale con due centri dati, ciascuno con il proprio sito Active Directory®: Redmond e Quincy. Il sito Redmond si trova nel centro dati principale (produzione), mentre il sito Quincy si trova in un centro dati secondario (backup). CCR viene distribuito nel sito Redmond per garantire la ridondanza all'interno del centro dati. Le destinazioni SCR vengono configurate, insieme agli elementi dell'infrastruttura necessari per Exchange 2007, in un cluster di standby nel sito Quincy per ottenere la resilienza del sito. Questi elementi aggiuntivi dell'infrastruttura, che includono i server Accesso client e Trasporto Hub, i server Active Directory e DNS e l'accesso a Internet, possono essere risorse dedicate o non dedicate. Le risorse dedicate sono le risorse progettate per fornire il supporto solo per gli utenti del centro dati in cui risiedono. Le risorse non dedicate sono le risorse che supportano sia gli utenti nel centro dati locale che gli utenti in altre posizioni. La decisione di utilizzare risorse dedicate o non dedicate dipenderà dalle esigenze specifiche della propria organizzazione. Per ulteriori informazioni sulle risorse dedicate e non dedicate, vedere l'argomento della Guida in linea di Exchange Server 2007 "Configurazioni con resilienza del sito" all'indirizzo technet.microsoft.com/bb201662.aspx. Si noti l'utilizzo di un nuovo tipo di quorum di maggioranza dei nodi (MNS, Majority Node Set). In Exchange Server 2007 la replica CCR utilizza il quorum MNS con il testimone di condivisione file (FSW, File Share Witness) al posto del tradizionale nodo voter, come illustrato nella Figura 3.

Nella Figura 4 la combinazione di CCR e un ambiente SCR progettato per la resilienza fornisce diversi livelli di ridondanza per le cassette postali e i servizi ospitati sul server EXCLUS1, garantendo la protezione delle cassette postali da errori irreversibili su ogni scala.

Figura 4** Server cassette postali autonomi che utilizzano SCR per la replica di gruppi di archiviazione da un server a un altro **(Fare clic sull'immagine per ingrandirla)

Anche le organizzazioni di piccole e medie dimensioni possono trarre vantaggio dalla replica SCR. Come illustrato nella Figura 4, ad esempio, un'organizzazione può distribuire due server cassette postali autonomi (EXMBX1 e EXMBX2) e utilizzare SCR per la replica di alcuni o di tutti i gruppi di archiviazione da un server cassette postali all'altro.

Nell'esempio EXMBX1 ed EXMBX2 sono server di produzione con cinque gruppi di archiviazione attivi. Ciascun gruppo di archiviazione è un'origine SCR per una destinazione SCR corrispondente sull'altro server. In caso di errore di archiviazione o nel caso in cui un gruppo di archiviazione attivo configurato come origine SCR non sia disponibile, la copia di destinazione SCR può essere rapidamente attivata utilizzando alcune attività amministrative in Exchange Management Shell. L'utilizzo di Microsoft® Office Outlook® 2007 e delle funzionalità di individuazione automatica e portabilità del database di Exchange 2007 consente di ridurre, in modo significativo, i tempi di inattività in caso di perdita di uno o più gruppi di archiviazione attivi.

Origini e destinazioni SCR

Analogamente a quanto avviene con LCR e CCR, anche per la replica SCR vengono utilizzati i concetti di copia attiva e copia passiva di un gruppo di archiviazione, definiti rispettivamente origini e destinazioni SCR. Tuttavia, le origini e le destinazioni SCR sono copie di gruppi di archiviazione (non è possibile abilitare i gruppi di archiviazione di ripristino per la replica SCR).

Il punto di partenza per SCR (origine SCR) è rappresentato da un qualsiasi gruppo di archiviazione su un server cassette postali autonomo o su un server cassette postali cluster in un cluster a copia singola o in un ambiente CCR. È importante notare che, sebbene l'origine SCR possa essere rappresentata da un server cassette postali cluster, la replica SCR non costituisce una soluzione cluster e pertanto non richiede il servizio cluster di Windows. L'endpoint per la replica SCR (destinazione SCR) può essere rappresentato da un server cassette postali autonomo o da un nodo in un cluster di failover nel quale sia installato il ruolo Cassette postali, ma nel cui cluster non sia stato configurato alcun server cassette postali cluster.

Relazioni tra origini e destinazioni

Per ogni gruppo di archiviazione di origine SCR può esistere un numero illimitato di destinazioni SCR. Per un'origine, ad esempio, può esistere una destinazione che risiede nello stesso centro dati e un'altra residente in un centro dati diverso. Tuttavia, Microsoft consiglia di utilizzare non più di quattro destinazioni per ogni origine. Qualora si decida di utilizzare più di quattro destinazioni, è necessario valutarne il potenziale impatto sul server di origine SCR in termini di memoria, CPU e risorse del disco ed effettuare una pianificazione adeguata. Per ogni computer di destinazione SCR possono esistere più server di origine. È necessario che il Service Pack 1 per Exchange 2007 sia installato nel computer di origine e in quello di destinazione e che il sistema operativo sia supportato dal Service Pack 1 per Exchange 2007, ad esempio Windows Server® 2008 o Windows Server 2003 SP2. Tuttavia, indipendentemente dal sistema operativo utilizzato, SCR non fornisce il supporto per più sistemi operativi e richiede che il sistema operativo nell'origine SCR corrisponda al sistema operativo utilizzato in tutte le destinazioni SCR per l'origine in questione. Pertanto, se nell'origine SCR è installato Windows Server 2003, è necessario che Windows Server 2003 venga eseguito anche in tutte le destinazioni SCR per tale origine.

SCR è disponibile in Exchange 2007 Standard Edition. Se un server cassette postali cluster in un ambiente SCC o CCR viene utilizzato come origine SCR, è necessario utilizzare Exchange 2007 Enterprise Edition. In Exchange 2007 Enterprise Edition ciascuna destinazione SCR supporta un massimo di 50 istanze, ossia 50 gruppi di archiviazione replicati, mentre in Exchange 2007 Standard Edition viene supportato un massimo di cinque istanze

È necessario inoltre soddisfare i requisiti delle destinazioni SCR descritti di seguito. Innanzitutto, è necessario che i computer di origine e di destinazione risiedano nello stesso dominio di Active Directory, anche se possono risiedere nello stesso sito o in siti diversi di Active Directory. Inoltre, è necessario che per ciascun gruppo di archiviazione replicato con la funzionalità SCR i percorsi del file di registro e del database nell'origine e in tutte le rispettive destinazioni siano uguali. Infine, quando un nodo o un server viene configurato come destinazione SCR, non è possibile abilitare la replica LCR per alcun gruppo di archiviazione nel computer di destinazione SCR e non è possibile aggiungere alcun server cassette postali cluster al cluster di failover di standby.

Confronto della replica SCR con CCR e LCR

La replica SCR (come illustrato nella Figura 5) utilizza la stessa tecnologia di riesecuzione e di distribuzione dei log utilizzata da LCR e CCR per fornire nuove configurazioni e opzioni di distribuzione. Analogamente a LCR e CCR, i gruppi di archiviazione abilitati per SCR non possono contenere più di un database. Inoltre, non è possibile utilizzare SCR per un database di cartelle pubbliche se nell'organizzazione di Exchange sono presenti più database di cartelle pubbliche.

Figura 5** Utilizzo di SCR per la distribuzione dei log su un altro server o un nodo passivo in un cluster di failover **

La differenza principale rispetto alla replica SCR è rappresentata dal fatto che quest'ultima supporta più destinazioni per ogni gruppo di archiviazione, mentre le repliche LCR e CCR supportano una sola destinazione, ossia la copia passiva. Inoltre, a differenza di CCR e LCR, non è possibile eseguire il backup di alcuna copia SCR. In caso di utilizzo di SCR, le intestazioni del database per le destinazioni SCR vengono aggiornate e i file di registro vengono troncati quando per il gruppo di archiviazione dell'origine SCR vengono eseguiti backup supportati (o nel caso di CCR e LCR, quando si eseguono backup delle copie attive o passive del gruppo di archiviazione dell'origine SCR).

Analogamente a LCR e CCR, la distribuzione dei log con SCR è continua e prevede l'utilizzo di un modello di estrazione. Dopo che un nuovo file di registro è stato chiuso e denominato con il numero di sequenza di generazione del file di registro, il servizio di replica di Microsoft Exchange eseguito sul computer di destinazione SCR estrae i file di registro delle transazioni chiusi dal computer di origine SCR e, dopo averli controllati e convalidati, li sposta nella cartella dei file di registro per i gruppi di archiviazione corrispondente sul computer di destinazione SCR.

Ritardo dell'attività di riesecuzione

Dopo che i file di registro sono stati copiati nel computer di destinazione SCR, SCR consente di effettuare un'operazione non eseguibile con LCR e CCR. Anziché rieseguire immediatamente i file di registro nella copia del database, la replica SCR prevede un ritardo incorporato per l'attività di riesecuzione pari a 50 file di registro e impostato su 24 ore. SCR consente inoltre di specificare un ritardo aggiuntivo oltre ai ritardi incorporati. L'impostazione del ritardo per l'attività di riesecuzione si rivela utile in un'ampia gamma di scenari. Ad esempio, in caso di danneggiamento logico di un database attivo, il ritardo può impedire il danneggiamento logico del database di destinazione SCR.

Il ritardo dell'attività di riesecuzione configurato dall'amministratore viene impostato mediante il parametro ReplayLagTime, che stabilisce il periodo di tempo in cui il servizio di replica di Exchange rimane in attesa prima della riesecuzione dei file di registro che sono stati copiati nel computer di destinazione SCR. Il formato del parametro è Giorni.Ore:Minuti:Secondi e l'impostazione predefinita è 24 ore L'impostazione massima consentita per questo valore è sette giorni. L'impostazione minima consentita è 0 secondi, valore con cui si eliminano i ritardi nell'attività di riesecuzione dei registri al di sopra del ritardo predefinito relativo a 50 file di registro.

Oltre a ReplayLagTime, in Exchange esiste un ritardo incorporato specificato a livello di codice di 50 file di registro, indipendentemente dal valore di ReplayLagTime. Per determinare quando deve essere rieseguito un file di registro, in Exchange viene utilizzato il valore più elevato di ReplayLagTime o x file di registro, dove x = 50. Questa caratteristica rappresenta un'ulteriore salvaguardia rispetto all'esigenza di eseguire nuovamente il seeding di un gruppo di archiviazione nei casi in cui in un'origine SCR che utilizza la replica continua, ad esempio un server cassette postali cluster in un ambiente CCR, si verifichi un failover e sia necessario riportare in linea uno o più gruppi di archiviazione mediante il cmdlet Restore-StorageGroupCopy. Il seeding è un processo che prevede l'utilizzo delle API di backup di flusso ESE (Extensible Storage Engine) per la creazione di una copia in linea del database di origine SCR nel computer di destinazione SCR. Grazie al ritardo dell'attività di riesecuzione nelle destinazioni SCR, quando si verifica un failover con perdita di dati in un'origine SCR la necessità di un reseeding delle copie SCR viene ridotta al minimo, poiché la natura della perdita dei dati nell'origine SCR determina un riavvicinamento temporale delle due copie.

Ritardo del troncamento

Nella versione RTM di Exchange 2007 le regole vengono applicate in modo che, in un ambiente di replica continua, un file di registro non venga eliminato se non già inserito in un backup e rieseguito nella copia del database. Quando si utilizza la replica SCR, questa regola viene modificata. Nella replica SCR, che introduce il concetto di copie multiple del database, i file di registro nel computer di origine SCR possono essere troncati non appena ispezionati da tutti i computer di destinazione SCR. Il troncamento dei file di registro sul server di origine SCR non attende la riesecuzione di tutti i registri in tutte le destinazioni SCR, poiché è possibile configurare le copie delle destinazioni SCR definendo un significativo ritardo di riesecuzione dei registri.

È inoltre possibile specificare un ritardo aggiuntivo per il troncamento dei file di registro utilizzando un nuovo parametro denominato TruncationLagTime, che indica il periodo di tempo per cui il servizio di replica di Microsoft Exchange resta in attesa (nel formato Giorni.Ore:Minuti:Secondi) prima di troncare i file di registro copiati nel computer di destinazione SCR e rieseguiti nella copia del database. Il periodo di tempo viene considerato a partire dalla riesecuzione dei file di registro nella copia del database. L'impostazione massima consentita per il valore è sette giorni, mentre l'impostazione minima consentita è 0 secondi, sebbene questa impostazione elimini tutti i ritardi nell'attività di troncamento dei registri.

Per determinare l'eventuale necessità di troncamento dei file di registro, in un ambiente SCR viene eseguito ogni tre minuti un thread in background. Se la sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro del gruppo di archiviazione e il file di registro è precedente a ReplayLagTime + TruncationLagTime, verrà troncato un file di registro nella destinazione SCR.

In un ambiente LCR o CCR esteso con SCR, un file di registro nella destinazione SCR viene troncato quando sono soddisfatti i seguenti criteri: il backup del file di registro è stato eseguito, la sequenza di generazione dei file di registro è al di sotto del punto di arresto dei file di registro per il gruppo di archiviazione, la copia passiva del gruppo di archiviazione è in uno stato che consente il troncamento del file di registro e il file di registro è stato ispezionato da tutte le destinazioni SCR.

Attivazione e gestione della replica SCR

La replica SCR viene attivata mediante il cmdlet Enable-StorageGroupCopy in Exchange Management Shell, che è stato aggiornato in SP1 con nuovi parametri. Come descritto in precedenza, ReplayLagTime e TruncationLagTime consentono di controllare alcuni comportamenti delle destinazioni SCR. Un altro parametro, SeedingPostponed, può essere utilizzato per ignorare il seeding iniziale della destinazione SCR. Il rinvio del seeding può risultare utile in numerose situazioni. Si supponga, ad esempio, che il database nel gruppo di archiviazione abilitato per la replica SCR sia pari a 100 GB. È opportuno evitare che 100 GB di dati attraversino la rete durante i periodi di produzione di picco. Il parametro SeedingPostponed consente di abilitare la replica SCR immediatamente e di eseguire un'attività di seeding in un momento successivo Quando tutto è pronto, eseguire manualmente il seeding della destinazione SCR mediante il cmdlet Update-StorageGroupCopy.

Mentre i parametri sopra riportati sono facoltativi, un parametro di Enable-StorageGroupCopy è obbligatorio per la replica SCR: StandbyMachine. Questo parametro consente di specificare il nome del computer che conterrà la destinazione SCR. Il valore del parametro viene impostato come parte del valore per l'attributo msExchStandbyCopyMachines del gruppo di archiviazione abilitato per SCR. L'attributo msExchStandbyCopyMachines è una stringa Unicode multivalore che viene aggiunta allo schema di Active Directory quando Exchange 2007 SP1 viene introdotto nell'organizzazione di Exchange. Questo è uno dei motivi per cui SP1 richiede un aggiornamento dello schema per Active Directory.

Il parametro StandbyMachine è fondamentale per la replica SCR e in SP1 alcuni cmdlet sono stati aggiornati in modo da utilizzare questo parametro per l'attivazione e la gestione delle destinazioni SCR. I cmdlet aggiornati sono descritti nella Figura 6.

Figure 6 Cmdlet che utilizzano il parametro Stand­by­Machine

Attivazione delle destinazioni SCR

SCR fornisce una o più copie aggiornate dei dati, che possono essere utilizzate nel caso in cui i dati originali vadano persi o diventino inutilizzabili. Il processo che prevede l'utilizzo di una copia di destinazione SCR e la riconfigurazione di tale copia come database di produzione è noto come attivazione. L'attivazione viene eseguita nel corso del processo di ripristino, che prevede l'utilizzo della portabilità del database o di una delle due opzioni di ripristino del programma di installazione (/m:RecoverServer per ripristinare un server autonomo o /RecoverCMS per ripristinare un server cassette postali cluster).

Possibili utilizzi della replica SCR

Verrà ora illustrato come un'azienda fittizia può utilizzare la replica SCR e la portabilità del database per eseguire il ripristino in seguito a un errore di un database delle cassette postali. Dopo aver rilevato che il database di produzione è stato danneggiato, l'amministratore attiva il database di destinazione SCR utilizzando la portabilità del database.

L'organizzazione ha distribuito Exchange 2007 con SP1 e ha deciso di utilizzare la replica SCR per fornire una copia di un gruppo di archiviazione su un server cassette postali remoto. I server cassette postali di origine e di destinazione risiedono entrambi nello stesso sito Active Directory e sono configurati per l'utilizzo dei server DNS integrati in Active Directory. L'intervallo di replica di Active Directory è configurato per 15 minuti.

Attivazione della replica SCR e ripristino per la gestione temporanea

La replica SCR è configurata in modo che i file di registro delle transazioni vengano replicati per un singolo gruppo di archiviazione, SG1, che contiene un solo database, MBX1. I percorsi per i file del gruppo di archiviazione e del database sono C:\SG1 e C:\SG1\MBX1.EDB In questo caso, EXMBX1 rappresenta l'origine SCR e EXMBX2 rappresenta la destinazione SCR. Questa configurazione è illustrata di seguito:

Enable-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

Una volta attivata la replica SCR, lo stato di SCR per SG1 viene verificato mediante il cmdlet Get-StorageGroupCopyStatus:

Get-StorageGroupCopyStatus EXMBX1\SG1 
-StandbyMachine EXMBX2

Per risparmiare tempo durante il processo di attivazione della destinazione SCR, EXMBX2 viene preconfigurato con un gruppo di archiviazione, SG1PORT, e un database, MBX1PORT, che verrà utilizzato come parte delle operazioni di portabilità del database. SG1PORT e MBX1PORT sono separati dai file del database e del gruppo di archiviazione della destinazione SCR. Pertanto, i percorsi per SG1PORT e MBX1PORT vengono configurati con un percorso temporaneo che non sia in conflitto con i percorsi della destinazione SCR. SG1PORT e MBX1PORT verranno utilizzati solo come oggetti di portabilità del database; i file del gruppo di archiviazione e del database effettivi per SG1PORT non sono necessari. Per questo motivo, l'amministratore smonta il database MBX1PORT ed elimina tutti i file all'interno del gruppo di archiviazione. Gli oggetti gruppo di archiviazione e database restano in Active Directory in quanto verranno utilizzati in seguito per la portabilità del database durante il processo di ripristino.

Attivazione e ripristino

Una voce del registro eventi applicazioni indica che il database di origine SCR è fisicamente danneggiato. Poiché la replica SCR è stata attivata per SG1, verrà eseguita l'attivazione manuale del database di destinazione SCR per SG1 e si utilizzerà la portabilità del database per ripristinare la disponibilità dei dati. L'attivazione della copia di destinazione SCR inizia con lo smontaggio di MBX1 in SG1 mediante il seguente cmdlet:

Dismount-Database EXMBX1\SG1\MBX1

Il database di destinazione SCR viene quindi reso disponibile per il montaggio e le cassette postali originariamente presenti in MBX1 verranno spostate in MBX1PORT.

Il processo per disattivare SCR e rendere il database di destinazione SCR disponibile per il montaggio prevede l'esecuzione del cmdlet Restore-StorageGroupCopy. Questa attività contrassegna il database del gruppo di archiviazione come montabile e fornisce un report sull'eventuale perdita dei dati in seguito al montaggio del database nel gruppo di archiviazione. Consente inoltre di verificare che tutti i file di registro generati dalla copia attiva del gruppo di archiviazione siano presenti nel percorso dei file del gruppo di archiviazione della copia passiva. L'operazione tenterà di copiare anche i file di registro eventualmente mancanti. Per rendere il database di destinazione SCR disponibile per il montaggio viene utilizzato il seguente cmdlet:

Restore-StorageGroupCopy EXMBX1\SG1 
-StandbyMachine EXMBX2

In questo esempio, i file di registro del gruppo di archiviazione dell'origine SCR sono disponibili per la copia. Se questi file non sono disponibili, ad esempio perché il computer di origine SCR è inattivo, sarà necessario aggiungere all'attività Restore-StorageGroupCopy il parametro Force. In caso contrario, Restore-StorageGroupCopy tenterà di connettersi continuamente all'origine SCR per copiare tutti i file mancanti e, se l'origine SCR non è disponibile, l'attività Restore-StorageGroupCopy avrà esito negativo e il database non verrà reso disponibile per il montaggio. L'aggiunta del parametro Force indica all'attività Restore-StorageGroupCopy che i file di origine non sono disponibili e, in tal caso, l'attività ignora il tentativo di connessione e procede per rendere il database di destinazione SCR disponibile per il montaggio.

Dopo aver completato il comando Restore-StorageGroupCopy, l'amministratore dovrà verificare che il database sia in uno stato di chiusura normale. Se il database è nello stato di chiusura anomala (visitare il sito all'indirizzo technet.microsoft.com/aa996757.aspx), è necessario riportarlo allo stato di chiusura normale. Se il prefisso del file di registro per il gruppo di archiviazione, ad esempio E00 o E01, è lo stesso per l'origine SCR (EXMBX1\SG1) e il gruppo di archiviazione nella destinazione SCR (SG1PORT) che verrà utilizzato per la portabilità del database (EXMBX2\SG1PORT), non sarà necessario eseguire Eseutil in modalità di ripristino e l'operazione finale per il montaggio del database riporterà il database nello stato di chiusura normale dopo la riesecuzione di tutti i file di registro replicati. Se il database non è in uno stato di chiusura normale, sarà necessario eseguire sul database Utilità database di Exchange Server (Eseutil) in modalità di ripristino (Eseutil /r).

Quando il database è in uno stato di chiusura normale, è possibile eseguire due comandi che consentono di aggiornare Active Directory con i nuovi percorsi dei file del gruppo di archiviazione e del file del database. Questi comandi consentono di modificare i percorsi originali per SG1PORT e MBX1nei percorsi per il gruppo di archiviazione e il database gestiti (SG1PORT e MBX1PORT):

Move-StorageGroupPath EXMBX2\SG1PORT 
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT 
-EdbFilePath C:\SG1\MBX1PORT.EDB 
–ConfigurationOnly

È necessario includere nei comandi sopra riportati il parametro –ConfigurationOnly in modo che solo le impostazioni di configurazione per questi oggetti vengano aggiornate in Active Directory. Non è necessario spostare dati o file in quanto SCR ha già replicato i dati in C:\SG1 nella destinazione EXMBX2.

Il passaggio successivo prevede la configurazione del database (MBX1PORT) in modo da consentirne la sovrascrittura durante un'operazione di ripristino. Questa operazione può essere eseguita selezionando la casella di controllo per l'impostazione "Database riscrivibile da un ripristino" nelle proprietà dell'oggetto database in Exchange Management Console o utilizzando il seguente comando in Exchange Management Shell:

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT 
-AllowFileRestore:$true

Una volta configurato il database per la sovrascrittura, il passaggio successivo prevede il montaggio del database mediante il seguente comando:

Mount-Database EXMBX2\SG1PORT\MBX1PORT

Dopo aver montato il database, le cassette postali presenti nel database di origine SCR (SG1\MBX1) devono essere spostate nel database MBX1PORT in EXMBX2. È sufficiente eseguire il cmdlet Get-Mailbox e inviare l'output al cmdlet Move-Mailbox. Durante questo processo, è importante che il Supervisore sistema di Exchange e che le cassette postali di sistema non vengano inclusi nell'output inviato dal cmdlet Get-Mailbox al cmdlet Move-Mailbox. Non è necessario né consigliabile spostare gli oggetti cassetta postale. Per spostare tutte le cassette postali degli utenti ed escludere le cassette postali di sistema, utilizzare il seguente comando:

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly 
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT

A questo punto, l'accesso client a MBX1PORT è possibile. Tuttavia, la capacità degli utenti di accedere alle relative cassette postali dopo che sono state spostate da EXMBX1\SG1\MBX1 in EXMBX2\SG1PORT\MBX1PORT dipende dalla latenza di replica di Active Directory; in altre parole, a seconda del numero di server di elenchi in linea, la propagazione dell'aggiornamento all'interno dell'ambiente potrebbe richiedere molto tempo. È inoltre importante considerare i metodi di accesso client. I client di messaggistica che eseguono Outlook 2007 e i client non Outlook possono accedere alla cassetta postale dell'utente dopo che i server di elenchi in linea utilizzati dal server Accesso client dell'utente sono stati aggiornati con i nuovi percorsi. I client di messaggistica che eseguono Outlook 2003 e versioni precedenti richiedono che il profilo di messaggistica desktop dell'utente venga aggiornato con il nuovo nome del server.

Passaggi finali

Dopo che i client hanno eseguito l'accesso alle relative cassette postali e ai dati delle cassette postali, è necessario determinare il livello di ridondanza riattivando la replica SCR. A tale scopo, rimuovere tutti i file del database e del gruppo di archiviazione rimanenti da EXMBX1. Una volta rimossi i file, è possibile spostare i percorsi per EXMBX1\SG1\MBX1 in una posizione temporanea e configurare EXMBX1 come destinazione SCR di EXMBX2.

Scott Schnoll è Principal Technical Writer nel team di Exchange Server in Microsoft e scrive articoli correlati a Exchange Server 2007. Prima di unirsi a Microsoft, Scott ha scritto il libro Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) ed è stato l'autore principale di Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.