《Ceph源码分析》——第1章,第4节Ceph客户端接口

1.4 Ceph客户端接口
Ceph的设计初衷是成为一个分布式文件系统,但随着云计算的大量应用,最终变成支持三种形式的存储:块存储、对象存储、文件系统,下面介绍它们之间的区别。

1.4.1 RBD
RBD(rados block device)是通过librbd库对应用提供块存储,主要面向云平台的虚拟机提供虚拟磁盘。传统SAN就是块存储,通过SCSI或者FC接口给应用提供一个独立的LUN或者卷。RBD类似于传统的SAN存储,都提供数据块级别的访问。
目前RBD提供了两个接口,一种是直接在用户态实现,通过QEMU Driver供KVM虚拟机使用。另一种是在操作系统内核态实现了一个内核模块。通过该模块可以把块设备映射给物理主机,由物理主机直接访问。
块存储用作虚拟机的硬盘,其对I/O的要求和传统的物理硬盘类似。一个硬盘应该是能面向通用需求的,既能应付大文件读写,也能处理好小文件读写。也就是说,块存储既需要有较好的随机I/O,又要求有较好的顺序I/O,而且对延迟有比较严格的要求。

1.4.2 CephFS
CephFS通过在RADOS基础之上增加了MDS(Metadata Server)来提供文件存储。它提供了libcephfs库和标准的POSIX文件接口。CephFS类似于传统的NAS存储,通过NFS或者CIFS协议提供文件系统或者文件目录服务。
Ceph最初的设计为分布式文件系统,其通过动态子树的算法实现了多元数据服务器,但是由于实现复杂,目前还远远不能使用。目前可用于生产环境的是最新Jewel版本的CephFS为主从模式(Master-Slave)的元数据服务器。

1.4.3 RadosGW
RadosGW基于librados提供了和Amazon S3接口以及OpenStack Swift接口兼容的对象存储接口。可将其简单地理解为提供基本文件(或者对象)的上传和下载的需求,它有两个特点:
提供RESTful Web API接口。
它采用扁平的数据组织形式。

  1. RESTful的存储接口
    其接口值提供了简单的GET、PUT、DEL等其他接口,对应对象文件的上传、下载、删除、查询等操作。可以看出,对象存储的I/O接口相对比较简单,其I/O访问模型都是顺序I/O访问。
  2. 扁平的数据组织形式
    NAS存储提供给应用的是一个文件系统或者是一个文件夹,其实质就是一个层级化的树状存储组织模式,其嵌套层级和规模在理论上都不受限制。

这种树状的目录结构为早期本地存储系统设计的信息组织形式,比较直观,容易理解。但是随着存储系统规模的不断扩大,特别是到了云存储时代,其难以大规模扩展的缺点就暴露了出来。相比于NAS存储,对象存储放弃了目录树结构,采用了扁平化组织形式(一般为三级组织结构),这有利于实现近乎无限的容量扩展。它使用业界标准互联网协议,更加符合面向云服务的存储、归档和备份需求。
图1-3 Amazon S3的对象存储结构

由于Amazon在云存储领域的影响力,Amazon的S3接口已经成为事实上的对象存储的标准接口。如图1-3所示,其接口分三级存储:Account/Bucket/Object(账户/桶/对象)。一个Account可以看作一个用户(租户),其下可以包含若干个的Bucket,一个Bucket可以拥有若干对象,其数量在理论上都不受限制。
在云计算领域,OpenStack已经成为广泛采用的云计算管理系统,OpenStack的对象存储接口Swift也成为广泛采用的接口,如图1-4所示,其也采用分三级存储:Account/Container/Object(账户/容器/对象),每层节点数均没有限制。可以看出,Swift接口和S3类似,Swift的Container对应S3的Bucket概念。Swift接口和S3接口没有太大的区别,但是一些管理接口会有一些差别。
图1-4 OpenStack Swift对象存储结构

时间: 2024-10-04 17:35:06

《Ceph源码分析》——第1章,第4节Ceph客户端接口的相关文章

《Ceph源码分析》——导读

目 录序言第1章 Ceph整体架构1.1 Ceph的发展历程1.2 Ceph的设计目标1.3 Ceph基本架构图1.4 Ceph客户端接口 1.4.1 RBD 1.4.2 CephFS1.4.3 RadosGW 1.5 RADOS 1.5.1 Monitor 1.5.2 对象存储1.5.3 pool和PG的概念1.5.4 对象寻址过程1.5.5 数据读写过程1.5.6 数据均衡1.5.7 Peering 1.5.8 Recovery和Backfill 1.5.9 纠删码1.5.10 快照和克隆1

