Gestione delle copie del database delle cassette postali

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

Ultima modifica dell'argomento: 2015-03-09

La mobilità del database costituisce una nuova architettura in Microsoft Exchange Server 2010 che rimuove il concetto di gruppo di archiviazione e separa un database delle cassette postali di Exchange 2010 da un server Cassette postali. Dato che sono stati rimossi i gruppi di archiviazione da Exchange 2010, la replica continua ora opera a livello di database. In Exchange 2010, i registri delle transazioni vengono replicati su uno o più server Cassette postali e riprodotti in una o più copie di un database delle cassette postali archiviate su quei server. Molti dei concetti di replica continua utilizzati in Exchange Server 2007 rimangono validi anche in Exchange 2010. Sono compresi i concetti di divergenza, l'utilizzo del dial di installazione automatica del database e l'utilizzo delle reti pubbliche e private.

Gestione delle copie del database

Dopo aver creato più copie di un database, è possibile utilizzare Exchange Management Console (EMC) e Exchange Management Shell per monitorare l'integrità e lo stato di ogni copia ed eseguire altre attività di gestione associate alle copie del database. Alcune attività di gestione che potrebbe essere necessario eseguire comprendono la sospensione o la ripresa, il seeding, il monitoraggio, la configurazione delle impostazioni e la rimozione di una copia del database.

Sospensione e ripresa delle copie del database

Per molte ragioni quali l'esecuzione della manutenzione pianificata, potrebbe essere necessario sospendere e riprendere l'attività di replica continua per una copia del database. Inoltre, alcune attività amministrative, quali il seeding, richiedono innanzitutto la sospensione di una copia del database. Si consiglia la sospensione di tutte le attività di replica quando viene modificato il percorso del database o dei relativi file di registro. È possibile sospendere e riprendere l'attività di copia del database utilizzando EMC o eseguendo i cmdlet Suspend-DatabaseCopy e Resume-DatabaseCopy in Shell. Per la procedura dettagliata sulla sospensione o la ripresa dell'attività di replica continua per una copia del database, vedere Sospensione o ripresa di una copia del database delle cassette postali.

Il troncamento dei registri non si verifica per la copia attiva del database delle cassette postali quando vengono sospese una o più copie passive. Se le attività di manutenzione pianificata richiedono un lungo periodo di tempo (ad esempio, diversi giorni), potrebbe verificarsi un notevole accumulo di file di registro. Per evitare che l'unità di registro si riempi di registri di transazioni, è possibile rimuovere la copia passiva del database interessata, invece di sospenderla. Una volta completata la manutenzione pianificata, è possibile aggiungere di nuovo la copia passiva del database.

Seeding di una copia del database

Il seeding, denominato anche aggiornamento, indica il processo in cui un database, vuoto o una copia del database di produzione, viene aggiunto al percorso della copia di destinazione su un altro server Cassette postali nello stesso gruppo di disponibilità del database (DAG) del database di produzione. Questo diventa il database di riferimento per la copia gestita da quel server.

In base alla situazione, il seeding può indicare un processo avviato automaticamente o manualmente. Quando viene aggiunta una copia del database, viene effettuato il seeding automatico della copia, a condizione che il server di destinazione e la relativa archiviazione siano configurati correttamente. Se si desidera il seeding manuale di una copia del database e non il seeding automatico durante la creazione della copia, è possibile utilizzare il parametro SeedingPostponed quando si esegue il cmdlet Add-MailboxDatabaseCopy.

Raramente le copie del database necessitano di un nuovo seeding dopo quello iniziale. Ma se fosse necessario o se si desidera effettuare il seeding manualmente invece che consentire al sistema di effettuarlo automaticamente, queste attività possono essere eseguite utilizzando la procedura guidata Aggiorna copia database in EMC o utilizzando il cmdlet Update-MailboxDatabaseCopy in Shell. Prima di effettuare il seeding di una copia del database, è necessario prima sospendere la copia del database delle cassette postali. Per la procedura dettagliata relativa al seeding di una copia del database, vedere Aggiornamento di una copia del database delle cassette postali.

