Gestire le copie del database delle cassette postali
In Exchange Server, è possibile usare il Exchange Management Console (EAC) o Exchange Management Shell per aggiungere copie del database delle cassette postali dopo che un gruppo di disponibilità del database è stato creato, configurato e popolato con membri del server Cassette postali.
Gestione delle copie del database
Dopo aver creato più copie di un database, è possibile utilizzare EAC o Exchange Management Shell per monitorare l'integrità e lo stato di ogni copia e per 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 diversi motivi, ad esempio 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, ad esempio il seeding, richiedono 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 usando EAC 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, è il processo in cui viene aggiunto un database vuoto o una copia del database di produzione al percorso di copia di destinazione in un altro server Cassette postali nello stesso dag del database attivo. Questo diventa il database di riferimento per la copia gestita da quel server.
A seconda della situazione, è possibile eseguire il seeding di un database usando un processo automatico o un processo manuale avviato. 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 vuole 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 usare il parametro SeedingPostponed quando si esegue il cmdlet Add-MailboxDatabaseCopy .
Raramente è necessario reinsediare le copie del database dopo il seeding iniziale. Tuttavia, se è necessario eseguire il reseeding o se si vuole eseguire manualmente il seeding di una copia del database anziché impostare il sistema automaticamente come seeding della copia, sono disponibili due opzioni. È possibile reinsediare un database tramite l'aggiornamento guidato della copia del database delle cassette postali nell'interfaccia di amministrazione di Exchange o tramite 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.
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 esegue un'operazione di inizializzazione, è possibile scegliere di inizializzare la copia del database delle cassette postali, il catalogo dell'indice di contenuto per la copia del database delle cassette postali o sia la copia del database che la copia del catalogo dell'indice di 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 di contenuto, usare il parametro DatabaseOnly quando si esegue il 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
Qualsiasi copia integra del database 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. Quando si aggiunge una copia di DB1 a MBX4, è disponibile l'opzione di utilizzare la copia su MBX3 come origine del seeding. Nel fare ciò, si evita di effettuare il seeding attraverso il 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 eseguire le operazioni seguenti:
Utilizzare il parametro SeedingPostponed quando si esegue il cmdlet Add-MailboxDatabaseCopy per aggiungere la copia del database. Se non si usa il parametro SeedingPostponed , la copia del database verrà eseguita in modo esplicito usando la copia attiva del database come origine.
È possibile specificare il server di origine che si vuole usare come parte della procedura guidata Update Mailbox Database Copy nell'interfaccia di amministrazione di Exchange oppure è possibile utilizzare il parametro SourceServer quando si esegue il cmdlet Update-MailboxDatabaseCopy per specificare il server di origine desiderato per il seeding. Nell'esempio precedente, è necessario specificare MBX3 come server di origine. Se non si usa il parametro SourceServer , la copia del database verrà eseguita in modo esplicito 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 usare Exchange Management Shell per specificare quali reti del gruppo di disponibilità del database usare. È possibile eseguire l'override delle impostazioni di compressione e crittografia della rete dag durante l'operazione di inizializzazione.
È possibile specificare le reti da usare per il seeding usando il parametro Network durante l'esecuzione del cmdlet Update-MailboxDatabaseCopy e specificare le reti DAG da usare. Se non si usa il parametro Network , il sistema usa il comportamento predefinito seguente per selezionare una rete da usare 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. Le impostazioni predefinite usano la crittografia e la compressione solo per le comunicazioni in subnet diverse. 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 inizia un processo di seeding usando i cmdlet Add-MailboxDatabaseCopy o Update-MailboxDatabaseCopy , vengono eseguite le attività seguenti:
Le proprietà del database da 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, 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.
Le attività di preparazione ai controlli del seeding vengono effettuate dal servizio Replica di Microsoft Exchange sul server di destinazione.
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.
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.
Se sono stati superati tutti i controlli preliminari, 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.
L'operazione di seeding viene avviata dal servizio Replica di Microsoft Exchange sul server di destinazione.
Il servizio Replica di Microsoft Exchange consente di sospendere la replica del database per la copia attiva del database.
Le informazioni sullo stato del database vengono aggiornate dal servizio Replica di Microsoft Exchange per riflettere uno stato di seeding.
Se sul server di destinazione ancora non esistono le directory per i database di destinazione e i file di registro, queste vengono create.
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.
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.
Il servizio Archivio informazioni di Microsoft Exchange invia un flusso di dati del database al servizio Replica di Microsoft Exchange.
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.
Il servizio Replica di Microsoft Exchange nel server di destinazione scrive la copia del database in una directory temporanea che si trova nella directory principale del database denominata temp-seeding.
L'operazione di backup del flusso sul server di origine termina quando viene raggiunta la fine del database.
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.
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.
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.
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.
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.
Il servizio Replica di Microsoft Exchange sul server di origine legge i file di catalogo dalla directory.
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.
Se nella directory sono presenti file di catalogo sul server di destinazione, il servizio Replica di Microsoft Exchange sul server di destinazione li elimina.
Il servizio Replica di Microsoft Exchange nel server di destinazione scrive i dati del catalogo in una directory temporanea denominata CiSeed.Temp fino a quando i dati non vengono completamente trasferiti.
Il servizio Replica di Microsoft Exchange sposta tutti i dati del catalogo nel percorso finale.
Il servizio Replica di Microsoft Exchange sul server di destinazione riprende l'indicizzazione di ricerca sul database di destinazione.
Il servizio Replica di Microsoft Exchange sul server di destinazione restituisce lo stato di completamento.
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. È anche possibile usare i cmdlet Get-MailboxDatabase e Set-MailboxDatabaseCopy in Exchange Management Shell per visualizzare e configurare le impostazioni di copia del database, ad esempio l'ora di ritardo di riproduzione, il tempo di ritardo del troncamento e l'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. Siccome entrambe le funzionalità comportano l'aumento temporaneo dei file di registro, il relativo utilizzo influenzerà la progettazione di archiviazione.
Intervallo di riesecuzione
Il tempo di ritardo di riproduzione è una proprietà di copia del database della cassetta postale che specifica la quantità di tempo, in minuti, per ritardare la riproduzione del log 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 usa le copie del database e le funzionalità di conservazione per controversia legale in Exchange Server può offrire protezione da una serie di errori che normalmente causerebbero 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 logico del database: corrisponde al checksum delle pagine del database, ma i dati nelle pagine non sono logici. 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 logico dell'archivio: i dati vengono aggiunti, eliminati o modificati in modo che l'utente non si aspetti. 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 blocco per controversia legale in Exchange Server offre protezione dal danneggiamento logico dell'archivio (perché impedisce l'eliminazione definitiva del contenuto da parte di un utente o di un'applicazione). Tuttavia, esistono scenari per cui una cassetta postale utente raggiunge uno stato di danneggiamento tale che risulta più semplice ripristinare il database ad un momento precedente del danneggiamento e quindi esportare la cassetta postale utente per recuperare i dati corretti.
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:
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.
Maggiore è l'impostazione dell'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.
Non è possibile applicare patch alle copie con ritardo con la funzionalità di ripristino a pagina singola di ESE. Se una copia ritardata rileva un danneggiamento della pagina del database (ad esempio, un errore -1018), la copia dovrà essere reinviata. Il reseeding perderà l'aspetto lag della copia.
Se si desidera che il database rieseguire tutti i file di log e rendere corrente la copia del database, l'attivazione e il ripristino 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, la prosa è più difficile perché è necessario modificare manualmente i file di log ed eseguire Exchange Server Utilità di database (Eseutil.exe).
Per i passaggi dettagliati su come attivare una copia del database delle cassette postali in ritardo, vedere Attivare una copia del database delle cassette postali in ritardo.
Intervallo di troncamento
Il tempo di ritardo del troncamento è la proprietà di una copia del database della cassetta postale che specifica la quantità di tempo, espressa in minuti, per ritardare l'eliminazione del log per la copia del database dopo la riproduzione del file di log 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 del log funziona come 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:
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 (tranne quelle in ritardo) devono avere 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 registro deve essere stato troncato nella copia attiva.
In Exchange Server, il troncamento del log non si verifica in una copia attiva del database delle cassette postali quando una o più copie passive vengono sospese. 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.
Exchange Server ha ora una funzionalità denominata troncamento allentato disabilitata per impostazione predefinita. Durante le operazioni comuni, tutte le copie del database conservano i registri da inviare ad altre copie del database, finché tutte le copie di un database confermano di aver eseguito di nuovo (copie passive) o di aver ricevuto (copie ritardate) i file di registro. Si tratta del comportamento di troncamento dei registri 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. 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 diventa insufficiente, troncherà in modo indipendente i file di log usando i parametri configurati descritti più avanti nella tabella Valore del Registro di sistema. Le copie passive tenteranno di rispettare la decisione di troncamento presa sulla copia attiva. Nonostante l'implicazione del nome MinCopiesToProtect, Exchange ignorerà solo lo straggler noto meno recente al momento in cui viene eseguito il troncamento.
Quando il database offline viene riportato online, mancano i file di log eliminati dalle altre copie integre e lo stato della copia del database sarà FailedAndSuspended. In questo caso, se autoreseed è configurato, la copia interessata verrà automaticamente reinviata. Se Autoreseed non è configurato, il seeding della copia del database dovrà essere eseguito manualmente da un amministratore.
Se la registrazione circolare è disabilitata, il troncamento libero rispetta i backup, se sono stati eseguiti, quindi se non è stato eseguito il backup dei log, non verranno rimossi dal troncamento allentato.
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. Per impostazione predefinita, la chiave BackupInformation con i seguenti valori DWORD non esiste e deve essere creata manualmente. Nella tabella riportata di seguito, sono indicati i valori del Registro di sistema DWORD in BackupInformation:
| Valore del Registro di sistema | Descrizione | Valore predefinito |
|---|---|---|
| LooseTruncation_MinCopiesToProtect | Questa chiave viene utilizzata per consentire il troncamento espanso. Rappresenta il numero di copie passive da proteggere dal troncamento espanso nella copia attiva di un database. L'impostazione del valore della chiave su 0 consente di disabilitare il troncamento espanso. | 0 |
| LooseTruncation_MinDiskFreeSpaceThresholdInMB | La soglia relativa allo spazio libero su disco (in MB) per l'attivazione del troncamento espanso. Se lo spazio libero sul disco supera questo valore, viene attivato il troncamento espanso. | Se il valore del Registro di sistema non è configurato, il valore predefinito usato dal troncamento espanso è 200 GB. |
| LooseTruncation_MinLogsToProtect | Il numero minimo di file di registri da mantenere nelle copie integre per le quali si sta eseguendo il troncamento dei registri. Se il valore del Registro di sistema è configurato, il valore configurato viene applicato alle copie attive e passive. | Se il valore del Registro di sistema non è configurato, vengono usati i valori predefiniti di 100.000 per le copie di database passive e di 10.000 per le copie di database attive. |
Quando si usa il valore del Registro di sistema LooseTruncation_MinLogsToProtect, si noti che il comportamento è diverso per le copie attive e passive del database. Nella copia attiva del database si tratta del numero di log aggiuntivi conservati prima di quelli richiesti dalle copie passive protette e dall'intervallo richiesto della copia attiva. In una copia passiva del database, si tratta del numero di log gestiti dal log più recente disponibile. Un decimo di questo numero viene usato anche per gestire i log prima dell'intervallo richiesto di questa copia passiva. I due limiti sono applicati per garantire che le copie ritardate del database non richiedano troppo spazio, poiché l'intervallo richiesto è in genere molto grande.
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 datacenter alternativo o a un datacenter in standby.
Se si configura una copia del database come copia ritardata per il ripristino.
Se si esegue la manutenzione o un 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 per un intero server usando il cmdlet Set-MailboxServer o una singola copia del database usando il cmdlet Set-MailboxDatabaseCopy per impostare il parametro DatabaseCopyAutoActivationPolicy su Blocked.
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 usata da servizi come il servizio Replica cassette postali di Exchange (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 il numero prerequisito di copie del database è disponibile.
Controllare lo scaricamento della replica: conferma che i file di log necessari sono stati riprodotti in base 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 sul 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 include i valori possibili seguenti:
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 sulla base del numero di volte che l'applicazione ha interrogato lo stato del database.
| Se il parametro DataMoveReplicationConstraint è impostato su... | Quindi, per un determinato database... |
|---|---|
SecondCopy |
Almeno una copia passiva del database per un database replicato deve soddisfare le condizioni descritte in precedenza. |
SecondDatacenter |
Almeno una copia passiva del database in un altro sito di Active Directory deve soddisfare le condizioni descritte in precedenza. |
AllDatacenters |
La copia attiva deve essere montata e una copia passiva in ogni sito di Active Directory deve soddisfare le condizioni descritte in precedenza. |
AllCopies |
È necessario montare la copia attiva e tutte le copie passive del database devono soddisfare le condizioni descritte in precedenza. |
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. Questo viene verificato confrontando il timestamp dell'ultimo registro replicato con il commit timestamp del servizio chiamante (in molti casi questo è il timestamp dell'ultimo file di registro che contiene i dati richiesti) più cinque secondi aggiuntivi (per compensare le differenze tra gli orari di sistema). Se il timestamp di riproduzione è maggiore del timestamp del commit, il parametro DataMoveReplicationConstraint viene soddisfatto. Se il timestamp di riproduzione è minore del 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 dag, è consigliabile configurare il parametro DataMoveReplicationConstraint in ogni database delle cassette postali in base al seguente:
| Se si sta distribuendo... | Impostare DataMoveReplicationConstraint su... |
|---|---|
| Database delle cassette postali che non hanno alcuna delle copie del database | None |
| Un gruppo di disponibilità del database (DAG) all'interno di un singolo sito di Active Directory | SecondCopy |
| Un gruppo di disponibilità del database (DAG) in più datacenter utilizzando un sito di Active Directory esteso | SecondCopy |
| Un gruppo di disponibilità del database che si estende su due siti di Active Directory ed è possibile disporre di copie di database a disponibilità elevata in ogni sito | SecondDatacenter |
| Un gruppo di disponibilità del database che si espande su due siti Active Directory e si avranno solo copie del database ritardate sul sito SecondCopy | SecondCopy Questo è dovuto al fatto che il servizio API di garanzia dei dati non garantisce che i dati vengano impegnati fino a che il file di registro sia replicato nella copia del database e a causa della natura della copia del database che deve essere ritardata questo vincolo non consentirà lo spostamento richiesto, a meno che il valore di ReplayLagTime della copia ritardata del database sia inferiore a 30 minuti. |
| Un gruppo di disponibilità del database (DAG) che si estende su tre o più siti Active Directory e ciascun sito conterrà un elevato numero di copie del database disponibili | AllDatacenters |
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
| Server | Numero di database attivi | Numero di database passivi | Numero di database installati | Numero di database disinstallati | Elenco conteggio delle preferenze |
|---|---|---|---|---|---|
| EX1 | 5 | 11 | 5 | 0 | 4, 4, 3, 5 |
| EX2 | 1 | 15 | 1 | 0 | 1, 8, 6, 1 |
| EX3 | 12 | 4 | 12 | 0 | 13, 2, 1, 0 |
| EX4 | 1 | 15 | 1 | 0 | 1, 1, 5, 9 |
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 considerare il sito di Active Directory.
BalanceDbsBySiteAndActivationPreference: quando si specifica questa opzione, lo script tenta di spostare i database attivi nella copia preferita, cercando al tempo stesso 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.
Gruppo DAG con una distribuzione bilanciata delle copie attive
| Server | Numero di database attivi | Numero di database passivi | Numero di database installati | Numero di database disinstallati | Elenco conteggio delle preferenze |
|---|---|---|---|---|---|
| EX1 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX2 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX3 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
| EX4 | 4 | 12 | 4 | 0 | 4, 4, 4, 4 |
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.
Parametri dello script RedistributeActiveDatabases.ps1
| Parametro | Descrizione |
|---|---|
| DagName | Specifica il nome del gruppo DAG che si desidera bilanciare di nuovo. Se questo parametro viene omesso, viene utilizzato il gruppo DAG di cui è membro il server locale. |
| BalanceDbsByActivationPreference | Specifica che lo script deve spostare i database nella copia preferita senza considerare il sito di Active Directory. |
| BalanceDbsBySiteAndActivationPreference | Specifica che lo script deve tentare di spostare i database attivi nella copia preferita, cercando al tempo stesso di bilanciare i database attivi all'interno di ogni sito di Active Directory. |
| ShowFinalDatabaseDistribution | Specifica la visualizzazione di un rapporto sulla distribuzione corrente del database dopo il completamento della ridistribuzione. |
| AllowedDeviationFromMeanPercentage | Specifica la variante consentita dei database attivi tra i siti, espressa in percentuale. L'impostazione predefinita è 20%. Ad esempio, se esistevano 99 database distribuiti tra tre siti, la distribuzione ideale era di 33 database in ogni sito. Se la discrepanza consentita è del 20%, lo script tenta di bilanciare i database in modo che ogni sito non abbia più del 10% in più o in meno del numero. Il 10% di 33 è 3,3, arrotondato a 4. Pertanto, lo script tenta di disporre di 29-37 database in ogni sito. |
| ShowDatabaseCurrentActives | Specifica che lo script produce un rapporto per ogni database che descrive lo spostamento del database e se ora è attivo sulla copia preferita. |
| ShowDatabaseDistributionByServer | Specifica che lo script produce un rapporto per ogni server che mostra la distribuzione di database. |
| RunOnlyOnPAM | Specifica che lo script viene eseguito solo sul membro DAG che attualmente dispone del ruolo PAM. Lo script verifica l'esecuzione dal ruolo PAM. Se non viene eseguito dal ruolo PAM, lo script viene chiuso. |
| LogEvents | Specifica che lo script registra un evento (evento MsExchangeRepl 4115) contenente un riepilogo delle azioni. |
| IncludeNonReplicatedDatabases | Specifica che lo script deve comprendere i database non replicati (database senza copie) nel determinare come ridistribuire i database attivi. Anche se i database non replicati non possono essere spostati, possono influenzare la distribuzione dei database replicati. |
| Conferma | L'opzione Confirm può essere utilizzata per sopprimere il prompt di conferma visualizzato per impostazione predefinita quando viene eseguito questo script. Per sopprimere il prompt di conferma, utilizzare la sintassi -Confirm:$False. È necessario includere i due punti ( : ) nella sintassi. |
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. È anche possibile usare il cmdlet Get-MailboxDatabaseCopyStatus in Exchange Management Shell per visualizzare un'ampia gamma di informazioni sullo stato per una copia del database.
Nota
Una copia del database costituisce la prima difesa contro gli errori che si verificano nella copia attiva del database. È quindi fondamentale monitorare l'integrità e lo stato delle copie del database per assicurarsi che siano disponibili quando necessario.
Per altre informazioni sul monitoraggio delle copie del database, vedere Monitorare i gruppi di disponibilità del database.
Eliminazione di una copia del database
Una copia del database può essere rimossa in qualsiasi momento tramite EAC o tramite 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 un passaggio usando il collegamento Attiva nell'interfaccia di amministrazione di Exchange o il cmdlet Move-ActiveMailboxDatabase in Exchange Management Shell.
Prima dell'attivazione di una copia passiva, verranno 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à usando 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. Utilizzando questo parametro l'operazione di seeding verrà cancellata 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 usando 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 usando 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 un cambio di database, è anche possibile eseguire l'override delle impostazioni 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 montaggio e di usare quelle 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.