Pregunta: ¿Hay alguna manera de hacer que este trabajo acumulado de 350,000 archivos se complete más rápido? Para casi todos los archivos, el único cambio fue un cambio en la ACL para cada archivo afectado. Algunos archivos han cambiado de contenido, pero ese no es el caso común en esta situación.
Esto podría ser arreglado. Editaré este texto para confirmar el éxito / fracaso después de un período de tiempo y verificación. Hacia el final del texto de esta pregunta, he detallado los cambios realizados recientemente que podrían haberlo solucionado.
Tenemos un grupo de replicación DFSR con aproximadamente 450,000 archivos y ocupa 1.5TB de espacio. En esta situación, hay dos servidores Windows Server 2008 R2 que están separados por aproximadamente 500 millas. Hay otros servidores, pero no están involucrados en este grupo de replicación. El servidor ALPHA es el servidor principal y es el utilizado por la mayoría del personal. El servidor BETA es el servidor de la oficina remota y está menos ocupado.
Aquí hay un gráfico de la cartera de pedidos para este grupo de replicación (PNG alojado en Google Drive) que muestra el progreso lento de la sincronización.
Necesitaba eliminar una entrada de permiso que estaba en el directorio raíz de ese grupo de replicación, que por supuesto fue heredada en la mayoría de las subcarpetas. Hice este cambio en el servidor ALPHA. Inmediatamente después de eso, DFSR tenía una acumulación de 350,000 archivos. Ha pasado más de una semana y ahora está en 267,000. Lo único que cambió (inicialmente) fue el cambio de permiso único.
Esto es lo que sucedió (esta no es la solución, solo otra explicación de lo que causó este problema): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -porque-resulta-el-viernes-noche-estaba-bien-para-pelear.aspx # dfsr
Cualquier cambio que ocurra en el servidor BETA se replica al servidor ALPHA muy rápidamente, ya que no existe una acumulación de pedidos en esa dirección. Cualquier archivo modificado en BETA llega a ALPHA sin problemas.
Se replica 24/7 a toda velocidad a través de una conexión de 50Mbps en un extremo a una fibra de 100Mbps en el otro extremo. El área de preparación es de 100 GB en cada servidor. No hay nada interesante en los registros de eventos. Hay un evento de marca de agua no relacionado que se muestra para un grupo de replicación no relacionado que no es para esta replicación en particular ni para este par de servidores ALPHA / BETA. En particular, no hay entradas de registro de eventos para marcas de agua altas ni para errores de conexión.
La opinión de ALPHA sobre el grupo de replicación:
Ahorro de ancho de banda : reducción del 99.83% (30.85 MB replicados en lugar de 18.1 GB)
Creo que los 30.85MB / 18.1GB ocurrieron desde la última vez que reinicié el servicio DFSR en ALPHA y BETA. Si es así, esto muestra que a pesar de que está tomando mucho tiempo (más de lo que creo que debería tomar), en realidad no está transfiriendo el contenido del archivo a través del cable.
Carpeta replicada : 1.46TB (tamaño real), 439,387 (archivos), 52,886 (carpetas)
Conflicto y carpeta eliminada : 100.00GB (tamaño configurado), 34.01GB (tamaño real), 19,620 (archivos), 2,393 (carpetas)
Carpeta provisional: 200.00 GB (tamaño configurado), 92.54 GB (tamaño real)
Obtuve un error de marca de agua alta en los registros (14 de mayo, 7 p.m.) y, por lo tanto, he aumentado la cuota de preparación a 200 GB de 100 GB. Sé que la ruta aprobada por Microsoft aumentará en un 20%, pero no estoy jugando con esto. Tenemos mucho espacio de disco de sobra en las matrices de discos de ensayo.
Desactivar el antivirus en todos los servidores no ayudó, aunque pensé que habría ayudado un poco. Por ahora he vuelto a habilitar el antivirus, pero configuré la ruta del grupo de replicación para que se excluya del escaneo a fin de eliminar esa variable de la ecuación.
¿Hay alguna manera de hacer que esto vaya más rápido? También haría este cambio en el servidor BETA también, pero hay archivos que han cambiado en ALPHA pero no se han replicado en BETA y al hacer el cambio de permiso heredado en BETA empujarían los archivos VIEJOS de BETA a ALPHA (porque parece que DFSR ignore las marcas de tiempo del archivo al comparar qué archivo es el ganador en una colisión). Y que eso suceda sería bastante malo.
El retraso se está reduciendo lentamente. Muy, muy despacio. Sin embargo, está avanzando. Pero a este ritmo, pasarán semanas antes de que termine. Estoy contemplando meter una copia del conjunto de datos en un disco de 3TB y enviarlo a la oficina remota. ¿Hay una mejor manera?
16 de mayo a las 4 a.m., hora del Pacífico de EE. UU .: ¿Qué pudo haber solucionado el problema?
Hice múltiples cambios en los DC que deberían haberse hecho hace mucho tiempo. El problema es que esta red fue heredada de otra persona que probablemente la heredó de otra persona, etc. No puedo prometer qué cambio solucionó el problema. Aquí no están en un orden particular:
- Todos los DC no estaban en la unidad organizativa "Controladores de dominio". Nunca he visto un dominio de Windows que tuviera sus DC en otro lugar. Los moví de regreso a donde pertenecían. Anteriormente estaban en unidades organizativas que estaban segregadas por el nombre de la ciudad en la que se encuentra cada oficina. (Tengo la sensación de que tengo que lidiar con algunos trabajos de plomería ahora que los mudé, pero todo parece estar bien en este momento ...)
- AVG Anti-Virus se ejecuta en todos los servidores DC y DFSR participantes. Excluí las carpetas replicadas y las carpetas de ensayo del análisis activo / en acceso. No creo que esto haya solucionado el problema y es probable que lo pruebe más adelante para ver si deshacer ese cambio interferirá con la velocidad de replicación de DFSR. Eso es un desafío para otro día.
- dcdiag.exe se quejó de un problema de DNS con respecto a los RODC. Remediamos ese problema a pesar de que no tenemos ningún RODC en el dominio. Dudo que esto haya solucionado algo.
- Faltaba uno de los registros SRV _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET para uno de los DC (no uno de los servidores DFSR) y lo solucioné. No creo que esto haya ayudado tampoco.
- Una de las veces que reinicié el servidor BETA se quejó de un mal cierre de la base de datos DFSR (evento 2212) y luego tardó horas en reconstruir la base de datos. Cuando terminó, informó el evento 2214 para informarme que terminó. Después de eso, la replicación seguía funcionando extremadamente lento, pero podría haber ayudado a despegar lo que estaba atascado.
- Uno de los DC no tenía 127.0.0.1 como servidor DNS secundario en su configuración de interfaz. Lo agregué Este no era uno de los servidores DFSR, por lo que probablemente no tenía nada que ver con eso.
- Seguí el blog de TechNet: Ajuste del rendimiento de replicación en la configuración de registro recomendada por DFSR para servidores DFSR. Usé todos los valores de "valor de alto rendimiento probado", excepto que AsyncIoMaxBufferSizeBytes se configuró en 4194304, que es una muesca más baja que el valor alto. Esto podría haber ayudado con el problema ... o tal vez no. Es difícil saber cuándo uno cambia demasiadas variables.
- dcdiag.exe se quejó de un problema con la comunicación con el servicio RPC en BETA, pero solo después de realizar los cambios anteriores. Este parecía ser el problema más probable, pero no hice nada para corregirlo. La VPN funcionaba correctamente y el firewall no la bloqueaba. Es posible que uno de los elementos anteriores sea lo que causó y luego solucionó el problema de RPC o podría haber sido una simple coincidencia. Estoy no conseguía que el error y la replicación ahora está funcionando sin problemas en la actualidad.
La moraleja de la historia es: cambiar una cosa a la vez o nunca sabrás realmente qué lo arregló. Pero estaba desesperado y se me estaba acabando el tiempo para arreglarlo, así que solo disparé un montón de balas al problema. Si alguna vez identifico la solución, lo reportaré aquí. Sin embargo, no confíes en mí reduciéndolo.
EDITAR 21/05/2012: Resolví esto conduciendo durante aproximadamente siete horas con un servidor de repuesto (GAMMA) a la oficina remota ayer. GAMMA ahora actúa como su servidor local principal, mientras que su servidor habitual (BETA) se pone al día con la replicación. Desde que lo puse en su lugar, los servidores han estado duplicando la velocidad de replicación. Si bien esto me dice que podría ser un problema relacionado con la VPN, estoy menos inclinado a creer que lo es, ya que todas las nuevas actualizaciones parecen replicarse a GAMMA desde ALPHA han sido muy rápidas y han funcionado bien.
EDITAR 22/05/2012: ahora es 12000 y debería estar terminado en unas pocas horas. Publicaré un buen gráfico del progreso desde el inicio lento hasta el final rápido. El problema es que lo único que realmente "solucionó" es la conexión del servidor local. Actualmente estoy pensando que tal vez la VPN sea parte del problema. Y si ese es el caso, creo que esta pregunta aún no está totalmente respondida. Después de tener más tiempo para comprobar cómo se replican las cosas a través de la VPN y ver cualquier falla, depuraré e informaré sobre el progreso.
Si algo cambia, actualizaré aquí.
dfsrdiag replicationstate /amuestra que solo está enviando dos archivos, pero ambos tienen el mismo nombre de archivo. Dice que, de todos modos, tiene dos conexiones salientes a BETA desde ALPHA. El archivo que está enviando es 850MB. Como se describió anteriormente, no estoy convencido de que en realidad esté enviando todo el contenido del archivo, aunque no estoy seguro de lo que haría si no, ya que lleva mucho tiempo lidiar con un solo archivo. El archivo se actualizó por última vez en 2008 (en ambos servidores), por lo que no hay razón para que tenga que hacer nada, excepto actualizar la información de ACL en el archivo en BETA.