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í.
fuente
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.Respuestas:
Problema muy extraño, especialmente después de revisar la edición.
Inspeccionaría el registro de depuración DFSR, que se encuentra aquí:% systemroot% \ debug De manera predeterminada, debería haber 9 archivos de registro anteriores que se han archivado GZ, y uno en el que se está escribiendo actualmente.
Ábralo en un archivo de texto y busque el texto "advertencia" o "error". Puede consultar esta serie de blogs para obtener información más detallada sobre los registros de depuración: http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1- logging-niveles-log-format-guid-s.aspx
Otras preguntas / sugerencias:
¿Hay algo fuera de lugar al mirar el Monitor de recursos? ¿Exceso de disco duro o actividad de CPU fuera de la línea de base?
Si es posible, reiniciaría los servidores Alpha y Beta. Si resuelve su problema, es posible que nunca sepa cuál fue el verdadero problema, pero si es crítico que se resuelva pronto, vale la pena intentarlo.
Edición basada en la actualización de preguntas
Mencionó dos entradas relacionadas con un archivo de 850 MB, así como un error dentro del registro de depuración DFSR.
¿Puede intentar cambiar la Ubicación provisional en una carpeta o unidad diferente en cada servidor? En caso de que los archivos que se están organizando actualmente estén dañados o bloqueen la replicación de alguna manera.
fuente
Puede ajustar el programa de replicación para permitir que DFS-R se replique a toda velocidad durante las horas libres (o incluso en horas si corresponde).
También puede intentar aumentar el tamaño de preparación en el servidor registrado de nuevo. Debería aumentar el rendimiento en esta situación.
No mencionas si está limitado o no, pero supongo que es así porque tienes replicación en una WAN.
fuente
Mi experiencia es que así es como funciona.
Me topé con esto después de actualizar la seguridad en una colección bastante pequeña de 4 grupos de replicación DFS (550 GB de datos, 58k archivos, 3.4k carpetas en total). Los datos realmente transmitidos en el cable son bajos, por lo que parece que no se están moviendo archivos completos solo por cambios de seguridad, pero la actividad del disco parece que se está volviendo a copiar toda la jerarquía: velocidades de transferencia de disco sostenidas entre 60-100 MB / seg, y colas de disco de 30, alcanzando un máximo de 500 en espacio de almacenamiento en niveles SSD.
Tengo la sensación de que DFS tiene mucha rotación en su proceso de puesta en escena y desestabilización que da como resultado una E / S de disco extrema. Un proceso de replicación inicial entre dos cajas conectadas a LAN de gigabits lleva más tiempo que los mismos datos simplemente copiados entre cajas, lo que parece indicar que cada byte replicado requiere múltiples bytes de lectura y escritura de disco.
Las actualizaciones de seguridad no parecen tener una lógica de replicación especial que prohíba el uso de la seguridad basada en notificaciones de 2012 (que no es ampliamente utilizada AFAICT), lo que da como resultado la misma etapa / deserción que obtendría para los cambios de datos.
fuente