加载中…
个人资料
Eric雪菲
Eric雪菲 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:37,164
  • 关注人气:13
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

2020再谈对象存储

(2020-06-17 14:33:25)
标签:

it

对象存储

应用

本篇文章的主题是对象存储的实际应用和一些案例反馈,主要目的是研讨对象存储发展到如今,在哪一些场景里面是适合的,以及其中的关键决定性因素。而关于对象存储的基本概念和一些技术细节,相信大家已经在不同的地方已经获得了充足的知识背景,这里就不做深入的介绍。

内容将分为三个部分,第一部分回顾对象存储发展的情况和现状,第二部分是围绕使用对象存储时相应的技术特点适用场景,第三部分对一些实际应用的案例反馈进行和总结。

2020再谈对象存储

第一部分:从学术项目到国标

首先我们先将看看对象存储的发展状况。

从我的理解来看,现在行业里对于对象存储的认识是有几个明显的时间分界线的。考虑到IT行业的技术更迭星驰电掣的速度,这里戏称为“几代人的对象存储认识”

对象存储的标准最初来自于学术科研的领域,美国的卡内基梅隆大学有个并行数据实验室,1995年建立了一个叫network attached secure disk的项目,在这个项目中首次提出了对象存储的概念。随着项目不断往前发展,在更大范围里得到了认可。1999年SNIA(网络存储工业协会)成立了一个叫做OSD(对象存储设备)的工作组,这个工作组发布了ANSI的x3 T10的标准,这就是对象存储的原型。

5年后的2004年SNIA正式发布了OSD1.0的标准,第一波对象存储的技术潮流由此涌现,一个典型的从学术走向工业界的过程。在这第一波浪潮里,Oracle推出了一个标准实现名为Lusture,相信大学和科研机构的人员对此较为熟悉,它在科学计算等领域得到较多广泛应用,可谓第一代的知名对象存储。

而对象存储的的第二波技术热潮得力于亚马逊,2006年AWS正式上线,S3对象存储是其推出的第一个云服务,随着云计算的全球热潮,对象存储的知名度得到了更进一步的大发展,相信很多人是从S3这里第一次知晓了对象存储的存在。

第三次技术热潮从我看来和OpenStack的兴起有很大关系。 OpenStack项目的最早只有两大组件Nova和Swift,其中NASA贡献出来的Nova是解决虚拟化的问题,而另一个Swift项目就是由Rackspace公司贡献出来的对象存储。在2012前后,OpenStack里面出现了一个明星项目Ceph,相信到今天大家已经耳熟能详。这个统一存储项目刚开始吸引大家眼球的特点是它可以提供分布式的块存储,但没想到8年过去,使用最多最流行的反而是它的对象存储功能。而走在前列的专业对象存储公司SwiftStack公司也在今年出现了被NVidia收购的新闻,事情的发展真是难以预料。

回到国内来看,2018年开始,对象存储开始出现了一波热潮:不仅市场上出现了非常多的对象存储公司,而且传统的IT大厂商也纷纷推出了自己的对象存储产品,同时大量的用户在不同的行业里开始采用对象存储方案,一直到2020年的今天,对象存储仍然很受关注。

对象存储发展到如今已经15年,我们不妨从一些有趣的角度来看看,例如从架构图体现出的不同年代感。
2020再谈对象存储

从一开始附在论文和标准里的简单风格的架构图,
2020再谈对象存储

到后期的扁平化二维化风格的架构图,表述的信息从抽象化渐渐走向越来越具体化,强调描述出具体部署的逻辑架构。
2020再谈对象存储
同时,如果你关注不同年代推出的对象存储产品强调的技术亮点,会发现技术亮点从网络的先进性已经变化到强调和容器技术的结合,相信从中也能窥一斑见全豹,感受到IT技术一波一波的变革。
而对象存储的相关技术标准,在近年也有了发展和变化。

在2015年之前,业界还是遵循的事实标准和企业标准,主要参考对象是亚马逊的S3和Swift。
2020再谈对象存储


而2015年9月和2019年8月,国家标准化委员会分别发布了两次相关的国家标准。分别是:
《标准号:GB/T 37732-2019;标准名称:信息技术 云数据存储和管理 第2部分:基于对象的云存储应用接口》 和
《标准号:GB/T 31916.2-2015;信息技术 云计算 分布式块存储系统总体技术要求》
严格的说,这两次颁布的标准大框架都是属于云计算范畴的标准,但其中囊括了云存储技术标准,而对象存储作为一个子类在其中占据了不小的篇幅。

