Sieciowy transfer plików VHD nie kończy się konsekwentnie przy 4 GB


16

Ten problem jest dla nas wyjątkowo frustrujący: podczas przesyłania dużego pliku VHD (wirtualnego dysku twardego) z komputera z systemem Windows 7 przez sieć do fizycznego komputera z systemem Windows Server 2008 w naszym centrum danych, transfer pliku systemu Windows nie kończy się przy 4 GB. Mamy bezpośrednie połączenie 100 Mb od naszego głównego biura do naszego centrum danych.

Gdy transfer się nie powiedzie, otrzymujemy komunikat o błędzie:

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

Jest tylko pliki VHD większe niż 4 GB, które nie powiedzie. Jeśli wyślemy dowolny inny typ pliku, działa dobrze. Jeśli skompresujemy VHD, to również działa. Co więcej, możemy przesłać VHD w innym kierunku (z centrum danych do głównego biura) bez problemu. To tylko pliki VHD w tym kierunku.

Ważne notatki:

  • Wszystkie partycje są NTFS !!
  • Między stacją roboczą a serwerem nie ma zapory ogniowej
  • Próbowaliśmy wyłączyć program antywirusowy na stacji roboczej (brak programu antywirusowego na serwerze)
  • Próbowaliśmy przenieść plik z komputera spoza domeny
  • Próbowaliśmy przenieść plik z komputera z systemem Ubuntu (nadal nie działa, ale ma około 450 MB zamiast 4 GB)
  • Przechwytywanie Wireshark pokazuje 40 DUP ACK, gdy przesyłanie się nie powiedzie
  • Xcopy i Robocopy (z flagami restartu) zawodzą (ten sam punkt)
  • Transfer FTP kończy się niepowodzeniem przy 4,14X, XXX, XXX bajtach i nie można go ponownie uruchomić w tym momencie
  • Próbowaliśmy zmienić rozszerzenie pliku (głupie, ale w ostateczności) na coś innego niż vhd przed wysłaniem go, ale nadal nie udało się
  • Połączenie jest następujące: stacja robocza Dell (główne biuro) -> zarządzalny przełącznik Dell PowerConnect 5448 (MO) -> router HP Procurve 2910al-24G Layer 3 (MO) -> łącze TLS 100 Mb -> HP Procurve 2910al-24G Layer 3 Router ( Centrum danych) -> Dell PowerConnect 5448 Managed Switch (DC) -> Dell Server (DC)

Zasadniczo zawodzą tylko pliki vhd> 4 GB z naszego głównego biura do naszego centrum danych. To po prostu się nie sumuje ... w tym momencie uważam, że jest to problem z naszymi ustawieniami sprzętu sieciowego, ale nie rozumiem, jaka jest różnica między przesyłaniem dużego dysku VHD (który kończy się niepowodzeniem, przy 4 GB), a duży plik wideo (który działa zawsze).


Czy próbowałeś innego protokołu niż CIFS / SMB?
Bart De Vos

Nie, nie mam; Spróbuję
Izaak Butt

1
Pozwólcie, że powtórzę, jaki rodzaj sprzętu sieciowego obsługuje to połączenie 100 Mb?
SpacemanSpiff

2
Przypuszczalnie jeśli obwinianie głębokiej kontroli pakietów (co wydaje się prawdopodobne) za pomocą zaszyfrowanego mechanizmu przesyłania, takiego jak SFTP lub SCP, rozwiązałoby problem. Lub możesz użyć IPSec, który jest wbudowany w Windows. A może routery obsługują szyfrowane tunele?
Harry Johnston,

2
@HarryJohnston Po skonfigurowaniu SFTP, przesyłanie plików VHD powiodło się, więc wygląda na to, że miałeś rację co do DPI na TLS. Porozmawiam z naszym dostawcą i zobaczę, czy można coś z tym zrobić :)
Isaac Butt

Odpowiedzi:


3

Po wielu godzinach rozwiązywania problemów (i wypróbowaniu wszystkich zamieszczonych tutaj sugestii) problemem okazało się łącze TLS między naszym głównym biurem a centrum danych. Zadzwoniłem do naszego dostawcy TLS i po rozmowie z kilkoma technikami NOC, jeden z nich wcześniej słyszał o dokładnym problemie. Okazało się, że niektóre urządzenia warstwy 2 były stare i miały problemy z danymi VHD.

