纠删码计算器
参考硬件
为您的 MinIO 部署选择最佳硬件
从一开始，MinIO 就被设计成可以在多种不同类型的硬件上高效运行。我们建议我们的用户和客户在纯 JBOD 模式下使用带有磁盘的商用硬件，以确保底层基础设施尽可能简单和高效。MinIO 是高性能和可扩展性的完美结合，这使得每个数据密集型工作负载都触手可及。MinIO 具有惊人的性能——最近的基准测试在 GET 上达到了 325 GiB/s (349 GB/s)，在 PUT 上达到了 165 GiB/s (177 GB/s)，只有 32 个现成的 NVMe SSD 节点。
选择最佳数据中心站点
在考虑灾难恢复或分布式数据时，数据中心的物理位置及其与客户的距离很重要。您希望在能够尽可能靠近边缘客户提供数据与同时访问能够将数据复制到多个位置的大型 Internet 管道之间取得平衡。
MinIO 提供以下类型的复制：
Bucket Replication：配置每个桶规则以在两个 MinIO 桶之间同步对象。Bucket Replication 在桶级别同步数据，例如桶前缀路径和对象。您可以随时配置存储桶复制，远程 MinIO 部署可能在复制目标存储桶上有预先存在的数据。
Batch Replication：您可以使用 replicate 作业类型创建一个批处理作业，以一定时间间隔将对象从本地 MinIO 部署复制到另一个 MinIO 位置。定义文件可以通过存储桶、前缀和/或过滤器限制复制以仅复制某些对象。
站点复制：将跨多个站点的多个 MinIO 部署配置为称为对等站点的副本集群。每个对等站点同步存储桶操作、STS 以及其他组件。
自从我们引入多站点主动-主动复制以来，我们的重点一直是在不对集群执行的现有操作造成任何额外影响的情况下最大限度地提高复制性能。这使您可以跨多个数据中心、云复制数据以进行持续操作和分析，甚至可以在一个站点离线不会降低整体应用程序可用性的情况下进行灾难恢复。复制配置完全在服务器端处理，具有“设置后不用管”的精神——使用 MinIO 的应用程序不需要以任何方式进行修改。
我们对灵活性的专注意味着 MinIO 支持现场和存储桶级别的复制，使您能够根据应用程序的需要微调复制配置，并尽可能多地控制流程。使用 S3 样式策略和 PBAC，跨多个 MinIO 部署的 IAM 仍然保护数据。复制同步对象和桶的创建、删除和修改。此外，它还同步元数据、加密设置和安全令牌服务 (STS)。请注意，您可以使用站点复制或存储桶复制，但不能同时使用两者。如果您已经在运行存储桶复制，则必须禁用它才能使站点复制正常工作。
选择服务器硬件
在基准测试、压力测试或建议生产硬件期间，我们一直是商品硬件的支持者。使用 MinIO，不需要像具有专有网络的专用 infiniband 基础设施这样的东西来最大化吞吐量。性能和扩展（以及大规模性能）由运行在商品硬件之上的 MinIO 管理。
我们不建议在 MinIO 之外添加 RAID 控制器或任何其他分布复制组件。理想情况下，服务器只需要包括一组具有足够驱动器容量的磁盘 (JBOD)，以满足您预期的数据对象存储需求和使网络饱和的速度。MinIO 旨在跨多个站点在软件级别处理数据的持久性、复制和弹性，同时可以将底层硬件配置保持在最低限度。稍后，我们将详细介绍服务器内部的特定组件。
驱动器
由于这里的主要用例是存储，所以让我们从谈论驱动器开始。有许多不同类型的驱动器，每种驱动器在成本、性能和容量方面都有很大差异；必须根据用例进行选择。驱动大致可以分为以下三类：
通常，如果您在生产中使用 MinIO 集群作为基本对象存储，那么您可能应该考虑使用 NVMe SSD 之类的东西，它可以在成本和性能之间取得良好的平衡。如果您正在处理超过一年的备份和存档数据，并且不经常查询，但仍然需要访问它，尽管速度不是闪电般的，那么它可以分层到更实惠的媒体。在这些情况下，您很可能会在归档层中使用简单的主轴 SATA HDD 以节省成本。
这就是 MinIO 的美妙之处；它非常简单、灵活，不仅可以在无数硬件上运行，而且您可以对对象和分层数据进行版本控制，以将旧的未使用对象数据发送到 SATA 等慢速驱动器，但将最新或经常访问的数据保留在 NVMe 等快速介质上。如前所述，根据我们的基准测试，NVMe 提供了最佳的性价比。
网络
在您自己的本地系统上工作时，您可能会认为驱动器是存储方面的主要瓶颈。虽然可能是这种情况，但当您将分布式存储添加到 MinIO 等组合中时，瓶颈就会转移，您还需要考虑依赖于网络的节点间性能。因为数据是跨多个服务器存储的，所以需要保证服务器之间的数据传输速度尽可能快。虽然可以以 1 Gbps 或 10 Gbps 的速度运行，但如果您真的想要顶级性能，则需要使用双 NIC 至少达到 25 Gbps 的速度。为了获得高性能，我们建议您使用您能负担得起的最快的网络和 NIC——100GbE、200GbE 和 400 GbE NIC 是我们目前在生产中看到的标准。
在谈论网络性能时，您需要考虑几件事。由于某些开销，尤其是在考虑分布式设置时，实际上不可能达到 NIC 的最大理论速度。除了 MinIO 之外，还有其他网络服务在其正常操作期间使用带宽。因此，您可以预期大约 50% 的 NIC 容量可用于 MinIO。在未来的博客文章中，我们将详细介绍网络的内部结构以及为 MinIO 设置网络的最佳方式。
低带宽会人为地影响 MinIO 的性能，因此必须确保所有网络组件（例如光纤/以太网电缆、路由器、交换机和 NIC）支持这些级别的高吞吐量。以下是我们推荐的指南的基本图表：
例如，如果您的最低要求是 4 个节点，每个节点有 4 个驱动器（总共 16 个驱动器）配置来自我们的多服务器多驱动器文档，您将需要 25GbE 的总网络可能聚合输出。
中央处理器和内存
MinIO 的 CPU 效率非常高，使用 TLS、内容加密、纠删码、压缩等功能通常不会对 MinIO 产生任何重大影响。典型的 CPU 使用率用于 IO - 网络，尤其是磁盘 IO。
一般来说 MinIO 不建议购买 SMP 系统，除非你希望在离散的 CPU 上运行多个 MinIO 实例。由于 MinIO 具有非常高的吞吐量，这意味着互连流量延迟和非统一内存访问 (NUMA) 通常会大大降低系统速度，以至于 SMP 几乎没有任何好处。
相反，MinIO 将从具有更高核心数的单个 CPU 中获益更多，或者将差额用于其他硬件改进。
考虑内存时，主要因素之一是集群上的并发请求量。并发请求总数可以计算如下
totalRam / ramPerRequest
要计算每个请求使用的 Ram 数量，请使用以下计算
让我们看几个基于驱动器和ram数量的最大并发请求数的问题
一般来说，内存量取决于请求数和集群中的驱动器数。下表显示了存储量和推荐的最小内存。
如果您看到性能下降，例如系统内存不足，那么您可以通过向集群添加更多节点来分散负载或向当前节点添加更多内存来水平扩展。对于生产工作负载，我们建议使用 128GiB RAM 以确保内存永远不会成为瓶颈。
机架电源
除了服务器故障外，机架及其周围的组件（如配电单元 (PDU)、交换机、路由器等设备）也可能出现故障。此外，有时这些由于定期维护需要离线，虽然采取了一切预防措施以确保维护不会破坏整个基础设施，但事情并不总是按计划进行，导致某些不可预见的单点故障故障（SPOF）。
在为 MinIO 部署设计配电时，最重要的是确保每台服务器至少有 2 个电源单元 (PSU)，并且它们连接到来自不同断路器的两个不同 PDU。这是为了确保以下每个级别都有冗余：
电源故障（断路器跳闸）
PDU 插座或条带故障
PSU 设备或电源线故障
将服务器连接到 PDU 时，通常建议不要超过电路额定安培数的 80%。例如，如果您配备了一个 30 安培的电路，那么您不应为其加载超过 24 安培的电流，否则会有电路过热和断路器跳闸的风险。然而，这并非总是如此。一些数据中心的接线方式可能会使用 100% 的电路额定容量。这些通常效率更高，因为与其他方式相比，您可以为每个机架的更多服务器供电。
但是当有 2 个冗余电路时呢？此时应该消耗多少功率？好吧，如果你考虑一下，如果你只能在一个 30 安培的电路上使用 24 安培，那么如果有 2 个电路，我们每个电路只能使用 12 安培。这样做的原因是当整个电路断电时，另一个电路需要接管额外的负载。如果两个电路都加载到 80%，那么在故障转移期间，单个电路将最终使用 24 + 24 总电流或 48 安培，它也会使“良好”电路跳闸。因此，建议在使用 2 个冗余电路时仅使用 50% 的可用电路容量。
基准测试工具
对于任何生产环境，您都希望确保对基础架构执行性能和压力测试。这可确保您在将生产数据放置在节点上之前解决设置中的任何瓶颈或边缘情况。我们为开源社区和客户提供了许多基准测试工具。
Perf 测试：集成为 `mc` 管理工具的一部分，perf 测试可帮助您对 MinIO 集群进行快速性能评估。使用结果，您可以跟踪性能加班或查看您可能遇到的特定陷阱。您将按如下方式运行命令：
mc support perf alias
WARP：这是一个由 MinIO 内部开发的工具，并作为一个单独的二进制文件开源，通过对 MinIO 集群使用的所有磁盘执行读写混合测试，彻底对 MinIO 或任何 S3 兼容存储进行基准测试。例如，这就是您启动 warp 混合基准测试的方式：
WARP_ACCESS_KEY=minioadmin WARP_SECRET_KEY=minioadmin ./warp mixed --host host{1...4}:9000 --duration 120s --obj.size 64M --concurrent 64DD：这是测试驱动器性能的默认操作系统工具。独立测试每个驱动器并比较结果以确保所有驱动器都提供相同的性能。要显示具有一致 I/O 的实际驱动器性能，请在写入操作期间测试驱动器性能。
dd if=/dev/zero of=/mnt/driveN/testfile bs=128k count=80000 oflag=direct conv=fdatasync > dd-write-drive1.txt
另外测试是在读取操作期间
dd if=/mnt/driveN/testfile of=/dev/null bs=128k iflag=direct > dd-read-drive1.txt
运行 dd 时要记住的一件事是确保您使用的对象与您在生产中期望的大小相似，以获得准确的结果。例如，如果您希望处理许多（几百万）个小文件，那么使用这么多文件和大小测试性能以确保它在生产中表现良好。
IO 控制器测试：IOZone I/O 测试集群内节点上控制器和所有驱动器的读写性能。以下是您将运行的示例命令：
iozone -s 1g -r 4m -i 0 -i 1 -i 2 -I -t 160 -F /mnt/sdb1/tmpfile.{1..16} /mnt/sdc1/tmpfile.{1..16} /mnt/sdd1/tmpfile.{1..16} /mnt/sde1/tmpfile.{1..16} /mnt/sdf1/tmpfile.{1..16} /mnt/sdg1/tmpfile.{1..16} /mnt/sdh1/tmpfile.{1..16} /mnt/sdi1/tmpfile.{1..16} /mnt/sdj1/tmpfile.{1..16} /mnt/sdk1/tmpfile.{1..16} > iozone.txt子网：除了上面提到的开源工具，我们的标准和企业客户还可以通过子网门户访问性能和健康检查工具。这增加了对性能数据的额外洞察力，并使我们的工程师能够在基础架构的架构和性能方面为您提供指导。
SUBNET 不仅深入到集群的性能检查中，而且还有许多额外的好处，例如诊断、日志、集群检查等。但最重要的是，您将获得我们编写 MinIO 代码库的工程师的直接支持。在升级之前，您无需多次开票解释同一件事。我们的 SUBNET 门户在设计时充分考虑了用户体验，它提供了类似聊天的体验，这与 Slack 不同，您可以在思绪流动时编写消息，同时我们的工程师会帮助您解决问题。我们的一些客户告诉我们，SUBNET 很神奇——没有其他软件公司可以让编写代码的工程师点击一下鼠标。
在混乱中建立信心
Chaos Monkey是一种最初由 Netflix 开发的工具，用于故意降低原本良好的基础设施，以了解和预测不同的故障场景。该工具可以做很多事情，但一个例子是让一定数量的服务器在负载下脱机，以查看其他服务器如何优雅地接管额外的负载。
与 MinIO 类似，我们可以发挥创造力并尝试模拟故障。将几个驱动器或服务器脱机，以查看您设置的纠删码计算器设置是否确实应按照计算器的预期工作。例如，如果您的设置要求在任何给定时间最多有 4 台服务器停机/离线，请尝试实际随机关闭 4 台服务器以查看集群是否仍在运行。这是在管理 MinIO 时在团队中建立信心的好方法，因此在将来发生故障或需要进行维护时，每个人都可以确切地知道对集群的期望。
您还可以尝试使单个网络设备脱机，例如交换机或整个机架，因为 MinIO 不仅可以了解驱动器和服务器级别的冗余，还可以了解机架级别的冗余，如下所示：
minio server http://rack{1…n}.host{1…n}/drive{1…n}
什么是理想的硬件配置？
事实上，MinIO 没有最佳的硬件配置。我们的客户根据他们的用例和要求选择硬件。如果 MinIO 有一个单一的最佳硬件配置，那么我们会在设备上销售 MinIO，但这会剥夺您为工作选择最佳硬件的自由，并将您锁定在特定的外形规格中。相反，我们选择让您能够选择最佳硬件或实例来实现您的目标。
请放心，无论您选择哪种硬件，MinIO 都旨在从中提取最大的性能。
在上面提到的 32 节点基准测试中，我们没有使用任何性能调优的硬件，而是依赖于商用硬件上的通用 NVMe SSD。设置如下：
32 个节点，每个节点具有：
96 个 CPU 内核
768 GB 内存
8 个 7500 GB NVMe SSD
具有双 NIC 的 100 Gbps 网络
我们还为您提供了一个方便的硬件参考指南和清单，向您展示了 MinIO 推荐硬件的一些配置以及我们背后的推理和计算。
此外，在将配置部署到生产环境之前，请务必使用上述工具对基础设施进行压力测试以获得基准性能。执行 Chaos Monkey 类型的操作，以确保基础架构尽可能具有弹性，并确保您的团队为意外故障做好准备。
在最终确定您的硬件之前，请务必联系我们的工程团队，根据您的应用程序要求为您的集群提供最佳配置。我们随时为您提供帮助！因此，请通过SUBNET、Slack或发送电子邮件至 sales@minio.org.cn 联系我们。