这篇文章给大家分享的是有关Ceph中存储引擎实现FileStore的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
公司主营业务：成都网站制作、网站建设、外贸网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出鸡泽免费做网站回馈大家。
Ceph作为一个高可用和强一致性的软件定义存储实现，去使用它非常重要的就是了解其内部的IO路径和存储实现。
ObjectStore是Ceph OSD中最重要的概念之一，它封装了所有对底层存储的IO操作。从上图中可以看到所有IO请求在Clieng端发出，在Message层统一解析后会被OSD层分发到各个PG，每个PG都拥有一个队列，一个线程池会对每个队列进行处理。
当一个在PG队列里的IO被提出后，该IO请求会被根据类型和相关附带参数进行处理。如果是读请求会通过ObjectStore提供的API获得相应的内容，如果是写请求也会利用ObjectStore提供的事务API将所有写操作组合成一个原子事务提交给ObjectStore。ObjectStore通过接口对上层提供不同的隔离级别，目前PG层只采用了Serializable级别,保证读写的顺序性。
ObjectStore主要接口分为三部分，第一部分是Object的读写操作，类似于POSIX的部分接口，第二部分是Object的属性(xattr)读写操作，这类操作的特征是kv对并且与某一个Object关联。第三部分是关联Object的kv操作(在Ceph中称为omap)，这个其实与第二部分非常类似，但是在实现上可能会有所变化。
目前ObjectStore的主要实现是FileStore，也就是利用文件系统的POSIX接口实现ObjectStore API。每个Object在FileStore层会被看成是一个文件，Object的属性(xattr)会利用文件的xattr属性存取，因为有些文件系统(如Ext4)对xattr的长度有限制，因此超出长度的Metadata会被存储在DBObjectMap里。而Object的omap则直接利用DBObjectMap实现。因此，可以看出xattr和omap操作是互通的，在用户角度来说，前者可以看作是受限的长度，后者更宽泛(API没有对这些做出硬性要求)。
DBObjectMap是FileStore的一部分，利用KeyValue数据库实现了ObjectStore的第三部分API，DBObjectMap主要复杂在其实现了clone操作的no-copy。因为ObjectStore提供了clone API，提供对一个Object的完全clone(包括Object的属性和omap)。DBObjectMap对每一个Object有一个Header，每个Object联系的omap(kv pairs)对会与该Header联系，当clone时，会产生两个新的Header，原来的Header作为这两个新Header的parent，这时候无论是原来的Object还是cloned Object在查询或者写操作时都会查询parent的情况，并且实现copy-on-write。那么Header如何与omap(kv pairs)联系呢，首先每个Header有一个唯一的seq，然后所有属于该Header的omap的key里面都会包含该seq，因此，利用KeyValueDB的提供的有序prefix检索来实现对omap的遍历。
上面提到FileStore会将每个Object作为一个文件，那么Object的一些属性会与Object Name一起作为文件名，Object 所属的PG会作为文件目录，当一个PG内所包含的文件超过一定程度时(在目录内文件太多会造成文件系统的lookup性能损耗)，PG会被分裂成两个PG。
感谢各位的阅读！关于“Ceph中存储引擎实现FileStore的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！