Le transfert de fichiers réseau VHD échoue systématiquement à 4 Go

16

Ce problème a été extrêmement frustrant pour nous: lors du transfert d'un gros fichier VHD (disque dur virtuel) d'une machine Windows 7 sur le réseau vers une machine physique Windows Server 2008 dans notre centre de données, le transfert de fichiers Windows échoue à 4 Go de manière cohérente. Nous avons une connexion directe de 100 Mbits entre notre bureau principal et notre centre de données.

Lorsque le transfert échoue, le message d'erreur que nous recevons est:

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

Il est seulement des fichiers VHD plus de 4 Go qui échouent. Si nous envoyons un autre type de fichier, cela fonctionne très bien. Si nous compressons le VHD, cela fonctionne également. De plus, nous pouvons envoyer un VHD dans l'autre sens (du centre de données au bureau principal) sans problème. Ce ne sont que des fichiers VHD dans cette direction.

Notes IMPORTANTES:

  • Toutes les partitions sont NTFS !!
  • Il n'y a pas de pare-feu entre le poste de travail et le serveur
  • Nous avons essayé de désactiver l'antivirus sur le poste de travail (pas d'antivirus sur le serveur)
  • Nous avons essayé de transférer le fichier depuis une machine qui n'est pas sur le domaine
  • Nous avons essayé de transférer le fichier depuis une machine Ubuntu (échoue toujours mais à environ 450 Mo au lieu de 4 Go)
  • La capture de Wireshark montre 40 DUP ACK lorsque le transfert échoue
  • Xcopy et Robocopy (avec drapeaux de redémarrage) échouent tous les deux (même point)
  • Le transfert FTP échoue à 4,14X, XXX, XXX octets et ne peut pas être redémarré à ce stade
  • Nous avons essayé de changer l'extension du fichier (stupide, mais en dernier recours) par autre chose que vhd avant de l'envoyer, mais cela a quand même échoué
  • La connexion est la suivante: Dell Workstation (bureau principal) -> Dell PowerConnect 5448 Managed Switch (MO) -> HP Procurve 2910al-24G Layer 3 Layer (MO) -> 100Mb TLS link -> HP Procurve 2910al-24G Layer 3 Router 3 ( Centre de données) -> Dell PowerConnect 5448 Managed Switch (DC) -> Dell Server (DC)

Donc, en gros, ce sont les fichiers vhd JUST> 4 Go, de notre bureau principal à notre centre de données qui échouent. Tout cela ne correspond pas ... à ce stade, je pense que c'est un problème avec nos paramètres matériels du réseau, mais je ne comprends pas quelle est la différence entre le transfert d'un grand disque dur virtuel (qui échoue, à 4 Go) et un grand fichier vidéo (qui fonctionne toujours).

file-sharing vhd windows Isaac Butt
la source
Avez-vous essayé un autre protocole que CIFS / SMB?
Bart De Vos
Non, je ne l'ai pas fait; Je vais essayer
Isaac Butt
1
Permettez-moi de reformuler, quel type d'équipement réseau gère cette connexion de 100 Mo?
SpacemanSpiff
2
Vraisemblablement, si l'inspection approfondie des paquets est à blâmer (ce qui semble probable), l'utilisation d'un mécanisme de transfert crypté tel que SFTP ou SCP contournerait le problème. Ou vous pouvez utiliser IPSec, qui est intégré à Windows. Ou peut-être que les routeurs ont une sorte de support de tunnel crypté?
Harry Johnston
2
@HarryJohnston Après avoir configuré SFTP, les fichiers VHD ont été transférés avec succès, il semble donc que vous ayez raison sur DPI sur le TLS. Je vais parler à notre fournisseur et voir s'il y a quelque chose qu'ils peuvent faire à ce sujet :)
Isaac Butt

Réponses:

3

