原文:http://www.cnblogs.com/me115/p/6366374.html Pool是存储对象的逻辑分区,它规定了数据冗余的类型和对应的副本分布策略:支持两种类型:副本(replicated)和 纠删码( Erasure Code):目前我们公司内部使用的Pool都是副本类型(3副本): PG( placement group)是一个放置策略组,它是对象的集合,该集合里的所有对象都具有相同的放置策略:简单点说就是相同PG内的对象都会放到相同的硬盘上: PG是 ceph的核心概念

优化: PG Number PG和PGP数量一定要根据OSD的数量进行调整,计算公式如下,但是最后算出的结果一定要接近或者等于一个2的指数.调整PGP不会引起PG内的对象的分裂,但是会引起PG的分布的变动三.总结PG是指定存储池存储对象的目录有多少个,PGP是存储池PG的OSD分布组合个数PG的增加会引起PG内的数据进行分裂,分裂到相同的OSD上新生成的PG当中PGP的增加会引起部分PG的分布进行变化,但是不会引起PG内对象的变动 Total PGs = (Total_number_of_OSD

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 (5)Ceph 与 OpenStack 集成的实现 (6)QEMU-KVM 和 Ceph RBD 的 缓存机制总结 (7)Ceph 的基本操作和常见故障排除方法 (8)关于Ceph PGs https://docs.google.com/presentation/d/1_0eIWNYWvJON4Gr

1 PG介绍pg的全称是placement group,中文译为放置组,是用于放置object的一个载体,pg的创建是在创建ceph存储池的时候指定的,同时跟指定的副本数也有关系,比如是3副本的则会有3个相同的pg存在于3个不同的osd上,pg其实在osd的存在形式就是一个目录,可以列出来看下: [root@abc ~]# ll /var/lib/ceph/osd/ceph-/current/ total drwxr-xr-x root root Sep : .11_head drwxr-xr-

以前我们需要对ssd和hdd进行分组的时候,需要大量的修改crush map,然后绑定不同的存储池到不同的 crush 树上面,现在这个逻辑简化了很多.以上是官方宣传听起来很不错等到12.2.0稳定版出来以后参考http://ceph.com/planet/ceph-luminous-%E6%96%B0%E5%8A%9F%E8%83%BD%E4%B9%8B%E7%A3%81%E7%9B%98%E6%99%BA%E8%83%BD%E5%88%86%E7%BB%84/进行尝试发现稳定版与此文有些不同

前言 性能优化大神Brendan Gregg发明了火焰图来定位性能问题,通过图表就可以发现问题出在哪里,通过svg矢量图来查看性能卡在哪个点,哪个操作占用的资源最多 在查看了原始数据后,这个分析的原理是按层级来对调用进行一个计数,然后以层级去做比对,来看横向的占用的比例情况 基于这个原理,把osd tree的数据和pg数据可以做一个层级的组合,从而可以很方便的看出pg的分布情况,主机的分布情况,还可以进行搜索,在一个简单的图表内汇聚了大量的信息 实践 获取需要的数据,这个获取数据是我用一个脚本解

今天检查ceph集群,发现有pg丢失,于是就有了本文~~~ 1.查看集群状态 [root@k8snode001 ~]# ceph health detail HEALTH_ERR 1/973013 objects unfound (0.000%); 17 scrub errors; Possible data damage: 1 pg recovery_unfound, 8 pgs inconsistent, 1 pg repair; Degraded data redundancy: 1/29

转自:https://www.ustack.com/blog/ceph-pg-fenlie/ 1 pg分裂 Ceph作为一个scalable的分布式系统,集群规模会逐渐增大,为了保证数据分布的均匀性,好的做法是在扩容时根据集群规模适当调整pg_num和pgp_num的值. PG作为Ceph数据流过程的中间层,它的数目pg_num和另一个值pgp_num(二者一般是相等的)直接影响集群的数据分布情况.pgp_num决定了多少pg会拿来存放数据,也就是说并不是所有创建出来的pg都会存放数据.理论上来

我的ceph集群中有4台服务器,16个osd,因为某些原因,集群中的数据都不要了,但是集群要保留给新的应用使用,集群现有的osd情况如下 [root@ceph-host-01 ~]# cat /etc/hosts 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1         localhost localhost.localdomain localhost6 localhost

1. 查看PG (ceph-mon)[root@controller /]# ceph pg stat 512 pgs: 512 active+clean; 0 bytes data, 1936 MB used, 447 GB / 449 GB avail (ceph-mon)[root@controller /]# ceph pg dump 2. pg映射OSD位置 (ceph-mon)[root@controller /]# ceph pg map 3.5d osdmap e53 pg 3.

一.概述 osd上pg的分布决定了数据分布的均匀与否,所以能直观的看到pg到osd的上分布是很有必要的: ceph只身提供了相关的命令: #ceph pg ls-by-osd.{osd_id} #for i in `ceph osd ls`; do ceph pg ls-by-osd osd.$i |awk '{print $1}' >> /tmp/aaa ;done #NOTE: 每次osd输出,第一行有一个pg_stat,需要去掉之后,就可以获取pg总数是ceph -s中 pg个数*副本数

https://www.jianshu.com/p/36c2d5682d87 1. PG介绍 继上次分享的<Ceph介绍及原理架构分享>,这次主要来分享Ceph中的PG各种状态详解,PG是最复杂和难于理解的概念之一,PG的复杂如下: 在架构层次上,PG位于RADOS层的中间. a. 往上负责接收和处理来自客户端的请求. b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务. 是组成存储池的基本单位,存储池中的很多特性,都是直接依托于PG实现的. 面向容灾域的备份策略使得一般而言的

前文我们了解了ceph集群状态获取常用命令以及通过ceph daemon.ceph tell动态配置ceph组件.ceph.conf配置文件相关格式的说明等,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/16727820.html:今天我们来聊一聊ceph的存储池.PG以及CRUSH相关话题: 一.关于存储池 我们知道ceph客户端存储对象数据到RADOS集群上,不是客户端直接存储到osd上:首先客户端会根据ceph集群的配置,将客户端存储的对象数据切分多

1. PG介绍 PG, Placement Groups.CRUSH先将数据分解成一组对象,然后根据对象名称.复制级别和系统中的PG数等信息执行散列操作,再将结果生成PG ID.可以将PG看做一个逻辑容器,这个容器包含多个对象,同时这个逻辑对象映射之多个OSD上. 如果没有PG,在成千上万个OSD上管理和跟踪数百万计的对象的复制和传播是相当困难的.没有PG这一层,管理海量的对象所消耗的计算资源也是不可想象的.建议每个OSD上配置50~100个PG. 2. 计算PG数 一般的, Ceph集群中的P

1  调高osd的日志等级 加上红框那一行就可以了 osd的日志路径:/var/log/ceph/ceph-osd.3.log 注意:加上了这一行后日志会刷很多,所以要特别注意日志容量的变化,以防把var目录写满了 2  缺少osdmap或者错误的osdmap 从osd日志中发现这两种错误都是属于osdmap不正常,可以从其它正常osd上拷贝osdmap到对应启动错误的osd上,假设不正常的osdmap序号是816,上图的是27601和671651 如以下图: 在一个正常osd上如osd.4上用

https://www.jianshu.com/p/ae96ee24ef6c 调整ceph的pg数 PG全称是placement groups,它是ceph的逻辑存储单元.在数据存储到cesh时,先打散成一系列对象,再结合基于对象名的哈希操作.复制级别.PG数量,产生目标PG号.根据复制级别的不同,每个PG在不同的OSD上进行复制和分发.可以把PG想象成存储了多个对象的逻辑容器,这个容器映射到多个具体的OSD.PG存在的意义是提高ceph存储系统的性能和扩展性. 如果没有PG,就难以管理和跟踪数

http://www.zphj1987.com/2016/10/19/Ceph%E4%B8%ADPG%E5%92%8CPGP%E7%9A%84%E5%8C%BA%E5%88%AB/ 一.前言 首先来一段英文关于PG和PGP区别的解释: PG = Placement GroupPGP = Placement Group for Placement purpose pg_num = number of placement groups mapped to an OSD When pg_num is

在一个ceph集群中,操作创建一个池后,发现ceph的集群状态处于warn状态,信息如下 检查集群的信息 查看看池 [root@serverc ~]# ceph osd pool ls images #只有一个池 [root@serverc ~]# ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.13129 root default -5 0.04376 host serverc 2 hdd 0.01459

一.心跳选项 完成基本配置后就可以部署.运行 Ceph 了.执行 ceph health 或 ceph -s 命令时,监视器会报告 Ceph 存储集群的当前状态.监视器通过让各 OSD 自己报告.并接收 OSD 关于邻居状态的报告来掌握集群动态.如果监视器没收到报告,或者它只收到集群的变更报告,那它就要更新集群运行图. 关于监视器与 OSD 的交互 Ceph 提供了合理的默认值,然而你可以覆盖它们.下面几段从集群监控角度描述了 Ceph 监视器与 OSD 如何交互. OSD 验证心跳 各 OSD

前言 本篇的内容实际上是另外一篇文章的字篇章,在另外一篇文章当中,将会对crush的分布的调整的做一次总结,用比较简单的方式来展示各种crush的区别 在做这个工作过程中,为了更好的能展示出效果,就有了下面的这个小工具的出现 工具来源 假如我现在想查看一个存储池内的pg的分布,那么我们需要下面的几个步骤 1.随机获取一个pg的id [root@lab101 ~]# ceph pg dump|grep ^0 后面的是存储池的编号 从输出中拿到0.196开头的这个pg 0.196 0 0 0 0 0

本文中的命令的第一版来源于国外的一个博客,后面的版本为我自己修改的版本 查询的命令如下: ceph pg dump | awk ' /^pg_stat/ { col=1; while($col!="up") {col++}; col++ } /^[0-9a-f]+\.[0-9a-f]+/ { match($0,/^[0-9a-f]+/); pool=substr($0, RSTART, RLENGTH); poollist[pool]=0; up=$col; i=0; RSTART=0