对象存储与块存储文件存储等对比

Posted 2020-12-03 nucdy

看到 一篇文档， 讲 对象存储， 好奇，搜索文章，摘抄,学习记录 ！

 

背景：

传统存储在面对海量非结构化数据时，在存储、分享与容灾上面临很大的挑战，主要表现在以下几个方面：传统存储并非为非结构化内容设计或优化、成本过高、并非PB级的扩展、不支持永远在线、专有的一体机设备等等，非结构化数据以每年60%～80%的速率增长，从而可扩展性变成了最迫切的需求。

传统存储在面对海量非结构化数据时，在存储、分享与容灾上面临很大的挑战，主要表现在以下几个方面：传统存储并非为非结构化内容设计或优化、成本过高、并非PB级的扩展、不支持永远在线、专有的一体机设备等等，非结构化数据以每年60%～80%的速率增长，从而可扩展性变成了最迫切的需求。

对象存储是无层次结构的数据存储方法，通常用于云中。不同于其他数据存储方法，基于对象的存储不使用目录树。各个单独的数据（对象）单元存在于存储池中的同一级别。每个对象都有唯一的识别名称，供应用进行检索。

 

我们一下探讨块存储、文件存储、对象存储几种方式的对比，以及对象存储Cleversafe的技术原理及应用。

1、块存储、文件存储、对象存储几种方式的对比？

块存储指在一个RAID（独立磁盘冗余阵列）集中，一个控制器加入一组磁盘驱动器，然后提供固定大小的RAID块作为LUN（逻辑单元号）的卷。

接着块存储会采用映射的方式将这几个逻辑盘映射给主机，主机上面的操作系统会识别到有5块硬盘，但是操作系统是区分不出到底是逻辑还是物理的，它一概就认为只是5块裸的物理硬盘而已，跟直接拿一块物理硬盘挂载到操作系统没有区别的，至少操作系统感知上没有区别。

此种方式下，操作系统还需要对挂载的裸硬盘进行分区、格式化后，才能使用，与平常主机内置硬盘的方式完全无异。

优点：

1、 这种方式的好处当然是因为通过了Raid与LVM等手段，对数据提供了保护。

2、 另外也可以将多块廉价的硬盘组合起来，成为一个大容量的逻辑盘对外提供服务，提高了容量。

3、 写入数据的时候，由于是多块磁盘组合出来的逻辑盘，所以几块磁盘可以并行写入的，提升了读写效率。

4、 很多时候块存储采用SAN架构组网，传输速率以及封装协议的原因，使得传输速度与读写速率得到提升。

缺点：

1、采用SAN架构组网时，需要额外为主机购买光纤通道卡，还要买光纤交换机，造价成本高。

2、主机之间的数据无法共享，在服务器不做集群的情况下，块存储裸盘映射给主机，再格式化使用后，对于主机来说相当于本地盘，那么主机A的本地盘根本不能给主机B去使用，无法共享数据。

3、不利于不同操作系统主机间的数据共享：另外一个原因是因为操作系统使用不同的文件系统，格式化完之后，不同文件系统间的数据是共享不了的。例如一台装了WIN7/XP，文件系统是FAT32/NTFS，而Linux是EXT4，EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘，插进Linux的笔记本，根本无法识别出来。所以不利于文件共享。

文件存储：为了克服块存储文件无法共享的问题，所以有了文件存储。文件存储也有软硬一体化的设备，但是其实普通拿一台服务器/笔记本，只要装上合适的操作系统与软件，就可以架设FTP与NFS服务了，架上该类服务之后的服务器，就是文件存储的一种了。

主机A可以直接对文件存储进行文件的上传下载，与块存储不同，主机A是不需要再对文件存储进行格式化的，因为文件管理功能已经由文件存储自己搞定了。

优点：

1、造价交低：随便一台机器就可以了，另外普通以太网就可以，根本不需要专用的SAN网络，所以造价低。

2、方便文件共享：例如主机A（WIN7，NTFS文件系统），主机B（Linux，EXT4文件系统），想互拷一部电影，本来不行。加了个主机C（NFS服务器），然后可以先A拷到C，再C拷到B就OK了。

缺点：

读写速率低，传输速率慢：以太网，上传下载速度较慢，另外所有读写都要1台服务器里面的硬盘来承担，相比起磁盘阵列动不动就几十上百块硬盘同时读写，速率慢了许多。

企业级的NAS存储采用RAID技术提升了数据的可靠性和读写速率，同时采用万兆光纤接口提升了网络传输速率，适合于中小规模的医院用于PACS系统非结构化数据的存取，当数据量达到PB级别时NAS机头会出现瓶颈。下图是块存储与文件存储的对比图：

对象存储：内置大容量硬盘的分布式服务器是对象存储的典型设备，对象存储最常用的方案，就是多台服务器内置大容量硬盘，再装上对象存储软件，然后再额外配置几台服务作为管理节点，安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。

之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否实现即读写快又利 于共享的目的呢？于是就有了对象存储。

首先，一个文件包含了属性（术语叫metadata，元数据，例如该文件的大小、修改时间、存储路径等）以及内容（以下简称数据）。