Una volta completata una operazione di seeding automatico, la replica per la copia del database delle cassette postali viene ripresa automaticamente. Se non si desidera la ripresa automatica della replica, è possibile utilizzare il parametro ManualResume durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy.

Scelta di cosa sottoporre a seeding

Quando si effettua un'operazione di seeding, si può scegliere se effettuarla per la copia del database delle cassette postali, per il catalogo di indicizzazione del contenuto della copia del database o per entrambi. La scelta predefinita della procedura guidata Aggiorna copia database e il cmdlet Update-MailboxDatabaseCopy è di sottoporre a seeding sia la copia del database delle cassette postali che la copia del catalogo di indicizzazione del contenuto. Per effettuare il seeding solo per la copia del database delle cassette postali e non per il catalogo di indicizzazione del contenuto, utilizzare il parametro DatabaseOnly durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy. Per effettuare il seeding solo per la copia del catalogo di indicizzazione del contenuto, utilizzare il parametro CatalogOnly durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy.

Selezione dell'origine del seeding

In Exchange 2007, la replica continua può sottoporre al seeding solo una copia del database copiandone la copia attiva. In Exchange 2010, qualsiasi copia del database integra può essere utilizzata come origine del seeding per un'altra copia di quel database. Tutto questo risulta particolarmente utile quando è presente un gruppo di disponibilità del database esteso su più ubicazioni fisiche. Ad esempio, si consideri una distribuzione del gruppo di disponibilità del database con quattro membri, in cui due (MBX1 e MBX2) si trovano a Portland (Oregon) e due (MBX3 e MBX4) si trovano a New York (New York). Il database delle cassette postali denominato DB1 è attivo su MBX1 e copie passive di DB1 sono presenti su MBX2 e MBX3. Durante l'aggiunta di una copia di DB1 a MBX4, si può utilizzare la copia su MBX3 come origine per il seeding e, così facendo, si evita di effettuare l'operazione sull'intero collegamento WAN (Wide Area Network) tra Portland e New York.

Per utilizzare una copia specifica come origine per il seeding durante l'aggiunta di una nuova copia del database, eseguire quanto segue:

• Utilizzare il parametro SeedingPostponed durante l'esecuzione del cmdlet Add-MailboxDatabaseCopy per aggiungere la copia del database. Se non si utilizza il parametro SeedingPostponed, sulla copia del database verrà esplicitamente effettuato il seeding utilizzando la copia attiva del database come origine.

• Utilizzare il parametro SourceServer durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy e specificare il server di origine desiderato per il seeding. Nell'esempio precedente, è necessario specificare MBX3 come server di origine. Se non si utilizza il parametro SourceServer, sulla copia del database verrà esplicitamente effettuato il seeding utilizzando la copia attiva del database come origine.

Seeding e reti

Oltre alla selezione di uno specifico server di origine per il seeding di una copia del database delle cassette postali, è anche possibile specificare le reti DAG da utilizzare ed eventualmente ignorare le impostazioni di compressione e crittografia della rete DAG durante l'operazione di seeding.

Per specificare le reti da utilizzare per il seeding, utilizzare il parametro Network quando durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy e specificare le reti DAG che si desidera utilizzare. Se non si utilizza il parametro Network, il sistema si comporta nel modo seguente per la selezione di una rete da utilizzare per l'operazione di seeding:

• Se i server di origine e di destinazione si trovano nella stessa subnet ed è stata configurata una rete di replica che comprende la subnet, verrà utilizzata la rete di replica.

• Se i server di origine e di destinazione si trovano in subnet diverse, anche se è stata configurata una rete di replica contenente queste subnet, per il seeding verrà utilizzata la rete client (MAPI).

• Se i server di origine e di destinazione si trovano in datacenter diversi, per il seeding verrà utilizzata la rete client (MAPI).

