前言

很久没有处理很大的集群，在接触一个新集群的时候，如果集群足够大，需要比较长的时间才能去理解这个集群的结构，而直接去看ceph osd tree的结果，当然是可以的，这里是把osd tree的结构进行了一个结构化输出，也可以理解为画出一个简单的结构图，比较适合给其它人讲解你对crush做了哪些改变，这个如果指着文字来讲估计很多人会听的云里雾里，如果有比较方便的方式出图就比较好了

为此写了一个小工具自己用，正好也可以看看我们对结构做简单调整后的效果

关于arm

之前wdlab对外发布过一次约500个节点的arm的ceph集群，那个采用的是微集群的结构，使用的是双核的cortex-a9 ARM处理器，运行速度为1.3 GHz，内存为1 GB，直接焊接到驱动器的PCB上，选项包括2 GB内存和ECC保护

这个在国内也有类似的实现，深圳瑞驰商用Arm存储NxCells

这个采用的是微集群的架构，能够比较好的应对一些冷存场景，但是今天要说的不是这种架构，而是一个比较新的平台，采用的是高性能的arm的架构，也就是类似X86的大主板结构

前言

自启动相关的文章很多，有分析的很详细的文章，这里就不做赘述，本篇讲述的是什么情况下用，怎么用的问题

使用场景

一台机器的系统盘坏了，需要重装系统，相关的一些信息没有了，但是上面的数据盘还是在的，所以需要保留

某个磁盘需要换台机器进行启动，但是那台机器上没有相关的信息

引言

ceph自从到了L版本以后，L版本的启用，对性能本身有了极大的提高，一直对这个比较不放心的就是内存的占用，刚开始的时候记得大量dd就可以把内存搞崩掉，这个应该是内部的设计逻辑需要更多的内存的占用

最近在做ARM版本的服务器的测试，机器为36盘位的机器，内存需要自然多，但是36盘位的机器，按之前想法是4G预留，那得需要144G内存了，这个还没有算迁移的时候的内存消耗，而很多时候，我们并不需要速度，只需要稳定就好

测试环境说明

测试环境比较简单，一台36盘位的arm机器，一台X86机器，通过万兆相连，设置集群为副本1，然后再X86上面通过rados命令进行测试

前言

之前在filestore里面，pg是直接暴露到文件系统的，也就是可以直接进去查看或者拷贝，在极端情况下，多个osd无法启动，pg无法导出的时候，那么对pg内部对象的操作处理，是可以作为最后恢复数据的一种方式的

这个在bluestore里面就没那么直接了，之前也碰到过一次，osd无法启动，内部死循环，pg无法export，osd就僵死在那里了，实际上，bluestore也提供了接口把对象能够直接显示出来

前言

ceph已经是一个比较成熟的开源的分布式存储了，从功能角度上来说，目前的功能基本能够覆盖大部分场景，而社区的工作基本上是在加入企业级的功能和易用性还有性能等方面在发力在，不管你是新手还是老手，都绕不开的一个问题就是crush，而crush是决定着数据的分布的，很多人并不理解为什么会有这个crush，这个算法到底是怎么去计算的，本篇是从更偏向用户层来对这个分布做一个解释，以及我们该怎么去动这个crush，本篇的内容不需要有代码开发能力，只需要稍加思考，都可以理解，剩下的就是你自己的选择了

所有的存储都离不开分布的问题，存储是不是做副本，副本是如何分布的都是有自己的一套逻辑的

这里拿gluster做例子，gluster的数据分布就是通过子卷来控制的，副本几，那么数据的子卷就是由几个组成，一个文件是默认落到一个子卷的，如果没做分片的话，然后所有的盘符的子卷组成了一整个的卷，数据是散列到子卷里面去的，这种子卷的组合是固定的，组合是通过命令的先后顺序来控制的，也就是数据的分布组合是固定的

而ceph的灵活之处在于把这种子卷的逻辑向下走了一层，通过一个pg的概念，以目录为结构做出很多这样的组合来，gluster是以磁盘（或者理解为固定目录）为粒度做brick，而ceph则是以可以飘动的pg来做分布，而pg的分布则可以通过人为的控制来实现我们的需求，好了，准备进入本篇的内容

前言

本篇的内容实际上是另外一篇文章的字篇章，在另外一篇文章当中，将会对crush的分布的调整的做一次总结，用比较简单的方式来展示各种crush的区别

在做这个工作过程中，为了更好的能展示出效果，就有了下面的这个小工具的出现

前言

前一段时间碰到一个系统，用rados bench 去跑都还比较正常，但是一跑数据库就非常慢，测试工具会抛出延时过大的提示，经过排查发现，云平台中有一台虚拟机还运行着备份数据库的服务，而这个备份软件是需要反复写一个标记文件的，因为这个标记文件只对应了一个对象，一个对象对应了一个pg，一个pg对应到固定的ssd上面，那个ssd的io几乎被这一个操作给打满了，然后全局的请求到了这个osd上面的时候，都会变得慢和卡顿

出现这种情况，在业务层面可能需要做好分离，我们在面对这种情况的时候该如何提前就做好测试，对自己的性能的剩余性能做一个更好的评估，什么时候需要分离，什么时候不需要分离，这个都是需要用数据来说话的

性能测试的时候，经常面临的这些问题，你告诉我这个环境能跑多少iops，带宽能多大，我的数据库能不能跑，这个我也没法回答，一般来说我都是说需要根据环境进行测试，这个测试也只能根据自己设计的模型进行测试，而越接近用户使用场景的业务模型，就越能反应真实的业务能力，最好的测试就是直接拿对接的软件进行测试，接什么业务就用什么业务压

这本书，可以节约你阅读20W行代码的时间!

了解Ceph的人都知道，RADOS是整个Ceph的基础，也是整个Ceph的核心，但越是核心，越难掌握，想想看，单单RADOS的代码就有将近20W行之多，不经历好几年的摸爬滚打，怕是难以掌握其中的来龙去脉。

前言

最近已经见到几个环境出现过incompelete了，这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理，但是随着处理的环境越来越多，这个地方还是有些需要注意的，本篇是写一些需要注意的点

一般来说是环境有多个机器同时坏盘或者掉电，或者掉主机引起的