《Ceph源码分析》——第3章,第1节Ceph网络通信框架

第3章Ceph网络通信本章介绍Ceph网络通信模块,这是客户端和服务器通信的底层模块,用来在客户端和服务器之间接收和发送请求.其实现功能比较清晰,是一个相对较独立的模块,理解起来比较容易,所以首先介绍它. 3.1 Ceph网络通信框架一个分布式存储系统需要一个稳定的底层网络通信模块,用于各节点之间的互联互通.对于一个网络通信系统,要求如下:高性能.性能评价的两个指标:带宽和延迟.稳定可靠.数据不丢包,在网络中断时,实现重连等异常处理.网络通信模块的实现在源代码src/msg的目录下,其首先定义了

《Ceph源码分析》——第1章,第5节RADOS

1.5 RADOS RADOS是Ceph存储系统的基石,是一个可扩展的.稳定的.自我管理的.自我修复的对象存储系统,是Ceph存储系统的核心.它完成了一个存储系统的核心功能,包括:Monitor模块为整个存储集群提供全局的配置和系统信息:通过CRUSH算法实现对象的寻址过程:完成对象的读写以及其他数据功能:提供了数据均衡功能:通过Peering过程完成一个PG内存达成数据一致性的过程:提供数据自动恢复的功能:提供克隆和快照功能:实现了对象分层存储的功能:实现了数据一致性检查工具Scrub.下面分

《Ceph源码分析》——第2章,第7节本章小结

2.7 本章小结 本章介绍了src/common目录下的一些公共库中比较常见的类的实现.BufferList在数据读写.序列化中使用比较多,它的各种不同成员函数的使用方法需要读者自己进一步了解.对于ShardedThreadPool,本章只介绍了实现的原理,具体实现在不同的场景会有不同,需要读者面对具体的代码自己去分析.

《Ceph源码分析》——第2章,第2节Buffer

2.2 BufferBuffer就是一个命名空间,在这个命名空间下定义了Buffer相关的数据结构, 这些数据结构在Ceph的源代码中广泛使用.下面介绍的buffer::raw类是基础类,其子类完成了Buffer数据空间的分配,buffer::ptr类实现了Buffer内部的一段数据,buffer::list封装了多个数据段. 2.2.1 buffer::raw类buffer::raw是一个原始的数据Buffer,在其基础之上添加了长度.引用计数和额外的crc校验信息,结构如下:`class b

《Ceph源码分析》——第1章,第2节Ceph的设计目标

1.2 Ceph的设计目标Ceph的设计目标是采用商用硬件(Commodity Hardware)来构建大规模的.具有高可用性.高可扩展性.高性能的分布式存储系统.商用硬件一般指标准的x86服务器,相对于专用硬件,性能和可靠性较差,但由于价格相对低廉,可以通过集群优势来发挥高性能,通过软件的设计解决高可用性和可扩展性.标准化的硬件可以极大地方便管理,且集群的灵活性可以应对多种应用场景.系统的高可用性指的是系统某个部件失效后,系统依然可以提供正常服务的能力.一般用设备部件和数据的冗余来提高可用性.

《Ceph源码分析》——第3章,第2节Simple实现

3.2 Simple实现Simple在Ceph里实现比较早,目前也比较稳定,是在生产环境中使用的网络通信模块.如其名字所示,实现相对比较简单.下面具体分析一下,Simple如何实现Ceph网络通信框架的各个模块. 3.2.1 SimpleMessager类SimpleMessager实现了Messager接口.class SimpleMessenger : public SimplePolicyMessenger { Accepter accepter; //用于接受客户端的链接请求 Dispa

《Ceph源码分析》——第3章,第3节本章小结

3.3 本章小结本章介绍了Ceph的网络通信模块的框架,及目前生产环境中使用的Simple实现.它对每个链接都会有一个发送线程和接收线程用来处理发送和接收.实现的难点还在于网络链接出现错误时的各种错误处理.

《Ceph源码分析》——第2章,第1节Object

第2章Ceph通用模块本章介绍Ceph源代码通用库中的一些比较关键而又比较复杂的数据结构.Object和Buffer相关的数据结构是普遍使用的.线程池ThreadPool可以提高消息处理的并发能力.Finisher提供了异步操作时来执行回调函数.Throttle在系统的各个模块各个环节都可以看到,它用来限制系统的请求,避免瞬时大量突发请求对系统的冲击.SafteTimer提供了定时器,为超时和定时任务等提供了相应的机制.理解这些数据结构,能够更好理解后面章节的相关内容. 2.1 Object对象