备份性能有问题？看看EMC技术大牛如何逐个排查原因（上）

一篇来自EMC技术大牛的文章，深入浅出，技术细节清晰有条理，类比也十分生动贴切。虽然讲的是Data Domain，但依然适用于目前大部分情况下的备份恢复性能分析，值得大家一看。

文/EMC备份恢复远程支持部 Jim

今天和大家谈一谈虚拟磁带库备份的性能问题，工作当中，有的客户会反映DD VTL备份速度比较慢，甚至比物理带库还要慢。因此他们就会怀疑DD不过尔尔，没有传说中牛叉之类的。对于这样的怀疑，我通常都会淡然一笑，其实80%以上的性能问题都和Data Domain无关，而是由于前期实施阶段没有规划好导致的后遗症或者是主机、网络压力过大产生的性能瓶颈。

因此，我会简单地和大家分享一下我的个人心得体会，希望对大家有所帮助。众所周知，性能调优向来是一个极其复杂而且繁琐的系统工程，因为它涉及到各种操作系统，不同的通信协议。在这里，一是由于本人知识有限，二是真往细了说估计三天三夜也说不完，因此我只会谈一些和VTL相关的点，不做很深入的展开。

既然都说了性能问题这么复杂，那么到底有哪些因素可以影响到数据备份和恢复的性能呢？

1. 备份服务器硬件配置，包括CPU，内存，硬盘以及网卡等；
2. 备份服务器操作系统；
3. 备份服务器日常工作压力；
4. 客户端硬件配置，包括CPU,内存，硬盘以及网卡/光口等；
5. 客户端操作系统；
6. 客户端日常工作压力；
7. 备份网络硬件和配置情况；
8. 备份网络拥塞情况；
9. 光纤存储网络硬件和配置情况；
10. 光纤网络拥塞情况；
11. 光纤传输距离以及交换机互联的带宽和跳数；
12. 不同的通信协议；
13. 通信协议优化；
14. 最终备份设备磁带库的硬件和配置

怎么样，看了是不是有点晕？你一定没想到平时仅占工作一小部分的备份会这么复杂吧？我们先来看张图，看看从存储节点到VTL的数据流走向从而加深对上面各种性能因素的理解。

我们说的性能分析一定要结合上面所说的各种因素以及数据流走向通盘分析，从数据流的源端开始自上而下来看到底哪里是瓶颈的所在。其实，我一直喜欢把备份比喻成矿产运输。

运输前，首先是挖掘机在挖矿，然后卸到卡车里，卡车经过指定的路线到达目的地卸货，然后返回到矿区继续运输。在这个过程中，总的运输窗口完全取决于客户需求，假如客户不急那么可以这样慢慢拉矿甚至可以用更小的车拉。那么假如客户要求加急，那就会投入更多工程车、运输车。多辆挖机同时采矿，装到更大的卡车里，好几辆卡车同时跑运输运到指定的不同仓库，从而大大缩短运输时间来满足客户需求，当然加急费是免不了的。

所以，对备份而言也是如此，只要能够满足你的备份时间窗口就可以了，没有最快只有更快，如果你想达到更好的备份性能，意味着你必须投入更多。

回过头来看数据备份。读取源数据的速度，一次读的大小好比有多少辆挖机同时在挖矿，然后传输到备份服务器（卡车），一次传输的大小以及一次可以传多少数据流（卡车的大小以及数量），再经过多少传输距离，网络堵不堵（道路交通状况）等诸多因素决定了备份窗口时间。对应到相关的专用术语就是：TCP window size, send/receive buffer size, buffer size, block size, multipule streams,  multiplexing and ISL bandwidth...

下面，就具体的每个节点展开一下。

备份服务器。备份服务器是整个数据备份恢复的指挥所，它控制着所有资源以及负责协调相关事件的运作。本文不会就具体的服务器系统内核调优作阐述，详细可以参见不同备份软件厂商的性能调优指南。但是千万不要让服务器过于繁忙，否则会影响整体数据备份/恢复的性能，我们可以用具体命令来查看服务器是否过于繁忙。比如-‘vmstat,sar,top’等命令。另外网络的拥塞情况也要具体查看，是不是需要多个网卡做聚合？DNS服务器解析有没有延时等等，这些都会影响性能。

媒体服务器，这是一个关键。媒体服务器是指直接可以和VTL通过光纤网络通信的服务器，因此它可以识别到VTL分配给它的磁带机设备。

在整个备份恢复环节中，媒体服务器既接收来自网络客户端的备份数据流，同时通过内存又将数据写到磁带设备。除了需要有足够强的硬件支撑以外，通常我们还需要在它的进口和出口下点功夫。进口就是服务器的网卡，是不是做了多网口聚合？有没有提高TCP window size以及收发的buffer size?如果是千兆网卡的话，有没有提高MTU的大小？出口的话有几个光纤口通往VTL，有没有做负载均衡等等。光纤卡的话frame size默认值是不是够大？比如，windows 32bit 2003/2008默认的frame size只有64K，需要调整注册表以及安装相应的驱动程序才能调整到1M以上。

备份客户端，顾名思义，客户端指的是真正需要做备份和恢复的服务器群体。除了上面提到的服务器负载，网络出口的带宽等等，我们还要注意备份的时候千万要把杀毒进程停掉，否则速度会非常慢。现在的应用服务器都挂载存储硬盘，所以RAID的配置以及LVM卷的管理也很重要。良好的卷管理，往往会整体提升IO数据读的响应时间。

最后，备份软件以及数据库。我们不提倡应用软件和数据库打开压缩和加密功能，因为这会直接影响到Data Domain数据压缩比以及备份速度，而且DD本身也提供数据压缩和加密服务，所以没有必要在应用端开启这些功能。多数据流备份这块，设多少个流合理呢？通常的话根据物理硬盘的数量，一个物理硬盘可以对应一个数据流这样可以确保在读数据的时候磁头不会来回找多个文件而浪费时间。

当今，RAID阵列环境中适当增加数据流还是可以帮助提升性能的，但是并不是越多越好，有时候过多的数据流反而会降低性能以及占用过多的系统资源。对于小文件，我们建议采用snap image技术进行备份，再加上增加读的buffer size可以大大提升效率。除了上面所有提到的之外，相当重要的一点就是磁带设备的block size，很多备份厂商默认的值都较小只有64K左右，所以千万要增加块的大小，至少要256K以上，这点尤为重要。

以上作者对备份的一个个节点进行了分析，接下来将会从通信协议以及Data Domain本身来查找原因，由于篇幅所限，下半部分内容将会在明天发出，请大家继续关注《备份性能有问题？看看EMC技术大牛如何逐个排查原因（下）》。

To Be Continued......