分布式文件系统
分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接再本地节点上,
而是通过计算机网络与节点相连
分布式文件系统的设计基于客户机/服务器(C/S)模式
常用分布式文件系统
Lustre,Hadoop,FastDFS,Ceph,GlusterFS
Ceph简介
有官方(付费)的和开源的
Ceph 是一个分布式文件系统
具有高扩展、高可用、高性能的特点
Ceph 可以提供对象存储、块存储、文件系统存储
Ceph 可以提供PB级别的存储空间(PB-->TB-->-->GB)
软件定义存储(Software Defined Storage)作为存储,行业的一大发展趋势
官网:/start/intro
Ceph过往
Ceph最早起源于Sage就读博士期间的工作、成果于发表,并随后贡献给开源社区。经过多年的发展之后,已得到众多云计算和存储厂商的支持,成为应用最广泛的开源分布式存储平台。
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的文件系统,支持文件存储。
Ceph的功能模块
Ceph的核心组件包括Client客户端、MON监控服务、MDS元数据服务、OSD存储服务,各组件功能如下:
Client客户端:负责存储协议的接入,节点负载均衡
MON监控服务:负责监控整个集群,维护集群的健康状态,维护展示集群状态的各种图表,如OSD Map、Monitor Map、PG Map和CRUSH Map
MDS元数据服务:负责保存文件系统的元数据,管理目录结构
OSD存储服务:主要功能是存储数据、复制数据、平衡数据、恢复数据,以及与其它OSD间进行心跳检查等。一般情况下一块硬盘对应一个OSD。
3.Ceph的资源划分
Ceph采用crush算法,在大规模集群下,实现数据的快速、准确存放,同时能够在硬件故障或扩展硬件设备时,做到尽可能小的数据迁移,其原理如下:
当用户要将数据存储到Ceph集群时,数据先被分割成多个object,(每个object一个object id,大小可设置,默认是4MB),object是Ceph存储的最小存储单元。
由于object的数量很多,为了有效减少了Object到OSD的索引表、降低元数据的复杂度,使得写入和读取更加灵活,引入了pg(Placement Group ):PG用来管理object,每个object通过Hash,映射到某个pg中,一个pg可以包含多个object。
Pg再通过CRUSH计算,映射到osd中。如果是三副本的,则每个pg都会映射到三个osd,保证了数据的冗余。
4.Ceph的数据写入
Ceph数据的写入流程
数据通过负载均衡获得节点动态IP地址;
通过块、文件、对象协议将文件传输到节点上;
数据被分割成4M对象并取得对象ID;
对象ID通过HASH算法被分配到不同的PG;
不同的PG通过CRUSH算法被分配到不同的OSD
5.Ceph的特点
Ceph支持对象存储、块存储和文件存储服务,故 称为统一存储。
采用CRUSH算法,数据分布均衡,并行度高,不需要维护固定的元数据结构;
数据具有强一致,确保所有副本写入完成才返回确认,适合读多写少场景;
去中心化,MDS之间地位相同,无固定的中心节点
Ceph存在一些缺点:
去中心化的分布式解决方案,需要提前做好规划设计,对技术团队的要求能力比较高。
Ceph扩容时,由于其数据分布均衡的特性,会导致整个存储系统性能的下降。
GFS
GFS是google的分布式文件存储系统,是专为存储海量搜索数据而设计的,提出,是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加,如大文件的读写。注重大文件的持续稳定带宽,而不是单次读写的延迟。
1.GFS的主要架构
GFS 架构比较简单,一个 GFS 集群一般由一个 master 、多个 chunkserver 和多个 clients 组成。
在 GFS 中,所有文件被切分成若干个 chunk,每个 chunk 拥有唯一不变的标识(在 chunk 创建时,由 master 负责分配),所有 chunk 都实际存储在 chunkserver 的磁盘上。
为了容灾,每个 chunk 都会被复制到多个 chunkserve
2.GFS的功能模块
GFS client客户端:为应用提供API,与POSIX API类似。同时缓存从GFS master读取的元数据chunk信息;
GFS master元数据服务器:管理所有文件系统的元数据,包括命令空间(目录层级)、访问控制信息、文件到chunk的映射关系,chunk的位置等。同时 master 还管理系统范围内的各种活动,包括chunk 创建、复制、数据迁移、垃圾回收等;
GFS chunksever存储节点:用于所有 chunk的存储。一个文件被分割为多个大小固定的chunk(默认64M),每个chunk有全局唯一的chunk ID。
3.GFS的写入流程
Client 向 master 询问要修改的 chunk在哪个 chunkserver上,以及 该chunk 其他副本的位置信息。
Master 将Primary、secondary的相关信息返回给 client。
Client 将数据推送给 primary 和 secondary;。
当所有副本都确认收到数据后,client 发送写请求给 primary,primary 给不同 client 的操作分配序号,保证操作顺序执行。
Primary 把写请求发送到 secondary,secondary 按照 primary 分配的序号顺序执行所有操作
当 Secondary 执行完后回复 primary 执行结果。
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(Hadoop Distributed File System),是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统,是Hadoop的核心子项目,是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS),是GFS的一个简化和开源版本。
1.HDFS的主要架构
HDFS Client(客户端):从NameNode获取文件的位置信息,再从DataNode读取或者写入数据。此外,client在数据存储时,负责文件的分割;
NameNode(元数据节点):管理名称空间、数据块(Block)映射信息、配置副本策略、处理客户端读写请求;
DataNode(存储节点):负责执行实际的读写操作,存储实际的数据块,同一个数据块会被存储在多个DataNode上
Secondary NameNode:定期合并元数据,推送给NameNode,在紧急情况下,可辅助NameNode的HA恢复。
2.HDFS的特点(Vs GFS)
分块更大,每个数据块默认128MB;
不支持并发,同一时刻只允许一个写入者或追加者;
过程一致性,写入数据的传输顺序与最终写入顺序一致;
Master HA,2.X版本支持两个NameNode,(分别处于Active和Standby状态),故障切换时间一般几十秒到数分钟
3.HDFS适合的应用场景:
适用于大文件、大数据处理,处理数据达到 GB、TB、甚至PB级别的数据。
适合流式文件访问,一次写入,多次读取。
文件一旦写入不能修改,只能追加。
4.HDFS不适合的场景:
低延时数据访问。
小文件存储
并发写入、文件随机修改
Swift
Swift 最初是由Rackspace公司开发的分布式对象存储服务, 年贡献给 OpenStack 开源社区。作为其最初的核心子项目之一,为其 Nova 子项目提供虚机镜像存储服务。
1.Swift的主要架构
Swift 采用完全对称、面向资源的分布式系统架构设计,所有组件都可扩展,避免因单点失效而影响整个系统的可用性。
Swift 组件包括:
代理服务(Proxy Server):对外提供对象服务 API,转发请求至相应的账户、容器或对象服务
认证服务(Authentication Server):验证用户的身份信息,并获得一个访问令牌(Token)
缓存服务(Cache Server):缓存令牌,账户和容器信息,但不会缓存对象本身的数据
账户服务(Account Server):提供账户元数据和统计信息,并维护所含容器列表的服务
容器服务(Container Server):提供容器元数据和统计信息,并维护所含对象列表的服务
对象服务(Object Server):提供对象元数据和内容服务,每个对象会以文件存储在文件系统中
复制服务(Replicator):检测本地副本和远程副本是否一致,采用推式(Push)更新远程副本
更新服务(Updater):对象内容的更新
审计服务(Auditor):检查对象、容器和账户的完整性,如果发现错误,文件将被隔离
账户清理服务(Account Reaper):移除被标记为删除的账户,删除其所包含的所有容器和对象
2.Swift的数据模型
**Swift的数据模型采用层次结构,共设三层:**Account/Container/Object(即账户/容器/对象),每层节点数均没有限制,可以任意扩展。数据模型如下:
3.一致性散列函数
Swift是基于一致性散列技术,通过计算将对象均匀分布到虚拟空间的虚拟节点上,在增加或删除节点时可大大减少需移动的数据量;
为便于高效的移位操作,虚拟空间大小通常采用 2 n;通过独特的数据结构 Ring(环),再将虚拟节点映射到实际的物理存储设备上,完成寻址过程。如下图所示:
散列空间4 个字节(32为),虚拟节点数最大为232,如将散列结果右移 m 位,可产生 2(32-m)个虚拟节点,(如上图中所示,当m=29 时,可产生 8 个虚拟节点)。
4.环的数据结构
Swift为账户、容器和对象分别定义了的环。
环是为了将虚拟节点(分区)映射到一组物理存储设备上,并提供一定的冗余度而设计的,环的数据信息包括存储设备列表和设备信息、分区到设备的映射关系、计算分区号的位移(即上图中的m)。
账户、容器和对象的寻址过程。(以对象的寻址过程为例):
以对象的层次结构 account/container/object 作为键,采用 MD5 散列算法得到一个散列值;
对该散列值的前 4 个字节进行右移操作(右移m位),得到分区索引号;
在分区到设备映射表里,按照分区索引号,查找该对象所在分区对应的所有物理设备编号。如下图:
5.Swift的一致性设计
Swift 采用 Quorum 仲裁协议
定义:N:数据的副本总数;W:写操作被确认接受的副本数量;R:读操作的副本数量
强一致性:R+W>N, 就能保证对副本的读写操作会产生交集,从而保证可以读取到最新版本;
弱一致性:R+W<=N,读写操作的副本集合可能不产生交集,此时就可能会读到脏数据;
Swift 默认配置是N=3,W=2,R=2,即每个对象会存在 3 个副本,至少需要更新 2 个副本才算写成功;如果读到的2个数据存在不一致,则通过检测和复制协议来完成数据同步。
如R=1,就可能会读到脏数据,此时,通过牺牲一定的一致性,可提高读取速度,(而一致性可以通过后台的方式完成同步,从而保证数据的最终一致性)
Quorum 协议示例如下所示:
6.Swift特点
原生的对象存储,不支持实时的文件读写、编辑功能
完全对称架构,无主节点,无单点故障,易于大规模扩展,性能容量线性增长
数据实现最终一致性,不需要所有副本写入即可返回,读取数据时需要进行数据副本的校验
是OpenStack的子项目之一,适合云环境的部署
Swift的对象存储与Ceph提供的对象存储区别:客户端在访问对象存储系统服务时,Swift要求客户端必须访问Swift网关才能获得数据。而Ceph可以在每个存储节点上的OSD(对象存储设备)获取数据信息; 在数据一致性方面,Swift的数据是最终一致,而Ceph是始终跨集群强一致性)
五、 Lustre分布式存储
Lustre是基于Linux平台的开源集群(并行)文件系统,最早在1999年由皮特·布拉姆创建的集群文件系统公司(Cluster File Systems Inc.)开始研发,后由HP、Intel、Cluster File System和美国能源部联合开发,正式开源,主要用于HPC超算领域。
1、Lustre的主要架构
Lustre组件包括:
管理服务器(MGS):存放集群中所有Lustre文件系统的配置信息,Lustre客户通过联系MGS获取信息,可以与MDS共享存储空间
元数据服务器(MDS): 管理存储在MDT中的元数据,使存储在一个或多个MDT中的元数据可供Lustre客户端使用,每个MDS可管理一个或多个MDT。
元数据目标(MDT): MDS用于存储元数据(例如文件名,目录,权限和文件布局),一个MDT可用于多个MDS,但一次只能有一个MDS访问
对象存储服务器(OSS):为一个或多个本地OST提供文件I / O服务和网络请求处理, 通常,OSS服务于两个到八个OST
对象存储目标(OST):用户文件数据存储在一个或多个对象中,每个对象位于单独OST中
Lustre客户端:运行Lustre客户端软件的计算节点,可挂载Lustre文件系统。客户端软件包括一个管理客户端(MGC),一个元数据客户端(MDC)和多个对象存储客户端(OSC)。每个OSC对应于文件系统中的一个OST。
逻辑对象卷(LOV)通过聚合OSC以提供对所有OST的透明访问,逻辑元数据卷(LMV)通过聚合MDC提供一种对所有MDT透明的访问。
2、Lustre特点
支持数万个客户端系统,支持PB级存储容量,单个文件最大支持320TB容量
支持RDMA网络,大文件读写分片优化,多个OSS能获得更高的聚合带宽
缺少副本机制,存在单点故障。如果一个客户端或节点发生故障,存储在该节点上的数据在重新启动前将不可访问
适用高性能计算HPC领域,适用于大文件连续读写。
六、 主流分布式存储技术的比较
几种主流分布式存储技术的特点比较如下:
此外,根据分布式存储系统的设计理念,其软件和硬件解耦,分布式存储的许多功能,包括可靠性和性能增强都由软件提供,因此大家往往会认为底层硬件已不再重要。但事实往往并非如此,我们在进行分布式存储系统集成时,除考虑选用合适的分布式存储技术以外,还需考虑底层硬件的兼容性。一般而言,分布式存储系统的产品有三种形态:软硬件一体机、硬件OEM和软件+标准硬件,大家在选择时,需根据产品的成熟度、风险规避、运维要求等,结合自身的技术力量等,选择合适的产品形态。
OpenStack简介
OpenStack 是一个开源的 IaaS 实现,它由一些相互关联的子项目组成,主要包括计算、存储、网络。
由于以 Apache 协议发布,自 年项目成立以来,超过 200 个公司加入了OpenStack 项目,其中包括 AT&T、AMD、Cisco、Dell、IBM、Intel、Red Hat 等。
目前参与 OpenStack 项目的开发人员有 17,000+,来自 139 个国家,这一数字还在不断增长中。
OpenStack 兼容一部分 AWS 接口,同时为了提供更强大的功能,也提供OpenStack 风格的接口(RESTFul API)。
和其他开源 IaaS 相比,架构上松耦合、高可扩展、分布式、纯 Python实现,以及友好活跃的社区使其大受欢迎,每半年一次的开发峰会也吸引了来自全世界的开发者、供应商和客户。
OpenStack 的主要子项目有:
Compute(Nova)提供计算虚拟化服务,是 OpenStack 的核心,负责管理和创建虚拟机。它被设计成方便扩展,支持多种虚拟化技术,并且可以部署在标准硬件上。
Object Storage(Swift)提供对象存储服务,是一个分布式,可扩展,多副本的存储系统。
Block Storage(Cinder),提供块存储服务,为 OpenStack 的虚拟机提供持久的块级存储设备。支持多种存储后端,包括Ceph,EMC 等。
Networking(Neutron)提供网络虚拟化服务,是一个可拔插,可扩展,API 驱动的服务。
Dashboard 提供了一个图形控制台服务,让用户方便地访问,使用和维护 OpenStack中的资源。
Image(glance)提供镜像服务,它旨在发现,注册和交付虚拟机磁盘和镜像。支持多种后端。
Telemetry(Ceilometer)提供用量统计服务,通过它可以方便地实现 OpenStack计费功能。
Orchestration(Heat)整合了 OpenStack 中的众多组件,类似 AWS 的 CloudFormation,让用户能够通过模板来管理资源。
Database(Trove)基于 OpenStack 构建的 database-as-a-service。
通常构建企业私有云,使用Nova、Glance、Keystone、Neutron 就可基本完成私有云IAAS搭建。近几年流行PAAS云服务,一般对业务系统Docker化,使用容器编排构建容器云。容器云可独立直接部署在物理机之上,也可构建在openstack私有云服务IAAS之上。