@ceph分布式存储应用接口（mds及rbd）

高层应用接口详解

rados之上封装的是librados,在librados之上封装了:对象存储接口rados gw、块存储接口rbd,以及文件存储接口Ceph FS,以下详细介绍

   ### 一、块设备存储接口  

1）什么是块设备

   块设备是i/o设备中的一类,是将信息存储在固定大小的块中,每个块都有自己的地址,还可以在设备的 任意位置读取一定长度的数据。暂且认为块设备就是硬盘或虚拟硬盘

[root@admin ~]# ls /dev/
/dev/sda      /dev/sda1    /dev/sda2     /dev/sdb /dev/sdb1     /dev/hda     /dev/rbd1     /dev/rbd2 、
.......
...


#/dev/sda、/dev/sdb和/dev/hda都是块设备文件

#块设备文件是如何生成的
    当给计算机连接块设备(硬盘)后,系统检测的有新的块设备,该类型块设备的驱动程序就在/dev/下，创建个对应的块设备设备文件,用户就可以通过设备文件使用该块设备了。
它们怎么有的叫 sda2有的叫 sdb2有的叫 hda2

#不同名称的区别
    以sd开头的块设备文件对应的是SATA接口的硬盘,而以hd开头的块设备文件对应的是IDE接口的硬盘。 那SATA接口的硬盘跟IDE接口的硬盘有啥区别，你只需要知道,IDE接口硬盘已经很少见到了,逐渐被淘汰中,而SATA接口的硬盘是目前的主流。而sda和sdb的区别呢2当系统检测到多个SATA硬盘时,会根据检测到的ᶲ序对硬盘设备进行字母顺序的命名。PS:系统按检测ᶲ序命名硬盘会导致了盘符漂移的问

#rbd1和rbd2文件的生成
    rbd就是由Ceph集群提供出来的块设备。可以这样理解,sda和 hda都是通过数据线连接到了真实的硬盘,而rbd是通过网络连接到了Ceph集群中的一块存储区域,往rbd设备文件写入数据,最终会被存储到Ceph集群的这块区域中

2）块设备的使用

#例:
   1、打个比方,一个块设备是一个粮仓,数据就粮食。农民伯伯可以粮食(写数据)了,需要存100斤玉米,粮仓(块设备)这么大放哪里呢,就挨着放(顺序写)吧。又需要存1000斤花生,还是挨着放吧。又需要存……
   2、后来,农民伯伯来粮食(读数据)了,他当时存了1000斤小麦,哎呀妈呀,粮仓这么大,小麦在哪里 ，啊？仓库管理员找啊找,然后哭晕在了厕所……
   3、新管理员到任后,想了个法子来解决这个问题,用油漆把仓库划分成了方格状,并且编了号,在仓库门口的方格那挂了个黑板,当农民伯伯来粮食时,管理员在黑板记录,张三存了1000斤小Ἀ在xx方格   处。后来,农民伯伯张三来粮食时,仓库管理员根据小黑板的记录，很快提取粮食
   4、故事到此为止了,没有方格和黑板的仓库(块设备)称为裸设备。由上例可见,裸设备对于用户使用是  很不友好的,直接导致了旧仓库管理员的狗带。
   5、例子中划分方格和挂黑板的过程其实是在块设备上构建文件系统的过程,文件系统可以帮助块设备对存储空间进行条理的组织和管理,于是新管理员通过文件系统(格子和黑板)迅速找到了用户(农民伯伯张三)存储的数据(1000斤小麦)。针对多种多样的使用场景,衍生出了很多的文件系统。有的文件系统能够提供更好的读性能,有的文件系统能提供更好的写性能。我们平时常用的文件系统如xfs、ext4是读写性能等各方ᶎ比较均衡的通用文件系统

#能否直接使用不含有文件系统块设备呢
   1、可以的,xfs和ext4等通用的文件系统旨在满足大多数用户的存储需求,所以在数据存储的各方面的性能 比较均衡。然而,很多应用往往并不ᵱ要这种均衡,而需要突出某一方面的性能,如小文件的存储性  能。
  /2、此时,xfs、ext4等通用文件系统如果不能满足应用的需求,应用往往会在裸设备上实现自己的数据 组织和管理方式。简单的说,就是应用为了强化某种存储特性而实现自己定制的数据组织和管理方式, 而不使用通用的文件系统

