Gestione delle copie del database delle cassette postali

Si applica a: Exchange Server 2013

Dopo aver creato, configurato e popolato un gruppo di disponibilità del database (DAG) con i membri del server Cassette postali, è possibile aggiungere copie del database delle cassette postali in modo flessibile e granulare.

Gestione delle copie del database

Dopo aver creato più copie di un database, è possibile utilizzare l'interfaccia di amministrazione di Exchange o Shell per monitorare l'integrità e lo stato di ogni copia. È anche possibile eseguire altre attività di gestione associate alle copie del database. Ad esempio:

• Sospendere o riprendere una copia del database.
• Eseguire il seeding di una copia del database.
• Monitorare le copie dei database.
• Configurare le impostazioni di copia del database.
• Rimuovere una copia del database.

Sospensione e ripresa delle copie del database

La manutenzione pianificata, il seeding e altre attività di manutenzione potrebbero richiedere la sospensione e la ripresa dell'attività di replica continua per una copia del database.

È consigliabile sospendere tutte le attività di replica quando viene modificato il percorso del database o dei relativi file di log. È possibile sospendere e riprendere l'attività di copia del database utilizzando l'interfaccia di amministrazione di Exchange o eseguendo i cmdlet Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy in Shell. Per la procedura dettagliata su come sospendere o riprendere l'attività di replica continua per una copia del database, vedere Sospendere o riprendere una copia del database delle cassette postali.

Seeding di una copia del database

Il seeding (noto anche come aggiornamento) consiste nell'aggiungere un database vuoto o una copia del database di produzione in un altro server Cassette postali nello stesso gruppo di disponibilità del database del database attivo. Questo database diventa il database di base per la copia gestita da tale server.

In base alla situazione, il seeding può indicare un processo avviato automaticamente o manualmente. Quando viene aggiunta una copia del database, ne viene eseguito automaticamente il seeding, a condizione che il server di destinazione e la relativa archiviazione siano configurati correttamente.

Per eseguire manualmente il seeding di una copia del database senza il seeding automatico quando si crea la copia, utilizzare il parametro SeedingPostponed nel cmdlet Add-MailboxDatabaseCopy .

Raramente è necessario eseguire il reseeding delle copie dei database dopo il seeding iniziale. Tuttavia, se è necessario o si vuole eseguire manualmente il seeding di una copia del database, è possibile usare uno dei metodi seguenti:

• Aggiornamento guidato della copia del database delle cassette postali nell'interfaccia di amministrazione di Exchange.
• 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 di esecuzione del seeding di una copia di database, vedere Aggiornamento di una copia del database delle cassette postali.

Al termine di un'operazione di inizializzazione manuale, la replica per la copia del database delle cassette postali di cui è stato eseguito il seeding viene ripresa automaticamente. Se non si desidera che la replica venga ripresa automaticamente, è possibile utilizzare il parametro ManualResume nel cmdlet Update-MailboxDatabaseCopy .

Scelta di cosa sottoporre a seeding

Quando si esegue un'operazione di inizializzazione, sono disponibili le opzioni seguenti:

• Eseguire il seeding della copia del database delle cassette postali: questo comportamento è quello predefinito per la procedura guidata Aggiorna copia database cassette postali e per il cmdlet Update-MailboxDatabaseCopy .
• Eseguire il seeding del catalogo dell'indice del contenuto per la copia del database delle cassette postali: utilizzare il parametro DatabaseOnly nel cmdlet Update-MailboxDatabaseCopy .
• Eseguire il seeding sia della copia del database che della copia del catalogo dell'indice del contenuto: utilizzare il parametro CatalogOnly nel cmdlet Update-MailboxDatabaseCopy .

Selezione dell'origine del seeding

Qualsiasi copia del database integra può essere usata come origine di seeding per una copia aggiuntiva del database. Questa opzione è utile quando si estende un gruppo di disponibilità del database in più posizioni fisiche.

Si consideri, ad esempio, una distribuzione di quattro membri del gruppo di disponibilità del database:

• Due membri (MBX1 e MBX2) si trovano a Portland, Oregon. In MBX1 è attivo un database delle cassette postali denominato DB1.
• Due membri (MBX3 e MBX4) si trovano a New York, New York. Esistono copie passive di DB1 su MBX2 e MBX3.

Quando si aggiunge una copia di DB1 a MBX4, è disponibile l'opzione di utilizzare la copia su MBX3 come origine del seeding. Questa opzione evita il seeding sul collegamento WAN (Wide Area Network) tra Portland e New York.

Per usare una copia specifica come origine per il seeding quando si aggiunge una nuova copia del database, seguire questa procedura:

• Per aggiungere la copia del database, utilizzare il parametro SeedingPostponed nel cmdlet Add-MailboxDatabaseCopy . Se il parametro SeedingPostponed non viene usato, il seeding della copia del database viene eseguito in modo esplicito usando la copia attiva del database come origine.

• È possibile specificare il server di origine da usare per il seeding nei percorsi seguenti:

  • Nella procedura guidata Aggiorna copia database cassetta postale nell'interfaccia di amministrazione di Exchange.
  • Parametro SourceServer nel cmdlet Update-MailboxDatabaseCopy .

Nell'esempio precedente, è necessario specificare MBX3 come server di origine. Se il parametro SourceServer non viene usato, viene eseguito in modo esplicito il seeding della copia del database dalla copia attiva del database.

Seeding e reti

Oltre a selezionare un server di origine specifico per il seeding di una copia del database delle cassette postali, è anche possibile utilizzare Shell per:

• Specificare le reti DAG da usare.
• Facoltativamente, eseguire l'override delle impostazioni di compressione e crittografia della rete del gruppo di disponibilità del database durante l'operazione di inizializzazione.

Per specificare le reti che si desidera utilizzare per il seeding, utilizzare il parametro Network nel cmdlet Update-MailboxDatabaseCopy e specificare le reti del gruppo di disponibilità del database che si desidera utilizzare. Se non si utilizza il parametro Network , il sistema utilizza il comportamento predefinito seguente per selezionare una rete da utilizzare per l'operazione di seeding:

• Se il server di origine e il server di destinazione si trovano nella stessa subnet ed è configurata una rete di replica che include la subnet, viene utilizzata la rete di replica.

• Se il server di origine e il server di destinazione si trovano su subnet diverse, anche se è configurata una rete di replica contenente tali subnet, la rete client (MAPI) viene utilizzata per il seeding.

• Se il server di origine e quello di destinazione si trovano in centri dati diversi, per il seeding viene 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 su subnet diverse e il gruppo di disponibilità del database è configurato con i valori predefiniti per NetworkCompression e NetworkEncryption, è possibile sostituire questi valori utilizzando i parametri NetworkCompressionOverride e NetworkEncryptionOverride nel cmdlet Update-MailboxDatabaseCopy .

Processo di seeding

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

1. Le proprietà del database in Active Directory e i percorsi del database vengono lette per convalidare il database e i server specificati:

   • I server di origine e di destinazione eseguono Exchange 2013.
   • Il server di origine e quello di destinazione sono entrambi membri dello stesso gruppo di disponibilità del database.
   • Il database specificato non è un database di ripristino.

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

3. Il servizio di replica di Microsoft Exchange sul server di destinazione verifica la presenza di file di database e di registro delle transazioni dai controlli descritti nel passaggio 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 vengono superati, verrà 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. Il servizio di replica di Microsoft Exchange aggiorna le informazioni sullo stato in modo che riflettano uno stato di seeding.

9. Se il server di destinazione non ha già le directory per il database di destinazione e i file di log, vengono creati.

10. Una richiesta TCP per eseguire il seeding del database viene passata dal server di destinazione al server di origine nel servizio di replica di Microsoft Exchange. Questa richiesta e le comunicazioni successive per il seeding del database si verificano in 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 di replica di Microsoft Exchange sul server di destinazione scrive la copia del database in una directory temporanea situata 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 in una 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 di replica di Microsoft Exchange richiede le informazioni sulla directory al servizio di ricerca di Microsoft Exchange e richiede la sospensione dell'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 di 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 nell'interfaccia di amministrazione di Exchange.
• È possibile utilizzare i cmdlet Get-MailboxDatabase e Set-MailboxDatabaseCopy in Shell per visualizzare e configurare le impostazioni di copia del database. Ad esempio:
  • Tempo di ritardo nella riproduzione dei giochi.
  • Tempo di ritardo di troncamento.
  • Ordine delle preferenze di attivazione.

