分布式文件系统Ceph调研

By | 03月14日
Advertisement

分布式文件系统Ceph调研1 – RADOS

Ceph是加州大学Santa Cruz分校的Sage Weil(DreamHost的联合创始人)专为博士论文设计的新一代自由软件分布式文件系统。自2007年毕业之后,Sage开始全职投入到Ceph开 发之中,使其能适用于生产环境。Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统,使数据能容错和无缝的复制。2010年3 月,Linus Torvalds将Ceph client合并到内 核2.6.34中。

Ceph中有很多在分布式系统领域非常新颖的技术点,对解决分布式文件系统中一些常见的问题的研究非常有指导意义。所以值得研究。

RADOS简介

1 RADOS概述

RADOS (Reliable, Autonomic Distributed Object Store) 是Ceph的核心之一,作为Ceph分布式文件系统的一个子项目,特别为Ceph的需求设计,能够在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统。事实上,RADOS也可以单独作为一种分布式数据存储系统,给适合相应需求的分布式文件系统提供数据存储服务。

2 RADOS架构简介

RADOS系统主要由两个部分组成(如图1所示):

1.由数目可变的大规模OSDs(Object Storage Devices)组成的机群,负责存储所有的Objects数据;

2.由少量Monitors组成的强耦合、小规模机群,负责管理Cluster Map,其中Cluster Map是整个RADOS系统的关键数据结构,管理机群中的所有成员、关系、属性等信息以及数据的分发。

分布式文件系统Ceph调研

图1 RADOS系统架构图示

对于RADOS系统,节点组织管理和数据分发策略均有内部的Monitors全权负责,所以,从Clients角度设计相对比较简单,它给应用提供的仅为简单的存储接口。

3 RADOS详细介绍

3.1 扩展机群

1.Cluster Map

存储机群的管理,唯一的途径是Cluster Map通过对Monitor Cluster操作完成。Cluster Map是整个RADOS系统的核心数据结构,其中指定了机群中的OSDs信息和所有数据的分布情况。所有涉及到RADOS系统的Storage节点和Clients都有最新epoch的Cluster Map副本。因为Cluster Map的特殊性,Client向上提供了非常简单的接口实现将整个存储机群抽象为单一的逻辑对象存储结构。

Cluster Map的更新由OSD的状态变化或者其他事件造成数据层的变化驱动,每一次Cluster Map更新都需要将map epoch增加,map epoch使Cluster Map在所有节点上的副本都保持同步,同时,map epoch可以使一些过期的Cluster Map能够通过通信对等节点及时更新。

在大规模的分布式系统中,OSDs的failures/recoveries是常见的,所以,Cluster Map的更新就比较频繁,如果将整个Cluster Map进行分发或广播显然会造成资源的浪费,RADOS采用分发incremental map的策略避免资源浪费,其中incremental map仅包含了两个连续epoch之间Cluster Map的增量信息。

2.Data Placement

数据迁移:当有新的储存设备加入时,机群上的数据会随机的选出一部分迁移到新的设备上,维持现有存储结构的平衡。

数据分发:通过两个阶段的计算得到合适的Object的存储位置。如图2所示。

分布式文件系统Ceph调研

图2 数据分发图示

1.Object到PG的映射。PG (Placement Group)是Objects的逻辑集合。相同PG里的Object会被系统分发到相同的OSDs集合中。由Object的名称通过Hash算法得到的结果结合其他一些修正参数可以得到Object所对应的PG。

2.RADOS系统根据根据Cluster Map将PGs分配到相应的OSDs。这组OSDs正是PG中的Objects数据的存储位置。RADOS采用CRUSH算法实现了一种稳定、伪随机的hash算法。CRUSH实现了平衡的和与容量相关的数据分配策略。CRUSH得到的一组OSDs还不是最终的数据存储目标,需要经过初步的filter,因为对于大规模的分布式机群,宕机等原因使得部分节点可能失效,filter就是为过滤这些节点,如果过滤后存储目标不能满足使用则阻塞当前操作。

3.Device State

Cluster Map中关于Device State的描述见下表所示。

表1 Device State描述

in out
assigned PGs not assigned PGs
up online & reachable active online & idle
down unreachable unreachable & not remapped failed

4.Map propagate

Cluster Map在OSD之间的更新是通过一种抢占式的方法进行。Cluster Map epoch的差异只有在两个通信实体之间有意义,两个通信实体在进行信息交换之前都需要交换epoch,保证Cluster Map的同步。这一属性使得Cluster Map在通信实体内部之间的更新分担了全局的Cluster Map分发压力。

每一个OSD都会缓存最近Cluster Map和到当前时刻的所有incremental map信息,OSD的所有message都会嵌入incremental map,同时侦听与其通信的peer的Cluster Map epoch。当从peer收到的message中发现其epoch是过期的,OSD share相对peer来说的incremental map,使通信的peers都保持同步;同样的,当从peer收到message中发现本地epoch过期,从其嵌入到message中的incremental map中分析得到相对本地的incremental map然后更新,保持同步。