2020再谈对象存储
这两个标准分别就对象存储的系统架构,功能和接口协议规范做了大量阐述,比较详细,值得一看。(相关的资料在网上可以获取)

本文主要的关注重点在于应用场景,所以我们看一下在8年前2012年的时候,当时所描述的开源对象存储Swift的应用场景。

1. 首先是移动互联网:巨大的终端数量代表很多的用户数,用户产生的数据量也在飞速增长,非结构化数据比重很大,Swift在这种场景是比较适合的。
2,其次是在游戏领域:页游,手游比重在增大,游戏用户的数量在增长,同时每个游戏用户的游戏相关数据也在增长,再加上多人在线这种大并发的需求,这全是Swift擅长的领域
3. 除了传统的归档领域,近年出现一种“热归档”的需求,对数据响应的要求大大提高,从几小时到几分钟,Swift在一个案例测试中曾经达到秒级,表现优秀,所以这也是一块新的领域。
4.大数据方面,曾经有人考虑过Hadoop和swift的结合并进行了一些测试,主要的做法是用Swift替代HDFS,这个尝试主要是考虑到swift几个好处,HA上面,原生的HDFS是有单点故障的风险,Namenode没有HA。 另外HDFS的客户端cache是64M,有时候不是很合适。另外swift本身设计有多租户的支持,如果搭建的系统想复用,也会比较方便。


当然到了2020年的今天,应用场景已经有很大拓展,除了音频类视频类的数据,我们看到在高性能计算,科学研究,大数据分析,AI,地震,遥感,气象,金融,医疗,交通和安防等领域,对象存储都开始有了实际的应用。
2020再谈对象存储


对象存储的聚合性能带宽近年有着巨大的增长,对于大数据和AI典型计算框架例如Spark、Presto、Tensorflow、Teradata、Vertica、Splunk等常见分析框架来说,达到10GB/S的带宽性能非常有吸引力;有很多MPP数据库事实上已经开始采用其作为后端存储,对象存储的影响力正在变得越来大。


第2部分,对象存储的产品/服务模式和相关技术特点

由于接触对象存储的时间节点和来源各不相同,我们注意到有些时候大家对于对象存储的认识有些混乱,不同人群从不同的维度有着自己的理解。为了尽可能的清晰阐述对象存储的特征,在本文的开始我们希望能够先对几个相关概念进行解释和描述,以便厘清一些容易迷惑之处。

何谓技术架构,产品功能和应用场景?
2020再谈对象存储

  
技术架构是指基于某一种理论去做具体产品服务设计时所采用的技术路线和实际架构搭建。我们以飞行汽车设计为例,是采用喷气式技术或者是旋翼技术?这是实现飞行的不同技术路线,而在旋翼技术里具体采用单旋翼还是多旋翼又是技术路线里面的细分。在对象存储里,由于牵涉到分布式系统的理论CAP,同时理论本身的限制C、A、P三者不可得兼,具体倾向于其中哪两项而弱化哪一项便是从开头就要确立的技术路线。

当确定了某一种技术路线之后,怎么实现内部机制,各部件如何有机的配合搭建一个高效率的架构,这便是是架构设计需要考虑的问题范畴,例如对象存储的MDS,OSD 怎么设计,在读写的时候如何实现更优的路径,如何判断最优服务质量的节点,如何保证数据的一致性和可靠性,这是对象存储所需要考虑的架构设计问题。
 
而产品功能是指一个产品做出来以后,实际能够解决什么问题,具有什么功能?例如飞行汽车有多大?能搭载几个人?是否能够垂直起降?有没有自动辅助驾驶等?反观对象存储,能支持多大的集群规模,做到多大的并发访问能力,能不能够做身份认证,用户配额,访问控制?这都是属于对象存储需要确定并且去实现的功能。
2020再谈对象存储

当一个产品有了确切的定义,并且成功的设计实现之后,需要考虑的问题就是适用于什么样的场景,如何应用。在一些特别的场景里,有可能需要做比较大的调整与适配,该应用模式。当然应用场景里啊,也有比较大的差别,例如飞行汽车既可以放大成为复仇者联盟里面的空天母舰,也可以用来滴滴打车,是不同的应用场景而已。
 2020再谈对象存储

 
当然,不同的场景对产品本身会有不同的要求。对象存储可以用来作为你的手机照片的云端备份,解决你的个人数据共享的需求,同时也可以用来存储医院核磁共振设备的数据,还可以用于金融证券的重要资料保存,这都是真实存在的应用场景。(需要注意到,有时候产品的新功能和特性能够帮助我们找到一些全新的应用场景,发掘出前所未有的机会,突破到无人触及的领域并培育出新的市场)


