本文转载自公众号「云计算」,高效运维社区致力于陪伴您的职业生涯,与您一起愉快的成长。
作者简介
曹亚孟
资深云计算老兵,有真实底料的解决方案架构师,十多年IT工作经验,曾任职某SaaS云、某OpenStack私有云、某对象存储云,当前在探索AI+Bigdata+Cloud的解决方案,明星业绩覆盖包含售前产品—解决方案—技术实施—运维售后 全系列工作,对其他技术略有涉猎保持好奇。
1. 前言和背景说明
能搭建和使用PB级存储一直是强悍但无用的屠龙绝技,我们更多将其用于炫耀和吹嘘。但最近两三年,我接触了数十家存储量到PB级的客户,深感屠龙绝技已经不再是摆设。
下列变化导致了PB级存储需求的横空出世,连带着CDN、大数据、AI技术一并发展。
首先看数据是因何产生的:
数据保存下来不代表有价值,曾经我们保留几百TB的日志,却只能做最简单的加减乘除统计,或者用于出问题后扒日志堆找证据;我们可以下载数万部影视剧,但一个人一辈子都看不完这些视频。
现在某些营销云已经可以做到毫秒级响应做精准广告投放,用户的日志更有价值了;人工智能逐渐参与辅助医疗,医学影像数据值得保存十年了。随着技术进步价格降低,无论是监管政策还是客户需求,都在推动着数据总量越来越大。比如说现在您买理财产品已经要求全程录像防止误导消费者了,比如说人脸识别已经应用到手机转账审核中。
我们在一个风口时代,无数从不联网的设备、从不收集的数据都跃上云端,已联网设备信息量也大大增加,作为技术决策人,必须有应对PB级存储需求的前瞻性。
假设你做ToC的App,只要你有爆款的梦想,就要存储爆仓的数据。
假设你是智能终端的设计者,现在生成的多媒体数据不仅仅可以被自然人拿来看了,我们还有很多想象空间把数据进行统计和处理。
假设你是物联网综合方案规划者,数据从存5天变成了存5年,你们能做出多少更合理更有长远性的决策?
PB级存储需求来了,但是市面上有多少成熟可用的PB级存储案例哪?
传统厂商会说我没问题,请上200个存储柜吧!但是就算我砸锅卖铁买了200个存储柜,存储服务不是简单的磁盘堆叠啊;而且提速降价的号角是2015年才的吹响的,传统存储设备的测试和成熟周期要5年时间吧。
前些年大量的个人网盘宣称自己有EB级别的数据,1EB的存储空间可是要用掉30-100万块4T盘啊,这些EB级网盘关停以后,这么多闲置硬盘居然没导致盘价跳水。
专用的网盘客户端遮住了实现细节,你的存储技术能否复用到我的项目中?即使接口可以复用,你是在存储群集层面真做到了PB级别,还是无数个50T小群集简单加成的1EB?跟个人客户做过的市场宣传,不应该拿到企业客户这里当做正式承诺。
我有幸在某牛和某度两个云存储厂商呆过,也亲手搭建和维护过单一命名空间过PB的存储系统。在此我和大家分享三方面的知识:
为什么PB级存储必须是对象存储?
如何采购和使用对象存储。
如何设计和实现一个PB级对象存储。
2.大存储必须是对象存储
2.1目录树的无奈
当我们还是儿童的时候,想的是挣大钱了买什么?绝对不是买房买车买彩票,而是买玩具食物和小衣服。当我们从GB级用户变成PB级用户时,传统存储用法已经过时,为通用需求设计的的PB级存储都必须用对象存储接口。
假设你有10PB存储,每个文件100M大,那么你会有1亿个文件。一亿个文件你该如何组织目录结构?我们不考虑文件系统设计上限,我们也假设inode没有耗尽,无论你是每个目录下放100万个文件,还是套十万层目录去存储文件,这种文件访问和管理方式是特别笨拙和无奈。实际情况会比1亿个文件残酷的多,我们常见的文件只有1M左右,大型客户一个项目能有数百亿个文件,这是目录树的设计者们从未考虑过的大变局。
据上文推理,具有普遍适用性的PB级存储,硬件存储厂商从未实现过,因为他们不参与解决过亿文件的管理问题。开源存储方案求一直在谈自己的技术先进性,如何做出又大又快的存储,但很少有人介绍自己元数据系统在百亿Metadata的性能设计。
当前能支撑PB级存储需求的访问方式只有对象存储形式,比如
http://mytest.baiduoss.com/ab/cd/ef.txt&token=asdf 。
当客户向存储群集提交这个get请求时,hostname部分可以被存储系统定位到出该存储群集上某个租户,在确认该租户的token=asdf有效以后,会通过查询metadata数据库的方式,快速得到“ab/cd/ef.txt这个key值存储在第80组存储的第15个扇区”,然后存储服务器将文件取出发给客户,客户浏览器下载的文件会命名为“ef.txt”。
这种访问形式不用担心一个目录下有100万个文件,也不用一层一层遍历目录,即使1000亿个文件,我们要定位文件也只做一次数据库查询。
2.2对象存储对程序员友好
我们习惯了点开文件夹的访问方式,对象存储对人类并不友好,但这种方式对程序很友好。
曾经你写程序必须要知道公用数据存在哪里能不能访问,你要关心ext4和nfs的权限问题,偶发网络波动会让你的所有应用全部hang住;现在你只需要拼接一个url并签发一个token,你编写的任何联网应用都可以读写数据,数据读写成功都有日志,即使读取失败也有可以理解的http返回值。
资源可以被简单描述、简单调用、调用结果可信赖、即使调用失败也能catch异常,这才是程序员想过的日子嘛。
对象存储不仅仅让读写一个文件变得简单优雅,还让管理一群文件不那么复杂。市面上通用的对象存储系统都包含下列文件信息,可以快速的管理大批文件。
filename / key value,就是文件的名字,存储资源的描述。
filesize 和createtime,文件大小和文件创建时间,文件管理和统计费用,也可用于文件筛选和判断。
Hash/MD5等等文件指纹,文件校验和去重使用。
Filehandle,描述文件实际在存储系统中的位置,这可能是物理或逻辑位置,这个信息一般不暴露给客户。
Mimetype或者其他的自定义文件标识,这是个扩展位,方便大存储顺路做简单数据处理。
Last Modified time其实是文件的createtime或meta信息的修改时间,对象存储所有的文件都没有修改,只有同名新文件。
不提供Owner信息,访问域名已经标识了多租户级别的Owner信息,开发者给自己的用户颁发token的过程中就完成了对应用级Owner的标识。
常规文件系统也提供了这些信息(hash值除外),但文件系统在亿万文件管理是太缓慢了,而且很多程序员并不熟悉如何调用这些信息,哪怕只有几万个文件,他们也更习惯把这些信息存在数据表里。现在有一个方便调用的API接口,这比自己维护数据表的成本更低了。
2.3 PB数据的业务场景
上文阐述清楚PB级存储必须用对象存储这种接口方式,什么样的场景会产生PB数据?即使我们现在只有10GB数据,我们也要做好成为PB用户的规划。
如果你要做个有百万以上用户级别的ToC应用,或者出货量过百万的智能硬件,每客户每月产生100M持久存储数据,一年就是1PB。最早的PB级用户大都是图床相册类用户,每月100M数据过去是100张低清照片,现在摄像头升级只能存30张照片了;中国的Icloud付费用户都在增加,其他有用户自生数据的应用就更多了。
在中国这么大人口基数的国家,只做一个百万级用户的ToC应用是很务实的小目标了。在没有高性价比存储的时代,这些应用只能牺牲用户感受限制用户存储数据,只能放弃有价值的客户行为日志。
现在时代变了,该帮客户存的数据存起来,该为自己记得日志记下来吧。某些智能硬件厂商通过分析日志来精准广告投放和运营APP市场,他们已经可以赔钱卖硬件靠广告赚钱,但这有个前提你要先存下来几个P的用户日志。
ToB业务的用户规模远不如ToC应用,但文件的存储周期和可靠性要求十倍于个人娱乐用户。ToB业务涉及人员请注意一下,带宽和存储已经都降价了,连带着大数据和AI技术都在进步,以前不敢想的业务场景可以去实践了。比如高清企业视频会议和无人机航拍后人工智能做设备点检,还有一套套呼之欲出的IOT方案,这都是在促进生产力的进步。
近几年自然数据的产生和处理能力急剧提升,PB存储俱乐部里也有了一批高科技新玩家,我们愿意帮着他们改变世界。比如医疗信息化整改,一个区域的所有PX影像要集中存十年以上,而且随着医疗器械的更新换代,这些影像数据会越来越大。
以前我们拍个CT片子是横着切5片,一个胶片20MB,现在我们拍个CT是纵切30片,一个胶片是200M。比如基因测序,每家基因公司都立志将全人类的基因记录一遍,录完人类的还有其他生物可以搞。比如气象和地质活动,现在有了更新的监测手段、更密集的监测网点,数据记录量也翻倍增加。这类方案对存储要求长周期平滑扩容,云服务厂商的对象存储会是这类客户的最佳方案。
2.4变通和妥协
对象存储并不是万能解决方案,它有解决不了的问题,也愿意为适应现状做兼容和妥协。
基于HTTP协议的文件传输,天然无法满足“大文件的小范围修改且实时落盘”这一需求,最典型的场景就是数据库的DBfile,以及视频原片的现编操作。
即使我们费尽心力让对象存储把自己模拟成本地磁盘,不严谨的兼容POSIX接口,当你打开一个1G的文件修改1k并保存时,本地文件系统只修改1k文件,而对象存储会上传一个1G大的新文件。
数据库这类低延迟应用天生和HTTP协议不投缘,而数据库活跃文件也不可能到PB级,所以DBfile很难去尝试兼容对象存储接口。视频剪辑软件倒是有兼容对象存储接口的技术可行性,他们可以把20G大的原片分散成2000个小文件,但客户的需求还不够强烈,本地的带宽还是不够稳定,这需要假以时日。
对象存储会主动用Fuse/NFS/FTP等手段来服务工业级数据产生设备;比如厂家几千万卖出的医疗仪器只支持FTP协议,这些仪器不可能主动去兼容对象存储,那对象存储就来主动适应这些工业设备。这些数据生产设备对存储的需求也很简单,就像投递邮件一样写数据,根本不关心已经写入的数据如何管理,也极大降低对象存储兼容模拟的实现难度。
对象存储还会用Fuse/NFS/FTP等手段来服务一些传统客户的低负载低需求需求,以保证尽量减少客户的业务变化。比如说银行里依赖一套存储的应用有50个,其中5个高性能应用必须改用对象存储接口,而另外45个低需求应用可以沿袭旧的访问方式,否则换个存储要改50套应用是推不下去的。
3.如何采购对象存储服务
各家公有云都做对象存储服务,那么该从哪些维度选存储服务,我有一些思考和建议。不用带任何情怀和理想,一年内能达到的存储容量是用户分类的唯一标准,GB/TB和PB。同样也不带任何理想和情怀,企业采购云服务就是公平交易,不要奢求免费的蛋糕,我们只期望能物有所值就够了。
3.1 小型用户宽松心态
如果你是一个GB级用户,一年内存储量都不会达到1TB,这时候用对象存储只是为了方便开发应用,不用太多思考存储自身特性。
首先谈价格,100G数据的存储成本每天就几毛钱,我不想讨论如何节约一毛钱的问题。
对象存储和云主机没任何直接技术关联,它是一个独立到孤立的服务,典型互联网架构中,对象存储甚至不和云主机交互任何业务数据,云存储直通客户APP。
对象存储一般会接CDN,CDN是最成熟透明的云应用,你可以CDN和存储选一家,也可以只用存储做源站,技术上不会有任何限制。
云存储都对接多媒体处理,市面上的多媒体处理大都套用imagemagick和ffmpeg,各家的主体功能趋同,细节毛刺上区别的这个级别的用户感觉不出来,有新需求也会被礼貌性无视。
对象存储的业务形态很容易被平台方窃取数据,即使你做了数据加密也可以根据你的计费日志评估你的业务量,但你现在只有G级别的数据,暂时不用考虑太多厂商中立性。
小容量数据也很容易迁移,假设你要从云存储迁移100G的数据到虚拟机,总成本不超过300元,迁移时间也可以控制在一天以内。有了方便迁移这个特性,云存储平台有什么让你不爽的,直接迁走。
3.2 中型用户三思后行
GB级用户不在意的坑,TB级用户全部要踩一遍;而TB级客户在面对繁杂市场宣传,很难看透云存储服务的本质内容。对象存储都是用API接口调用,普通用户看不到也不关心群集规模和技术细节。大家读完本文以后可以更理性和警惕的评估云存储供应商。
首先说数据持久性和安全性不用太关心。云存储厂商都宣称数据可靠性超过10个9,在我看来各种SLA超过8个9就已经比第三次世界大战的几率还小了; 平台说自己能到多少个9,我们都笑笑就好,故障出来了平台总能找到理由的。你买最贵的EMC存储柜也不能保证100%不丢数据,怕丢数据要设计备份方案而不是寄希望于单一硬件或服务。
TB级用户同样不用太关心存储群集的性能,因为你是用HTTP协议访问一个广域网服务,广域网和客户端才是网络吞吐性能的瓶颈。几家云存储厂商在SLA里都没承诺速率,上行带宽本来就免费,而下行带宽都会走CDN。但是这类客户已经出现迁移困难了,假设你有200T数据要从某云迁到自己机房,如果你的迁移用IDC带宽是1000M需要20天才能完成任务。
上文是拨开一些企宣烟幕弹信息,下文是TB级用户最关注的问题。
价格问题。
假设你有200T数据,每年的开销在30万左右;这里说谈价格不是让你死抠存储的价格是10万还是40万,而是注意存储会带来其他消费,比如说现在存储要计算CDN回源带宽了,比如说两个云存储互为备份带宽同步费用有多少。当前存储厂商是按需付费定期调价,短周期看大家都是在不计成本的降价获取客户,但长周期看寡头形成竞争会淡化,存储涨价是合法商业行为,而你数据量大且深度耦合平台业务很难搬走。企业服务市场没有免费蛋糕,我们要适当考虑超低价服务的风险。
云端处理和分发能力。
当你的数据量到TB以后,单台服务器已经无法承载和处理这些数据了,你需要尽量借助云存储平台的处理和分发能力。我本来以为这些功能大家都会各平台都有,但试读者反馈还是建议我加上这一段。
云存储直接处理数据都是这样一个形态:文件输入来自于云存储,参数输入来自于客户的get和post请求,在云端做一些无状态处理,文件可以下载或存储到云存储,参数输出或者接口回调。常见的例子是图片实时打水印有损压缩后下载,视频异步转码另存,涉广告图片检查后返回特征码,日志文件检索特定字段,文件自定义加密解密等等。
这些服务使用方便收费低廉,甚至在改变原有的开发模式,成为存储必备的核心功能点,但是这些服务使用过程中小坑不断。比如说实时有损压缩图片这个功能可极大节省CDN带宽提高资源加载速度,客户端可以根据自己的设备、网络、应用场景决定要什么分辨率的图片,此功能带来了无与伦比的灵活性。
但用户不可能是多媒体处理专家,很多应用场景细节根本就想不到的。比如你往我的平台塞个200M大图我是拒绝处理的,友商不管图片多大都敢去切图,但有30%几率是后台切图程序崩溃,让你等是十分钟才收到个50X的报错;比如说某些音频编解码规范应用了半个世纪,某款新出的手机可能会出兼容性问题。
这类技能太生僻,云厂商培养技术人员都很困难,客户要靠自己评估厂商就更难了。我的建议是多发几个工单,看接工单的是技术人员还是商务客服,看工单处理周期和结果吧。
分发能力好理解,某网盘厂商一开始是把云存储挂载服务器后端,由服务器端的BGP带宽来负责网盘文件下载,后来改成云存储通过CDN直接给网盘客户端发数据,带宽成本降低到以前的20%。
厂商的职业操守
前文刚一本正经的说云计算是企业服务,现在怎么突然又提到操守了?国内的云平台都是做互联网ToC业务起家,习惯用摆布个人用户的伎俩去招揽企业生意,近几年大型云平台屡屡爆出蛮横管理狡诈运营的丑闻。云计算是企业服务,云平台是我们的供应商不是我们的管理者。TB级用户正是业务高速发展的关键时刻,我们更要防备某些吃相难看的混蛋。
云存储相对业务简单,遇到野蛮运营的问题主要集中在窃取数据、估算业务量、恶意不兼容其他服务这三方面。
窃取用户数据指的是监守者自盗后自用,要是泄露给第三方那是安全事故可以直接报警抓人,但平台方自用用户数据很难抓现行。云存储里大都是多媒体数据,谁敢盗播打官司就好;
日志文件加密了就用不了云端大数据分析了,但不挂个人信息的基因测序样本被偷了也不怕。如果客户真的特别害怕丢数据,云平台确实没手段能自证清白,谁偷过用户数据只能听业内风闻。
真正让用户头疼的是平台方会根据计费日志估算你的业务规模,就像小区保安总共能看到你何时出门一样。据不可靠传闻,某厂商本来能拿到某云厂商母公司数亿美元投资,自吹数据量有数PB,该司投资部去调了一下他们的消费金额就取消投资了。
单一个消费总金额就这么麻烦,访问日志可以看文件数量、用户规模分布和大致的动作类型,一个新兴企业最好还是把业务分散在两个厂商那里,毕竟他们两家不能核对你的账单。
最后一条就是有些领先大厂直接压制,故意做技术无关的不兼容、甚至拒绝服务、甚至从其他层面正面打压业务。这里就不举例了,太明显针对单一厂商。如果只是技术不兼容那算和其他云平台恶意竞争,如果到了云平台明抢客户自身业务的阶段,技术采购决策人请把风险告知公司决策层,该妥协还是硬扛不是你的职责范围。
3.3 大型用户谨慎选型
大型用户即使只存储1PB,每年也要花100多万了;中小型客户只要做选型,而大项目不仅要选型和定制,还有更多技术以外的东西要考量。
首先同样说价格问题,大型客户比中小客户更难办,小客户是嫌价格贵,大客户却怕低价砸场。云存储服务不能违背商业服务的本质,甲方没蠢到敢让乙方赔钱做服务,但采购决策层更喜欢看谁的报价最低。
数十PB的数据上云后基本下不来,平台方无论是提价还是降速,有的是追加预算的手段;如果对方真是赔本卖吆喝,成功了就会甩开这个包袱,失败了就直接倒闭。我谈PB级存储项目时,我很愿意分享不同底层技术带来的实际成本构成,为什么同样的价格我们还能挣钱而友商已经在贴钱,相关内容会在第四章节详细说明。
成功案例是很重要的决策依据,但这个依据很难考证真实性。厂商做过PB级项目但其实是一小群TB项目做的计费融合,厂商确实做过数百P的项目却和标准对象存储功能不通用,这类事情太多了,对象存储合同上不会有总容量,发票存根也只是简单的信息服务费。
客户的成功案例必须是单一命名空间容量达到PB级别,并简要说明文件数量和主要读写场景。考察案例真实性的方法主要靠听对方能否自圆其说,甚至让多个厂商当面质疑,能逻辑自治的厂商终归还是靠谱一些。
大客户对云端数据的处理的要求比中小客户更简单,因为复杂业务功能可以自己做,还可以要求厂商为自己做定制开发。
大客户的数据一般都是存在于旧系统的,其迁移方案比小客户复杂,拉专线、寄设备、追增量、切业务等等方面都要考虑到。一般迁移方案是现有数百T数据,规划未来3年到10PB,数十个轻量应用对接代理网关继续使用,几个核心高负载应用改成直接访问存储。为了更好的发挥对象存储优势,厂商还要诱导客户使用云平台的各种新功能。迁移方案要靠谱必须说清楚所依赖环境、操作时间规划、各步风险评估、验证验收标准等信息。
大客户同样在于云平台的职业操守,但其反击能力要强于中小客户,因为他们不会用云平台的标准合同,而是自己订制合同内容。法律合同上能震慑平台的一部分小动作,但计费统计数据云平台还是会拿到,客户可以考虑多分几个供应商多做几个存储池。
3.4 何时选择私有云
对象存储一般是公有云服务,但是超大型国企、电信运营商、国家级项目、大型独立互联网企业、金融行业、智慧城市、基因、气象、医疗等行业都因特定原因使用私有云存储。
对象存储适用于私有云主要基于这三方面考虑:
建设成本。
公有云建设成本有三大头,服务器、IDC和公网带宽。公有云对比对中小型客户在这三方面成本有巨大优势,但也给自己保留了利润空间。很多客户能拿到比云厂商更低价格的资源,那可以拿掉给云平台留的利润,自建私有云存储。
网络通信成本。
这里提的网络通讯成本和前文的公网带宽并不重复,公网带宽是面向分散的广域网客户的,网络通讯成本是强调几个固定的大带宽消耗对象。假设你某个应用的数据读写速度是10Gb/s,云存储和客户端两侧的广域网带宽成本是巨大的,某些弱势运营商甚至要考虑网间结算费用。大读写速率的客户端和云存储会是固定长期合作关系,无论是内网互联、同IDC光纤、同城专线的成本都比互联网通讯的成本低很多。
数据安全等合规需求。
有些客户连计费日志都不想让公有云看到,或者确实有强安全性法规限制,或者只让采购资产不认可采购服务,那也会采用私有云的建设方式。如果本地数据做云端的容灾备份,或者多云厂商之间的权威数据源,这也是可行的方案。
私有云的输出形式有三类,分别是远程代维护、买软件和软硬一体化。买软件和软硬一体化交付大家很熟悉,厂商需要提供非常详实的交付文档,应对一切异常情况。
但当前云存储软件的可维护性并不高,交付文档可能写不出来,远程代维护才是最便利的交付方式。按过去买硬件的习惯,离线运维系统都要巡检和计划内停机,其可用性比在线运维要低很多。
厂商的驻场工程师只能做日常响应工作,让核心技术人员远程代维好过停业务等人来现场。现在几个硬件存储厂商也用类似的远程维护方案,他们的智能诊断程序会将群集状态信息自动发送给厂商,这泄密的风险和远程代维护是相同的。
4.自建/评估对象存储群集
免泄密声明:此文是我基于已知公开常识写的内容,我的工作经历是让我验证这些观点并感觉到了客户痛点,此文只谈架构不谈具体实现方法,并不涉及技术机密。
本章节都是架构技术干货,无论是要自建对象存储群集、采购私有云还是采购PB级公有云都需要评估厂商的技术架构是否可靠,如果您做其他分布式系统也可能会有所收获。
4.1 群集总览
计算机只是一个应用技术,最近几十年少有颠覆性技术革新,我们做的是架构选型和调优,通过放弃某些功能来获得更高更可靠的性能,而非设计一个新模式。为了实现高性能高容量的对象存储,只有将其在HTTP访问场景下做深度优化定制,让底层组件的功能简单甚至笨拙,才能实现足够的性能和稳定性。
首先让大家惊讶一下,我喜欢的对象存储每个节点看起来都有点土。
大部分服务器拆了硬盘后价格低于两万元,没有任何吞金怪兽级硬件。
分布式系统网络IO最珍贵,但为省钱我更愿意用几根千兆线做Bond。
只做入门常识级系统优化,没用专用文件系统也没写裸设备,据说每个节点有50%的性能优化余地。
整体结构可以简化到不需要画架构图的地步,群集有几十个功能项,你想合并成几个服务也行,想分成几十个进程也对。
因为有超高的容错性,所以群集自协商机制比较简单,嗯,应该说是简陋。
我们不买高配服务器,因为我们的技术是做公有云过来的,公有云定价不看成本只看友商的价格,合理花钱才能生存下去持续服务;我们不做单点极限性能优化,那是招不到架构师才走的歪路。这是最有性价比最务实的架构方案,我们练得是一招致命的杀敌功夫,不是翩若惊鸿的表演性武术。
一个基于http对象存储的架构场景有三个主要角色:读写代理、元数据、存储服务。
读写代理,客户端直接访问的Web server,它不存数据只是代理。
元数据,客户可见的Metadata信息和不可见的Filehandle等信息都在这里。
存储服务,实际数据落盘在这些服务器上,有不同的存储形式。
此外还有些辅助角色,简单列一下但不细聊了。
客户端SDK,简化客户访问,还能做一些容错遮蔽。
群集状态同步服务,99%类似Zookeeper。
鉴权认证系统
计费系统以及附属的计费日志搜集系统。
运维监控系统和资产管理系统。
核心组件设计
坚持有中心设计
很多分布式系统都宣称无中心设计,说有中心架构里到处是性能瓶颈和高可用单点。但我坚持有中心设计,有中心设计非常容易做文件管理和统计,群集的修复和扩容范围可控,支持异构存储。而所谓的性能瓶颈和高可用单点,在Http对象存储场景下都有成熟的解决方案。
4.2 系统设计要点
为了让下文的系统设计更有目标性,我们先预设一个通用访问场景:
当前10PB的存储群集已有200亿个500k的文件,群集并发带宽20G,并发链接(含等待链接)5万个,客户每秒写入5000个文件,读取5000个文件,查询2万个文件的fileinfo,有5个客户在做五千万文件的list操作。
4.2.1 给元数据减负
元数据服务是个数据库,存储每个文件的key值、所属bucket、metadata、filehandle以及一些特殊标识。客户每次读访问、写访问、列表统计都会访问元数据服务,我们要充分考虑其性能和高可用问题。
首先元数据服务选型,因为各条用户数据的关联不大,没有任何全局排序对比算平均数的需求,推荐用文档型或列族型NoSql,但继续用关系型数据库少做些索引也没问题。
文档型Nosql一般是三个节点自协商谁是主从,且客户端会旁观整个选举过程,关系型数据库也有成熟的高可用方案,现在元数据的高可用问题算解决一多半了,读写代理来解决另一小办高可用问题。
我们看看元数据的访问需求究竟有多大?上文场景说的是每秒对数据库做5000个读和写操作,再加上2万个获取fileinfo的操作,用户猛然一看这频率很低啊!但每个文件500KByte大,5000个文件就等于20Gbit带宽了,有多少应用群集能是超过20Gbit带宽接入的?
在写库的时候,假设群集每秒接5000个创建文件的请求,在数据库看来就是在表尾做5000条数据的appended操作;单台Mongodb只要做一些常识性优化,配块SSD盘轻松达到1万QPS,案例中的5000个写请求对数据库没任何压力。
用户要读取单条Metadata数据的时候也只有文件名一个筛选条件,没有任何复杂的排序对比操作,这代表数据可以轻易分库分表,25000个读请求分到4个实例还有压力吗?
任何数据库都讨厌list操作,但存储计费和用户需求都会扫表。结合对象存储的list需求,我们可以做几个只读的从库就可以查询99.9%的准实时数据,如果你怕从库数据同步慢还可以单独做个最热数据表,在最热表上合并一下0.1%的新数据。
当我们贴合场景去想,平台计费list操作不要求实时高精确数据啊,我给1000个文件晚计费1分钟很重要吗?一个客户要下载自己2000万条fileinfo信息,按5条信息1k算,这2000万条 fileinfo信息有4GB大,就算云存储能精确的0.1秒查完,客户有能力0.1秒下载完这些信息吗?
如果你觉得元数据服务压力还是大,那还可以让计费系统、读写代理都对查询结果做缓存,或者将数据库挂在成熟的Proxy背后做分库和调度。
我们的数据库能低压力运行,就是设计时充分理解适应了对象存储元数据这一简单需求。
4.2.2 灵活的读写代理
读写代理是整个群集保持松耦合高性能的关键点,这也离不开对场景的深度理解。
首先说读写代理的高可用、负载均衡和高性能,我们会在读写代理前面加几台Nginx,客户端到读写代理都是无状态连接。客户端可以通过LVS、单域名DNS轮询、多域名分散业务等方式将请求分散到多台Nginx,Nginx将请求交给任意读写代理都是能得到相同结果的。
单个读写代理服务崩溃了SDK端会后台重试,直接访问API的用户会以为是自己网慢重新刷新。这么灵活的访问方式,有性能问题多堆几台机器就好了,20G带宽5万个链接很容易消化。
读写代理在访问客户时代表存储服务端,在群集内部扮演的可信客户端。一个分布式系统中,客户端是可控可信,可以知晓群集内其他服务状态,则群集设计会非常简单,可以做到所有组件都自动协商、自宣告状态、有序引导流量以及异常错误重试。
读写代理要访问元数据时可以看到主从库的选举结果,还可以从状态服务获取存储群集的自宣告信息。它不会访问已经宕机的数据库,也不会往已满的存储内写入数据。自宣告的状态信息总有意外时效的情况,这没关系,局域网内重试速度很快的,客户感觉只是多了几毫秒延迟。
读写代理还可以将一些读写策略、缓存策略写入自身配置属性,比如100k以下文件写到SSD存储池,优先写入新扩容存储服务器,某Bucket文件自动做异地复制,某后缀名的文件不缓存,某账户有特殊API语法等等。
综上所述,读写代理是元数据和存储系统的可控可信可减负的好朋友好客户。
4.2.3 存储的硬功夫
存储在元数据和读写代理的保护和调度下过滤了外部访问压力,每个节点都只关心存储本职工作就好。
对象存储群集内部存储可以分为四种,可四种混用也可只用一两个。
三副本存储,读写代理将数据写入到member1,member1一边落盘一边将数据通过网卡复制给member2,member2将数据传递给member3。这种存储实现原理简单,单链接速度上限就是单盘顺序读写速度,磁盘再慢也比网络块,插上十几块盘就能跑满本机网卡。
这类存储大多作为纠删码大存储池的持久化写缓冲组件,单独使用三副本消耗太多硬盘了,即使不在意硬盘的价格,硬盘越多机器就越多组网就越麻烦。
数据库型存储,读写代理将数据文件处理成N多kb级碎片,然后塞入数据库中做持久化写缓冲组件,后端有消费者服务将数据取出另存到纠删码大存储池。我实践中不太推荐这种方式,因为对三副本存储没太大优势。
纠删码存储,纠删码存储是老技术了,大家买的超强纠错的VCD盘片就用的本地纠删码技术。我们可以简单把纠删码技术类比成网络版Raid5,这种技术大大的节省磁盘,而且可以设置多块校验盘来提高数据安全性,是PB级存储的主力存储池。
但它的缺点也很明显,因为数据要做聚合条带后重新编码,写入速度较慢;Raid5磁盘修复时IO放大问题在EC里同样严重;而且纠删码回收已删除文件的空间难度很大速度很慢。
SSD小文件存储,这其实是标准三副本存储的SSD版本,一般用来存储小文件,SSD盘再贵也比缓存服务的内存便宜。小文件存储的数据总量不大,一般在本盘存储即可,不用导入纠删码存储中。
上述存储手段只是落盘手段,作为存储组件还要通盘考虑下列问题。
磁盘故障时的修复性能
商用磁盘都是按照36-60个月的使用周期设计的,假设你有6000块磁盘每个月要坏100块盘,天天坏盘天天修盘已经成为常态。厂商要保证损坏磁盘快速修复,避免修复周期内另外几块冗余盘一并损坏,又要保证磁盘修复时群集性能受不了太大影响。
当前大家都采购4T8T硬盘,按照磁盘顺序写入300M的速率,填满一个磁盘的数据需要10个小时以上,最通用的处理方案是将一块4T盘分为40个小PG,40个PG逃逸到40块新盘上速度就在30分钟以内,而且没消耗新磁盘太多IO。磁盘修复时的IO放大有解决方案但很复杂且涉密,本文不提及。我只透露前文不让做单节点性能压榨就是防着这类异常情况,http下载场景中引入缓存可以减少重复读取的压力。
群集动态扩容能力
很少有项目是上线就建设50PB的容量,并在半个月内全部数据就位。对象存储群集刚建成只有几十个机柜几千兆带宽,后续群集容量和性能都要动态扩容。存储系统扩容后不要做无意义的数据重新分布,因为数据重新分布可以理解成磁盘修复,太容易出性能类故障了。
我们不做数据再平衡,但磁盘写入时要有优先级,否则群集内各存储节点会受力不均而出现新的瓶颈,比如当前有四组存储,第一组用量90%,第二组50%,第三组10%,第四组刚新增用量0%。我们在读写代理那一层可以做策略控制,第一组存储不再写入数据,第二组存储低优先级写入数据,第三第四组存储主力写入数据。
如何提升读写性能
对象存储场景里很少出现一个链接读写100G文件的情况,而常见的是几万个链接去竞争带宽资源,大家都慢慢读写。只要有100个并发连接,群集的访问压力会分布均匀。一个PB级存储系统,存储机怎么也有20台以上,每台主机提供1000Mb带宽用于对外服务,这就是20Gb总出口带宽了,群集默认性能就不会太差。数据都是顺序写入硬盘,SATA盘也能达到极高写入性能。
读取数据的性能也不是大问题,互联网类型数据的缓存命中功率极高,一台缓存可以减负一大堆元数据和存储服务;大数据一下要读几百T的数据必然是多链接,每个存储节点都会分到数据读取任务的,而且应用要读这么多数据不会要秒级完成任务,五分钟内完成下载就是闪电速度了。
回收空间的性能
前文提到数据都是顺序写硬盘,这样文件删除时回收空间很慢,但4T盘浪费50%的空间也比买15K盘或者SSD合算,某些小规模或超有钱云存储都没做回收空间这个功能。
当文件有计划内滚动删除需求需求,比如说互联网安防监控,一般是用两副本或单副本群集扛性能,为回收空间要浪费50%空间,也有公司在开发快删专用的环形存储结构。如果数据进了纠删码才被删掉,比如说走了个PB级相册客户,那浪费磁盘空间的损失可能要持续半年以上。
数据去重问题
对象存储不做数据去重功能,看着简单的功能背后都有蛛网一样的复杂考量,元数据服务、计费服务、存储服务、增数据逻辑、删数据逻辑、回收空间逻辑、用户资源隔离逻辑都会因为这个很炫的功能被彻底改变。
真正要去重的文件就是那些电影,随着版权保护的加深,电影只存原片盗版减少会是趋势,其他文件即使做切片去重,命中率也非常低。我们提供hash值让客户判断该不该删文件,该不该做文件映射就够了。
长周期软硬件换代
对象存储是付费企业级服务,并不是终身免费但匆匆关张的个人网盘。我们必须考虑十年为刻度的长周期维护问题,某种硬件停产了怎么办,假设系统内核停止维护怎么办?我强烈反对极端优化单点性能,就是因为单点性能极限优化必然和硬件、内核、文件系统都有深度关联。我推荐存储主力服务是应用层服务用户态进程,老中青三代服务器和谐运行,群集性能瓶颈本来就不在单点,不要给自己的软件无故设限。
冷存储问题
冷存储分真冷和低温两种类型,真冷存储就是用磁带、蓝光盘、可离线存储节点来存储数据,这样可以节省机柜电量,但这是个工程学问题不是计算机问题了。低温存储就是标准存储换更大更慢更省电的磁盘,通过硬件选型来降低硬件和机柜成本。
4.3 存储测试标准
前文我大量篇幅介绍对象存储和传统存储的不同,如果搭建一个私有对象存储群集,我们该做的测试也要贴合场景。
存储系统交付时,我会推荐做如下测试:
用户侧标准功能测试,如文件读、写、删除、获取metadata信息。
单链接读写速率测试。
一万并发连接读写速率测试。
群集长周期并发写入测试,既要击穿写缓冲池,又为其他测试积累数据。
群集长周期随机读取测试,注意是随机读取避免命中缓存。
随机关一台存储服务器,观测群集读写性能是否受影响,观察群集修复速率。
通过读取文件Metadata信息对元数据服务进行读取和并发性能压测。
随机关闭各角色服务器各一台,看群集功能和性能是否受影响。
同名文件大范围替换测试,观察文件频繁修改后是否会性能降低。
根据厂商承诺的空间回收策略做空间回收测试。
某些厂商没话题可聊就强调自己的IO和IOPS非常高,这就非常不专业了,HTTP接口的存储要谈性能也该谈并发连接和总带宽。
4.4 运营成本问题
当你要建设一个存储群集时,没有存储技术可以去买,但建完赔钱就不行了。评估TCO成本是要上公有云还是私有云,用哪家公司方案最合理的主要依据。
我们不能像买个存储柜一样简单算TCO成本,对象存储群集的成本有五大块:
硬件采购成本,一般占总成本的20-30%。
服务器和硬盘是一次性投入,按照五年报废周期折算。
机柜电力成本,一般占总成本的20-30%。
存储节点经常插几十块磁盘,都是高功耗的电老虎,五年机柜成本不比硬件低。
带宽接入成本,一般占总成本的是5-50%。
根据这个存储的业务类型可以确定带宽接入成本,最低可能只是个维护带宽加几光纤,最高可能是运营商的大客户。
资源闲置成本,一般占总成本的5-50%。
私有群集要计算多久才能填满空间,公有群集要为潜在需求预留足够资源。
人力/软件成本,一般占总成本的20-30%。
开发一套对象存储然后公有云磨练几年,这需要投入亿元以上,分摊到一个项目也有数百万投入。厂商的人力成本很多是用在压缩硬件、机柜、带宽、闲置成本上,节省了人力成本其他开销就会增大。
在千万级别项目投入里,金融成本也是很大的成本。建设一个存储群集的总成本会和买一套硬件存储柜的价格差不多,报价不便宜但考虑金融成本就很合算了。假设客户买一套硬件存储柜是一次性掏5000万;而对象存储群集硬件占比不高,机柜、带宽人力等成本都是按月缴纳五年才凑到5000万的。
拿着上述数据我们已经可以预估出新建一个存储群集的实际成本,我们拿这些钱和公有云价格进行对比,如果私有云成本比公有云高太多,我们也能说服采购决策层继续用公有云。
在群集运营过程中规模会受到IDC环境的限制,机柜和带宽不是想买就有的。电力也好机柜也好,IDC都是卖不出去资源就愿意接大客户,哪怕零利润总好过闲置;但如果资源都卖给一个大客户了,这个IDC也就没资源接其他客户了。我很少考虑100PB以上的存储问题,也有这方面考虑。有些工程师吹牛皮说做过EB级存储,让他基于常识说一下自己的硬件投了多少。
结束语
上文为我对PB级对象存储知道的一切常识,PB级存储需求离你我业务越来越近,大家早做准备各自努力吧。
近期好文:
PostgreSQL在阿里的应用
从中华武术谈运维工程师以及运维自动化
Linux 私房菜(鸟哥):我和 Linux 的这些年,那些事
从无到有:熊猫直播 Rancho 发布系统构建之路
【原创故事】运维的一天:架构设计、故障处理、人员离职...
自动化运维之架构设计六要点 | 腾讯大梁专栏
想了解
更多?
更深?
GOPS 2017 北京站有更多专家的分享哟
2017.7.28-7.29
点击“阅读原文”,关注 728·GOPS2017 北京站