一个最小化的Ceph集群需要三个组件MON MGR OSD.上一章我们部署了MON,本章节我们完成剩下MGROSD 的部署。在文末我们将重点介绍下什么是FileStoreBlueStore,并详细分析其特点,来说明为什么Ceph社区放弃了FileStore,直接采用了BlueStore.

1、MGR 部署

  1. 创建mgr工作目录
sudo -u ceph mkdir /var/lib/ceph/mgr/ceph-mon01
  1. mgr 授权
#例子 ceph auth get-or-create mgr.$name mon \# 'allow profile mgr' osd 'allow *' mds 'allow *'# allow profile mgr 表示允许管理和配置mgr 的权限 ceph auth get-or-create mgr.mon01 mon \'allow profile mgr' osd 'allow *' mds 'allow *' \  > /var/lib/ceph/mgr/ceph-mon01/keyring
  1. 修改目录的属主和属组为ceph用户,并启动ceph-mgr 进程
chown -R ceph:ceph /var/lib/ceph/mgr/systemctl restart ceph-mgr@mon01systemctl enable ceph-mgr@mon01

4、检查集群状态

[root@mon01 tmp]# ceph -s   cluster:    id:     51be96b7-fb6b-4d68-8798-665278119188    health: HEALTH_WARN            mon is allowing insecure global_id reclaim            1 monitors have not enabled msgr2   services:    mon: 1 daemons, quorum mon01 (age 44m)    mgr: mon01(active, since 1.5342s)    osd: 0 osds: 0 up, 0 in   data:    pools:   0 pools, 0 pgs    objects: 0 objects, 0 B    usage:   0 B used, 0 B / 0 B avail    pgs:     

此时发现mgr: mon01 显示active 为活动状态表示部署成功。 但是Ceph 集群的状态还是显示为HEALTH_WARN。

  • 问题1 : 1 monitors have not enabled msgr2
    msgr2 协议 是Ceph中的新消息传递协议,它带来了一些性能和安全性方面的改进。在集群中,所有的监视器都应该启用msgr2以确保它们之间使用最新的消息传递协议。

总结:

  1. msgr是MON用来消息传递的协议,目前有两个版本V1 和V2 ,V1版本使用6789端口,
    V2版本使用3300端口。

  2. ceph mon enable-msgr2 开启V2版 消息传递协议。

【思考】:做过ceph运维的小伙伴肯定会遇见一种情况就是执行ceph -s 或其他ceph命令时命令一直卡住,很长时间都没有反应,第一次遇见此情况的小伙伴甚至怀疑集群宕机了。

【实验】 禁止本机3300端口

 #使用iptables 规制禁止了3300端口的访问 iptables -A  INPUT -p tcp   -m  tcp --dport 3300 -j DROP


现在我们使用ceph -s 命令背后的逻辑

  • 先确定其进程编号
  • lsof 查看其命令访问的端口号


从上图中发现其确实访问的3300端口。因此我们得出结论,当执行ceph命令时,进程卡住了,先检查下3300 和6789 端口是否能正常访问。 iptables -F 清空filter 表后恢复正常

  • 问题2: mon is allowing insecure global_id reclaim
#关闭非安全的集群id 回收ceph config set mon \    auth_allow_insecure_global_id_reclaim false

2、OSD 部署

OSD的安装可以分两步:初始化、激活,也可以一步到位。

#初始化ceph-volume lvm prepare --data /dev/sdb ceph-volume lvm list #来获取osd.id 和 osd fsid

#激活ceph-volume lvm activate 0 acdadb1a-ed18-4068-bbcb-432ba0cfcdb2

验证第一个osd


第二个osd 和第三三个osd 安装使用create 等于上面的两步

ceph-volume lvm create --data /dev/sdcceph-volume lvm create --data /dev/sdd

到此整个ceph 集群就部署完成了,一个MON ,一个MGR 和3个OSD 组成了一个最小化的Ceph集群。
不过上述的部署方式仅限于测试环境,生产环境切勿直接使用上述命令。为什么?

对ceph 有过生产经验的小伙伴都知道,Ceph是需要日志盘的。这里我们只使用了数据盘,那日志盘了?
要解释清楚这个问题,我们先弄清楚FileStoreBlueStore

3、Filestore or Bluestore

在之前的章节中我们曾介绍说,一般数据可以简单分为两部分,数据和元数据,在Ceph集群中,数据在写入集群时,将被客户端分割成4MB为单位的对象。每个对象都会写入OSD来实现落盘。在FileStore中每一个对象都需要通过FileStore的功能来实现将对象写入磁盘。

Ceph采用的是全日志系统,也就是说将所有数据存放在日志中(数据和元数据都存放在日志中),这样做的好处是Ceph可以先把一些零散的、随机的I/O请求保存到缓存中并进行合并,然后再统一向内核发起I/O请求。这样做效率会比较高,其带来的问题就是一旦OSD崩溃,缓存中的数据就会丢失。因此Ceph的日志是事务日志。事务日志不是真正去修改数据,而是记录数据修改的操作,这样当数据崩溃后,只要基于当前时间节点回放事务日志就能还原数据。