3）Ceph块设备接口的使用

#Ceph集群中创建块设备
1、保证/etc/ceph目录下有Cephᵞ群的配置文件ceph.conf和ceph.client.admin.keyring rbd create -s 1G egonrbd

2、在用户机上挂载该Ceph块设备,可以理解为往用户机上插入硬盘:
rbdmap egonrbd

3、输出:
/dev/rbd1


#Ceph块设备格式化成文件系统并挂载
[root@admin ~]# mkfs.xfs /dev/rbd1 
[root@admin ~]# mkdir -p /mnt/ceph_rbd
[root@admin ~]# mount /dev/rbd1 /mnt/ceph_rbd
#通过/mnt/ceph_rbd读写数据,都是在读写Ceph集群中该块设备对应的存储区域

4）总结（块设备）

   块设备可理解成一块硬盘,用户可以直接使用不含文件系统的块设备,也可以将其格式化成 特定的文件系统,由文件系统来组织管理存储空间,从而为用户提供丰富而友好的数据操作支持。

二、文件存储接口

1）Ceph的文件系统接口

Cephᵞ群实现了自己的文件系统来组织管理集群的存储空间,用户可以直接将Cephᵞ群的文件系统挂载到用户机上使用

2）文件系统接口与块设备接口的区别

 因为应用场景的不同,Ceph的块设备具有优异的读写性能,但不能多处挂载同时读写,目前主要用在OpenStack上作为虚拟磁盘,而Ceph的文件系统接口读写性能较块设备接口差,但具有优异的共享性。
 
PS:想了解更多?快去查查SAN和NAS

#Ceph的文件系统接口具有共享性,Ceph的块设备接口不具有
   1、#Ceph的块设备接口
   如图2,文件系统的结构状态是维护在各用户机内存中的,假设Ceph块设备，同时挂载到了用户机1和用户机2,当在用户机1上的文件系统中写入数据后,更新了用户机1的内存中文件系统状态,最终数据存储到了Ceph集群中,但是此时用户机2内存中的文件系统并不能得知底层 Ceph集群数据已经变化而维持数据结构不变,因此用户无法从用户机2上读取用户机1上新写入的数据。
    2、#Ceph的文件系统接口
    如图3,文件系统的结构状态是维护在远集群中的,Ceph文件系统同时挂载到了用户机1和用户机2,当往用户机1的挂载点写入数据后,远端Cephᵞ群中的文件系统状态 结构随之更新,当从用户机2的挂载点访问数据时会去远端Ceph集群取数据,由于远端Ceph集群已更新,所有用户机2能够获取最新的数据。

3）Ceph的文件系统接口的使用

#将Ceph的文件系统挂载到用户机目录
/* 保证/etc/ceph目录下有Ceph集群的配置文件ceph.conf和ceph.client.admin.keyring */ 
[root@admin ~]# mkdir -p /mnt/ceph_fuse
[root@admin ~]# ceph-fuse /mnt/ceph_fuse

#在/mnt/ceph_fuse下读写数据,都是读写远程Ceph集群

#总结
    Ceph的文件系统接口弥补了Ceph的块设备接口在共享性方面的不足,Ceph的文件系统接口符合POSIX标准,用户可以像使用本地存储目录一样使用Ceph的文件系统的挂载目录。
    还是不懂？这样理解吧,无需修改你的程序,就可以将程序的底层存储换成空间无限并可多处共享读写的Ceph集群文件系统

三、对象存储接口

1) 对象存储接口的使用

​ 通过http协议上传下载删ᴻ对象(文件即对象)

2)块设备接口存储和文件系统接口存储与（对象存储）区别

