这是 FAS2240 8.2P3 7 模式
备份软件：EMC Networker 8.1
NDMP 已在 vFiler 内部配置并运行。
让我们从备份开始。Networker 中的备份命令是：
nsrndmp_save -T dump
您也可以指定 -M (DSA)，但我认为这里它是隐含的。
应用程序信息是（为了安全起见，只需使用新客户端向导在 Networker 中重新创建 NDMP 客户端）：
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
但是：从磁带恢复时，我们只能获得大约 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
以下是恢复期间文件管理器的统计信息
>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 使用率似乎较高，而磁盘利用率也较高，这是理所当然的。
在两个文件服务器之间执行同样的事情，平均速度约为 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 on，如建议的那样https://communities.netapp.com/thread/15890，没有效果。
我们甚至购买了带有 10GbE 卡的文件器，因此该文件器至少具有真正实现功能的潜力，但目前我还不确定它是否真的具有功能。
我用于测试的卷位于一个 snaplock 聚合上，底层有 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
并且可以找到输出这里。
请注意，该文件器似乎有 768 MB 的 NVRAM，而我们正在处理的聚合中有 10 个 7200rpm SATA 磁盘，采用 RAID-5
更新 #26月10日
我不确定为什么我们在之前的例子中达到了那么多的高水位，但现在我在支持的帮助下发现了以下内容：
- 10MB/s 的读取速度似乎很正常，因为文件管理器一直在清理磁盘
- 禁用控制器故障转移 (cf disable) 会使 NDMP 恢复 (因此写入) 以 5 倍或更多的速度 (50-100MB/s) 进行，这是预期的
我仍然不确定他们为什么向我们出售最高速度为 100MB/s 的 10G 卡，但我会继续努力。特别是，据我所知，WAFL 始终使用所有磁盘将写入分散到尽可能多的主轴上，而这个文件管理器可以处理大约 20 个磁盘，即使它们只是“BSAS”
答案1
上述输出中最有趣的部分是转储期间收集的 systat。我们看到了一个固定的 CPU，但这可能会产生误导，因为 systat -x CPU 输出仅显示最高固定的 CPU，而不是每个核心的平均值。但是，我们看到了其他有趣的东西。我们几乎一直在做 CP，它们是 H CP（高水位线）。这表明 NVRAM 中要提交到磁盘的数据已超过高水位线。因此，我们将阻止客户端请求尝试将 NVRAM 数据刷新到磁盘。但是，为了使事情复杂化，我们只做了大约 20-25MB/s，我们的 CP 每秒都在发生，有时需要 3 秒才能完成。这个数学计算没有得到证实。我不确定 2240 上每个 HA 合作伙伴的 NVRAM 大小是多少，但我知道它至少是每个头 256MB，可能更大。在 25MB/s 的速度下，需要 8-10 秒才能达到高水位，无论如何我们都会在那之前做出承诺，但这不是我们在这里看到的。
总而言之，上面的输出暗示文件管理器在幕后执行其他操作。我建议深入研究 systat -m，看看哪个域最活跃。如果是 Kahuna，并且一个核心固定在 100%，那么我们可能会遇到 WAFL 瓶颈。我还会评估可能发生的任何其他后台处理（sis 作业、snap* 作业等）。
如果您无法自行找到问题所在，请在收集 perfstat 时重现该问题并联系 NetApp 支持。
答案2
检查 systat -m。该文件管理器正在执行其他操作，否则您无法仅使用 20m/s 的 IO 如此快速地到达 CP 检查点。测试期间后台有某些程序在运行 - 或者某种奇怪的错误在起作用。
Perf 团队的人都喜欢这个东西。在执行 ndmp 时捕获 perfstat 并打开技术 perf 案例。
答案3
首先，2240 是低端系统之一，具有低端 RAM。我认为“H”CP 类型是“高水位线”，之后您还会得到“f”，这意味着在 CP 完成写入之前，NVMEM 的 1/2 已被填满。
底线是，写入性能受到以下因素的限制：a) 系统中的 NVMEM/NVRAM 数量以及系统可以写入磁盘的主轴数量，以便尽快清除写入缓存。
您在此处的 sysstat 显示您始终处于 CP 状态，因此似乎表明您的主轴可能受限。如果您发布了“statit -b”（等一下）和“statit -e”的输出，那么我们可以确定。请确保您首先“priv set advanced”。