Los errores y conceptos erróneos más comunes al configurar DFSR

[Nota traductor El artículo es para Windows Server 2003 / 2003R2 / 2008 / 2008R2, pero la mayoría de lo anterior se aplica a versiones posteriores del sistema operativo]

Hola a todos! Warren está aquí nuevamente, y esta publicación de blog es una compilación de los problemas de DFSR más comunes que he encontrado en los últimos años. El propósito de esta publicación es enumerar errores comunes en la configuración de DFSR que causan estos problemas y evitar que cometa errores similares. Saber lo que no se debe hacer es tan importante como saber qué hacer. Muchos de los elementos descritos están relacionados con otros temas, por lo que se proporcionan los enlaces correspondientes para un estudio en profundidad del tema.

El tamaño de la cuota es demasiado pequeño para la carpeta provisional

¿Viste muchos eventos en la revista con los códigos 4202 y 4204? En este caso, el tamaño de la carpeta provisional está configurado incorrectamente. Una consecuencia desagradable del tamaño incorrectamente establecido de la carpeta de ensayo es la reducción del rendimiento de la replicación, porque en lugar de replicar archivos, el servicio pasará tiempo limpiando la carpeta de ensayo.
Los servidores DFSR que están configurados con un tamaño de carpeta de preparación suficiente son más eficientes por al menos dos razones:

1. Es mucho más eficiente simplemente colocar el archivo en una carpeta intermedia una vez, luego enviarlo a todos los socios de replicación de host, que crear el archivo, replicarlo y luego eliminar una copia para cada socio de host.
2. Si la edición Enterprise del sistema operativo está instalada en al menos un miembro, los servidores pueden usar la tecnología RDC entre archivos [aprox. traductor: a partir de Windows Server 2012, esta tecnología también está disponible en la edición estándar]

Un tamaño configurado incorrectamente para la carpeta provisional también puede causar bucles de replicación. Esto sucede si el archivo replicado ya se ha copiado en la carpeta provisional en el servidor receptor, pero el mecanismo de limpieza de la carpeta provisional elimina este archivo antes de que pueda moverse a la carpeta de destino. El archivo eliminado se replicará nuevamente en el servidor y este servidor lo eliminará nuevamente de la carpeta provisional, como resultado de lo cual el servidor nunca podrá recibir el archivo. Este proceso se repetirá hasta que el servidor acepte el archivo.

No ignore los eventos de registro para la carpeta de ensayo.

Consulte esta publicación que describe cómo usar el método para determinar el tamaño mínimo de una carpeta intermedia.

Consulte la sección "Aumento de la cuota provisional" aquí .

Para obtener información sobre RDC entre archivos, puede leer el artículo "Información sobre la compresión diferencial remota", publicado aquí .

Procedimiento de preselección incorrecto o no probado

Un procedimiento de preselección es la copia de datos que se replicarán en un nuevo servidor miembro de replicación antes de agregarse a la carpeta final de este servidor, a fin de reducir el tiempo requerido para completar la replicación primaria. La mayoría de las fallas del procedimiento de presentación previa que encontré fueron causadas por tres razones.

1. Desajuste de ACL en origen y destino.
2. Después de copiar a un nuevo miembro de replicación, se realizaron cambios en los archivos.
3. No se realizaron pruebas previas para verificar que el procedimiento de preselección utilizado funcionara como se esperaba.

En resumen, los archivos deben copiarse de cierta manera, y no pueden cambiarse después de haber sido copiados en la carpeta intermedia, y todo el proceso debe ser probado previamente por usted.

Haga clic aquí para leer el blog del Sr. Pile sobre cómo organizar adecuadamente el procedimiento de preselección para sus servidores DFSR.

Tamaño de cola de copia grande a lo largo del tiempo

Además del hecho de que una cola de copia grande que existe durante mucho tiempo significa que sus datos no están sincronizados, esto puede conducir a una resolución de conflictos indeseable cuando un archivo con contenido antiguo gana en un script de resolución de conflictos. El escenario más común en el que me encontré con este comportamiento es la adición masiva de nuevas carpetas de replicación. En lugar de realizar una implementación por fases, algunos administradores agregaron de inmediato 20 carpetas nuevas para la replicación desde 20 sucursales diferentes, lo que sobrecargó el servidor host. Implemente en etapas para que la replicación primaria se complete en un período de tiempo razonable.

