2018年XXX卡中心重点进行分布式对象存储池初期建设规划。通过对语音存储、云计算平台、影像平台、图片资源平台等相关业务系统存储需求进行调研,确定了各个业务系统系统对存储资源池需求状况。此外选取了当前国内具体一定实力的对象存储厂商进行了相关的产品验证,下面对本人一年之内所做工作进行一个完整总结。
- 完成分布式对象存储系统需求整理
初期,通过调研卡中心各个业务系统中文件存储情况,对各个业务系统进行系统的需求整理。通过需求调研发现,当前卡中心非结构化文件存储采用传统文件存储系统(如NAS)做为主要存储方案,NAS存在单卷容量上限(约100T)和文件数量上限的问题,而随着文件数量的增加NAS的读写性能会明显下降。为了对后期存储池建设提供数据支撑,和卡中心业务部门进行了详细的文件数量估算,具体文件量如下:影像系统每月210 万个文件,5 年存储空间预估将超过4PB;语音系统每日50万通录音、每月1500 万个文件,分析平台使用3个月,录音需存储近2PB。
1、需求背景
目前卡中心采用传统文件存储系统(如NAS)做为主要存储方案,NAS存在单卷容量上限(约100T)和文件数量上限的问题,而随着文件数量的增加NAS的读写性能会明显下降。随着业务的发展,文件量存储将会急剧上升,比如影像系统每月210 万个文件,5 年存储空间预估将超过4PB;语音系统每日50万通录音、每月1500 万个文件,分析平台使用3个月,录音需存储近2PB。目前NAS主要通过分卷的形式提供服务来降低单卷容量和减少文件数量,同时多卷组合提供大容量服务来临时解决海量文件存储问题,同时将历史数据归档来降低在线数据的容量需求。为解决海量文件存储问题,企业及解决方案是引入分布式对象存储,借助软件整合服务器及其磁盘资源,提高存储的服务器能力,实现软件定义存储。
2、需求的业务可行性和必要性
通过以上需求调研,确认了分布式对象存资源池完整建设需求。建设存储资源池为构建高可用、高性能的分布式存储系统,并为影像系统、云计算平台、图片资源平台等业务系统提供存储服务,满足数据的全量存储和实时在线访问的需求,提高数据访问效率。
3、需求目标
一期目标为完成分布式存储的平台建设,搭建完整的资源池,实现存储资源的快速交付;对接现有的云计算平台的存储模块,并为影像、语音等业务应用系统提供海量存储服务,替换FastDFS为图片资源平台提供图像存储,总容量规划1PB。
4、业务概述
分布式对象存储提供高可用、高性能、易操作、易维护、易监控的存储服务,并对接影像系统、云计算平台、FastDFS替换、语音平台等业务系统,满足数据的全量存储和实时在线访问。
容器云计算平台已经承载34套互联网系统,近5000个容器,但是镜像模块和发布模块仍使用传统存储,文件系统侵入云平台主机层,存在严重的耦合现象。通过引入对象存储,云平台通过API灵活调用,达到镜像文件和发布包与云平台完全解耦的目标。
影像平台采用本地存储(传统NAS)分卷叠加的方式进行数据存储,仅能满足短期存储的需求,现需将历史影像数据及在线数据进行统一整合,达到数据永久保留以及影像实时调阅的业务目标,同时增加图像处理(图片转换、图片压缩、水印处理、批量上传下载、异常鉴别)和图像智能识别(鉴黄、鉴暴、政治敏感识别)等功能,实现存储和数据处理一体化功能。
目前图片资源平台存储互联网系统的图像资源,使用FastDFS实现,并对外提供图片浏览服务,随着卡中心日益激增的业务需求,对接系统已达23个,需增加用户、权限、鉴权、监控、配额、运维、报表等方面的功能,形成存储的统一管理和可视化管理。
5、功能需求
功能性需求包括存储平台功能和数据处理功能两大功能。
存储平台功能主要包括历史版本、数据迁移、接口类型、存储管理、安全管理、日志管理、文件管理、多数据中心、监控管理、系统管理、报表统计等11个模块,数据处理图像处理、音视频处理、其他处理等3个模块。
6、非功能需求
非功能需求中从业务量指标、数据存储要求、服务等级指标、存储性能要求、高可用要求等方面进行了完整的概述,为后期POC性能测试提供了完整需求参考。
7、风险预估及应急方案
为了保证分布式对象存储的安全稳定,对系统运行过程中可能发生的风险点进行预估,并制定应急方案,及时排查解决系统异常。
- 硬件异常和处理机制
当硬盘发生故障时,停止硬盘服务,待业务低峰期停止服务器并更换硬盘,由于系统高可用,磁盘不影响存储服务器。
当服务器发生异常时,服务器停止服务进行检查,彻底查明原因后,再提供服务。由于系统高可用,服务器异常时不影响存储服务。
- 软件异常处理机制
系统有完善的日志模块和监控模块,当发生软件故障,可以快速定位故障点,并排除故障。系统提供高可用机制,单台服务器软件故障时不影响存储服务。
- 系统网络异常处理机制
如果系统网络发生异常,及时调度相关技术人员,检查网络设备,更换或者重新装配设备,保证尽快修复网络异常。
- 数据库异常处理机制
数据库采用主备同步操作,做好数据的备份与保存。定期检查数据库硬件设备与性能指标,监控相关阀值设置,为数据库做健康检查。
- 保障机制
定期或国家法定长假,国家重大会议活动等进行预防性维护服务,检查系统的工作情况,记录并分析系统的报警记录及运行指标,排查故障和隐患,保证系统正常运行
- 完成分布式对象存储测试方案
为了对各家供应商存储产品进行验证,在POC测试之前,制定了完成的测试方案,测试分为两个部分,功能性测试和非功能性测试。功能性测试包括存储基本功能、数据处理功能,共计申请54台虚拟机服务器;非功能性测试包括基准性能测试、100T数据模拟迁移测试等,共计申请存储节点6台(内存128G PCIE SSD卡1.6T×1),管理节点服务器:3台 内存64G,压力测试服务器:4台 内存64G,数据库服务器:1台 内存64G。
1、功能性测试方案
功能性测试包括存储基本功能和数据处理功能。
存储基本功能从历史版本、数据迁移、接口类型、存储管理、数据安全管理、日志管理、文件管理、多数据中心、监控管理、系统管理、生命周期管理、报表统计、服务器管理、内外网管理、数据库需求、其他功能等15个维度进行全面测试,共计131项测试案例。
数据处理功能从3个维度进行全面测试,包括图片处理、视频处理、其他,共计24项测试案例。
2、非功能性测试方案
非功能测试具体测试案例包括:100T数据迁移测试、Cosbench基准性能测试、高可用测试、稳定性测试、Poc测试系统优缺点等。
从以上几个维度制定了完整的存储测试方案,为后期各家厂商产品测试提供了完整的测试参考用例依据。
- 完成厂商POC测试报告
经过前期功能需求、非功能需求、业务功能需求以及方案审核调研,选定6家供应商进行对象存储POC测试,六家厂商产品测试周期为3个多月(2018-03-23至2018-06-30)。
POC测试测试中深入了解了各家厂商产品功能完整性、产品读写性能及其系统稳定性。通过对象存储功能(20%)、图像音视频处理(10%)、100T数据迁移(20%)、cosbench并发读写速度和响应时间(32%)、PoC测试中发现的BUG(5%)、用户体验(5%)以及产品优势(4%)和其他(4%)等维度进行了完整的POC测试,最终产生各家厂商POC测试报告。
- 完成对象存储项目技术可行性方案
计划第一阶段实现对象存储异地双活集群搭建,实现存储资源的快速交付;对接现有的云计算平台的存储模块,并为影像、语音等业务应用系统提供海量存储服务,替换FastDFS为好无聊系统提供图像存储,总容量规划1PB。需求的适用范围和影响范围,包括行内机构适用范围、用户适用范围、客户适用范围、渠道适用范围等。
在非功能性需求中从以下维度进行了完整的考察。
1、读写性能
分别考察大文件和小文件在各种并发之下读写性能
读写性能考察维度 | 文件大小 | 4K |
16K | ||
256K | ||
1M | ||
4M | ||
20M | ||
256M | ||
512M | ||
并发数量 | 2G | |
5G | ||
50 | ||
200 | ||
400 | ||
600 | ||
1000 | ||
2000 | ||
请求类型 | 上传 | |
下载 |
通过以上维度记录文件平均读写速度、响应时间、procTime、TPS等指标值,如下图:
read | 速度/MBps |
响应时间/ms | |
procTime | |
TPS/k | |
write | 速度/MBps |
响应时间/ms | |
procTime | |
TPS/k |
2、集群高可用
为了保证集群在个别异常情况之下能够提供正常服务,并有自动感知、告警、处理异常能能力,需要搭建高可靠的集群环境。分别从异地容灾、集群故障、服务器故障、磁盘损坏、应用崩溃等维度考察产品的高可用。
硬盘损坏 |
|
故障恢复 |
|
高并发是否数据统计错误 |
|
存储节点服务器1-n故障 |
|
元数据节点故障/leader切换 |
|
网络故障 |
|
存储应用奔溃 |
|
3、系统稳定性
除了提供高可靠的分布式资源池,还需要考虑在长时间、高负荷等环境之下系统的稳定性。需要从如下几点考察系统服务能力:1、24小时无故障服务;2、大数据量情况iops指标无明显变动;3、大数据量下吞吐量指标无明显变化;4、系统负载在一定阀值下服务。具体通过对cpu,内存,网络,io,磁盘等资源性能指标进行监控记录。
24小时无故障服务 |
|
大数据量情况iops指标无明显变动 |
|
大数据量下吞吐量指标无明显变化 |
|
系统负载在一定阀值下服务 |
|
4、100T 数据迁移
为了考察产品的最佳性能和稳定性,需要通过迁移100T数据来完成集群在海量小文件数据执行系统性能。具体记录的项目为:1、100T数据推送是否中断。2、数据写入过程中系统是否平稳,iops波动情况3、随着并发数增加,TPS和带宽有增长趋势,性能是否提升。4、数据迁移过程中系统内存,cpu相关资源负荷以及IO吞吐量记录。此外还需要具体记录如下指标,供后期对产品性能分析和判断:
实际推送数据量 |
|
总迁移时间 |
|
平均推送速度 |
|
数据迁移bug记录 |
|
系统资源指标记录 |
|
成功迁移文件数 |
|
迁移失败文件数 |
|
100T数据迁移优点记录 |
|
5、安全需求
系统应以一定的安全机制保证业务系统数据与分布式对象存储数据读写的安全性,例如关键数据加密、数据一致性检查、数据读写权限、提供多租户功能,实现不同用户之间的数据隔离访问,并可控制用户的配额管理;提供审计日志功能,可以对文件的变更操作(增/删/改)进行记录和查询;提供鉴权和授权机制,及白名单、防盗链、主子账号功能。对于非法用户和无读写权限数据做合法性校验,给出明确错误提示,减少与后台服务的交互。
- 完成对象存储容量评估
为了建设合理容量的存储池,并且对未来5年内存储需求提供建设依据,我们对当前卡中心业务系统容量进行了系统的调研评估。分别完成影像系统容量、云计算平台数据存储容量、FastDFS存储替换容量、企业网盘存储容量、语音存储容量相关业务系统容量评估。具体评估数据统计如下。
1、影像系统容量评估
当前影像系统历史容量有80T数据量,一年增加320T数据。当前共有400T数据。考虑到数据存储5年,并且年增20%数据量。通过计算共计2.4PB数据量。
业务需求 | 影像系统 |
容量 | 历史:80T,一年:320T,共计:400T,考虑存储5年,按年增20%计算,共计2.4P |
应用场景 | 图片存储,历史为tif,改造后为jpg |
文件大小 | 1-5M不等 |
文件数量 | 每月210万 |
文件处理 | 具体图像处理需求沟通中 |
多中心 | 异地灾备 |
存储年限 | 永久 |
应用改造 | NAS迁移到对象存储 |
备注 | 对影像系统后期存储评估:a) 按日进件量20w预估,每份申请的影像图片包括展示图和缩略图(小图),影像系统的图片张数日增长量为100w张((20w+20w*15%*10)*2);b) 按日进件量为20w预估,考虑到后续无纸化申请项目的开展,将PAD进件申请量预估到30%,且附件大小预估为30M/份;影像系统的存储日增长量约900G(20w*30%*30M*50%+300K*20w);当前一年900G*365/1024=320T |
2、云计算平台数据存储评估
云计算当前承载5000个容器应用。当前镜像文件逐年增加。随着业务的发展,镜像文件、应用发布包,依赖包等相关非结构化数据增加较快。通过计算单副本需要9T容量,考虑到3副本存储,需要9T*3=27T存储容量。
业务需求 | 云计算平台存储 |
容量 | 9T |
应用场景 | 镜像存储、发布包存储、卷挂载 |
文件大小 | 未定 |
文件数量 | 百万级别 |
文件处理 | 暂无 |
多中心 | 异地灾备 |
存储年限 | 永久 |
应用改造 | GlusterFS迁移到对象存储 |
备注 | 每个区域1TB,考虑两地三中心,共4套环境,每套环境2个区域(WEB和APP),此外再加上一套内网区域,共计9T*3=27T |
3、FastDFS存储替换容量评估
当前卡中心图像资源平台中,图片存储使用FastDFS进行存储,并对外提供图片浏览服务。由于FastDFS在运维管理、监控管理、用户管理等功能较为欠缺,因此需使用对象存储产品满足相关功能需求,并进行存储的统一管理和可视化管理,后续将FastDFS中存储文件迁移到对象存储,需要5T容量。
业务需求 | FastDFS存储替换 |
容量 | 4T |
应用场景 | 内部API访问接口,外网访问接口,小图片、视频存储 |
文件大小 | TB级别 |
文件数量 | 海量图片视频 |
文件处理 | 暂无 |
多中心 | 待定 |
存储年限 | 永久 |
应用改造 | FastDFS迁移到对象存储 |
备注 |
|
4、企业网盘存储容量评估
业务需求 | 企业网盘 |
容量 | 现状:20T,总量:待评估 |
应用场景 | owncloud |
文件大小 | 各种均有 |
文件数量 | 海量(未能估计) |
文件处理 | 暂无 |
多中心 | 异地灾备 |
存储年限 | 永久 |
应用改造 | NFS迁移到对象存储 |
备注 | 优先级较低 |
5、语音存储容量评估
客服中心语音目前每天平均产生约50W个语音文件,单个文件大小为20~50MB之间,质检系统存储需要保存3个月的客服中心语音,超过3个月的数据自动删除。
在语音处理过程会将2个语音文件合并为1个合成文件,再将合成文件语音转码为转译系统可以识别的语音格式文件,最后在转译为文本文件存储。中间文件都会保存到存储系统,所以实际需要的存储容量是比较大的,通过各种调研计算,具体系统1.72PB容量。
根据存储规划,几类型文件的存储时间和容量计算如下:
业务需求 | 语音存储 |
容量 | 1,72P |
应用场景 | 录音文件 |
文件大小 | 30-50M |
文件数量 | 每天50万比数据量 |
文件处理 | 合并、转码 |
多中心 | 异地灾备 |
存储年限 | 未合并之前(7天) |
应用改造 | GlusterFS迁移到对象存储 |
备注 | 考虑风险,暂不改造 |
- 完成存储池服务器规划
通过对业务系统需求分析和六家厂商测试结果,卡中心领导对当前存储系统进行了细致的分析,确定初期按照1PB有效容量来规划当前存储池。通过计算需要负载均衡服务器3台,存储节点服务器40台,索引池节点、数据处理、后台管理服务器5台,MySQL数据库服务器2台。具体物理服务器架构规划如下。
总结:
通过以上各个方面的总结,最终为2019年存储池建设提供了完整的建设依据。后期计划项目分为两个阶段进行实施。
第一阶段目标为完成分布式存储的平台建设,搭建完整的资源池,为业务系统提供高可用、高性能、易操作、易维护、易监控的存储服务,并实现存储资源的快速交付。整个实施计划从2019年1月1日开始实施,到2019年3月31日上线完成,存储总容量规划1PB。
第二阶段目标是应用对接和存储切换,共计三个系统,计划从2019年4月1日到2018年12月31日,首先对接图片资源平台替换FastDFS进行试点,推广对接影像系统从NAS切换到对象存储,最后对接现有的云计算平台的存储模块为镜像和应用发布包提供存储服务。
以上就是本人在该年度做的具体工作,本人在一年当中对分布式对象存储也有了深入了了解,对本人的技术能力有了很大的提升,希望2019年存储资源池建设顺利。