为什么不应该在 SAN/NAS 设备上运行 MinIO（还有一个例外）

本文主要是介绍为什么不应该在 SAN/NAS 设备上运行 MinIO（还有一个例外），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

我们想分享一下我们在 SAN/NAS 设备上运行 MinIO 的想法。首先，您可以在 SAN/NAS 设备上运行 MinIO。虽然这是可能的，但这不是一个好主意，我们强烈建议客户不要采用这种方法。不要让友好的邻居 SAN/NAS 设备供应商在没有先阅读以下内容的情况下说服您。它解释了为什么这是一个坏主意以及其含义是什么。

MinIO 几乎可以在任何东西上运行。话虽如此，我们提出了一些建议，您可以在这里找到它们。如果您对任何其他框有任何疑问，请给我们留言，在 Slack 频道上提问或通过定价页面上的“咨询专家”聊天功能提问。

以下是您不应在 SAN/NAS 设备上运行 MinIO 的原因。

替代，而不是补充。对象存储是 SAN/NAS 的替代品，而不是补充。POSIX 无法在我们生活的云原生世界中扩展。正在衰落的是传统技术。由于 SAN/NAS 曾经占据的市场份额，他们非常希望将对象存储视为 API 层。事实并非如此。对象存储是云的主存储。云建立在对象存储之上，而不是 SAN/NAS。
重复的耐久性。MiniO 是一个功能齐全的对象存储，其纠删码实现针对全球规模进行了高度优化。每个对象都使用自己的基于高速公路哈希的 bitrot 哈希独立进行纠删编码。当您在 SAN/NAS 设备上运行 MinIO 时，您实际上是在重复这项工作 - 对性能的影响是可预测的。由于您正在执行两次操作，因此速度较慢，此外，SAN/NAS 设备未运行优化的纠删码，因此性能差异更加明显。
性能瓶颈。已在重复的持久性部分中引用 - 在 SAN/NAS 设备上运行 MinIO 时，性能会下降。作为一般规则，MinIO 将在几乎任何平台上最大化硬件 - 最大化使用 NVMe 的网络和带有 HDD 的驱动器（尽管较小的网络也将是 HDD 的瓶颈）。MinIO 已经并将继续投入大量资源来优化 AVX-512、NEON 和 VSX 扩展的 SIMD 优化。没有其他供应商进行过这项投资，这在基准测试中有所体现。
尽管 SAN/NAS 架构被设计为联网，但对于分布式架构来说太过繁琐。因此，高 IOPS 声明仅限于纵向扩展架构，随之而来的是挑战。一个系统中只有这么多的驱动器和 CPU。
此外，现代数据库和 AI/ML 应用程序是吞吐量密集型的，而不是 IOPS 密集型的，因为它们将数据提取到本地内存中，在那里它们可以高速执行突变和转换。吞吐量比 IOPS 更容易、更经济地扩展，因此发生了转变。

如下图所示，驱动器还有一层额外的存储网络。这会导致性能损失、复杂性增加和成本增加。

并发。SAN/NAS 设备无法允许大量应用程序通过网络大规模读取、修改文件并将其写回存储。相比之下，MinIO 将问题分解并在分布式架构中并行执行任务，以提供更高的吞吐量。

每个现代数据库和数据处理工作负载都是为分布式数据处理而设计的。Hadoop开启了大规模并行分布式数据处理的趋势。原因是纵向扩展存储架构很快就遇到了瓶颈。

与 SAN/NAS 设备相比，具有运行软件定义存储的 100GbE NIC 的直连存储相当便宜。在直连存储模型中，数十到数百个节点处理 PB 级数据的情况并不少见。

为了说明这一点，使用 32 个具有 100GbE NIC 和 16 个 NVMe SSD 的节点，您可以实现 3,200 Gbps 网络带宽和 1,536 GBps（16 个 SSD x 3GBps x 32 个节点驱动器带宽）。这在 SAN/NAS 方法中在经济上不可行，因此我们建议独立运行 MinIO。

专用存储。如果您要与 MinIO 以外的其他应用程序共享底层 SAN/NAS 基础架构，您可能希望使用 QoS 设置为 MinIO 保留吞吐量 - 尽管存在一些限制，即使这也不是一个好的解决方案。MinIO 受 I/O 限制，底层存储介质的任何波动都会体现在应用程序的性能中。
快照已过时且受限。由于 MinIO 的对象级版本控制和不可变性提供了持续的数据保护，因此它有效地使 SAN/NAS 快照过时。你所需要的只是一个没有花里胡哨的愚蠢的街区商店。

SAN/NAS 快照较差的原因是，它不支持多卷一致性快照，它不能保护快照窗口之间的任何数据丢失，并且不能扩展到大型 PB 卷。

将 MinIO 与这些劣质数据保护方案一起运行并不是在增加冗余，而是在降低平台的有效性，并通过不必要地占用过时的快照方法的驱动器空间来增加成本。

MinIO 涵盖了弹性组件，使用该功能并让快照消失。

在记下了不在 SAN/NAS 上运行 MinIO 的所有原因之后，还有一些值得讨论的其他细节可能会被证明是一般建议的例外。以下每个方案都着眼于在三种不同配置中运行的 MinIO：单服务器/单驱动器、单服务器/多驱动器和多服务器/多驱动器。

让我们从理想的场景开始 - 我们建议将其作为参考点：

在这里，MinIO 作为商用硬件上的直连存储运行，以大规模提供性能、经济性和简单性。

接下来，我们看一下在 SAN 上运行 MinIO：

许多 Web 和移动应用程序处理少量数据，通常从数百 GB 到几 TB 不等。作为一般规则，它们对性能的要求并不高。在这种情况下，如果您已经对 SAN 基础架构进行了投资，则可以在连接到 SAN LUN 的单个容器或 VM 上运行 MinIO。发生故障时，虚拟机和容器会自动移动到下一个可用的服务器，并且数据卷可以由 SAN 基础架构保护，前提是您已将其架构为此类架构。

但是，随着应用程序从单个 LUN 扩展到多个 LUN 或多个虚拟机/容器，挑战也随之而来。上述所有限制均适用于此处。每个 LUN 的扩展能力不能超过 16TB。以独立或分布式模式跨多个 LUN 提供 MinIO 可以工作，但效率不高。只要您意识到性能和复杂性方面的局限性，那么这是一种可行的方法，即使不是最佳方法。

最后，我们看一下在 NAS 上运行 MinIO：

与作为块存储的 SAN 和 DAS 不同，NAS 是一种网络文件系统。在功能上，它比 SAN 更接近对象存储。由于重叠，在充当底层存储介质时，它会严重削弱对象存储。位于 NAS 之上的对象存储根本无法克服传统的 POSIX 限制。因此，除了在单服务器/单驱动器（NAS 导出）方案中之外，您根本无法在 NAS 上运行 MinIO。