厘清了基本概念,我们就能清晰的了解一下容易混淆的概念,如果一个产品是按照对象存储的技术标准去实现的,从底层起就使用的对象存储架构,它当然可以成为一个对象存储产品,但是,也可以成为一个分布式文件存储产品或者分布式块存储产品。例如Ceph的底层是对象,但一开始展现出来的却是分布式块存储和文件存储。
2020再谈对象存储

( 注:上图引自刘爱贵兄的博客)
而另一种情况是,当底层的技术架构并非是对象存储,但在数据存取层实现了对象的接口,展现出来的外部特征很像是一个对象存储,这样的实现严格来说并非真正的对象存储。但在某些小负载的简单应用下,是可以当作对象存储来使用的,应用程序和用户端无法感知,这往往就是让人迷惑之处。

接下来,我们来看看对象存储如何实际应用,从大的维度划分,我认为应该分为两类:基于云端服务的应用场景和基于“2B”场景的IT解决方案。

首先,为了更好说明什么是基于云端的应用场景,我们分析下(RedHat)红帽公司所提供的的一个云端服务案例(是的,Redhat公司也提供云服务)。
2020再谈对象存储

   
CLIMB(微生物生物信息学云基础架构)是四所英国大学(Warwick, Birmingham, Cardiff, and Swansea Universities)共同创建的一个分析平台项目,用于帮助生物学家们研究病毒的科研应用。这个项目旨在提供基于云的免费计算、存储和分析工具,其中包括数百TB的对象存储,能够帮助分布在欧洲,中东以及非洲的研究人员完成大量病毒数据研究和分析。
2020再谈对象存储

 
该项目的Thomas Connor博士 表示:“大多数微生物学家并不精通计算机,但擅长通过实验室研究来解决实际问题……因为我们非常重视疾病等问题,也非常关注全球性问题,例如,在非洲埃博拉病毒爆发期间,各个团队正是使用这一系统来共享信息”。“红帽 Ceph 存储的功能,方便了我们高效存储这些海量数据。现在,我们拥有了足够的存储容量,可以充分满足未来研究数据的存储需求。”

从数据存储的角度看,在这个应用里,对象存储重点解决了三个问题:异构系统互通、跨地域的数据共享和存储成本问题(相较原方案降低了一半)。然而当我们再深入思考,你可能也会注意到,这里面相当的部分是由于云的架构所带来的好处,对象存储在里面,只是作为一个提供服务的技术手段。

通过云端服务去使用对象的时候,通常需要按照接口协议去编写程序对数据进行存取。真实的情况可能会是像下面这样的代码实现:
2020再谈对象存储

 
利用代码把你的数据通过upload或者说put操作上传到对象存储,或者通过get操作从云端获取一个对象,从而拿到你需要的数据,这就的典型的对象存储使用模式(前提是网络是畅通的,按照云计算定义叫做泛在网络)

说完云服务的对象存储形式,我们看看另一种类型,传统的企业级市场。相信大家对这类的产品或者方案也有不少接触,这是以更传统的软硬件的形态提供出来一个具体产品。当然也有可能集成在某一个整体的方案里,例如常见的大数据平台里,或者是MPP的分析数据库方案里,对象存储作为是其中的一个存储子模块,是方案的重要组成部分。

商业市场上,大部分常见的是软件的对象存储产品,适配于标准的通用硬件,X86服务器。
这样的产品已经很多,国内国外的厂商都不少,这里就不再赘述。

但是,也许很多人并不知道的是,对象存储也有硬件的产品。
2020再谈对象存储

 
例如DELL有DX6000系列产品,而EMC虽然被DELL收购,但也有自己独立的ECS硬件产品。(至于怎么处理两个产品冲突导致“一家人内部打架”的问题和最终两个产品的未来前景,目前并不清楚。)
2020再谈对象存储
国内一些厂商例如UIT也有相应的硬件产品UDOS系列,不仅能够提供不同规格硬件产品,甚至可以整机柜交付。

这类软硬件一体化的产品特点还是比较明显的:产品出厂前已经充分的做了软硬件适配的工作,不会出现兼容性问题;同时由于硬件规格参数是已经明确的,也有条件在产品阶段就完成更有针对性的性能优化工作。在实施部署时开箱即用,运维方便的同时也更加稳定可靠。

