微信号:dellemc_tech

介绍:为戴尔易安信客户提供技术支持服务,为广大IT行业用户分享技术文章与行业信息。

浅谈虚拟磁带库备份的性能问题

2017-04-02 12:24 EMC中国技术社区

       很多时候,用户会反映DD VTL备份速度比较慢,甚至比物理带库还要慢很多。因此他们就会怀疑DD不过尔尔没有传说中的牛叉。基本上对于这样的怀疑,我都会淡然一笑然后帮助他们找到问题的根源。其实80%以上的性能问题都和Data Domain本身没有关系,而是由于前期实施阶段没有规划好而导致的后遗症或者是主机,网络压力过大产生的性能瓶颈。


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


      既然都说了性能问题这么复杂,那么我们不妨先来看看到底有哪些因素可以影响到数据备份和恢复的性能呢?


  1. 备份服务器的硬件配置,包括CPU,内存,硬盘以及网卡等;

  2. 备份服务器的操作系统;

  3. 备份服务器的日常工作压力;

  4. 客户端的硬件配置,包括CPU,内存,硬盘以及网卡/光口等;

  5. 客户端的操作系统;

  6. 客户端的日常工作压力;

  7. 备份网络的硬件和配置情况;

  8. 备份网络的拥塞情况;

  9. 光纤存储网络的硬件和配置情况;

  10. 光纤网络的拥塞情况;

  11. 光纤传输距离以及交换机互联的带宽和跳数;

  12. 不同的通信协议;

  13. 通信协议的优化;

  14. 最终的备份设备-磁带库的硬件和配置


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

 

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

运输前,首先是挖机在挖矿,然后卸到卡车的拖斗里面,卡车启动出发经过指定的路线到达目的地卸货然后返回到矿地继续运输。看似很简单吧?其实总的运输窗口完全取决于客户的需求,假如客户不急那么可以这样慢慢拉矿甚至可以用更小的车拉,这是出于对成本的考虑。那么假如客户要求加急,需要急用这些矿,怎么办?那就加急呗,当然这个加急费是免不了的,然后就会投入更多的性能极佳的工程车,运输车。多辆挖机同时采矿,然后装到更大的卡车,好几辆卡车同时跑运输运到指定的不同仓库,从而大大缩短了运输的窗口来满足客户的需求。所以,对于备份而言也是如此,只要能够满足你的备份时间窗口就可以了,没有最快只有更快,如果你想达到更好的备份性能,意味着你必须投入更多。回过头来看数据备份,读取源数据的速度,一次读的大小就好比有多少辆挖机同时在挖矿,再传输到备份服务器(卡车),一次传输的大小以及一次可以传多少数据流(卡车的大小以及数量),再经过多少传输距离,网络堵不堵等诸多因素决定了备份窗口时间。对应到相关的专用术语就是:TCPWINDOW SIZE,SEND/RECEIVE  BUFFER SIZE,BUFFER SIZE,BLOCK SIZE,MULTIPLE STREAMS,MUTIPLEXING and ISL BANDWIDTH…

 

下面,就具体的每个节点再来和大家分享一下。


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


再来看一下媒体服务器。媒体服务器指的是直接可以和VTL通过光纤网络通信的服务器,因此它可以识别到VTL分配给它的磁带机设备。它在整个备份恢复环节中起着举足轻重的作用,因为它既接收来自网络客户端的备份数据流同时通过内存又将数据写到磁带设备。除了上面提到的足够强的硬件支撑以外,通常我们还需要在它的进口和出口下点功夫。进口就是服务器的网卡,是不是做了多网口聚合?有没有提高tcpwindowsize以及收发的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以上,这一点尤为重要。

 

上面我们聊的都是一个个节点,下面我们从通信协议上看看有哪些地方需要关注的。


TCP/IP网络方面,我们可以增加tcpwindowsize 和buffer size来提升数据在网络传输过程中的吞吐量。


  • Oracle Solaris

    • 设置TCPIPWINDOW SIZE 63k 或者更高

    • 编辑文件in_proto.c 来调整下面的buffer size

      • tcp_default_mss-recommend is 1500 MTU

      • tcp_sendspace-changed to 16KB or 32KB

      • tcp_recvspace-changed to 16KB or 32KB


  • AIX-no(network option)-我们可以使用’no’命令来调整网络参数

    • Use no –a to view current settings

    • When using TCP window sizes ≥ 64, set rfc1323 to 1

    • Here are the recommended values for the parameters described in this section

      • § lowclust = 200

      • § lowmbuf = 400

      • § thewall = 131072

      • § mb_cl_hiwat = 1200

      • § sb_max = 1310720

      • § rfc1323 = 1