前段时间群友有人问，怎么能找到存在Ceph里面的文件呢，我说为什么要这样问，他说要给领导演示下Ceph的高可用，某个节点down掉之后不影响数据丢失。下面针对于这个前提，做了如下实验，感兴趣的可以试试。
在开始之前先科普下Ceph的基本概念知识。
一张非常经典的寻址图，下面来继续探索Ceph的寻址流程，首先介绍下寻址流程中用到的几个概念。
File——此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。
Ojbect——处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。
PG（Placement Group）——顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。
OSD —— 即object storage device。OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。
Failure domain ——就是故障域。
好了，理论看完了，下面开始实操。
大概的顺序就是
创建File、将File写入到Object里面然后存到Pool里面，最终映射到PG和OSD上，跟上面的图类似。
下面来验证下，可以看到我创建了个devin.txt，里面有一些英文内容，接着可以看到数据最终是存在了OSD1和OSD2上面，并且在OSD1中找到了我的文件。
下面我down掉了一个OSD2所在的节点。可以看到我的ceph-node2上的OSD已经全部down掉了。
可以看到我的文件数据已经rebalance到了OSD5上
OK.小实验验证完毕，感兴趣的可以玩玩。
本文转自Devin 51CTO博客，原文链接:http://blog.51cto.com/devingeng/1904440
