Восстановление сетевой ленты происходит быстрее, чем копирование с диска на диск
Как это может быть?
Запуск cp или rsync (с -W --inplace) занимает два часа для 93Gb; восстановление ленты по выделенной резервной сети занимает 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 я использовал размер блока 1024k (или 1048576, или 8192*128).
Мне действительно интересно, если это размер блока. Я прочитал в PerlMonks, что модуль Perl File::Copy работает быстрее, чем cp; это интригует: интересно.
Если NetBackup использует tar, то он не использует cp: это также может объяснить увеличение скорости.
Обновление: кажется, что чтение из снимка почти в два раза медленнее, чем чтение с реального устройства. Запуск cp идет медленно, так же как и запись tar в командную строку. Использование tar немного лучше (при использовании файла), но ограничено 8 ГБ файлами (размер рассматриваемого файла - 96 ГБ или около того). Использование Perl File::Copy с томом без снимка, кажется, один из самых быстрых способов.
Я собираюсь попробовать это и сообщу здесь, что я получаю.
5 ответов
Другой вопрос заключается в том, связаны ли вы с IO внутри сети FC, попросите ребят из SAN продемонстрировать (хорошие графики) фактическую доступную свободную полосу пропускания (о, и если коммутаторы FC являются Cisco, как они гарантируют, что избегают проблемы пропускной способности внутри коммутатора)
Чтобы убедиться, что ваш тест похож на тест, попробуйте выполнить копирование диска через tar (NetBackup использует tar для чтения с ленты):
$ tar cf - старые товары | (cd newdir; tar xf -)
Если все ваши диски находятся на одной и той же оптоволоконной карте, теоретически вы можете быть привязаны к этой карте, но я в этом сомневаюсь.
Снимок VxFS может быть дополнительным, особенно если исходная файловая система в данный момент занята записью. VxFS копирует при записи, поэтому, если исходный диск получает записи, диски моментальных снимков будут заняты получением данных исходного диска.
Если исходная файловая система простаивает, вы можете исключить фактор VxFS.
Если ваша лента также находится в сети SAN, возможно, что xfer передается и идет прямо с ленты на диск, в то время как копия должна проходить через хост, выполняющий копирование, и, следовательно, медленнее.
Вы ограничены чтением и записью на одном и том же диске в массиве?
Если диски подключены к разным шинам на материнской плате, данные могут быть скопированы на 3 или более внутренних шин, и задержка убивает ваш ввод-вывод для копирования с диска на диск. В этом случае вполне возможно, что сетевой ленточный накопитель имеет более высокую пропускную способность пути к целевому диску, чем исходный диск.