写日志有两种模式:ParallelWriteahead

  • Parallel(并行写): 是日志和磁盘数据同时写;
  • Writeahead(预写日志): 是先写日志,只要日志写成功,就返回,后台每隔一段时间会同步日志中的写操作,实现落盘。这种方法带来的好处就是,可以把很多小I/O请求合并,形成顺序写盘,提高每秒读写次数。通常在生产环境中,我们使用SSD来单独存储日志文件,以提高Ceph读写性能。

Writeahead模式下,Ceph对象(数据和元数据)一旦写入日志盘之后,就返回给客户端写入完成,之后按照一定的同步周期来将数据同步到后端真正的数据盘中。也就是说,当用户写入了一个对象数据(Ceph 中一切皆对象)返回成功时,可能该数据仅仅只是写了日志盘,还没有真正落入后端的存储磁盘。这就引入了第一个问题,FileStore 的双写问题(数据先写了日志盘,之后按一定周期写入后端磁盘)。

其次是在ceph按一定周期将日志盘的信息写入后端数据盘时,其前端对日志的写操作是要暂停的。专门执行日志数据到文件系统的同步。日志系统空间大小代表能缓存的数据量,同步时间的设置也会影响Ceph的性能。

在从文件系统的角度来看,FileStore底层使用POSIX规范的文件系统接口,例如xfs、ext4、btrfs,无论是数据还是元数据,都需要先写入文件系统层(如图中的XFS文件系统),然后由XFS文件系统接口来实现数据的落盘操作。我们可以简单理解为其在文件系统层也有写放大的问题,增加了文件系统层IO操作。


前文中我们提过,数据的元数据的一些随机的小IO,在FileStore 中使用Leveldb键/值数据库来存放其元数据,而Leveldb 为了保证自身事务的一致性,也采用事务日志来记录其操作,而不是真正的元数据进行操作。这些只是记录操作本身,而不对真正数据操作的行为都可以称为WAL(Write Ahead Log预写日志),其优点是一方面提高了效率(将随机IO变成了顺序IO),另一方面也保证事务的唯一性要求。(其思想反复应用在各种数据库中).

下面我们总结下FileSore的特点:

  1. 无论是数据还是元数据都是先写日志盘,再由日志盘同步到数据盘。存在数据双写问题。
  2. 无论是数据还是元数据都是在文件系统层之上,存在文件系统层的写放大问题。
  3. 日志盘同步数据到数据盘时日志盘不能写入有性能问题。
  4. 为加速对元数据的访问,用键值数据库LevelDB来优化其访问,LevelDB为保证事务的持久化采用WAL。

BlueStore的诞生是为了解决FileStore同时维护一套日志系统和基于文件系统写放大的问题,实现FileStore本身没有的对SSD的最优支持

  1. BlueStore 数据是直接写入裸盘的,不存在双写问题
  2. BlueStore 数据写入的裸盘中是没有文件系统层的。
  3. 实现在用户态下使用linux aio直接对裸设备进行I/O操作,去除了本地文件系统的消耗,减少系统复杂度,更有利于Flash介质盘发挥性能优势
  4. 采用RockDB来存储对象的元数据和DB WALRocksDB是一种嵌入式高性能键/值存储。在闪存存储方面表现出色,RocksDB无法直接写入原始磁盘设备,需要底层文件系统来存储其持久化数据,因此设计了BlueFS
  5. BlueFS:简化的文件系统,解决元数据、文件及磁盘的空间分配和管理问题

无论是FileStore 还是BlueStore中为加速元数据的访问都使用键值存储数据库,键值存储数据是依赖文件系统的。FileStore 采用了LevelDB ,BlueStore采用了BlueFS .为了持久化存储事务日志都采用了预写日志的方式(DB WAL)。

因此在生产中FileStore一般是用SSD磁盘作为为日志盘来使用,而数据盘一般是HDD磁盘。 而在BlueStore环境中 一般是采用两块SSD磁盘 ,一块用作RockDB ,一块用作DB WAL。体现在命令上如下

FileStore 环境#--data 指定数据盘 --journal 指定日志盘,一般为分区。ceph-volume --cluster ceph lvm create --osd-id 0 /--filestore --data /dev/sdb--journal /dev/sda1
#--data 指定数据盘 --block.db 指定RocksDB --block.wal 指定WAL ceph-volume lvm create --bluestore \--data /dev/{data_device} \--block.db /dev/{db_device} \--block.wal /dev/{wal_device}

问题:如何判断一个Ceph集群使用的是FileStore还是BlueStore ?

通过磁盘的type来判断是比较通用的方式

[root@mon01 ~]# cat /var/lib/ceph/osd/ceph-0/type bluestore

写在最后

生产中存储系统的IO上限就决定了整个系统的磁盘IO的上限。因此为了追求极致的IO,仅仅对元数据的加速访问使用SSD或NVME磁盘是远远不够的。因此下一章节我们将介绍存储的缓存技术。聊下目前比较流行的两种存储的缓存技术。