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

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

前言 这个问题来源于我们研发的一个问题,在进行pg调整的时候,是一次调整到位好,还是分多次调整比较好,分多次调整的时候会不会出现某个pg反复挪动的问题,造成整体迁移量大于一次调整的 最近自己的项目上也有pg调整的需求,这个需求一般来源于pg规划好了,后期出现节点扩容的情况,需要对pg进行增加的调整 本篇用具体的数据来分析两种方式的差别 因为本篇的篇幅较长,直接先把结论拿出来 数据结论 调整pg 迁移pg 迁移对象 1200->1440 460 27933 1440->1680 458 2773

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

前言 很久没有处理很大的集群,在接触一个新集群的时候,如果集群足够大,需要比较长的时间才能去理解这个集群的结构,而直接去看ceph osd tree的结果,当然是可以的,这里是把osd tree的结构进行了一个结构化输出,也可以理解为画出一个简单的结构图,比较适合给其它人讲解你对crush做了哪些改变,这个如果指着文字来讲估计很多人会听的云里雾里,如果有比较方便的方式出图就比较好了 为此写了一个小工具自己用,正好也可以看看我们对结构做简单调整后的效果 创建一个模拟集群 环境就一台机器,不需要用到

前言 之前看过一个朋友一篇文章,讲述的是Vsan为什么使用的是两副本,而ceph则大多数情况下需要三副本,当时个人观点是这个并不是关键点,但是在仔细考虑了问题的出发点以后,这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看 发生丢失数据的事件,这个来说,出现这个事件的概率是一致的,同等硬件情况下没有谁的系统能够说在两副本情况下把这个出现坏盘概率做的比其他系统更低 发生坏盘事件以后,数据丢失波及的范围,这个就是那个朋友提出的一个观点,对于Vsan来说因为文件的不拆分,也就是在丢了的情况下

在Ceph的osd节点上,启动osd进程失败,查看其日志/var/log/ceph/ceph-osd.{osd-index}.log日志,报错如下: 2017-02-14 16:26:13.558535 7fe3883f58c0 0 filestore(/var/lib/ceph/osd/ceph-1) mount: enabling WRITEAHEAD journal mode: checkpoint is not enabled 2017-02-14 16:26:13.558712 7fe

