云原生时代下,越来越多的企业开始使用 Kubernetes(K8s)承载数据库、消息中间件等“生产级”有状态工作负载。由于这些应用对数据持久保存、性能、容量扩展和快速交付具有较高的要求,企业往往需要采用专为 Kubernetes 环境设计的持久化存储方案,来满足有状态应用的存储需求。这也是不少用户感到困惑的地方:如何从市面上众多的 K8s 存储方案中,找到适合自己的产品?

这篇文章中,我们详细对比了 Longhorn、OpenEBS、Portworx、IOMesh 等主流 K8s 持久化存储方案,通过特性对比与性能测试,为用户产品选型提供直观参考。

功能特性对比

在存储方案特性方面,Gartner 在《如何在容器与 Kubernetes 环境进行存储选型和实践(How Do I Approach Storage Selection and Implementation for Containers and Kubernetes Deployments)?》报告中,列举了 5 项云原生数据服务对传统存储方案的改进要求:

  • 软件定义与“硬件无关(hardware agnostic)”。
  • 可编程,可作为“基础设施即代码(IaC)”进行管理,由 API 驱动并支持高级和细粒度的数据服务(如高可用与数据保护)。
  • 基于分布式架构,可以任意规模部署。
  • 与多种 Kubernetes 发行版通过认证,并可与之进行互操作、实现完全集成。
  • 具有简单且可预测的跨环境许可模型。

我们参考以上要求,同时结合国内对 IT 基础架构技术自研等方面的关注,对 Longhorn、Rook、OpenEBS、Portworx 和 IOMesh 5 款产品,从技术开闭源、本土化支持、存储架构、高级数据服务、与 K8s 的集成程度等方面进行了全面对比:

基于以上对比,用户在功能特性层面的选型上需要注意以下几点:

  • 关注数据安全与合规性的用户(如金融与政府机构),应尽量选择闭源 K8s 存储方案。同时,闭源厂商往往具备更强的存储核心代码支持能力,基于开源存储技术的方案,若遇到存储部分的故障,可能无法得到及时解决。
  • OpenEBS 与 Portworx 当前没有中国本土支持,更考验运维人员在 K8s 环境方面的知识与经验储备。
  • 若采用 K8s 支持对 I/O 性能要求较高、数据一致性要求较强的应用场景(数据库、消息中间件、缓存等),应尽量选择支持块存储的解决方案。
  • 运行对连续性要求较高的应用,应尽量选择具备高可用与数据保护的产品。

性能测试

性能是评判存储系统是否能够支撑核心业务的关键指标。我们对 IOMesh、Longhorn、Portworx 和 OpenEBS 四个方案*,在 MySQL 和 PostgreSQL 数据库场景下进行了性能压测(使用 sysbench-tpcc 模拟业务负载)。

* 对 Rook 的性能测试还在进行中,测试结果会在后续文章中更新。敬请期待!

 

测试环境

  • 测试集群为 3 节点混闪配置,搭载 Intel CPU,使用 2 块 SATA SSD 做缓存,存储网卡为 10GbE。
  • 测试数据选择 2 副本场景,TPCC 测试参数:time=600, tables=4, scale=50。
  • 软件版本:IOMesh 0.10.2, Longhorn 1.1.1, Portworx 2.6.3, OpenEBS 2.9.0。

 

测试结果

四个云原生存储系统在两项测试中的 TPS、QPS 以及 P95 延迟表现如下图所示。

02_kubernetes-persistent-storage-comparison.png

 

从以上数据与对比可以看出,四个存储方案在性能与稳定性上的表现,从优到次依次为 IOMesh、Longhorn、Portworx 与 OpenEBS。

 

作为国内首款 K8s 原生的企业级分布式存储,IOMesh 可为运行在 Kubernetes 集群上的各类有状态应用提供稳定、高性能的持久化存储资源,降低方案构建成本与运维难度,加速企业云原生转型进程。欲了解方案详情,您可阅读博客、观看产品解读视频,或点击获取《IOMesh 用户指南》

 

继续阅读