前言在很久以前在研究一套文件系统的时候，当时发现一个比较奇怪的现象，没有文件存在，磁盘容量还在增加，在研究了一段时间后，发现这里面有一种比较奇特的处理逻辑
这套文件系统在处理一个文件的时候放入的是一个临时目录，最开始在发送第一个写请求后，在操作系统层面马上进行了一个delete操作，而写还在继续，并且需要处理这个数据的进程一直占着的，一旦使用完这个文件，不需要做处理，这个文件就会自动释放掉，而无需担心临时文件占用空间的问题
在Ceph集群当中，有人碰到了去后台的OSD直接rm一个对象后，在前端通过rados还能get到这个删除的对象，而不能rados ls到，我猜测就是这个原因，我们来看下怎么验证这个问题
验证步骤准备测试数据，并且put进去集群12345[root@lab8106 ~]# cat zp1 sdasdasd[root@lab8106 ~]# rados -p rbd put zp1 zp1[root@lab8106 ~]# rados -p rbd lszp1
找到测试数据并且直接 rm 删除12345[root@lab8106 ~]# ceph osd map rb ...
前言ceph里面的数据是以对象的形式存储在OSD当中的，有的时候因为磁盘的损坏或者其它的一些特殊情况，会引起集群当中的某一个对象的异常，那么我们需要对这个对象进行处理
在对象损坏的情况下，启动OSD有的时候都会有问题，那么通过rados rm的方式是没法发送到这个无法启动的OSD的，也就无法删除，所以需要用其他的办法来处理这个情况
处理步骤查找对象的路径12[root@lab8106 ~]# ceph osd map rbd rbd_data.857e6b8b4567.00000000000000baosdmap e53 pool 'rbd' (0) object 'rbd_data.857e6b8b4567.00000000000000ba' -> pg 0.2daee1ba (0.3a) -> up ([1], p1) acting ([1], p1)
先找到这个对象所在的OSD以及PG
设置集群的noout1[root@lab8106 ~]#ceph osd set noout
这个是为了防止osd的停止产生不必要的删除
停 ...
前言我们在使用集群的时候，一般来说比较关注的是后台的集群的状态，但是在做一些更人性化的管理功能的时候，就需要考虑到更多的细节
本篇就是其中的一个点，查询ceph被哪些客户端连接了
实践从接口上来说，ceph提供了文件，块，和对象的接口，所以不同的接口需要不同的查询方式，因为我接触文件和块比较多，并且文件和块存储属于长连接类型，对象属于请求类型，所以主要关注文件和块存储的连接信息查询
我的集群状态如下
12345678910111213[root@lab8106 ~]# ceph -s cluster 3daaf51a-eeba-43a6-9f58-c26c5796f928 health HEALTH_WARN mon.lab8106 low disk space monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0} election epoch 6, quorum 0 lab8106 fsmap e20: 1/1/1 up {0=l ...
前言在跟一个朋友聊天的时候，聊到一个技术问题，他们的一个环境上面小文件巨多，是我目前知道的集群里面规模算非常大的了，但是目前有个问题，一方面会进行一倍的硬件的扩容，而文件的数量也在剧烈的增长着，所以有没有什么办法来 缓解这个增长的压力
当时也没想到太多的办法,只是觉得这么用下去风险太大
后来在思考了一段时间后，大概有了一个想法，这个就要看是否能把方案做下去，如果是我自己在用的集群，而非客户，我会这么去用的
方案介绍方案一也就是默认的方案，一般来说就是一个主MDS，然后几个备用MDS，整个一个挂载点，全局混用的空间
存在问题：
扩容以后，有大量的数据迁移
所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题
优点：
全局统一命名空间
方案二：采用分存储池的结构，也就是将集群内的目录树分配到整个集群的多个相互独立的空间里面
存在问题：
同样是所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题
优点：
全局统一命名空间下面对应目录到不同的存储池当中，在进行扩容的时候，不会影响原有的数据，基本是没有迁移数据 ...
前言在ceph的研发群里看到一个cepher提出一个问题，编译的ceph的二进制文件过大，因为我一直用的打包好的rpm包，没有关注这个问题，重新编译了一遍发现确实有这个问题
本篇就是记录如何解决这个问题的
打rpm包的方式用我自己的环境编译的时候发现一个问题，编译出来的rpm包还是很大，开始怀疑是机器的原因，换了一台发现二进制包就很小了，然后查询了很多资料以后，找到了问题所在
在打rpm包的时候可以通过宏变量去控制是否打出一个的debug的包，这个包的作用就是把二进制文件当中包含的debug的相关的全部抽离出来形成一个新的rpm包，而我的环境不知道什么时候在/root/.rpmmacros添加进去了一个
1%debug_package %{nil}
搜寻资料后确定就是这个的问题,这个变量添加了以后，在打包的时候就不会进行debug相关包的剥离，然后打出的包就是巨大的，可以这样检查自己的rpmbuild的宏变量信息
1234567[root@host1 ceph-10.2.6]# rpmbuild --showrc|grep debug ...
暂未分类
未读前言之前看过一个朋友一篇文章，讲述的是Vsan为什么使用的是两副本，而ceph则大多数情况下需要三副本，当时个人观点是这个并不是关键点，但是在仔细考虑了问题的出发点以后，这个也可以说是其中的一个点
一个集群数据丢失可以从多方面去看
发生丢失数据的事件，这个来说，出现这个事件的概率是一致的，同等硬件情况下没有谁的系统能够说在两副本情况下把这个出现坏盘概率做的比其他系统更低
发生坏盘事件以后，数据丢失波及的范围，这个就是那个朋友提出的一个观点，对于Vsan来说因为文件的不拆分，也就是在丢了的情况下，只是局部数据的丢失，而ceph的数据因为拆分到整个集群，基本上说就是全军覆没了，这一点没有什么争议
一般来说，ceph都是配置的分布式文件系统，也就是数据以PG为组合，以对象为最小单元的形式分布到整个集群当中去，通过控制crush能够增加一定的可用概率，但是有没有办法实现真的丢盘的情况下，数据波及没有那么广，答案当然是有的，只是需要做一些更细微的控制，前端的使用的接口也需要做一定的改动，本篇将讲述这个如何去实现，以及前端可能需要的变动
方案实现首先来一张示意图，来介绍大致的实现方式，下面再给 ...
前言前一篇介绍了docker在命令行下面进行的ceph部署，本篇用docker的UI进行ceph的部署，目前来说市面上还没有一款能够比较简单就能直接在OS上面去部署Ceph的管理平台，这是因为OS的环境差异化太大，并且包的版本，以及各种软件的适配都可能造成失败，而docker比较固化环境，因此即使一个通用的UI也能很方便的部署出一个Cpeh集群
本篇就是对Docker UI部署集群做一个实践，对ceph了解，对docker了解，对dokcer的UI操作进行一定的了解的情况下，再做实践会比较好，总体上还是比较简单的
安装并运行portainer安装软件1234cd /optwget https://github.com/portainer/portainer/releases/download/1.12.1/portainer-1.12.1-linux-amd64.tar.gztar xvpfz portainer-1.12.1-linux-amd64.tar.gzcd portainer
运行软件1./portainer -H unix:///var/run/docker.sock ...
前言容器和ceph的结合已经在一些生产环境当中做了尝试，容器的好处就是对运行环境的一个封装，传统的方式是集成为ISO，这个需要一定的维护量，而容器的相关操作会简单很多，也就有了一些尝试，个人觉得如果玩的转容器可以考虑，当然得懂ceph，不然两套系统在一起，问题都不知道是哪个的，就比较麻烦了
本篇是基于之前我的填坑群里面的牛鹏举的一个问题，他的环境出现了创建osd的时候权限问题，我这边没遇到，现在实践了一遍，感觉应该是之前目录提前创建了的问题
实践步骤安装docker1yum install docker
下载ceph镜像这个镜像是sebastien维护的，他是redhat的ceph工程师，ceph-ansible的负责人,很多一线的资料都是来自他的分享，这个是一个集成好的镜像
1docker pull ceph/daemon
准备好一些目录
12mkdir -p /etc/cephmkdir -p /var/lib/ceph/
注意只需要做这个两个目录，不要创建子目录，docker内部有相关的操作
创建一个mon123456sudo docker run -d --net=host ...
暂未分类
未读前言系统中有些地方会进行资源的限制，其中的一个就是open file的限制，操作系统默认限制的是1024,这个值可以通过各种方式修改，本篇主要讲的是如何在线修改，生产上是不可能随便重启进程的
实践查看系统默认的限制12[root@lab8106 ~]# ulimit -a|grep openopen files (-n) 1024
默认的打开文件是1024
12345[root@lab8106 ~]# ps -ef|grep ceph-osdceph 28176 1 0 18:08 ? 00:00:00 /usr/bin/ceph-osd -f --cluster ceph --id 0 --setuser ceph --setgroup cephroot 28619 26901 0 18:10 pts/3 00:00:00 grep --color=auto ceph-osd[root@lab8106 ~]# cat /proc/28176/limits |grep openMax open f ...
