前言在跟一个朋友聊天的时候，聊到一个技术问题，他们的一个环境上面小文件巨多，是我目前知道的集群里面规模算非常大的了，但是目前有个问题，一方面会进行一倍的硬件的扩容，而文件的数量也在剧烈的增长着，所以有没有什么办法来 缓解这个增长的压力 当时也没想到太多的办法,只是觉得这么用下去风险太大 后来在思考了一段时间后，大概有了一个想法，这个就要看是否能把方案做下去，如果是我自己在用的集群，而非客户，我会这么去用的 方案介绍方案一也就是默认的方案，一般来说就是一个主MDS，然后几个备用MDS，整个一个挂载点，全局混用的空间 存在问题： 扩容以后，有大量的数据迁移 所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题 优点： 全局统一命名空间 方案二：采用分存储池的结构，也就是将集群内的目录树分配到整个集群的多个相互独立的空间里面 存在问题： 同样是所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题 优点： 全局统一命名空间下面对应目录到不同的存储池当中，在进行扩容的时候，不会影响原有的数据，基本是没有迁移数据 ...

前言在看一个Linux Vault 2017的资料的时候，看到红帽分享的一个测试的过程，里面关于小文件元数据性能测试的，环境准备的还比较好,可以作为一种测试模型 测试用例测试用例一： 使用find -name 测试 find -size 测试 测试用例二： 使用find -name 测试 find -size 测试 测试用例三： 使用rmdir进行测试 总结本篇就是记录一个测试模型 变更记录 Why Who When 创建 武汉-运维-磨渣 2017-03-24

前言在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 ...

前言我们以前的管理平台在python平台下面做的，内部做的一些操作采用的是命令执行，然后解析的方式去做的，ceph自身有python的rados接口，可以直接调用原生接口，然后直接解析json的方式，这样更靠近底层 在看ceph-dash内部的实现的时候，发现里面的获取集群信息的代码可以留存备用 代码实例123456789101112131415161718192021222324#!/usr/bin/env python# -*- coding: UTF-8 -*-import jsonfrom rados import Radosfrom rados import Error as RadosErrorclass CephClusterCommand(dict): """ Issue a ceph command on the given cluster and provide the returned json """ def __init__(self, cluster, **kwargs): ...

前言所谓吃一堑长一智，每次面对问题才是最好的学习机会，在面对问题的时候，尽量是能够自己去解决，或者去尝试能够最接近答案，确实无法解决再去寻求他人帮助，这样成长的会更快一些，在学校读书做题的时候，老师也是经常告诉我们要忍住，不要去直接翻答案，在当今的互联网飞速的发展下，在google的帮助下，基本上90%的问题都能找到正确的答案，而我们其实真正需要锻炼的是实践能力和甄别的能力 去年一年给不少的生产环境解决过问题，在相互交流几次以后，解决问题的过程，基本也熟悉了，一般解决问题的大致流程都是： 告之我环境的当前状况，需要实现的情况 准备好远程的环境 告之对方可能出现的情况，是否可操作，然后解决问题 交流问题的出现原因以及解决的办法 目前来看，基本都解决了，对于我来说是一次处理故障经验的累积，对对方来说是环境的恢复，以及下次在出现相同故障的时候，自己能够处理好类似问题 本次恢复对于我来说也是刷新了的认识，进展只到了解决问题的地方，就结束了，那么我就记录下这次解决问题当中的收获 处理过程故障的发生应该是在一次掉电后触发的,整个集群在重新启动以后，出现了多块磁盘故障的问题，也有主机无法启动的情 ...