Il trasferimento di file di rete VHD non riesce costantemente a 4 GB


16

Questo problema è stato estremamente frustrante per noi: quando si trasferisce un file VHD (disco rigido virtuale) di grandi dimensioni da un computer Windows 7 in rete a un computer Windows Server 2008 fisico nel nostro datacenter, il trasferimento di file Windows non riesce a 4 GB in modo coerente. Abbiamo una connessione diretta a 100 mbit dalla nostra sede principale al nostro data center.

Quando il trasferimento fallisce, il messaggio di errore che riceviamo è:

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

E ' solo i file VHD più grandi di 4 GB che non riescono. Se inviamo qualsiasi altro tipo di file, funziona benissimo. Se comprimiamo il disco rigido virtuale, anche quello funziona. Inoltre, possiamo inviare un VHD nell'altra direzione (dal data center all'ufficio principale) senza problemi. Sono solo file VHD in quella direzione.

Note importanti:

  • Tutte le partizioni sono NTFS !!
  • Non esiste un firewall tra workstation e server
  • Abbiamo provato a disabilitare l'antivirus sulla workstation (nessun antivirus sul server)
  • Abbiamo provato a trasferire il file da una macchina non sul dominio
  • Abbiamo provato a trasferire il file da una macchina Ubuntu (non riesce ancora ma a circa 450 MB anziché 4 GB)
  • L'acquisizione di Wireshark mostra 40 ACK DUP quando il trasferimento non riesce
  • Xcopy e Robocopy (con flag di riavvio) falliscono entrambi (stesso punto)
  • Il trasferimento FTP non riesce a 4,14X, XXX, XXX byte e non può essere riavviato a quel punto
  • Abbiamo provato a cambiare l'estensione del file (stupido, ma un'ultima risorsa) in qualcosa di diverso da VHD prima di inviarlo, ma non è riuscito
  • La connessione è la seguente: Dell Workstation (Main Office) -> Dell PowerConnect 5448 Managed Switch (MO) -> HP Procurve 2910al-24G Layer 3 Router (MO) -> 100Mb TLS link -> HP Procurve 2910al-24G Layer 3 Router ( Data center) -> Dell PowerConnect 5448 Managed Switch (DC) -> Dell Server (DC)

Quindi, fondamentalmente, sono SOLO file vhd> 4 GB, dal nostro ufficio principale al nostro datacenter che falliscono. Tutto questo non si somma ... a questo punto credo che sia un problema con le nostre impostazioni hardware di rete, ma non capisco quale sia la differenza tra il trasferimento di un VHD di grandi dimensioni (che non riesce, a 4 GB) e un file video di grandi dimensioni (che funziona sempre).


Hai provato un altro protocollo quindi CIFS / SMB?
Bart De Vos,

No non l'ho fatto; Ci proverò
Isaac Butt

1
Consentitemi di riformulare, che tipo di dispositivi di rete gestisce quella connessione da 100 Mb?
SpacemanSpiff

2
Presumibilmente se la colpa è dell'ispezione di pacchetti profondi (che sembra probabile) l'uso di un meccanismo di trasferimento crittografato come SFTP o SCP aggirerebbe il problema. Oppure potresti usare IPSec, che è integrato in Windows. O forse i router hanno una sorta di supporto tunnel crittografato?
Harry Johnston,

2
@HarryJohnston Dopo aver impostato SFTP, i file VHD vengono trasferiti correttamente, quindi sembra che tu abbia ragione sul DPI sul TLS. Parlerò con il nostro fornitore e vedrò se c'è qualcosa che possono fare al riguardo :)
Isaac Butt,

Risposte:


3

Dopo aver risolto il problema per molte ore (e aver provato tutti i suggerimenti pubblicati qui), il problema si è rivelato essere il collegamento TLS tra la nostra sede principale e il centro dati. Ho chiamato il nostro provider TLS e dopo aver parlato con diversi tecnici NOC, uno di loro aveva già sentito parlare del problema esatto. Si è scoperto che alcune delle loro apparecchiature di livello 2 erano vecchie e avevano problemi con i dati VHD.

La soluzione stava aggiornando il firmware su questi dispositivi, che è stato eseguito dal provider TLS. Ora non abbiamo problemi a trasferire VHD di grandi dimensioni. Per coloro che sono interessati, il nostro fornitore TLS è Shaw Communications a Victoria, in Canada.


1

Prova Xcopy o Robocopy; almeno uno o entrambi hanno un interruttore "riprendi". Anche Rsync può essere di aiuto.

Per curiosità, una delle macchine è a 32 bit, ma l'altra è a 64 bit? In tal caso, puoi provare temporaneamente la tua copia con un computer a 64 bit.


Sia Robocopy che Xcopy falliscono allo stesso punto, anche con l'interruttore di ripresa (e bufferizzato / senza buffer). Sia il server che la workstation sono a 64 bit.
Isaac Butt,

Brutale. L'unica opzione che mi viene in mente di rimediare è quella di controllare l'opzione VHD da 2 GB in ESX. Le mie condoglianze.
gWaldo,

Nessun problema, apprezzo il tuo aiuto :) (stiamo usando Hyper-V non VMWare)
Isaac Butt

Buon punto; Ho usato un sacco di piattaforme di virtualizzazione, quindi le analizzo mentalmente come $ disk_file o $ config_file, ecc ...
gWaldo

0

Cercando su Google grandi errori di copia della rete di file, troverai alcuni thread che parlano di problemi simili ma non solo di VHD. Questo KB è di solito collegato per vedere se modificare le impostazioni della scheda di rete aiuta. Offload TCP, impostazioni camino, ecc.

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


