我们想分享一下我们在 SAN NAS 设备上运行 Minio 的想法。 首先，您可以在 SAN NAS 设备上运行 Minio。 虽然这是可能的，但这不是一个好主意，我们强烈建议客户不要使用这种方法。 不要让友好邻居 SAN 的设备供应商在没有先阅读以下内容的情况下说服您。 它解释了为什么这是一个坏主意以及它意味着什么。
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 已经并将继续投入大量资源来优化 X-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 受 IO 限制，底层存储介质的任何波动都会反映在应用程序的性能上。
快照是过时且有限的。 由于 Minio 的对象级版本控制和不可变性提供了持续的数据保护，因此它有效地使 SAN NAS 快照过时。 你所需要的只是一个愚蠢的邻里商店，没有花里胡哨。
SAN NAS 快照较差的原因是它不支持多卷一致性快照，它不能防止快照窗口之间的任何数据丢失，并且不能扩展到大型 PB 卷。
使用这些劣质的数据保护方案运行 minio 并不是增加冗余，而是通过不必要地占用过时的快照方法的驱动器空间来降低平台的有效性并增加成本。
Minio 涵盖了弹性组件，使用该功能并使快照消失。
在记下了您不在 SAN NAS 上运行 Minio 的所有原因之后，还有一些其他值得讨论的细节可能会被证明是一般建议的例外情况。 以下每个场景都着眼于以三种不同配置运行的 minio：单服务器单驱动器、单服务器多驱动器和多服务器多驱动器。
让我们从理想的场景开始 - 我们建议将其作为参考点：
在这里，minio 作为商用硬件上的直连存储运行，以大规模提供性能、经济性和简单性。
接下来，让我们看一下在SAN上运行minio
许多 Web 和移动应用程序处理少量数据，通常从数百 GB 到数 TB 不等。 一般来说，它们在性能方面要求不是很高。 在这种情况下，如果您已经投资了 SAN 基础架构，则可以在连接到 SAN LUN 的单个容器或虚拟机上运行 Minio。 在发生故障时，虚拟机和容器会自动移动到下一个可用的服务器，并且数据卷可以由 SAN 基础架构保护，前提是您已将其构建为此类架构。
但是，随着应用程序从单个 LUN 扩展到多个 LUN 或多个虚拟机容器，挑战也随之而来。 上述所有限制均适用于此处。 每个 LUN 不能扩展到 16TB 以上。 在独立或分布式模式下跨多个 LUN 提供 minio 是有效的，但效率不高。 只要您意识到性能和复杂性方面的局限性，它就是一种可行的方法，即使不是最好的方法。
最后，让我们看一下在 NAS 上运行 Minio：
与块存储的 SAN 和 DAS 不同，NAS 是一种网络文件系统。 从功能上讲，它比 SAN 更接近对象存储。 由于重叠，它在充当底层存储介质时会严重削弱对象存储。 NAS之上的对象存储根本无法克服传统POSIX的局限性。 因此，除了单服务器、单驱动器（NAS 导出）场景外，您根本无法在 NAS 上运行 MiniO。
即使在这种情况下，您也应该将其限制为简单的文件服务工作负载，而不是使用并发读取-修改-写入-覆盖类型的工作负载来增加对象存储的负担。 NAS 一致性和并发性保证较弱。 一些供应商伪造文件锁原语，这可能导致数据丢失。 在将此设置投入生产之前，请确保针对各种 IO 对设置进行全面测试。
Minio 是出了名的极简主义，非常注重简单性和自动化。 与人们听到极简主义这个词时想到的相反，它的意思恰到好处。 添加一些东西，它变得杂乱无章或臃肿，拿走一些东西，它就变得缺乏了。
在 SAN NAS 上运行 Minio 相当于添加一些不需要的东西。 是的，你可以做到，但你最终会在多个层面上受到损害，多个系统执行冗余操作。
数据驱动型公司的表现优于非数据驱动型公司，当数据访问速度缓慢且效率低下时，您根本无法成为数据驱动型公司。