分布式存储系统之Ceph基础( 二 ) _生活百科

Ceph块设备

文章插图
存储领域中，“块（block）”是进行数据存取的主要形式，块设备也于是成为了主流的设备形式，因此，RBD虚拟块设备也就成了Ceph之上广为人知及非常受欢迎的访问接口；RBD的服务接口无须依赖于特定的守护进程，只要客户端主机有对应内核模块librbd ，就可以通过ceph RBD 接口使用；
Ceph对象网关

文章插图
Ceph对象网关是一个建立在librados之上的对象存储接口为应用程序提供的Ceph存储集群的RESTful网关。Ceph对象存储支持两个接口s3和Swift；Ceph对象存储使用Ceph对象网关守护进程(radosgw) ，它是一个HTTP服务器，用于与Ceph存储集群交互；RGW依赖于在RADOS集群基础上独立运行的守护进程（ceph-radosgw）基于http或https协议提供相关的API服务，不过，通常仅在需要以REST对象形式存取数据时才部署RGW；
管理节点（admin host）

文章插图
Ceph的常用管理接口是一组命令行工具程序，例如rados、ceph、rbd等命令，管理员可以从某个特定的MON节点执行管理操作，但也有人更倾向于使用专用的管理节点；事实上，专用的管理节点有助于在Ceph相关的程序升级或硬件维护期间为管理员提供一个完整的、独立的并隔离于存储集群之外的操作环境，从而避免因重启或意外中断而导致维护操作异常中断；
存储池、PG（Placement Group）和OSD（Object Store Device）之间的关系

文章插图
提示：存储在Ceph存储系统之上的数据，都会先由Ceph将对应数据切分等额大小的对象数据，然后将这些数据存储到对应的存储池中；存储池主要作用是向外界展示集群的逻辑分区；对于每个存储池，我们可以定义一组规则，比如每个对象数据需要有多少个副本存在；PG是Placement Group的缩写，归置组；它是一个虚拟的概念，主要作用是用于将对象数据映射到osd上而存在的，对象数据具体通过那个pg存放在那个osd上，这个是根据ceph的crush算法动态映射的；我们可以理解为根据存储池中PG的数量，结合一致性hash将对象数据动态映射至PG上，然后PG根据osd数量结合一致性hash动态映射到不同的磁盘上；我们在创建存储池的时候就必须指定一定数量的PG；如上图所示，我们将数据存储到存储池B中，那么对应数据就会根据存储池B中的规则进行存储，即3个副本；在存储池B中只有2个归置组，两个归置组分别对应了不同的OSD；如果将数据存储到PG3上，那么对应数据就会在osd2\6\7分别存储一份以做备份；如果将数据存储到PG4上，这对应数据就会被分发到osd3\4\9上进行存储；
File Store 和 Blue Store

文章插图
什么是file store呢？file store是传统ceph存储对象的方法，它依赖于xfs文件系统（ext4有bug和缺陷，会导致数据丢失，所以ceph只支持xfs上使用file store）；通过上述的描述，我们知道ceph不管是什么客户端提交的对象数据，最终都会存储到osd所在主机的硬盘上；那么问题来了，osd所在主机的磁盘是怎么被osd管理的呢？传统ceph是将对应磁盘格式化分区挂载在osd所在主机的文件系统，被osd所在主机以一个目录的形式表示；即用户存储的对象数据，最后会被存放为一个文件的形式存放在osd所在主机的磁盘上；这也意味着我们需要存放文件本身的元数据和数据；除此之外对象本身也有数据和元数据，那么对象本身的数据和元数据是怎么存放的呢？file store是是将对象的元数据存放在leveldb（早期ceph版本）中，数据存放在文件系统的数据区；简单讲file store就是将对象的元数据存放在leveldb中，数据存放在osd所在主机的文件系统的数据区中，中间有文件系统做转换的过程；而blue store将osd所在主机的磁盘不格式化分区，而是直接用裸设备硬盘被osd识别和管理；在osd所在主机对应osd进程会将自己管理的磁盘中一小部分格式化为bluefs文件系统，用于安装使用rocksdb；即客户端提交的对象数据，对象本身的元数据会被存放在rocksdb中，数据会被直接存放在磁盘上（由osd进程直接管理数据格式等，不会存放为文件）；rocksdb为了管理它自己本身的数据持久化，它也会维护一个日志文件，类似redis的aof；这样一来blue store的方式存储对象数据，在磁盘上就会存在三种数据，第一种是对象本身的数据，第二种是对象的元数据，第三种就是rocksdb的日志文件；ceph为了使存储的数据更高效，它支持将blue store方式的三种数据分别存放不同的磁盘，如下图