Windows DFSR - Alterou as permissões de diretório replicado e agora possui um atraso de 350.000 por mais de uma semana

Pergunta: Existe uma maneira de tornar esse atraso de 350.000 arquivos mais rápido? Para quase todos os arquivos, a única alteração foi uma alteração na ACL de cada arquivo afetado. Alguns arquivos alteraram o conteúdo, mas esse não é o caso comum nessa situação.

Isso pode ser corrigido. Editarei este texto para confirmar o êxito / falha após um período de tempo e verificação. No final deste texto da pergunta, detalhei as alterações feitas recentemente que podem ter sido corrigidas.

Temos um grupo de replicação DFSR com cerca de 450.000 arquivos e ocupa 1,5 TB de espaço. Nessa situação, existem dois servidores Windows Server 2008 R2 separados por cerca de 500 milhas. Existem outros servidores, mas eles não estão envolvidos nesse grupo de replicação. Servidor ALPHA é o servidor principal e é usado pela maioria dos funcionários. Servidor BETA é o servidor no escritório remoto e está menos ocupado.

Aqui está um gráfico da lista de pendências para esse grupo de replicação (PNG hospedado no Google Drive) mostrando o progresso lento da sincronização.

Eu precisava remover uma entrada de permissão que estava no diretório raiz desse grupo de replicação, que obviamente foi herdada na maioria das subpastas. Eu fiz essa alteração no servidor ALPHA. Imediatamente depois disso, o DFSR teve um atraso de 350.000 arquivos. Já faz mais de uma semana e agora é de 267.000. A única coisa que mudou (inicialmente) foi a alteração de permissão única.

Foi o que aconteceu (esta não é a solução, apenas mais uma explicação do que causou esse problema): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -porque-acontece-sexta-noite-estava-tudo-bem-para-lutar.aspx # dfsr

Quaisquer alterações que ocorram no servidor BETA são replicadas para o servidor ALPHA muito rapidamente, pois não há lista de pendências nessa direção. Quaisquer arquivos alterados no BETA chegam ao ALPHA sem problemas.

Ele está replicando 24 horas por dia, 7 dias por semana, a toda velocidade, através de uma conexão de 50 Mbps de uma extremidade para uma fibra de 100 Mbps na outra extremidade. A área de preparação é de 100 GB em cada servidor. Não há nada interessante nos logs de eventos. Há um evento de marca d'água alta não relacionado que aparece para um grupo de replicação não relacionado que não é para esta replicação específica nem para este par de servidores ALPHA / BETA. Em particular, não há entradas no log de eventos para marca d'água alta nem para erros de conexão.

Visão da ALPHA do grupo de replicação:

Economia de largura de banda : redução de 99,83% (30,85 MB replicados em vez de 18,1 GB)

Acredito que os 30.85MB / 18.1GB ocorreram desde a última vez em que reiniciei o serviço DFSR no ALPHA e BETA. Nesse caso, isso mostra que, embora esteja demorando muito tempo (mais do que eu acredito que deveria levar), na verdade, não está transferindo o conteúdo do arquivo pela conexão.

Pasta replicada : 1,46 TB (tamanho real), 439,387 (arquivos), 52,886 (pastas)

Pasta Conflito e Excluída : 100,00 GB (tamanho configurado), 34,01 GB (tamanho real), 19,620 (arquivos), 2,393 (pastas)

Pasta de teste : 200,00 GB (tamanho configurado), 92,54 GB (tamanho real)

Eu recebi um erro de marca d'água alta nos logs (14 de maio às 19:00) e, portanto, aumentamos a cota de teste para 200 GB a partir de 100 GB. Eu sei que a rota aprovada pela Microsoft deve aumentar em 20%, mas não estou brincando com isso. Temos bastante espaço em disco para poupar nas matrizes de disco temporário.

Desabilitar o antivírus em todos os servidores não ajudou, embora eu pensasse que teria ajudado um pouco. Por enquanto, reativei o antivírus, mas defina o caminho do grupo de replicação para ser excluído da verificação, a fim de remover essa variável da equação.

