为备份加保险 巧用虚拟带库建集群（1）

本文是虚拟带库应用的系列案例，通过前面的文章，我们依次跟大家介绍了，，，，。本文则重点讲述虚拟带库在集群方式下的应用。这次，我们的案例企业是一家电信公司。

    对于一些大型的电信公司，信息的传输、响应速度、信息安全都至关重要。我们分析的用户是中国网通在某省的分支机构，负责中国联通在该省行政区的电信业务，对全省9个市州的分公司行使全面的管理职能。这家公司是该省惟一一家集移动通信GSM130/131/132 ，CDMA133，长途193，数据17910/17911，互联网165为一体的综合电信运营企业，通信网络联接城乡，并通达世界。

电信备份改造，备份性能第一位
    从前到后一直和我们讨论方案设计的是这家公司运营部门的高处长，高处长详细向我们介绍了他们的前期系统的构架。

    通过前期的业务集中、数据整合后，这家网通公司的业务系统包含了计费、营帐、97数据库、查询等系统，主机平台以HP Superdome和IBM P650为主，单机和集群系统服务器超过10台，数据库均采用Oracle 9 ，规划总存储数据量超过20TB，分别存储在一台EMC的磁盘阵列中和一台HP的磁盘阵列中。备份系统采用EMC Legato NetWorker备份管理软件和一个HP30槽位的磁带库。示意图如图一。

图一：原有存储备份系统示意图

    通信计费、营帐等业务数据至关重要，数据备份当然必不可少。对于电信企业来说，通信应用系统复杂，计费、营帐等数据量十分庞大，因此要求数据备份系统必须有极高的备份速度、足够的存储容量和较好的可管理性。其数据的完整性和恢复及时性要求都比较高，否则一旦发生故障，长时间的中断会对客户服务、业务受理造成直接或间接影响，导致经济损失，影响公司信誉和市场竞争力。

    现在高处长最头疼的就是数据量增长的过快，并且下一季度还要上一个新的项目，数据量估计还会爆炸性的增长。高处长也仔细考虑过目前的存储系统，觉得存储容量和性能应该都没有问题，唯一系统内部一个瓶颈就是原有的备份系统速度太慢，直接导致这种原因的就是一个采用LTO2的30槽位的HP磁带库，所以在这次建设中我们需要对备份系统进行改造，主要是更换更高级的备份设备，提高数据的备份、恢复速度。

追求更高级别的备份性能

    高处长这边的情况我们也都大致了解，由于电信行业的数据量非常大，对备份性能要求高，我们直接推荐了虚拟带库。

    虚拟带库的优势我们在前期的文章中已经有了充分的说明，这家网通分支机构每天的全备份都在几个TB，磁带虽然能够满足其容量的要求，但从性能上已经完全不能满足每天备份时间的需要。磁盘备份也存在诸多的弊端和局限性，所以，就目前而言，针对这家网通分支机构而言，VTL是最为合适的解决方案。

    高处长对各类存储产品也比较了解，对我们提出的方案基本认同，唯一觉得不妥的就是担心虚拟带库的性能可靠性：这么大的数据量每天这么频繁的写入到这个虚拟带库中，一旦虚拟带库控制引擎出现问题怎么办？我们的数据如何恢复？如果从磁带恢复那需要多长时间？

    高处长一连串的问题还真是让我们体会到了客户方的难处，其实，上备份系统就如同买保险一样，可能几十年都用不上一次，但一旦发生问题了，恢复是最主要的，不管你用什么方法，都要按时、按需的恢复需要的数据。尤其像网通这样的大型电信机构，一旦因为后台故障造成前端业务中断，那可真是要掉脑袋的，看来要进一步提高备份系统的可靠性才可以。

    我们看到了高处长的网通公司的业务系统都是采用集群架构的，这下仿佛也给我们一个启发，能不能把我们VTL的控制引擎也做一个集群架构，那样的话既可以满足高处长所说的发生故障的问题，还可以做数据的负载均衡。我们的想法很快得到了公司开发部工程师的确认，告诉我们这种方案设计完全可行，而且的确提高了备份系统的可靠性。