主流分布式存储技术架构对比分析.docx

主流分布式存储技术架构对比分析.docx

《主流分布式存储技术架构对比分析.docx》由会员分享，可在线阅读，更多相关《主流分布式存储技术架构对比分析.docx（18页珍藏版）》请在冰豆网上搜索。

主流分布式存储技术架构对比分析

主流分布式存储技术架构对比分析

存储根据其类型，可分为块存储，对象存储和文件存储。

在主流的分布式存储技术中，HDFS/GPFS/GFS属于文件存储，Swift属于对象存储，而Ceph可支持块存储、对象存储和文件存储，故称为统一存储。

一、Ceph

Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。

经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。

Ceph根据场景可分为对象存储、块设备存储和文件存储。

Ceph相比其它分布式存储技术，其优势点在于：

它不单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡。

同时，由于采用了CRUSH、HASH等算法，使得它不存在传统的单点故障，且随着规模的扩大，性能并不会受到影响。

1.Ceph的主要架构

Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终存储用户数据。

RADOS系统主要由两部分组成，分别是OSD和Monitor。

RADOS之上是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。

基于LIBRADOS层开发的有三种接口，分别是RADOSGW、librbd和MDS。

RADOSGW是一套基于当前流行的RESTFUL协议的网关，支持对象存储，兼容S3和Swift。

librbd提供分布式的块存储设备接口，支持块存储。

MDS提供兼容POSIX的文件系统，支持文件存储。

2.Ceph的功能模块

Ceph的核心组件包括Client客户端、MON监控服务、MDS元数据服务、OSD存储服务，各组件功能如下：

Client客户端：

负责存储协议的接入，节点负载均衡

MON监控服务：

负责监控整个集群，维护集群的健康状态，维护展示集群状态的各种图表，如OSDMap、MonitorMap、PGMap和CRUSHMap

MDS元数据服务：

负责保存文件系统的元数据，管理目录结构

OSD存储服务：

主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其它OSD间进行心跳检查等。

一般情况下一块硬盘对应一个OSD。

3.Ceph的资源划分

Ceph采用crush算法，在大规模集群下，实现数据的快速、准确存放，同时能够在硬件故障或扩展硬件设备时，做到尽可能小的数据迁移，其原理如下：

当用户要将数据存储到Ceph集群时，数据先被分割成多个object，（每个object一个objectid，大小可设置，默认是4MB），object是Ceph存储的最小存储单元。

由于object的数量很多，为了有效减少了Object到OSD的索引表、降低元数据的复杂度，使得写入和读取更加灵活，引入了pg（PlacementGroup）：

PG用来管理object，每个object通过Hash，映射到某个pg中，一个pg可以包含多个object。

Pg再通过CRUSH计算，映射到osd中。

如果是三副本的，则每个pg都会映射到三个osd，保证了数据的冗余。

4.Ceph的数据写入

Ceph数据的写入流程

1）数据通过负载均衡获得节点动态IP地址；

2）通过块、文件、对象协议将文件传输到节点上；

3）数据被分割成4M对象并取得对象ID；

4）对象ID通过HASH算法被分配到不同的PG；

5）不同的PG通过CRUSH算法被分配到不同的OSD

5.Ceph的特点

Ceph支持对象存储、块存储和文件存储服务，故称为统一存储。

采用CRUSH算法，数据分布均衡，并行度高，不需要维护固定的元数据结构；

数据具有强一致，确保所有副本写入完成才返回确认，适合读多写少场景；

去中心化，MDS之间地位相同，无固定的中心节点

Ceph存在一些缺点：

去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。

Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。

二、GFS

GFS是google的分布式文件存储系统，是专为存储海量搜索数据而设计的，2003年提出，是闭源的分布式文件系统。

适用于大量的顺序读取和顺序追加，如大文件的读写。

注重大文件的持续稳定带宽，而不是单次读写的延迟。

1.GFS的主要架构

GFS架构比较简单，一个GFS集群一般由一个master、多个chunkserver和多个clients组成。

在GFS中，所有文件被切分成若干个chunk，每个chunk拥有唯一不变的标识（在chunk创建时，由master负责分配），所有chunk都实际存储在chunkserver的磁盘上。

为了容灾，每个chunk都会被复制到多个chunkserve

2.GFS的功能模块

GFSclient客户端：

为应用提供API，与POSIXAPI类似。

同时缓存从GFSmaster读取的元数据chunk信息；

GFSmaster元数据服务器：

管理所有文件系统的元数据，包括命令空间（目录层级）、访问控制信息、文件到chunk的映射关系，chunk的位置等。

同时master还管理系统范围内的各种活动，包括chunk创建、复制、数据迁移、垃圾回收等；

GFSchunksever存储节点：

用于所有chunk的存储。

一个文件被分割为多个大小固定的chunk（默认64M），每个chunk有全局唯一的chunkID。

3.GFS的写入流程

1）Client向master询问要修改的chunk在哪个chunkserver上，以及该chunk其他副本的位置信息；

