Передача файлов VHD по сети терпит неудачу последовательно в 4 ГБ

16

Эта проблема очень расстраивала нас: при переносе большого файла VHD (виртуального жесткого диска) с компьютера под управлением Windows 7 по сети на физический компьютер под управлением Windows Server 2008 в нашем центре обработки данных передача файлов Windows последовательно завершалась с ошибкой 4 ГБ. У нас есть прямое соединение 100 мбит от нашего главного офиса до нашего центра обработки данных.

Когда передача не удалась, мы получаем сообщение об ошибке:

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

Это только VHD-файлы размером более 4 ГБ. Если мы отправим любой другой тип файла, он работает нормально. Если мы застегнем VHD, это тоже работает. Более того, мы можем отправить VHD в другом направлении (от центра обработки данных до главного офиса) без проблем. Это просто VHD файлы в этом направлении.

Важные заметки:

  • Все разделы NTFS!
  • Между рабочей станцией и сервером нет брандмауэра
  • Мы попытались отключить антивирус на рабочей станции (антивирус на сервере отсутствует)
  • Мы попытались перенести файл с компьютера, не входящего в домен.
  • Мы попытались перенести файл с компьютера с Ubuntu (по-прежнему происходит сбой, но около 450 МБ вместо 4 ГБ)
  • Захват Wireshark показывает 40 ACK DUP при сбое передачи
  • Xcopy и Robocopy (с флагами перезапуска) не работают (одна и та же точка)
  • Сбой FTP-передачи на 4,14X, XXX, XXX байт и не может быть перезапущен в этот момент
  • Мы попытались изменить расширение файла (глупо, но в крайнем случае) на что-то отличное от vhd перед отправкой, но все равно не получилось
  • Подключение выполняется следующим образом: рабочая станция Dell (основной офис) -> управляемый коммутатор Dell PowerConnect 5448 (MO) -> маршрутизатор HP Procurve 2910al-24G уровня 3 (MO) -> TLS-соединение 100 МБ -> маршрутизатор HP Procurve 2910al-24G уровня 3 ( Центр обработки данных) -> Управляемый коммутатор Dell PowerConnect 5448 (DC) -> Сервер Dell (DC)

Таким образом, в основном, это просто файлы VHD> 4 ГБ, от нашего главного офиса до нашего центра обработки данных, который выходит из строя. Все это просто не складывается ... на данный момент я считаю, что это проблема с настройками нашего сетевого оборудования, но я не понимаю, в чем разница между передачей большого виртуального жесткого диска (который не работает, на 4 ГБ) и большой видео файл (который работает всегда).

file-sharing vhd windows Исаак Батт
источник
Вы пробовали другой протокол, чем CIFS / SMB?
Барт Де Вос
Нет у меня нет; Я дам это попробовать
Исаак Батт
1
Позвольте мне перефразировать, какой тип сетевого устройства обрабатывает это соединение 100 Мб?
SpacemanSpiff
2
Предположительно, если во всем виновата глубокая проверка пакетов (что кажется вероятным), использование зашифрованного механизма передачи, такого как SFTP или SCP, может решить эту проблему. Или вы можете использовать IPSec, который встроен в Windows. Или, возможно, маршрутизаторы имеют какую-то поддержку зашифрованного туннеля?
Гарри Джонстон
2
@HarryJohnston После настройки SFTP файлы VHD успешно передаются, поэтому похоже, что вы были правы насчет DPI в TLS. Я поговорю с нашим провайдером и посмотрю, могут ли они что-то с этим сделать :)
Исаак Батт

Ответы:

3

После устранения неполадок в течение многих часов (и проверки всех предложений, опубликованных здесь) проблема оказалась связью TLS между нашим главным офисом и центром обработки данных. Я позвонил нашему провайдеру TLS и после разговора с несколькими техническими специалистами NOC один из них уже слышал о точной проблеме. Оказалось, что некоторые из их оборудования уровня 2 были старыми и имели проблемы с данными VHD.

Решением было обновление прошивки на этих устройствах, которое было выполнено поставщиком TLS. Теперь у нас нет проблем с переносом больших виртуальных жестких дисков. Для тех, кто заинтересован, наш поставщик TLS - Shaw Communications в Виктории, Канада.

Исаак Батт
источник
1

Попробуйте Xcopy или Robocopy; по крайней мере один или оба имеют переключатель «возобновить». Rsync тоже может помочь.

Из любопытства, является ли одна из машин 32-разрядной, а другая - 64-разрядной? Если да, можете ли вы временно попробовать свою копию на 64-битном компьютере?

gWaldo
источник
Как Robocopy, так и Xcopy также дают сбой в одной точке, даже с переключателем возобновления (и буферизованным / небуферизованным). И сервер, и рабочая станция являются 64-битными.
Исаак Батт
Brutal. Единственный вариант, о котором я могу подумать, - это проверить параметр 2 ГБ VHD в ESX. Мои соболезнования.
gWaldo
Нет проблем, я ценю вашу помощь :) (мы используем Hyper-V, а не VMWare)
Исаак Батт
Хорошая точка зрения; Я использовал кучу платформ виртуализации, поэтому мысленно анализирую их как $ disk_file или $ config_file и т. Д.
gWaldo
0

При поиске в Google сбоев при копировании больших файловых сетей вы обнаружите, что некоторые темы говорят о похожих проблемах, а не только о vhd. Этот КБ обычно связан, чтобы увидеть, помогают ли настройки настройки NIC. TCP разгрузка, настройки дымохода и т. Д.

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