A livello di DAG, le reti DAG sono configurate per la crittografia e compressione. Per impostazione predefinita, la crittografia e la compressione vengono utilizzate solo per le comunicazioni su diverse subnet. Se l'origine e la destinazione si trovano in subnet diverse e il DAG è configurato con i valori predefiniti per NetworkCompression e NetworkEncryption, è possibile sostituire questi valori utilizzando rispettivamente i parametri NetworkCompressionOverride e NetworkEncryptionOverride, durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy.

Processo di seeding

Quando si avvia un processo di seeding utilizzando i cmdlet Add-MailboxDatabaseCopy o Update-MailboxDatabaseCopy, si effettuano le seguenti attività:

1. Le proprietà del database da Active Directory vengono lette per convalidare il database e i server specificati e per verificare l'esecuzione di Exchange 2010 da parte dei server di origine e di destinazione, entrambi membri dello stesso DAG, e che il database specificato non sia un database di ripristino. Vengono letti anche i percorsi dei file del database.

2. Le attività di preparazione ai controlli del seeding vengono effettuate dal servizio Replica di Microsoft Exchange sul server di destinazione.

3. Il servizio Replica di Microsoft Exchange sul server di destinazione consente di controllare la presenza del database e dei file di registro delle transazioni nelle directory dei file lette dai controlli di Active Directory nel passo 1.

4. Il servizio Replica di Microsoft Exchange consente di restituire le informazioni sullo stato dal server di destinazione all'interfaccia amministrativa da cui è stato eseguito il cmdlet.

5. Se tutti i controlli preliminari sono stati superati, viene richiesto di confermare l'operazione prima di continuare. Se si conferma l'operazione, il processo continua. Se si verifica un errore durante i controlli preliminari, viene riportato l'errore e l'operazione si interrompe.

6. L'operazione di seeding viene avviata dal servizio Replica di Microsoft Exchange sul server di destinazione.

7. Il servizio Replica di Microsoft Exchange consente di sospendere la replica del database per la copia attiva del database.

8. Le informazioni sullo stato del database vengono aggiornate dal servizio Replica di Microsoft Exchange per riflettere uno stato di seeding.

9. Se sul server di destinazione ancora non esistono le directory per i database di destinazione e i file di registro, queste vengono create.

10. Viene inoltrata una richiesta di seeding del database dal servizio Replica di Microsoft Exchange sul server di destinazione al servizio Replica di Microsoft Exchange sul server di origine utilizzando TCP. Questa richiesta e le successive comunicazioni per il seeding del database si verificano su una rete DAG configurata come rete di replica.

11. Il servizio Replica di Microsoft Exchange sul server di origine avvia un backup di flusso ESE (Extensible Storage Engine) tramite l'interfaccia del servizio Archivio informazioni di Microsoft Exchange.

12. Il servizio Archivio informazioni di Microsoft Exchange invia un flusso di dati del database al servizio Replica di Microsoft Exchange.

13. I dati del database vengono spostati dal servizio Replica di Microsoft Exchange del server di origine al servizio Replica di Microsoft Exchange del server di destinazione.

14. Il servizio Replica di Microsoft Exchange sul server di destinazione scrive la copia del database in una directory temporanea che si trova nella directory del database principale denominata temp-seeding.

15. L'operazione di backup del flusso sul server di origine termina quando viene raggiunta la fine del database.

16. L'operazione di scrittura sul server di destinazione viene completata e il database viene spostato dalla directory temp-seeding al percorso finale. La directory temp-seeding viene eliminata.

17. Sul server di destinazione, il servizio Replica di Microsoft Exchange inoltra una richiesta al servizio Ricerca di Microsoft Exchange per installare il catalogo di indicizzazione del contenuto per la copia del database, se esiste. Se esistono file di catalogo non aggiornati provenienti da un'istanza precedente della copia del database, l'operazione di installazione non andrà a buon fine, provocando la replica del catalogo dal server di origine. Allo stesso modo, se il catalogo non esiste e non esiste una nuova istanza della copia del database sul server di destinazione, è necessaria una copia del catalogo. Il servizio Replica di Microsoft Exchange indica al servizio Ricerca di Microsoft Exchange di sospendere le'indicizzazione per la copia del database mentre un nuovo catalogo viene copiato dall'origine.

