Gestire le copie del database delle cassette postali

SI APPLICA A:2016 2019 Edizione in abbonamento

In Exchange Server, è possibile utilizzare Exchange Management Console (EAC) o Exchange Management Shell per aggiungere copie del database delle cassette postali dopo la creazione, la configurazione e il popolamento di un gruppo di disponibilità del database (DAG) con membri del server Cassette postali.

Gestione delle copie del database

Dopo aver creato più copie di un database, è possibile utilizzare l'interfaccia di amministrazione di Exchange o Exchange Management Shell per eseguire le seguenti operazioni:

• Monitorare l'integrità e lo stato di ogni copia.
• 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

Per vari motivi, ad esempio per l'esecuzione di manutenzioni programmate, potrebbe essere necessario sospendere e riprendere l'attività di replica continua per una copia del database. Alcune attività amministrative, ad esempio il seeding, richiedono inoltre la sospensione di 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 Exchange Management 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, si verifica quando un database vuoto o una copia del database di produzione viene aggiunto al percorso di copia di destinazione in un altro server Cassette postali nello stesso gruppo di disponibilità del database attivo. Questo database diventa il database di base per la copia gestita da tale server.

A seconda della situazione, è possibile eseguire il seeding di un database usando un processo automatico o un processo manuale avviato dall'utente. Quando viene aggiunta una copia del database, viene eseguito automaticamente il seeding della copia se il server di destinazione e la relativa archiviazione sono configurati correttamente. Per eseguire manualmente il seeding di una copia del database e non si vuole che venga eseguito il seeding automatico durante la creazione della copia, è possibile utilizzare il parametro SeedingPostponed nel cmdlet Add-MailboxDatabaseCopy .

Raramente è necessario eseguire il reseeding delle copie del database dopo il seeding iniziale. Tuttavia, se è necessario eseguire il reseeding o eseguire manualmente il seeding di una copia del database invece di fare in modo che il sistema esegua automaticamente il seeding della copia, sono disponibili due opzioni:

• Utilizzare la Copia guidata aggiornamento database cassette postali nell'interfaccia di amministrazione di Exchange.
• Utilizzare il cmdlet Update-MailboxDatabaseCopy in Exchange Management 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 esegui un'operazione di inizializzazione, puoi scegliere di:

• Eseguire il seeding della copia del database delle cassette postali.
• Inizializzare il catalogo dell'indice del contenuto per la copia del database delle cassette postali.
• Eseguire il seeding sia della copia del database che della copia del catalogo dell'indice del contenuto.

La scelta predefinita della procedura guidata di aggiornamento della copia database delle cassette postali e del 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 eseguire il seeding solo della copia del database delle cassette postali senza eseguire il seeding del catalogo dell'indice dei contenuti, utilizzare il parametro DatabaseOnly nel cmdlet Update-MailboxDatabaseCopy .

Per eseguire il seeding solo della copia del catalogo dell'indice del contenuto, utilizzare il parametro CatalogOnly nel cmdlet Update-MailboxDatabaseCopy .

Selezione dell'origine del seeding

È possibile usare qualsiasi copia del database integra come origine di seeding per un'altra copia del database. Questa opzione è particolarmente utile quando un gruppo di disponibilità del database è esteso in più posizioni fisiche.

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

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

Quando si aggiunge una copia di DB1 a MBX4, è possibile utilizzare la copia su MBX3 come origine per il 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, è possibile seguire questa procedura:

• Utilizzare il parametro SeedingPostponed nel cmdlet Add-MailboxDatabaseCopy per aggiungere la copia del database. In caso contrario, viene eseguito in modo esplicito il seeding della copia del database usando la copia attiva del database come origine.

• È possibile specificare il server di origine da utilizzare nella procedura guidata Aggiorna copia database cassette postali nell'interfaccia di amministrazione di Exchange oppure è possibile utilizzare il parametro SourceServer nel cmdlet Update-MailboxDatabaseCopy per specificare il server di origine desiderato per il seeding.

  Nell'esempio precedente è necessario specificare MBX3 come server di origine. In caso contrario, 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 Exchange Management Shell per specificare le reti DAG da utilizzare. È possibile ignorare le impostazioni di compressione e crittografia della rete DAG durante l'operazione di seeding.

È possibile specificare le reti da utilizzare per il seeding utilizzando 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. Le impostazioni predefinite usano la crittografia e la compressione solo per le comunicazioni su subnet diverse. 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 di Active Directory vengono lette per convalidare il database e i server specificati e per verificare che i server di origine e di destinazione eseguano Exchange Server, che siano entrambi membri dello stesso gruppo di disponibilità del database 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 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 del database 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 servizio di replica di Microsoft Exchange sul server di destinazione al servizio di replica di Microsoft Exchange sul server di origine. 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 che l'indicizzazione venga sospesa.

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. È inoltre possibile utilizzare i cmdlet Get-MailboxDatabase e Set-MailboxDatabaseCopy in Exchange Management Shell per visualizzare e configurare le impostazioni di copia del database. Ad esempio, tempo di ritardo di riproduzione, tempo di ritardo di troncamento e ordine di preferenza 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

