Summary: Il quorum è uno degli aspetti più importanti di un Database Availability Group (DAG). Aiuta a decidere se il DAG deve rimanere online o andare offline. Per evitare che il DAG vada offline e causi un'interruzione, deve assicurarsi che il quorum sia mantenuto. Se riceve il messaggio di errore "Il Gruppo di disponibilità del database deve avere il quorum", deve risolverlo immediatamente per garantire il recupero automatico dei dati e le funzioni di resilienza del sito dei DAG.
Un Database Availability Group (DAG) è ottimo per il failover e l’alta disponibilità del suo Exchange Server e dei suoi servizi. Sebbene questa sia la soluzione migliore per la continuità aziendale di Exchange Server e il recupero dei dati, potrebbe incontrare alcuni problemi imprevisti che potrebbero influire sulle prestazioni, sulla qualità e sull’integrità dei dati dell’infrastruttura di Exchange Server.
Uno degli scenari peggiori in cui un amministratore di Exchange può imbattersi è quando un database di mailbox viene smontato. Se prova a montare il database, potrebbe verificarsi il seguente errore:
Non è stato possibile montare il database “DB01“. Errore: Un processo di Active Manager è fallito. Errore: Si è verificato un errore durante un’operazione di Active Manager. Per eseguire questa operazione, il server deve essere membro di un gruppo di disponibilità del database e il gruppo di disponibilità del database deve avere un quorum. Errore: Non è possibile leggere dal database del cluster.
Questo può accadere se il server è stato recentemente rimosso dal gruppo di disponibilità del database.
[Server: EX2019.mail.lan]
+ CategoryInfo : InvalidOperation: (DB01:ADObjectId) [Mount-Database], InvalidOperationException
+ FullyQualifiedErrorId : [Server=EX2019,RequestId=c51a831c-33e3-4a75-867f-51433b925ee2,TimeStamp=1/1/2020
4:13:12 AM] [FailureCategory=Cmdlet-InvalidOperationException] 7E29F70A,Microsoft.Exchange.Management.SystemConfigurationTasks.MountDatabase
+ PSComputerName : EX2019.mail.lan
L’errore di cui sopra può verificarsi per vari motivi. Alcuni dei motivi sono
- Un aggiornamento andato storto
- Errore umano
- Guasto hardware
- Perdita di potenza
- Attacchi malware e ransomware
- Corruzione o problemi di memoria
- Guasto dell’unità di archiviazione del server
Correggere l’errore “Il gruppo di disponibilità del database deve avere un quorum”.
Innanzitutto, deve verificare se ha la maggioranza dei voti nel suo cluster. Ciò significa che la metà dei suoi server più un server sono online e che tutti i server partecipanti sono sani e funzionanti. Deve anche verificare che lo storage di ciascun nodo e i servizi di Exchange e del cluster siano in funzione e che non si siano verificati errori. Se si è verificato un problema hardware che ha spento il server, questo potrebbe essere un problema, in quanto il DAG non può funzionare con uno solo dei tre server. Come per altri cluster (ad esempio SQL), il cluster viene spento come precauzione di sicurezza se non si raggiunge la maggioranza dei voti.
Se tutte le correzioni sono state effettuate e non c’è nulla da fare per ripristinare i servizi alla normalità, l’unica opzione è rimuovere le copie del database, in modo che il server sia in modalità database singolo.
Per farlo, esegua il comando Remove-DatabaseAvailabiltyGroupServer nella Shell di gestione di Exchange. Questo comando elimina tutte le voci DAG da Active Directory.
Nota: non è necessario creare prima una copia di backup di tutti i dati, in quanto viene eliminata solo la configurazione.
Remove-DatabaseAvailabilityGroupServer -ConfigurationOnly -MailboxServer SRV-MBX-01 -Identity DAG001
Questo processo deve essere eseguito su ciascun nodo. Se il suo gruppo di disponibilità del database (DAG) è quindi composto da due server, deve eseguire i passaggi precedenti su entrambi i server.
Al termine di questo processo, la configurazione del Database Availability Group (DAG) viene rimossa da Active Directory.
Il passo successivo consiste nel rimuovere i nodi dal cluster Windows. Tuttavia, non può utilizzare Cluster Manager per questo processo. Deve farlo con PowerShell. Il processo è abbastanza semplice, in quanto è sufficiente utilizzare Get-ClusterNode e Remove-ClusterNode con il parametro force (come nell’esempio seguente).
Get-ClusterNode <nome server> | Remove-ClusterNode -Force
Se la configurazione di Exchange Server per il gruppo di disponibilità del database (DAG) è composta da due o più server, deve eseguire questa operazione per ogni nodo del cluster.
Qualsiasi configurazione del gruppo di disponibilità del database viene quindi rimossa dallo schema di Active Directory e la configurazione deve essere convertita come server autonomo. Ciò significa che dopo il riavvio del server, il database deve essere montato in quanto è stato rimosso dal gruppo di disponibilità del database (DAG).
Cosa devo fare se i database non vengono ancora montati?
Se ora diciamo che i database dovrebbero essere montati senza problemi, significa che i database non sono stati danneggiati. Se i database non sono ancora montati, deve controllare i database con gli strumenti nativi forniti con Exchange Server, come ESEUtil.
ESEUtil è uno strumento nativo che identifica i problemi e tenta di riparare i database danneggiati. Deve essere eseguito tramite un’interfaccia a riga di comando.
Per determinare se il database è danneggiato, deve eseguire ESEUtil con il parametro /mh e verificare lo stato del database. Un database sano avrà lo stato Arresto pulito, mentre un database danneggiato visualizzerà Arresto sporco.
EseUtil /mh <File del database di Exchange>.
ESEUtil offre due opzioni per il recupero dei dati: il recupero soft e il recupero hard. Il recupero soft, come suggerisce il nome, esegue un recupero morbido/veloce del database. Se il danno è lieve, il recupero dati soft tenta di risolvere il problema.
Se questo non riesce e lo stato del database rimane nello stato di Arresto Sporco, significa che il danno è grave. In questo caso, l’unica soluzione è ripristinare i database da un backup. Tuttavia, questo comporterà una perdita di dati, in quanto è possibile ripristinare i dati solo dall’ultimo backup. L’altra opzione è quella di eseguire un recupero dati sul disco rigido. Anche questo comporta una perdita di dati, in quanto il recupero dei dati elimina tutti i dati considerati danneggiati. D’altra parte, Microsoft non la supporterà se il database è classificato come recupero duro. Inoltre, non c’è alcuna garanzia che il database possa essere montato in seguito.
Come alternativa sana, può utilizzare un’applicazione di terze parti come Stellar Repair for Exchange, che è facile da aprire qualsiasi database di Exchange Server in qualsiasi stato e le permette di leggere e cercare il file EDB. Può esportare i dati in PST e altri formati. Il software di recupero dati di Exchange Server dispone anche di una funzione per esportare direttamente in un database di Exchange Server live o in un tenant di Office 365.
