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

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.

一.ceph概述本质上是rados:可靠的.自动的.分布式对象存储特性:高效性(大型的网络raid,性能无限接近raid).统一性(支持文件存储.块存储.对象存储).可扩展性数据库的一个弱点:查表ceph中没有数据库,集群状态全靠cluster map展示三种存储类型与rados的关系 补充云主机创建:nova-->libvirtd:虚拟机控制程序-->qemu(其他硬件的虚拟化)-kvm(cpu.内存的虚拟化)驱动-->云主机块存储创建:cinder-->backend驱动---

一.概述 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个数*副本数

本文中的命令的第一版来源于国外的一个博客,后面的版本为我自己修改的版本 查询的命令如下: 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

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上用

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

优化: 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

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-

1. 创建一个文件,并把该文件作为对象放到集群中: [root@node1 ~]# echo "this is test! " >>test.txt [root@node1 ~]# rados -p testpool ls [root@node1 ~]# rados -p testpool put test.txt test.txt [root@node1 ~]# rados -p testpool ls test.txt 2. 查看该对象对应的pg号以及osd组: [ro

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

PG和PGP调整经验调整前准备为了降低对业务的影响,需要调整以下参数ceph tell osd.* injectargs ‘–osd-max-backfills 1’ceph tell osd.* injectargs ‘–osd-recovery-max-active 1’ceph tell osd.* injectargs ‘–osd-recovery-max-single-start 1’计算pool合理的pg和pgp数量:计算公式:(单个osd上pg数,一般为100) x (osd数量)

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

ceph是目前开源分布式存储里面最好的一个,但是在高负载下会有很多异常的情况会发生,有些问题无法完全避免,但是可以进行一定的控制,比如:在虚拟化场景下,重启osd会让虚拟机挂起的情况 重新启动osd会给这个osd进程所在的磁盘带来额外的负载,随着前面业务的需求的增长,会增加对存储的I/O的需求,虽然这个对于整个业务系统来说是好事,但是在某些情况下,会越来越接近存储吞吐量的极限,通常情况下没有异常发生的时候,都是正常的,一旦发生异常,集群超过了临界值,性能会变得剧烈的抖动 对于这种情况,一般会升级

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

作者:吴香伟 发表于 2017/01/24 版权声明:可以任意转载,转载时务必以超链接形式标明文章原始出处和作者信息以及版权声明 存储QoS是个可以做很大也可以做很小的特性.SolidFire认为将QoS归类为特性太儿戏,QoS应该是存储系统设计之初就要仔细考虑的架构问题.的确,分析了一众主流存储大厂后还是觉得它在这方面做得最细致最全面.同时也有些厂商做得比较简陋,只提供了带宽或者IOPS的限速功能.这或许在某些场景中已经够用,但我认为一个完整的QoS方案至少要包括对带宽.IOPS的预留.上限和

Ceph集群管理 每次用命令启动.重启.停止Ceph守护进程(或整个集群)时,必须指定至少一个选项和一个命令,还可能要指定守护进程类型或具体例程. **命令格式如 {commandline} [options] [commands] [daemons] 常用的commandline为"ceph",对应的options如下表: 对应的commands如下表: 能指定的daemons(守护进程)类型包括mon,osd及mds. 通过SysVinit机制运行ceph: 在 CentOS.Re

ceph 管理 上次介绍了Ceph集群架构并且搭建了ceph集群,本节介绍ceph用户认证流程和挂载.cephFS.ceph RBD以及ceph mds高可用 1. ceph 授权流程和用户权限管理 1.1. ceph 认证机制 Ceph 使用 cephx 协议对客户端进行身份认证.cephx 用于对 ceph 保存的数据进行认证访问和授权,用于对访问 ceph 的请求进行认证和授 权检测,与 mon 通信的请求都要经过 ceph 认证通过,但是也可以在 mon 节点关闭 cephx 认证,但是

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 (5)Ceph 与 OpenStack 集成的实现 (6)QEMU-KVM 和 Ceph RBD 的 缓存机制总结 (7)Ceph 的基本操作和常见故障排除方法 (8)基本的性能测试工具和方法 (9) pool 的size 和 min_size,choose 和 chooseleaf,pg scru

作者:吴香伟 发表于 2014/10/10 版权声明:可以任意转载,转载时务必以超链接形式标明文章原始出处和作者信息以及版权声明 心跳是用于OSD节点间检测对方是否故障的,以便及时发现故障节点进入相应的故障处理流程.故障检测需要在故障的发现时间和心跳带来的负载之间做权衡,如果心跳频率太高则过多的心跳报文会影响系统性能,如果心跳频率过低则会延长发现故障节点的时间,从而影响系统的可用性. 建立连接 在大规模部署的场景中,如果任意两个OSD节点间都建立心跳连接将带来巨大的负担.尤其,当新加入一个OSD