前言之前有个想法，是不是有办法找到rbd中的文件与对象的关系，想了很久但是一直觉得文件系统比较复杂，在fs 层的东西对ceph来说是透明的，并且对象大小是4M，而文件很小，可能在fs层进行了合并，应该很难找到对应关系，最近看到小胖有提出这个问题，那么就再次尝试了，现在就是把这个实现方法记录下来
这个提取的作用个人觉得最大的好处就是一个rbd设备，在文件系统层被破坏以后，还能够从rbd提取出文件，我们知道很多情况下设备的文件系统一旦破坏，无法挂载，数据也就无法读取，而如果能从rbd中提取出文件，这就是保证了即使文件系统损坏的情况下，数据至少不丢失
本篇是基于xfs文件系统情况下的提取，其他文件系统有时间再看看，因为目前使用的比较多的就是xfs文件系统
本篇也回答了一个可能会经常被问起的问题，能告诉我虚拟机里面的文件在后台存储在哪里么，看完本篇就知道存储在哪里了
XFS文件系统介绍1234567891011[root@lab8106 ~]# mkfs.xfs -f /dev/rbd0p1 warning: device is not properly aligned /dev/rbd0p ...
前言性能优化大神Brendan Gregg发明了火焰图来定位性能问题，通过图表就可以发现问题出在哪里，通过svg矢量图来查看性能卡在哪个点，哪个操作占用的资源最多
在查看了原始数据后，这个分析的原理是按层级来对调用进行一个计数，然后以层级去做比对，来看横向的占用的比例情况
基于这个原理，把osd tree的数据和pg数据可以做一个层级的组合，从而可以很方便的看出pg的分布情况，主机的分布情况，还可以进行搜索，在一个简单的图表内汇聚了大量的信息
实践获取需要的数据，这个获取数据是我用一个脚本解析的osd tree 和pg dump，然后按照需要的格式进行输出
default;lab8106;osd.2;0.0 6default;lab8106;osd.3;0.0 6default;rack1;lab8107;osd.0;0.0 6
需要的格式是这个样的，最后一个为权重，使用的是对象数，因为对象数可能为0，所以默认在每个数值进行了加一的操作，前面就是osd的分布的位置
脚本/sbin/stackcollapse-crush内容如下：
1234567891011121 ...
前言文件系统当中如果某些文件不见了，有什么办法判断是删除了还是自己不见了，这个就需要去日志里面定位了，通常情况下是去翻日志，而日志是会进行压缩的，并且查找起来非常的不方便,还有可能并没有开启
这个时候就需要日志系统了，最近正好看到一篇最佳日志实践（v2.0），一篇非常好的文章，本篇日志属于文章里面所提到的统计日志，统计客户端做了什么操作
对于日志系统来说，很重要的一点，能够很方便的进行查询，这就需要对日志信息进行一些处理了，怎么处理就是设计问题，要求就是不多不少
结构
其中graylog配置部分在这篇使用日志系统graylog获取Ceph集群状态，根据这篇的操作，配置出12201的udp监听端口即可，剩余部分就是本篇中的配置
配置集群的配置需要对MDS的配置进行debug_ms=1,在/etc/ceph/ceph.conf当中添加下面配置
123[mds.lab8106]debug_ms=1hostname=lab8106
这个地方集群的文件操作日志是记录在message里面的1级别的，所以把mds的debug_ms开到1日志长这个样子：
120 ...
前言本篇是luminous一个新功能介绍，关于磁盘智能分组的，这个在ceph里面叫crush class，这个我自己起名叫磁盘智能分组，因为这个实现的功能就是根据磁盘类型进行属性关联，然后进行分类，减少了很多的人为操作
以前我们需要对ssd和hdd进行分组的时候，需要大量的修改crush map，然后绑定不同的存储池到不同的 crush 树上面，现在这个逻辑简化了很多
ceph crush class {create,rm,ls} manage the new CRUSH deviceclass feature. ceph crush set-device-class will set the clas for a particular device.
Each OSD can now have a device class associated with it (e.g., hdd orssd), allowing CRUSH rules to trivially map data to a subset of devicesin the system. Manually w ...
前言ceph luminous版本新增加了很多有意思的功能，这个也是一个长期支持版本，所以这些新功能的特性还是很值得期待的，从底层的存储改造，消息方式的改变，以及一些之前未实现的功能的完成，都让ceph变得更强，这里面有很多核心模块来自中国的开发者，在这里准备用一系列的文章对这些新功能进行一个简单的介绍，也是自己的一个学习的过程
相关配置配置ceph国内源修改 /etc/yum.repos.d/ceph.repo文件
12345678[ceph]name=cephbaseurl=http://mirrors.163.com/ceph/rpm-luminous/el7/x86_64/gpgcheck=0[ceph-noarch]name=cephnoarchbaseurl=http://mirrors.163.com/ceph/rpm-luminous/el7/noarch/gpgcheck=0
添加完更新下缓存
1yum makecache
前一段时间163源上的ceph没有了，可能是误操作的，现在的163源已经恢复，上面添加的是最新的luminous版 ...
前言这个问题来源于我们研发的一个问题，在进行pg调整的时候，是一次调整到位好，还是分多次调整比较好，分多次调整的时候会不会出现某个pg反复挪动的问题，造成整体迁移量大于一次调整的
最近自己的项目上也有pg调整的需求，这个需求一般来源于pg规划好了，后期出现节点扩容的情况，需要对pg进行增加的调整
本篇用具体的数据来分析两种方式的差别
因为本篇的篇幅较长，直接先把结论拿出来
数据结论
调整pg
迁移pg
迁移对象
1200->1440
460
27933
1440->1680
458
27730
1680->1920
465
27946
1920->2160
457
21141
2160->2400
458
13938
总和
2305
132696
调整pg
迁移pg
迁移对象
1200->2400
2299
115361
结论：分多次调整的时候，PG迁移量比一次调整多了6个，多了0.2%，对象的迁移量多了17335，多了15%
从数据上看pg迁移的数目基本一样，但是数据量是多了15%，这个是因为分多次 ...
前言在看集群的配置文件的时候看到ceph里面有一个graylog的输出选择，目前看到的是可以收集mon日志和clog，osd单个的日志没有看到，Elasticsearch有整套的日志收集系统，可以很方便的将所有日志汇总到一起，这个graylog的收集采用的是自有的udp协议，从配置上来说可以很快的完成，这里只做一个最基本的实践
系统实践graylog日志系统主要由三个组件组成的
MongoDB – 存储配置信息和一些元数据信息的，MongoDB (>= 2.4)
Elasticsearch – 用来存储Graylog server收取的log messages的，Elasticsearch (>= 2.x)
Graylog server – 用来解析日志的并且提供内置的web的访问接口
配置好基础源文件
CentOS-Base.repoepel.repo
安装java要求版本Java (>= 8)
1yum install java-1.8.0-openjdk
安装MongoDB安装软件
1yum install mongodb ...
前言最近在群里两次看到出现mon地址不对的问题，都是显示0.0.0.0:0地址，如下所示：
12345[root@lab8106 ceph]# ceph -s cluster 3137d009-e41e-41f0-b8f8-5cb574502572 health HEALTH_ERR 1 mons down, quorum 0,1,2 lab8106,node8107,lab104 monmap e2: 4 mons at {lab104=192.168.10.4:6789/0,lab8106=192.168.8.106:6789/0,lab8107=0.0.0.0:0/2,node8107=192.168.8.107:6789/0}
这个之前偶尔会看到有出现这个问题，但是自己一直没碰到过，想看下是什么情况下触发的，在征得这个cepher的同意后，登录上他的环境检查了一下，发现是主机名引起的这个问题
问题复现在部署的过程中，已经规划好了主机名，而又去修改了这个机器的主机名的情况下就会出现这个问题比如我的这个机器，开始规划 ...
前言这个问题存在有一段时间了，之前做的centos7的ISO，在进行内核的升级以后就存在这个问题：
系统盘在板载sata口上是可以正常启动新内核并且能识别面板硬盘
系统盘插在面板口上新内核无法启动，调试发现无法找到系统盘
系统盘插在面板上默认的3.10内核可以正常启动
暂时的解决办法就是让系统插在板载的sata口上，因为当时没找到具体的解决办法，在这个问题持续了一段时间后，最近再次搜索资料的时候，把问题定位在了initramfs内的驱动的问题，并且对问题进行了解决
解决过程查询initramfs的驱动
123[root@lab103 lab103]# lsinitrd -k 3.10.0-327.el7.x86_64|grep mpt[23]sasdrwxr-xr-x 2 root root 0 Apr 17 12:05 usr/lib/modules/3.10.0-327.el7.x86_64/kernel/drivers/scsi/mpt2sas-rw-r--r-- 1 root root 337793 Nov 20 ...
前言freebsd10.2环境在安装一个新软件包的时候提示升级pkg到1.10.1，然后点击了升级，然后整个pkg环境就无法使用了
记录升级完了软件包以后第一个错误提示
FreeBSD: /usr/local/lib/libpkg.so.3: Undefined symbol “utimensat”
这个是因为这个库是在freebsd的10.3当中才有的库，而我的环境是10.2的环境
网上有一个解决办法更新源
12345# cat /usr/local/etc/pkg/repos/FreeBSD.confFreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_2", enabled: yes}
检查当前版本
12# pkg --version1.10.1
更新缓存
1# pkg update
卸载
1# pkg delete -f pkg
重新安装
12# pkg install -y pkg# pkg2ng
检查 ...