不是同一个通信对等方的两个OSD之间的epoch差异,不影响同步。

3.2 智能存储

1Replication

RADOS实现了三种不同的Replication方案,见下图3示:

分布式文件系统Ceph调研

图3 RADOS实现的三种replication方案

Primary-copy:读写操作均在primary OSD上进行,并行更新replicas;

Chain:链式读写,读写分离;

Spaly:Primary-copy和Chain的折中方案:并行更新replicas和读写分离。

2Consistency

一致性问题主要有两个方面,分别是Update和Read:

  1. Update:在RADOS系统中所有Message都嵌入了发送端的map epoch协调机群的一致性。
  2. Read:为避免部分OSD失效导致数据不能从该OSD读需要转向新的OSD,但是read operation的发起方还没有该OSD的失效信息的问题,同一个PG所在的OSDs需要实时交换Heartbeat。

3Failure Detection

错误检测:RADOS采取异步、有序的点对点Heartbeat。(此处的错误检测是OSDs自身检测)

4Data Migration & Failure Recovery

由于设备失效、机群扩展、错误恢复造成的Cluster Map更新使得PG到OSDs的对应关系发生了变化,一旦Cluster Map发生变化,相应的OSDs上的数据也需要做相应的调整。

数据的移植和数据恢复都是由Primary OSD负责统一完成。

(Data Migration & Failure Recovery具体方法待续)

3.3 Monitors

Monitors是Cluster Map主备份存储目标,所有其他位置上的Cluster Map最初都是从Monitors请求得到。Monitors通过对Cluster Map的周期更新升级实现存储机群的管理。

Monitor的工作分两个阶段:

1.首先在多个Monitors中选举Leader,之后Leader向所有Monitors请求Map Epoch,Monitors周期性向Leader汇报结果并告知其活跃(Active Monitor),Leader统计Quorum。这阶段的意义是保证所有的Monitors的Map Epoch都是最新的,通过Incremental updates对已失效的Cluster Map进行更新。

2.Leader周期向每一个Active Monitor授权许可提供分发Cluster Map副本给OSDs和Clients的服务。当授权失效但Leader仍没有重新分发认为Leader died,此时重回第一阶段进行Leader重选;当Active Monitor没有周期向Leader反馈ACK则认为有Monitor died,重回第一阶段进行Leader选举并更新Quorum。Leader周期分发Lease和Active Monitor周期反馈ACK的另外一个作用是同步Monitors的Cluster Map。Active Monitor收到Update请求时,首先验证当前的Epoch是否为最新,如果不是,更新后向上汇报到Leader,Leader分发给所有的Monitors,同时回收授权,重新开始新一轮的Leader选举到Cluster Map服务。

通常Monitor的负载比较小:OSDs上的Cluster Map更新通过OSDs之间的机制实现;OSDs的状态变化比较罕见不会对Monitors的负载造成影响。但是一些特殊情况可能会对Monitors负载带来影响,比如:同时有n OSDs failed,每一个OSD store m个PGs,此时会形成m×n个failure report到达Monitors,对于规模较大的机群这样的数据量比较大。为避免这种情况给Monitor带来的负载压力,OSDs采用伪随机的时间间隔交错安排failure检测(此处是从OSDs到Monitor的检测)向上汇报,另外根据Monitors的并行化和负载均衡分配的特点,扩展Monitors是解决Monitors的负载压力的另一措施。

4 总结

与传统的分布式数据存储不同,RADOS最大的特点是:

1.将文件映射到Objects后利用Cluster Map通过CRUSH计算而不是查找表方式定位文件数据在存储设备中的位置。省去了传统的File到Block的映射和BlockMap管理。

2.RADOS充分利用了OSDs的智能特点,将部分任务授权给OSDs,最大程度的实现可扩展。

5 参考文献

[1] RADOS: A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters.

[2] Ceph: A Scalable, High-Performance Distributed File System.

