存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载CephFSCeph File System将文件数据与元数据彻底分离所有文件数据都以 RADOS 对象的形式存储于存储集群而目录、文件名、权限等元数据由 MDSMetadata Server负责维护。本文以 cephfs-io-path.rst 为核心系统讲解 CephFS 的数据 I/O 路径——客户端如何通过能力capability协商获得文件读写权、如何直接绕过 MDS 访问 RADOS 完成数据读写、数据对象如何按inode号.对象索引分条命名以及用户态libcephfs librados与内核态ceph.ko libceph.ko两条客户端路径的异同。读完本文你将掌握 CephFS 数据平面与元数据平面分离的设计精髓理解读缓存cache与写缓冲buffer能力的语义并能从源码级理解文件布局参数stripe unit / stripe count / object size如何决定对象的切分方式。一、总览元数据与数据分离的 I/O 架构CephFS 的核心设计原则是文件数据全部存放在 RADOS 对象中客户端可以直接访问 RADOS 读写文件数据MDS 只处理元数据操作。这一设计使得数据路径上没有 MDS 这个中间环节从而避免了元数据服务器成为数据吞吐的瓶颈。doc/cephfs/cephfs-io-path.rst中给出的架构图清晰地展示了这条两条路径--------------------- | Application | --------------------- | V --------------------- Data I/Os -------------------- | CephFS Library | --------- | LibRados | --------------------- -------------------- | | | Metadata Operations | Objects Read/Write V V --------------------- -------------------- | MDSs | -------- | OSDs | --------------------- -------------------- ---------------------- --------------------- | CephFS kernel client | Data I/Os | Ceph kernel library | | (ceph.ko) | -------- | (libceph.ko) | ---------------------- --------------------- | | | Metadata Operations | Objects Read/Write v v --------------------- -------------------- | MDSs | -------- | OSDs | --------------------- --------------------图中上、下两半分别对应 CephFS 的两种客户端实现用户态客户端应用 → CephFS Librarylibcephfs→ LibRados → OSDs元数据操作走 CephFS Library → MDSs。内核态客户端应用 → CephFS kernel clientceph.ko→ Ceph kernel librarylibceph.ko→ OSDs元数据操作走 ceph.ko → MDSs。两条路径的数据 I/O 都直接发生在客户端与 OSD 之间MDS 只负责元数据目录层次、inode 分配、能力协商、锁管理等。这也是 CephFS 能够在大量客户端并发读写时保持扩展性的根本原因——数据平面是水平扩展的OSD 集群元数据平面由 MDS 集群承载二者互不干扰。二、能力Capability协商读/写文件前的第一道关卡在 CephFS 中读写一个文件的前提是客户端拥有对应 inode 的 file read/write 能力capability。能力机制是 CephFS 保证多客户端缓存一致性的核心协议其实现遍布 MDS 与客户端两侧MDS 侧src/mds/Capability.h/src/mds/Capability.cc定义能力对象src/mds/Locker.cc负责能力的发放、收回与锁协调客户端侧src/client/Client.cc维护客户端视图中的能力集合并在 open 文件、需要扩展能力时向 MDS 发起请求。2.1 能力不足时怎么办cap message当客户端没有所需的文件读写能力时它不会直接去访问 RADOS而是先向 MDS 发送一个cap message告诉 MDS 自己想要什么。MDS 在条件允许时会向客户端发放issue能力。只有拿到 file read/write 能力之后客户端才被允许直接访问 RADOS 读写文件数据。这一协商流程保证了任何时刻客户端对某 inode 的读写权限都由 MDS 统一裁决多个客户端之间的缓存一致性例如一个客户端要独占写、其他客户端必须 flush 并丢弃缓存都由 MDS 通过能力回收与再发放来维护。2.2 能力位的源码定义能力的底层定义位于 src/include/ceph_fs.h每种通用能力位generic bits都通过左移叠加到对应的能力域auth、link、xattr、file上#define CEPH_CAP_GSHARED 1 /* client can reads */ #define CEPH_CAP_GEXCL 2 /* client can read and update */ #define CEPH_CAP_GCACHE 4 /* (file) client can cache reads */ #define CEPH_CAP_GRD 8 /* (file) client can read */ #define CEPH_CAP_GWR 16 /* (file) client can write */ #define CEPH_CAP_GBUFFER 32 /* (file) client can buffer writes */ #define CEPH_CAP_GWREXTEND 64 /* (file) client can extend EOF */对应到文件域file realm的能力位定义如下#define CEPH_CAP_FILE_SHARED (CEPH_CAP_GSHARED CEPH_CAP_SFILE) #define CEPH_CAP_FILE_EXCL (CEPH_CAP_GEXCL CEPH_CAP_SFILE) #define CEPH_CAP_FILE_CACHE (CEPH_CAP_GCACHE CEPH_CAP_SFILE) #define CEPH_CAP_FILE_RD (CEPH_CAP_GRD CEPH_CAP_SFILE) #define CEPH_CAP_FILE_WR (CEPH_CAP_GWR CEPH_CAP_SFILE) #define CEPH_CAP_FILE_BUFFER (CEPH_CAP_GBUFFER CEPH_CAP_SFILE) #define CEPH_CAP_FILE_WREXTEND (CEPH_CAP_GWREXTEND CEPH_CAP_SFILE)这些位进一步组合成客户端常用到的能力集合同一文件的相邻代码段CEPH_CAP_ANY_SHARED任意域的 shared 能力多个客户端可以同时持有代表我可以读CEPH_CAP_ANY_EXCL任意域的 excl 能力代表我可以独占读写并更新CEPH_CAP_ANY_FILE_RD CEPH_CAP_FILE_RD | CEPH_CAP_FILE_CACHE | ...文件读能力全集CEPH_CAP_ANY_FILE_WR CEPH_CAP_FILE_WR | CEPH_CAP_FILE_BUFFER | ...文件写能力全集CEPH_CAP_ANY所有能力全集。注意区分CEPH_CAP_FILE_RD可以读 RADOS 对象与CEPH_CAP_FILE_CACHE可以把读到的数据缓存到本地后续读直接命中缓存是两回事CEPH_CAP_FILE_WR可以写 RADOS 对象与CEPH_CAP_FILE_BUFFER可以把写操作缓冲在本地缓存稍后异步 flush也是两回事。这正是原文档强调的能力语义。2.3 单客户端场景cache 与 buffer 能力原文档特别指出如果文件只被一个客户端打开MDS 还会向这个唯一的客户端发放 file cache/buffer 能力。二者的含义是file cache 能力文件读可以由客户端缓存满足读命中本地缓存即可返回无需每次都访问 OSDfile buffer 能力文件写可以被缓冲在客户端缓存中写操作先在本地缓存聚合再由客户端按对象异步刷写到 RADOS。在多客户端场景下由于缓存一致性难以保证MDS 不会轻易发放 cache/buffer 能力而在单客户端或 MDS 判定可以安全共享的场景下cache/buffer 能力让客户端获得类似本地文件系统的读写性能同时依旧保持数据最终落在 RADOS 对象上的持久性。这也是 CephFS 在单客户端工作负载如单机挂载运行数据库下表现出色的重要原因之一。三、数据分条Data Stripinginode号.对象索引的对象命名与布局客户端获得文件读写能力后便直接访问 RADOS 进行数据读写。文件数据以inode number.object index的形式存储为 RADOS 对象。也就是说每个 CephFS 文件对应一系列 RADOS 对象对象名由文件的 inode 号与对象序号拼接而成。关于数据分条的完整背景原文档指引读者参考 Architecture 文档的 Data Striping 一节。该节阐述了分条的必要性与原理存储设备存在吞吐量上限因此存储系统通常把连续的数据分条striping到多个设备上以提高吞吐与性能类似 RAID 0Ceph 的分条能够同时获得 RAID 0 的吞吐、n 路镜像的可靠性以及更快的恢复速度注意Ceph 存储集群中的对象本身是不分条的分条逻辑由各客户端负责——CephFS、RBD、RGW 都会把各自数据分条到多个存储集群对象上直接通过 librados 写数据的客户端必须自行完成分条与并行 I/O 才能获得这些收益。最简单的分条形式是 stripe count 1客户端把一个文件的 stripe unit 顺序写入对象直到对象达到最大容量再创建下一个对象继续写入。对于大文件、大对象客户端把 stripe unit 并行写入对象集合中的多个对象时写入性能提升显著——因为不同对象经 CRUSH 映射到不同的 placement group 与不同的 OSD写操作可以并行发生、叠加多块盘的吞吐。3.1 文件布局file layout的源码结构决定一个文件如何切分为对象的参数统称为文件布局file layout其内核协议结构定义在 src/include/ceph_fs.h__le32 fl_stripe_unit; /* stripe unit, in bytes. must be multiple ... */ __le32 fl_stripe_count; /* over this many objects */ __le32 fl_object_size; /* until objects are this big, then move to ... */ __le32 fl_object_stripe_unit; /* UNUSED. for per-object parity, if any */三个核心参数的含义参数含义说明stripe_unit分条单元字节写入每个对象的数据块大小必须是某个对齐单位的倍数stripe_count分条对象数在一个对象集合object set内轮转多少个对象object_size对象大小字节对象达到该大小后开始使用下一批对象当 stripe_count 1 时客户端按 stripe_unit 大小把文件逻辑区间轮流映射到 stripe_count 个对象上形成对象集合stripe_count 个对象写满 object_size 后再开启下一个对象集合对象索引继续递增。最终文件在 RADOS 中的对象序列正是inode.n、inode.n1、inode.n2……3.2 布局的查看与设置CephFS 布局可以按目录继承式地设置。常用操作# 查看文件/目录的布局 getfattr -n ceph.file.layout /mnt/cephfs/somefile # 为目录设置布局新文件将继承该布局 setfattr -n ceph.file.layout.stripe_unit -v 1048576 /mnt/cephfs/bigdir setfattr -n ceph.file.layout.stripe_count -v 4 /mnt/cephfs/bigdir setfattr -n ceph.file.layout.object_size -v 4194304 /mnt/cephfs/bigdir # 或用 ceph fs 命令查看文件系统默认布局 ceph fs get cephfs在 cephfs-journal-tool.rst 中可以见到一个真实的布局 JSON 示例layout: { stripe_unit: 4194304, stripe_count: 1, object_size: 4194304 }这是一个典型的 4 MiB 对象、单对象分条布局。更完整的布局机制继承规则、pool 选择、约束条件参见 file-layouts.rst而布局与权限的结合点——只有拥有p标志layout-modification的客户端才能修改布局参见 client-auth.rst。3.3 分条与副本的关系一个容易混淆的点是分条与对象副本是相互独立的。CRUSH 算法负责把对象副本分布到多个 OSD 上例如 size3 的三副本而分条决定一个文件切分成多少个逻辑对象。因此一个文件既可能被分条成多个对象跨盘并行每个对象又拥有多份副本可靠性二者叠加而不冲突。四、两条客户端实现路径的纵深对比原文档用同一幅图描绘了两条数据通路二者的数据平面本质相同但实现位置不同维度用户态客户端libcephfs内核态客户端ceph.ko数据 I/O 库librados用户态libceph.ko内核态元数据协议libcephfs 通过 Messenger 与 MDS 通信ceph.ko 通过内核消息与 MDS 通信能力管理src/client/Client.cc中的 Cap 跟踪内核ceph文件系统驱动的 capability 结构适用场景需要灵活性的应用、ceph-fuse 挂载高吞吐的内核 VFS 挂载mount -t ceph无论哪条路径文件数据 RADOS 对象、数据直连 OSD、元数据走 MDS的架构都不变。MDS 侧对两种客户端一视同仁地执行能力协商与锁管理src/mds/Locker.cc因为能力协议是线缆级wire protocol的公共协议而不是某个客户端的私有实现。五、总结与延伸阅读CephFS 的 I/O 路径可以概括为一条主线能力协商cap message → MDS 发放能力→ 客户端直连 RADOS → 按文件布局把数据分条为inode.对象索引对象 → 并行读写 OSD。MDS 全程只参与元数据与能力仲裁不参与数据搬运单客户端场景下 cache/buffer 能力还能让客户端获得本地缓存读与写缓冲的性能收益。如果希望继续深入推荐按以下顺序阅读仓库中的相关材料doc/cephfs/cephfs-io-path.rst本文核心依据doc/architecture/ceph-protocol.rst数据分条的原理与图示doc/cephfs/file-layouts.rst布局参数的完整语义与继承规则src/include/ceph_fs.h能力位与文件布局结构的协议定义src/mds/Locker.cc 与 src/mds/Capability.hMDS 侧能力发放与锁协调的实现src/client/Client.cc用户态客户端侧能力跟踪与数据读写逻辑。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Nacos 客户端能力协商Ability Negotiation机制深度解析gRPC 连接建立期的能力协商规范与源码实现Nacos 客户端能力协商Ability Negotiation机制深度解析gRPC 连接建立期的能力协商规范与源码实现 导读 本文围绕 Nacos 的《后端微服务配置中心服务注册发现云原生Karukan上下文工程实战10个字符的lctx为什么这么够用Karukan上下文工程实战10个字符的lctx为什么这么够用 Karukan 是一个面向 Linux 与 macOS 的开源日语输入法核心是一台神经网络假人工智能NLP本地部署桌面应用listmonk数据库读写分离客户端配置连接路由listmonk数据库读写分离客户端配置连接路由 你是否在使用listmonk管理大规模邮件列表时遇到数据库性能瓶颈当订阅用户超过10万、日发送量突破百万时后端企业应用上一篇革命性嵌入式开发工具Kaluma让JavaScript运行在Raspberry Pi Pico上的完整指南下一篇告别因子冗余gs-quant多因子模型正交化全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
`：设置 Location 响应头的完整指南)