18. Il servizio Replica di Microsoft Exchange sul server di destinazione invia una richiesta di seeding del catalogo al servizio Replica di Microsoft Exchange sul server di origine.

19. Sul server di origine, il servizio Replica di Microsoft Exchange richiede le informazioni sulla directory dal servizio Ricerca di Microsoft Exchange e richiede di sospendere l'indicizzazione.

20. Il servizio Ricerca di Microsoft Exchange sul server di origine restituisce le informazioni sulla directory del catalogo di ricerca al servizio Replica di Microsoft Exchange.

21. Il servizio Replica di Microsoft Exchange sul server di origine legge i file di catalogo dalla directory.

22. Il servizio Replica di Microsoft Exchange sul server di origine sposta i dati del catalogo al servizio Replica di Microsoft Exchange sul server di destinazione utilizzando una connessione su una rete di replica. Una volta completata l'operazione di lettura, il servizio Replica di Microsoft Exchange invia una richiesta al servizio Ricerca di Microsoft Exchange per riprendere l'indicizzazione del database di origine.

23. Se nella directory sono presenti file di catalogo sul server di destinazione, il servizio Replica di Microsoft Exchange sul server di destinazione li elimina.

24. Il servizio Replica di Microsoft Exchange sul server di destinazione scrive i dati del catalogo in una directory temporanea denominata CiSeed.Temp fino al completo trasferimento dei dati.

25. Il servizio Replica di Microsoft Exchange sposta tutti i dati del catalogo nel percorso finale.

26. Il servizio Replica di Microsoft Exchange sul server di destinazione riprende l'indicizzazione di ricerca sul database di destinazione.

27. Il servizio Replica di Microsoft Exchange sul server di destinazione restituisce lo stato di completamento.

28. Il risultato finale dell'operazione viene inviato all'interfaccia amministrativa da cui è stato chiamato il cmdlet.

Configurazione delle copie del database

Dopo aver creato una copia del database, è possibile visualizzare e modificare le impostazioni di configurazione, se necessario. È possibile visualizzare alcune informazioni di configurazione esaminando la pagina Proprietà di una copia del database in EMC. Si possono anche utilizzare i cmdlet Get-MailboxDatabase e Set-MailboxDatabaseCopy in Shell per visualizzare e configurare le impostazioni di copia del database, quali l'intervallo di riesecuzione, il tempo di ritardo di troncamento e l'ordine di preferenza dell'attivazione. Per la procedura dettagliata sulla visualizzazione e la configurazione delle impostazioni di copia del database, vedere Configurazione delle proprietà della copia del database delle cassette postali.

Utilizzo delle opzioni Intervallo di riesecuzione e Tempo di ritardo di troncamento

Le copie del database delle cassette postali supportano l'utilizzo dei valori Intervallo di riesecuzione e Tempo di ritardo di troncamento, entrambi espressi in minuti. Impostando un intervallo di riesecuzione, è possibile riportare una copia del database indietro a uno specifico momento. Impostando un tempo di ritardo di troncamento, è possibile utilizzare i registri su una copia passiva del database per eseguire il ripristino dei file di registro sulla copia attiva del database. Siccome entrambe le funzionalità comportano l'aumento temporaneo dei file di registro, il relativo utilizzo influenzerà la progettazione di archiviazione.

Intervallo di riesecuzione

L'intervallo di riesecuzione indica una proprietà della copia del database delle cassette postali che specifica il tempo, in minuti, del ritardo nella riesecuzione dei file di registro per la copia del database. L'intervallo di riesecuzione inizia da quando un file di registro è stato replicato sulla copia passiva e ha superato il controllo. Ritardando la riesecuzione dei registri sulla copia del database, si ha la possibilità di ripristinare il database a uno specifico momento nel passato. Una copia del database delle cassette postali, configurata con un intervallo di riesecuzione maggiore a 0, viene denominata copia ritardata del database delle cassette postali o semplicemente copia ritardata.