当然,纯软件的对象存储产品在首次采购上价格会比较低,因为占大头的服务器硬件成本并不计算在内。如果已经有大量闲置服务器,配置也足够高(对象存储对服务器的要求有一定门槛,老旧服务器不一定能适合),只采用对象存储软件能够有效利旧,不失为一个很好的方案;但如果仍需要新购服务器以满足对象存储的要求,那么软硬两种方案那一个成本更优就不一定了,需要视实际核算结果具体权衡。

由于对象存储的参与厂商逐渐增多,我们注意到产品也出现两个明显的发展趋势。
1. 更低成本,对象存储本身用于解决的就是“超海量”的数据,对成本的控制无论多么激进也不为过,因此一个明显趋势是采用更高密度的硬件设备,无论是云服务提供商还是传统硬件产品提供商,都对高密度设备有追求。
2. 极限速度:有人追求低成本就有人追求高性能,新存储介质的出现例如NVme接口的闪存也会帮助性能的大幅提升,加上网络也在进一步升级,我们已经看到了NVme+100Gb网络方案的尝试,能够到达35GB/s以上的性能表现。(当然,在对象存储里,性能是指的吞吐量性能带宽(thoughtput)而非IOps)

最后一点,我认为兼容性才是对象存储能否成功应用的重要因素是,某种程度上,这一点甚至是决定性的,8年前如此,8年后的今天仍然不可忽视。

这里涉及到近年大家屡屡耳闻的一个概念“云原生”应用。如果一个应用是云原生的,意味着应用从诞生之时起就是处于云端的环境,应用和底层系统、平台服务以及其他应用系统的交互都是发生在云端的,这样的应用天生兼容对象存储也更适配与对象存储,两者的结合自然而然,就不存在任何大的兼容问题。
2020再谈对象存储

然而,有大量的企业级应用并未完全云化,即使已经搬迁到虚拟化环境或者私有云环境里,这些应用和存储系统的交互仍然是基于几十年来的经典文件系统,数据读写仍然是打开一个文件写入数据然后关闭保存。这种情况下,应用不做任何改动,想要直接使用对象存储是不可能的,必须要找到额外的解决方案。要么改动应用的所有存储相关模块,要么在应用外部额外增加文件到对象的转换机制,例如对象存储网关。
 
总之,兼容性仍然是对象存储想要推而广之的一个必经门槛,在目前的阶段,必须正面应对。


第3部分 实际案例反馈和分析

 
之前我们已经对技术特点和产品形态进行了探讨,那么我们反过来,由终到始,从具体的应用场景出发,看看哪一些场景比较适合对象存储。
2020再谈对象存储

涉及的应用场景较多,我们抽象归纳有以下几个共同点。

    1.海量的小文件(或者说数据更准确) - (10-100亿)。
    2.更强的弹性扩展能力 - (100节点)。
    3.百倍的传统总容量指标 - (100PB)。
    4.大量的非结构化数据和半结构化数据。
    5.冷数据和热数据混合。

我归纳为“三个一百,冷热混合”。具有以上这些特征的是非常适合用对象存储的,只要具备其中两三个特点,对象存储在这种情况下就凸显出非常强的排他性,具有非常明显的优势,遥遥领先。

如果追溯到对象存储的本质,从数据结构上讲,需求要到达二叉树的极限以上,才更能体现出哈希表的强大。

接下来我们将分析三个具有一定特点的典型案例,从中探索对象存储的适用范畴和真正影响是否能够成功的决定性因素。

A. 局域网环境下的成功应用。
2020再谈对象存储

 
相信大家已经知道,高速公路取消省界收费站的行动已经在全国慢慢铺开,在这个活动开展过程中,在高速公路的两省交界处,虽然人工的收费已经取消了,但并不是一撤了之,取而代之的是电子化和数字化的信息获取,只记录不马上收费而已,更具智慧的AI识别系统填补上了原有人员撤离后的空白。
大多数情况下,每一台车辆经过收费站卡口通道会产生5~7张的抓拍图片,车辆无需停车,源源不断的经过,意味着产生的数据也源源不断的到来,所以这样的数据量的增长是可以想见的;虽然这些抓拍的图片在数量上非常多,但总计的容量倒不见得很大,这是另外一个需要注意的特点,

对象存储在这个场景里能够成功应用有两个关键因素,第一个因素就是网络。对于高速公路省界收费站改造项目来说,整个IT解决方案是一个边缘计算的典型场景,从物理部署上来讲,每一个收费站就是一个边缘节点或者小型的边缘数据中心,实时处理边缘处产生的大量信息流。整个系统从分布的地理位置上看是非常远的,但是从IT逻辑框架图上面来看,边缘节点/数据中心内部的数据网络却是一个局域网,这意味着网络的条件和服务质量是有保障的。

