-
Notifications
You must be signed in to change notification settings - Fork 523
Roadmap_CN
更新时间:2022-06
提到云原生,大家都知道比较流行的云原生应用的12要素,但在这里我们不打算讲解,因为我们不是做应用的,我们做的是存储基础设施。
存储基础设施,从最早的单机存储,到后来的磁盘阵列存储,再到后来的分布式存储,就是一种逐步云化的过程,在基础设施层面我们认为所谓的云就是资源池,存储也不例外。
现阶段来说,云原生基础设施的落地主要依赖云操作系统(开源的有OpenStack、Kubernetes、Spark等,商业的主要是各大公有云),我们理解的云原生就是指在这类操作系统之上开发运行的应用,包括但不限于web服务、APP后端、消息中间件、数据库中间件、负载均衡服务、AI/ML/DL、bigdata等等(这些应用是否符合云原生应用12要素我们并不关心)。
讨论完对云原生的理解之后,我们再来讨论下云原生存储。
存储本身是一种基础设施资源,云存储就是为云操作系统提供存储子系统的,例如OpenStack Cinder对接的各种存储引擎、Kubernetes CSI插件对接的各种存储引擎、Spark等的底层存储引擎HDFS(或与HDFS兼容的存储引擎),以及各公有云厂商提供的云硬盘、NAS、对象存储等服务。基于这类存储系统,云操作系统使用方可以为其应用申请存储资源,但只有云操作系统的管理员才可以构建和维护云存储资源。
而云原生存储则与云存储有所区别,云存储是随云操作系统一起提供的基础设施资源,云操作系统的用户(云原生应用开发或运维人员)自身无法自定义资源类型、资源池大小及数量,资源如何部署维护也不了解,一切都是黑盒。云原生存储则是基于云存储之上,云原生应用的开发/运维人员自己定义的一种存储资源,一切都是白盒,所有云原生应用都可以不做修改无缝使用。
云原生存储基于云存储来构建,可以在各类云操作系统上随时构建、销毁、迁移,甚至可以同时使用多个云操作系统,做到了与云操作系统的解耦。并且其构建和运维也极其便利,不需要关注底层云存储细节和硬件基础设施,也不需要深入了解云原生存储的实现细节。
云原生存储还将与云原生应用深度糅合,使二者互相感知,提升应用的性能、用户体验、可靠性、可用性等,并尽力降低单位存储成本。例如为应用提供就近存储、就近缓存、应用备份、分层存储、异地恢复等传统云存储无法支撑的高级特性。
我们对云原生存储的理解:对上层云原生应用提供无缝的业务接口(POSIX接口、块存储接口、对象存储接口、HDFS接口等等),对下层云操作系统屏蔽云存储资源细节,对云原生应用的开发运维人员提供自定义存储类型、存储资源池(跨云)、数据生命周期管理、数据可靠性可用性策略等等。
Curve块存储本身是一种云存储系统,我们后续将尽力把Curve打造成云原生存储系统。
- 打造云原生存储系统
- 提供基于FUSE的用户态的文件读写接口
- 提供私有协议的接口SDK,HDFS协议接口SDK
- 支持多client的一写多读
- 支持数据存储到对象存储系统
- 支持数据生命周期管理
- 支持数据缓存策略(主动、被动)
- 文件系统高级特性(如快照、配额、多文件系统、多租户、内核态客户端等)
- 支持基于公有云云硬盘、对象存储等的云原生存储
- 托管的元数据服务
- 支持接管已经存储在对象存储桶中的数据
- 内部改进的需求
- 支持云原生部署、运维、使用
- 支持HDD盘及HDD/固态盘混合场景
- 快照方式的改进
- 支持作为对象存储服务的底层存储引擎
- 采用COW方式,不需要使用LOG方式来维持写的事务
- 性能优化:bRaft的multi raft改进,大io的性能优化,RDMA,io_uring,SPDK等
- 数据一致性运行时检测和恢复