Una strategia che utilizza le copie del database e le funzionalità di conservazione in caso di dispute in Exchange 2010 può fornire protezione rispetto a una serie di errori che di solito causano la perdita di dati. Tuttavia, queste funzionalità non possono fornire sistemi di sicurezza contro la perdita dei dati in caso di danneggiamento della partizione logica che, sebbene raro, può causare la perdita di dati. Le copie ritardate sono pensate per prevenire la perdita dei dati in caso di danneggiamento della partizione logica. Generalmente, esistono due tipi di danneggiamento della partizione logica:

• Danneggiamento della partizione logica del database   Il checksum delle pagine del database corrisponde, ma i dati delle pagine sono errati logicamente. Questo può verificarsi se ESE tenta di scrivere una pagina del database e, sebbene il sistema operativo indichi che l'operazione è riuscita, i dati non siano stati scritti sul disco o siano stati scritti nel posto sbagliato. Questo viene definito rilevamento flush. Per prevenire la perdita dei dati a causa dei rilevamenti flush, ESE comprende un meccanismo di rilevazione flush nel database insieme a una funzionalità di correzione della pagina (ripristino pagina singola).

• Danneggiamento della partizione logica di archiviazione   I dati vengono aggiunti, eliminati o manipolati in modo imprevisto. Questi casi sono generalmente causati da applicazioni di terze parti. Generalmente, questa situazione viene percepita dall'utente come un danneggiamento. L'archivio di Exchange considera la transazione che ha causato il danneggiamento della partizione logica come una serie di operazioni MAPI valide. La funzionalità di conservazione in caso di dispute in Exchange 2010 fornisce protezione dal danneggiamento logico dell'archivio (in quanto impedisce l'eliminazione permanente dei contenuti da parte di un utente o un'applicazione). Tuttavia, possono esistere scenari in cui la cassetta postale di un utente è così danneggiata da rendere più facile il ripristino del database a un determinato momento prima del danneggiamento e la successiva esportazione della cassetta postale per recuperare i dati non danneggiati.

La combinazione delle copie del database, dei criteri di conservazione e del ripristino di singole pagine tramite ESE non offre sistemi di sicurezza nel caso di un danno gravissimo alla partizione logica dell'archivio, anche se raro. La decisione di utilizzare una copia del database con un intervallo di riesecuzione (copia ritardata) dipende dalle applicazioni di terze parti che si utilizzano e dalla cronologia dell'organizzazione con il danneggiamento della partizione logica dell'archivio.

Se si sceglie di utilizzare le copie ritardate, tenere presente le seguenti implicazioni del loro utilizzo:

• A differenza della replica continua di standby (SCR) in Exchange 2007, che disponeva di un intervallo di riesecuzione hardcoded di 50 file di registro, non esiste alcun numero hardcoded per i file di registro ritardati. Al contrario, l'intervallo di riesecuzione indica un valore configurato dall'amministratore e per impostazione predefinita è disabilitato.

• L'impostazione dell'intervallo di riesecuzione ha un valore predefinito pari a 0 giorni e un valore massimo di 14 giorni.

• Le copie ritardate non sono considerate copie altamente disponibili. Al contrario, sono progettate per eseguire un ripristino di emergenza, per proteggere da danneggiamenti logici dell'archivio.

• Quanto maggiore è l'intervallo di riesecuzione, più lungo sarà il processo di ripristino del database. In base al numero di file di registro che è necessario riprodurre durante il ripristino e della velocità a cui l'hardware può riprodurli, possono essere necessarie diverse ore per ripristinare un database.

• Si consiglia di determinare se le copie ritardate sono fondamentali per la strategia globale del ripristino di emergenza. Se sono fondamentali per la strategia, si consiglia l'utilizzo di più copie ritardate o l'impiego di un array ridondante di dischi indipendenti (RAID) per proteggere un'unica copia ritardata, se non si dispone di più copie ritardate. Se si smarrisce un disco o viene danneggiato, non si perde il punto di ripristino.