Rozwiązaniem było uaktualnienie oprogramowania układowego na tych urządzeniach, które zostało wykonane przez dostawcę TLS. Nie mamy teraz problemów z przesyłaniem dużych dysków VHD. Dla zainteresowanych naszym dostawcą TLS jest Shaw Communications w Victoria, Kanada.


1

Wypróbuj Xcopy lub Robocopy; co najmniej jeden lub oba mają przełącznik „wznawiania”. Rsync też może być pomocny.

Z ciekawości, czy jedna z maszyn jest 32-bitowa, a druga 64-bitowa? Jeśli tak, czy możesz tymczasowo wypróbować kopię na komputerze 64-bitowym.


Zarówno Robocopy, jak i Xcopy również zawodzą w tym samym punkcie, nawet przy przełączniku wznawiania (i buforowanym / niebuforowanym). Zarówno serwer, jak i stacja robocza są 64-bitowe.
Isaac Butt

Brutalny. Jedyną opcją, którą mogę wymyślić, jest usunięcie opcji 2 GB VHD w ESX. Moje kondolencje.
gWaldo

Nie ma problemu, doceniam twoją pomoc :) (używamy Hyper-V, a nie VMWare)
Isaac Butt

Słuszna uwaga; Użyłem wielu platform wirtualizacyjnych, więc parsuję je mentalnie jako $ plik_dyskowy lub $ plik_konfiguracyjny itp.
gWaldo

0

Przeszukując google w poszukiwaniu błędów kopiowania dużych plików w sieci, znajdziesz wątki mówiące o podobnych problemach, ale nie tylko vhd. Ten KB jest zwykle połączony, aby sprawdzić, czy poprawienie ustawień karty sieciowej pomaga. Odciążanie TCP, ustawienia komina itp.

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


Dziękuję za sugestie. Mogę przesyłać inne duże pliki bez problemu, ale przyjrzę się poprawieniu niektórych z tych ustawień. Wyłączenie odciążenia komina nie ma wpływu.
Izaak Butt

0

Mmmmhhhh ... Widzę różne odpowiedzi powyżej i zdaję sobie sprawę, że nadal nie mogę powiedzieć, czy naprawdę próbowałeś skopiować za pomocą 64-bitowego programu do kopiowania. (xcopy, robocopy i większość klientów FTP jest 32-bitowa, nawet w 64-bitowym systemie Windows).

Czy możesz spróbować z 64-bitową wersją TotalCommander 8.0? (Wciąż jest to wersja Release Candidate, ale bardzo stabilna). To naprawdę tylko wersja 64-bitowa.

Kolejną rzeczą do wypróbowania, jeśli serwer ma włączoną obsługę IPV6 (zwykle robi to na W2K8): Całkowicie wyłącz IPV4 na stacji roboczej, aby kopia musiała używać IPV6. Ciekawie będzie zobaczyć, czy to robi różnicę.

Jeśli żadne z powyższych nie przyniesie ulgi ... Zawsze możesz użyć HJSplit (lub funkcji podziału TotalCommander), aby podzielić plik na 1 GB porcji, ale oczywiście musisz mieć możliwość ponownego dołączenia ich na serwerze. Będzie to zależeć od tego, czy masz dostęp do uruchomienia programu na samym serwerze. (Po prostu „kopiuj / b fragment1 + fragment2 + fragment3 total.vhd” zrobi się, jeśli nie będziesz mógł zainstalować dodatkowego oprogramowania po stronie serwera.)


Próbowałem TotalCommander 8, transfer nie powiedzie się nawet przed 4 GB i wyświetla komunikat „Usuń ochronę przed zapisem!” ale nie sądzę, że faktycznie oznacza to błąd ochrony przed zapisem.
Isaac Butt,

Mamy inne sposoby przenoszenia danych. Mógłbym po prostu ZRARGOWAĆ plik i przesłać go dalej (nawet nie muszę dzielić go na małe części), ale jest to dodatkowy krok, którego naprawdę nie powinniśmy robić. Dziękuję za sugestię, doceniam twoją pomoc.
Isaac Butt,

