为什么你不应该在 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 是一个功能齐全的对象存储，其纠删码实现针对全球规模进行了高度优化。每个对象都使用其自己的基于高速哈希的 bitrot 哈希独立地进行擦除编码。当您在 SAN/NAS 设备上运行 MinIO 时，您实际上是在重复这项工作——对性能的影响是可预测的。因为你做了两次，所以速度变慢了，此外 SAN/NAS 设备没有运行优化的擦除编码，使性能差异更加明显。
   
   

3. 性能瓶颈。已在重复的持久性部分中引用 - 当 MinIO 在 SAN/NAS 设备上运行时，性能将下降。作为一般规则，MinIO 将在几乎任何平台上最大化 HW——使用 NVMe 最大化网络和使用 HDD 的驱动器（尽管较小的网络也将成为 HDD 的瓶颈）。MinIO 已经并将继续投入大量资源用于 AVX-512、NEON 和 VSX 扩展的 SIMD 优化。没有其他供应商进行过这项投资，这在基准测试中得到了体现。
   
   尽管它们被设计为联网，但 SAN/NAS 架构对于分布式架构来说过于繁琐。因此，高 IOPS 要求仅限于扩展架构 - 随之而来的挑战。只有这么多驱动器和 CPU 适合单个系统。
   
   此外，现代数据库和 AI/ML 应用程序是吞吐量密集型的，而不是 IOPS 密集型的，因为它们将数据拉入本地内存，在那里它们可以高速执行变异和转换。吞吐量比 IOPS 更容易扩展，也更经济，因此发生了这种转变。

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

1. 并发。SAN/NAS 设备不允许大量应用程序通过网络大规模读取文件、修改文件并将它们写回存储。相比之下，MinIO 将问题分解并在分布式架构中并行执行任务以提供更高的吞吐量。  
   
   每个现代数据库和数据处理工作负载都是为分布式数据处理而设计的。Hadoop 开创了大规模并行分布式数据处理的趋势。原因是纵向扩展的存储架构很快就遇到了瓶颈。
   
   与 SAN/NAS 设备相比，具有运行软件定义存储的 100GbE NIC 的直接连接存储相当便宜。在直接附加存储模型中，数十到数百个节点处理 PB 级数据的情况并不少见。
   
   换句话说，使用具有 100GbE NIC 和 16 个 NVMe SSD 的 32 个节点，您可以实现 3,200 Gbps 网络带宽和 1,536 GBps（16 个 SSD x 3GBps x 32 个节点驱动器带宽）。这对于 SAN/NAS 方法在经济上不可行，为什么我们建议独立运行 MinIO。
   
   

2. 专用存储。如果除了 MinIO 之外，您还与其他应用程序共享底层 SAN/NAS 基础设施，您可能希望使用 QoS 设置为 MinIO 保留吞吐量——尽管有几个限制甚至不能成为一个好的解决方案。MinIO 受 I/O 限制，底层存储介质的任何波动都会体现在应用程序的性能上。
   
   

3. 快照已过时且受限。因为 MinIO 的对象级版本控制和不变性提供了持续的数据保护——它有效地使 SAN/NAS 快照过时了。您所需要的只是一家没有花里胡哨的哑巴商店。
   

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

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

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

注意到所有不在 SAN/NAS 上运行 MinIO 的原因后——还有一些额外的细节值得讨论，它们可能被证明是一般建议的例外。以下每个场景都着眼于三种不同配置下运行的 MinIO：单服务器/单驱动器、单服务器/多驱动器和多服务器/多驱动器。

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

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

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

许多 Web 和移动应用程序处理少量数据，通常从数百 GB 到几 TB。一般来说，他们并不渴望表现。在这种情况下，如果您已经对 SAN 基础架构进行了投资，则可以在连接到 SAN LUN 的单个容器或 VM 上运行 MinIO。如果发生故障，VM 和容器会自动移动到下一个可用服务器，并且数据量可以由 SAN 基础架构保护，前提是您已将其架构为 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，并直接与我们的工程师合作，以不断改进您的部署，从而提高您组织的数据敏锐度。

数据驱动的公司优于非数据驱动的公司，当数据访问缓慢且效率低下时，你根本无法成为数据驱动的公司。