跳到主要内容

适用于 OpenShift 和 Kubernetes 的 vSAN 替代方案

用契合 OpenShift、KubeVirt 和现代 Kubernetes 运维的存储替换 VMware vSAN,没有 Broadcom 锁定。

离开 VMware 的团队需要的不仅仅是通用的“Kubernetes 存储”。他们需要在 VM 磁盘、快照、克隆和 Day-2 运维方面替代 vSAN 的行为, 同时契合 OpenShift 或 Kubernetes 目标架构的方案。 Simplyblock 是一个软件定义的 NVMe 块存储平台,具备 CSI 集成、通过 NVMe/TCP 实现低于 200µs 的 P99 延迟,以及跨超融合、分离式和混合 模型的部署灵活性,并且完全无需任何 Broadcom 订阅。

适用于 OpenShift 和 Kubernetes 的 vSAN 替代方案

为何 vSAN 在 VMware 退出计划中成为瓶颈

续订时的 Broadcom 价格冲击

自 Broadcom 收购 VMware 以来,vSAN 客户面临仅订阅许可,续订时成本增加 3 到 5 倍。 锁定了永久许可的团队,若不彻底替换整个堆栈,便没有干净的途径来规避新的 价格。

仅限 ESXi 的架构

vSAN 围绕 ESXi 虚拟机管理程序节点构建。当目的地是 OpenShift、Kubernetes 或 KubeVirt 时, vSAN 无法跟随:它没有 Kubernetes CSI 驱动程序,没有持久卷集成,也没有通向 云原生运维模型的路径。

硬件兼容性列表锁定

vSAN 仅在 VMware 认证的硬件上运行。刷新基础设施或转向普通服务器的团队 面临 HCL 审批流程,这限制了硬件选择,并相比开放的普通替代方案抬高了 刷新成本。

NVMe 硬件上的性能上限

vSAN 的存储路径在每次 I/O 操作上增加大量软件开销。运行现代 NVMe 节点的团队 发现 vSAN 无法达到 NVMe 原生的吞吐和延迟潜力,导致在 PostgreSQL、MySQL 和 VM 密集型 部署等工作负载上硬件容量未被利用。

一个实用的 vSAN 替代方案必须提供什么

目标不仅仅是替换一款存储产品。而是要在不延续 VMware 时代的限制或 Broadcom 时代价格的前提下, 支持 OpenShift、KubeVirt 和有状态的 Kubernetes 工作负载。

支持 OpenShift 和 KubeVirt

Simplyblock 支持 OpenShift 存储、Kubernetes CSI 工作流以及 KubeVirt VM 存储。VM 磁盘和容器持久卷共享同一个存储 平台和同一个运维模型,无需为容器和 VM 设置独立的存储孤岛。

无 VMware 锁定的 NVMe 性能

Simplyblock 通过标准以太网上的 NVMe/TCP 数据路径提供每核心高达 250,000 IOPS 和低于 200µs 的 P99 延迟,没有专有虚拟机管理程序, 没有 HCL 要求,没有 Broadcom 订阅。 软件定义存储 意味着该平台运行在团队已经拥有或可自由采购的普通硬件上。

不会把您困住的迁移路径

当超融合是最快的运维契合方案时从超融合开始,然后随着平台成熟,转向混合或分离式 部署,无需更改存储层或重新培训运维人员。如果您的 目的地特别是 Red Hat,请从 面向 OpenShift 的超融合存储开始,并从那里进行扩展。

平台团队通过 Simplyblock 获得什么

更低的成本、更高的性能,以及契合 OpenShift 和 Kubernetes 团队实际工作方式的运维模型。

TCO 最高降低 75%

消除 Broadcom vSAN 许可并减少硬件耦合。用 simplyblock 替换 vSAN 的团队 通常会通过普通硬件选择、用高效的纠删码取代三副本复制,以及没有按插槽的 订阅费用,看到总存储成本最高下降 75%。

面向 VM 和数据库的 NVMe 性能

Simplyblock 的 NVMe 优先架构提供每核心高达 250,000 IOPS 和低于 200µs 的 P99 延迟, 达到硬件实际能够实现的水平,而不是像 vSAN 那样在其之上叠加一层软件 I/O 开销 层。

HCI、混合或分离式

保持部署模型的灵活性。OpenShift 团队可以在合理之处保持超融合,并在 经济性或规模需要时将计算与存储分离,无需在架构演进时替换存储平台。

快照、克隆和弹性