Per la procedura dettagliata su come visualizzare e configurare le 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. Poiché entrambe queste funzionalità determinano l'accumulo temporaneo di file di log, l'uso di una di esse influisce sulla progettazione dell'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. Il timer di ritardo di riproduzione inizia quando un file di log viene replicato nella copia passiva e supera correttamente l'ispezione. 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 tempo di ritardo di riproduzione maggiore di zero viene definita 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 2013 può fornire protezione rispetto a una serie di errori che di solito causano la perdita di dati. Tuttavia, queste funzionalità non possono fornire protezione contro la perdita di dati a causa della frequenza con cui si verificano danneggiamenti logici. Le copie ritardate sono progettate per evitare la perdita di dati a causa di un danneggiamento logico. Generalmente, esistono due tipi di danneggiamento della partizione logica:

• Danneggiamento logico del database: ESE tenta di scrivere una pagina di database e i dati non vengono mai scritti sul disco o vengono scritti nella posizione sbagliata. Questa situazione è indicata come un flush perso. 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 logico dell'archivio: i dati vengono aggiunti, eliminati o modificati in modi non previsti dall'utente. Questi casi sono in genere causati da applicazioni non Microsoft. È corruzione nel senso che l'utente la vede come corruzione. 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 blocco per controversia legale in Exchange 2013 fornisce protezione dal danneggiamento logico dell'archivio (perché impedisce a un utente o a un'applicazione di eliminare definitivamente il contenuto). Tuttavia, in alcuni scenari è possibile che una cassetta postale di un utente venga danneggiata a tal punto che potrebbe essere più semplice ripristinare il database e quindi esportare la cassetta postale dell'utente 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 o meno una copia del database con un ritardo di riproduzione (una copia ritardata) dipende dalle applicazioni non Microsoft in uso e dalla storia dell'organizzazione con il danneggiamento logico dell'archivio.

Le copie ritardate possono risolversi in Exchange 2013 quando si richiama la riproduzione automatica dei log per riprodurre i file di log in determinati scenari:

• Viene raggiunta una soglia di spazio su disco insufficiente.
• La copia ritardata presenta un danneggiamento fisico e deve essere patchata nella pagina.
• Sono disponibili meno di tre copie integre (solo attive o passive; le copie ritardate del database non vengono conteggiate) per più di 24 ore.

L'applicazione di patch alla pagina è disponibile per le copie ritardate tramite questa funzione di riproduzione automatica. Se il sistema rileva che l'applicazione di patch di pagina è necessaria per una copia ritardata, i registri vengono riprodotti automaticamente nella copia ritardata per eseguire l'applicazione di patch di pagina. Anche le copie ritardate richiamano questa funzionalità di riproduzione automatica negli scenari seguenti:

• Viene raggiunta una soglia di spazio su disco insufficiente.
• La copia ritardata viene rilevata come unica copia disponibile per un periodo di tempo specifico.

Il comportamento di riproduzione delle copie ritardate è disabilitato per impostazione predefinita e può essere abilitato utilizzando il comando seguente.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Una volta abilitata, la riproduzione avviene quando ci sono meno di tre copie. È possibile modificare il valore predefinito di 3, modificando il seguente valore di registro DWORD.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Per abilitare la riproduzione per il raggiungimento della soglia di spazio insufficiente su disco, è necessario configurare la seguente voce di registro.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Dopo aver configurato tutte le impostazioni di registro, riavviare il servizio Microsoft Exchange DAG Management per rendere effettive le modifiche.

Si consideri ad esempio un ambiente in cui un database dispone di quattro copie:

• Tre copie a disponibilità elevata.
• Una copia ritardata.
• L'impostazione predefinita viene utilizzata per ReplayLagManagerNumAvailableCopies.

Se una copia non ritardata è fuori servizio per qualsiasi motivo (ad esempio, la copia è sospesa), la copia ritardata riproduce automaticamente i file di log in 24 ore.

Se si sceglie di usare copie ritardate senza abilitare il ReplayLagManagerEnabled parametro, tenere presenti le implicazioni seguenti:

• Il tempo di ritardo di riproduzione è un valore configurato dall'amministratore. Per impostazione predefinita, il tempo di ritardo di riproduzione è 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. Sono invece progettati per scopi di ripristino di emergenza, per la protezione dal danneggiamento della logica dell'archivio.

• Maggiore è l'impostazione dell'intervallo di riesecuzione, più lungo sarà il processo di ripristino del database. Il ripristino di un database può richiedere diverse ore in base ai fattori seguenti:

  • Numero di file di log che devono essere riprodotti.
  • Velocità con cui l'hardware può riprodurre i file di log.

• Si consiglia di determinare se le copie ritardate sono fondamentali per la strategia globale del ripristino di emergenza. Se l'uso di queste funzioni è fondamentale per la strategia, è consigliabile eseguire le configurazioni seguenti:

  • Utilizzo di più copie ritardate.
  • Utilizzo di un array ridondante di dischi indipendenti (RAID) per proteggere una singola copia ritardata.

  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 una copia ritardata rileva un danneggiamento della pagina di database (ad esempio, un errore -1018), deve essere riavviata (perdendo l'aspetto ritardato della copia).

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 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 Exchange Server Utilità database (Eseutil.exe).

Per la procedura dettagliata su come attivare una copia ritardata del database delle cassette postali, vedere Attivazione di una copia ritardata del database delle cassette postali.

Intervallo di troncamento

Il tempo di ritardo di troncamento è una proprietà di una copia del database delle cassette postali. Specifica il numero di minuti per ritardare l'eliminazione del log per la copia del database dopo che il file di log viene riprodotto nella copia del database.

Il timer di ritardo di troncamento viene avviato dopo che un file di log è stato replicato nella copia passiva, ha superato correttamente l'ispezione e viene riprodotto correttamente nella copia del database.

Ritardando il troncamento dei file di log dalla copia del database, è possibile eseguire il ripristino da errori che interessano i file di log per la copia attiva del database.

Copie del database e troncamento dei registri

Il troncamento del log funziona allo stesso modo in Exchange 2013 rispetto a Exchange 2010. Le impostazioni di ritardo di riproduzione e di ritardo di troncamento per la copia del database determinano il comportamento di troncamento.

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:

• È necessario eseguire correttamente il backup del file di log o abilitare 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 esaminare il file di registro.
• Tutte le altre copie (non copie ritardate) devono riprodurre il file di log.

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 log deve essere troncato nella copia attiva.

In Exchange 2013, il troncamento del registro non si verifica su una copia attiva del database delle cassette postali quando vengono sospese una o più copie passive. Se le attività di manutenzione pianificate richiederanno un periodo di tempo prolungato, ad esempio diversi giorni, è possibile che si verifichi 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. Al termine della manutenzione pianificata, è possibile aggiungere nuovamente la copia passiva del database.

Exchange 2013 Service Pack 1 (SP1) introduce una nuova funzionalità denominata troncamento insufficiente, disabilitata per impostazione predefinita. Durante le normali operazioni, ogni copia del database mantiene i log che devono essere spediti ad altre copie del database. Tutte le copie del database devono confermare i fatti seguenti:

• Tutte le copie passive del database confermano di aver riprodotto i file di log.
• Tutte le copie ritardate del database confermano di aver ricevuto i file di log.

Questo comportamento di troncamento del log è quello predefinito.

Se la copia di un database passa in modalità non in linea, i file di registro iniziano ad accumulare sui dischi utilizzati dalle altre copie del database. Una copia del database interessata che rimane offline per un periodo di tempo prolungato può causare l'esaurimento dello spazio su disco delle altre copie del database.

Quando è attivato il troncamento espanso, il comportamento di troncamento è diverso. Ogni copia del database tiene traccia dello spazio libero sul disco e applica il comportamento di troncamento espanso se lo spazio è insufficiente. Per la copia attiva, lo straggler meno recente (la copia del database passiva meno recente nella riesecuzione del registro) viene ignorato e il troncamento rispetta le rimanenti copie passive meno recenti. La copia del database attiva è dove viene calcolato il troncamento globale. Le copie passive tentano di rispettare la decisione di troncamento presa sulla copia attiva. Nonostante l'implicazione del nome MinCopiesToProtect, Exchange ignora solo il ritardatario più vecchio noto al momento dell'esecuzione del troncamento. Per una copia passiva, se lo spazio si riduce, tronca autonomamente i file di log utilizzando i parametri configurati descritti nella tabella seguente.

Un database offline riportato online presenta i problemi seguenti:

• Nel database mancano i file di log eliminati dalle altre copie integre.
• Lo stato della copia del database è FailedAndSuspended.

Se Autoreseed è configurato, la copia interessata viene riavviata automaticamente. Se Autoreseed non è configurato, un amministratore deve eseguire manualmente il seeding della copia del database.

I parametri relativi al numero necessario di copie integre, la soglia relativa allo spazio libero su disco e il numero di registri da conservare, sono configurabili. Per impostazione predefinita, la soglia dello spazio libero su disco è 204.800 MB (200 GB) e il numero di log da mantenere è 100.000 (100 GB) per le copie passive e 10.000 (10 GB) per le copie attive.

È possibile abilitare il troncamento libero e configurare i parametri di troncamento libero modificando il Registro di sistema di Windows in ogni membro del gruppo di disponibilità del database. È possibile configurare tre valori del Registro di sistema, tutti memorizzati in HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. La chiave BackupInformation I valori DWORD seguenti non esistono per impostazione predefinita e devono essere creati manualmente. Nella tabella riportata di seguito, sono indicati i valori del Registro di sistema DWORD in BackupInformation:

Il LooseTruncation_MinLogsToProtect valore del Registro di sistema provoca un comportamento diverso per le copie di database attive e passive.

• Copie attive: specifica il numero di log aggiuntivi conservati prima dei log richiesti dalle copie passive protette e l'intervallo richiesto della copia attiva.
• Copie passive: specifica il numero di log gestiti dall'ultimo log disponibile. Un decimo di questo numero viene utilizzato anche per mantenere i log prima dell'intervallo richiesto di questa copia passiva.

I due limiti assicurano che le copie ritardate del database non occupino troppo spazio, poiché l'intervallo richiesto è in genere molto ampio.

Criterio di attivazione del database

I seguenti scenari indicano dove potrebbe essere necessario creare una copia del database delle cassette postali e impedire al sistema di attivare automaticamente tale copia dopo un errore:

• È possibile distribuire una o più copie del database delle cassette postali in un centro dati alternativo o di standby.
• Si configura una copia ritardata del database a scopo di ripristino.
• Si sta eseguendo una manutenzione o un aggiornamento del server.

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.

Questa configurazione consente al sistema di mantenere la valuta del database attraverso il log shipping e la riproduzione, ma impedisce al sistema di attivare e utilizzare automaticamente la copia.

L'amministratore deve bloccare manualmente le copie per l'attivazione. È possibile configurare i criteri di attivazione del database usando i metodi seguenti:

• Per server: usare il cmdlet Set-MailboxServer .
• Per database: utilizzare il valore Blocked del parametro DatabaseCopyAutoActivationPolicy nel cmdlet Set-MailboxDatabaseCopy .

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

Effetto degli spostamenti della cassetta postale sulla replica continua

In un database delle cassette postali molto trafficato con un'elevata frequenza di generazione dei registri, esiste una maggiore possibilità di perdita di dati se la replica nelle copie passive del database non riesce a tenere il passo con la generazione dei registri. Gli spostamenti delle cassette postali possono rappresentare un'elevata frequenza di generazione dei registri.

Exchange 2013 include un'API Data Guarantee. Il servizio di replica delle cassette postali di Microsoft Exchange (MRS) e altri servizi utilizzano questa API per controllare l'integrità dell'architettura di copia del database. Questo controllo di integrità si basa sul valore del parametro DataMoveReplicationConstraint impostato dal sistema o da un amministratore. Nello specifico, l'API Data Guarantee viene utilizzata per le seguenti verifiche:

• Integrità replica: conferma che è disponibile il numero prerequisito di copie del database.
• Scaricamento della replica: conferma che i file di log necessari sono stati riprodotti rispetto al numero prerequisito di copie del database.

Quando viene eseguito, il servizio API restituisce all'applicazione chiamante le seguenti informazioni di stato:

• Riprova: indica che sono presenti errori temporanei che impediscono il controllo di una condizione nel database.
• Soddisfatto: indica che il database soddisfa le condizioni richieste o che il database non viene replicato.
• NotSatisfied: indica che il database non soddisfa le condizioni richieste. Inoltre, all'applicazione chiamante viene fornita l'informazione relativa al motivo per cui è stata fornita la risposta NotSatisfied.

Il valore del parametro DataMoveReplicationConstraint per il database delle cassette postali determina il numero di copie del database da valutare come parte della richiesta. Il parametro DataMoveReplicationConstraint ha i seguenti valori possibili:

• None: quando si crea un database delle cassette postali, questo valore viene impostato per impostazione predefinita. Quando è impostato questo valore, le condizioni del servizio API di garanzia dei dati vengono ignorate. Questa impostazione deve essere utilizzata solo per i database delle cassette postali che non sono replicati.
• SecondCopy: questo valore è il valore predefinito quando si aggiunge la seconda copia di un database delle cassette postali. Quando è impostato questo valore, almeno una copia passiva del database deve soddisfare le condizioni del servizio API di garanzia dei dati.
• SecondDatacenter: quando questo valore è impostato, almeno una copia passiva del database in un altro sito di Active Directory deve soddisfare le condizioni dell'API Data Guarantee.
• AllDatacenters: quando questo valore è impostato, almeno una copia passiva del database in ogni sito di Active Directory deve soddisfare le condizioni dell'API Data Guarantee.
• AllCopies: quando questo valore è impostato, tutte le copie del database delle cassette postali devono soddisfare le condizioni dell'API Data Guarantee.

Controllo integrità replica

Quando viene eseguito il servizio API di garanzia dei dati per valutare l'integrità dell'infrastruttura della copia del database, vengono valutati vari elementi.

Controllo scaricamento replica

L'API Data Guarantee può essere usata anche per verificare che un numero prerequisito di copie del database abbia riprodotto i log delle transazioni richiesti. L'API verifica questo stato confrontando il timestamp dell'ultimo log riprodotto con il timestamp di commit del servizio chiamante. Nella maggior parte dei casi, questo timestamp è il timestamp dell'ultimo file di log contenente i dati necessari. L'API aggiunge altri cinque secondi per gestire l'asimmetria o la deriva dell'orologio del sistema.

• Se il timestamp di riproduzione è maggiore del timestamp di commit, il parametro DataMoveReplicationConstraint è soddisfatto.
• Se il timestamp di riproduzione è inferiore al timestamp di commit, DataMoveReplicationConstraint non è soddisfatto.

Prima di spostare un numero elevato di cassette postali da o verso database di replica all'interno di un gruppo di disponibilità del database, si consiglia di configurare il parametro DataMoveReplicationConstraint in ogni database delle cassette postali in base alla tabella seguente:

Bilanciamento delle copie del database

A causa della natura intrinseca dei DAG, in seguito a switchover e failover del database, le copie attive del database delle cassette postali cambiano host più volte nel corso della durata di un 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. Nella tabella precedente, EX3 contiene database con le seguenti configurazioni:

• 13 copie del database con una preferenza di attivazione pari a 1.
• Due copie con una preferenza di attivazione pari a 2.
• Una copia con una preferenza di attivazione pari a 3.
• Nessuna copia con una preferenza di attivazione di 4.

Come si può notare, questo gruppo di disponibilità del database non è bilanciato per i motivi seguenti:

• Il numero di database attivi ospitati da ogni membro del gruppo di disponibilità del database.
• Il numero di database passivi ospitati da ogni membro del gruppo di disponibilità del database.
• Conteggio delle preferenze di attivazione dei database ospitati.

È possibile usare lo RedistributeActiveDatabases.ps1 script per bilanciare le copie attive dei database delle cassette postali in un gruppo di disponibilità del database. 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 anche di bilanciare 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 si specifica questa opzione, lo script tenta di spostare i database nella copia preferita (in base alle preferenze di attivazione) senza tenere conto del sito di Active Directory.
• BalanceDbsBySiteAndActivationPreference: quando viene specificata questa opzione, lo script tenta di spostare i database attivi nella copia preferita, tentando anche di bilanciare i database attivi all'interno di ogni sito di Active Directory.

Dopo aver eseguito lo script con la prima opzione, il precedente gruppo di disponibilità del database sbilanciato viene bilanciato, come illustrato nella tabella seguente.

Gruppo DAG con una distribuzione bilanciata delle copie attive

Come illustrato nella tabella precedente, questo gruppo di disponibilità del database è ora bilanciato in base ai fattori seguenti:

• Il numero di database attivi e passivi in ogni server.
• Preferenza di attivazione tra i server.

La seguente tabella elenca 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 senza chiedere conferma.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

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. È fondamentale monitorare l'integrità e lo stato delle copie del database per assicurarsi che siano disponibili quando necessario.

• È possibile usare l'interfaccia di amministrazione di Exchange per visualizzare informazioni sulla copia del database. Ad esempio:
  • Lunghezza coda di copia.
  • Lunghezza coda di riproduzione.
  • Stato.
  • Informazioni sullo stato dell'indice dei contenuti.
• È possibile utilizzare il cmdlet Get-MailboxDatabaseCopyStatus in Shell per visualizzare un'ampia gamma di informazioni sullo stato di una copia del database.

Per altre informazioni sul monitoraggio delle copie del database, vedere Monitoraggio dei gruppi di disponibilità del database.

Eliminazione di una copia del database

Una copia del database può essere rimossa in qualunque momento utilizzando l'interfaccia di amministrazione di Exchange 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 su come eseguire il seeding di una copia di database, vedere Rimuovere 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 è noto come 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 eseguire facoltativamente l'override dell'impostazione del dial per il montaggio del database sul 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 a destra nella scheda Copie database nell'interfaccia di amministrazione di Exchange. È possibile eseguire uno switchover utilizzando il collegamento Attiva nell'interfaccia di amministrazione di Exchange o utilizzando il cmdlet Move-ActiveMailboxDatabase in Shell.

Ci sono diversi controlli interni che vengono fatti 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 ignorare questo comportamento e ignorare 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.

• La copia attiva del database viene controllata per vedere se questa rappresenta attualmente l'origine di un seeding per qualsiasi copia passiva del database. Se la copia attiva è attualmente utilizzata come origine del seeding, lo switchover viene bloccato. È possibile ignorare questo comportamento e ignorare il controllo dell'origine di seeding usando il parametro SkipActiveCopyChecks del cmdlet Move-ActiveMailboxDatabase . Questo parametro consente di spostare una copia attiva mentre viene usata come origine di un seeding. L'utilizzo di questo parametro fa sì che l'operazione di seeding venga annullata e considerata non riuscita.

• 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. Lo switchover è bloccato nei seguenti scenari:

  • I valori per le lunghezze delle code non rientrano nei criteri configurati.
  • Il database è attualmente usato come origine per il seeding.

  È possibile ignorare questo comportamento e ignorare 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 ignorare 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 è in uno stato non integro o inutilizzabile, è necessario eseguire di nuovo la ricerca per indicizzazione o eseguire il seeding del catalogo di ricerca.

Quando si esegue uno switchover del database, è anche possibile ignorare le impostazioni del comando di montaggio configurate per il server che ospita la copia passiva del database attivata. L'uso del parametro MountDialOverride del cmdlet Move-ActiveMailboxDatabase indica al server di destinazione di eseguire l'override delle proprie impostazioni di composizione di montaggio e di utilizzare l'impostazione specificata dal parametro MountDialOverride .

Per la procedura dettagliata su come eseguire il passaggio a una copia del database, vedere Attivazione di una copia del database delle cassette postali.