第二个重要因素是IT系统的兼容性。大家也知道,像这样的改造工程大多是最近一两年正在发生的事情,所以大部分其实是一个新上的系统,没有太多历史包袱。在这种情况下,新的平台和系统建设之初已经考虑到各种存储类别,和对象存储的兼容性是完全没问题的,也就是说新系统可以无缝的自如的使用对象存储,不需要任何改造,这也确保了项目的成功应用。

这个成功的应用方案同样可以放在物联网应用和工业互联网应用里,在边缘计算的场景,使用对象存储应对大量的数据,特点鲜明,易于复制和推广。

B.广域网下的成功应用
第二个应用场景有点超乎一般人的想象,说实话也出乎我的意料,是一个地域上跨省的广域网应用。
 
我们国家近年对安全防护和工程质量的要求越来越高,大量利用先进技术实施精细化管理,并且已有相关的法规要求在建筑工地必须部署足够的监控摄像头,以保证对现场情况能够如实记录。而建筑行业的项目通常是有时间周期性的,一些项目已经能缩短到几个月就能完成。而这个周期还在不断的缩短,例如火神山医院雷神山医院,相信大家都印象深刻。(已经有很多段子对中国人吓人的基建速度进行描述了,这里就不再多说)
2020再谈对象存储

因此,项目实施周期变短,由此产生的影响是部署于工地的监控系统需要更加灵活。整套的设施能够周期性灵活的部署,工作一段时间之后会被回收迁移。到下一个建筑工地再重新部署并发挥作用。(这个模式看起来其实有点像虚拟机或容器)。但工地监控所产生这些数据并不会跟着工地所到之处到处游走,而是会要求上传到指定的某个云端数据中心。

国内一些比较大的建筑类的企业,它的项目其实是在全国各地都有分布的。因此,我们碰到的这个例子,实际上它是在相邻的两个省,工地在A省,而云端的数据中心在B省,两地相隔有800公里以上。

在这个案例里使用对象存储作为云端后台前端,直接以对象的方式把数据源源不断的放到邻省的数据中心里。看上去虽然有很多不利的因素,但这个项目却取得了意外的成功。分析了一下原因有以下几点。

    1.网络带宽和稳定性得到了保证.这个项目里面使用的网络状况比较好。大部分情况下都是比较稳定的。
    2.总的数据流量负载有限。那一个工地看起来挺大,但是实际上嗯需要的摄像头却有限,用比较好的摄像头高清的广角的动态的摄像头就能够覆盖较大一片。总的业务压力不是特别大。
    3.整套系统有缓存机制,对象存储有断点续传功能,和对于业务压力变化的动态自我调整。
以相对稳定的带宽配合缓存机制,去应对有限的业务负载。三个条件确保了这一个看似不可能的案例成功应用。


C. 第三个类似案例呢,却是一次不太成功的尝试。
2020再谈对象存储

 
这个案例发生在上海,客户在陆家嘴三件套其中的一栋楼,应用需求是一个7×24小时不间断的安防监控,产生大量的视频数据,需要存放到云端数据中心。数据中心的物理位置其实相比前一个案例来说不远,仍然在上海,也仍然在浦东区,所以物理距离也就是几十公里之内。

该项目的限制比较多,只能使用虚拟机以软件形式进行部署,无法获得专有的硬件资源,对接的应用平台也无法充分配合做优化和修改,这是明显的不利因素。另一个不利因素在于网络质量,首先为了充分测试极限性能,业务数据流几乎占满了可以提供的网络带宽。在超过3个月的长考过程中,不可避免地出现了几次网络抖动和短时间网络故障,当网络故障时间超过系统的容错上限,面对源源不断到来的数据内容,缓存占满后只能做数据包丢弃处理,这导致了最终的数据完整性,低于相应要求的标准。
在将近4个月的时间里,7x24小时不间断的接收高清的监控视频数据流,经过转换以后,上传到云端的对象存储,虽然系统一直稳定运行,但最终由于城域网络问题导致的数据缺损,未能满足电信级高达5个9的可靠性要求。
从这个案例中来看,拥有持续稳定的网络带宽,并且设计中留出足够的带宽余量,是对象存储应对持续高压力业务负载下,必不可少的保证措施。

2020再谈对象存储
综上,在应用对象存储时,我们必须从本质上对其有认识,它仍然是基于网络的外部存储,正是其依赖的HTTP协议,决定了地理位置并不重要,而网络质量才是能否顺利实施的关键因素。

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有