云原生时代下，越来越多的企业开始使用 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 的集成程度等方面进行了全面对比：
文章来源地址https://www.toymoban.com/news/detail-613234.html
基于以上对比，用户在功能特性层面的选型上需要注意以下几点：
- 关注数据安全与合规性的用户（如金融与政府机构），应尽量选择闭源 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 延迟表现如下图所示。
从以上数据与对比可以看出，四个存储方案在性能与稳定性上的表现，从优到次依次为 IOMesh、Longhorn、Portworx 与 OpenEBS。
作为国内首款 K8s 原生的企业级分布式存储，IOMesh 可为运行在 Kubernetes 集群上的各类有状态应用提供稳定、高性能的持久化存储资源，降低方案构建成本与运维难度，加速企业云原生转型进程。欲了解方案详情，您可阅读博客、观看产品解读视频，或点击获取《IOMesh 用户指南》。
扫描下方二维码，一键获取 IOMesh 1.0.0 用户指南。文章来源：https://www.toymoban.com/news/detail-613234.html
到了这里，关于Longhorn vs Rook vs OpenEBS vs Portworx vs IOMesh：细说 5 款 K8s 持久化存储产品优劣势的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
