Как это может быть?
Запуск cp или rsync (с -W --inplace) занимает два часа для 93 ГБ; Время восстановления ленты по выделенной сети резервного копирования составляет 41 минуту. Восстановление ленты - 50 Мб / с; Диск на диск был измерен и рассчитан как максимум 16 Мб / с - 2 Мб / с, если процессор занят.
Программное обеспечение для восстановления - Veritas NetBackup; диски находятся в массиве EMC Symmetrix по оптоволокну. Коробка - HP rx6600 (Itanium) с 16 Гбайт под управлением HP-UX 11i v2. Все диски находятся на одной оптоволоконной карте, перечисленные как:
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
На всех дисках также используется Veritas Volume Manager (вместо HP LVM).
Обновить: Мне приходит в голову, что это не просто прямая копия с диска на диск; на самом деле это снимок на диск скопировать. Может ли чтение снимка так сильно замедлить работу? Снимок представляет собой снимок HP VxFS (не vxsnap); возможно, взаимодействие между снимком и VxVM вызывает снижение скорости?
Обновить: Используя fstyp -v, получается, что размер блока (f_bsize) равен 8192; размер блока UNIX по умолчанию - 512 (или 8192/16). При тестировании с dd я использовал размер блока 1024 КБ (или 1048576, или 8192 * 128).
Мне действительно интересно, это размер блока. Я прочитал в PerlMonks, что модуль Perl File :: Copy быстрее, чем cp; это интригует: интересно.
Если NetBackup использует tar, то это не используя cp: это также может объяснить увеличение скорости.
Обновить: Похоже, что чтение из снимка почти вдвое медленнее, чем чтение с реального устройства. Запуск cp выполняется медленно, как и запись tar в командную строку. Использование tar немного лучше (при использовании файла), но ограничено файлами размером 8 ГБ (размер файла 96 ГБ или около того). Использование Perl File :: Copy с томом, не являющимся моментальным снимком, кажется одним из самых быстрых способов.
Я собираюсь попробовать это и сообщу здесь, что у меня получилось.
Другой вопрос, связаны ли вы вводом-выводом внутри сети FC, попросите ребят из SAN продемонстрировать (графики хорошие) актуальный доступная запасная пропускная способность (о, и если коммутаторы FC являются коммутаторами Cisco, как они гарантируют, что они избегают проблем с пропускной способностью внутри коммутатора)
Чтобы убедиться, что ваш тест похож на подобный, попробуйте скопировать диск с помощью tar (NetBackup использует tar для чтения с ленты):
$ tar cf - старые вещи | (cd newdir; tar xf -)
Если все ваши диски находятся на одной оптоволоконной карте, теоретически вы можете быть привязаны к этой одной карте ввода-вывода, но я сомневаюсь в этом.
Моментальный снимок VxFS может добавлять накладные расходы, особенно если исходная исходная файловая система в это время занята записями. VxFS копирует при записи, поэтому, если исходный диск получает записи, диски моментальных снимков будут заняты получением исходных данных диска.
Если исходная файловая система простаивает, вы можете исключить фактор VxFS.
Если ваша лента также находится в SAN, то возможно, что xfer передается и переходит прямо с ленты на диск, в то время как копия требуется для передачи через хост, выполняющий копирование, и, следовательно, медленнее.
Ограничены ли вы чтением с одного и того же диска в массиве и записью на него?
Если диски подключены к разным шинам на материнской плате, данные могут быть скопированы по 3 или более внутренним шинам, и задержка убивает ваш ввод-вывод для копирования с диска на диск. В этом случае вполне возможно, что сетевой ленточный накопитель имеет более высокую пропускную способность пути к целевому диску, чем исходный диск.