每天5分钟复习OpenStack（十二）Ceph FileStore 和 BlueSotre_ceph12 是filestore还是bulestore-CSDN博客

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

1、MGR 部署
创建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
2
3
4
5
6
7
修改目录的属主和属组为ceph用户，并启动ceph-mgr 进程
chown -R ceph:ceph /var/lib/ceph/mgr/
systemctl restart ceph-mgr@mon01
systemctl enable ceph-mgr@mon01
1
2
3
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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
此时发现mgr: mon01 显示active 为活动状态表示部署成功。 但是Ceph 集群的状态还是显示为HEALTH_WARN。

问题1 ： 1 monitors have not enabled msgr2
msgr2 协议 是Ceph中的新消息传递协议，它带来了一些性能和安全性方面的改进。在集群中，所有的监视器都应该启用msgr2以确保它们之间使用最新的消息传递协议。
总结：
msgr是MON用来消息传递的协议，目前有两个版本V1 和V2 ，V1版本使用6789端口，
V2版本使用3300端口。

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

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

【实验】 禁止本机3300端口

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

现在我们使用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
1
2
3
2、OSD 部署
OSD的安装可以分两步：初始化、激活，也可以一步到位。

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

#激活
ceph-volume lvm activate 0 acdadb1a-ed18-4068-bbcb-432ba0cfcdb2
1
2
验证第一个osd

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

ceph-volume lvm create --data /dev/sdc
ceph-volume lvm create --data /dev/sdd
1
2

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

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

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

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

写日志有两种模式：Parallel和Writeahead。

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的特点：

无论是数据还是元数据都是先写日志盘，再由日志盘同步到数据盘。存在数据双写问题。
无论是数据还是元数据都是在文件系统层之上，存在文件系统层的写放大问题。
日志盘同步数据到数据盘时日志盘不能写入有性能问题。
为加速对元数据的访问，用键值数据库LevelDB来优化其访问,LevelDB为保证事务的持久化采用WAL。
BlueStore的诞生是为了解决FileStore同时维护一套日志系统和基于文件系统写放大的问题，实现FileStore本身没有的对SSD的最优支持

 

BlueStore 数据是直接写入裸盘的，不存在双写问题
BlueStore 数据写入的裸盘中是没有文件系统层的。
实现在用户态下使用linux aio直接对裸设备进行I/O操作，去除了本地文件系统的消耗，减少系统复杂度，更有利于Flash介质盘发挥性能优势
采用RockDB来存储对象的元数据和DB WAL 。RocksDB是一种嵌入式高性能键/值存储。在闪存存储方面表现出色，RocksDB无法直接写入原始磁盘设备，需要底层文件系统来存储其持久化数据，因此设计了BlueFS。
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
1
2
3
4
#--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}

1
2
3
4
5
6
问题：如何判断一个Ceph集群使用的是FileStore还是BlueStore ?

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

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

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

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/weixin_45645078/article/details/134818150

发表评论

邮箱地址不会被公开。 必填项已用*标注