Desistências ao acessar o compartilhamento pelo nome DFS

Question

Eu tenho um problema estranho, não são todos! Eu tenho uma raiz DFS \ domínio \ arquivos \ vms, ele tem um único destino em um servidor diferente do namespace.

Eu posso copiar um conjunto de arquivos de teste do destino diretamente via \ server \ vms $ \ testfiles e tudo está bem, os arquivos copiam bem. Eu repeti esses testes muitas vezes.

Se eu tentar copiar os arquivos da raiz do dfs, recebo grandes pausas no tráfego da rede, cerca de 50 segundos a cada dois minutos, todo o tráfego para a cópia. Se eu iniciar outra cópia entre as mesmas duas máquinas durante essa pausa, ela será copiada corretamente, por isso sei que não é um problema com os discos no servidor.

De vez em quando a cópia falhará, sem erros, a barra de progresso irá zipar até 100% e a caixa de diálogo de cópia será fechada. Verificar a pasta de destino mostra que a cópia está incompleta.

Mudei o LUN para outro servidor e tive o mesmo problema.

Os servidores são todos do 2008 R2, os clientes são Vista x64, Windows7 x64 e 2008 R2, todos têm o mesmo problema.

Alguém tem alguma ideia?

Felicidades,

Stephen

Mais informações:

Eu tenho executado um rastreamento NetMon na conexão quando a cópia do arquivo falha e o que parece estar se destacando é que ao abrir um arquivo que a cópia completa no comando SMB fica assim:

SMB2: C  CREATE (0x5), Name=Training\PDC2008\BB34 Live Services Notifications, Awareness, and Communications.wmv@#422082, Context=DHnQ, Context=MxAc, Context=QFid, Context=RqLs, Mid = 245376
SMB2: R  CREATE (0x5), Context=MxAc, Context=RqLs, Context=DHnQ, Context=QFid, FID=0xFFFFFFFF00000015, Mid = 245376

Mas o último arquivo quando a caixa de diálogo de cópia é fechada se parece com isso:

SMB2: C  CREATE (0x5), Name=gt\files\Media\Training\PDC2008\BB36 FAST Building Search-Driven Portals with Microsoft Office SharePoint Server 2007 and Microsoft Silverlight.wmv@#859374, Context=DHnQ, Context=MxAc, Context=QFid, Context=RqLs, Mid = 77
SMB2: R , Mid = 77 - NT Status: System - Error, Code = (58) STATUS_OBJECT_PATH_NOT_FOUND

A principal diferença parece estar no nome, uma é relativa ao compartilhamento de arquivos abertos, a outra ganhou o prefixo gt \ files \ media que é o nome do destino do DFS.

Essas falhas são sempre precedidas por logoff e back-on do destino SMB.

Pode ser necessário aumentar esse para o PSS.

    

Answer 1

Contanto que você tenha mais de um servidor raiz, exclua o servidor raiz DFS problemático, verifique se a pasta e o compartilhamento foram removidos. Em seguida, recrie essa raiz para que ela defina o compartilhamento de volta. O atraso de 50 segundos precedido pelo logoff, eu experimentei antes com seus sintomas relacionados exatos. Eu rastreei até dois servidores raiz que tiveram seu sistema operacional reconstruído, mas a configuração correspondente no DFS nunca foi limpa e reconfigurada para esses dois servidores. Concordando com Eric aqui, examine a configuração e a integridade apenas dos servidores de resolução de link raiz.

-Greg

    

Answer 2

Algum evento DFS aparecendo no Visualizador de Eventos no servidor DFS?

Um tiro no escuro, mas você está executando um software anti-malware no servidor / clientes? Em caso afirmativo, você tentou desativar temporariamente quaisquer recursos relacionados à rede para fins de solução de problemas?

    

Answer 3

Quais são os tempos limites de raiz e link definidos em seu namespace DFS? Você pode querer experimentar alongá-los. Isso tornará os clientes mais lentos para selecionar alterações no namespace. Se o seu namespace for estático, não há problema se os clientes executarem usando referências armazenadas em cache, em vez de verificar com o servidor de espaço para nome para uma nova referência.

    

Answer 4

Encontrei um problema com grandes atrasos ao acessar compartilhamentos de arquivos conectados por meio do DFS. Nós tínhamos uma tonelada de raízes DFS obsoletas (órfãs). Você já verificou lá?