作者将本文同时发布到：EMC中文支持论坛/community/support/chinese/brsw/blog//08/27/%E6%B5%85%E8%B0%88%E8%99%9A%E6%8B%9F%E7%A3%81%E5%B8%A6%E5%BA%93%E5%A4%87%E4%BB%BD%E7%9A%84%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98
很多时候，用户会反映DDVTL备份速度比较慢，甚至比物理带库还要慢很多。因此他们就会怀疑DD不过尔尔没有传说中的牛叉。基本上对于这样的怀疑，我都会淡然一笑然后帮助他们找到问题的根源。其实80%以上的性能问题都和DataDomain本身没有关系，而是由于前期实施阶段没有规划好而导致的后遗症或者是主机，网络压力过大产生的性能瓶颈。
接下来，我会简单地和大家分享一下我的个人心得体会，希望会对大家有所帮助。众所周知，性能调优向来都是一个极其复杂而且繁琐的系统工程，因为它涉及到各种操作系统平台，不同的通信协议。在这里，一是由于本人的知识有限，二是真的往细了说估计三天三夜也说不完，因此我只会谈一些和VTL相关的点，不做很深入的展开。
既然都说了性能问题这么复杂，那么我们不妨先来看看到底有哪些因素可以影响到数据备份和恢复的性能呢？
备份服务器的硬件配置，包括CPU,内存，硬盘以及网卡等；
备份服务器的操作系统；
备份服务器的日常工作压力；
客户端的硬件配置，包括CPU,内存，硬盘以及网卡/光口等；
客户端的操作系统；
客户端的日常工作压力；
备份网络的硬件和配置情况；
备份网络的拥塞情况；
光纤存储网络的硬件和配置情况；
光纤网络的拥塞情况；
光纤传输距离以及交换机互联的带宽和跳数；
不同的通信协议；
通信协议的优化；
最终的备份设备-磁带库的硬件和配置
怎么样，看了是不是有点晕？你一定没想到平时仅占工作一小部分的备份会这么复杂吧？我们先来看张图，看看从存储节点到VTL的数据流走向从而加深对上面各种性能因素的理解。
我们说的性能分析一定要结合上面所说的各种因素以及数据流走向通盘分析，从数据流的源端开始自上而下来看到底哪里是瓶颈的所在。其实，我一直喜欢把备份比喻成交通运输，把矿产运到指定的仓库。
运输前，首先是挖机在挖矿，然后卸到卡车的拖斗里面，卡车启动出发经过指定的路线到达目的地卸货然后返回到矿地继续运输。看似很简单吧？其实总的运输窗口完全取决于客户的需求，假如客户不急那么可以这样慢慢拉矿甚至可以用更小的车拉，这是出于对成本的考虑。那么假如客户要求加急，需要急用这些矿，怎么办？那就加急呗，当然这个加急费是免不了的，然后就会投入更多的性能极佳的工程车，运输车。多辆挖机同时采矿，然后装到更大的卡车，好几辆卡车同时跑运输运到指定的不同仓库，从而大大缩短了运输的窗口来满足客户的需求。所以，对于备份而言也是如此，只要能够满足你的备份时间窗口就可以了，没有最快只有更快，如果你想达到更好的备份性能，意味着你必须投入更多。回过头来看数据备份，读取源数据的速度，一次读的大小就好比有多少辆挖机同时在挖矿，再传输到备份服务器（卡车），一次传输的大小以及一次可以传多少数据流（卡车的大小以及数量），再经过多少传输距离，网络堵不堵等诸多因素决定了备份窗口时间。对应到相关的专用术语就是：TCPWINDOWSIZE,SEND/RECEIVEBUFFERSIZE,BUFFERSIZE,BLOCKSIZE,MULTIPLESTREAMS,MUTIPLEXINGandISLBANDWIDTH…
下面，就具体的每个节点再来和大家分享一下。
首先是备份服务器这一块。备份服务器是整个数据备份恢复的指挥所，它控制着所有的资源以及负责协调相关事件的运作。所以，它必须有强悍的硬件才能支撑起它每天繁忙的事务。本文不会就具体的服务器系统内核调优作阐述，详细可以参见不同备份软件厂商的性能调优指南。但是千万不要使得服务器过于繁忙，否则会影响整体的数据备份/恢复的性能，我们可以用具体的命令来查看服务器是否过于繁忙。比如-‘vmstat,sar,top…’等命令。另外网络的拥塞情况也要具体的查看，是不是需要用多个网卡做聚合？DNS服务器解析有没有延时等等。。。这些都会影响性能。
再来看一下媒体服务器。媒体服务器指的是直接可以和VTL通过光纤网络通信的服务器，因此它可以识别到VTL分配给它的磁带机设备。它在整个备份恢复环节中起着举足轻重的作用，因为它既接收来自网络客户端的备份数据流同时通过内存又将数据写到磁带设备。除了上面提到的足够强的硬件支撑以外，通常我们还需要在它的进口和出口下点功夫。进口就是服务器的网卡，是不是做了多网口聚合？有没有提高tcpwindowsize以及收发的buffersize?如果是千兆网卡的话，有没有提高MTU的大小？出口的话就是有几个光纤口通往VTL，有没有做负载均衡等等。。。光纤卡的framesize默认值是不是够大？比如，windows32bit/默认的framesize只有64K，需要调整注册表以及安装相应的驱动程序才能调整到1M以上。
现在该聊一聊备份客户端了。顾名思义，客户端指的就是真正需要做备份和恢复的服务器群体。除了上面所提到的服务器负载，网络出口的带宽等等，我们还要注意在备份的时候千万要把杀毒进程停掉，否则速度会非常慢。通常，现在的应用服务器都挂载着存储硬盘，所以RAID的配置以及LVM卷的管理也很重要。良好的卷管理，往往会整体提升IO数据读的响应时间。
最后，我们看一下关于备份软件以及数据库方面我们有哪些可以值得关注的？我们不提倡应用软件和数据库这边打开压缩和加密功能，因为这个直接会影响到datadomain数据压缩比以及备份速度。其实我们DD本身也提供数据压缩和加密的服务，所以没有必要在应用端开启这些功能。谈及多数据流备份这块，就是一个客户端的备份数据集可以同时备份到多个磁带设备，那么设多少个流合理呢？通常的话根据物理硬盘的数量，一个物理硬盘可以对应一个数据流这样可以确保在读数据的时候磁头不会来回找多个文件而浪费时间。当今，RAID阵列环境中适当的增加数据流还是可以帮助提升性能的，但是并不是越多越好，有时候过多的数据流反而会降低性能以及占用过多的系统资源。对于那些小文件，我们建议采用snapp_w_picpath的技术进行备份，再加上增加读的buffersize可以大大提升效率。除了上面所有提到的之外，相当重要的一点就是磁带设备的blocksize，很多备份厂商默认的值都较小只有64K左右，所以千万要增加块的大小，至少要256K以上，这一点尤为重要。
上面我们聊的都是一个个节点，下面我们从通信协议上看看有哪些地方需要关注的。
TCP/IP网络方面，我们可以增加tcpwindowsize和buffersize来提升数据在网络传输过程中的吞吐量。
OracleSolaris
设置TCPIPWINDOWSIZE63k或者更高
编辑文件in_proto.c来调整下面的buffersize
tcp_default_mss-recommendis1500MTU
tcp_sendspace-changedto16KBor32KB
tcp_recvspace-changedto16KBor32KB
AIX-no(networkoption)-我们可以使用’no’命令来调整网络参数
Useno–atoviewcurrentsettings
WhenusingTCPwindowsizes≥64,setrfc1323to1
Herearetherecommendedvaluesfortheparametersdescribedinthissection
§lowclust=200
§lowmbuf=400
§thewall=131072
§mb_cl_hiwat=1200
§sb_max=1310720
§rfc1323=1
WindowsPlatform
WIN:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]Tcp1323Opts,REG_DWORD,3
WINXP/2K3:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]DefaultSendWindow"=dword:1048576
DefaultReceiveWindow"=dword:1048576
GlobalMaxTcpWindowSize"=dword:1048576
TcpWindowSize"=dword:1048576
Tcp1323Opts"=dword:3
Linux-Checkwith“cat/proc/sys/net/ipv4/tcp_window_scaling”,默认值应该大于64K
SAN网络方面：
首先要排除有没有物理端口或者光纤线的问题。例如我们可以用交换机的命令查看“porterrshow”-可以查看是不是哪个SFP有错误，比如’crcerror’等物理错误计数。如果你看到哪个口错误比较多的，还可以看看光强度是不是够，这个可以用命令’sfpshow’查看(brocade)，建议值是大于-7dbm。
是否备份服务器和VTL跨多个交换机，建议不要超过3台交换机。另外，特别重要的是ISL带宽够不够用，备份数据流就像运矿的车，不单单体积大而且源源不断的在跑运输，所以马路宽不宽也很重要，否则就会造成堵车。
长距离传输的话需要增加交换机的B2Bcreditbuffer,这个就相当于tcpwindowsize，一次可以传的数据大一点，可以免去在路上往返的开销。
我们建议主机那边的光口只连接到VTL，不能共享，这个也可以避免出现意外的通讯故障。
Slowdraindevice-我们称之为累赘型设备。比如8G的SAN网络里连接了2G的节点，慢的设备会成为瓶颈所在，因为它处理数据很慢，其他设备都会因为等待它的回应而造成整体性能的下降。
Zoning的配置很重要，多个initiator放在一个zoning有时候会造成性能问题，因为他们彼此会尝试握手建立连接，但是永远不成功，所以对性能会有些许的影响。
最后，再来谈谈DD本身到底什么情况下会影响性能呢？
DD本身有硬件问题，比如硬盘或者内存的问题。
在出现坏的硬盘以后，RAID在数据重建，这个往往会消耗很多的系统资源。
垃圾回收和复制在同时运行，因为他们会占用很多的资源，导致备份速度下降。我们建议备份窗口不要和它们重叠。
系统空间是不是超过了85%，系统空间越满，DD会占用更多的时间来查找数据的唯一性。
VTL的光口没有做到负载均衡。
VTL没有被充分利用，可以增加并发数据流来提高整体的吞吐量。
DD过于繁忙，没有过多的资源来进行快速的IO处理。我们可以用命令’iostat2’来监控。
本次就聊得这里，对于DD虚拟带库的性能问题概括起来就是先排除DD本身有没有问题，比如硬件问题，空间使用情况，系统资源负载情况，光纤口有没有做到负载均衡。
所有其他的瓶颈都是DD以外的，最直接的就是磁带设备的blocksize是不是大于256k。光纤网络有没有性能和配置问题以及备份主机的压力情况等等。总而言之，顺着单向的数据流一个个节点排查就是了。
