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.
dfsrdiag replicationstate /amostra que está enviando apenas dois arquivos, mas ambos têm o mesmo nome de arquivo. Ele diz que tem duas conexões de saída para BETA da ALPHA, de qualquer maneira. O arquivo que está enviando é de 850 MB. Como descrito anteriormente, não estou convencido de que ele esteja realmente enviando o conteúdo do arquivo inteiro, embora não tenha certeza do que estaria fazendo se não, pois leva muito tempo apenas para lidar com um único arquivo. O arquivo foi atualizado pela última vez em 2008 (nos dois servidores), portanto, não há motivo para que ele faça alguma coisa, exceto atualizar as informações da ACL no arquivo no BETA.