Ceph的块设备存储具有优异的存储性能但不具有共享性,而Ceph的文件系统具有共享性 然而性能较块设备存储差,为什么不权衡一下存储性能和共享性,整个具有共享性而存储性能好于文件系统存储的存储呢,对象存储就这样出现了

#对象存储为什么性能会比文件系统好？
    因为是对象存储组织数据的方式相对简单,只有bucket和对象两个层次(对象存储在bucket中),对对象的操作也相对简单。而文件系统存储具有复杂的数据组织方式,目录和文件层  次可具有无ᴴ深度,对目录和文件的操作也复杂的多,因此文件系统存储在维护文件系统的结构数据时会更加繁杂,从而导致文件系统的存储性能偏低

3）Ceph的对象存储接口的使用

Ceph的对象接口符合亚Ḙ逊S3接口标准和OpenStack的Swift接口标准

   文件系统存储具有复杂的数据组织结构,能够提供给用户更加丰富的数据操作接口,而对象存储精简了数据组织结构,提供给用户有限的数据操作接口,以换取更好的存储性能。对象接口提供了REST API
,非常适用于作为web应用的存储

4）总结

     块设备速度快,对存储的数据没有进行组织管理,但在大多数场景下,用户数据读写不方便(以块设备位置offset + 数据的length来记录数据位置,读写数据)。而在块设备上构建了文件系统后,文件系统帮助块设备组织管理数据,数据存储对用户更加友好(以文件名来读写数据)。Ceph文件系统接口解决了“Ceph块设备+本地文件系统”不支持多客户端共享读写的问题,但由于文件系统结构的复杂性导致了存储性能较Ceph块设备差。对象存储接口是一种折中,保证一定的存储性能,同时支持多客户端共享读写

四、块存储接口rbd的写入

1)块存储接口rbd的写入过程

#客户端写入数据以块存储rbd为例,一般有两种方法:
   1、第一种 是 Kernel rbd。就是创建了rbd设备后,把rbd设备map到内核中,形成一个虚拟的块设备,这时这个块设备同其他通用块设备一样,一般的设备文件为/dev/rbd0,后续直接使用这个块  设备文件就可以了,可以把 /dev/rbd0 格式化后 mount 到某个目录,也可以直接作为裸设备使用。这时对rbd设备的操作都通过kernel rbd操作方法进行的。
   2、 第二种是 librbd 方式。就是创建了rbd设备后,这时可以使用librbd、librados库进行访问管理块设备。这种方式不会map到内核,直接调用librbd提供的接口,可以实现对rbd设备的访问和管理,但是不会在客户端产生块设备文件。

#应用写入rbd块设备的过程(假设后端存储引擎为filestore)
   1.应用调用 librbd 接口或者对linux 内核虚拟块设备写入二进制块,以 librbd 为例。
   2.librbd 对二进制块进行分块,默认块大小为 4M,每一块都有名字,成为一个对象
   3.librbd 调用 librados 将对象写入 Ceph ᵞ群
   4.librados 向主 OSD 写入分好块的二进制数据块 (先建立TCP/IP连接,然后发送消息给 OSD,OSD接收后写入其磁盘)
   5.主 OSD 负责同时向一个或者多个次 OSD 写入副本
#注意这里是写到日志(Journal)就返回,因此,使用SSD作为Journal的话,可以提高响应速度,做到服务器端对客户端的快速同步返回写结  果(ack)。
   6.当主次OSD都写入完成后,主 OSD 向客户端返回写入成功。
   7.当一段时间(也许得几秒钟)后Journal 中的数据向磁盘写入成功后,Ceph通过事件通知客户端数据写入磁盘成功(commit),此时,客户端可以将写缓存中的数据彻底清除掉了。
   8.默认地,Ceph客户端会缓存写入的数据直到收到集群的commit通知。如果此阶段内(在写方法返回到收到commit通知之间)OSD 出故ᵑ导致数据写入文件系统失败,Ceph 将会꧋许客户端重做尚未提交的操作(replay)。因此,PG 有个状态叫 replay:“The placement group is waiting for clients to replay operations after an OSD crashed.” 。也就是,文件系统负责文件处理,librdb 负责块处理,librados 负责对象处理,OSD 负责将数据写入在
