A transferência de arquivos de rede VHD falha constantemente em 4 GB


16

Esse problema foi extremamente frustrante para nós: ao transferir um arquivo VHD (disco rígido virtual) grande de uma máquina Windows 7 pela rede para uma máquina Windows Server 2008 física em nosso datacenter, a transferência de arquivos do Windows falha com 4 GB de forma consistente. Temos uma conexão direta de 100 mbit do nosso escritório principal com o nosso data center.

Quando a transferência falha, a mensagem de erro que recebemos é:

There is a problem accessing \\server-name\d$ Make sure you are connected to the network and try again.

É apenas arquivos VHD maior do que 4 GB que falhar. Se enviarmos qualquer outro tipo de arquivo, ele funcionará bem. Se compactarmos o VHD, isso também funcionará. Além disso, podemos enviar um VHD na outra direção (do data center para o escritório principal) sem problemas. São apenas arquivos VHD nessa direção.

Anotações importantes:

  • Todas as partições são NTFS !!
  • Não há firewall entre a estação de trabalho e o servidor
  • Tentamos desativar o antivírus na estação de trabalho (nenhum antivírus no servidor)
  • Tentamos transferir o arquivo de uma máquina que não está no domínio
  • Tentamos transferir o arquivo de uma máquina Ubuntu (ainda falha, mas com cerca de 450 MB em vez de 4 GB)
  • A captura do Wireshark mostra 40 DUP ACKs quando a transferência falha
  • Xcopy e Robocopy (com sinalizadores de reinicialização) ambos falham (mesmo ponto)
  • A transferência FTP falha em 4,14X, XXX, XXX bytes e não pode ser reiniciada nesse momento
  • Tentamos alterar a extensão do arquivo (estúpido, mas um último recurso) para algo diferente de vhd antes de enviá-lo, mas ele ainda falhou
  • A conexão é a seguinte: Estação de trabalho Dell (escritório principal) -> Switch gerenciado Dell PowerConnect 5448 (MO) -> Roteador HP Procurve 2910al-24G camada 3 (MO) -> Link TLS 100Mb -> Roteador HP Procurve 2910al-24G camada 3 ( Data center) -> Dell PowerConnect 5448 Managed Switch (DC) -> Servidor Dell (DC)

Então, basicamente, são APENAS arquivos vhd> 4 GB, do escritório principal ao datacenter que falham. Tudo isso simplesmente não se resume ... neste momento, acredito que seja um problema com as configurações de hardware da rede, mas não entendo qual é a diferença entre transferir um VHD grande (que falha, a 4 GB) e um arquivo de vídeo grande (que funciona sempre).


Você tentou outro protocolo depois do CIFS / SMB?
Bart De Vos

Não, eu não tenho; Eu vou dar um que tente
Isaac Butt

11
Deixe-me reformular, que tipo de equipamento de rede lida com essa conexão de 100Mb?
SpacemanSpiff

2
Presumivelmente, se a inspeção profunda de pacotes é responsável (o que parece provável), usar um mecanismo de transferência criptografado, como SFTP ou SCP, resolveria o problema. Ou você pode usar o IPSec, que é incorporado ao Windows. Ou talvez os roteadores tenham algum tipo de suporte de túnel criptografado?
Harry Johnston

2
@HarryJohnston Depois de configurar o SFTP, os arquivos VHD são transferidos com sucesso, então parece que você estava certo sobre o DPI no TLS. Eu vou falar com nosso fornecedor e ver se há algo que possamos fazer sobre isso :)
Isaac Butt

Respostas:


3

Após solucionar esse problema por muitas horas (e tentar todas as sugestões postadas aqui), o problema acabou sendo o link TLS entre o escritório principal e o datacenter. Liguei para o provedor TLS e, depois de conversar com vários técnicos do NOC, um deles já havia ouvido falar do problema exato antes. Verificou-se que alguns dos equipamentos da camada 2 eram antigos e tinham problemas com os dados VHD.

A solução estava atualizando o firmware nesses dispositivos, executado pelo provedor TLS. Agora não temos problemas ao transferir VHDs grandes. Para os interessados, nosso provedor TLS é a Shaw Communications em Victoria, Canadá.


1

Experimente o Xcopy ou o Robocopy; pelo menos um ou ambos têm uma opção de "retomar". Rsync também pode ser útil.

Por curiosidade, uma das máquinas é de 32 bits, mas a outra é de 64 bits? Nesse caso, você pode tentar sua cópia temporariamente com uma máquina de 64 bits.


Tanto o Robocopy quanto o Xcopy também falham no mesmo ponto, mesmo com a opção de retomar (e com buffer / sem buffer). O servidor e a estação de trabalho são de 64 bits.
Isaac Butt

Brutal. A única opção em que posso pensar em corrigir é verificar a opção VHD de 2 GB no ESX. Minhas condolencias.
gWaldo

Não tem problema, eu aprecio sua ajuda :) (estamos usando o Hyper-V não VMWare)
Isaac Butt

Bom ponto; Eu usei um monte de virtualização de plataformas, então eu mentalmente analisá-los quanto $ disk_file ou US $ config_file, etc ...
gWaldo

0

Pesquisando no Google por falhas de cópia na rede de arquivos grandes, você encontrará alguns tópicos falando sobre problemas semelhantes, mas não apenas os VHDs. Esse KB geralmente está vinculado para verificar se os ajustes da NIC ajudam. Descarregamento de TCP, configurações de chaminé, etc.

