上一章我们成功部署了bcache,这一章我们将Ceph与Bcache结合来使用,使用Bcache来为ceph的数据盘提速。
1 ceph 架构
一个标准的ceph集群可能是如下的架构,SSD/NVME 存储元数据,而SATA盘存储数据。这样的架构下,物理介质的SATA盘读写速率上限决定了存储集群Ceph的上限(木桶效应)。如果在此架构下我们给SATA盘加上一层缓存层.
在官方文档中给出了缓存层的结构如下
其整体思路都是一样,只是缓存层的方案因此长时间没有人维护。目前还处在非生产可用阶段 。
而bcache 技术则是经过了时间的洗礼,在ceph缓存技术中是比较成熟的方案。
则采用Bcache存储架构变成了如下架构。
在此架构下我们将Bcache的模式修改为writeback模式,则在使用缓存的情况下Ceph对数据盘写入性能得到了极大的提升。在生产环境中我们只需要专注于解决增加缓存的命中率即可。实际上大多数生产环境正是这么做的。
2 部署
在第十三章中我们介绍了ceph单节点的部署,如果你还没有一个单节点的ceph环境,那赶紧跳转回去,在自己的虚拟机环境上搭建一个最小的ceph环境。
我们只需要在ceph osd部署时将 --data 盘的参数指向bcache 则即可以完成上述架构的部署
ceph-volume --cluster ceph lvm create --bluestore \
--data /dev/bcache0 --block.db /dev/sde1
ceph-volume --cluster ceph lvm create --bluestore \
--data /dev/bcache1 --block.db /dev/sde2
ceph-volume --cluster ceph lvm create --bluestore \
--data /dev/bcache2 --block.db /dev/sde3
此时的--data 指定了数据盘为bcache0 、bcache1、bcache2,sde盘的分区1、2、3 则对应了block.db 。
此时在查看ceph集群的状态
3 思考
每一个数据盘都对应一个三级目录结构如下
sdd
└─bcache0
└─ceph--f015264a--34a3--484e--b17a--1811290fea04-osd--block--c6b8e971--5246--46db--93f8--0ceda4626015
3.1 其中这一长串都是到底是什么?
知晓LVM是什么的小伙伴可以清晰看出,右边这一侧是LV(Logical Volume编号,而左边这一侧是 VG (Volume Group)编号。
我们知道,LVM --VG --PV 对应一个三级结构,因此知道了VG ,通过 vgdisplay
pvdisplay
就能知晓了PV ,而PV 一般就是一个分区或磁盘,此时对应ceph集群就是BcacheX,此时X是Bcache的编号。通过Bcache的编号,在结合lsblk
就知晓了真正存储数据的后端数据盘的盘符。
(注意 lsblk
输出的VG 和LV编号分隔符是带两个--而,vgdisplay
和lvdisplay
都是一个-做为分隔符,因此在搜索时过滤最后1段就行)
3.2 为什么我们要知晓这些?或者换一句话说知道这些有什么用了?
我们知道ceph的数据盘在ceph中表现为一个osd.2 等数字,现在问题来了,如果osd.2 坏了需要换盘,你怎么知道osd.2对应的数据盘是哪一块盘了?
总结下来就是如下图所示
从图中可以知道osd 对应编号 和磁盘的对应关系,那和VG LVM编号又有什么关系了,通过osd的安装目录就已经知晓了 磁盘和osd的对应的关系。管他什么LV VG了。
我们试想一个这样一个场景如果bcache2坏了,此时lsblk显示的ceph字段自然也不存在了?你怎么关联osd编号和磁盘的对应关系了?此时VG和PV就派上了用途。
因此作者建议在学习时,不要做一个工具人,而是要做到知其然也要知其所以然。
3.3 有没有简单命令 一眼就能看出的其对应关系的 ?
ceph-volume lvs list
命令就可以直接实现
写在最后:
目前我们已经完成了一个最小化的ceph集群,ceph作为一个分布式存储,知晓其概念,并进行维护是一项艰巨的任务,记下来我们将从理论到实践,重点阐述下ceph运维技巧。
标签:ceph,VG,--,dev,Ceph,OpenStack,Bcache,osd From: https://www.cnblogs.com/alex0815/p/18397410