Après avoir résolu cela pendant plusieurs heures (et essayé toutes les suggestions publiées ici), le problème s'est avéré être le lien TLS entre notre bureau principal et le centre de données. J'ai appelé notre fournisseur TLS et après avoir parlé à plusieurs techniciens du CNO, l'un d'eux avait déjà entendu parler du problème. Il s'est avéré que certains de leurs équipements de couche 2 étaient vieux et avaient des problèmes avec les données VHD.

La solution consistait à mettre à niveau le micrologiciel de ces appareils, ce qui a été effectué par le fournisseur TLS. Nous n'avons maintenant aucun problème pour transférer de gros disques durs virtuels. Pour les personnes intéressées, notre fournisseur TLS est Shaw Communications à Victoria, Canada.

Isaac Butt
la source
1

Essayez Xcopy ou Robocopy; au moins un ou les deux ont un interrupteur "reprise". Rsync peut également être utile.

Par curiosité, l'une des machines est-elle 32 bits, mais l'autre est 64 bits? Si tel est le cas, pouvez-vous essayer temporairement votre copie avec une machine 64 bits.

gWaldo
la source
Robocopy et Xcopy échouent également au même point, même avec le commutateur de reprise (et tamponné / non tamponné). Le serveur et la station de travail sont en 64 bits.
Isaac Butt,
Brutal. La seule option à laquelle je peux penser est de vérifier l'option VHD de 2 Go dans ESX. Mes condoléances.
gWaldo
Pas de problème, j'apprécie votre aide :) (nous utilisons Hyper-V et non VMWare)
Isaac Butt
Bon point; J'ai utilisé un tas de plates-formes de virtualisation, donc je les analyse mentalement comme $ disk_file ou $ config_file, etc ...
gWaldo
0

En recherchant sur Google les échecs de copie du réseau de fichiers volumineux, vous trouverez des discussions sur des problèmes similaires, mais pas seulement sur les VHD. Cette base de connaissances est généralement liée pour voir si l'ajustement des paramètres NIC aide. Déchargement TCP, réglages de cheminée, etc.

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

Willy
la source
Merci pour les suggestions. Je peux transférer d'autres gros fichiers sans problème, mais je vais essayer de modifier certains de ces paramètres. La désactivation du déchargement de la cheminée n'a aucun effet.
Isaac Butt
0

Mmmmhhhh ... Je vois les différentes réponses ci-dessus et je me rends compte que je ne peux toujours pas dire si vous avez vraiment essayé de copier avec un programme de copie 64 bits. (xcopy, robocopy et la plupart des clients FTP sont 32 bits, même sous Windows 64 bits.)

Pouvez-vous l'essayer avec la version 64 bits de TotalCommander V8.0? (Il s'agit toujours d'une version candidate, mais très stable.) Il s'agit vraiment de 64 bits uniquement.

Une autre chose à essayer si IPV6 est activé sur le serveur (généralement sur W2K8): Désactivez complètement IPV4 sur le poste de travail pour que la copie doive utiliser IPV6. Sera intéressant de voir si cela fait une différence.

Si aucun des éléments ci-dessus ne soulage ... Vous pouvez toujours utiliser HJSplit (ou la fonction de division de TotalCommander) pour diviser le fichier en morceaux de 1 Go, mais bien sûr, vous devez avoir un moyen de les rejoindre à nouveau sur le serveur. Cela dépendra si vous avez accès à l'exécution d'un programme sur le serveur lui-même. (Juste "copier / b chunk1 + chunk2 + chunk3 total.vhd" fera l'affaire si vous n'êtes pas autorisé à installer des logiciels supplémentaires côté serveur.)

Tonny
la source
Essayé TotalCommander 8, le transfert échoue même avant 4 Go et signale "Veuillez supprimer la protection en écriture!" mais je ne crois pas que cela indique réellement une erreur de protection en écriture.
Isaac Butt,
Nous avons d'autres façons de déplacer les données. Je pourrais simplement RAR le fichier et le transférer (pas même besoin de le diviser en petits morceaux), mais c'est une étape supplémentaire que nous ne devrions vraiment pas avoir à faire. Merci pour cette suggestion, j'apprécie votre aide.
Isaac Butt
0

