【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/...

你可能感兴趣的:(ceph)