DFSR utilizado como solución de respaldo

Lo creas o no, algunos administradores implementan DFSR sin copias de seguridad sin conexión de datos replicados. DFSR no fue diseñado como una solución de respaldo. Uno de los objetivos del desarrollo de DFSR es formar parte de una estrategia de respaldo empresarial, porque DFSR le permite recopilar sus datos distribuidos geográficamente en un sitio centralizado para su posterior respaldo, recuperación y archivado. Varios miembros de replicación brindan protección contra fallas en el servidor, pero esto no lo protege de eliminaciones accidentales. Para estar completamente protegido, debe hacer una copia de seguridad de sus datos.

Replicación unidireccional: su uso y métodos de reparación incorrectos

En un intento por evitar que ocurran actualizaciones no deseadas en servidores donde los datos nunca cambiarán (o si desean evitar cambios en ellos), muchos clientes configuran la replicación unidireccional al eliminar las conexiones salientes para los miembros de replicación. La replicación unidireccional no es compatible con ninguna versión de DFSR anterior a Windows Server 2008 R2. Windows 2008 R2 admite la replicación unidireccional, lo que le permite configurar carpetas de solo lectura para carpetas replicadas.

El uso de miembros de replicación de solo lectura puede lograr el objetivo de la replicación unidireccional, lo que evita cambios no deseados en los datos que se replican. Si desea usar la replicación unidireccional usando DFSR, use Windows 2008 R2 y para aquellos miembros que no deben cambiarse, seleccione el modo de solo lectura.

Haga clic aquí y aquí para obtener información sobre la replicación de solo lectura DFSR.

Otro problema común ocurre cuando el administrador descubre que la replicación unidireccional no es compatible e intenta corregir la situación, pero lo hace de manera incorrecta. Simplemente habilitar la replicación bidireccional puede tener resultados no deseados.

Haga clic aquí para aprender cómo solucionar la replicación unidireccional.

Servidor de nodo como punto único de falla y servidores de nodo sobrecargados

He visto muchas implementaciones con un servidor de nodo único. Si este servidor de nodo falla, la implementación completa está en riesgo. Si está utilizando Windows Server 2003 o 2008, debe tener al menos dos servidores host, y si uno falla, el otro debe manejar la carga en el tiempo de recuperación del primero con un impacto mínimo en los usuarios finales. A partir de Windows Server 2008 R2, DFSR se puede implementar en un clúster de conmutación por error de Windows, proporcionando alta disponibilidad y reduciendo a la mitad los requisitos de almacenamiento.

Tarde o temprano, los administradores tienen una situación en la que hay demasiados servidores en las sucursales que están configurados para replicarse con un servidor de un solo nodo. Esto puede provocar retrasos en la replicación. Para comprender cuántos servidores de Office Office puede servir un servidor de nodo único, puede utilizar el seguimiento de la cola de copia. No existe una fórmula mágica, ya que cada entorno es único y existen muchas dependencias.

Lea la sección "Configuración de topología" aquí para obtener información sobre cómo implementar servidores host.
Haga clic aquí para obtener información sobre cómo configurar DFSR en un clúster de conmutación por error de Windows Server 2008.

Demasiadas carpetas para replicar en una sola base de datos Jet

DFSR usa una base de datos Jet en el volumen. Como resultado, colocar todas las carpetas replicadas en el mismo volumen hace que todas estén en la misma base de datos Jet. Si surge un problema en esta base de datos que necesita ser reparado o restaurado, la base de datos afectará a todas las carpetas replicadas en este disco. [Nota traductor obviamente, esto no es un disco, sino un volumen.] Sería más correcto usar tantos discos como sea posible y distribuir las carpetas replicadas entre ellos, asegurando así el tiempo máximo de disponibilidad de datos.

Implementación basada en soluciones iSCSI de presupuesto

A menudo he visto implementaciones de DFSR utilizando el hardware iSCSI más barato. Por lo general, si usa DFSR, lo hace para lograr objetivos críticos, como la redundancia de datos, la consolidación de copias de seguridad, la entrega programada de aplicaciones y las actualizaciones del sistema operativo. No es una buena idea depender de equipos de baja calidad que no cuentan con el soporte normal del proveedor. Si los datos son importantes para su negocio, el equipo en el que trabajan el SO y el mecanismo de replicación serán importantes para ello.