Similar Posts:

  • Mogilefs分布式文件系统-Keepalived+Nginx双主模型实现图片分布式存储、访问

    一.分布式文件系统: 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连.计算机通过文件系统管理.存储数据,单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式,在容量大小.容量增长速度.数据备份.数据安全等方面的表现都差强人意. 分布式文件系统可以有效解决数据的存储和管理难题:将固定于某个地点的某个文件系统,扩展到任意多个地点/多个文件系统,众多的节点组成一个文件系统网络.每个节点可以分布在

  • 分布式文件系统比较

    MooseFS 很不错,已经实用了半月了,易用,稳定,对小文件很高效. MogileFS 据说对于 Web 2.0 应用存储图片啥的很好. GlusterFS 感觉广告宣传做的比产品本身好. OpenAFS/Coda 是很有特色的东西. Lustre 复杂,高效,适合大型集群. PVFS2 搭配定制应用会很好,据说曙光的并行文件系统就是基于 PVFS. 适合做通用文件系统的有 MooseFS,GlusterFS,Lustre. ==================================

  • 分布式文件系统MogileFS

    一:什么是分布式文件系统 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连,也就是集群文件系统,可以支持大数量的节点以及PB级的数量存储.相对地,在一个分享的磁盘文件系统中,所有节点对数据存储区块都有相同的访问权,在这样的系统中,访问权限就必须由客户端程序来控制.分布式文件系统可能包含的功能有:通透的数据复制与容错.也就是说,即使系统中有一小部份的节点脱机,整体来说系统仍然可以持续运作而不会有数

  • mooseFS 分布式文件系统

    市面上各种分布式文件系统品种繁多,层出不穷.列举几个主要的: mogileFS:Key-Value型元文件系统,不支持FUSE,应用程序访问它时需要API,主要用在web领域处理海量小图片,效率相比mooseFS高很多. fastDFS:国人在mogileFS的基础上进行改进的key-value型文件系统,同样不支持FUSE,提供比mogileFS更好的性能. mooseFS:支持FUSE,相对比较轻量级,对master服务器有单点依赖,用perl编写,性能相对较差,国内用的人比较多 glust

  • 开源的分布式文件系统

    moosefs:支持FUSE,相对比较轻量级,对master服务器有单点依赖,用perl编写,性能相对较差,国内用的人比较多(豆辩在用),适合数量少的大文件 glusterfs:支持FUSE,比mooseFS庞大 这是两个比较好的开源分布式文件系统,实现了posix,后者功能多一些,bug也多一些. mogilefs :Key-Value型元文件系统,不支持FUSE,应用程序访问它时需要API,主要用在web领域处理海量小图片,效率相比mooseFS高很多,功能比较简单,不支持posix,依赖m

  • 分布式文件系统元数据服务模型

    随着非结构化数据的爆炸,分布式文件系统进入了发展的黄金时期,从高性能计算到数据中心,从数据共享到互联网应用,已经渗透到数据应用的各方各面.对于大多数分布式文件系统(或集群文件系统,或并行文件系统)而言,通常将元数据与数据两者独立开来,即控制流与数据流进行分离,从而获得更高的系统扩展性和I/O并发性.因而,元数据管理模型显得至关重要,直接影响到系统的扩展性.性能.可靠性和稳定性等.存储系统要具有很高的Scale-Out特性,最大的挑战之一就是记录数据逻辑与物理位置的映像关系即数据元数据,还包括诸如

  • 分布式文件系统(3)

     分布式存储: 分布式文件系统的历史. http://blog.chinaunix.net/uid-29759225-id-4489272.html 把分布式文件系统的历史划分为4个阶段. 对每个阶段的优缺点总结不够透彻,历史的脉搏也不够清晰,但这很难吧. 使用 FUSE 开发自己的文件系统 http://www.ibm.com/developerworks/cn/linux/l-fuse/ FUSE使得文件系统开发的门槛大幅降低. SNIA云存储标准 http://blog.chinaun

  • 分布式文件系统MFS实现存储共享剖析

    编者按:现在,有大量的企业采用共享存储服务器NFS的方式,来对应用数据进行网络存储,但这存在性能瓶颈和单点故障的问题,于是,分布式文件存储管理系统开始流行起来.本文为大家推荐了开源的分布式文件系统MFS,相信对大家有所帮助. 分布式文件系统MFS(moosefs) 实现存储共享剖析(上) 分布式文件系统MFS(moosefs) 实现存储共享剖析(中) 分布式文件系统MFS(moosefs) 实现存储共享剖析(下) [IT168 专稿]由于用户数量的不断攀升,我对访问量大的应用实现了可扩展.高可靠

  • 分布式文件系统FastDFS部署

    一.简介 FastDFS是一款类Google FS的开源分布式文件系统,它用纯C语言实现,支持Linux.FreeBSD.AIX等UNIX系统.它只能通过专有API对文件进行存取访问,不支持POSIX接口方式,不能mount使用.准确地讲,Google FS以及FastDFS.mogileFS.HDFS.TFS等类Google FS都不是系统级的分布式文件系统,而是应用级的分布式文件存储服务. 二.FastDFS的架构 图1展示的是FastDFS的系统架构. 图1 FastDFS的系统架构 从图

  • 分布式文件系统:原理、问题与方法

    本地文件系统如ext3,reiserfs等 (这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源.提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用.但随着互联网企业的高 速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大:而类似于youtube, 优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等.这些应用场景都是传统文件系统不能解决的.分布式文件系统将数据 存储在物理上分散的多个存储

Tags: