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

我们想分享一下关于在 SAN/NAS 设备上运行 MinIO 的想法。首先，你可以在 SAN/NAS 设备上运行 MinIO。虽然这可行，但这并不是一个好主意，我们强烈建议我们的客户不要采用这种方式。在阅读下面的内容之前，不要让你的友好邻里 SAN/NAS 设备供应商说服你这样做。它解释了为什么这是一个糟糕的主意以及会产生什么影响。 

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

以下列出了一些你应该避免在 SAN/NAS 设备上运行 MinIO 的原因。

1. 替代，而非补充。 对象存储是 SAN/NAS 的替代品，而不是补充。POSIX 在我们所处的云原生世界中无法扩展。它是一种正在衰落的传统技术。由于 SAN/NAS 曾经占据的市场份额，他们非常希望将对象存储视为一个 API 层。并非如此。对象存储是云的主要存储。云是建立在对象存储之上，而不是 SAN/NAS。
   
   
2. 重复的持久性。 MiniO 是一个功能齐全的对象存储，其擦除编码实现针对全球范围进行了高度优化。每个对象都独立进行擦除编码，并使用其自身的基于高速哈希的位腐烂哈希。当你在 SAN/NAS 设备上运行 MinIO 时，你实际上是在重复这项工作——并会对性能造成可预见的影响。由于你正在执行相同操作两次，因此速度会更慢，此外，SAN/NAS 设备并没有运行优化的擦除编码，这使得性能差异更加明显。
   
   
3. 性能瓶颈。 这已经在重复持久性部分提到过——当 MinIO 在 SAN/NAS 设备上运行时，性能会下降。通常情况下，MinIO 几乎可以在任何平台上最大限度地利用硬件——使用 NVMe 最大限度地利用网络，使用 HDD 最大限度地利用驱动器（尽管在使用 HDD 时，较小的网络也会成为瓶颈）。MinIO 一直致力于针对 AVX-512、NEON 和 VSX 扩展进行 SIMD 优化。没有其他供应商进行了这项投资，这一点在基准测试 中有所体现。
   
   尽管 SAN/NAS 架构旨在联网，但它们对于分布式架构来说过于频繁。因此，高 IOPS 要求仅限于纵向扩展架构——以及随之而来的挑战。在一个系统中，只能容纳有限数量的驱动器和 CPU。
   
   此外，现代数据库和 AI/ML 应用是吞吐量密集型应用，而不是 IOPS 密集型应用，因为它们会将数据拉入本地内存，然后在其中以高速执行变更和转换。吞吐量比 IOPS 更容易且更经济地扩展，因此出现了这种转变。

从下面的图片中可以看出，驱动器还有一个额外的存储网络层。这会导致性能下降、复杂性增加以及额外成本。

1. 并发性。SAN/NAS 设备无法让大量应用在网络中大规模读取文件、修改文件并将它们写回存储。相比之下，MinIO 会将问题分解并以分布式架构并行执行任务，以提供更高的吞吐量。 
   
   每个现代数据库和数据处理工作负载都针对分布式数据处理进行架构设计。Hadoop 开启了这种大规模并行分布式数据处理的趋势。原因是纵向扩展存储架构很快就会遇到瓶颈。
   
   使用 100GbE NIC 的直接连接存储运行软件定义存储，与 SAN/NAS 设备相比相当便宜。在直接连接存储模型中，看到数十到数百个节点处理 PB 级数据并不罕见。
   
   具体来说，使用 32 个具有 100GbE NIC 的节点和 16 个 NVMe SSD，你可以实现 3,200 Gbps 的网络带宽和 1,536 GBps（16 个 SSD x 3 GBps x 32 个节点驱动器带宽）。对于 SAN/NAS 方法来说，这是不经济的，因此我们建议独立运行 MinIO。
   
   
