DirectPV 简介

DirectPV 是一个用于直连存储的 CSI 驱动程序。在最基本的层面上，它是一个分布式持久卷管理器，而不是像 SAN 或 NAS 这样的存储系统。DirectPV 用于在服务器之间发现、格式化、挂载、调度和监控驱动器。

在我们深入了解 DirectPV 的架构之前，让我们先解决一下为什么我们需要构建它。

历史

现代分布式数据存储，如对象存储、数据库、消息队列和 AI/ML/分析工作负载，被设计为在带有本地连接驱动器的商用现成服务器上运行。由于它们已经处理了诸如擦除编码或复制和高可用性等关键存储功能，因此它们只需要以 JBOD 配置（一堆驱动器）直接本地访问简单的商用驱动器。在 Kubernetes 环境中使用网络附加存储 (NAS) 和存储区域网络 (SAN) 硬件设备来提供这些分布式数据服务既效率低下，也是 Kubernetes 的反模式。您将在引入驱动器和主机之间第二个网络跃点的同时复制已经复制的数据。两者都没有必要。即使对于 超融合基础设施 也是如此。

LocalPV 与 NetworkPV

Kubernetes 早期通过 Hostpath 和 LocalPV 功能引入了对本地连接存储的初步支持。但是，自从引入 Kubernetes 容器存储接口 (CSI) 驱动程序模型以来，这项工作一直留给存储供应商，以扩展核心 Kubernetes 之外的功能。

API 不偏向于本地 PV 或网络 PV 方法。它以抽象的 API 术语编写，就像 API 应该做的那样。当时，持久卷市场由 SAN 供应商主导。这仅仅是由于历史上存储供应商都是文件和块供应商的事实。即使在今天，与对象存储供应商相比，SAN 和 NAS 供应商也多得多——尽管对象存储在主要工作负载中的增长。这将随着时间的推移而自行解决。但我们扯远了。

由于有更多的 SAN 或 NAS 供应商，并且由于它们并非天生就是云原生的（POSIX 与 S3/RESTful API），因此他们非常努力地将 CSI 吹捧为桥接解决方案。

在应用程序领域，SAN/NAS 供应商花费了不成比例的时间来讨论解耦。在他们的叙述中，解耦发生在无状态微服务和容器与有状态服务（如数据存储）之间。这些数据存储的示例包括 MinIO、Cassandra 和 Kafka。

存储供应商争先恐后地为其 SAN 和 NAS 硬件设备提供 Kubernetes CSI 驱动程序，但他们对实现会蚕食自身产品的 CSI 驱动程序没有兴趣。VMware 最早认识到这个问题，并引入了 vSAN Direct 来解决此 LocalPV 问题。但是，此解决方案仅适用于 VMware Tanzu 客户。

第二个遵循的是 OpenEBS LocalPV，它提供本地和网络持久卷。其他像 LongHorn 这样的项目正在计划支持 LocalPV 功能（https://github.com/longhorn/longhorn/issues/3957）。

DirectPV 简介

由于 MinIO 从头开始构建以实现云原生，因此我们的许多 MinIO 部署都在 Kubernetes 上。我们经常处理每个机箱容纳 12 到 108 个驱动器的 JBOD。虽然我们喜欢 Kubernetes 原生 LocalPV 的简单性，但它在操作上无法扩展。卷必须静态预配，并且没有简单的方法来管理大量驱动器。此外，LocalPV 缺乏 CSI 驱动程序模型的复杂性。

考虑到 MinIO 的极简设计理念，我们寻求具有有用卷管理功能（如驱动器发现、格式化、配额和监控）的动态 LocalPV CSI 驱动程序实现。市场上没有这样的驱动程序，所以我们做了我们一直做的事情，我们自己构建了一个。

因此引入了直接持久卷 - https://min-io.cn/directpv。

DirectPV 是一个用于直接连接存储 (DAS) 的 Kubernetes 容器存储接口 (CSI) 驱动程序。一旦本地卷被预配并连接到容器，DirectPV 不会妨碍应用程序 I/O。所有读写操作都直接在卷上执行。您可以预期性能与本地驱动器一样快。分布式有状态服务（如 MinIO、Cassandra、Kafka、Elastic、MongoDB、Presto、Trino、Spark 和 Splunk）将从 DirectPV 驱动程序中获益匪浅，满足其热层需求。为了长期持久性，它们可以使用 MinIO 对象存储作为温层。MinIO 将反过来使用 DirectPV 将数据写入持久存储介质。

这有效地将行业从基于传统 SAN 和 NAS 的存储系统中解放出来。

DirectPV 内部

控制器

当提出卷声明时，控制器会从可用驱动器池中统一预配卷。DirectPV 了解 Pod 的亲和性约束，并从 Pod 本地驱动器中分配卷。请注意，每个集群仅运行一个活动的控制器实例。

节点驱动程序

节点驱动程序实现卷管理功能，例如节点上驱动器的发现、格式化、挂载和监控。节点驱动程序的一个实例在每个存储服务器上运行。

UI

存储管理员可以使用 kubectl CLI 插件来选择、管理和监控驱动器。集成的 Web UI 目前正在开发中。

试一试！

DirectPV 完全开源，安装也很简单。它只需要两个步骤。成功安装 DirectPV krew 插件后，尝试使用 info 命令以确保安装成功。

接下来，您将发现所有驱动器并将其置于 DirectPV 管理之下。从现在开始，这些驱动器将专门由 DirectPV 用于 Kubernetes 容器。

$ kubectl directpv drives ls

$ kubectl directpv drives format -drives /dev/sd{a…f} -nodes directpv-{1…n}

您的驱动器现在可以作为 LocalPV 动态预配了。Pod 将自动获得与具有匹配 LocalPV 的节点的亲和性。要提出卷声明，请在 PodSpec.VolumeClaimTemplates 中使用 directpv 作为存储类。

总结

您会立即注意到直接持久卷的效率和简单性。消除了整整一层复杂性。应用程序通过数据存储直接与数据通信，消除了传统 SAN/NAS 层。DirectPV 省去了所有额外的网络硬件需求，所有额外的管理。

DirectPV 的优势在于其极简设计。因此，它解决了 LocalPV 问题——但仅限于此问题。我们不打算添加对 NetworkPV 的支持，因为它们适用于传统应用程序，并且市场上有一些解决方案可以解决它们。

Github: https://github.com/minio/directpv

社区 Slack 频道：https://slack.min.io/