Вот любопытные для гуру:
Настроить:
Исходный компьютер: компьютер с Windows Server 2003 R2 с локальным жестким диском. VHD файл размером 40 ГБ. 1 сетевая карта 1 Гбит / с, кабель Cat6, коммутатор.
Целевая машина: машина с Windows Server 2008 R2 с подключением iSCSI к цели iSCSI на отдельной машине (1 ТБ, RAID5). 1 сетевая карта 1 Гбит / с, кабель Cat6, подключенный к тому же коммутатору, что и для Source Machine. Вторая сетевая карта 1 Гбит / с, кабель Cat6, подключенная через изолированный коммутатор к цели iSCSI.
Коммутаторы модели Netgear JGS524 (управление через Интернет).
Если я копирую с машины Win2003R2 на локальный диск машины Win2008R2, я получаю 40 ГБ за 45 минут 36 секунд.
Если я копирую с машины Win2008R2 на цель iSCSI (локальный диск на цель iSCSI), я получаю 40 ГБ за 37 минут 56 секунд.
Если я копирую с машины Win2003R2 на цель iSCSI через машину Win2008R2, я получаю 40 ГБ за 3 часа 50 минут 24 секунды.
Все копии были сделаны с помощью следующей команды, запущенной на Win2008R2:
XCOPY <источник> <цель> / J
XCOPY / J - копирует с использованием небуферизованного ввода-вывода. Рекомендуется для очень больших файлов.
Итак, что мне здесь не хватает? Почему обратная копия занимает в общей сложности 1 час 23 минуты 32 секунды, в то время как прямая копия занимает почти в 3 раза больше времени?
Коммутаторы не показывают ошибок, сеть колеблется около отметки использования 3% в течение всего времени копирования (в то время как копии «один за другим» находятся около отметки использования 25%).
Что я пропустил?
Может быть проблема в «небуферизованной» копии? Возможно, Windows выполняет некоторые уловки, которые могут ускорить копирование, если исходный / целевой является локальным диском, но он возвращается к более безопасному поведению, если использует два сетевых устройства.
Я играл с тестированием дисков в Unix, и операционные системы могут сыграть много трюков с дисковой подсистемой. Удачи.
Во-первых, в обоих случаях вы копируете с 2003R2 на 2008R2. Поскольку задействован 2003 год, он может использовать только SMB1 и мало что делает для одновременных запросов, и информация будет проходить по сети фрагментами размером около 64 КБ, и каждый фрагмент 64 КБ должен быть подтвержден сервером как записанный до Коробка 2003R2 отправляет следующий.
Теперь, если ящик 2008R2 должен отправить запрос iSCSI и получить подтверждение, прежде чем он вернет ответ в ящик 2003R2, это может замедлить процесс. Некоторые расчеты на обратной стороне конверта предполагают, что для фрагментов размером 64 КБ вам потребуется 22 мс между запросом от 2003R2 для записи фрагмента и ответом о том, что он был записан. Это кажется немного длинным, но не выходит за рамки возможного, учитывая все необходимые шаги.
Я не уверен, что это ваша проблема, но если вам интересно, вы можете использовать wirehark для просмотра сетевого трафика и проверки того, какие размеры блоков и задержки задействованы.
Еще одна менее интересная возможность состоит в том, что ваш сервер настроен как Full Duplex, а ваш коммутатор настроен на автоматическое согласование. Эта комбинация не работает и приводит к тому, что коммутатор считает, что соединение является полудуплексным, и иногда вызывает отбрасывание пакетов. Отброшенные пакеты будут намного хуже, если сервер одновременно отправляет и принимает большие объемы данных, как это было бы в случае вашего второго процесса копирования.
А как насчет SMB-протокола? Win2k8R2 использует SMB 2.0, в то время как старые версии Win имеют только SMB 1.0, что не так быстро И активен ли антивирусный сканер? С другой стороны, для прямого доступа к iSCSI-устройству используется другой протокол с минимальными накладными расходами и без антивирусного сканера для Shure.