当前位置: 首页 > 科技观察

块存储、文件存储、对象存储的区别与联系

时间:2023-03-13 23:22:20 科技观察

1.块存储、文件存储、对象存储的本质区别是什么?1、块存储典型设备:磁盘阵列,硬盘块存储主要是将整个裸磁盘空间映射到主机上使用,也就是说磁盘阵列中有5块硬盘(为了描述方便,每个硬盘假设为1G),然后可以通过划分逻辑盘,做Raid,或者LVM(逻辑卷)等多种方式逻辑划分N个逻辑硬盘。(假设划分出来的逻辑盘也是5个,每个都是1G,但是这5个1G的逻辑盘和原来的5个物理硬盘意义完全不同,比如第一个逻辑硬盘A中,前200M是来自物理硬盘1,第二个200M来自物理硬盘2,所以逻辑硬盘A是由多个物理硬盘逻辑创建的硬盘。)然后块存储将使用映射的方法将这些逻辑磁盘映射到主机,主机上的操作系统会识别出有5块硬盘,但是操作系统分不清是逻辑的还是物理的,会认为只是5块裸露的物理硬盘,直接挂载一个物理的硬盘和操作系统没有区别,至少在操作系统的感知上没有区别。这样,操作系统也需要对挂载的裸硬盘进行分区格式化后才能使用,这与普通主机内置硬盘的方式完全相同。优点:1、这种方式的优点当然是通过Raid和LVM的方式保护了数据。2、另外,可以将多块便宜的硬盘组合成一个大容量的逻辑盘,对外提供服务,增加容量。3、写入数据时,由于是由多个磁盘组成的逻辑磁盘,可以并行写入多个磁盘,提高了读写效率。4、块存储大多采用SAN架构组网、传输速率和封装协议,从而提高传输速度和读写速率。缺点:1、使用SAN架构组网时,需要为主机额外购买光纤通道卡和光纤交换机,价格昂贵。2.主机之间的数据不能共享。如果服务器没有集群,裸块存储盘映射到宿主机,格式化使用后,相当于宿主机的本地盘,所以宿主机A的本地盘根本不能用。供主机B使用,数据不能共享。3、不利于不同操作系统主机之间的数据共享:另一个原因是操作系统使用不同的文件系统。格式化后,不同文件系统之间的数据无法共享。比如一台安装了WIN的电脑,文件系统是FAT32/NTFS,而Linux是EXT4,EXT4无法识别NTFS的文件系统。就像NTFS格式的U盘,插到Linux笔记本上根本无法识别。所以不利于文件共享。2、文件存储典型设备:FTP、NFS服务器为了克服上述文件不能共享的问题,出现了文件存储。也有用于文件存储的硬件和软件集成设备,但实际上,如果您拿一台服务器/笔记本电脑并安装相应的操作系统和软件,就可以设置FTP和NFS服务。这类服务后的服务器是文件的一种存储。主机A可以直接上传和下载文件到文件存储。与块存储不同,主机A不需要对文件存储进行格式化,因为文件管理功能已经由文件存储自己处理了。优点:1.成本低:任何机器都可以,普通以太网就可以,根本不需要专门的SAN网络,成本低。2、方便的文件共享:比如主机A(WIN,NTFS文件系统)和主机B(Linux,EXT4文件系统)想互相拷贝一部电影,这是不可能的。添加一台主机C(NFS服务器),然后可以先把A复制到C,再把C复制到B就OK了。(例子很肤浅,见谅。。。)缺点:读写速率低,传输速率慢:以太网,上传下载速度慢,而且所有的读写都必须由服务器中的硬盘来承担,相比之下diskarray几十上百块硬盘动不动就同时读写,速度慢很多。3、对象存储典型设备:内置大容量硬盘的分布式服务器对象存储最常见的解决方案是安装多台内置大容量硬盘的服务器,安装对象存储软件,然后提供几个附加的serversformanagement在节点上安装对象存储管理软件。管理节点可以管理其他服务器,对外提供读写访问功能。对象存储之所以??存在,就是为了克服块存储和文件存储各自的缺点,发挥各自的优势。简单来说,块存储读写快,不利于共享,而文件存储读写慢,利于共享。能不能做个快速读写,好分享一下?于是就有了对象存储。首先,一个文件包含属性(术语称为元数据,元数据,如文件的大小、修改时间、存储路径等)和内容(以下简称数据)。过去,像FAT32这样的文件系统直接将文件的数据与元数据一起存储。存储过程首先根据文件系统的最小块大小对文件进行打散(比如一个4M的文件,假设文件系统需要一个4K的块,则将文件打散成1000个小块),然后写入写入硬盘,过程中没有数据/元数据的区分。而每个block最后都会告诉你下一个要读取的block的地址,然后按照map的顺序依次查找,最后完成整个文件所有block的读取。在这种情况下,读写速度是很慢的,因为即使你有100个机械臂读写,但是由于你只有读完第一个块才能知道下一个块在哪里,相当于只有一个机械臂手臂确实有效。对象存储将元数据分离,控制节点称为元数据服务器(服务器+对象存储管理软件),主要负责存储对象的属性(主要是对象的数据分散存储在那些分布式的servers)information),而其他负责存储数据的分布式服务器称为OSD,主要负责存储文件的数据部分。当用户访问一个对象时,他将首先访问元数据服务器。元数据服务器只负责反馈该对象存储在哪些OSD中。假设反馈文件A存储在B、C、D三个OSD中,用户再次访问这三个OSD服务器。读取数据。此时由于三个OSD同时向外界传输数据,所以传输速度加快。OSD服务器数量越多,读写速度提升越多。这样就达到了快速读写的目的。另一方面,对象存储软件有一个特殊的文件系统,所以OSD对外相当于一个文件服务器,所以文件共享没有难度,文件共享的问题也解决了。因此,对象存储的出现很好地结合了块存储和文件存储的优点。最后,当对象存储兼有块存储和文件存储的优点时,为什么要使用块存储或文件存储呢?1.有一类应用需要存储直接裸盘映射,比如数据库。因为数据库需要存储裸盘并映射到自己,然后根据自己的数据库文件系统格式化裸盘,不能使用其他已经格式化成某种文件系统的存储。此类应用程序更适合使用块存储。2、对象存储的成本还是高于普通文件存储,需要购买专门的对象存储软件和大容量硬盘。如果对数据量的要求不是很大,只是为了文件共享,不如直接使用文件存储,这样比较划算。2、从应用的角度来看,块存储、文件存储、对象存储产品与市场需求之间存在着各种相互影响,但无论使用哪一种,最终的表现都是产品和应用需要匹配。应用需求越多样化,市场越细化,产品种类越丰富。在存储行业,我们也可以从“应用适配”的角度来谈各种类型的存储。传统上,IT设备分为计算/存储/网络三大类,楚汉界限分明。大家都知道计算,服务器,小型机,大型机;网络是路由器交换机;存储包括内置存储和外接存储,最常见的是磁盘阵列。在HCI(超融合)概念被炒作之前,计算网络存储的定义还是很明确的,各司其职。今天我们不讨论超融合的情况,只看传统理解的存储情况。从逻辑上讲,存储通常分为块存储、文件存储和对象存储。这三种存储在实际应用中的适应环境还是有明显区别的。块存储(DAS/SAN)通常用于一些专有系统,对随机读写性能和可靠性要求高。通常搭载Oracle/DB2等传统数据库,连接方式通常主要是FC光纤(8Gb/16Gb),采用光纤协议。如果要求稍微低一点,也会有基于千兆/10G以太网的连接方式。MySQL等数据库可能使用IPSAN,使用iSCSI协议。通常使用块存储的是系统而不是用户,并发访问不多。经常会出现一套存储只为一个应用系统服务的情况,比如一个交易系统,一个计费系统。典型行业如金融、制造、能源、电信等。相对而言,文件存储(NAS)可以兼顾多种应用和更多的用户访问,同时提供便捷的数据共享手段。毕竟,大多数用户数据都是以文件的形式存储的。PC时代,数据共享多以文件形式存在。比如常见的FTP服务、NFS服务、Samba共享等都是典型的文件存储。NAS存储可以解决几十个用户甚至上百个用户的文件存储共享访问。在中小企业市场,一两台NAS存储设备就可以支撑整个IT部门。CRM系统、SCM系统、OA系统、邮件系统都可以使用NAS存储来处理。即使在公有云发展初期,用户量没有增加的时候,云存储的底层硬件也可以用几台NAS存储设备就可以解决,甚至云主机的形象都放在了NAS存储上。文件存储的广泛兼容性和易用性是这类存储的突出特点。但从性能上看,它低于SAN。NAS存储基本是以太网访问方式,普通千兆网络,NFS/CIFS协议。对象存储的概念是后来出现的。存储标准化组织SINA早在2004年就给出了定义,但早期多出现在超大规模系统中,因此不为大众所熟知,相关产品也一直不温不火。直到云计算和大数据的概念在全民大力推广下,才慢慢进入大众视野。前面提到的块存储和文件存储基本都是在专有局域网内部使用,而对象存储的优势场景是互联网或者公网,主要解决海量数据和海量并发访问的需求。基于互联网的应用是对象存储的主要适配(当然,这个条件也适用于云计算,基于互联网的应用最容易迁移到云端,因为在云这个词出现之前就已经在上面了),基本上成熟的公有云,不管是国内的还是国外的,都提供对象存储产品。对象存储常见的适配应用包括网盘、媒体娱乐、医疗PACS、气象、归档等数据量大但相对“冷数据”和离线处理的应用类型。这类应用个体数据量大,总量大,适合海量对象存储、易扩展的特点。网盘应用类似,数据量大,并发访问量大。值得单独列出一个项目来支持100,000级用户访问(这方面的扫盲想想12306)。归档应用只是数据量大的冷数据,并发访问的需求不那么突出。此外,一些基于移动终端的新兴应用也很适合。随着智能手机和移动互联网的普及,所谓的UGD(user-generateddata,photosandvideosofmobilephones)和用户数量非常具有挑战性。毕竟直接使用HTTPget/put就可以实现数据访问,这对移动应用还是有吸引力的。对象存储的访问通常是在互联网上,使用HTTP协议。性能方面,单看一个连接是不高的(还需要解决掉线、中断传输等可靠性问题)。主要优势是支持并发量和聚合性能带宽非常可观。从产品形态来看,块存储和文件存储都是成熟的产品,各种规格、形态的硬件已经让人眼花缭乱。但对象存储通常是一堆服务器或增强型服务器。毕竟这东西还是互联网行业广泛使用的,DIY的风格。在性能和容量方面,我做了一张图来对比三种存储。块存储就像一辆超级跑车。它不在乎它是否可以承载更多的人。它想要的是极速和高速下的稳定性和可靠性。各大厂商发布新品都要到新北环跑一圈。快记录,千方百计提高一两秒,7分钟内跑不出来,就看不到前三。(块存储容量不大,在TB量级,支持的应用和适用环境都比较专业(FC+Oracle),他们关心的是IOPS的性能值,厂商想用SPC-1做新产品,测试好会得意,测试不好会自动忽略。)文件存储就像一张收藏卡,适用于各种场合,可以容纳数据(数百条)TB),具有良好的相容性。只要你是一个文件,各种Cargo都可以塞进去,各种常见的系统都可以拉,不超过性能负载。标准POXIS接口,后门可装卸。货车也不挑路,不像块存储必须在轨道上行驶,普通的千兆道路是可以畅通无阻的。虽然速度没有块存储超跑快,但是跑80/100码还是很稳定的。对象存储就像一艘海运货轮,应对“真正的海量”,几十上百PB的数据,容器/容器(bucket)的单元编码整齐,里面装满了各种对象数据。一艘船可以处理100,000个客户发送的所有货物(数据)。根据键值(KeyVaule)记住清楚。发货速度慢,遇到一些网络风暴有时不稳定,但支持断点续传,最后还是可以安全发货的。对于大宗商品,尤其是非结构化数据,总体来说是最快最方便的。.在接入方式上,块存储通常通过光纤网络连接。服务器/小机配置FC光纤HBA卡,存储通过光纤交换机连接(IPSAN可通过千兆以太网与iSCSI客户端连接存储)。端作为逻辑卷(Volume)被访问。连接成功后,应用程序通过起始地址和偏移量的方式访问存储。但是NAS文件存储一般只要在局域网中就可以在千兆/百兆以太网环境下使用。接上网线,服务器端可以通过操作系统内置的NAS客户端,如NFS/CIFS/FTP客户端进行访问,挂载为本地文件夹存储。只要符合POXIS标准,应用程序就可以使用标准的open、seek、write/read、close这些方法来访问它。对象存储不关心网络,它的访问非常独特。只能访问和删除(put/get/delete),不能打开、修改和保存。修改后只能移除上传,覆盖原对象。(因为中间有不靠谱的网络,所以不保证你修改的时候不会掉线。所谓你在这,对象在那里,你爱的对象隔着山海。山海不能平。)另外,再说说分布式存储的问题,就是以上三种存储可以结合分布式的概念,成为分布式文件系统,分布式块存储,本质上是分布式对象存储。对象存储的定义将不同节点上的元数据管理和数据存储访问分开。多个节点应该处理多个并发访问。这自然是一种分布式存储产品。分布式文件系统有很多种,开源和闭源的产品也有几十种,每一种都有不同的应用领域。至于分布式块存储产品,产品比较少,很难做好。个人觉得这个产品形态有点不协调。分布式思维和块存储的设计追求其实是有冲突的。如前所述,块存储主要用于快速图。分布式分发肯定会是一个严重的障碍。由于都是分布式的,节点之间的通信必然会增加额外的负担。另外,CAP为了保持一致性会牺牲响应速度。好处是可扩展性。就像用链节连接超级跑车,哪里有可能跑高速?链条比车重,能当火车戴吗?不过文件存储本来就是集装箱卡车,大家联合起来装火车还是可行的。3、从应用的角度讨论了块存储、文件存储、对象存储的层次关系。让我们看一下这三种存储类型的一些技术细节。首先,让我们看一下系统级别的分布。我们从下往上看,最下面是硬盘,多个硬盘可以做成一个RAID组,不管是单硬盘还是RAID组,都可以做成一个PV,多个PV物理volumes被捏在一起组成一个VGvolumegroup,就是做一个大蛋糕。接下来,可以从蛋糕上切出很多LV逻辑卷,这是用户最熟悉的存储卷的层。到这个层次,数据一直以块的形式存在,此时提供的服务就是块存储服务。可以通过FC协议或者iSCSI协议访问卷,映射到本地主机端,成为裸设备。在主机端,数据库可以直接安装在上面,也可以格式化成文件系统,交给应用程序使用。此时是标准的SAN存储设备访问方式,块在网络之间传输。如果不急着访问,也可以在本地做一个文件系统,然后用NFS/CIFS协议挂载,映射到本地目录,直接作为文件访问。这成为NAS访问模式,文件在网络之间传输。.如果不使用NAS,将OSD服务器部署在本地文件系统上,将整个设备做成一个OSD。这样的节点再多几个,再加上必要的MDS节点,互联网另一端的应用程序就可以直接使用HTTP协议了。访问,成为对象存储的访问方式。当然,对象存储通常不需要专业的存储设备。之前的LV/VG/PV层也可以完全省略,直接在硬盘上搭建本地文件系统,然后做成OSD。这是对象存储的标准模式。存储硬件设备通常使用具有大磁盘的服务器。从系统层面来看,这三种存储是按照block->file->object的顺序往上走的。文件必须基于块来完成,无论是远程还是本地。对象存储的底层或后端存储通常基于本地文件系统(XFS/Ext4..)。这是一个更加合理流畅的结构。但是每个人都有很多想法,各种特产。我们一一来看:对象存储除了可以基于文件,还可以直接基于块,但是实现的很少。毕竟文件系统的工作你还是要做的。是的,自己实现一套元数据管理还是挺麻烦的。另外,对象存储还可以基于对象存储,这就有点尴尬了,转个身就好了,何必呢?但这还不是最奇怪的。最奇怪的是把对象存储放在了底层,也就是这两年流行的Ceph。Ceph是一个开源的分布式存储。相信大家都见过类似的架构图。为了便于分析,我还绘制了底层细节。底层是RADOS,是一个标准的对象存储。基于RADOS,Ceph可以提供三种存储服务:文件、块和对象。其中,RBD提供的块存储更有价值,毕竟开源的分布式块存储在市场上很少见(以前有牧羊犬,现在不流行)。当然它也通过CephFS模块和对应的私有Client来提供文件服务,这也是很多人认为Ceph是文件系统的原因。此外,其自带的原生对象存储可以通过RadosGW存储网关模块提供对象存储服务,并兼容对象存储的事实标准AmazonS3和Swift。所以可以看出,这其实是一个万事俱备的统一方案。以上大家或多或少都了解了,但是RADOS底层的细节可能会被忽略。RADOS也是一个标准的对象存储,也有MDS的元数据管理和OSD的数据存储,OSD本身可以基于一个Local文件系统,比如XFS/EXT4/Brtfs。之前的版本,你在部署Ceph的时候,需要为OSD创建数据目录吗?其实这一步已经在本地文件系统上操作过了(当前版本的Ceph可以直接使用硬盘)。现在让我们看看数据访问路径。你看Ceph的文件接口,从下到上依次是硬盘(块)->文件->对象->文件路径;如果看RBD的块存储服务,是经过硬盘(block)->file->object->block,也可能是硬盘(block)->object->block的路径;看对象接口(虽然用的不多),是通过硬盘(块)->文件->对象或者硬盘(块)->对象路径。虽然现在大家这么随便组合,但这三种存储方式还是有本质区别的。让我们回到计算机基础课程。从数据结构的角度来看,这三种存储方式有着本质的区别。块存储的数据结构是数组,而文件存储是二叉树(B、B-、B+、B*各种树),对象存储基本是哈希表。数组和二叉树老生常谈,不多说了,对象存储使用的哈希表也是经常听到的key-value(KeyVaule类型)存储的核心数据结构。每个对象找到一个UID(所谓的“Key”KEY),计算哈希值(所谓的“valueVaule”)并对应到目标。找了一个哈希表的例子如下:key-value对应关系简单粗暴。毕竟计算一个hash值是非常快的。这种扁平的组织形式可以做得很大,避免了二叉树的深度。对于真正海量的数据,存储和大规模访问都有很好的支持。所以不仅是对象存储,很多NoSQL分布式数据库都会用到它。顺带一提,这种NoSQL的出现多少打破了数据库和文件存储之间的天然屏障。本来关系型数据库是不会存太多数据的,现在像MongoDB这样的NoSQL支持直接把大的丢进去。“文档”数据,所以从应用的角度来看,有时对象存储、分布式文件系统、分布式数据库是在同一个表上进行比较,是一个mashup。当然,事实上,swift、ceph等几个开源对象存储都采用了一致性哈希,进阶版,最后变成一个环,首尾相接,避免了一个节点失效时海量数据迁移的尴尬。4、分布式存储在块存储、文件存储、对象存储中的应用效果软件定义的分布式块存储还处于发展阶段。目前在产品成熟度、高性能、高可靠性、功能等方面仍与传统块存储相比。差距较大,国内软件定义块存储厂商也在这方面进行改进和迎头赶上。文件存储也有其适合的应用场景。它使用起来简单快捷,并且易于与多个主机共享。它需要带宽、IOPS和延迟不敏感,但需要频繁更改数据(立即更改存储上的文件数据)。应用场景对比适合搭配文件存储使用。对象存储由于架构设计限制,适用于应用数据场景:只有全读全写的应用场景和海量数据场景。但是,对象存储非常适合需要频繁更改数据(即时更改存储上的数据)的应用场景。对象存储可以用来替代NAS存储的一些使用场景。另一种流行的做法是使用对象存储进行数据归档和备份。比如优酷、爱奇艺的视频(电影视频发布后,会一次性写入对象存储,不会有后续的数据修改操作。)或者微信的图片(图片只能上传、写入和删除。当你看到腾讯了吗?让你在线编辑照片。)这种类型的应用程序是对象存储的最爱。总的来说,我个人认为分布式对象存储是最成熟的软件定义分布式存储类型。现在很多对象存储厂商都支持多副本和EC校验码数据保护方式,通过EC校验码可以大大提高有效可用容量。做同类型的传统RAID存储容量利用率,大大降低成本。