System|分布式|Ceph & BlueStore
Ceph放弃了使用传统的文件系统作为分布式存储后端,因为它们有以下弊端:
- 难以零开销事务机制
- metadata的性能显著影响分布式性能
- 新型硬件支持不佳
转而使用BlueStore。BlueStore是Ceph最新的存储引擎,运行在用户态并且完全控制IO,取得了极大性能提升。
File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution SOSP 2019
Ceph
分布式文件系统需求
- 高效率的事务
- 快速的Metadata操作
- 支持新型异构的硬件
然而对于那些支持POSIX标准的底层文件系统而言,他们却往往缺少事务支持(因为overhead太大),DFS必须在顶层加上WAL或者放大底层文件系统内部的事务机制。而如果它们支持的话,顶层就能简化事务设计。
而对于Metadata,大如在分布式文件系统上做目录枚举,小如在本地文件系统上查找,无论是中心化还是分布式设计都无法在两种情况下性能高效。
新型的存储设备,例如SMR(瓦式磁盘,通过磁道重叠提高存储密度,只能顺序写,一种解决方案是Ext4+LFS缓存metadata),ZNS 固态硬盘等都是传统的基于block的文件系统无法处理的。
Ceph 架构
Reliable Autonomic Distributed Object Store(RADOS)是Ceph的核心,里面有多个Object Storage Devices(OSD),提供自我修复、自我管理、自我备份等机制。
在上层则通过librados库提供抽象,支持事务和各种原语。
object存在池子里,通过备份或者纠删码获得冗余,被划分到placement groups(PG)里。PG通过CRUSH伪随机数据分配算法分配给不同OSD,从而不需要metadata服务。通过这个间接层,Object能够进行迁移。
BlueStore
设计目标
- Fast metadata operations
- No consistency overhead for object writes
- Copy-on-write clone operation
- No journaling double-writes
- Optimized I/O patterns for HDD and SSD
BlueFS 和 RocksDB
Metadata
通过将metadata存在RocksDB里,提供了快速的metadata操作。
这点很有趣,因为这里的metadata同时是本地的,也是分布式的。
这点可以和GFS做个对比,GFS的metadata在本地是inode,在master则是trie
例如,以O开头的key代表object的metadata,B代表block,C代表collection
C12.e4-6表示pool12中hash值以e4的高6位开头的object集合。(111001)
O12e532(111001)属于此集合,O12.e832 则不属于(111010)
这样通过改变位数,很容易使得集合分裂,非常高效。
无一致性Overhead
RocksDB运行于BlueFS之上,作出两个改变
- 直接刷新缓存写入data
- 复用BlueFS的WAL,直接刷新缓存写入metadata
COW
BlueStore使用COW机制,也就是先在其他地方写,写完之后让metadata指向new data。COW的好处在于没有double-writes (journal data)。
- 对于大于最小分配size的写,当Data持久化后再把对应的MetaData插入RocksDB。
- 对于小于最小分配size的写,把Data和MetaData同时插入RocksDB,Data之后异步地写入磁盘。这样不仅可以Batch利用带宽,同时优化IO模式,例如<64kb的HDD overwrite是异步的,<16kb的SDD overwrite是inplace的。
空间分配
Freelist manager 基于bitmap,bit per block(那你叫freelist干嘛啊),利用merge原子性反转多个位。
Allocator则是内存中的freelist拷贝,当分配完成后通知Freelist进行修改。为了节约空间,采用层次化的索引,1TB数据只需35MB
Cache
Blue Store与磁盘直接IO,因此无法利用page cache。
scan resistant 2Q 算法在内存中建立了write-through cache
cache通过OSD相同的CRUSH伪随机数据分配算法分配到指定核,因此核能准确找到2Q
Feature
checksum
每次写生成checksum,每次读验证checksum。
由于分布式系统大部分数据只读,可以通过IO hint控制checksum size。
例如只读的部分size可以更大,压缩的部分可以计算压缩后的checksum。
纠删码的覆写
仅支持RGW,因为纠删码只有在append/delete的情况下才能保证性能(不然修改的范围太大)
这里利用COW机制完成2PC,仅当所有备份OSD均正确overwrite时才会commit。
Transparent Compression
当压缩数据部分被修改时,新的数据只会COW在别的地方而不会覆写压缩数据本身。
只有当overwrite太多导致碎片化时,才会读取这些数据再进行覆写,一般来说通过hint仅压缩那些不容易被覆写的数据。
举个例子 1234 -> 1234|2' -> 1234|2'|3' ->12'3'4'
探索新接口
因为BlueFS自己控制IO,所以开源社区正在对新硬件提供支持
总结
Problem: 传统单机文件系统不支持分布式文件系统场景
Related work: 事务支持overhead大,性能不佳
Observation: 利用RocksDB存储Metadata,COW
Solution: COW提供事务支持,分布式的metadata就是本地的metadata
Evaluation: 性能提高,支持新硬件
Comments:需要特殊定制的数据库, 而且天生为Ceph服务,定制化程度高
相关文章
- 金融服务领域的大数据:即时分析
- 影响大数据、机器学习和人工智能未来发展的8个因素
- 从0开始构建一个属于你自己的PHP框架
- 如何将Hadoop集成到工作流程中?这6个优秀实践必看
- SEO公司使用大数据优化其模型的5种方法
- 关于Web Workers你需要了解的七件事
- 深入理解HTTPS原理、过程与实践
- 增强分析:数据和分析的未来
- PHP协程实现过程详解
- AI专家:大数据知识图谱——实战经验总结
- 关于PHP的错误机制总结
- 利用数据分析量化协同过滤算法的两大常见难题
- 怎么做大数据工作流调度系统?大厂架构师一语点破!
- 2019大数据处理必备的十大工具,从Linux到架构师必修
- OpenCV中的KMeans算法介绍与应用
- 教大家如果搭建一套phpstorm+wamp+xdebug调试PHP的环境
- CentOS下三种PHP拓展安装方法
- Go语言HTTP Server源码分析
- Go语言HTTP Server源码分析
- 2017年4月编程语言排行榜:Hack首次进入前五十