VTL备份速度问题讨论

andy_lyb

几乎所有的VTL厂商都说VTL备份比Tape备份要快，从参数上看也的确挺诱人，中高档的VTL动辄每小时几个TB，也就是每秒钟几百MB甚至1GB的总体吞吐速度，看起来的确需要n多台Tape Drive才能与之抗衡。

但实际上，这个美丽的数字并不是我们轻易就可以达到的，首先要有足够多的磁盘，许多厂家在估算单块SATA磁盘的持续写速时往往只估算到15MB/s，除掉RAID所需的校验盘和热备盘损失之后，磁盘数量就急剧增加了。

但是，更关键的是RAID组的问题，我们不可能将所有磁盘划到一个RAID组，一般做到8+2的RAID6就了不起了。这也就意味着，每个LUN最多只有8块盘的写速度，约120MB/s。同时也就意味着每一盘虚拟磁带的最大写速度为120MB/s。换句话说，如果不巧，你需要的所有虚拟磁带都在同一个RAID组上面，这些磁带总的写速度只能达到120MB/s（碰巧与LTO4磁带机速度相等，纯属巧合，呵呵）。

那么好了，假设我有一个超大的备份任务，例如Oracle数据库，全库备份几个TB，采用并行方式进行备份，需要同时调用8盘磁带进行写操作。

如果是用Tape Drive，简单了，我通过8个Tape Drive调用8盘磁带，理论上速度可以达到8个Tape Drive的总和，假设型号为LTO4，即960MB/s；
但是我现用VTL，麻烦了，调用8盘虚拟磁带，交给8个虚拟的磁带机加载使用，最理想的情况是，这8盘虚拟磁带分布在8个不同的RAID组上面，才能达到960MB/s的速度。可是如果不巧，这8盘虚拟磁带全部在一个RAID组上面，再碰巧这个RAID组还有其他备份任务要处理，完蛋了，可能连120MB/s也达不到了。

也许有人会建议手工创建虚拟磁带，并进行细致的备份策略规划，或许可以解决这个问题。但是回过头想想，只有数据量很大的情况下，我们才会关注速度的问题，而数据量很大，直接的后果就是VTL的容量也会很大，虚拟磁带会非常多，这个管理的工作量实在是太大了......

不知各位XDJM有没有什么行之有效的办法？
欢迎讨论。

无牙

我做过一个类似的项目，也是VTL的备份速度问题，要备份的数据全是海量Oracle数据库。
用户被折磨了N周后，得出的结论是：
1.VTL机头的数量、配置以及与盘阵的连接方式是关键。
2.虚拟磁带的使用顺序是关键，正如楼主说的RAID组的问题，要将虚拟磁带岔开，并行备份作业最好不用在一个RAID上的虚拟磁带。
3.磁盘阵列的性能不能忽视，前面两样注意了性能还上不去，最后只能“硬撑”了！

yangm63

靠机头的内存缓冲呀

w3wu

driver写的速度=备份速度？？？影响备份速度的因素很多的，虚拟带库的缺点的确在容量上面，至于速度还是有点优势的。

realy8

原帖由 无牙 于 2009-2-11 22:07 发表
我做过一个类似的项目，也是VTL的备份速度问题，要备份的数据全是海量Oracle数据库。
用户被折磨了N周后，得出的结论是：
1.VTL机头的数量、配置以及与盘阵的连接方式是关键。
2.虚拟磁带的使用顺序是关键， ...

和盘阵的关系很大，需要最优的配置才能榨出VTL的速度

andy_lyb

原帖由 yangm63 于 2009-2-11 22:37 发表
靠机头的内存缓冲呀

机头内存只能解决最开始的备份速度问题，一旦备份任务大到内存放不下就不管用了。我知道有些厂商为了提高性能，甚至关闭了后端盘阵的Cache。

andy_lyb

原帖由 无牙 于 2009-2-11 22:07 发表
2.虚拟磁带的使用顺序是关键， ...

顺序的问题很难控制的，一般VTL创建虚拟磁带的时候都是批量的，而备份软件调用磁带的时候也是自动的。

如果有什么优化的算法就好了，比如说VTL机头判断出某个备份任务是来自同一台主机的，自动将该任务所需要的虚拟磁带指向不同的RAID组。反正他的虚拟磁带只是个标志位，最终占用的都是磁盘空间嘛。

无牙

原帖由 andy_lyb 于 2009-2-12 10:36 发表


顺序的问题很难控制的，一般VTL创建虚拟磁带的时候都是批量的，而备份软件调用磁带的时候也是自动的。

如果有什么优化的算法就好了，比如说VTL机头判断出某个备份任务是来自同一台主机的，自动将该任务所 ...

当时用的是STK的VTL,STK有一算法知道分配后的虚拟磁带那个和那个是一个RAID组的。然后在备份软件中创建了很多pool，把这些都分开了。

光调这个就弄了十几天，开始效果还行，但是随着数据量的增多，速度也就慢慢的降下了。

现在用户已经调整了策略，海量数据一般都是直接进物理磁带库。