前言收到一个问题如下： 一个300TB 的RBD，只有7800万的objects，如果存储小文件的话，感觉不够用 对于这个问题，我原来的理解是：对象默认设置的大小是4M一个，存储下去的数据，如果小于4M，就会占用一个小于4M的对象，如果超过4M，那么存储的数据就会进行拆分成多个4M，这个地方其实是不严谨的 对于rados接口来说，数据是多大对象put进去就是多大的对象，并没有进行拆分，进行拆

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

前提一套系统的最低要求是可恢复，也就是数据不丢失，但是在各种各样的原因下，整套系统都有被毁掉的可能，一直以来有个观点就是存储是需要两套的，一般情况下很难实现，但是如何把故障发生的概率降低到最低，这个是我们需要考虑的问题 最近在社区群里面又听闻一个案例，一套系统的文件系统被重置掉了，也就是fs被重建了，实际上这属于一个不应该有的操作，但是已经发生的事情，就看怎么样能在下次避免或者把损失降到最低，对

前言在Centos7 下，现在采用了 systemctl来控制服务，这个刚开始用起来可能不太习惯，不过这个服务比之前的服务控制要强大的多，可以做更多的控制，本节将来介绍下关于 Ceph的 osd 磁盘挂载的问题 很多人部署以后，发现在Centos7下用Jewel的时候没有去写fstab也没有写配置文件，重启服务器一样能够挂载起来了，关于这个有另外一篇文章：「ceph在centos7下一个不容易发现

前言现在已经是2016年收官的一个月了，之前一直想做一个calamari的集成版本，之所以有这个想法，是因为，即使在已经打好包的情况下，因为各种软件版本的原因，造成很多人无法配置成功，calamari发布以后，因为版本的更迭，经常出现软件版本引起的BUG 这里直接把需要的软件集成在一起了，按照本篇指导，一步一步是能够很简单的配置起来的，并且提供了一个视频的指导，应该能够很大程度上降低calamar

前言这个问题是不久前在ceph社区群里看到的，创建image的时候，当时的报错如下： 2016-12-13 23:13:10.266865 7efbfb7fe700 -1 librbd::image::CreateRequest: pool not configured for self-managed RBD snapshot supportrbd: create error: (22) In

前言Cephfs的快照功能在官网都很少提及，因为即使开发了很多年，但是由于cephfs的复杂性，功能一直没能达到稳定，这里，只是介绍一下这个功能，怎么使用，并且建议不要在生产中使用，因为搞不好是会丢数据的 功能介绍首先这个功能是默认关闭的，所以需要开启 123[root@lab8106 ~]# ceph fs set ceph allow_new_snaps 1Error EPERM: Warn

前言之前写过一篇关于查询OSD的运行的CPU的情况的分享，本篇是讲的获取内存占用的，代码包括两种输出，一种是直接的表格，一种是可以方便解析的json 代码直接上代码，python才用不久，所以可能代码实现比较低级，主要是看实现的方法 12345678910111213141516171819202122232425262728293031323334353637383940414243444546

Linux当中最核心的部分就是内核，这个也是最基础，最可能被忽视的一部分，随便找一个刚入职的运维，学习个两三天，网上找些资料也能能自己安装编译内核了，很多运维的初期培训就是做的这些学习，为什么在网上已经有这么多文章的情况下，还要写一篇关于内核的文章，这是因为，我想讲的是如何去选择内核 一般来说，找内核的时候都会去下面这个网站进行选择 https://www.kernel.org/ 很多人在问

Ceph和OpenStack是一个非常有用和非常受欢迎的组合。 不过，部署Ceph / OpenStack经常会有一些容易避免的缺点 - 我们将帮助你解决它们 使用 show_image_direct_url and the Glance v2 API使用ceph的RBD（RADOS Block Device）,你可以创建克隆,你可以将克隆理解为可写的快照（快照通常是只读的）。克隆只