0

Tylko myśl: czy dysk VHD jest używany przez hiperwizora lub zamontowany?

Może się to nie udać, ponieważ część dysku VHD jest zablokowana i nie można jej odczytać z systemu plików. Dlatego działa skompresowanie pliku i dlaczego pliki wideo o tym samym rozmiarze również działają, ale nie pliki VHD.

Szukasz blokady pliku w systemie Windows:

  1. Pobierz eksplorator procesów (bezpośredni link do live.sysinternals.com)
  2. Wybierz menu Znajdź, wybierz Znajdź uchwyt lub DLL ...
  3. Wpisz nazwę pliku, wybierz szukaj.

Wydaje się, że istnieje punkt wymiany ekspertów o podobnych problemach. Ale odpowiedzi nie zawierają żadnych postanowień.


Słuszna uwaga. Czasami trzeba nawet zrestartować stację roboczą, aby naprawdę odblokować plik. Może się wydawać, że jest darmowy, ale tak naprawdę nigdy nie wiadomo.
Tonny

@ Tonny Na pewno możesz powiedzieć, że potrzebujesz odpowiednich narzędzi. Zaktualizowałem moją odpowiedź sugerowaną metodą.
Joseph Kern

Tak, widziałem artykuł z wymiany ekspertów i brzmi podobnie. Eksplorator procesów nic nie pokazuje dla pliku. Co więcej, mogę zrobić kopię, a próba przeniesienia kopii nadal kończy się niepowodzeniem, więc nie wydaje się, aby istniała blokada. Total Commander 8 RC (wersja 64-bitowa) nie działa już po przesłaniu 2 GB transferu z komunikatem „Usuń ochronę przed zapisem!” chociaż jest to prawdopodobnie tylko zapasowa odpowiedź na błąd.
Isaac Butt

1
Ta odpowiedź TC jest naprawdę przydatna. Prześle tę wiadomość tylko w połowie kopii, jeśli naprawdę coś blokuje próbę zapisu. Musi to być po stronie serwera lub LAN / WAN. Czy jesteś pewien, że sieć LAN jest naprawdę transparentna? Szukałbym routera przeprowadzającego Statefull Packet Inspection lub urządzenia Network Accelerator (np. Urządzenia Cisco WAAS), które są w pewien sposób zdezorientowane co do tego rodzaju danych.
Tonny

Hmm, cóż, linia powinna być przezroczysta; Mógłbym zadzwonić do naszego dostawcy i powiedzieć im, co się dzieje, ale założę się, że to oni zrzucą winę w inne miejsce.
Izaak Butt

0

Wydaje się, że może to być nawet problem z uprawnieniami, gdy próbujesz skopiować plik do lokalizacji sieciowej, zostanie zatrzymany lub nie powiedzie się, być może możesz spróbować utworzyć folder sieciowy, aby był w pełni otwarty, co oznacza, że ​​zostanie udostępniony grupie „Wszyscy” a także ustaw to w zakładce bezpieczeństwa. Jeśli to rozwiąże problem, wygląda to na problem z uprawnieniami, ponieważ skoro wspomniałeś, że kopia Linuksa nie powiodła się wcześniej, wydaje się, że problemem mogą być uprawnienia. Upewnij się, że pliki w VHD nie są używane i że masz odpowiednie uprawnienia dostępu do nich.

Upewnij się również, że folder, z którego kopiujesz, ma otwarte uprawnienia. Pamiętaj, że to po to, aby sprawdzić, czy uprawnienia przeszkadzają, zawsze możesz je zaostrzyć później, gdy zobaczysz, że kopia działa poprawnie.

Kolejna sprawa i może to być długa szansa, ale czy próbowałeś zaktualizować sterowniki karty sieciowej? Być może w najnowszym sterowniku komputera może być poprawka.

Mam nadzieję, że to pomaga, zdrowie


Dzięki za sugestię, ale to nie wyjaśnia, dlaczego przesyłanie pliku kończy się powodzeniem, jeśli dane są zaszyfrowane. Nadal uważam, że problem dotyczy linii TLS; Obecnie rozmawiam z ich wsparciem
Izaak Butt
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.