El servicio DFSR no instala los parches actuales

DFSR es activamente compatible con Microsoft y se actualiza según sea necesario. Actualice DFSR si hay una nueva versión para él en el momento de su próximo ciclo de instalación de actualizaciones. Asegúrese de que sus servidores estén actualizados de acuerdo con los artículos de la base de conocimiento que se enumeran a continuación.

Revisiones DFSR para Windows 2003 R2
Revisiones DFSR para Windows 2008 y Windows 2008 R2

Tenga en cuenta que, además de DFSR.EXE / DFSRS.EXE, las actualizaciones enumeradas también son para NTFS.SYS y otros archivos. Para que la replicación funcione correctamente, asegúrese siempre de que los últimos parches estén instalados al menos para DFSR y NTFS. Otras correcciones de la lista se refieren principalmente a problemas de interfaz de usuario, y deberá instalarlas al menos en los sistemas donde se realizan las tareas de configuración de DFSR.

Se recomienda que los parches se instalen en el servidor DFSR por adelantado, incluso si todo funciona bien, ya que más adelante esto lo ayudará a evitar la aparición de problemas ya conocidos.

Los controladores del adaptador de red no son compatibles hasta la fecha

DFSR solo podrá funcionar normalmente si la red que le proporciona también funciona sin problemas. Usar controladores hace 5 años no es la solución más inteligente. Tenía experiencia comunicándome con varios clientes para quienes los problemas de replicación DFSR se resolvieron al actualizar un controlador NIC desactualizado.

Falta el monitoreo de DFSR

A pesar del hecho de que DFSR se utiliza para mover, como regla, datos críticos, muchos administradores no tienen idea de lo que está haciendo DFSR hasta que se encuentran con un problema. Aquellos que tienen más recursos crean sus propios scripts para monitorear las colas de copias en sus servidores, pero la mayoría simplemente confía en ellos. El paquete de administración para DFSR se lanzó hace casi un año (y otras versiones aparecieron antes). Instálelo y úselo, y luego podrá detectar problemas y responder a ellos antes de que se conviertan en una pesadilla. Si no puede usar el Paquete de administración de gestión de operaciones para DFSR, al menos escriba un script para monitorear la cola de copias diariamente para comprender si los archivos DFSR se están replicando o no.

Haga clic aquí para obtener información sobre el Paquete de administración de gestión de operaciones para DFSR.

Actualizado el 19 de enero de 2011:

Realizar cambios en el almacenamiento en disco sin archivar primero los datos

Si necesita reemplazar el disco duro en el servidor DFSR o agregar uno nuevo para aumentar el espacio de almacenamiento, es extremadamente importante tener una copia de seguridad de datos actualizada en caso de que algo salga mal. Todo puede salir mal, la mayoría de las veces se producen eventos de conflicto debido a cambios inesperados en la carpeta principal o la eliminación accidental de la carpeta principal, que se replica a todos los socios. Debe hacer una copia de seguridad de sus datos antes de realizar cambios y conservarlos hasta que se complete el proyecto.

Detener el servicio DFSR para detener temporalmente la replicación

A veces necesita detener temporalmente la replicación. La forma correcta de hacer esto es deshabilitar la replicación para el grupo deseado usando un horario. El servicio DFSR debe estar ejecutándose para poder leer las actualizaciones en el registro de USN. No detenga el servicio DFSR durante un período prolongado (días, semanas), ya que esto puede provocar un desbordamiento del registro (si se han cambiado, agregado o eliminado muchos archivos durante este tiempo). DFSR se recuperará de los desbordamientos del registro, pero en implementaciones grandes tomará mucho tiempo y la replicación no funcionará o será muy lenta durante la recuperación del registro. Además, es probable que observe colas de copia muy grandes hasta que se complete la recuperación del registro.

Espero que esta lista te ayude. Buena replicación!

Warren "red ancha" Williams

[Nota traductor Si hay interés de los lectores, más adelante intentaré traducir los artículos publicados en los enlaces indicados en el texto, así como otros artículos del autor original]