• Le copie ritardate non sono riparabili con la funzionalità di ripristino di singole pagine tramite ESE. Se in una copia ritardata viene riscontrato il danneggiamento di una pagina del database (ad esempio, un errore -1018), sarà necessario sottoporla a reseeding (operazione che le farà perdere l'aspetto di copia ritardata).

L'attivazione e il ripristino di una copia ritardata del database delle cassette postali è un processo semplice se si desidera che il database esegua di nuovo tutti i file di registro e renda corrente la copia del database. Se si desidera, invece, eseguire nuovamente i file di registro fino a un determinato momento, l'operazione può rivelarsi più complicata, in quanto è necessario manipolare manualmente i file di registro ed eseguire lo strumento Eseutil.

Per la procedura dettagliata relativa all'attivazione di una copia ritardata del database delle cassette postali, vedere Attivazione di una copia del database delle cassette postali ritardata.

Tempo di ritardo di troncamento

Il tempo di ritardo di troncamento indica una proprietà della copia del database delle cassette postali che specifica la quantità di tempo, in minuti, per ritardare l'eliminazione dei registri per la copia del database dopo la riesecuzione dei file di registro nella copia del database. Il tempo di ritardo di troncamento inizia quando un file di registro è stato replicato nella copia passiva, ha superato il controllo ed è stato correttamente rieseguito nella copia del database. Ritardando il troncamento dei file di registro dalla copia del database, si ha la possibilità di correggere gli errori che riguardano i file di registro per la copia attiva del database.

Copie del database e troncamento dei registri

Il troncamento dei registri funziona allo stesso modo sia in Exchange 2010 che in Exchange 2007. Il comportamento del troncamento viene determinato dalle impostazioni dell'intervallo di riesecuzione e del tempo di ritardo di troncamento per la copia.

Per ottenere il troncamento dei file di registro di una copia del database quando le impostazioni di intervallo vengono lasciate al valore predefinito di 0 (disabilitato), è necessario soddisfare i seguenti criteri:

• Deve essere disponibile una copia di backup del file di registro o deve essere abilitata la registrazione circolare.

• Il file di registro deve essere al di sotto del checkpoint (il file di registro minimo richiesto per il ripristino) del database.

• Tutte le altre copie ritardate devono avere ispezionato il file di registro.

• Tutte le altre copie (non ritardate) devono aver eseguito di nuovo il file di registro.

Per ottenere il troncamento di una copia ritardata del database, è necessario soddisfare i seguenti criteri:

• Il file di registro deve essere al di sotto del checkpoint per il database.

• Il file di registro deve essere precedente a ReplayLagTime + TruncationLagTime.

• Il file di registro deve essere stato troncato nella copia attiva.

Criterio di attivazione del database

Esistono scenari in cui si può creare un database delle cassette postali e impedire al sistema di attivare automaticamente quella copia nel caso si verifichi un errore. Ad esempio:

• Se si distribuiscono una o più copie del database delle cassette postali a un secondo datacenter o a un datacenter in standby.

• Se si configura una copia del database come copia ritardata per il ripristino.

• Se si stanno eseguendo operazioni di manutenzione o di aggiornamento di un server.

In ciascuno degli scenari precedenti, esistono copie del database che il sistema non deve attivare automaticamente. Per impedire l'attivazione automatica di una copia del database delle cassette postali da parte del sistema, è possibile configurare la copia come bloccata (sospesa) per l'attivazione. In questo modo, il sistema può mantenere aggiornato il database tramite la distribuzione e la riesecuzione dei file di registro, ma non può attivare automaticamente e utilizzare la copia. Le copie bloccate per l'attivazione devono essere attivate manualmente da un amministratore. È possibile configurare i criteri di attivazione del database utilizzando il cmdlet Set-MailboxServer per impostare il parametro DatabaseCopyAutoActivationPolicy su Bloccato.

Per ulteriori informazioni sulla configurazione del criterio di attivazione del database, vedere Configurazione del criteri di attivazione per una copia di database delle cassette postali.

Bilanciamento delle copie del database

A causa della natura intrinseca dei gruppi DAG, come conseguenza dei switchover e dei failover del database, le copie attive del database delle cassette postali modificheranno gli host più volte durante il ciclo di vita di un gruppo DAG. Di conseguenza, i gruppi DAG possono diventare non bilanciati in termini di distribuzione delle copie attive del database delle cassette postali. Nella tabella seguente viene illustrato un esempio di un gruppo DAG che dispone di quattro database con quattro copie di ogni database (per un totale di 16 database su ogni server) con una distribuzione non uniforme delle copie attive del database.

Gruppo DAG con una distribuzione non bilanciata delle copie attive

Nell'esempio precedente, esistono quattro copie di ogni database, quindi solo quattro valori possibili per la preferenza di attivazione (1, 2, 3 o 4). Nella colonna Elenco conteggio delle preferenze viene visualizzato il conteggio del numero di database con ogni valore. Ad esempio, in EX3 esistono 13 copie del database con la preferenza di attivazione 1, due copie con la preferenza di attivazione 2, una copia con la preferenza di attivazione 3 e nessuna copia con la preferenza di attivazione 4.

Come è possibile vedere, questo gruppo DAG non è bilanciato in termini di numero dei database attivi e passivi ospitati da ogni membro DAG o di conteggio delle preferenze di attivazione dei database ospitati.

Per bilanciare le copie attive dei database delle cassette postali in un gruppo DAG, è possibile utilizzare lo script RedistributeActiveDatabases.ps1. Questo script sposta i database tra le copie per cercare di avere un numero uguale di database installati su ogni server del gruppo DAG. Se necessario, lo script tenta di bilanciare anche i database attivi tra i siti.

Lo script fornisce due opzioni per il bilanciamento delle copie attive del database all'interno di un gruppo DAG:

• BalanceDbsByActivationPreference   Quando questa opzione viene specificata, lo script tenta di spostare i database nella copia preferita (in base alla preferenza di attivazione) indipendentemente dal sito di Active Directory.

• BalanceDbsByActivationPreference   Quando questa opzione viene specificata, lo script tenta di spostare i database attivi nella copia preferita, mentre tenta di bilanciare anche i database attivi all'interno di ogni sito di Active Directory.

Dopo l'esecuzione dello script con la prima opzione, il precedente gruppo DAG non bilanciato diventa bilanciato, come mostrato nella tabella seguente.

Gruppo DAG con una distribuzione bilanciata delle copie attive

Come mostrato nella tabella precedente, il gruppo DAG è ora bilanciato in termini di numero dei database attivi e passivi su ogni server e di preferenza di attivazione tra i server.

Nella seguente tabella, vengono elencati i parametri disponibili per lo script RedistributeActiveDatabases.ps1.

Parametri dello script RedistributeActiveDatabases.ps1

Esempi di RedistributeActiveDatabases.ps1

In questo esempio, viene mostrata la distribuzione corrente del database per un gruppo DAG, compreso l'elenco conteggio delle preferenze.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

In questo esempio, le copie attive del database delle cassette postali in un gruppo DAG vengono ridistribuite e bilanciate utilizzando la preferenza di attivazione.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

In questo esempio, le copie attive del database delle cassette postali in un gruppo DAG vengono ridistribuite e bilanciate utilizzando la preferenza di attivazione e viene prodotto un riepilogo della distribuzione.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Monitoraggio delle copie del database

Una copia del database costituisce la prima difesa contro gli errori che si verificano nella copia attiva del database. Comunque, è molto importante monitorare l'integrità e lo stato delle copie del database per assicurarne la disponibilità quando necessario. È possibile visualizzare alcune informazioni sull'integrità e lo stato esaminando la pagina Proprietà di una copia del database in EMC. È possibile utilizzare anche il cmdlet Get-MailboxDatabaseCopyStatus in Shell per visualizzare una serie di informazioni sullo stato di una copia del database.

Per ulteriori informazioni sul monitoraggio delle copie del database, vedere Monitoraggio della disponibilità elevata e della resilienza del sito.

Eliminazione di una copia del database

Una copia del database può essere rimossa in qualunque momento utilizzando EMC o il cmdlet Remove-MailboxDatabaseCopy in Shell. Una volta rimossa una copia del database, è necessario eliminare manualmente tutti i file di registro del database e delle transazioni dal server da cui viene rimossa la copia del database. Per la procedura dettagliata relativa all'eliminazione di una copia del database, vedere Eliminazione di una copia del database delle cassette postali.

Switchover del database

Il server Cassette postali che ospita la copia attiva di un database viene denominato master del database delle cassette postali. Il processo di attivazione di una copia passiva del database modifica il master per il database delle cassette postali e converte la copia passiva nella nuova copia attiva. Questo processo viene denominato switchover del database. In uno switchover del database, la copia attiva di un database viene disinstallata da un server Cassette postali e una copia passiva di quel database viene installata come nuova copia attiva del database delle cassette postali su un altro server Cassette postali. Quando si esegue uno switchover, è possibile sostituire l'impostazione dial di installazione del database per il nuovo master del database delle cassette postali.

È possibile individuare rapidamente quale server Cassette postali è il master del database delle cassette postali corrente consultando la colonna Stato copia nella scheda Copie database in EMC. Solo la copia attiva avrà lo stato Installato. Tutte le altre copie del database visualizzeranno lo stato corrente di replica per la copia del database. È possibile eseguire uno switchover utilizzando la procedura guidata di spostamento del master del database delle cassette postali o utilizzando il cmdlet Move-ActiveMailboxDatabase in Shell.

Esistono molti controlli interni che verranno eseguiti prima di attivare una copia passiva:

• Viene controllato lo stato della copia del database. Se la copia del database ha lo stato non riuscito, lo switchover viene bloccato. È possibile modificare questo comportamento e non eseguire il controllo di integrità utilizzando il parametro SkipHealthChecks del cmdlet Move-ActiveMailboxDatabase. Questo parametro consente di spostare la copia attiva in una copia del database con lo stato non riuscito.

• Viene controllata la lunghezza della coda di copia e la lunghezza della coda di riesecuzione per la copia del database per assicurarsi che i valori rientrino nei criteri configurati. Inoltre, la copia del database viene controllata per assicurarsi che non sia attualmente in uso come origine per il seeding. Se i valori di lunghezza delle code non rientrano nei criteri configurati o se il database è attualmente utilizzato come origine per il seeding, lo switchover viene bloccato. È possibile ignorare questo comportamento e non eseguire questi controlli utilizzando il parametro SkipLagChecks del cmdlet Move-ActiveMailboxDatabase. Questo parametro consente l'attivazione di una copia con code di copia e di riesecuzione che non rientrano nei criteri configurati.

• Viene controllato lo stato del catalogo di ricerca (indice dei contenuti) per la copia del database. Se il catalogo di ricerca non è aggiornato, non è integro o è danneggiato, lo switchover viene bloccato. È possibile ignorare questo comportamento e non eseguire il controllo del catalogo di ricerca utilizzando il parametro SkipClientExperienceChecks del cmdlet Move-ActiveMailboxDatabase. Questo parametro fa sì che questo tipo di ricerca ignori il controllo di integrità del catalogo. Se il catalogo di ricerca per la copia del database che si sta attivando non è integro o non è utilizzabile e viene utilizzato questo parametro per ignorare il controllo di integrità del catalogo e viene attivata la copia del database, sarà necessario sottoporre di nuovo il catalogo a indicizzazione o seeding.

Quando si esegue uno switchover del database, è possibile anche sostituire le impostazioni dial di installazione configurate per il server che ospita la copia passiva del database attivato. L'utilizzando del parametro MountDialOverride del cmdlet Move-ActiveMailboxDatabase indica al server di destinazione di ignorare le impostazioni dial di installazione e di utilizzare quelle specificate dal parametro MountDialOverride.

Per la procedura dettagliata relativa all'esecuzione dello switchover di una copia del database, vedere Attivazione di una copia database delle cassette postali. Per ulteriori informazioni sugli switchover del database, vedere Passaggi e failover.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.