Вопрос: Почему robocopy заставил мой Windows 2012 сервер повесить прошлой ночью?


Я нахожусь в процессе вывода старого сервера 2003 года, который работает как файловый сервер, и просто пытаюсь выполнить сухое переключение хранилища файлов на новый блок Windows Storage Server 2012. Я использую robocopy для копирования файлов и в настоящее время просто выполняю некоторые пробные прогоны, чтобы увидеть, сколько времени потребуется, прежде чем мы сделаем окончательное изменение.

В первый раз, когда я выполнил robocopy, я поставил следующие переключатели: Options: , / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 100000 / W: 30 Он прошел нормально (хотя я бы не рекомендовал переключатели / r и / w, так как это займет навсегда!) Во второй раз я запустил его со следующими ключами (каталог назначения уже содержал копию исходного адресата с первого раза, когда я его запускал, / MIR обеспечит его обновление): Параметры: , / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 0 / W: 0

Это заставило сервер зависнуть около 5 минут после начала работы. Он полностью висел, и мне пришлось вручную включить его, чтобы перезапустить его. Журналы не дают мне огромного указания на то, что пошло не так - мысли состояли в том, что / mt: 128 вызвали проблемы, но я поставил этот переключатель в первый раз, и все было в порядке.

Во второй раз я меняю пару переключателей на / r: 0 и / w: 0, хотя я бы не подумал, что они заставят его висеть.

Наконец, тот факт, что я выбрал / MIR проблематичным, поскольку пункт назначения уже был скопирован из источника один раз раньше - я бы не подумал об этом, хотя, как я думал, единственным потенциальным недостатком зеркалирования было то, что он удалял бы файлы в пункт назначения, который больше не находится в источнике. Если бы кто-нибудь мог пролить свет на то, что пошло не так, это обеспечит, что в следующий раз я попробую это сделать.

EDIT: перечисленные выше переключатели взяты из файла журнала robocopy, и в некотором смысле они являются интерпретацией указанных мной переключателей, которые были: / MIR / COPY: DATSOU / MT: 128 / R / W

2nd Edit: на сервере есть двойной сетевой адаптер, объединенный с использованием встроенного сетевого интерфейса Windows Server. Я считаю, что это важная информация, которую я не разделял, когда я изначально разместил вопрос. Хотелось бы исследовать это. Соответствующим сетевым адаптером является сетевое соединение Intel (R) 82574L Gigabit. Команда NIC - «Мультиплексирующий драйвер сетевого адаптера Microsoft».


5
2018-05-09 16:38


Источник


Выполнение robocopy не должно зависать сервера независимо от того, какие параметры указаны. Но что-то происходит, я бы назвал OEM-сервер хранилища и преследовал их. - tony roth
Я использую либо / S, / E или / MIR, но не более одного. / MIR должен работать нормально, и вам также не нужно / PURGE. Я также оставил потоки (/ MT) по умолчанию 8. 128 кажется чрезмерным. - Peter Hahndorf
Да, нет никакого способа, чтобы он полностью повесил сервер. Я рад, что сеть насыщена, но она не должна перегружать сервер. параметр, который я указал, был просто / MIR (эквивалентно / e и / purge) / / должен быть из / copy: datsou - kafka
это верная версия сервера хранения oem? Если это так, вам нужно связаться с oem, потому что я уверен, что это проблема с драйвером. - tony roth
это вполне может быть проблемой с драйверами, поскольку у нас сейчас есть сервер Windows 2012, который довольно недавний, и им не 100% все оборудование имеет полностью обновленные драйверы. коробка была поставлена ​​без и os, которую я положил, а затем поставил драйверы с компакт-диска. я вижу, могу ли я их обновить - kafka


Ответы:


Это похоже на проблему с драйвером сетевой карты. Чтобы узнать, является ли это ошибкой с вашей двойной настройкой, отрегулируйте параметр IPG примерно до 20 миллисекунд и удалите параметр / MT: 128 (поскольку / IPG и / MT несовместимы). Используя вашу строку «switch I specified» в вашем исходном сообщении, это будет выглядеть так.

/MIR /COPYALL /R /W /IPG:20 /Z

/ IPG: 20 (межпакетный зазор) значительно замедлит передачу, но обеспечивает стабильность.

Режим / Z (перезапускаемый режим) важен для копий по сети, в случае сбоев в работе сети (вызванных плохими картами, драйверами или действительными сетевыми проблемами), поскольку это позволит копировать, где он остановился.

Если это завершено успешно, у вас возникла проблема с сетевым драйвером. Проблема заключалась бы в том, что любой драйвер, который вы используете, не может обрабатывать пропускную способность / IPG: 0.

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

Предложение поступило из cb42 на technet.

http://social.technet.microsoft.com/Forums/en-US/itprovistaapps/thread/9555a996-1301-4f68-b9d3-82a87fc6ba46/

... и ss64 скалы (просто сказать!) http://ss64.com/nt/robocopy.html


1
2018-05-28 19:16



Спасибо за этого Лукреция. Интересно, что robocopy снова зависает на этом сервере (к счастью, он не разбил весь сервер), и это было копирование с внутреннего жесткого диска на внешний, зашифрованный жесткий диск! (Мне нужно выяснить способ шифрования наших внешних жестких дисков и заставить их работать с wbadmin, но мне не нравятся мои зашифрованные разделы truecrypt). Поэтому, хотя исходная ошибка почти наверняка является проблемой драйвера на nic_team (это последний драйвер тоже), у меня также возникают проблемы с robocopy, не пересекая сеть. Позор, когда он работает, отлично. - kafka
Вы можете попробовать копировать в необработанном режиме с помощью robocopy, добавив / EFSRAW в конце. /EFSRAW : Copy any encrypted files using EFS RAW mode. - Lucretius


Мне кажется, что Robocopy - это A) багги, а B) каким-то образом перехватывает ядро, что может сделать всю систему невероятно неустойчивой, когда она удаляется. Мы видели, как это происходит довольно часто (особенно с опцией MT) при синхронизации по разумно высокоскоростным каналам глобальной сети (20 Мбит / с - 100 Мбит / с). Поэтому я уверен, что это не драйвер NIC, который имеет проблемы с объемом трафика. Мы делаем что-то в производстве, которые злоупотребляют ими гораздо хуже, чем это, и мы это видим даже при подключении LAN 10Gbps на Cisco UCS / VMWare 5.5, при этом все исправленные текущие и Robocopy v6.3.9600.17415 от 28.10.2014.

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


2
2017-12-14 19:13



BTW, robocopy - это UNSUPPORTED M $ release. Это должно сказать вам немного. - mdpc


Почему вы используете /S с /E? Кажется, это наоборот. А также /E + /Purge равно /Mirror, И я думаю / MT: 128 слишком высока, вы должны уменьшить его. Пытаться:

/S /MIRROR /COPYALL /MT:64 /R:10 /W:60 

0
2018-05-09 16:55



Флаги берутся из файла журнала, указанные мной параметры: / MIR / copy: DATSOU / mt: 128 / R / W - kafka
Зашел ли Robocopy на консоль? Если нет, возможно, что он не был висел, а потому, что вы не видели какой-либо продукции, которую вы предположили, что она была повешена. - joeqwerty
он записывался в текстовый файл. система была полностью невосприимчива, и когда я перезагрузил ее сегодня, журналы сервера были остановлены прошлой ночью в 5:30 вечера, после этого ничего не произошло. - kafka