Juste une pensée: le VHD est-il utilisé par l'hyperviseur ou monté?

Il peut échouer car une partie du disque dur virtuel est verrouillée et ne peut pas être lue à partir du système de fichiers. C'est pourquoi la fermeture éclair du fichier fonctionne et pourquoi les fichiers vidéo de la même taille fonctionnent également, mais pas les fichiers VHD.

Vous cherchez un verrou de fichier dans Windows:

  1. Télécharger l' explorateur de processus (lien direct vers live.sysinternals.com)
  2. Sélectionnez le menu Find, choisissez Find Handle ou DLL ...
  3. Saisissez le nom du fichier, sélectionnez Rechercher.

Il semble qu'il y ait un poste d'échange d'experts avec des problèmes similaires. Mais il n'y a pas de résolutions dans les réponses.

Joseph Kern
la source
Bon point. Parfois, vous devez même redémarrer le poste de travail pour qu'il déverrouille vraiment le fichier. Il peut sembler gratuit, mais vous ne pouvez jamais vraiment le dire.
Tonny
@Tonny Vous pouvez le dire, vous avez juste besoin des bons outils. Mis à jour ma réponse avec une méthode suggérée.
Joseph Kern
Ouais, j'ai vu l'article d'échange d'experts et cela semble similaire. L'explorateur de processus n'affiche rien pour le fichier. De plus, je peux en faire une copie et essayer de transférer la copie échoue toujours donc il ne semble pas y avoir de verrou. Total Commander 8 RC (64 bits) échoue dès 2 Go dans le transfert avec un message "Veuillez supprimer la protection en écriture!" bien que ce soit probablement juste une réponse d'erreur de stock.
Isaac Butt
1
Cette réponse de TC est réellement utile. Il ne donnera ce message à mi-chemin de la copie que si quelque chose bloque vraiment la tentative d'écriture. Cela doit être côté serveur ou lié au LAN / WAN. Êtes-vous certain que le LAN est vraiment transparent? Je rechercherais un routeur faisant l'inspection de paquet de Statefull, ou un dispositif d'accélérateur de réseau (par exemple l'appliance de Cisco WAAS) qui obtient d'une certaine manière confus au sujet de ce type particulier de données.
Tonny
Hmm, la ligne est censée être transparente; Je pourrais appeler notre fournisseur et leur dire ce qui se passe, bien que je parie qu'ils dirigeront le blâme ailleurs.
Isaac Butt
0

Il semble que cela puisse même être un problème d'autorisations, lorsque vous essayez de copier le fichier vers l'emplacement réseau où il est arrêté ou échoue, vous pouvez peut-être essayer de créer un dossier réseau pour le rendre complètement ouvert, c'est-à-dire partagé avec le groupe "Tout le monde" et également définir de cette façon dans l'onglet de sécurité. Si cela résout le problème, cela ressemble à un problème d'autorisations, en fait, puisque vous avez mentionné que la copie Linux a échoué plus tôt, il semble que les autorisations soient le problème. Assurez-vous que les fichiers à l'intérieur du disque dur virtuel ne sont pas utilisés et que vous disposez des autorisations appropriées pour y accéder.

Assurez-vous également que le dossier à partir duquel vous copiez possède des autorisations ouvertes. N'oubliez pas que c'est juste pour voir si les autorisations gênent, vous pouvez toujours les resserrer plus tard une fois que le point de départ de la copie fonctionne correctement.

Une autre chose et cela pourrait être long, mais avez-vous essayé de mettre à jour les pilotes NIC? Il existe peut-être un correctif dans le pilote le plus récent pour votre machine.

J'espère que cela aide, Cheers

Frank R
la source
Merci pour la suggestion, mais cela n'explique pas pourquoi le transfert de fichiers est réussi si les données sont cryptées. Je pense toujours que le problème réside dans la ligne TLS; Je suis en pourparlers avec leur soutien en ce moment
Isaac Butt