Journal和磁盘中

2）储备知识:常见的write cache种类

缓存种类	说明	优劣势	适合场景
Write- through(直写/同步写)	这种缓存方式在写 I/O 时把数据放入缓存,同时直接写入底层的持久存储,然后再向主机确认写入操作完成。	安全地保存数据,从缓存读,减少了读操作的延迟,但是写操作的延迟没得到优化	适合于写较少,但是频繁度的应用
Write-back (回写/异步写)	数据直接写入缓存,然后向主机返回写入完成。	对频繁写应用减少了写的延迟,但是有数据丢失风险	对读写混合型应用有优势,但是需要考虑数据 保护·····

#缓存的通常位置分类
1、服务器(主机)上:RAID 卡或者 HBA 卡上做缓存。
2、VMM 内:在 Hypervisor 上做缓存。
3、客户机操作系统内:以 Windows 2012 为例,它提供 write-back 缓存机制

3）RBD块存储缓存

默认情况下,Ceph RBD 是不使用缓存的,读和写直接到 Ceph ᵞ群中的存储,写只有在所有replication上写都完成后才给客户端返回写完成。在较新的版本上陆续添加了 缓存支持

#简述：
   1、从 0.46 版本开始,Ceph 支持 write-back 缓存,你可以在 ceph.conf 文件的 [client] 部分添加rbd cache = true 来使得 write-back 缓存生效。这时候,写几乎是立即返回,但是数据只有在被flushed 后才写入到实际存储。
   2、从 0.47 版本开始,Ceph 支持 write-through 缓存机制。你只ᵱ要再添加配置ᶱ rbd cache max dirty = 0 即可
   3、从 0.60 版本开始,Ceph 支持 rbd cache writethrough until flush 配置ᶱ。设置它为 true 时,会使得 write-through 机制变得更加安全,因为老的客户机操作系统(2.6.32 内核版本之前)可能不支持 flush 操作。因此,在设置了该配置ᶱ为 true 时,即使用户设置了使用 write-through 机制,Ceph 也会自动使用 write-back 机制,直到它收到第一个flush 指令后才真正使用 write- through。
   
   
 #可见 RBD 缓存是在客户端做的,见如下图示

4）Cache tiering (缓存分层)

​ Ceph 还支持在ᵞ群段做缓存分层。其原理是,在较快的磁盘比如 SSD 上建立一个 cache pool,在建立存储池(storage pool)和它之间的 cache 关系,设置一定的缓存策略,实现类似于在客户端缓存同样的效果

5)RBD Cache 和 Cache Tiering 的区别

#从上面的分析可以看出来,两者的区别在于缓存的位置不同
   1、sCache tiering 是 RADOS 层在 OSD  端进行数据缓存,也就是说不论是块存储、对象存储还是文件存储都可以使用tier来提ṛ读写速度
   2、RBD Cache是 rbd 层在客户端的缓存,也就是只支持块存储。
   3、Rbd cache是 客户端的缓存,当多个客户端使用同个块设备时,存在客户端数据不-致的问᷌。举个例子,用户A向块设备写入数据后,数据停留在客户自己的缓存中,没有立即刷新到磁盘,所以   其它用户读取不到A写入的数据。但是tier不存在这个问᷌,因为所有用户的数据都直接写入到 ssd,用户读取数据也是在ssd中读取的,所以不存在客户端数据不一问题。
   4、一般地,Tier 使用 SSD 做缓存,而 Rbd cache 只能使用内存做缓存。SSD和内存有两个方ᶎ的差别,一个是读写速度、另一个是掉电保护。掉电后内存中的数据就丢失了,而ssd中的数据不会丢失。

五、存储引擎

1) 存储引擎介绍

