华为OceanStor VTL6900产品技术建议书模板文档格式.docx
《华为OceanStor VTL6900产品技术建议书模板文档格式.docx》由会员分享，可在线阅读，更多相关《华为OceanStor VTL6900产品技术建议书模板文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
VTL由计算机硬件、应用软件和磁盘驱动器三部分组成。
计算机硬件通常为Intel处理器或相近的变体，一般基于Linux操作系统；
应用软件则用来模拟物理磁带库和驱动器；
磁盘驱动器则往往是基于RAID技术的存储阵列，它不仅具有很好的读写性能，同时也可以在磁盘失效时避免数据丢失。
随着数据量的不断增加，备份系统对于备份设备的容量、备份速度、可靠性、性能价格比等要求越来越高。
传统的磁带库备份由于备份速度低，机械故障点多，而且磁带制式频繁升级、管理繁琐、受灰尘环境等因素影响大，经常导致备份失败（备份失败率高达20％以上），因而很难满足应用连续性要求。
而且，磁带库的维护成本也居高不下。
据StorageMagazine统计，磁带库每年维护成本平均为采购成本的15％。
因此，传统物理磁带备份设备已经无法满足用户对于数据保护的需要。
随着磁盘介质容量的大幅提高，价格的大幅下跌，以SATA为主的磁盘备份系统已经在用户IT环境中大量部署，并逐渐被用户所接受。
磁盘具有高速随机访问的优点，磁盘RAID技术又可以提供磁带所无法比拟的高可靠性。
虚拟磁带库使用内置软件将磁盘虚拟为主流的磁带库，兼有磁盘设备（高性能，易维护）和磁带设备（先进成熟的介质管理）两者的优点，受到市场和用户的广泛关注。
一经推出，即获得了良好的成长。
1.2VTL备份和物理带库备份
下面从可靠性、性能、可扩展性、投资回报率几个方面来比较一下VTL备份和物理带库备份。
∙可靠性
物理磁带库完全由机械设备构成，磁带库的机械手、磁带驱动器和磁带均为非封闭的精密部件，它们的可靠性远不像磁带库厂商宣传的那样高，平均无故障使用时间、平均无故障换带次数等关键指标并不能作为实际应用的参考基准，多个部件组合后整体系统的可用性将更低：
磁带驱动器、磁带存储槽、机械臂系统、控制器、条码扫描系统、磁带入库和磁带出库装置等部件任何的单点故障均可能会导致整个磁带库运转异常，增加宕机时间，甚至影响整个应用系统的正常运转。
同时磁带库不具备容错能力，很容易受灰尘、潮湿等环境因素的影响而导致故障。
有相当大比例的使用中端以下（包括中端）磁带库的用户至少都经历过一次导致备份失败的磁带库故障。
尤其令用户烦恼的是，磁带库修复必须由专业人员进行，而且维修响应时间长，造成日常运营混乱。
用户因此而被迫购买多个磁带驱动器，而驱动器恰恰是磁带库中的最主要的昂贵部件，这进一步加大了用户的总体拥有成本。
VTL基于磁盘阵列设计，没有磁带库设备的介质可靠性低、维护成本高等方面的困扰；
同时，VTL中的磁盘阵列采用RAID技术，因而VTL又具有极强的容错能力。
∙性能
目前磁带技术的发展远远落后于数据量的增长，由于其读写速率低下，因而它已经成为整个备份系统的瓶颈。
另一方面，磁带加载所需要的时间，有时候比磁带读写需要的时间还要长，如果用户要恢复的数据在多盘磁带上，那么要进行一次完整的系统恢复将是漫长的过程，恢复性能将极其低下。
随着业务的增长，每个系统能留给备份的时间越来越少，为了能够在更短的时间内完成更多数据量的备份，用户只能在磁带库内安装更多的磁带机，这也意味着更高的支出，更高的故障率，当磁带技术更新的时候还意味着更大的投资浪费，更糟糕的是，由于磁带库库体设计的限制，能够增加的磁带机数量也是很有限的。
VTL基于磁盘阵列设计，在性能上不存在磁带库具有的读写速率瓶颈，同时VTL是虚拟的磁带库，不存在物理磁带库加载磁带的过程。
∙可扩展性
随着数据量不断增长，物理磁带库存储空间的扩展就显得极其有限。
而如果一开始就采购比较大型的磁带库（如200槽以上），即使采用较低的初始配置，其价格仍然很高。
另外磁带库支持的驱动器数目有限，其性能扩展也将受到很大限制。
VTL采用软件虚拟磁带库和磁带机，所以只需在软件上创建就可以进行磁带库和磁带机的扩展。
VTL存储空间的扩展也只需要增加更多的磁盘即可，十分方便简捷。
∙投资回报率
一方面，物理磁带插槽很快就不够用，另一方面，几乎绝大部分磁带库其磁带空间都无法充分利用（由于备份管理上的要求，很多磁带只写入了几十GB甚至几GB的数据，就由于保存周期和磁带分类管理等要求，而不能写入新的数据），这样，一台号称几十TB的磁带库，可能只能利用不到一半的空间就必须考虑扩容了。
由于物理磁带库较为封闭，大部分配件的维修、更换必须由磁带库原厂商工程师完成，这使得实际故障排除时间难以控制，维修成本也很高。
最终，用户会发现，用于数据保护的投资往往超出预期，而备份系统本身又极大地增加了系统维护的工作量，最终的结果却依旧不能令人满意。
1.3VTL备份和磁盘备份
随着SATA磁盘容量的提升和价格的下降，考虑到物理带库备份的众多问题，很多用户和咨询专家开始倾向使用磁盘阵列作为备份介质。
VTL是基于磁盘阵列的，在性能及可靠性方面，VTL和磁盘阵列都有很好的表现，而在可管理性、安全性和可以提供的功能等方面，VTL的表现比磁盘阵列更好。
∙共享及管理
考虑在一个有多台服务器的环境中实现LANFree组网方式备份的应用场景，磁盘备份配置的复杂性和成本都会迅速提高。
磁盘阵列用于备份，首先都要在其上创建文件系统，这样它才能被备份软件识别继而使用。
然而，一般的文件系统都不能被多服务器共享，只有磁带库可以实现共享。
如果要像使用传统磁带库一样，通过SAN实现多服务器共同使用同一个磁盘阵列，必须要在磁盘阵列上建立多个逻辑设备，然后将每个逻辑设备分配给每台备份服务器。
这就带来了管理上一系列的问题，例如：
何决定为每台服务器分配多少块磁盘；
一旦分配的空间太少，如何在线进行扩展等问题。
虽然现在有些备份软件也提供了备份存储池的概念，但也仅能解决同平台下数据共享的问题，对于跨平台数据共享的问题，需要购买相关的共享选件才能实现，并且兼容的平台很有限。
对于VTL来说，可以通过同时虚拟多个虚拟磁带库、每个虚拟磁带库对应一台服务器来解决该问题。
∙安全性
磁盘备份情况下，备份数据以文件的形式存在于服务器文件系统中，存在诸多安全隐患：
（1）系统管理员的误操作或其他人的恶意删除导致数据丢失；
（2）数据被非法拷贝到其它计算机上进行恢复，导致关键机密的泄漏；
（3）系统被病毒感染，导致备份数据不可用。
VTL中的备份数据以块的方式存储，不存在上述风险。
磁盘备份情况下，尤其在多任务、多进程的情况下，文件系统很有可能成为整个备份系统的性能瓶颈。
VTL中的备份数据以块的方式存储，不存在文件系统，因而没有文件系统固有的性能瓶颈。
∙功能
备份管理软件是设计为磁带库使用的，虽然目前绝大部分备份软件都支持使用磁盘阵列作为备份设备，但与使用磁带时的功能仍然存在很多差别。
这些差别会导致磁盘备份出现一些严重的问题：
（1）对于已有的备份环境，使用磁盘备份就必须彻底改变已有的备份策略，不能实现无缝接入。
（2）磁盘备份不能实现数据硬件压缩功能，不能有效提高备份性能及节约存储空间。
（3）存放在磁盘阵列上的备份数据，无法直接进行介质复制和远程数据保存。
这样，就失去了使用磁带带来的一系列灵活性，如离线保存、数据迁移、异地容灾等等。
VTL能够仿真主流厂商的多种磁带库/磁带机，可以无缝接入到现有备份环境，而且它支持虚拟磁带数据归档和远程复制，轻松实现数据离线保存和异地容灾。
2.用户需求分析
2.1现网环境
客户现网环境收集列表
信息收集列表
客户现网环境客户端数量情况
客户现网环境客户端操作系统情况
客户现网环境数据库系统情况
客户现网环境应用系统情况
客户现网环境初始数据量
客户现网环境数据每日增量
客户现网环境备份策略
客户现网环境备份软件情况
客户现网环境备份服务器硬件配置情况
客户现场光纤交换机可用端口数量
客户现场以太网交换机可用端口数量
客户现场物理磁带库的型号
客户现场磁带机型号
存储网络拓扑图。
存储网络介绍，包括存储组网、备份主机类型、业务数据类型、业务数据量大小等。
根据备份数据类型，确认用户是否需要重复数据删除。
举例：
备份数据类型
初始业务数据量
增量
备份策略
Oracledatabase
500GB
每周增加1GB
一周一全备，保留1个月
每天增备
考虑使用重复数据删除，需要知道数据变化率，下表为一现网数据收集信息统计
初始数据量
变化率
每周约有1%的数据改变
一周一全备，保留1个月，每天增备，增备保留1周
2.2建设需求
客户需要备份什么数据。
客户需要备份容量满足未来多长时间的备份需求
客户的希望的备份策略是什么（全备、增备、备份频率、备份数据保留期等）。
如果客户不清楚自己需要的备份策略，我们必须至少给出一个建议的备份策略。
客户希望的备份时间为多长（备份窗口）。
2.3需求分析
●存储空间需求
根据需要备份的数据量大小和备份策略分析客户对备份存储容量的需求。
●备份性能需求
根据需要备份的数据量大小、备份策略和备份窗口分析客户对备份性能的需求。
3.方案设计原则
3.1.高性能
XXX存储系统中多个数据库的数据需要备份，涉及的备份客户端数量众多、备份数据量大，因而要求备份系统具有优异的备份性能，以便满足多主机并发备份情况下的备份窗口要求。
3.2.易扩展
XXX存储系统中要备份的数据库多，备份数据量大，数据增长较快，因而要求备份系统具有很好的扩展性，具体包括：
未来当备份客户端数量增加时，备份系统的性能要能够平滑扩展，以满足更多主机并发备份的性能要求；
未来当备份数据量增加时，备份系统的存储容量要能够平滑扩展，以满足更大备份数据量的存储空间需求。
3.3.高可靠
备份系统的各网络通路、各设备部件必须冗余配置，以排除单点故障。
没有可靠性可言的备份系统，其任何其他特性将成为空中楼阁。
VTL6900通过RIAD技术、热备磁盘、磁盘预拷贝、Active-Active双引擎配置、SIR引擎2+1集群技术来保证备份系统稳定可靠。
3.4.安全性
备份系统的安全性是异常重要的，它必须能够保证备份数据不被黑客和病毒入侵，必须能够保证备份数据在传输过程中不会因为被截获而导致信息泄露等，因而在设计备份系统时，必须采取多种措施和手段以保证备份数据的安全性。
3.5.便于管理和维护
管理和维护成本是IT投资的一个重要部分。
备份系统应尽量采取集中统一的管理方式，以支持系统配置、性能和状态监控等功能。
同时，备份系统必须具有良好的故障告警机制，并支持硬件在线升级、部件在线更换以及系统扩容等。
3.6.系统整体的均衡
应该对备份系统各部分都进行性能估算，使备份系统不产生明显的瓶颈。
所有备份恢复负载应均衡到不同的网卡、交换机、存储介质等。
追求局部性能而忽视整体的均衡实际上达不到高性能。
4.建议的备份方案
4.1.备份组网
备份组网拓扑图。
VTL6900典型组网方案有如下三种，请根据用户实际环境以及需求选择。
（1）集中备份系统
（2）分级备份系统
当客户本身环境已有物理磁带库，其备份性能已经不能满足要求时，可以采用类似如下的组网方式。
数据备份到VTL6900，VTL6900接管物理带库，开启自动归档或自动缓存功能以便将备份数据在恰当时间归档到物理带库。
此组网方式可以充分利用客户已有投资，提高备份速度，同时可对数据归档过程进行加密，保证数据安全性。
（3）灾备一体化备份系统
此方式适用于客户环境中处于不同的地理位置，各分支机构各自备份，并定期向总部进行备份的场景。
分支机构的数据备份到本地VTL再通过IP网络复制到总部备份中心。
分支以及总部的VTL均开启重复数据删除功能，可以大大缩减数据传输量，降低对网络带宽的要求。
4.2.方案说明
首先详细介绍备份组网和整个备份系统，然后给出技术说明，主要从备份策略、存储容量和备份性能几个方面来说明。
●备份策略说明
详细描述备份策略，包括备份类型（全备、增备）、备份频率、备份数据保留期等。
备份策略的制定必须考虑系统的备份性能需求，很多情况下，为了缩短单次全备时间，需要将业务数据分成若干部分分别作全备。
如果必要，需要说明系统中备份数据的划分（最终对应到备份主机的划分）。
●容量说明
根据要备份的业务数据量和备份策略，给出建议的VTL存储容量。
最终必须得出结论：
VTL（s）的容量可以满足客户需求。
在此假定用户环境如下：
初始数据为100GB，每周一次全备，每日一次增备，数据保存期为6个月。
增备数据为5GB，假设新增加的数据中重复比为2，即新增加的数据有一半是重复的数据。
针对用户存储空间需求需要确认备份方案中是否需要重复数据删除，
可以按照常规以及使用重复数据删除两种方式来计算客户的存储容量需求
1常规备份方式
在如上的假定环境下，所需存储容量如下表所示：
用户第一周全备数据量为100GB，一周后数据增长35GB，因此全备数据量变为135GB。
依次类推，6个月中的最后一次全备数据量为（100+24*35）=940GB。
用户一次全备数据量
需要保留全备数量
全备存储容量
100GB
100+135+….+940=13000GB
用户每次增备数据量为5GB，6个月中（需要除去25次全备）执行增备的次数为6*30-25=155，总的增备数据量为155*5GB=775GB。
故总的存储容量需求为13000+775=13775GB。
注：
通常需要和用户商定预留合适的存储空间余量，此时实际给客户配置的存储容量大小都需要在计算值的基础上增加一定比例的空间余量（一般取20%~50%）。
2重复数据删除备份方式
使用VTL6900重复数据删除功能时，VTL6900的重复数据删除存储空间被划分为两部分：
DedupeCache（对应于VTL）和DedupeRepository（对应于SIR）。
其中，前者用于存放Dedupe索引（并缓存备份数据），后者用于存放Dedupe之后的数据块。
实际配置时需要分别计算这两部分存储空间的大小。
VTL6900支持两种方式的重复数据删除：
在线重删和后处理重删，两种方式下DedupeCache（也就是VTL）部分的存储空间计算方法略有不同，DedupeRepository（也就是SIR）部分的存储空间计算方法没有差异。
建议先计算DedupeRepository（SIR）的存储空间大小，后计算DedupeCache（VTL）的存储空间大小。
在前述假定环境下，所需存储容量计算方法如下：
（1）计算DedupeRepository（SIR）存储空间
首先计算如下两个输入的值：
A）常规方式下总的存储容量：
13775GB。
计算方法见常规备份方式内容。
B）总体重删率：
15。
总体重删率一般为估算值，取值区间建议为8~20。
如果备份数据为数据库，则总体重删率估值可以略高，比如为12~20；
如果备份数据为文件，则总体重删率估值可以略低，比如为8~15。
保留期越长的，总体重删率估值越高；
保留期越短的，总体重删率估值越低。
此处以15为例。
基于上述两个输入，可以得出DedupeRepository（也就是SIR）部分的存储空间大小约为13775GB/15=918GB，即：
常规方式下总的存储容量/总体重删率。
（2）计算DedupeCache（VTL）存储空间
首先计算最大完全备份数据量大小，本例中为940GB。
最大全备一般为最后一次全备，计算方法见常规备份方式内容。
然后根据VTL6900计划使用的重删方式计算DedupeCache的大小，计算方法如下表：
VTL6900计划使用的重删方式
DedupeCache计算公式
在线重删
4%*常规方式下总的存储容量
后处理重删
最大完全备份数据量+4%*常规方式下总的存储容量
其中，常规方式下总的存储容量大小计算方法见常规备份方式内容。
本例中，如果VTL6900使用在线重删方式，则DedupeCache的大小为4%*13775GB=551GB；
如果VTL6900使用后处理重删方式，则DedupeCache的大小为940GB+4%*13775GB=1491GB
综上所述，重删方式下VTL6900所需存储容量大小为：
重删方式
DedupeCache（VTL）容量
DedupeRepository（SIR）容量
总计容量
551GB
918GB
1469GB
1491GB
2409GB
●性能说明
根据业务数据量、备份策略、备份窗口（一般为8小时，也可以给出一个建议的时间窗口）、重复数据删除性能、备份链路（和IP复制链路）的速率、备份服务器和备份主机的接口速率，分析建议的备份系统的性能。
备份系统的性能可以满足客户需求。
4.3.软件配置
描述建议的备份解决方案的软件配置。
（例如，配置多少的backupserverLicense，databaseagent，client等等）。
4.4.硬件配置
描述建议的备份解决方案的硬件配置。
（例如，配置多少的backupserver，VTL，分别配置什么型号的产品等等）。
4.5.方案优势
描述建议的备份解决方案的亮点和优势（例如，高性能、充分利用客户投资、安全节能、部署灵活、易于管理维护、广泛的兼容性等）。
1高性能
VTL6900
备份性能（TB/hr）
恢复性能（TB/hr）
单引擎
15
11.3
双引擎
30
22.5
2重复数据删除（方案中是否涉及重复数据删除）
VTL6900提供了基于数据块的在线方式和后处理方式重复数据删除技术，能极大的减少备份存储容量空间的需求。
其中，在线方式存储管理更为简单，后处理方式不影响备份窗口。
针对不同类型的数据，VTL6900的首次删除率如下表所示：
文件类型
首次删除比
oracle数据库文件
3
Office文档（.excel,.ppt.word.txt）
1.5～2
图片文件.jpg
1.1
多媒体文件（.mp3,.avi）
压缩文件.rar
3高可靠
VTL6900支持Active-Active双引擎配置，当其中一个引擎出现故障时，Active-Active配置能迅速将接管故障引擎上所有的备份作业，当故障引擎被修复时，接管引擎又能自动将属于原来故障引擎的备份作业交换给原来的引擎。
同时VTL6900通过RIAD技术、热备磁盘、磁盘预拷贝、SIR引擎2+1集群技术来保证备份系统稳定可靠。
升级会员 