2. 专用存储。如果你除了 MinIO 之外，还与其他应用共享基础的 SAN/NAS 基础设施，你可能需要使用 QoS 设置为 MinIO 保留吞吐量——尽管有一些限制，甚至这也不是一个好的解决方案。MinIO 是 I/O 密集型应用，基础存储介质的任何波动都会反映在应用的性能中。
   
   
3. 快照已过时且有限。由于 MinIO 的对象级版本控制和不变性提供了持续数据保护，它实际上使 SAN/NAS 快照过时。你只需要一个没有花里胡哨功能的简单块存储。
   

SAN/NAS 快照性能不如 MinIO 的原因是，它不支持多卷一致性快照，无法保护快照窗口之间发生的任何数据丢失，并且无法扩展到大规模的 PB 级卷。

在这些性能较低的数据保护方案旁边运行 MinIO 不会增加冗余——它会降低平台的有效性，并通过不必要地在驱动器上占用空间来实现过时的快照方法，从而增加成本。

MinIO 已经涵盖了弹性组件，请使用该功能并放弃快照。

在注意到所有不应该在你的 SAN/NAS 上运行 MinIO 的原因之后，还有一些额外的细节值得讨论，这些细节可能被证明是上述普遍建议的例外。以下每个场景都从三个不同的配置角度分析了 MinIO 的运行：单服务器/单驱动器、单服务器/多驱动器和多服务器/多驱动器。

让我们从理想的场景开始——我们推荐它作为参考点。

在这里，MinIO 在商品硬件上作为直接连接存储运行，以提供可扩展的性能、经济性和简单性。

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

许多 Web 和移动应用处理少量数据，通常从数百 GB 到几个 TB 不等。通常情况下，它们对性能要求不高。在这种情况下，如果你已经投资了 SAN 基础设施，那么将 MinIO 运行在一个连接到 SAN LUN 的单一容器或 VM 上是可以接受的。如果发生故障，VM 和容器会自动迁移到下一个可用的服务器，并且你可以通过 SAN 基础设施来保护数据卷，前提是你已经将其架构设计为可以这样操作。

但是，随着应用从单个 LUN 扩展到多个 LUN 或多个 VM/容器，就会出现挑战。上述所有限制都适用于此。LUN 的扩展能力在每个 16TB 以上就有限。在独立或分布式模式下跨多个 LUN 提供 MinIO 服务是可行的，但效率不高。只要你了解有关性能和复杂性的限制，那么这是一种可行的，尽管不是最佳的方法。

最后，我们来看看在 NAS 上运行 MinIO。

与 SAN 和 DAS 都是块存储不同，NAS 是网络文件系统。在功能方面，它比 SAN 更接近对象存储。由于重叠，它在用作底层存储介质时会严重削弱对象存储。坐在 NAS 之上的对象存储根本无法克服传统的 POSIX 限制。因此，你只能在单服务器/单驱动器（NAS 导出）场景中在 NAS 上运行 MinIO。

即使在这种情况下，你也应该将其限制在简单的文件服务工作负载，而不是用并发读-修改-写-覆盖类型工作负载给对象存储带来负担。NAS 的一致性和并发保证很弱。一些供应商会伪造文件锁定原语，这会导致数据丢失。确保在将此设置投入生产之前，对所有类型的 I/O 进行全面测试。

结论

MinIO 以其极简主义而闻名，专注于简单性和自动化。与人们听到“极简主义”一词时所想到的概念相反，它意味着恰到好处。添加一些内容会导致它变得杂乱或臃肿，删除一些内容会导致它变得缺乏。

在 SAN/NAS 上运行 MinIO 相当于添加了一些不需要的东西。是的，你可以这样做，但这会导致你在多个级别上受到影响，多个系统会执行冗余操作。

正确的答案是在专用硬件上运行 MinIO，并使用商业许可证，以及直接与我们的工程师合作，不断改进你的部署，从而提高你组织的数据敏锐度。

数据驱动型公司比非数据驱动型公司表现出色，而当你无法快速有效地访问数据时，你根本无法成为一家数据驱动型公司。