ceph后端支持多种存储引擎,以插件式的方式来进行管理使用,目前支持filestore,kvstore, memstore以及最新的bluestore。

  1、在老版本的Ceph当中FileStore是ἕ认的对象存储引擎,但FileStore是基于操作系统通用的文件系统层,   例如Ext4和XFS等,这些都是日志文件系统,所以filestore在写数据前ᵱ要先写journal,会有写放大问题(即一次读写请求实际在低层磁盘发生的IO次数,再加上FileStore的日志双写,放大倍数成倍增加, 推荐阅读https://blog.csdn.net/majianting/article/details/105517527),并且filestore一开始只是对于 机械盘进行设计的,没有专门针对ssd做优化考虑,因此整体性能欠佳。
  2、于是bluestore应运而生,BlueStore设计的初衷就是为了减少写放大,并针对ssd做优化,而且直接管理裸盘,抛弃了ext4/xfs等本地文件系统,从理论上进一步减少文件系统如ext4/xfs等部分的开销、效率更高



#luminous版默认的存储引擎为bluestore,结构图如下

#BlueStore
直接使用一个原始分区,ceph对象将直接写在块设备上,不再需要任何的文件系统,和osd一起进来的元数  据将存储在一个名为 RocksDB 的键꧊对数据库;

# 各层意义
RocksDB :存储 WAL 日志和元数据(omap)
BlueRocksEnv: 与RocksDB 交互的接口
BlueFS	: 一个类似文件系统的 mini C++,使 rocksdb 生效,ENv 接口(存储 RocksDB 日志和sst 文件);
因为rocksdb 一般跑在一个文件系统的上层,所以创建了 BlueFS。

# RocksDB 存放的数据类型对象的元数据
write-ahead 日志
ceph omap	数据
allocator metadata(元数据分配器):决定数据存放位置;此功能可插拔

# ἕ认BlueStore模型
第一个小分区(XFS或者ext4),包括ceph files
(init system descriptor,status,id,fsid,keyring 等)和RocksDB 文件第二个分区是一个原始分区

# 优点
每一部分都可以存放在不同的磁盘中,RocksDB WAL 和 DB 可以存放在不同的磁盘或者小分区中

#查看帮助文档
root@admin ceph]# ceph-deploy osd --help
For bluestore, optional devices can be used::
。。。
For filestore, the journal must be specified, as well as the objectstore::

ceph-deploy osd create {node} --filestore --data /path/to/data --journal
/path/to/journal

https://ceph.com/community/new-luminous-bluestore/

https://baijiahao.baidu.com/s?id=1635414952916759127&wfr=spider&for=pc

2)Bluefs中的DB和WAL分区

https://www.cnblogs.com/linhaifeng/articles/14708563.html

3)基于bluestore管理osd

   1、由于Luminous里ἕ认使用Bluestore,直接在裸盘上进行操作即可,无ᵱ制作文件系统,所以压根不ᵱ 要journal盘,但是ᵱ要block-db与block.wal,综合考虑
   2、data盘我们使用sas口的机械硬盘,block-db与block.wal我们使用固态盘的两个分区(生产环境一块ssd磁盘会对应多块osd,所以我们ᵱ要把ssd多个分区)


#需知底层都会做逻辑卷
    1、eph-volume 是在 Luminous 推出的全新 OSD 部署和管理介质的工具,用于替换之前使用很多年的ceph-disk。目前 ceph-volume 使用 LVM 作为设备的管理实现,也就是说,在 Luminous 以后, 社区会强制使用 LVM 作为所有 OSD 的设备管理工具。但是为了兼容 ceph-disk 原本管理的设备, ceph-volume 仍然支持对旧设备的简单管理。在 12.2.2 版本后,ceph-disk 会正式废弃。
   2、Sage 在上周邮件列表宣布了这一变化,短期来看,lvm 会被强制使用,暂时没有支持其他插件的计划。背后主要也是维护多套设备管理成本太ṛ,另外 Redhat 对于 DeviceMapper 这块有巨大投入,更愿意整合 LVM 而不是其他工具。
   3、对于 LVM 方式来说,好处是带来了众多 LVM 本身的功能,比如 dmcache,加密等,另一方ᶎ,LVM 也是 Linux 管理员熟识的工具,方便用户直接管理。不过问᷌是 LVM 毕竟是一层不可忽视的逻辑,对性能特别是ṛ速介质还是有一些损耗,这个对于一些用户来说是个顾虑。不过对于未来来说,社区仍然希望有其他插件来跟 LVM 并存,目前从 12.2.2 版本开始,用户已经可以使用ceph-volume了