Existe uma maneira de fazer isso ir mais rápido? Eu também faria essa alteração no servidor BETA, mas há arquivos que foram alterados no ALPHA, mas que não foram replicados para BETA, e, ao fazer a alteração da permissão herdada no BETA, os arquivos VELHOS foram transferidos de BETA para ALPHA (porque o DFSR parece ignore os registros de data e hora do arquivo ao comparar qual arquivo é o vencedor em uma colisão). E isso acontecer seria muito ruim.

A lista de pendências está diminuindo lentamente. Muito, muito devagar. Está indo para frente, no entanto. Mas, nesse ritmo, levará semanas para terminar. Estou pensando em colocar uma cópia do conjunto de dados em uma unidade de 3 TB e enviá-la para o escritório remoto. Existe uma maneira melhor?

16 de maio, 04:00 EUA PT: O que pode ter corrigido o problema (supondo que seja honestamente corrigido, de qualquer maneira):

Fiz várias alterações nos CDs que deveriam ter sido feitas há muito tempo. O problema é que essa rede foi herdada de outra pessoa que provavelmente a herdou de outra pessoa etc. Não posso prometer qual mudança corrigiu o problema. Aqui eles estão em nenhuma ordem particular:

• Todos os controladores de domínio não estavam na UO "Controladores de Domínio". Eu nunca vi um domínio do Windows que tivesse seus CDs em outro lugar. Mudei-os de volta para onde eles pertenciam. Eles estavam anteriormente em UOs que eram segregadas pelo nome da cidade em que cada escritório se encontra. (Sinto que tenho alguns trabalhos de encanamento para lidar agora que os mudei, mas tudo parece estar bom no momento ...)
• O AVG Anti-Virus está sendo executado em todos os servidores participantes do DC e do DFSR. Excluí as pastas replicadas e as temporárias da verificação ativa / ao acessar. Não acho que isso tenha corrigido o problema e provavelmente testarei esse problema mais tarde, para ver se desfazer essa alteração interferirá na velocidade de replicação do DFSR. Esse é um desafio para outro dia.
• O dcdiag.exe reclamou de um problema de DNS em relação aos RODCs. Corrigi o problema, mesmo que não tenhamos RODCs no domínio. Duvido que isso tenha corrigido alguma coisa.
• Um dos registros SRV _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET estava ausente para um dos controladores de domínio (não um dos servidores DFSR) e eu o corrigi. Eu também não acho que isso tenha ajudado.
• Uma vez que reiniciei o servidor BETA, ele se queixou de um desligamento incorreto do banco de dados DFSR (evento 2212) e, em seguida, passou horas para reconstruir o banco de dados. Quando concluído, relatou o evento 2214 para que eu saiba que terminou. Depois disso, a replicação ainda estava sendo executada lentamente, mas poderia ter ajudado a descolar o que estava travado.
• Um dos controladores de domínio não tinha 127.0.0.1 como servidor DNS secundário em sua configuração de interface. Eu adicionei. Este não era um dos servidores DFSR, portanto provavelmente não tinha nada a ver com isso.
• Segui o Blog do TechNet: Ajustando o desempenho da replicação nas configurações de registro recomendadas pelo DFSR para servidores DFSR. Usei todos os valores de "valor de alto desempenho testado", exceto AsyncIoMaxBufferSizeBytes, que foram definidos para 4194304, que é um ponto abaixo do valor alto. Isso poderia ter ajudado com o problema ... ou talvez não. É difícil dizer quando alguém altera muitas variáveis.
• O dcdiag.exe reclamou de um problema com a comunicação com o serviço RPC no BETA, mas somente depois de fazer as alterações acima. Esse parecia ser o problema mais provável, mas não havia nada que eu fiz para corrigi-lo. A VPN estava funcionando corretamente e o firewall não a estava bloqueando. É possível que um dos itens acima tenha causado e corrigido o problema de RPC ou poderia ter sido uma simples coincidência. Estou não recebendo esse erro agora e replicação está funcionando perfeitamente no presente.

A moral da história é: mude uma coisa de cada vez ou você nunca saberá realmente o que a corrigiu. Mas eu estava desesperado e estava ficando sem tempo para consertá-lo, então apenas atirei várias balas no problema. Se alguma vez identificar a correção, relatarei isso aqui. Não confie em mim, diminuindo-o.