Уилли
источник
Спасибо за предложения. Я могу перенести другие большие файлы без проблем, но я рассмотрю некоторые настройки. Отключение разгрузки дымохода не имеет никакого эффекта.
Исаак Батт
0

М-м-м-м-м-м ... Я вижу различные ответы выше и понимаю, что до сих пор не могу сказать, действительно ли вы пытались копировать с помощью 64-битной программы копирования. (xcopy, robocopy и большинство FTP-клиентов 32-битные, даже на 64-битной Windows.)

Можете ли вы попробовать его с 64-битной версией TotalCommander V8.0? (Это все еще версия-кандидат, но очень стабильная.) Это действительно только 64-битная версия.

Еще одна вещь, которую стоит попробовать, если на сервере включен IPV6 (обычно это делается в W2K8): полностью отключить IPV4 на рабочей станции, чтобы при копировании пришлось использовать IPV6. Будет интересно посмотреть, если это изменит.

Если ни один из вышеперечисленных случаев не приводит к облегчению .... Вы всегда можете использовать HJSplit (или функцию разделения TotalCommander), чтобы разбить файл на куски по 1 ГБ, но, конечно, у вас должно быть средство для их повторного объединения на сервере. Это будет зависеть от того, есть ли у вас доступ для запуска программы на самом сервере. (Просто «copy / b chunk1 + chunk2 + chunk3 total.vhd» подойдет, если вам не разрешено устанавливать дополнительное программное обеспечение на стороне сервера.)

Tonny
источник
Попробовал TotalCommander 8, передача завершается неудачно даже до 4ГБ и выдает сообщение "Пожалуйста, снимите защиту от записи!" но я не верю, что это на самом деле указывает на ошибку защиты от записи.
Исаак Батт
У нас есть другие способы перемещения данных. Я мог бы просто RAR файл и передать его (даже не нужно разбивать его на небольшие куски), но это дополнительный шаг, который нам действительно не нужно было делать. Спасибо за предложение, я ценю вашу помощь.
Исаак Батт
0

Просто мысль: VHD используется гипервизором или смонтирован?

Это может быть сбой, потому что часть VHD заблокирована и не может быть прочитана из файловой системы. Вот почему архивирование файлов работает и почему видеофайлы того же размера также работают, но не VHD-файлы.

Ищем блокировку файла в windows:

  1. Загрузите проводник процессов (прямая ссылка на live.sysinternals.com)
  2. Выберите меню «Найти», выберите «Найти дескриптор» или «DLL» ...
  3. Введите имя файла, выберите поиск.

Похоже, что существует обменный пост экспертов с аналогичными вопросами. Но в ответах нет никаких решений.

Джозеф Керн
источник
Хорошая точка зрения. Иногда вам даже нужно перезагрузить рабочую станцию, чтобы она действительно разблокировала файл. Это может показаться бесплатным, но вы никогда не можете сказать, на самом деле.
Тонни
@ Тонни Вы уверены, что можете сказать, вам просто нужны правильные инструменты. Обновил мой ответ предложенным методом.
Джозеф Керн
Да, я видел статью об обмене экспертами, и это звучит похоже. Проводник процесса ничего не показывает для файла. Более того, я могу сделать его копию, и попытка передать копию все равно не удалась, поэтому, похоже, нет блокировки. Total Commander 8 RC (64-битный) завершается с ошибкой уже 2 ГБ при передаче с сообщением «Пожалуйста, снимите защиту от записи!» хотя это, скорее всего, просто ответ об ошибке на складе.
Исаак Батт
1
Этот ответ ТС на самом деле полезен. Это сообщение будет передано только на полпути через копию, если действительно что-то блокирует попытку записи. Это должно быть на стороне сервера или связано с LAN / WAN. Вы уверены, что локальная сеть действительно прозрачна? Я бы искал маршрутизатор, выполняющий Statefull Packet Inspection, или устройство сетевого ускорителя (например, устройство Cisco WAAS), которое каким-то образом запуталось в этом конкретном типе данных.
Тонни
Хм, ну линия должна быть прозрачной; Я мог бы позвонить нашему провайдеру и сказать им, что происходит, хотя держу пари, что они возьмут на себя вину в другом месте.
Исаак Батт
0

Похоже, что это может быть даже проблема с разрешениями, когда вы пытаетесь скопировать файл в сетевое расположение, он останавливается или не работает, возможно, вы можете попытаться создать сетевую папку, сделав ее полностью открытой, то есть доступной группе «Все» а также установить этот путь на вкладке безопасности. Если это решает проблему, то это выглядит как проблема с разрешениями, фактически, поскольку вы упомянули, что копия Linux не удалась раньше, похоже, что проблема может быть в разрешениях. Убедитесь, что файлы внутри VHD не используются, и у вас есть соответствующие разрешения для доступа к ним.

Также убедитесь, что папка, из которой вы копируете, имеет открытые разрешения. Помните, что это просто для того, чтобы увидеть, мешают ли разрешения, вы всегда можете сжать их позже, как только начнете работать правильно.

Другое дело, и это может быть далеко, но вы пытались обновить драйверы NIC? Возможно, есть исправление в самом последнем драйвере для вашей машины.

Я надеюсь, что это поможет, ура

Фрэнк Р
источник
Спасибо за предложение, но это не объясняет, почему передача файла прошла успешно, если данные зашифрованы. Я все еще думаю, что проблема заключается в линии TLS; Я сейчас веду переговоры с их поддержкой
Исаак Батт