以往像FAT32这种文件系统，是直接将一份文件的数据与metadata一起存储的，存储过程先将文件按照文件系统的最小块大小来打散（如4M的文件，假设文件系统要求一个块4K，那么就将文件打散成为1000个小块），再写进硬盘里面，过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址，然后一直这样顺序地按图索骥，最后完成整份文件的所有块的读取。

这种情况下读写速率很慢，因为就算你有100个机械手臂在读写，但是由于你只有读取到第一个块，才能知道下一个块在哪里，其实相当于只能有1个机械手臂在实际工作。

而对象存储则将元数据独立了出来，控制节点叫元数据服务器（服务器+对象存储管理软件），里面主要负责存储对象的属性（主要是对象的数据被打散存放到了那几台分布式服务器中的信息），而其他负责存储数据的分布式服务器叫做OSD，主要负责存储文件的数据部分。当用户访问对象，会先访问元数据服务器，元数据服务器只负责反馈对象存储在哪些OSD，假设反馈文件A存储在B、C、D三台OSD，那么用户就会再次直接访问3台OSD服务器去读取数据。

这时候由于是3台OSD同时对外传输数据，所以传输的速度就加快了。当OSD服务器数量越多，这种读写速度的提升就越大，通过此种方式，实现了读写快的目的。

另一方面，对象存储软件是有专门的文件系统的，所以OSD对外又相当于文件服务器，那么就不存在文件共享方面的困难了，也解决了文件共享方面的问题。

所以对象存储的出现，很好地结合了块存储与文件存储的优点。

为什么对象存储兼具块存储与文件存储的好处，还要使用块存储或文件存储呢？

1、有一类应用是需要存储直接裸盘映射的，例如数据库。因为数据库需要存储裸盘映射给自己后，再根据自己的数据库文件系统来对裸盘进行格式化的，所以是不能够采用其他已经被格式化为某种文件系统的存储的。此类应用更适合使用块存储。

2、对象存储的成本比起普通的文件存储还是较高，需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量，只是为了做文件共享的时候，直接用文件存储的形式好了，性价比高。

对象存储简介：

对象存储的出现就是为解决了存储海量大数据的问题。比如存储万亿的视频、图片，照片等。比如进行海量的数据归档，数据备份等。对象存储可以存储海量非结构化数据，然后进行大数据分析。

对象存储其采用key-volume的扁平化存储架构设计，使用简单，调用API就能进行数据存储和读取。可以存储海量数据，这点传统存储和NAS就没辙。在海量数据场景中你只能选择对象存储。如果传统SAN存储是跑车，NAS是货车，那么对象存储就是万亿吨海上集装箱大油轮。

2、对象存储Cleversafe与Ceph的对比优势？

Ceph并不是开源对象存储最好的选择，Ceph是个统一存储，有分布式块，文件，对象三种存储接口，比较全，这是它比较受关注的原因。单独来看底层的对象存储Rados，在开发者社区中口碑并不是很好，存在着诸多问题。

如果是选择厂商的SDS方案，如果是基于Ceph做的（国内不少厂商），其实这个阶段成熟与否还不好说，毕竟这项目社区里参与者很多，时间也不长，所谓成熟也就是有一部分坑能填上吧。前面说的社区版本迭代跟不跟的问题也还是一样存在的。

一个开源项目能不能生产使用很多时候并不取决于项目本身，同时使用者对于整个生产系统和开源项目的理解占了相当大比例。当然，也跟项目的阶段以及整个生态息息相关。

就使用 Ceph 而言，如果是一些无害环境，基本上也不会发现啥问题。当只要是需要保证性能和可用性的情况下，用户通常都要经历长时间的运维和解决问题的磨练。特别是眼下 Ceph 迭代较快，问题解决方式有限，很多时候都要依赖开发者才能解决。当然，如果没碰到问题当然万事大吉。

好一些的做法是在一些开发测试环境先使用某一个版本至少半年以上，尝试在保证一些性能以及数据可用性基础上运维。半年之后，自然会对这个问题有更深理解。

我们如果把对象存储部署在一个相对快的局域网环境内，那么这个对象存储也就兼具了NAS的高速基因，这时，一个对象存储也就在某种程度上，可以演变为 一个相对快速的存储，这也是为什么ceph可以兼具对象存储、块存储、文件存储的原因。当然，这种“变味”的对象存储也就不具备全国乃至全球分布式带来的超高可靠性了。

IBM Cleversafe具有以下特性：

1、可扩展性，多家100PB以上的客户，扩展至EB以上的无共享架构。

2、安全性，零接触、运营商级别的安全性且内置加密功能。

3、可管理性，每名管理员可管理25PB数据，零宕机时间。

4、可用性，提供9个9的可靠性，6个9的可用性。

5、经济效益，消除复制、镜像和DR成本，成本降低80%，软件解决方案可在任何供应商的x86硬件上运行。

3、对象存储适用的场景有哪些？

对象存储主要面对与非结构化数据的增长需求。对应于邮件，影像，日志文件等的备份，归档，存取，NAS场景都非常适合。