EDIT 21/05/2012: Eu resolvi isso dirigindo por cerca de sete horas com um servidor sobressalente (GAMMA) no escritório remoto ontem. A GAMMA agora está atuando como seu servidor local principal, enquanto o servidor usual (BETA) atualiza a replicação. Desde que eu o instalei, os servidores passaram o dobro da velocidade de replicação. Embora isso me diga que pode ser um problema relacionado à VPN, estou menos inclinado a acreditar que é porque todas as novas atualizações parecem replicar para o GAMMA do ALPHA foram muito rápidas e estão indo bem.

EDIT 22/22/2012: Chegam às 12000 e devem terminar em algumas horas. Vou postar um bom gráfico do progresso, do início lento ao final rápido. O problema é que a única coisa que realmente "consertou" é a conexão do servidor local. Atualmente, estou pensando que talvez a VPN faça parte do problema. E se for esse o caso, sinto que essa pergunta ainda não está respondida. Depois de ter mais tempo para verificar como as coisas estão se replicando via VPN e vendo falhas, depurarei e relatarei o progresso.

Se algo mudar, atualizarei aqui.

Problema muito estranho, especialmente depois de revisar a edição.

Eu inspecionaria o log de depuração do DFSR, que está localizado aqui:% systemroot% \ debug Por padrão, deve haver 9 arquivos de log anteriores que foram arquivados pelo GZ e um que está sendo gravado no momento.

Abra isso em um arquivo de texto e faça uma pesquisa pelo texto "aviso" ou "erro". Você pode conferir esta série de blogs para obter informações mais detalhadas sobre os logs de depuração: http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1- níveis de log-formato-log-guid-s.aspx

Outras perguntas / sugestões:

Há algo fora do lugar ao olhar para o Monitor de Recursos? Excesso de atividade do disco rígido ou da CPU que está fora da linha de base?

Se possível, eu reiniciaria os servidores Alpha e Beta. Se o problema for resolvido, talvez você nunca saiba qual era o problema real, mas se for crítico que isso seja resolvido em breve, vale a pena tentar.

Editar com base na atualização da pergunta

Você mencionou duas entradas relacionadas a um arquivo de 850 MB, além de um erro no log de depuração do DFSR.

Você pode tentar alterar o local de armazenamento temporário para uma pasta ou unidade diferente em cada servidor? Caso os arquivos que estão sendo testados no momento estejam corrompidos ou bloqueando a replicação de alguma forma.

Você pode ajustar o agendamento da replicação para permitir que o DFS-R seja replicado em velocidade máxima durante o horário de folga (ou mesmo horas, se apropriado).

Você também pode tentar aumentar o tamanho do teste no servidor com logon atrasado. Deve aumentar o desempenho nessa situação.

Você não menciona se está limitado ou não, mas presumo que seja porque você tem replicação em uma WAN.

Minha experiência é que é assim que funciona.

Eu me deparei com isso depois de atualizar a segurança em uma coleção bastante pequena de 4 grupos de replicação DFS (dados de 550 GB, arquivos de 58k, pastas de 3.4k no total). Os dados realmente transmitidos na conexão são baixos e, portanto, parece não estar movendo arquivos inteiros apenas para alterações de segurança, mas a atividade do disco parece que toda a hierarquia está sendo copiada novamente - taxas sustentadas de transferência de disco entre 60-100 MB / s e filas de disco de 30, chegando a 500 no espaço de armazenamento em camadas SSD.

Meu senso é que o DFS tem muita rotatividade em seu processo de preparação e destino, o que resulta em extrema E / S de disco. Um processo de replicação inicial entre duas caixas conectadas à LAN de gigabit leva vários minutos a mais do que os mesmos dados simplesmente copiados entre caixas, o que parece indicar que cada byte replicado requer vários bytes de leitura e gravação em disco.

As atualizações de segurança parecem não ter nenhuma lógica de replicação especial, exceto o uso da segurança baseada em declarações de 2012 (que não é amplamente usada AFAICT), resultando no mesmo estágio / rotatividade de destino que você obteria para alterações de dados.