【4.分布式存储】-ceph

http://docs.ceph.org.cn/archi...
扩展性极强的分布式对象存储（swift python写的），块存储，文件存储（hdfs和hadoop的结合紧密性能居然更好，NN节点PB，cephEB，java写的）。
特色：

• 无路由存储CRUSH，造就极高扩展性；自动failover,rebalance等
• 日志文件系统（原子+顺序批量）缓存分级，原来默认filestore,日志SSD+无内核缓存+数据fs的正常存储。发展中的Bluestore，ROCKSDB+裸设备，全完无内核缓存，rocksdb还能够优化用NVRAM断电不影响的RAM。
• 三副本或EC
• 带条化

组件

客户端：{块，对象，文件}，计算路由，与监视器认证和取配置
监视器：认证密钥下发，元数据一致性保证，集群自身可用性（paxos），轻量（数据少，OSD集群相互上报，对它依赖少，6s一次，20s*3个断定失效）
存储集群OSDs：上报状态，与副本集通讯复制数据一致性，主要计算发现副本（序号靠前是主）
元数据：包含集群状态没有路由看下官网吧

流程

读写过程

与monitor认证，获取集群配置，
计算pgid(hash，提早规定好pgid,不能改了)
发送到osd机器上
osd副本之间同步返回ack(能够配置SSD缓存，分别ACK确认，第一次返回第二次到磁盘后删除)

带条化

CRUSH

File -> object 映射
Object -> PG 映射 hash(oid) & mask -> pgid。Ceph也推荐PG总数应该为OSD总数的数百倍，以保证有足够数量的PG可供映射。2的幂
PG -> OSD 映射

failover、reblance

新OSD，与monitor通讯。Monitor将其加入cluster map，并设置为up且out状态，再将最新版本的cluster map发给这个新OSD。
收到monitor发来的cluster map以后，这个新OSD计算出本身所承载的PG，以及和本身承载同一个PG的其余OSD。而后，新OSD将与这些OSD取得联系。若是这个PG目前处于降级状态（即承载该PG的OSD个数少于正常值，如正常应该是3个，此时只有2个或1个。这种状况一般是OSD故障所致），则其余OSD将把这个PG内的全部对象和元数据复制给新OSD。数据复制完成后，新OSD被置为up且in状态。而cluster map内容也将据此更新。这事实上是一个自动化的failure recovery过程。固然，即使没有新的OSD加入，降级的PG也将计算出其余OSD实现failure recovery。

若是该PG目前一切正常，则这个新OSD将替换掉现有OSD中的一个（PG内将从新选出Primary OSD），并承担其数据。在数据复制完成后，新OSD被置为up且in状态，而被替换的OSD将退出该PG（但状态一般仍然为up且in，由于还要承载其余PG）。而cluster map内容也将据此更新。这事实上是一个自动化的数据re-balancing过程。

若是一个OSD发现和本身共同承载一个PG的另外一个OSD没法联通，则会将这一状况上报monitor。此外，若是一个OSD deamon发现自身工做状态异常，也将把异常状况主动上报给monitor。在上述状况下，monitor将把出现问题的OSD的状态设为down且in。若是超过某一预订时间期限，该OSD仍然没法恢复正常，则其状态将被设置为down且out。反之，若是该OSD可以恢复正常，则其状态会恢复为up且in。在上述这些状态变化发生以后，monitor都将更新cluster map并进行扩散。这事实上是自动化的failure detection过程。

即使由数千个甚至更多OSD组成，cluster map的数据结构大小也并不惊人。同时，cluster map的状态更新并不会频繁发生。即使如此，Ceph依然对cluster map信息的扩散机制进行了优化，以便减轻相关计算和通讯压力。

首先，cluster map信息是以增量形式扩散的。若是任意一次通讯的双方发现其epoch不一致，则版本更新的一方将把两者所拥有的cluster map的差别发送给另一方。
其次，cluster map信息是以异步且lazy的形式扩散的。也即，monitor并不会在每一次cluster map版本更新后都将新版本广播至全体OSD，而是在有OSD向本身上报信息时，将更新回复给对方。相似的，各个OSD也是在和其余OSD通讯时，将更新发送给版本低于本身的对方。
基于上述机制，Ceph避免了因为cluster map版本更新而引发的广播风暴。这虽然是一种异步且lazy的机制，但根据Sage论文中的结论，对于一个由n个OSD组成的Ceph集群，任何一次版本更新可以在O(log(n))时间复杂度内扩散到集群中的任何一个OSD上。
若是一个client和它要访问的PG内部的各个OSD看到的cluster map状态一致，则访问操做就能够正确进行。而若是这个client或者PG中的某个OSD和其余几方的cluster map不一致，则根据Ceph的机制设计，这几方将首先同步cluster map至最新状态，并进行必要的数据re-balancing操做，而后便可继续正常访问。

数据格式

底层都是对象：ID,二进制数据，metadata（随意定义）

OSD的日志与bluestore

日志

OSD使用日志的缘由有两个：

• 速度： 日志使得 OSD 能够快速地提交小块数据的写入， Ceph 把小片、随机 IO 依次写入日志，这样，后端文件系统就有可能归并写入动做，并最终提高并发承载力。所以，使用 OSD 日志能展示出优秀的突发写性能，实际上数据尚未写入 OSD ，由于文件系统把它们捕捉到了日志
• 一致性：OSD须要一个能保证原子化复合操做的文件系统接口。 OSD 把一个操做的描述写入日志，并把操做应用到文件系统。这确保了对象（例如归置组元数据）的原子更新。每隔一段时间（由filestore max sync interval 和 filestore min sync interval控制 ）， OSD 会中止写入，把日志同步到文件系统，这样容许 OSD 修整日志里的操做并重用空间。若失败， OSD 从上个同步点开始重放日志。日志的原子性表如今，它不使用操做系统的文件缓存（基于内存），避免断电丢数据的问题

bluestore

直接管理裸设备，抛弃了ext4/xfs等本地文件系统，BlockDevice实如今用户态下使用linux aio直接对裸设备进行I/O操做。
Onode是常驻内存的数据结构，持久化的时候会以kv的形式存到rocksdb里。rocksdb自己是基于文件系统的，封装实现了一个小的文件系统BlueFS，在系统启动mount这个文件系统的时候将全部的元数据都加载到内存中，BluesFS的数据和日志文件都经过BlockDevice保存到裸设备上
https://www.sysnote.org/2016/...
使用HDD做为数据盘
使用SSD做为RockDB元数据盘
使用NVRAM做为RockDB WAL
参考资料：
https://blog.gmem.cc/ceph-stu...
https://www.siguadantang.com/...