ceph读书笔记

上图最底层的RADOS，是真正实现ceph存储功能的部分。

RADOS是“A reliable, autonomous, distributed object storage”。 RADOS由两个组件组成：

    OSD： Object Storage Device，将数据存储在object中，管理data replication , recovery , rebalancing ，并且负责上报stage信息给Ceph Monitor。

    Monitor：维护整个Ceph集群的健康状态，通过维护 Monitor map , OSD map , Placement Group ( PG ) map 和CRUSH map, Monitor接收各组件的状态信息，用这些信息维护map，并将这些map再回传给其他的Monitor和OSD节点。

Ceph另外两个组件是：

MDS：用于保存CephFS的元数据。

RADOS Gateway：对外提供REST接口，兼容S3和Swift的API。

四、RADOS的核心-寻址机制

具体而言， Ceph中的寻址至少要经历以下三次映射：

1. File -> object映射

这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分，相当于RAID中的条带化过程。这种切分的好处有二：一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。

每一个切分后产生的object将获得唯一的oid，即object id。其产生方式也是线性映射，极其简单。图中，ino是待操作file的元数据，可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该file id之后得到的。举例而言，如果一个id为filename的file被切分成了三个object，则其object序号依次为0、1和2，而最终得到的oid就依次为filename0、filename1和filename2。

这里隐含的问题是，ino的唯一性必须得到保证，否则后续映射无法正确进行。

2. Object -> PG映射

在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。这个映射过程也很简单，如图中所示，其计算公式是：

hash(oid) & mask -> pgid

由此可见，其计算由两步组成。首先是使用Ceph系统指定的一个静态哈希函数计算oid的哈希值，将oid映射成为一个近似均匀分布的伪随机值。然后，将这个伪随机值和mask按位相与，得到最终的PG序号（pgid）。根据RADOS的设计，给定PG的总数为m（m应该为2的整数幂），则mask的值为m-1。因此，哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。基于这一机制，当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的size相同，因而，这一映射最终保证了，各个PG中存储的object的总数据量近似均匀。

从介绍不难看出，这里反复强调了“大量”。只有当object和PG的数量较多时，这种伪随机关系的近似均匀性才能成立，Ceph的数据存储均匀性才有保证。为保证“大量”的成立，一方面，object的最大size应该被合理配置，以使得同样数量的file能够被切分成更多的object；另一方面，Ceph也推荐PG总数应该为OSD总数的数百倍，以保证有足够数量的PG可供映射。

3. PG -> OSD映射

第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。如图所示，RADOS采用一个名为CRUSH的算法，将pgid代入其中，然后得到一组共n个OSD。这n个OSD即共同负责存储和维护一个PG中的所有object。前已述及，n的数值可以根据实际应用中对于可靠性的需求而配置，在生产环境下通常为3。具体到每个OSD，则由其上运行的OSD deamon负责执行映射到本地的object在本地文件系统中的存储、访问、元数据维护等操作。

和“object -> PG”映射中采用的哈希算法不同，这个CRUSH算法的结果不是绝对不变的，而是受到其他因素的影响。其影响因素主要有二：

一是当前系统状态，也就是上文逻辑结构中曾经提及的cluster map。当系统中的OSD状态、数量发生变化时，cluster map可能发生变化，而这种变化将会影响到PG与OSD之间的映射。

二是存储策略配置。这里的策略主要与安全相关。利用策略配置，系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上，从而进一步改善存储的可靠性。

因此，只有在系统状态（cluster map）和存储策略都不发生变化的时候，PG和OSD之间的映射关系才是固定不变的。在实际使用当中，策略一经配置通常不会改变。而系统状态的改变或者是由于设备损坏，或者是因为存储集群规模扩大。好在Ceph本身提供了对于这种变化的自动化支持，因而，即便PG与OSD之间的映射关系发生了变化，也并不会对应用造成困扰。事实上，Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性，Ceph可以将一个PG根据需要动态迁移到不同的OSD组合上，从而自动化地实现高可靠性、数据分布re-blancing等特性。

之所以在此次映射中使用CRUSH算法，而不是其他哈希算法，原因之一正是CRUSH具有上述可配置特性，可以根据管理员的配置参数决定OSD的物理位置映射策略；另一方面是因为CRUSH具有特殊的“稳定性”，也即，当系统中加入新的OSD，导致系统规模增大时，大部分PG与OSD之间的映射关系不会发生改变，只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此，CRUSH算法的设计也是Ceph的核心内容之一。

至此为止，Ceph通过三次映射，完成了从file到object、PG和OSD整个映射过程。通观整个过程，可以看到，这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构cluster map，在后文中将加以介绍。可以在这里指明的是，cluster map的维护和操作都是轻量级的，不会对系统的可扩展性、性能等因素造成不良影响。

ceph有好几种map，那么每种map都是做什么用的呢？

monitor map: 包含集群的fsid, position(什么的？), 每个monitor的主机名和IP，当前epoch版本, map创建时间, map最后一次更改的时间。
OSD map: 包含集群的fsid, map创建时间, map最后一次更改的时间, Pool的列表，副本数, PG数量, OSD列表和状态(例如 up, in.)
PG map: 包含PG版本;时间戳; 最新的OSD map epoch; full ratios和PG的详细信息（例如：PG ID, Up Set, Acting Set, PG状态）; 每个pool的数据使用情况统计。
CRUSH map: 包含存储设备列表，failure domain的层级分布(例如：device, host, rack, row, room),存储数据时如何遍历failure domain的层级的规则。

关于ceph更多理论性的研究可以参考"ThinkDiff"老兄的博客，http://www.cnblogs.com/bodhitree/，我上边的文字就是从他文章里扒来的，受益匪浅 ，此兄台是专注ceph研发的。

五、ceph安装的流水账

[ceph-x86_64]

name=Ceph x86_64 packages

baseurl=https://download.ceph.com/rpm-luminous/el7/x86_64/

enabled=1

gpgcheck=1

type=rpm-md

gpgkey=https://download.ceph.com/keys/release.asc

预算是多少？

Ceph集群是24x7x365运转还是有计划停机时间？

多少应用会使用该ceph集群？

什么类型的数据会存储在该ceph集群

该为性能和容量优化该ceph集群吗？

整个集群的可用容量计划是多少？

集群的数据增长的规律是什么？

集群总共支持多少IOPS?

集群总共支持多少吞吐量？

集群的数据冗余程度，即数据应该被保存几份？

集群需要跨IDC吗？需要跨机柜吗？（影响CRUSH MAP的布局）

OSD节点是一致的硬件吗？

SSD硬盘是作为journal还是数据盘?

需要采用10G甚至40G的网络互联吗？（基于数据量）

节点网卡需要做teaming吗？如果做，总共需要多少交换机端口？

Monitor节点需要保存log，那么Monitor的本地磁盘需要准备多大？