Grazie per i suggerimenti Posso trasferire altri file di grandi dimensioni senza alcun problema, ma cercherò di modificare alcune di queste impostazioni. La disabilitazione dello scarico del camino non ha alcun effetto.
Isaac Butt,

0

Mmmmhhhh ... Vedo le varie risposte sopra e mi rendo conto che non riesco ancora a capire se hai davvero provato a copiare con un programma di copia a 64 bit. (xcopy, robocopy e la maggior parte dei client FTP sono a 32 bit, anche su Windows a 64 bit.)

Puoi provarlo con la versione a 64 bit di TotalCommander V8.0? (È ancora un candidato al rilascio, ma molto stabile.) Questo è veramente solo a 64 bit.

Un'altra cosa da provare se sul server è abilitato IPV6 (di solito su W2K8): disabilitare IPV4 completamente sulla workstation in modo che la copia dovrà utilizzare IPV6. Sarà interessante vedere se questo fa la differenza.

Se nessuna delle due opzioni precedenti ti dà sollievo ... Puoi sempre usare HJSplit (o la funzione split di TotalCommander) per dividere il file in blocchi da 1 GB, ma ovviamente devi avere un modo per ricongiungerli sul server. Ciò dipenderà se si ha accesso per eseguire un programma sul server stesso. (Solo "copia / b chunk1 + chunk2 + chunk3 total.vhd" farà se non ti è permesso installare software aggiuntivo sul lato server.)


Ho provato TotalCommander 8, il trasferimento fallisce anche prima di 4 GB e riporta "Rimuovere la protezione da scrittura!" ma non credo che ciò indichi effettivamente un errore di protezione dalla scrittura.
Isaac Butt,

Abbiamo altri modi per spostare i dati. Potrei semplicemente RAR il file e trasferirlo (non è nemmeno necessario dividerlo in piccoli blocchi), ma è un passaggio in più che non dovremmo davvero fare. Grazie per il suggerimento, apprezzo il tuo aiuto.
Isaac Butt,

0

Solo un pensiero: il disco rigido virtuale è utilizzato dall'hypervisor o montato?

Potrebbe non riuscire perché parte del disco rigido virtuale è bloccato e non può essere letto dal filesystem. Ecco perché funziona zippare il file e perché funzionano anche i file video della stessa dimensione, ma non i file VHD.

Alla ricerca di un blocco di file in Windows:

  1. Scarica Process Explorer (collegamento diretto a live.sysinternals.com)
  2. Seleziona il menu Trova, scegli Trova handle o DLL ...
  3. Digita il nome del file, seleziona cerca.

Sembra che ci sia un posto di scambio di esperti con problemi simili. Ma non ci sono risoluzioni nelle risposte.


Buon punto. A volte è anche necessario riavviare la workstation per farlo sbloccare davvero il file. Può sembrare gratuito, ma non puoi mai dirlo.
Tonny,

@Tonny Lo sai sicuramente, hai solo bisogno degli strumenti giusti. Aggiornato la mia risposta con un metodo suggerito.
Joseph Kern,

Sì, ho visto l'articolo di scambio di esperti e sembra simile. Process Explorer non mostra nulla per il file. Inoltre, posso farne una copia e provare a trasferire la copia fallisce ancora, quindi non sembra esserci un lucchetto. Total Commander 8 RC (64 bit) non riesce nel trasferimento da 2 GB con un messaggio "Rimuovere la protezione da scrittura!" anche se probabilmente è solo una risposta di errore di magazzino.
Isaac Butt,

1
Quella risposta TC è effettivamente utile. Fornirà quel messaggio solo a metà della copia se c'è davvero qualcosa che blocca la tentata scrittura. Questo deve essere sul lato server o relativo a LAN / WAN. Sei sicuro che la LAN sia davvero trasparente? Vorrei cercare un router che esegue Statefull Packet Inspection o un dispositivo Network Accelerator (ad esempio l'appliance Cisco WAAS) che si confonde in qualche modo su questo particolare tipo di dati.
Tonny,

Hmm, beh, la linea dovrebbe essere trasparente; Potrei chiamare il nostro fornitore e dire loro cosa sta succedendo, anche se scommetto che dirigeranno la colpa altrove.
Isaac Butt,

0

Sembra che potrebbe anche essere un problema di autorizzazioni, quando si tenta di copiare il file nella posizione di rete, viene arrestato o fallito, forse si potrebbe provare a creare una cartella di rete per renderlo completamente aperto, il che significa condiviso con il gruppo "Tutti" e anche impostare in questo modo nella scheda di sicurezza. Se questo risolve il problema, allora sembra un problema di autorizzazioni, infatti da quando hai menzionato la copia di Linux non è riuscita prima, sembra che le autorizzazioni potrebbero essere il problema. Assicurarsi che i file all'interno del disco rigido virtuale non siano in uso e che si disponga delle autorizzazioni appropriate per accedervi.

Assicurati anche che la cartella da cui stai copiando abbia le autorizzazioni aperte. Ricorda che questo è solo per vedere se i permessi si frappongono, puoi sempre rafforzarli in seguito una volta che un punto di partenza della copia funziona correttamente.

Un'altra cosa e potrebbe essere un colpo lungo, ma hai provato ad aggiornare i driver della scheda di rete? Forse potrebbe esserci una correzione nel driver più recente per la tua macchina.

Spero che questo ti aiuti, Saluti


Grazie per il suggerimento, ma ciò non spiega perché il trasferimento dei file abbia esito positivo se i dati sono crittografati. Penso ancora che il problema risieda nella linea TLS; Sono in trattative con il loro supporto al momento
Isaac Butt,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.