基于公有云平台，打造TB级海量文件备份保护系统
企业业务稍微上点规模的，IT系统产生的数据很容易就超过TB级，并且资料文档等很容易超过亿级别的规模，如果用手动复制的方案来备份，基本是非常困难的；这种情况下，即使购买一些专业系统，随着数据量日益增大，跑起来也非常吃力。本文重点讨论如何基于云平台，来实现对应的解决方案。
TB级海量文件场景特点- 文件规模大，动作上千万级规模
- 文件目录结构多，层次多
- 文件大小从KB 到MB，GB，甚至百GB级别分布
- 文件变化快，或者有批量增加的场景
- 无用的，有用的，混在一起
- 时间分布久，跨度大
- 文件类型文本，视频，图片，压缩等都有
- 单个节点的数据量上TB级
- 总量上TB级，但分布在多个节点
面对如此特点，如果按照目前的设备+软件方案，在以下几点有非常大的缺陷：
1.升级扩展复杂，预先估计容量，后续扩展起来相当麻烦，必须的改变存储策略，或重新离线做数据迁移分布。如果初始购买的存储扩展有限，后期还不能很好的升级扩展。
2.3-5年左右的生命周期，也就是说，数据经过几年后，改造升级，购买新的方案是必须的，这样当数据上到百TB级别，整个工程实施也是相当复杂了。
3. 一次投入特别的贵，如果对原始TB级数据做专业备份保护，投入得数十万，具体到不同的行业，性能和保护窗口参数稍微提升，投入立即上升到百万级。
随着数据量的增长，超过一个量级，比如10TB级别，其实这类方案已经难于胜任了。
破解思路基本上来说，要破解海量数量，以及TB级增长的难题，基于云的方案是目前最有前途的思路，云有4个核心好处：
1.存储和计算能力按需扩展
2.可靠，云的计算和存储分布特点，使得系统在计算和存储都具备传统结构不具备的数倍的可靠性
3.安全，基础云服务商自身在安全方面不计成本，比起自己构建IT设施，来得更加专业
4.扩展，开放性更好，使得构建的服务，更容易外部系统对接
目前在国内以及全球其他地区，都有成熟的云平台可以作为构建基础。当然，除了明显的优点外，也有1个缺点是，云毕竟在异地，速度方面没有本地来得快，所以在设计系统的时候，要充分考虑到此处特点。以此为基础，考虑构思如下备份系统的设计目标：
- 最高性价比的TB级海量小文件备份服务
- 支持分布式，多节点集中管理监控
- 备份容易且快速恢复
结合云平台的优缺点，基本的设计思路大体如下：
- 规模上量：单点TB突破，分布式上量
- 最小空间占用：最大化变小数据
- 平衡性能开销：IO扫描和效益平衡
- 不做无用功：特征类型自适应处理
- 最近最快，最远最可靠：多级模式结合，平衡速度和可靠性
以下将围绕以上5个点展开，看一个专业级别的备份保护系统如何打造。
TB级突破实现TB级突破，重点思路在于如何解决备份和恢复的速度，以及海量规模的数据块存储。而解决数据备份和恢复速度的关键在于组织好数据索引；我们日常看到的网盘备份是简单的同步模型，很难胜任连续的数据块版本影射关系。而一个专业的备份系统，此处是必须要解决好。
架构上要突破纯云的方案，本地和云结合 
纯云的方案，用了云的几个优势点，但也同时受云天生异地的特点影响，在传输效率方面是必定落后本地的方案，在强调速度的备份和恢复场景下，只有压缩数据，加大带宽。因此，更好的专业级方案是兼顾云和本地的优势进行设计。
以下黄色部分，就是加的一层本地存储；本地客户端将以分块的形式把数据写入本地客户端，同时启动同步逻辑，把数据从本地同步到云存储。
本地索引采用分段分布设计，突破传统RDB单库数量过大，查询过慢的瓶颈。本地索引模型读写相对简单，可以采用自己研发或开源的本地数据存储方案，Sparkey, levelDB，BDB，甚至MongoDB等都可以，实现索引库理论支持TB级以上的的索引大小，具体到文件为每条索引可做到100字节以内
索引容量： TB/0.1KB > 100亿条索引 
按照简单的顺序存取模型，海量的目录，文件索引，这种分级模型的索引框架，可以轻松解决TB级数据与海量小文件场景的管理。
当然，如果离开了异地配合，这种方案还是不完整的。因此在云上，要支持更大规模的索引容器。幸运的是，在云上，我们可以选择的方案还比较多。可以基于MongoDB，LevelDB等优秀的列模型数据库，也可以基于云平台本身的分布式KV数据库来保存索引。
设备通过调度中心定位到云索引中心 ； 单个云索引中心采用NO-SQL DB分布式设计，具体按照任务ID进行分布。关于具体的索引容器，可以选择云平台提供的KV数据库，如果要更多灵活的控制，也可以自己选用专业的KV 数据库来构建。理论上云端可以管理索引的数量无限。
数据按系列段分块存储，提升混合云模型的速度参数普通的量级数据读写，无所谓要不要分块了，但一旦规模上到TB级别，特别在文件量变化快的场景，要尽可能缩短备份窗口，必要的数据存储组织就显得非常的关键。其数据存储分为两部分，本地和云。
本地数据存储设计，可采用N *KB – N *MB 相对固定系列段的分块设计，兼顾读写效率与空间平衡分块采用期望分块方案，尽可能让分块分布在1个区间，保证去重效果的同时，减低分块对索引记录数占用的数量。本文按照64KB 到 4MB的经验值方案来计算.
总可索引数据量区间：理论最小管理数据 100亿* 64KB = 600+TB ， 理论最大管理数据 100亿* 4MB = 40+ PB 这么大的规模，理论上已经远远满足数据存储管理需要。
对于数据上云，初始化系统这里可以把设备定位到不同的云数据中心，与索引位于同1个中心内；上传的数据异步化存储到云存储，或可同时异步到特定的块存储设备；对于块存储，提供合并机制，将小块进行合并存储，提高存储读写效率。所以，理论上云端冗余管理的数据量受限于云存储空间提供商的。
本地和云的数据存储组织方案，在本地通过相对分块序列的方案，在云采用云存储的方案，从KB-MB级的小数据块文件都可以轻松管理起来。
上图是基于索引和块存储结合的增量应用。任何一个数据块的变化都会第一时间，通过本地的索引块签名快速判断是否需要上传备份 ； 如果本地的索引无法启动，将从云端获取签名进行比对。任何一个需要备份的数据块，可以快速通过分块序列存储方案，保存在对应的数据块文件中。
通过并行冗余通道，提升上下云的速度、稳定和可靠性互联网络本身是一个质量无法端到端保证的的一个网络，传输的稳定性会又多个环节影响。包括运营商网络，平台的网络，以及用户接入的网络等。对于一个专业级的备份系统，必须要考虑网络通道的连续、稳定运行。
以上，在任何一次客户端注册期间，一旦认证通过后，可以根据系统资源情况，分配合适的数据节点给客户端。 客户端可以根据情况，正常情况下，多通道并行传送 ； 一旦检测到通道出现问题，自动摘除 ；各个节点会上报数据到调度中心； 同时当链路恢复的时候，自动接入到系统中。下图就是示意多通道在同步到云，以及从云恢复或下载数据。
在备份体系中，数据保密性设计不依赖于人，从机制上保证数据备份到云是机密的。最常用的一种方案就是采用对称加密，具体可以采用AES，3DES等算法。目前比较常用AES256位，而key的产生可以在客户端产生。Key一旦丢失，数据将无法恢复和使用。因此key的妥善保护，也是非常重要。
在基于块的加密设计中，结合云分布特征，数据被打散在不同的存储位置，因此在数据安全方面进一步增加了强度。基于目前的公有云平台的情况，在国内和国外都有几大主流的云存储平台，分布在全球。理论上，数据可以分步在任何一个地方。唯一考虑的是数据如何跨地区进行同步和分布； 当然这里可以先写入本地云中心，冗余块通过高速通道，再同步其他云中心，这里可以是同构的云，也可以是异构的云。
在海量文件情况下，由几种系统因素影响备份的效率和资源开销。备份系统如果全速开进，会消耗过多的计算和IO资源，如果是生产系统，势必也会带来冲突。以下是几种典型的需要规避的：
- 压缩比例和CPU消耗的冲突
- 磁盘IO和小文件随机分布的冲突
- 强加密和CPU需求的冲突
- 实时检测和系统资源的冲突
- 文件类型和压缩效果的冲突
- 备份带宽消耗
通过对带宽，压缩算法，文件类型定义等预定义策略，可以快速平衡好系统资源。这种适合在确定判断系统场景的情况启用。
对于无法预知的情况，启动自动监测机制，包括压缩比，是否硬件加密加速，是否需要启动实时或批量扫描等。
总结与展望：随着云平台的成熟和发展，网络基础设施日益完善，用云构建的数据备份系统，可以充分利用天然的地区分布，运维简单，灵活扩展特点，以及弹性按需投入的优势，企业数据走向云端简单更加简单可行。
作者简介：陈元强，多备份创始人。15年经历，包括一线技术公关、项目与团队管理等，涉及云服务架构，系统底层、网络、存储、安全、大数据计算分析、移动应用等业务和技术领域。（责编/魏伟）
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
