Curve 文件存储的缓存策略

Curve 文件存储简介

Curve 文件存储的架构如下：

 

• 客户端 Posix 兼容：像本地文件系统一样使用，业务无缝接入，无侵入性；

• 独立的元数据集群：元数据分布式设计，可以无限扩展。同一文件系统可以在数千台服务器上同时挂载，高性能并发读写，共享数据；

• 多种数据后端的支持：数据支持存储在各种支持 S3 接口的对象存储中，也支持存储在 Curve 块存储中；

• close-to-open 一致性：文件重新 open 可以看到最新的修改信息。

Curve 文件存储数据缓存

 Curve文件系统元数据缓存

Curve 的元数据缓存并不保证全场景下的元数据一致性，对于元数据来说，需要实现大部分场景下的缓存一致性，并提供足够好的性能。当前一致性从 3 个维度来衡量：

• 文件可见性：在一个客户端执行文件创建、删除、重命名等操作，另外一个客户端可以立马看到。这一维度需要完全保证；

• 属性一致性：一个文件属性(如 atime、ctime、mtime、mode、size...)在一个客户端修改后，另外一个客户端立即能看到。针对这一维度，允许某些属性在某些场景下存在一定延迟；

• 内容一致性：文件内容符合 close-to-open 的语义，即关闭后，重新打开能立即看到全部修改。

文件的元数据缓存主要有两个部分：一部分是在 kernel 中，一部分在 CurveFS-Fuse 中：

选用 CurveFS 的原因

本地盘到 MinIO

为了符合国内的法律约束，线上系统需要按照要求存储6个月到1年不等的系统日志，主要是国内等保、金融合规等场景。按照内部管理的服务器数量，单纯syslog的日志存储空间每天就需要1T，按照当前手头有的5台12盘位4T硬盘的服务器，最多只能存储200多天的日子，无法满足日志存储1年的需求。

针对ES使用本地盘无法满足存储容量需求这一情况，网易ES底层存储之前单独引入过基于S3的存储方案来降低存储空间的消耗。如下图，ES配合minio做数据存储空间的压缩。举例来说100G的日志，到了ES里面因为可靠性需求，需要双副本，会使用200G的空间。ES针对索引分片时间，定期性转存储到minio仓库。

MinIO 到 CurveFS

这个方案从一定程度上缓解了存储空间的资源问题，但是实际使用的时候还会感觉非常不便利。

• 运维成本。ES节点升级的时候需要额外卸载安装S3插件，有一定的运维成本。

• 性能瓶颈。自己私有化搭建的Minio随着bucket里面数据量的增长，数据存储和抽取都会成为一个很大的问题

• 稳定性问题。在内部搭建的Minio集群在做数据restore的时候，因为文件处理性能等因素，经常遇到访问超时等场景，所以一直在关注是否有相关的系统可以提供更好的读写稳定性。

由于S3协议经过多年的演化，已经成了对象存储的工业标准。很多人都有想过用fuse的方式使用S3的存储能力。事实上基于S3的文件系统有很多款，例如开源的s3fs-fuse、ossfs、RioFS、CurveFS等。

在通过实际调研以及大量的测试后，基于Curve的性能（尤其是元数据方面，CurveFS是基于RAFT一致性协议自研的元数据引擎，与其他没有元数据引擎的S3文件系统(比如s3fs,ossfs)相比具备巨大的性能优势），易运维，稳定性，Curve可以同时提供块存储以及文件存储能力等能力以及Curve活跃的开源氛围，最终选用了CurveFS。

Curve是什么，CurveFS是一个基于 Fuse实现的兼容POSIX 接口的分布式文件系统，架构如下图所示: