La modalità Datacenter Activation Coordination (DAC) è una proprietà di un Database Availability Group (DAG). Questa modalità viene utilizzata per controllare il montaggio del database sul comportamento di avvio del Database Availability Group (DAG). La funzione è progettata per evitare che si verifichi lo split brain a livello di database quando si verifica uno switchback.
Che cos’è uno split brain? Il cervello diviso, noto anche come sindrome del cervello diviso, è una condizione in cui un database di mailbox è impostato come copia attiva di due membri del Database Availability Group. Ciò comporta problemi di comunicazione tra i due server e database.
Per evitare un cervello diviso, è possibile attivare la modalità Datacenter Activation Coordination (DAC), che richiede l’autorizzazione a montare il database dai membri del Database Availability Group (DAG) prima dell’attivazione. Si tratta di un’opzione di sicurezza.
Come controllare e abilitare la modalità DAC?
Quando la modalità Datacenter Activation Coordination (DAC) è abilitata, oltre a impedire che il cluster si trovi in una situazione di split-brain, abilita anche nuovi cmdlet, tra cui Stop-DatabaseAvailabilityGroup, Start-DatabaseAvailabilityGroup e Restore-DatabaseAvailabilityGroup. Questi comandi sono utili durante il cambio di data center.
Per verificare se la modalità DAC è attiva o meno, è possibile utilizzare il comando Get-DatabaseAvailabilityGroup con i seguenti parametri per ottenere le informazioni.
Get-DatabaseAvailabilityGroup | Seleziona nome, server, DatacenterActivationMode
Se non è stata abilitata, l’uscita viene visualizzata come “off”.
Per abilitare la modalità DAC, è necessario utilizzare il cmdlet Set-DatabaseAvailabilitGroup, come indicato di seguito. Set-DatabaseAvailabilityGroup servername -DatacenterActivationMode DagOnly /servername
Una volta completata questa operazione, il DataCenterActivationMode passerà a DagOnly.
Cose da considerare prima di abilitare la modalità DAC
La modalità DAC è disattivata per impostazione predefinita quando è configurato un Exchange Server ad alta disponibilità. Deve essere attivata per tutti i gruppi di disponibilità del database con due o più membri che sono configurati per utilizzare la replica continua.
Se sono installati software o hardware di replica di terze parti, si consiglia di non abilitare la funzione. Questo vale anche per la modalità di replica di terze parti. Inoltre, non è supportata se il DAG ha un solo membro nel cluster.
Un’altra cosa da considerare è che la modalità DAC può essere abilitata su qualsiasi Database Availability Group esistente all’interno di un singolo datacenter, anche se non è probabile che si verifichi uno split-brain. Si consiglia di abilitarla perché esiste comunque la possibilità che si verifichi. Lo split brain può facilmente verificarsi quando si dispone di una configurazione multi-sito in cui un Exchange Server si trova nel sito principale e gli altri in una posizione geografica diversa per il ripristino di emergenza e la continuità aziendale. Ciò può accadere a causa della latenza, delle disconnessioni o persino di una configurazione errata tra i siti.
È importante conoscere questi aspetti perché potrebbero verificarsi problemi se non è configurato bene o se è configurato con una configurazione non supportata. Non vorrete trovarvi di fronte a una configurazione con registri delle transazioni di Exchange danneggiati o a una mancata corrispondenza dei database tra i siti con conseguente perdita di dati. Se sono attivi due database, si avranno problemi di replica e persino di integrità dei dati.
Cosa fare se si verifica uno sdoppiamento del cervello?
Se si verifica il processo di split-brain, entrambi i server penseranno di essere server attivi. Questo causerà il caos nei dati del sito e provocherà il danneggiamento del database di Exchange o addirittura il danneggiamento dei database o dei registri.
In questi casi, si finisce per ripristinare i server dal backup, poiché la risoluzione del problema può richiedere un buon numero di ore. Il ripristino dal backup comporterebbe una perdita di dati, a seconda dell’ora del giorno in cui si verifica. I database o i registri delle transazioni danneggiati non sono piacevoli perché i database non vengono montati.
È possibile utilizzare ESEUtil per eseguire un ripristino rapido o un ripristino rigido per risolvere il problema. Tuttavia, il ripristino rapido è sconsigliato in quanto eliminerà tutti i dati ritenuti danneggiati. Dopo tutto questo percorso, non c’è alcuna garanzia che il database venga montato.
Una soluzione alternativa
Le applicazioni di recupero di Exchange di terze parti, come Stellar Repair for Exchange, possono essere utili in queste situazioni. Stellar Repair for Exchange può aprire più database di Exchange Server di qualsiasi versione e in qualsiasi stato. È possibile sfogliare l’archivio dati ed esportare in PST e altri formati di file. Se il database di Exchange non viene montato, è possibile creare facilmente un nuovo database ed esportare direttamente dal database danneggiato a quello nuovo. È anche possibile esportare direttamente in un tenant di Office 365. Il programma offre la mappatura automatica o manuale delle caselle di posta, il recupero parallelo delle caselle di posta, le esportazioni con priorità VIP e la continuazione del processo in caso di interruzione. In questo modo si riducono al minimo i costi e i tempi di ripristino.
Was this article helpful?