直接上干货: ceph自动挂载原理 系统启动后,ceph 通过扫描所有磁盘及分区的 ID_PART_ENTRY_TYPE 与自己main.py中写死的osd ready 标识符来判断磁盘(及其分区)是否准备好自动挂载(journal ,block, osd 同是一个道理) main.py中记载的状态标志 /usr/lib/python2./site-packages/ceph_disk/main.py 'osd': { 'ready': '4fbd7e29-9d25-41b8-afd0-062c

正常状态:

ceph osd 批量删除,注意删除的是当前节点正在使用的osd,数据删除有风险,所以最后一步没有去format磁盘,给你留下一剂后悔药. #!/bin/bash osd_list=`mount|grep osd|awk '{print $3}'|awk -F'-' '{print $2}'` for var in $osd_list; do echo "ceph osd out $var" ceph osd out $var echo "service ceph-osd s

正常状态: 故障状态: 实施更换步骤: (1)关闭ceph集群数据迁移: osd硬盘故障,状态变为down.在经过mod osd down out interval 设定的时间间隔后,ceph将其标记为out,并开始进行数据迁移恢复.为了降低ceph进行数据恢复或scrub等操作对性能的影响,可以先将其暂时关闭,待硬盘更换完成且osd恢复后再开启: for i in noout nobackfill norecover noscrub nodeep-scrub;do ceph osd set $

前言 如果看到标题,你是不是第一眼觉得写错了,这个怎么可能,完全就是两个不相关的东西,最开始我也是这么想的,直到我发现真的是这样的时候,也是很意外,还是弄清楚下比较好,不然在某个操作下,也许就会出现意想不到的情况 定位 如果你看过我的博客,正好看过这篇 <<ceph在centos7下一个不容易发现的改变>> ,那么应该还记得这个讲的是centos 7 下面通过udev来实现了osd的自动挂载,这个自动挂载就是本篇需要了解的前提 [root@lab101 ~]# df -h|grep

前言 本篇来源于群里一个人的问题,有没有办法让ceph的磁盘不自动挂载,一般人的问题都是怎样让ceph能够自动挂载,在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的,这个我之前也写过两篇文章<ceph在centos7下一个不容易发现的改变>和<Ceph数据盘怎样实现自动挂载>,来讲述这个自动挂载的 这里讲下流程: 开机后 udev 匹配 95-ceph-osd.rules 规则,触发 ceph-disk trigger,遍历磁盘,匹配到磁盘的标记后就触

前言 这个工具我第一次看到是在填坑群里面看到,是由研发-北京-蓝星同学分享的,看到比较有趣,就写一篇相关的记录下用法 火焰图里面也可以定位内存方面的问题,那个是通过一段时间的统计,以一个汇总的方式来查看内存在哪个地方可能出了问题 本篇是另外一个工具,这个工具的好处是有很清晰的图表操作,以及基于时间线的统计,下面来看下这个工具怎么使用的 本篇对具体的内存函数的调用占用不会做更具体的分析,这里是提供一个工具的使用方法供感兴趣的研发同学来使用 环境准备 目前大多数的ceph运行在centos7系列上面

前言 前段时间看到豪迈的公众号上提到了这个离线转换工具,最近看到群里有人问,找了下没什么相关文档,就自己写了一个,供参考 实践步骤 获取代码并安装 git clone https://github.com/ceph/ceph.git cd ceph git submodule update --init --recursive ./make-dist rpm -bb ceph.spec 生成rpm安装包后进行安装,这个过程就不讲太多,根据各种文档安装上最新的版本即可,这个代码合进去时间并不久,大

前言 之前有一篇文章介绍的是,在centos7的jewel下面如果自己做的分区如何处理自动挂载的问题,当时的环境对journal的地方采取的是文件的形式处理的,这样就没有了重启后journal的磁盘偏移的问题 如果采用的是ceph自带的deploy去做分区的处理的时候,是调用的sgdisk去对磁盘做了一些处理的,然后deploy能够识别一些特殊的标记,然后去做了一些其他的工作,而自己分区的时候,是没有做这些标记的这样就可能会有其他的问题 我们看下如何在部署的时候就处理好journal的uuid的

参数化的定义:使用指定的数据源中的值来替换脚本录制生成的语句中的参数. 对Vuser脚本进行参数化的好处: 1.减小脚本的大小 2.提供了使用不同的脚本的值执行脚本的能力 参数化涉及两个任务: 1.用参数替换Vuser脚本的常量值 2.为参数设置属性和数据源 "Select next row"定义的是如何选择下一行数据.该处有三个选项"Sequential","Random","Unique", Sequential:顺序地向

参考文档:http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/architecture/architectureDataDistributeAbout_c.html#concept_ds_g43_g3f_fk 在Cassandra中,数据分配和复制是同时进行的.这是因为Cassandra被设计为一个点对点的系统,数据有多个复制,被分发到一组节点上.数据按照表的形式构建以主键进行标识.主键

作为刚开始学习Loadrunner的新人,Data Assignment Method以及Update Method在相互组合之后,LR如何进行取值让我很是头疼. 于是花了一个晚上的时间认真学习官方文档并且编写代码来实际验证,最后把个人的学习成果以及理解全部总结在博客里,分享给大家希望能给大家帮助. 第一部分: Data Assignment Method及Update Method根据官方文档作出的总结: Data Assignment Method(数据分配方法),在Vuser脚本执行过程中

数据分配方法: 在“Select next row“列表中选择一个数据分配方法,以指示在Vuser脚本执行期间如何从参数文件中取得数据.选项包括”Sequential“.“Random”.“Unique”,详情描述参见下表 分配方法 描述 Sequential(顺序) “顺序”方法顺序地想Vuser分配数据.当正在运行的Vuser访问数据表时,会提取下一个可用的数据行.如果在数据表中没有足够的值,则Vuser返回到表中的第一个值,循环直至到测试结束. Random( 随机) “随机”方法为每个V

之前一直用翻滚窗口,每条数据都只属于一个窗口,所有不需要考虑数据需要在多个窗口存的事情. 刚好有个需求,要用到滑动窗口,来翻翻 flink 在滑动窗口中,数据是怎么分配到多个窗口的 一段简单的测试代码: val input = env.addSource(kafkaSource) val stream = input .map(node => { Event(node.get("id").asText(), node.get("createTime").asT