Summary: Database Availability Group (DAG) se introdujo con Exchange 2010 que permite a las organizaciones agregar varios servidores de buzones de correo en un grupo para lograr una alta disponibilidad y resiliencia del sitio. Cuando los servidores miembros son pares, el DAG emplea un servidor testigo de archivos para mantener el quórum. Sin embargo, si este servidor testigo falla o se desconecta, puede interrumpir o romper el flujo de correo electrónico y comprometer el DAG. Por lo tanto, es crítico arreglar un servidor testigo fallido. En este blog, aprenderá algunas soluciones sencillas para solucionar el problema del servidor testigo fallido y restaurar los buzones de correo mediante el software de recuperación de Exchange.
Microsoft Exchange Database Availability Group o DAG requiere un servidor testigo y un directorio testigo (creado automáticamente por Exchange en el servidor testigo) para mantener el quórum.
Un servidor testigo o servidor testigo de archivos (FSW) proporciona protección automática contra fallos. Identifica qué servidor miembro contiene la copia espejo y qué servidor contiene la copia principal de la base de datos, garantizando que al menos un servidor esté activo en todo momento.
Sin embargo, a veces, debido a problemas subyacentes o a una configuración incorrecta en el servidor testigo del Exchange DAG, puede producirse un estado de error, lo que da lugar a un DAG insalubre y comprometido. El estado de un servidor testigo también puede mostrarse como fallido si el servidor no arranca debido a un fallo de hardware o software.
Para comprobar el estado del servidor testigo en DAG, utilice el cmdlet Get-DatabaseAvailabilityGroup en Exchange Management Shell (EMS),
Get-DatabaseAvailabilityGroup -Identity "DAG01" -Status | ft Name, Witness*, ServersSi el servidor testigo ha fallado, se muestra el siguiente mensaje de error/advertencia en la salida,
ADVERTENCIA: El testigo del grupo de disponibilidad de base de datos 'DAG01' se encuentra en estado de error. El grupo de disponibilidad de base de datos requiere que el servidor testigo mantenga el quórum. Utilice el cmdlet Set-DatabaseAvailabilityGroup para volver a crear el servidor testigo y el directorio.ServidorTestigo : FSW.dominio.localWitnessDirectory : C:\DAGFileShareWitnesses\DAG1.domain.localAlternateWitnessServer :AlternateWitnessDirectory :WitnessShareInUse : InvalidConfigurationDxStoreWitnessServers :En este blog, aprenderá una solución simple para arreglar el estado del servidor testigo fallido y devolver su DAG a un estado saludable.
Métodos para resolver el estado de error del servidor testigo DAG en Exchange
Si el servidor testigo falla debido a un problema de hardware o software y no a un problema relacionado con la red, configure un nuevo servidor testigo y, a continuación, cambie el servidor testigo y el directorio de testigos en el DAG mediante el cmdlet Set-DatabaseAvailabilityGroup. El comando es el siguiente
Set-DatabaseAvailabilityGroup -Identity "DAGName" -WitnessServer "NewFileWitnessServerName" -WitnessDirectory NonRootLocalLongFullPathPor ejemplo,
Set-DatabaseAvailabilityGroup -Identity "DAG01" -WitnessServer "FSW02.abc.com" -WitnessDirectory C:\DAG01Si el cortafuegos de Windows está activado, es posible que aparezca el siguiente mensaje de advertencia en la salida,
ADVERTENCIA: No se puede acceder a los archivos compartidos en el servidor testigo 'FSW02.abc.com'. El grupo de disponibilidad de base de datos puede ser más vulnerable a fallos hasta que se corrija este problema. Puede utilizar el cmdlet Set-DatabaseAvailabilityGroup para volver a intentar la operación. Error: No se encontró la ruta de red No se pudo cambiar el quórum para el grupo de disponibilidad de base de datos DAG01. No se encontró la ruta de red para el servidor testigo '\FSW02.abc.com\DAG01.abc.com'. Esto puede deberse a la configuración del cortafuegos.En tal caso, puede desactivar el Firewall de Windows o añadir una excepción para Compartir archivos e impresoras en el puerto SMB 445 (utilizado por el servidor testigo). A continuación, ejecute el cmdlet.
Para verificar el nuevo servidor testigo DAG, ejecute el siguiente cmdlet,
Get-DatabaseAvailabilityGroup -Identity "DAG01" -Status | ft Name, Witness*, ServersSi la salida muestra el nuevo servidor de testigos y el directorio de testigos, ha cambiado correctamente el servidor de testigos.
También puede realizar estos pasos a través del Centro de administración de Exchange (EAC). Los pasos son los siguientes,
- En EAC, vaya a servidores > grupos de disponibilidad de bases de datos
- Seleccione el DAG y haga clic en el icono de edición (lápiz)
- Introduzca el nuevo FQDN del servidor de testigos y la nueva ruta del directorio de testigos y haga clic en Guardar.
Para verificar el servidor testigo DAG, compruebe el nombre del servidor en servidores > grupos de disponibilidad de base de datos. Compruebe también que el directorio de testigos se ha creado correctamente en el servidor de testigos.
NOTA IMPORTANTE: Después de esto, debe excluir el directorio de testigos en el servidor de testigos del antivirus.
Solución alternativa
Si la solución anterior no le ha funcionado y su servidor testigo no está muerto, intente comprobar el clúster utilizando el cmdlet Get-ClusterResource.
Si la salida muestra el estado de File Share Witness como fallido, vuelva a ponerlo en línea utilizando el siguiente cmdlet,
Get-ClusterResource | Start-ClusterResource
Esto iniciará el cluster y devolverá la FSW al estado online. Si esto ocurre, no necesitas realizar ninguna acción adicional.
Conclusión
El servidor testigo es un componente importante del DAG necesario para mantener el quórum. Sin embargo, un servidor testigo puede quedar fuera de línea o fallar después de un reinicio, lo que lleva a un estado de servidor testigo fallido que rompe el clustering de conmutación por error. En una situación tan crítica, debe intentar poner en línea el servidor testigo o cambiar a un nuevo servidor testigo y directorio testigo. Si el servidor testigo falla durante estas operaciones o la base de datos se desmonta debido a incoherencias, puede utilizar la copia de seguridad para restaurar la base de datos y los buzones de correo. Si dispone de copias de seguridad, puede utilizar un software de recuperación de Exchange, como Stellar Repair for Exchange, para reparar la base de datos, extraer los buzones y guardarlos como PST. También puede exportar los buzones directamente a su servidor Exchange activo o Microsoft 365.
