Il Microsoft Exchange Database Availability Group o DAG richiede un server testimone e una directory testimone (creata automaticamente da Exchange sul server testimone) per mantenere il quorum.
Un server testimone o file witness server (FSW) fornisce una protezione automatica dal failover. Identifica il server membro che detiene la copia mirror e il server che detiene la copia principale del database, assicurando che almeno un server sia attivo in qualsiasi momento.
Tuttavia, a volte, a causa di problemi sottostanti o di una configurazione errata del server witness del DAG di Exchange, può verificarsi uno stato di fallimento, con il risultato di un DAG non sano e compromesso. Lo stato di un server witness può essere visualizzato come fallito anche se il server non si avvia a causa di un guasto hardware o software.
Per verificare lo stato del server witness nel DAG, utilizzare il cmdlet Get-DatabaseAvailabilityGroup in Exchange Management Shell (EMS),
Get-DatabaseAvailabilityGroup -Identity "DAG01" -Status | ft Name, Witness*, Servers
Se il server dei testimoni è fallito, nell’output viene visualizzato il seguente messaggio di errore/avviso,
AVVISO: il gruppo di disponibilità del database 'DAG01' è in stato di fallimento. Il gruppo di disponibilità del database richiede il server witness per mantenere il quorum. Utilizzare il cmdlet Set-DatabaseAvailabilityGroup per ricreare il server witness e la directory.
WitnessServer : FSW.domain.local
Directory dei testimoni: C:\DAGFileShareWitnesses\DAG1.domain.local
AlternateWitnessServer :
AlternateWitnessDirectory :
WitnessShareInUse : InvalidConfiguration
DxStoreWitnessServers :
In questo blog, imparerete una semplice soluzione per risolvere lo stato di fallimento del server witness e riportare il DAG a uno stato sano.
Metodi per risolvere lo stato di fallimento del server DAG Witness in Exchange
Quando il server dei testimoni si guasta a causa di un problema hardware o software piuttosto che di un problema di rete, impostare un nuovo server dei testimoni e quindi cambiare il server dei testimoni e la directory dei testimoni nel DAG utilizzando il cmdlet Set-DatabaseAvailabilityGroup. Il comando è il seguente,
Set-DatabaseAvailabilityGroup -Identity "DAGName" -WitnessServer "NewFileWitnessServerName" -WitnessDirectory NonRootLocalLongFullPath
Per esempio,
Set-DatabaseAvailabilityGroup -Identity "DAG01" -WitnessServer "FSW02.abc.com" -WitnessDirectory C:\DAG01
Se il firewall di Windows è abilitato, è possibile che venga visualizzato il seguente messaggio di avviso nell’output,
ATTENZIONE: Impossibile accedere alle condivisioni di file sul server witness 'FSW02.abc.com'. Il gruppo di disponibilità del database potrebbe essere più vulnerabile ai guasti fino a quando questo problema non verrà corretto. È possibile utilizzare il cmdlet Set-DatabaseAvailabilityGroup per riprovare l'operazione. Errore: Il percorso di rete non è stato trovato Impossibile modificare il quorum per il gruppo di disponibilità del database DAG01. Il percorso di rete per il server witness '\\FSW02.abc.com\DAG01.abc.com' non è stato trovato. Questo potrebbe essere dovuto alle impostazioni del firewall.
In questo caso, è possibile disattivare il firewall di Windows o aggiungere un’eccezione per la condivisione di file e stampanti sulla porta SMB 445 (utilizzata dal server witness). Eseguire quindi il cmdlet.
Per verificare il nuovo server DAG witness, eseguire il seguente cmdlet,
Get-DatabaseAvailabilityGroup -Identity "DAG01" -Status | ft Nome, Witness*, Server
Se l’output visualizza il nuovo server Witness e la nuova directory dei testimoni, la modifica del server dei testimoni è avvenuta con successo.
È possibile eseguire questi passaggi anche tramite Exchange Admin Center (EAC). I passaggi sono i seguenti,
- In EAC, andare su server > gruppi di disponibilità del database
- Selezionare il DAG e fare clic sull’icona di modifica (matita).
- Inserire il nuovo FQDN del server dei testimoni e il percorso della nuova directory dei testimoni, quindi fare clic su Salva.
Per verificare il server DAG witness, controllare il nome del server in server > gruppi di disponibilità del database. Inoltre, verificare che la directory dei testimoni sia stata creata correttamente sul server dei testimoni.
NOTA IMPORTANTE: Dopo questa operazione, è necessario escludere la directory dei testimoni sul server dei testimoni dall’antivirus.
Soluzione alternativa
Se la soluzione precedente non ha funzionato e il server witness non è morto, provare a controllare il cluster utilizzando il cmdlet Get-ClusterResource.
Se l’output visualizza lo stato di File Share Witness come fallito, riportarlo online utilizzando il seguente cmdlet,
Get-ClusterResource | Start-ClusterResource
Questo avvia il cluster e riporta il FSW allo stato online. In questo caso, non è necessario eseguire altre azioni.
Conclusione
Il server Witness è un componente importante del DAG, necessario per mantenere il quorum. Tuttavia, un server witness può andare offline o guastarsi dopo un riavvio, causando un fallimento dello stato del server witness che interrompe il clustering failover. In una situazione così critica, è necessario cercare di riportare il server witness online o passare a un nuovo server witness e a una nuova directory witness. Se il server membro si guasta durante queste operazioni o il database si smonta a causa di inconsistenze, è possibile utilizzare il backup per ripristinare il database e le caselle di posta. Se i backup sono disponibili, è possibile utilizzare un software di ripristino di Exchange, come Stellar Repair for Exchange, per riparare il database, estrarre le cassette postali e salvarle come PST. È anche possibile esportare le caselle di posta elettronica direttamente sul server Exchange o su Microsoft 365.
Was this article helpful?