Il tempo di ritardo nella riproduzione è una proprietà di copia del database delle cassette postali che specifica la quantità di tempo, in minuti, per ritardare la riproduzione del 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 copie del database e le funzionalità di blocco per controversia legale in Exchange Server può fornire protezione contro una serie di errori che normalmente causerebbero la perdita di dati. Tuttavia, queste funzionalità non possono fornire protezione contro la perdita di dati a causa di danneggiamento logico. Anche se il danneggiamento logico è raro, può causare la perdita di dati. 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: il checksum delle pagine del database corrisponde, ma i dati nelle pagine sono logicamente errati. Questa situazione si verifica quando ESE tenta di scrivere una pagina di database. Anche se il sistema operativo restituisce un messaggio di esito positivo, i dati non vengono mai scritti nel disco o vengono scritti nella posizione sbagliata. Questa condizione viene definita scarico 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. Le applicazioni non Microsoft in genere causano questi casi. È generalmente considerato corruzione nel senso che l'utente lo 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 Server protegge dal danneggiamento logico dell'archivio (perché impedisce che il contenuto venga eliminato definitivamente da un utente o un'applicazione). Tuttavia, in alcuni scenari in cui una cassetta postale dell'utente diventa talmente danneggiata che sarebbe più semplice ripristinare il database a un punto nel tempo precedente al danneggiamento 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.

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

• Il tempo di ritardo di riproduzione è un valore configurato dall'amministratore. Per impostazione predefinita, il tempo di ritardo di riproduzione è disabilitato.

• L'impostazione del tempo di ritardo di riproduzione ha un'impostazione predefinita di zero giorni e un'impostazione massima 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 potrebbe richiedere diverse ore a causa di:

  • Numero di file di log da riprodurre.
  • La velocità con cui l'hardware può riprodurli.

• 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 possono essere patchate con la funzionalità di ripristino a pagina singola ESE. Se una copia ritardata rileva un danneggiamento della pagina di database (ad esempio, un errore -1018), è necessario eseguire nuovamente il seeding della copia. Il reseeding perde l'aspetto ritardato della copia.

Se si desidera che il database riproduca tutti i file di log e renda corrente la copia del database, l'attivazione e il recupero di una copia ritardata del database delle cassette postali è un processo semplice. Se si desidera riprodurre i file di log fino a un momento specifico, il processo è più difficile perché è necessario modificare manualmente i file di log ed eseguire Exchange Server Database Utilities (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 è la proprietà di una copia del database delle cassette postali che specifica il tempo in minuti per ritardare l'eliminazione del registro per la copia del database dopo che il file di registro è stato riprodotto 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 log funziona allo stesso modo in Exchange 2016 ed Exchange 2019 come in Exchange 2010. 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:

• Il backup del file di log è stato eseguito correttamente o la registrazione circolare è abilitata.
• 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 hanno ispezionato il file di log.
• Tutte le altre copie (ad eccezione delle copie ritardate) hanno riprodotto 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 viene troncato nella copia attiva.

In Exchange Server, il troncamento del registro non si verifica su una copia attiva del database delle cassette postali quando una o più copie passive vengono sospese. 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. Una volta completata la manutenzione pianificata, è possibile aggiungere di nuovo la copia passiva del database.

Exchange Server dispone ora di una funzionalità denominata troncamento indefinito disabilitata per impostazione predefinita. Durante le normali operazioni, ogni copia del database mantiene i log che devono essere spediti ad altre copie del database fino a quando tutte le copie di un database non confermano:

• Hanno riprodotto i file di log (copie passive).
• Hanno ricevuto i file di registro (copie ritardate).

Questo comportamento è quello predefinito per il troncamento del log. 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. Se la copia del database interessata resta in modalità non in linea per un lungo periodo, è possibile che le altre copie del database esauriscano lo spazio sul disco disponibile.

Il comportamento di troncamento è diverso quando sono abilitati il troncamento libero e la registrazione circolare. 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.

• Per una copia passiva, se lo spazio si riduce di numero, tronca autonomamente i file di log utilizzando i parametri configurati descritti più avanti nella tabella Valore del Registro di sistema. 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.

Quando il database offline viene riportato online, i file di log mancanti vengono eliminati dalle altre copie integre e lo stato della copia del database è FailedAndSuspended. In questo caso, se è configurato Autoreseed, viene eseguito nuovamente il seeding automatico della copia interessata. Se Autoreseed non è configurato, il seeding della copia del database deve essere eseguito manualmente da un amministratore.

Se la registrazione circolare è disabilitata, il troncamento libero rispetta tutti i backup eseguiti. Il troncamento libero non rimuove i file di log di cui non viene eseguito il backup.

Il troncamento è una funzionalità consigliata per l'architettura preferita in cui i backup non vengono usati e la registrazione circolare è abilitata.

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 di spazio libero su disco è pari a 204800 MB (200 GB) e il numero di registri da conservare è pari a 100.000 (100 GB) per le copie passive e 10.000 (10 GB) per le copie attive.

Se si abilita il troncamento espanso, la configurazione dei relativi parametri viene eseguita tramite modifica del Registro di sistema di Windows in ogni membro DAG. È possibile configurare 3 valori del Registro di sistema, 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:

Quando si usa il valore del Registro di sistema LooseTruncation_MinLogsToProtect, il comportamento è diverso per le copie di database attive e passive

• Attivo: il numero di log aggiuntivi conservati prima dei log richiesti dalle copie passive protette e l'intervallo richiesto della copia attiva.
• Passivo: 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 sono stati applicati per garantire che le copie ritardate del database non occupino troppo spazio, poiché l'intervallo richiesto è in genere molto ampio.

Criterio di attivazione del database

Esistono scenari in cui potrebbe essere necessario creare una copia del database delle cassette postali e impedire al sistema di attivarla automaticamente. Ad esempio, 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.

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.

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. Un amministratore deve attivare manualmente le copie bloccate per l'attivazione.

È possibile impostare il parametro DatabaseCopyAutoActivationPolicy su Blocked per:

• Un intero server utilizzando il cmdlet Set-MailboxServer .
• Una singola copia del database utilizzando il 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 occupato con una alta frequenza di generazione di registri, esiste una grande probabilità di perdita di dati se le repliche nelle copie del database passivo non sono allineate alla generazione dei registri. Uno scenario che può provocare una alta frequenza di generazione di registri è lo spostamento delle cassette postali. Exchange Server include un'API Data Guarantee utilizzata da servizi come Exchange Mailbox Replication Service (MRS) per controllare l'integrità dell'architettura di copia del database in base al valore del parametro DataMoveReplicationConstraint impostato dal sistema o da un amministratore. In particolare, il servizio API di garanzia dei dati può essere utilizzato per:

• Controllare l'integrità della replica: conferma che è disponibile il numero prerequisito di copie del database.

• Controlla lo scaricamento della replica: conferma che i file di log richiesti vengono 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 è 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.

In tutti gli scenari, la copia passiva del database deve soddisfare le condizioni seguenti:

• Essere integra.

• Avere una coda di riesecuzione entro 10 minuti dell'intervallo di riesecuzione.

• Avere una lunghezza della coda di copia inferiore a 10 registri.

• Avere una lunghezza media della coda di copia inferiore a 10 registri. La lunghezza media della coda di copia viene calcolata in base al numero di volte in cui l'applicazione ha eseguito query sullo stato del database.

Controllo scaricamento replica

Il servizio API di garanzia dei dati può essere utilizzato per convalidare che un numero prerequisito di copie del database hanno replicato i registri delle transazioni richiesti. Ciò viene verificato confrontando il timestamp dell'ultimo log riprodotto con quello del timestamp di commit del servizio chiamante (nella maggior parte dei casi, questo è il timestamp dell'ultimo file di log che contiene i dati necessari) più altri cinque secondi (per gestire l'inclinazione 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.

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 si può vedere, questo gruppo di disponibilità del database non è bilanciato in termini di numero dei database attivi e passivi ospitati da ogni membro del gruppo di disponibilità del database o in termini di conteggio delle preferenze di attivazione dei database ospitati.

È possibile utilizzare lo script RedistributeActiveDatabases.ps1 per bilanciare le copie del database delle cassette postali attivo attraverso il gruppo di disponibilità del database (DAG). 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 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 l'esecuzione dello script con la prima opzione, il precedente gruppo DAG non bilanciato diventa bilanciato, come mostrato nella tabella seguente.

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.

La seguente tabella elenca i parametri disponibili per lo 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

È possibile vedere una grande varietà di informazioni, incluso la lunghezza della coda di copia, lunghezza della coda di replica, informazioni di stato e stato dell'indice dei contenuti esaminando i dettagli di una copia del database nell'interfaccia di amministrazione di Exchange. È inoltre possibile utilizzare il cmdlet Get-MailboxDatabaseCopyStatus in Exchange Management Shell per visualizzare un'ampia gamma di informazioni sullo stato di una copia del database.

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

Eliminazione di una copia del database

È possibile rimuovere una copia del database in qualsiasi momento utilizzando l'interfaccia di amministrazione di Exchange o il cmdlet Remove-MailboxDatabaseCopy in Exchange Management 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 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 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 Exchange Management Shell.

Prima dell'attivazione di una copia passiva vengono eseguiti diversi controlli interni. In alcuni casi, il passaggio al database viene bloccato o annullato. In altri casi, è possibile usare i cmdlet per spostare o ignorare alcuni controlli.

• 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 in uno 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. 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 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 e si usa questo parametro per ignorare il controllo di integrità del catalogo e attivare la copia del database, è 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 della manopola 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 le impostazioni specificate dal parametro MountDialOverride .

Per la procedura dettagliata relativa all'esecuzione dello switchover di una copia del database, vedere Attivare una copia del database delle cassette postali.