ceph简介

1、初认ceph
刚到公司后，开始接触软件存储产品，发现都是基于一个叫ceph的开源解决方案来做的。后来慢慢开始关于ceph的一些基础知识和相关操作。接触的产品囊括了ceph所支持的块存储，对象存储和文件存储。

2、ceph来源
ceph产生于Sage Weil大神大学时期的相关研究课题的论文，之后逐渐为大众所熟知，Sage Weil后来开办公司主导ceph的开发与社区维护。

3、ceph的特性
（1） 高可靠性：所谓“高可靠”，首先是针对存储在系统中的数据而言，也即，尽可能保证数据不会丢失。其次，也包括数据写入过程中的可靠性，也即，在用户将数据写入Ceph存储系统的过程中，不会因为意外情况的出现造成数据丢失。
（2）高度自动化：具体包括了数据的自动replication，自动re-balancing，自动failure detection和自动failure recovery。总体而言，这些自动化特性一方面保证了系统的高度可靠，一方面也保障了在系统规模扩大之后，其运维难度仍能保持在一个相对较低的水平。
（3）高可扩展性：这里的“可扩展”概念比较广义，既包括了系统规模和存储容量的可扩展，也包括了随着系统节点数增加的聚合数据访问带宽的线性扩展，还包括了基于功能丰富强大的底层API提供多种功能、支持多种应用的功能性可扩展。

4、ceph的特色
作为一个提供分布式存储解决方案，那么它就要涉及到数据应该写到哪里，该去×××到数据这两个基本问题。
ceph独特之处就在于此，借用ceph浅析文章中的一句话就是“无需查表，算算就好”。
针对上述两个问题，传统方案是引入专用的服务器节点，在其中存储用于维护数据存储空间映射关系的数据结构。在用户写入/访问数据时，首先连接这一服务器进行查找操作，待决定/查到数据实际存储位置后，再连接对应节点进行后续操作。而Ceph彻底放弃了基于查表的数据寻址方式，而改用基于计算的方式。简言之，任何一个Ceph存储系统的客户端程序，仅仅使用不定期更新的少量本地元数据，加以简单计算，就可以根据一个数据的ID决定其存储位置。

5、ceph架构和rados逻辑结构

rados：基础存储系统RADOS（Reliable, Autonomic, Distributed Object Store，即可靠的、自动化的、分布式的对象存储）。所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。
librados：这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是整个Ceph）进行应用开发。特别要注意的是，RADOS是一个对象存储系统，因此，librados实现的API也只是针对对象存储功能的。
radosgw，rbd，ceph fs：这三个是高层应用接口，分别对应对象存储，块存储和文件存储业务。其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

ps：librados和radosgw都可以提供关于对象存储的接口，但两者还是有不同的，radosgw抽象层次更高提供兼容Amazon S3和swift的restful api，I所操作的“对象”只有三个：用户账户、用户存储数据对象的容器、数据对象，并且所有的操作均不涉及存储系统的底层硬件或系统信息。而librados则提供的是本地api。librados API向开发者开放了大量的RADOS状态信息与配置参数，允许开发者对RADOS系统以及其中存储的对象的状态进行观察，并强有力地对系统存储策略进行控制。

rados的逻辑结构由osd和mon这两个角色组成，在文件系统场景下有mds的角色出现，这里不讨论这个东西。
osd：为数众多的、负责完成数据存储和维护功能的节点
mon：若干个负责完成系统状态检测和维护
在使用RADOS系统时，大量的客户端程序通过与OSD或者monitor的交互获取cluster map，然后直接在本地进行计算，得出对象的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。可见，在此过程中，只要保证cluster map不频繁更新，则客户端显然可以不依赖于任何元数据服务器，不进行任何查表操作，便完成数据访问流程。在RADOS的运行过程中，cluster map的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种：OSD出现故障，或者RADOS规模扩大。而正常应用场景下，这两种事件发生的频率显然远远低于客户端对数据进行访问的频率。

后面再会讲讲ceph数据读写流程和crush算法的一些内容。

转载于:https://blog.51cto.com/12374206/2128650