医疗行业的PACS系统，金融行业的后督系统，票据系统，以及未来的双录需求，都是对象存储可以一展拳脚的领域。

4、对象存储Cleversafe与传统存储高可用性对比有哪些优势？

传统存储系统当面对超过PB级别的存储需求是，性能会急速下降，而Cleversafe依据其特有的优化，能够使得系统得到大规模扩展性的同时，保证性能。

采用传统的存储在RAID6架构下1PB的原始数据要占用1.2PB的存储空间，为了实现数据安全做本地镜像和同城复本后数据要占用3.6PB（1.2*3）的存储空间，那么膨胀因子就是3倍，采用IBM Cleversafe对象存储1PB的原始数据要占用1.7PB的存储空间， Cleversafe对象存储使用1.7倍的膨胀因子就可以实现建设与RAID6相同或是还要高可靠的存储系统， Cleversafe对象存储占用更少的磁盘，占用更少的机架，节约机房空间，降低了运营成本，降低了运维管理的难度，无需其它软件就可以实现高可靠性和高可用性。

5、对象存储Cleversafe纠删码技术工作原理分析

IBM Cleversafe对象存储使用纠删码技术实现存储系统的高可靠和高可用，纠删码技术首先对原始数据进行分段（每段4M），之后对一个分段进行切片，例如一个分段切7片，之后通过ECC校验算法变换为12片，这样膨胀因子就是1.7，1PB的原始数据就占用了1.7PB的存储空间，这1.7PB的存储空间由12个切片组成，把这12个切片均匀的部署在多个站点的每一台服务器中，例如在三个站点每个站点部署4台服务器，这样在这三个站点中只要有7台服务器是正常运行的，数据就是完好的可以正常读取，可以避免服务器硬件故障或断电，网络故障，甚至1个站点故障都不会影响数据的可靠性和可用性，任何一个站点的任意一台服务器硬盘损坏后，只需插入一块新硬盘而无需做RAID就可以正常使用了。

6、开源存储GlusterFS适用于哪些非结构数据存储场景？

GlusterFS 作为一种开源分布式存储组件，具有非常强大的扩展能力，同时也提供了非常丰富的卷类型，能够轻松实现PB级的数据存储。

 

 

关于Ceph 这个框架，我也摘抄一下：

 

Ceph	MooseFS(MFS)	GlusterFS	Lustre
Metadata server	单个MDS。存在单点故障和瓶颈。	多个MDS，不存在单点故障和瓶颈。MDS可以扩展，不存在瓶颈。	无，不存在单点故障。靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。	双MDS(互相备份)。MDS不可以扩展，存在瓶颈。
FUSE	支持	支持	支持	支持
访问接口	POSIX	POSIX	POSIX	POSIX/MPI
文件分布/数据分布	文件被分片，数据块保存在不同的存储服务器上。	文件被分片，每个数据块是一个对象。对象保存在不同的存储服务器上。	Cluster Translators(GlusterFS集群存储的核心)包括AFR、DHT（和Stripe三种类型。 AFR相当于RAID1，每个文件都被复制到多个存储节点上。Stripe相当于RAID0，文件被分片，数据被条带化到各个存储节点上。 Translators可以组合，即AFR和stripe可以组成RAID10，实现高性能和高可用。	可以把大文件分片并以类似RAID0的方式分散存储在多个存储节点上。
冗余保护/副本	多副本	多副本	镜像	无
数据可靠性	由数据的多副本提供可靠性。	由数据的多副本提供可靠性。	由镜像提供可靠性。	由存储节点上的RAID1或RAID5/6提供可靠性。假如存储节点失效，则数据不可用。
备份				提供备份工具。支持远程备份。
故障恢复	手动恢复	当节点失效时，自动迁移数据、重新复制副本。	当节点、硬件、磁盘、网络发生故障时，系统会自动处理这些故障，管理员不需介入。	无
扩展性	增加存储服务器，可以提高容量和文件操作性能。但是由于不能增加MDS，因此元数据操作性能不能提高，是整个系统的瓶颈。	可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展。	容量可扩展。	可增加存储节点，提高容量可文件操作性能，但是由于不能增加MDS，因此元数据操作性能不能提高，是整个系统的瓶颈。
安装/部署	简单	简单	简单	复杂。而且Lustre严重依赖内核，需要重新编译内核。
开发语言	C	C++	C	C
适合场景	大量小文件读写	小文件	适合大文件。 对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS并没有在I/O方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是瓶颈，数据分布和并行性也无法充分发挥作用。因此，GlusterFS的小文件性能还存在很大优化空间。	大文件读写
产品级别	小型	中型	中型	重型
应用	国内较多	无	较多用户使用	HPC领域。
优缺点	实施简单，但是存在单点故障。	不稳定，目前还在实验阶段，不适合于生产环境。	无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)。具有线性横向扩展能力。   由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存。 但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点。因此不建议使用较深的路径。	很成熟、很庞大。

 

 

参考：http://www.cnblogs.com/caoxiaojian/

参考：http://stor.51cto.com/art/201712/561063.htm