4）基于filestore管理osd

需要先对硬盘制作文件系统,每个制作过文件系统的disk最好对应一块journal盘,journal盘无需制作文件系统

   #注
   1、这里是写到日志(Journal)就返回,因此,使用SSD作为Journal的话,可以提高响应速度,做到服务器端对客户端的快速同步返回写结果(ack)。
   2、journal的信息建议使用硬盘或SSD盘单独存放,所以我们ᵱ要为OSD节点上的每个disk配一个journal日  志盘,最好为ssd盘,说到ssd盘,需要先了解一下它的写放大现象:如下地址

https://www.cnblogs.com/linhaifeng/articles/14692472.html

   #案列：
   在公司做ceph的时候版本为hammer,osd节点上总共有个16+8+2块盘,16块为disk,8块为ssd,2块为ssd做raid1当系统盘,8块ssd每块分两个分区(固态硬盘讲究少分区、小分区,但分成两个分区还是可以的,你要有钱,你买16块ssd那自然最好),于是分成了16个journal与16个disk对应,具  体一个disk应该对应多大的journal盘呢,有一个计算公式 ：
   1、在ceph.conf中,日志大小osd journal sizeἕ认5120MB,即5G
#注:如果是0表示整个块设备都用来存日志,建议初始设为1G

   2、osd journal size至少为 2 * (expected throughput * filestore max sync interval)
#其中throughput 为磁盘disk的转速和网络速率的最小一个
   3、ilestore max sync interval最大的同步时间,ἕ认为15s
   4、磁盘disk的速率为6Gbps,而网络为10Gbps,选取最小的一个
   5、 2*(6Gbps*15)=180 ，180/8=30G,ᵱ要30G的日志盘,而我们一个ssd盘200G,分两个分区,每个分区100G,足足够了



#监控硬盘的时候:
分区使用率70%警告,80%报警

#提示
1、Gbps
   Gbps也称交换带宽,是衡量交换机总的数据交换能力的单位,以太网是IEEE802.3以太网标准的扩展,传   输速度为每秒1000兆比特位(即1Gbps)。

2、Filestore sync interval
    为了创建一个一致的提交点(consistent commit point),filestoreᵱ要停止写操作来执行syncfs(),也就是从日志中同步数据到数据盘,然后清理日志。更加᷇繁地同步操作,可以减少存储在日   志中的数据量。这种情况下,日志就能꧌分得到利用。配置一个越小的同步꧊,越有利于文件系统合并小量  的写,提升性能。下ᶎ的参数定义了两次同步之间最小和最大的时间周期。
    
filestore_min_sync_interval = 10
filestore_max_sync_interval = 15



#对于hammer版ceph,后端的存储引擎为了filestore,部署osd时ᵱ要执行下述命令格式为: osd节点的ip地址:osd磁盘:日志盘

ceph-deploy --overwrite-conf osd create $host:sdb1:/dev/sdh1
$host:sdc1:/dev/sdh2 $host:sdd1:/dev/sdi1 $host:sde1:/dev/sdi2
$host:sdf1:/dev/sdj1 $host:sdg1:/dev/sdj2

六、ceph版本

[root@admin ceph]# ceph --version     #版本查看
ceph version 12.2.13 (584a20eb0237c657dc0567da126be145106aa47e) luminous (stable)

Luminous v12.2.x是一个LTS长期稳定版本,官方建议所有用户升级到此版本

1）ceph版本

https://docs.ceph.com/en/latest/releases/

http://docs.ceph.org.cn/releases/

2) ceph-deploy版本

https://docs.ceph.com/en/latest/install/

[root@admin ~]# ceph-deploy --version 
2.0.1

ceph-deploye不再积极维护,它没有在比Nautilus新的Ceph版本上进行测试。它不支持RHEL8、CentOS 8或更新的操作系统。