随着云原生技术日益普及的今天,在 Kubernetes 上运行无状态应用已经非常成熟,平滑扩展能力也很强,但对于有状态的应用,数据需要持久化存储,这还有很大提升的空间,面临着很多挑战。
上图是 CNCF 对于“在使用/部署容器的过程中遇到的挑战”做出的调查报告。根据报告的结果,可以总结出云原生存储遇到的挑战表现在以下几个方面:
Rook-Ceph:Rook-Ceph 是一个可以提供 Ceph 集群管理能力的 Operator,使用底层云原生容器管理,调度和编排平台提供的功能来执行其职责。
OpenEBS:OpenEBS 存储控制器本身就运行在容器中。OpenEBS Volume 由一个或多个以微服务方式运行的容器组成。
1.与云原生编排系统的融合,具有很好的容器数据卷接入能力。
2.完全开源,社区较为活跃,网络资源、使用资料丰富,容易入手。
Rook-Ceph 不足:
OpenEBS-hostpath 不足:没有高可用功能,单点故障。
OpenEBS-zfs-localpv 不足:在磁盘上安装 zfs,然后在 zfs 上 创建 vol,也是没有高可用功能。
因此多在企业内部测试环境,很少用于持久化关键应用数据,部署到生产环境中。
NeonIO 是一款支持容器化部署的企业级分布式块存储系统,能够给 Kubernetes 平台上提供动态创建(Dynamic Provisioning) 持久存储卷(Persistent Volume) 的能力,支持 Clone、Snapshot、Restore、Resize 等功能,NeonIO 的结构图如下:
NeonIO 包括的服务组件如下:
下面从以下几个方面来看 NeonIO 为什么适合云原生存储:
1.组件容器化: 服务组件、CSI、Portal 容器化
2.支持 CSI: 提供标准的 IO 接入能力,可静态、动态创建 PV
3.UI 界面,运维方便:
4.与云原生高度融合:
服务发现、分布式协调支持 etcd、元数据的管理,使用 CRD 的方式。
5.一键式部署: :helm install neonio ./neonio --namespace kube-system
6.和 Rook-Ceph 对比,部署简单灵活:
性能单 PV IOPS 100K,时延亚毫秒。
1.全闪的分布式存储架构
支持 RDMA:通过高速的 RDMA 技术将节点连接。
2.极短的 IO 路径: 抛弃文件系统,自研元数据管理系统,使 IO 路径极短。
3.使用 HostNetwork 网络模式
好处:
1.服务组件可靠性与可用性
使用探针检测 Pod 服务是否可用,是否存活,检测到 Pod 服务部可用剔除组件服务,检测到 Pod 死掉后重启 Pod,使其重新启动服务
2.数据的可靠性与可用性
Teststand: NeonIO hyper-converged all-in-one cluster (3 nodes, 192.168.101.174 - 192.168.101.176).
Note: All tests use NVMe SSDs. Volume size = 1TiB. Performance tool: https://github.com/leeliu/dbench.
图中黄色表示的是 NeonIO,第一张图纵坐标是 IOPS,第二张图纵坐标是毫秒,从结果来看,无论是单副本还是 3 副本,NeonIO 在 IOPS、时延都有明显的优势。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论