![](https://img-blog.csdnimg.cn/20201014180756738.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Ceph
文章平均质量分 83
mxy990811
这个作者很懒,什么都没留下…
展开
-
ceph之rados设计原理与实现第七章:在线数据恢复——Recovery和Backfill
由于每个写操作都需要产生和操作日志,所以处于效率考虑,必须定时对日志进行裁剪。由于PG保存的日志条目有限,按照能否依靠日志进行数据恢复,存在两种数据恢复方式,分别为Recovery和Backfill。Recovery指只需要修复副本(PG)上与权威日志不同步的那部分对象(即降级对象即可)。missing已经记录Backfill指以PG全体对象为目标的数据迁移过程。例如所在OSD离线太久而期间产生大量客户端发起的读写请求,或者Ceph自身出于数据重平衡需要而执行Backfill。原创 2024-01-23 15:33:51 · 1260 阅读 · 0 评论 -
ceph之rados设计原理与实现第六章:移动的对象载体——PG
Peering确保PG的所有对象副本在OSD间的一致性,但为了尽快恢复业务(Peering时无法接受客户端读写请求,所以Peering时间要尽可能短),Peering过程标记出降级的PG(比如OSD故障导致PG降级)即可算完成,之后这些故障的OSD上面的数据需要通过增量日志或者全量同步的方式恢复到由CRUSH或者PG Temp计算出的新OSD上,会触发Recovery或Backfill,数据恢复的过程就是Recovery或Backfill。这样就造成了Acting与Up不一致的Remapped状态。原创 2024-01-23 09:52:18 · 1130 阅读 · 0 评论 -
ceph之rados设计原理与实现第二章:计算寻址之美与数据平衡之殇crush
因为针对上述参数的调整都是需要人工干预,都是多次微调实际非常麻烦,并且实际生产环境ceph扩容或者故障导致的pg自动迁移非常频繁,每次pg迁移后之前的调整都付之东流,因此自动化调整应运而生。"crushmap"包含了数据中心、机架、主机、osd等整个拓扑结构,除了osd都是虚拟的,并且记录了每个osd的weight和reweight,weight和reweight直接影响了随机哈希算法结果,但是由于crush是随机的,所以调整weight、reweight并不能精确控制pg在osd上的分布。原创 2023-12-29 15:12:29 · 526 阅读 · 0 评论 -
ceph之rados设计原理与实现第三章:集群的大脑monitor
Monitor和核心是OSD Monitor,利用分布式领域的一致性算法Paxos来维护集群唯一的一张表OSDMap。Monitor采用分担负荷的方式,一个集群可以有多个Monitor节点,任何时刻,任何客户端或者OSD都可以通过和任意一个Monitor进行交互,以索取或者请求更新集群表OSDMap。原创 2024-01-03 13:59:18 · 595 阅读 · 0 评论 -
ceph之rados设计原理与实现第四章:存储的基石OSD
OSD本质上是凌驾于操作系统之上的进程,拥有cpu、内存、网络带宽等资源,用于实现对象存储,并兼容各种类型的文件系统。OSD之间利用集群网络互相监督,出现故障及时上报Monitor,由Monitor修改OSDMap后,再由OSD之间互相点对点传播最新OSDMap。原创 2024-01-04 14:25:47 · 766 阅读 · 0 评论 -
ceph之rados设计原理与实现第五章:高效的本地对象存储引擎Bluestore
由于FileStore底层仍然通过操作系统自带的本地文件系统管理磁盘,所以为了能够使用本地文件系统,所有针对RADOS的操作都需要转换成POSIX语义。所以引入了BlueStore直接管理文件。原创 2024-01-09 17:07:31 · 940 阅读 · 0 评论