http://support.microsoft.com/kb/951037


Obrigado pelas sugestões. Posso transferir outros arquivos grandes sem problemas, mas analisarei algumas dessas configurações. Desativar a descarga da chaminé não tem efeito.
Isaac Butt

0

Mmmmhhhh ... Vejo as várias respostas acima e percebo que ainda não sei dizer se você realmente tentou copiar com um programa de cópia de 64 bits. (xcopy, robocopy e a maioria dos clientes FTP são de 32 bits, mesmo em um Windows de 64 bits.)

Você pode tentar com a versão de 64 bits do TotalCommander V8.0? (Ainda é um candidato a lançamento, mas muito estável.) Isso é realmente apenas de 64 bits.

Outra coisa a tentar se o servidor tiver o IPV6 ativado (geralmente o W2K8): desative o IPV4 completamente na estação de trabalho para que a cópia precise usar o IPV6. Será interessante ver se isso faz diferença.

Se nenhuma das opções acima trouxer alívio ... Você sempre pode usar o HJSplit (ou a função de divisão do TotalCommander) para dividir o arquivo em pedaços de 1 GB, mas é claro que você deve ter um meio de se juntar a eles no servidor. Isso dependerá se você tiver acesso para executar um programa no próprio servidor. (Apenas "copy / b chunk1 + chunk2 + chunk3 total.vhd" funcionará se você não tiver permissão para instalar software adicional no lado do servidor.)


Tentei o TotalCommander 8, a transferência falhou antes mesmo de 4 GB e informa "Remova a proteção contra gravação!" mas não acredito que realmente indique um erro de proteção contra gravação.
Isaac Butt

Temos outras maneiras de mover os dados. Eu poderia apenas RAR o arquivo e transferi-lo (nem precisa dividi-lo em pequenos pedaços), mas é uma etapa extra que realmente não devemos fazer. Obrigado pela sugestão, agradeço a sua ajuda.
Isaac Butt

0

Apenas um pensamento: o VHD está sendo usado pelo hipervisor ou montado?

Pode estar falhando porque parte do VHD está bloqueado e não pode ser lido no sistema de arquivos. É por isso que o zíper do arquivo funciona e os arquivos de vídeo do mesmo tamanho também funcionam, mas não os arquivos VHD.

Procurando um bloqueio de arquivo no Windows:

  1. Baixe o explorador de processos (link direto para live.sysinternals.com)
  2. Selecione o menu Localizar, escolha Localizar identificador ou DLL ...
  3. Digite o nome do arquivo, selecione pesquisar.

Parece haver um posto de troca de especialistas com problemas semelhantes. Mas não há resoluções nas respostas.


Bom ponto. Às vezes, você precisa reiniciar a estação de trabalho para desbloquear o arquivo. Pode parecer gratuito, mas você nunca pode realmente dizer.
Tonny

@ Tony Você com certeza sabe que precisa das ferramentas certas. Atualizei minha resposta com um método sugerido.
Joseph Kern

Sim, eu vi o artigo de troca de especialistas e parece semelhante. O explorador de processos não mostra nada para o arquivo. Além disso, posso fazer uma cópia e a tentativa de transferir a cópia ainda falha, para que não pareça haver um bloqueio. O Total Commander 8 RC (64 bits) falha tão cedo quanto 2 GB na transferência com a mensagem "Remova a proteção contra gravação!" embora isso seja provavelmente apenas uma resposta a erro de estoque.
Isaac Butt

11
Essa resposta do TC é realmente útil. Ele enviará essa mensagem apenas na metade da cópia, se houver realmente algo bloqueando a tentativa de gravação. Isso deve estar no lado do servidor ou relacionado à LAN / WAN. Você tem certeza de que a LAN é realmente transparente? Eu procuraria um roteador executando a Statefull Packet Inspection ou um dispositivo Network Accelerator (por exemplo, dispositivo Cisco WAAS) que de alguma forma se confunda com esse tipo específico de dados.
Tonny

Hmm, bem, a linha deve ser transparente; Eu poderia ligar para o nosso provedor e dizer o que está acontecendo, embora aposto que eles vão direcionar a culpa para outro lugar.
Isaac Butt

0

Isso pode até parecer um problema de permissão. Quando você tenta copiar o arquivo para o local da rede em que ele pára ou falha, talvez você possa tentar criar uma pasta de rede para torná-lo totalmente aberto, o que significa que é compartilhado com o grupo "Todos" e também defina isso na guia segurança. Se isso resolver o problema, parece um problema de permissão; na verdade, como você mencionou que a cópia do Linux falhou antes, parece que as permissões podem ser o problema. Verifique se os arquivos dentro do VHD não estão em uso e se você tem permissões adequadas para acessá-los.

Verifique também se a pasta da qual você está copiando tem permissões abertas. Lembre-se de que isso é apenas para verificar se as permissões estão atrapalhando; você sempre pode reforçá-las mais tarde, depois que um ponto de partida da cópia estiver funcionando corretamente.

Outra coisa e pode ser um tiro no escuro, mas você já tentou atualizar os drivers da NIC? Talvez possa haver uma correção no driver mais recente da sua máquina.

Espero que isso ajude, Saúde


Obrigado pela sugestão, mas isso não explica por que a transferência de arquivos foi bem-sucedida se os dados foram criptografados. Ainda acho que o problema está na linha TLS; Estou em conversações com o seu apoio no momento
Isaac Butt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.