Восстановление NDMP NetApp Filer выполняется медленно
Это FAS2240 8.2P3 7-Mode
Программное обеспечение для резервного копирования: EMC Networker 8.1
NDMP настроен и работает внутри vFiler.
Начнем с резервного копирования. Команда резервного копирования в сети:
nsrndmp_save -T dump
Вы также можете указать -M (DSA), но я думаю, что здесь это неявно.
Информация о приложении (просто заново создайте клиент NDMP в Networker с помощью мастера новых клиентов, чтобы быть на безопасной стороне):
USE_TBB_IF_AVAILABLE=Y
DIRECT=Y
BUTYPE=dump
HIST=Y
UPDATE=Y
Полное резервное копирование выполняется с более или менее высокой скоростью
> sysstat -x 5
CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk OTHER FCP iSCSI FCP kB/s iSCSI kB/s
in out read write read write age hit time ty util in out in out
29% 0 0 0 1 485 94867 98060 11 0 0 0s 91% 0% - 90% 1 0 0 0 0 0 0
31% 0 0 0 1 502 97711 101518 490 0 0 0s 89% 13% T 90% 1 0 0 0 0 0 0
32% 0 0 0 57 530 103167 107344 251 0 0 0s 89% 5% Zf 88% 57 0 0 0 0 0 0
30% 0 0 0 41 552 107049 110286 222 0 0 0s 89% 7% : 87% 41 0 0 0 0 0 0
ОДНАКО: Мы получаем только около 10 МБ / сек при восстановлении с ленты. Резервное копирование на ленту было сделано, когда больше ничего не было запущено, поэтому проблема не в том, что данные на ленте чередуются.
Команда и вывод от Networker (восстановление на пустой том):
# nsrndmp_recover -S 1760972238 -m /vol/vfprod_xtest /vol/vfprod_x
42795:nsrndmp_recover: Performing recover from Non-NDMP type of device
85183:nsrndmp_recover: DSA is listening for an NDMP data connection on: 1.2.4.5, port = 8745
42690:nsrndmp_recover: Performing non-DAR Recovery..
86724:nsrdsa_recover: DSA listening at: host 'backupserv', IP address '1.2.4.5', port '8745'.
42937:nsrdsa_recover: Performing Immediate recover
42940:nsrdsa_recover: Reading Data...
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Dump came from a SnapLock volume.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Incremental restores to SnapLock volumes are not supported.
All files will be correctly restored, but subsequent restores
of incremental backups will not recreate the file system as
it appeared during the final incremental backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: ./.etc/gid_map: cannot create file: Read-only file system
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb 8 14:52:25 2014: Writing data to files.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb 8 14:56:43 2014 : We have read 3361690 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb 8 15:01:43 2014 : We have read 7053433 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb 8 15:06:43 2014 : We have read 10908694 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: failed to find the file
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb 8 15:11:22 2014: Restoring NT ACLs.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: RESTORE IS DONE
42942:nsrdsa_recover: Reading data...DONE.
42927:nsrndmp_recover: Successfully done
Вот статистика на файлере во время восстановления
>sysstat -x 5
CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk OTHER FCP iSCSI FCP kB/s iSCSI kB/s
in out read write read write age hit time ty util in out in out
91% 0 0 0 35 15364 143 5369 20946 0 0 0s 98% 56% H 55% 35 0 0 0 0 0 0
91% 0 0 0 20 14668 126 5135 20617 0 0 59s 98% 56% H 56% 20 0 0 0 0 0 0
91% 2 0 0 3 14407 119 5685 20954 0 0 1 98% 53% H 52% 1 0 0 0 0 0 0
91% 0 0 0 1 15564 154 5454 20711 0 0 1 98% 56% Hf 53% 1 0 0 0 0 0 0
91% 0 0 0 2 14447 121 6502 14358 0 0 1 98% 42% Hf 56% 2 0 0 0 0 0 0
...
92% 6 0 0 6 19503 245 4696 15072 0 0 1 98% 46% : 56% 0 0 0 0 0 0 0
93% 0 0 0 3 18902 253 7667 13669 0 0 0s 98% 22% Hf 63% 3 0 0 0 0 0 0
91% 6 0 0 7 18099 216 1957 32432 0 0 0s 97% 100% :f 45% 1 0 0 0 0 0 0
91% 6 0 0 6 16111 153 4427 23419 0 0 0s 98% 55% : 56% 0 0 0 0 0 0 0
92% 7 0 0 7 15629 156 8155 0 0 0 1 98% 0% - 68% 0 0 0 0 0 0 0
91% 0 0 0 3 14226 125 4427 32453 0 0 1 99% 79% Hf 53% 3 0 0 0 0 0 0
94% 6 0 0 6 32264 594 744 38453 0 0 2 97% 100% :f 45% 0 0 0 0 0 0 0
92% 6 0 0 6 14781 127 9846 59 0 0 2 98% 7% Hn 61% 0 0 0 0 0 0 0
90% 6 0 0 63 11546 57 2073 42592 0 0 2 99% 100% :f 50% 57 0 0 0 0 0 0
Загрузка ЦП кажется высокой по сравнению с резервным копированием, где загрузка диска была высокой, как и должно быть.
Выполнение одного и того же действия между двумя фильтрами дает в среднем около 40 МБ / с:
na1> ndmpcopy -sa root:xx -da root:xx /vol/vfprod_x/fs1 na2:/vol/test/xtest
Ndmpcopy: Starting copy [ 1 ] ...
Ndmpcopy: na1: Notify: Connection established
Ndmpcopy: na2: Notify: Connection established
Ndmpcopy: na1: Connect: Authentication successful
Ndmpcopy: na2: Connect: Authentication successful
Ndmpcopy: na1: Log: DUMP: creating "/vol/vfprod_x/../snapshot_for_backup.10825" snapshot.
Ndmpcopy: na1: Log: DUMP: Dumping from a SnapLock volume
Ndmpcopy: na1: Log: DUMP: Using subtree dump
Ndmpcopy: na1: Log: DUMP: Date of this level 0 dump: Sat Feb 8 15:23:04 2014.
Ndmpcopy: na1: Log: DUMP: Date of last level 0 dump: the epoch.
Ndmpcopy: na1: Log: DUMP: Dumping /vol/vfprod_x/fs1 to NDMP connection
Ndmpcopy: na1: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: na1: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: na2: Log: RESTORE: Dump came from a SnapLock volume.
Ndmpcopy: na1: Log: DUMP: estimated 16178315 KB.
Ndmpcopy: na1: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: na1: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:23:12 2014: Begin level 0 restore
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:23:12 2014: Reading directories from the backup
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:23:13 2014: Creating files and directories.
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:23:31 2014: Writing data to files.
Ndmpcopy: na1: Log: DUMP: Sat Feb 8 15:28:11 2014 : We have written 12577964 KB.
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:28:11 2014 : We have read 12575988 KB from the backup.
Ndmpcopy: na1: Log: ACL_START is '16565304320'
Ndmpcopy: na1: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: na1: Log: DUMP: 16177066 KB
Ndmpcopy: na1: Log: DUMP: DUMP IS DONE
Ndmpcopy: na2: Log: RESTORE: Sat Feb 8 15:29:36 2014: Restoring NT ACLs.
Ndmpcopy: na1: Log: DUMP: Deleting "/vol/vfprod_x/../snapshot_for_backup.10825" snapshot.
Ndmpcopy: na1: Log: DUMP_DATE is '5686836680'
Ndmpcopy: na1: Notify: dump successful
Ndmpcopy: na2: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: na2: Notify: restore successful
Ndmpcopy: Transfer successful [ 0 hours, 6 minutes, 41 seconds ]
Ndmpcopy: Done
Также опробовал параметры ndmpd.tcpnodelay.enable on, как предложено в https://communities.netapp.com/thread/15890, безрезультатно.
Мы даже купили файлер с картой 10GbE, так что, по крайней мере, файлер действительно способен доставить, но сейчас я не уверен, что это так.
Том, который я использовал для тестирования, находится в режиме мгновенной блокировки с базовыми дисками SATA 10x 7200 об / мин (8 используемых, двойная четность).
День, когда нам потребуется восстановить больший объем данных, был бы адом в этом сценарии, потому что одного дня не хватило бы для восстановления нескольких ТБ...
У кого-нибудь есть полезные идеи?
Благодарю.
ОБНОВЛЕНИЕ № 1
Хорошо, не имеет отношения к NDMP. Я почти все время читаю 10 МБ / с, поэтому вот некоторые статистические данные о производительности, которые я получил с помощью этого сценария.
#!/bin/sh
#
if [ -z $1 ]; then
echo " "
echo "I need a filer target"
echo "An example syntax"
echo " $0 filer01.msg.dcn"
echo " "
exit 0
fi
SSH="ssh -i /root/.ssh/id_rsa-netapp"
FILER=$1
#
DATAFILE="${FILER}_$(date +%Y%m%d%H%M)"
echo "" >> $DATAFILE
date >> $DATAFILE
echo "------------------------------" >> $DATAFILE
$SSH $FILER 'priv set -q diag; statit -b' 2>/dev/null
echo "Starting statit sample" >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfsstat -z' 2>/dev/null
echo "Zeroing nfsstat" >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfs_hist -z' 2>/dev/null
echo "Zeroing nfs_hist" >> $DATAFILE
$SSH $FILER 'priv set -q diag; wafl_susp -z' 2>/dev/null
echo "Zeroing wafl_susp" >> $DATAFILE
$SSH $FILER 'sysstat -xs -c 30 1' >> $DATAFILE
# And we wait...
$SSH $FILER 'priv set -q diag; statit -en' >> $DATAFILE 2>/dev/null
$SSH $FILER 'priv set -q diag; nfsstat -d' >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfs_hist' >> $DATAFILE
$SSH $FILER 'priv set -q diag; wafl_susp -w' >> $DATAFILE
echo " ** " >> $DATAFILE
и выход можно найти здесь.
Обратите внимание, что этот файлер имеет 768 МБ видеопамяти NVRAM, а совокупность, над которой мы работаем, имеет 10 7200 об / мин дисков SATA в RAID-5.
ОБНОВЛЕНИЕ № 2 10 июня
Я не уверен, почему мы ударяли так много высоких водяных знаков в примере ранее, но сейчас я узнал следующее с помощью поддержки:
- чтение 10MB/s кажется нормальным, поскольку filer всегда чистит диски
- отключение аварийного переключения контроллера (cf disable) заставляет восстановление NDMP (таким образом, запись) выполняться в 5 или более раз быстрее (50-100 МБ / с), и это ожидается
Тем не менее, я не уверен, почему они продали нам карту 10G за макс. 100 МБ / с, но я буду держать это. Тем более что, насколько я понял, WAFL все время использует все диски для распределения записей по максимально возможному количеству шпинделей, а этот файлер имеет около 20 дисков, хотя они только "BSAS".
3 ответа
Наиболее интересной частью вышеприведенного вывода является systat, собранный во время дампа. Мы видим привязанный ЦП, но это может вводить в заблуждение, поскольку выходной сигнал ЦП системы systat -x показывает только самый высокий ЦП, а не среднее значение для каждого ядра. Но мы видим еще кое-что интересное. Мы почти постоянно делаем CP, и они являются H CP (высокий водяной знак). Это указывает на то, что данные в NVRAM, которые должны быть зафиксированы на диске, превысили верхний водный знак. Поэтому мы собираемся заблокировать клиентские запросы, чтобы попытаться сбросить данные NVRAM на диск. Но, чтобы усложнить ситуацию, мы выполняем только около 20-25 МБ / с, а наши CP происходят каждую секунду, а иногда для завершения требуется 3 секунды. Эта математика не проверяется. Я не уверен, какой размер NVRAM для каждого HA-партнера установлен на 2240, но я знаю, что он составляет не менее 256 МБ на голову и, вероятно, больше. При скорости 25 МБ / с это 8-10 секунд, чтобы достичь высокого уровня, и мы все равно будем делать это раньше, и это не то, что мы видим здесь.
В целом вывод выше намекает на то, что файлер делает что-то еще за кадром. Я бы предложил покопаться в systat -m, чтобы увидеть, какой домен наиболее активен. Если это Kahuna и одно ядро закреплено на 100%, то мы можем попасть в узкое место WAFL. Я также оценил бы любую другую фоновую обработку, которая может происходить (задания sis, привязки * и т. Д.)
Если вы не можете отследить его самостоятельно, воспроизведите проблему во время сбора perfstat и включите поддержку NetApp.
Проверьте systat -m. Этот файлер делает что-то еще, в противном случае вы не сможете так быстро достичь контрольных точек CP только с 20 м / с ввода-вывода. Во время теста что-то работает в фоновом режиме - или какая-то странная ошибка в игре.
Парни из команды Perf любят это. Захватите perfstat, выполняя ndmp, и откройте технический случай перфорации.
ОК, во-первых, 2240 является одной из систем нижнего уровня, с ОЗУ нижнего уровня. Тип "H" CP, по-моему, является "верхним водяным знаком", и вы также получаете "f" после того, как это означает, что 1/2 NVMEM была заполнена до того, как CP был завершен при записи.
Суть в том, что производительность записи ограничена: а) количеством NVMEM/NVRAM в системе в сочетании с количеством шпинделей, которые система может записать на диск, чтобы как можно быстрее очистить кэш записи.
Имеющийся у вас sysstat показывает, что вы постоянно находитесь в CP, так что, похоже, это указывает на то, что вы, вероятно, привязаны к шпинделю. Если вы опубликовали вывод "statit -b" (подождите минуту) и "statit -e", тогда мы можем быть уверены. Сначала убедитесь, что вы "Priv Set Advanced".