Replica continua di standby: Portabilità del database
Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Ultima modifica dell'argomento: 2008-11-18
In questo argomento viene descritto dettagliatamente uno scenario in cui l'organizzazione Woodgrove Bank utilizza la replica continua di standby (SCR) e la portabilità del database per eseguire il ripristino a causa di un errore in un singolo database. In questo scenario, in un database di origine SCR vengono rilevati dei danni fisici e l'amministratore decide di attivare il database SCR di destinazione. Durante l'attivazione, la replica continua di standby viene disabilitata, il database SCR di destinazione viene montato come database di produzione e le cassette postali degli utenti vengono spostate. Dopo aver ripristinato l'accesso ai dati sui client, la replica continua di standby viene di nuovo abilitata in modo che nel gruppo di archiviazione vengano ripristinate ridondanza e protezione per la replica continua di standby di destinazione.
Replica continua di standby e portabilità del database
Woodgrove Bank ha distribuito Microsoft Exchange Server 2007 Service Pack 1 (SP1) e ha stabilito di utilizzare la replica continua di standby per fornire una copia ridondante di un gruppo di archiviazione su un server Cassette postali remoto. Entrambi i server Cassette postali si trovano nello stesso sito del servizio directory di Active Directory e sono configurati per utilizzare i server DNS integrati con Active Directory. L'intervallo di replica di Active Directory per il sito di Active Directory è configurato per 15 minuti.
La replica continua di standby è configurata in modo che i file di registro delle transazioni vengano replicati per un singolo gruppo di archiviazione, SG1, che contiene un unico database, MBX1. EXMBX1 è il computer SCR di origine e EXMBX2 è il computer SCR di destinazione. I percorsi dei file del gruppo di archiviazione (che comprendono i file di registro delle transazioni) e del file di database sono rispettivamente E:\SG1 e D:\SG1\MBX1.EDB. Questi percorsi vengono utilizzati sia nei computer di origine che di destinazione.
Tali assegnazioni sono state configurate utilizzando il seguente comando:
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
L'integrità e lo stato della replica continua di standby per SG1 sono stati verificati utilizzando i cmdlet Test-ReplicationHealth e Get-StorageGroupCopyStatus in Exchange Management Shell. Ad esempio:
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2 | fl
Per risparmiare tempo durante il processo di attivazione della replica continua di standby di destinazione, EXMBX2 viene configurato con un gruppo di archiviazione e un database che sarà utilizzato come parte delle operazioni di portabilità del database. Il gruppo di archiviazione e il database sono denominati rispettivamente SG1PORT e MBX1PORT.
Importante
SG1PORT e MBX1PORT sono separati dal gruppo di archiviazione SCR di destinazione e dai file di database. Pertanto, è necessario configurare i percorsi di SG1PORT e MBX1PORT con un percorso temporaneo che non entri in conflitto con i percorsi SCR di destinazione.
Nota
Una volta creato MBX1PORT, si consiglia di montarlo e quindi di smontarlo e di eliminare tutti i file del gruppo di archiviazione e il file di database.
Attivazione della replica continua di standby di destinazione
L'amministratore di messaggistica rileva una voce del registro eventi delle applicazioni che indica la presenza di un danneggiamento fisico nel database SCR di origine. Poiché la replica continua di standby è stata abilitata per SG1, si decide rapidamente di eseguire l'attivazione manuale del database SCR di destinazione per SG1 e di ripristinare la disponibilità dei dati. Per attivare la copia SCR di destinazione, è innanzitutto necessario smontare il database in SG1. Il database SCR di destinazione viene quindi reso utilizzabile per il montaggio e lo spostamento delle cassette postali nel database delle cassette postali interessato. Per eseguire questa operazione, procedere come segue:
Il database SCR di origine viene smontato utilizzando il seguente comando:
Dismount-Database EXMBX1\SG1\MBX1
Per disabilitare la replica continua di standby e rendere utilizzabile per il montaggio il database SCR di destinazione, è necessario eseguire il cmdlet Restore-StorageGroupCopy. Questa attività consente di contrassegnare il database del gruppo di archiviazione come montabile e di fornire un rapporto sull'eventuale perdita di dati causata dal montaggio del database nel gruppo di archiviazione. Viene inoltre verificato 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. Se mancano alcuni file di registro, durante l'operazione si cercherà di copiare i file di registro mancanti. La replica continua di standby è disabilitata e il database di destinazione viene reso utilizzabile per il montaggio tramite il seguente comando:
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
Importante
Se l'origine SCR non è disponibile, è necessario aggiungere il parametro Force al comando Restore-StorageGroupCopy.
Una volta completato il comando Restore-StorageGroupCopy, l'amministratore deve verificare se il database si trova in uno stato di chiusura normale. Se il database si trova in uno stato di chiusura anomala, l'amministratore può portare il database in uno stato di chiusura normale eseguendo la modalità di ripristino Exchange Server Database Utilities (Eseutil) (Eseutil /r) sul database. Per la procedura dettagliata relativa all'esecuzione della modalità di ripristino Eseutil, vedere Come eseguire Eseutil /R (Ripristino).
Nota
Se il prefisso del gruppo di archiviazione (ad esempio, E00 o E01) è lo stesso dell'origine SCR (EXMBX1\SG1) e del gruppo di archiviazione SCR di destinazione che verrà utilizzato per la portabilità del database (EXMBX2\SG1PORT), non sarà necessario eseguire Eseutil in modalità di ripristino. Nell'operazione di montaggio finale il database verrà portato in uno stato di chiusura normale dopo aver riprodotto tutti i file di registro replicati.
Con il database in stato di chiusura normale, l'amministratore esegue due comandi che consentono di aggiornare Active Directory con i nuovi percorsi dei file del gruppo di archiviazione e del file di database. Utilizzare i seguenti comandi per modificare i percorsi di SG1PORT e MBX1PORT dai percorsi temporanei ai percorsi del gruppo di archiviazione SCR di destinazione e dei file di database:
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath E:\SG1 -LogFolderPath E:\SG1 -ConfigurationOnly Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath D:\SG1\MBX1.EDB -ConfigurationOnly
È necessario quindi rendere riscrivibile il database durante un'operazione di ripristino. A tale scopo, selezionare la casella di controllo Database riscrivibile da un ripristino nelle proprietà dell'oggetto database in Exchange Management Console. È possibile eseguire questa attività anche utilizzando il seguente comando in Exchange Management Shell:
Set-Mailboxdatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
Una volta reso riscrivibile il database durante un ripristino, l'amministratore può montare il database utilizzando il seguente comando:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Dopo aver montato il database, le cassette postali presenti nel database SCR di origine devono essere spostate per puntare a MBX1PORT su EXMBX2. A tale scopo, eseguire il cmdlet Get-Mailbox ed eseguire il pipelining dell'output al cmdlet Move-Mailbox. Durante questo processo, è importante che Supervisore sistema di Microsoft Exchange e le cassette postali di sistema non siano inclusi nell'output dal cmdlet Get-Mailbox di cui è stata eseguita la pipeline al cmdlet Move-Mailbox. Per effettuare questa operazione, eseguire il comando riportato di seguito:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
A questo punto è disponibile l'accesso client a MBX1PORT. Tuttavia, l'accesso effettivo degli utenti alle cassette postali dopo lo spostamento da EXMBX1\SG1\MBX1 a EXMBX2\SG1PORT\MBX1PORT dipende da diversi fattori:
Latenza delle replica di Active Directory In base al numero di server di elenchi in linea, potrebbero essere necessari diversi minuti per la propoagazione dell'aggiornamento in tutto l'ambiente.
Metodo di accesso client I client di messaggistica che eseguono Microsoft Office Outlook 2007 e i client diversi da Outlook disporranno dell'accesso alla cassetta postale dell'utente dopo che i server di elenchi in linea utilizzati dal server Accesso client dell'utente sono stati aggiornati in base ai nuovi percorsi. I client di messaggistica che eseguono Outlook 2003 e versioni precedenti richiederanno l'aggiornamento del profilo di messaggistica del desktop dell'utente con il nuovo nome del server se il server originale è inattivo o in qualche modo non disponibile. Se il server originale è in linea e disponibile a rispondere alle richieste dei client, i client di messaggistica che eseguono Outlook 2003 e versioni precedenti avranno il proprio profilo di messaggistica del desktop aggiornato automaticamente dal server originale con il nome del nuovo server e non sarà necessario modificare tale profilo manualmente.
Ripristino della ridondanza dopo l'attivazione della destinazione SCR
Una volta consentito ai client di accedere alle proprie cassette postali e ai relativi dati, il passaggio finale è di stabilire di nuovo la ridondanza abilitando nuovamente la replica continua di standby. A tale scopo, rimuovere i gruppi di archiviazione e i file di database rimanenti da EXMBX1. Dopo aver rimosso i file, è possibile spostare i percorsi di EXMBX1\SG1\MBX1 in un percorso temporaneo e EXMBX1 può diventare una destinazione SCR di EXMBX2. Dopo aver completato questa operazione, la ridondanza sarà stata ripristinata nell'ambiente.