即时写时复制快照、卷克隆和可配置的纠删码支持迁移、 Day-2 运维,以及平台团队对一个认真的 VMware 替代方案所期望的数据保护 工作流。

为何 vSAN 替换的搜索常常以 OpenShift 收尾

许多 VMware 退出计划实际上是平台重新设计项目。一旦团队决定将 Kubernetes 作为长期运维模型,OpenShift 便成为常见的目的地,因为它将企业策略、自动化和生命周期控制纳入同一个平台。这就是为何关于存储的讨论会从“我们如何替换 vSAN?”转向“我们如何在 OpenShift 上获得类似 vSAN 的成果?”

如果这是您的路径,请将本页与 从 VMware 迁移到 OpenShift 和 Kubernetes面向有状态工作负载的 OpenShift 存储 以及 面向 OpenShift 的超融合存储 一起阅读。

在 OpenShift 上“类似 vSAN 的存储”意味着什么

在实践中,团队通常指的是几件具体的事情:

  • 单一存储平台上的 VM 磁盘和持久卷
  • 契合 Day-2 运维的快照和克隆
  • 面向数据库和平台服务的可预测延迟
  • 在简单性重要时的超融合部署
  • 在规模变化时通向混合或分离式存储的路径

Simplyblock 通过 软件定义存储 和普通硬件上的 NVMe/TCP 存储 数据路径满足这一组需求,没有绑定 VMware 的架构,也没有 Broadcom 许可要求。

面向 OpenShift 的 HCI vs 分离式存储

一些团队希望保留他们从 vSAN 中熟悉的运维简单性,并在 OpenShift 上从超融合存储开始。另一些团队已经知道他们需要在容量和性能上进行独立扩展。更好的答案通常不是意识形态,而是一个同时支持两条路径的平台。

这就是为何 simplyblock 支持超融合、混合和分离式部署模型。如果您的近期目标是在 OpenShift 上实现类似 vSAN 的运维模型,请从 面向 OpenShift 的超融合存储 开始。如果更广泛的计划是完整的 VMware 退出,也请查看 从 VMware 迁移到 OpenShift 和 Kubernetes

Questions and Answers

在 OpenShift 上用什么替代 vSAN?

团队通常用一个支持 VM 磁盘、持久卷、快照、克隆和可预测延迟的 CSI 原生软件定义块存储平台来替代 OpenShift 上的 vSAN。 Simplyblock 正是为这一角色而设计,通过 NVMe/TCP 提供亚毫秒级的块存储,并直接对接 OpenShift 和 KubeVirt, 无需 Broadcom 许可堆栈。

能否在没有 VMware 的情况下获得类似 vSAN 的存储?

可以。主要要求并非 VMware 堆栈本身,而是存储的行为:一致的性能、 运维上简单的配置,以及对包括 VM 磁盘和快照在内的有状态工作负载的支持。 Simplyblock 通过软件定义的 NVMe 块存储和 NVMe/TCP 数据路径交付这些成果, 无需 VMware 虚拟机管理程序或 Broadcom 许可。

在性能方面 simplyblock 与 vSAN 相比如何?

vSAN 在每条 I/O 路径上都增加软件开销,阻止 NVMe 硬件达到其原生 吞吐潜力。Simplyblock 的 NVMe 优先架构在普通 NVMe 硬件上提供每核心高达 250,000 IOPS 和 低于 200µs 的 P99 延迟,这一差异对数据库、分析服务和 VM 密集型工作负载至关重要。

OpenShift 团队应保持超融合还是转向分离式存储?

这取决于工作负载组合和扩展压力。对于早期的 OpenShift 和 VMware 退出计划,超融合存储通常是最快的运维契合方案。 当计算和存储需要独立扩展时,分离式存储变得更具吸引力。 Simplyblock 同时支持两种模型,因此当架构变化时,团队无需重新平台化 存储层。

VMware 被 Broadcom 收购对 vSAN 客户有何影响?

自 Broadcom 收购 VMware 以来,vSAN 许可已转为仅订阅模式,价格 显著上涨。许多客户报告续订时成本增加 3 到 5 倍。对于已经计划转向 OpenShift 或 Kubernetes 的团队来说,这种价格压力已成为决定性因素。Simplyblock 没有按插槽 或按核心的 VMware 许可依赖。

Not sure if simplyblock is right for your team?

请您喜爱的 AI 就 VMware 到 OpenShift 的存储计划,将 simplyblock 与 vSAN、OpenShift Data Foundation 和 Ceph 进行 比较。

vSAN and all other product names, logos, and brands are property of their respective owners and are used for identification purposes only.