NetApp Filer的NDMP恢复速度很慢

这是一个FAS2240 8.2P3 7-模式

备份软件：EMC Networker 8.1

NDMP在vFiler中configuration并运行。

我们从备份开始。 Networker中的备份命令是：

nsrndmp_save -T dump

你也可以指定-M（DSA），但我认为这是隐含的。

应用程序信息（刚刚使用新build客户端向导重新创buildNetworker中的NDMP客户端以保证安全）：

 USE_TBB_IF_AVAILABLE=Y DIRECT=Y BUTYPE=dump HIST=Y UPDATE=Y

完全备份运行速度或多或less

 > 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

但是，从磁带恢复时，平均只能达到10MB /秒。磁带备份是在没有其他任何操作的情况下进行的，所以问题不是磁带上的数据是交错的。

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

以下是恢复期间文件pipe理器的统计信息

 >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

与备份相比，CPU使用率似乎很高，而磁盘util是高的，因为它应该如此。

两个文件pipe理器之间做同样的事情，平均每秒40MB /秒

 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选项，如https://communities.netapp.com/thread/15890所示，没有任何效果。

我们甚至买了一个10GbE卡的Filer，所以Filer至less有潜力真正交付，但现在我不知道它的确。

我用于testing的卷位于基础10x 7200rpm SATA磁盘（8个可用，双奇偶校验）的快照集合上。

在这种情况下，我们需要恢复大量数据的那一天将是地狱，因为一天不足以恢复几个TB。

任何人有任何有用的想法？

谢谢。

更新＃1

好吧，与NDMP无关我几乎所有的时间都能读到10MB / s的数据，所以这里有一些我使用这个脚本的性能数据

 #!/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

和输出可以在这里find。

请注意，这个文件似乎有768 MB的NVRAM，我们正在处理的聚合有10个7200转SATA磁盘在RAID-5

6月10日更新

我不知道为什么我们在前面的例子中遇到了很多高水印，但是现在我已经在支持的帮助下发现了以下几点：

10MB / s的读取似乎是正常的，因为文件pipe理器一直在擦除磁盘
禁用控制器故障切换（cf disable）使得NDMP恢复（因此写入）以5倍或更多倍的速度（50-100MB / s）进行，这是预期的

不过，我不确定为什么他们卖给我们一个最大的10G卡。 100MB /秒，但我会继续。尤其是，据我所知，WAFL一直使用所有的磁盘在尽可能多的主轴上传输写入数据，而这个大约20个磁盘即使只是“BSAS”

上面输出中最有趣的部分是转储期间收集的systat。我们看到一个挂钩的CPU，但这可能会引起误解，因为systat -x CPU输出仅显示最高的CPU，而不是每个内核的平均值。但是，我们看到其他有趣的事情。我们几乎一直在做CP，它们是H CP（高水位）。这表明NVRAM中的数据被提交到磁盘已经超过了高位水印。因此，我们将阻止客户端请求尝试将NVRAM数据刷新到磁盘。但是，为了使事情复杂化，我们只做了大约20-25MB / s，我们的CP每秒都在发生，有时需要3秒才能完成。那math不检查。我不确定2240每个HA伙伴的NVRAM大小是多less，但是我知道每个头至less有256MB，甚至更大。在25MB / s，这是8-10秒来打高水印，我们会承诺之前，无论如何，这不是我们在这里看到的。

总而言之，上面的输出暗示了在后台执行其他操作的filter。我会build议挖掘systat -m来查看哪些域是最活跃的。如果是Kahuna，一个核心是100％，那么我们可能会遇到WAFL的瓶颈。我还要评估可能发生的其他后台处理（sis作业，快照*作业等）

如果您无法自行追踪，请在收集perfstat的同时重现问题，并点击NetApp支持。

检查出systat -m。那个文件pipe理员正在做别的事情，否则你只能以20米/秒的速度打这么快的CP检查点。在testing过程中，有些东西会在后台运行 – 或者是一些不可思议的bug。

Perf团队的人喜欢这个东西。在执行ndmp的同时捕获一个perfstat并打开一个技术性的性能testing用例。

首先，2240是低端系统之一，低端内存。我认为“H”型CP是“高水位”，你也得到了“f”，这意味着在CP写完之前已经填满了1/2的NVMEM。

底线是，写性能受限于a）系统中的NVMEM / NVRAM的数量，以及系统可以发送到磁盘的主轴的数量，以尽可能快地清除写caching。

你在这里的系统状态显示你不断在CP，所以这似乎表明，你可能是主轴绑定。如果你发布了“statit -b”的输出（等一下）和“statit -e”，那么我们可以肯定的。确保你先“priv set advanced”。