2）Master将Primary、secondary的相关信息返回给client；

3）Client将数据推送给primary和secondary；

4）当所有副本都确认收到数据后，client发送写请求给primary，primary给不同client的操作分配序号，保证操作顺序执行；

5）Primary把写请求发送到secondary，secondary按照primary分配的序号顺序执行所有操作；

6）当Secondary执行完后回复primary执行结果；

7）Primary回复client执行结果。

由上述可见，GFS在进行写数据时，有如下特点：

GFS在数据读写时，数据流与控制流是分开的，并通过租约机制，在跨多个副本的数据写入中,保障顺序一致性；

Master将chunk租约发放给其中一个副本，这个副本称为主副本，由主副本确定chunk的写入顺序，次副本则遵守这个顺序，这样就保障了全局顺序一致性；

Master返回客户端主副本和次副本的位置信息，客户端缓存这些信息以备将来使用，只有当主副本所在chunkserver不可用或返回租约过期了，客户端才需要再次联系Master；

GFS采用链式推送，以最大化利用每个机器的网络带宽，避免网络瓶颈和高延迟连接，最小化推送延迟；

GFS使用TCP流式传输数据，以最小化延迟。

4.GFS特点

适合大文件场景的应用，特别是针对GB级别的大文件，适用于数据访问延时不敏感的搜索类业务

中心化架构，只有1个master处于active状态

缓存和预取，通过在client端缓存元数据，尽量减少与master的交互，通过文件的预读取来提升并发性能

高可靠性，master需要持久化的数据会通过操作日志与checkpoint的方式存放多份，故障后master会自动切换重启。

三、HDFS

HDFS（HadoopDistributedFileSystem），是一个适合运行在通用硬件（commodityhardware）上的分布式文件系统，是Hadoop的核心子项目，是基于流数据模式访问和处理超大文件的需求而开发的。

该系统仿效了谷歌文件系统（GFS），是GFS的一个简化和开源版本。

1.HDFS的主要架构

HDFSClient（客户端）：

从NameNode获取文件的位置信息，再从DataNode读取或者写入数据。

此外，client在数据存储时，负责文件的分割；

NameNode（元数据节点）：

管理名称空间、数据块（Block）映射信息、配置副本策略、处理客户端读写请求；

DataNode（存储节点）：

负责执行实际的读写操作，存储实际的数据块,同一个数据块会被存储在多个DataNode上；

SecondaryNameNode：

定期合并元数据，推送给NameNode，在紧急情况下，可辅助NameNode的HA恢复。

2.HDFS的特点（vsGFS）

分块更大，每个数据块默认128MB；

不支持并发，同一时刻只允许一个写入者或追加者；

过程一致性,写入数据的传输顺序与最终写入顺序一致；

MasterHA，2.X版本支持两个NameNode，（分别处于Active和Standby状态），故障切换时间一般几十秒到数分钟

3.HDFS适合的应用场景

适用于大文件、大数据处理，处理数据达到GB、TB、甚至PB级别的数据。

适合流式文件访问，一次写入，多次读取。

文件一旦写入不能修改，只能追加。

4.HDFS不适合的场景：

低延时数据访问。

小文件存储

并发写入、文件随机修改

四、Swift

Swift最初是由Rackspace公司开发的分布式对象存储服务，2010年贡献给OpenStack开源社区。

作为其最初的核心子项目之一，为其Nova子项目提供虚机镜像存储服务。

1.Swift的主要架构

Swift采用完全对称、面向资源的分布式系统架构设计，所有组件都可扩展，避免因单点失效而影响整个系统的可用性。

Swift组件包括

代理服务（ProxyServer）：

对外提供对象服务API，转发请求至相应的账户、容器或对象服务

认证服务（AuthenticationServer）：

验证用户的身份信息，并获得一个访问令牌（Token）

缓存服务（CacheServer）：

缓存令牌，账户和容器信息，但不会缓存对象本身的数据

账户服务（AccountServer）：

提供账户元数据和统计信息，并维护所含容器列表的服务

容器服务（ContainerServer）：

提供容器元数据和统计信息，并维护所含对象列表的服务

对象服务（ObjectServer）：

提供对象元数据和内容服务，每个对象会以文件存储在文件系统中

复制服务（Replicator）：

检测本地副本和远程副本是否一致，采用推式（Push）更新远程副本

更新服务（Updater）：

对象内容的更新

审计服务（Auditor）：

检查对象、容器和账户的完整性，如果发现错误，文件将被隔离

账户清理服务（AccountReaper）：

移除被标记为删除的账户，删除其所包含的所有容器和对象

2.Swift的数据模型

Swift的数据模型采用层次结构，共设三层：

Account/Container/Object（即账户/容器/对象），每层节点数均没有限制，可以任意扩展。

数据模型如下：

3.一致性散列函数

Swift是基于一致性散列技术，通过计算将对象均匀分布到虚拟空间的虚拟节点