从一开始，MinIO 就被设计成能够在各种硬件上高效运行。我们建议我们的用户和客户使用纯JBOD模式下的通用硬件，以确保底层基础设施尽可能简单高效。MinIO 是高性能和可扩展性的完美结合，这使得每个数据密集型工作负载都触手可及。MinIO 能够实现惊人的性能 - 最近的一次基准测试在 32 个节点的现成 NVMe SSD 上，GET 操作达到了 325 GiB/s（349 GB/s），PUT 操作达到了 165 GiB/s（177 GB/s）。
选择最佳数据中心站点
在考虑灾难恢复或分布式数据时，数据中心的物理位置及其与客户的距离确实很重要。您需要在能够尽可能接近边缘的客户提供数据服务，以及同时拥有能够将数据复制到多个位置的大型互联网管道的之间取得平衡。
MinIO 提供以下几种类型的复制
- 桶复制: 为每个桶配置规则，以在两个 MinIO 桶之间同步对象。桶复制在桶级别同步数据，例如桶前缀路径和对象。您可以在任何时候配置桶复制，远程 MinIO 部署可能在复制目标桶上具有预先存在的数据。
- 批量复制: 您可以使用复制作业类型创建批量作业，该作业将在某个时间间隔内将本地 MinIO 部署中的对象复制到另一个 MinIO 位置。定义文件可以按桶、前缀和/或过滤器限制复制，以便仅复制某些对象。
- 站点复制: 将跨多个站点的多个 MinIO 部署配置为称为对等站点的副本集群。每个对等站点同步桶操作、STS 以及其他组件。
自从我们推出多站点主动-主动复制以来，我们的重点一直是最大化复制性能，而不会对集群执行的现有操作造成任何额外降级。这使您能够跨多个数据中心、云复制数据以进行持续操作和分析，甚至用于灾难恢复，其中一个站点脱机不会降低整体应用程序可用性。复制配置完全在服务器端处理，采用设置后即可忘记的理念 - 使用 MinIO 的应用程序无需以任何方式修改。
我们对灵活性的承诺意味着 MinIO 支持站点和桶级别的复制，使您能够根据应用程序的需要微调复制配置，并尽可能地控制该过程。数据通过 IAM 在多个 MinIO 部署中使用 S3 风格的策略和 PBAC 保护。复制同步对象的创建、删除和修改以及桶。此外，它还同步元数据、加密设置和安全令牌服务 (STS)。请注意，您可以使用站点复制或桶复制，但不能同时使用两者。如果您已经在运行桶复制，则必须禁用它才能使站点复制工作。
选择服务器硬件
在基准测试、压力测试或建议生产硬件时，我们一直是通用硬件的支持者。使用 MinIO，无需像使用具有专有网络的专用无限带宽基础设施那样才能最大限度地提高吞吐量。MinIO 运行在通用硬件之上，管理性能和扩展性（以及大规模性能）。
我们不建议在 MinIO 之外添加 RAID 控制器或任何其他分布式复制组件。理想情况下，服务器只需要包含一组磁盘 (JBOD)，磁盘容量足够大，能够满足您预期容纳数据对象的需求，并且速度足够快，能够饱和网络。MinIO 旨在跨多个站点在软件级别处理数据的持久性、复制和弹性，而底层硬件配置可以保持最小化。稍后，我们将详细介绍服务器内部的特定组件。
驱动器
由于这里的主要用例是存储，所以让我们从谈论驱动器开始。有许多不同类型的驱动器，它们在成本、性能和容量方面差异很大；必须根据用例进行选择。驱动器可以大致分为以下三类
通常，如果您将 MinIO 集群用于生产中的基本对象存储，那么您应该考虑使用 NVMe SSD，它在成本和性能之间取得了良好的平衡。如果您处理的是一年前以上的备份和存档数据，而且这些数据很少被查询，但仍然需要访问，即使不是以闪电般的速度，那么可以将其分层到更实惠的介质中。在这些情况下，您最有可能使用存档层中的简单主轴 SATA HDD 来节省成本。
这就是 MinIO 的魅力所在；它非常简单、灵活，不仅可以在多种硬件上运行，而且您可以对对象进行版本控制并分层数据，将旧的未使用的对象数据发送到 SATA 等慢速驱动器，但将最新的或经常访问的数据保留在 NVMe 等快速介质上。如前所述，根据我们的基准测试，NVMe 提供了最佳的性能成本比。
网络
从在您自己的本地系统上工作开始，您可能会认为驱动器是存储方面的主要瓶颈。虽然这可能是事实，但是当您将分布式存储（如 MinIO）加入到组合中时，瓶颈会发生变化，您还需要考虑节点间的性能，这取决于网络。由于数据存储在多个服务器上，因此您需要确保服务器之间的数据速度尽可能快。虽然可以在 1 Gbps 或 10 Gbps 上运行，但如果您真正想要获得最佳性能，那么至少需要 25 Gbps 的速度和双 NIC。为了获得高性能，我们建议您使用您能负担得起的最快网络和 NIC - 100GbE、200GbE 和 400 GbE NIC 目前正成为生产环境中的标准。
谈到网络性能，您需要考虑一些因素。由于某些开销，尤其是在考虑分布式设置时，物理上无法达到 NIC 的最大理论速度。除了 MinIO 之外，还有其他网络服务在正常运行期间使用带宽。因此，您可以预期大约 50% 的 NIC 容量可用于 MinIO。在未来的博文中，我们将详细介绍网络内部结构以及为 MinIO 设置网络的最佳方法。
低带宽会人为地影响 MinIO 的性能，因此必须确保所有网络组件（例如光纤/以太网电缆、路由器、交换机和 NIC）都支持这些高吞吐量级别。以下是我们建议的基本图表
例如，如果您按照我们的多服务器多驱动器文档中的最低要求配置 4 个节点，每个节点有 4 个驱动器（总计 16 个驱动器），您将需要总网络可能的聚合输出为 25GbE。
CPU 和内存
MinIO 的 CPU 效率非常高，使用 TLS、内容加密、擦除编码、压缩等功能通常不会对 MinIO 产生任何重大影响。典型的 CPU 使用量用于 IO - 网络，尤其是磁盘 IO。
一般来说，MinIO 不建议购买 SMP 系统，除非您预计在独立 CPU 上运行多个 MinIO 实例。由于 MinIO 能够实现非常高的吞吐量，这意味着互连流量延迟和非一致内存访问 (NUMA) 通常会使系统速度降低到 SMP 几乎没有或没有带来任何益处的程度。
相反，MinIO 将更多地从具有更高核心数的单个 CPU 或将差价用于其他硬件改进中获益。
在考虑内存时，主要因素之一是集群上的并发请求数。并发请求总数可以按如下方式计算
totalRam / ramPerRequest
要计算每个请求使用的内存量，请使用以下计算方法
让我们看看一些基于驱动器数量和内存数量的最大并发请求数量问题
一般来说，内存量取决于集群中的请求数和驱动器数量。以下表格显示了存储量和最小和推荐的内存量。
如果您看到性能下降，例如系统内存不足，那么您可以通过添加更多节点到集群以分散负载或向当前节点添加更多内存来进行横向扩展。对于生产工作负载，我们建议使用 128GiB 的 RAM，以确保内存永远不会成为瓶颈。
机架电源
除了服务器故障外，机架及其周围的组件（例如配电单元 (PDU)、交换机、路由器以及其他设备）也容易出现故障。此外，有时由于定期维护需要将这些设备脱机，虽然采取了各种预防措施以确保维护不会使整个基础设施瘫痪，但事情并不总是按计划进行，导致在某个不可预见 的单点故障 (SPOF) 处发生故障。
在设计 MinIO 部署的配电时，务必确保每个服务器至少有两个电源单元 (PSU)，并且它们连接到来自不同断路器的两个不同的 PDU。这样做是为了确保在以下每个级别都存在冗余
- 电源故障（断路器跳闸）
- PDU 插座或插排故障
- PSU 设备或电源线故障
在将服务器连接到 PDU 时，通常建议不要超过电路额定电流的 80%。例如，如果您拥有 30 安培电路，那么您不应该将其负载超过 24 安培，否则可能会导致电路过热并跳闸。但是，情况并非总是如此。一些数据中心布线方式可能允许您使用电路额定容量的 100%。这些数据中心通常效率更高，因为与其他数据中心相比，您可以在每个机架上为更多服务器供电。
但是，如果有多个电路冗余怎么办？ 此时应该消耗多少功率？ 好吧，如果你仔细想想，如果你在一个 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 64
DD：这是一个默认的操作系统工具，用于测试驱动器性能。 独立测试每个驱动器，并将结果进行比较，以确保所有驱动器都具有相同的性能。 为了显示具有持续 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：除了上面提到的开源工具外，我们的标准和企业客户还可以通过 SUBNET 门户访问 性能和运行状况检查 工具。 这为性能数据增加了额外的见解，并且具有以下额外优势：我们的工程师能够指导您进行基础设施的架构和性能。
SUBNET 不仅深入研究集群的性能检查，而且还具有许多附加优势，例如诊断、日志、集群检查等。 但最重要的是，您将获得编写 MinIO 代码库的工程师的直接支持。 您无需打开工单来多次解释同一件事，然后再升级。 我们的 SUBNET 门户旨在以用户体验为中心，它提供类似于 Slack 的聊天体验，您可以在其中像思想流动一样编写您的信息，而我们的工程师会帮助您解决您的问题。 我们的一些客户告诉我们，SUBNET 非常神奇——世界上没有其他软件公司，他们的工程师编写了代码，并且只需单击一下即可获得他们的帮助。
通过混乱建立信心
Chaos Monkey 是最初由 Netflix 开发的工具，它故意降低原本良好的基础设施，以了解和预测不同的故障场景。 该工具执行了许多操作，但其中一个例子是将一定数量的服务器在负载下脱机，以查看其他服务器是否能够顺利承担额外的负载。
同样，对于 MinIO，我们可以变得富有创造力，并尝试模拟故障。 将几个驱动器或服务器脱机，看看您设置的 Erasure Code 计算器 设置是否按预期工作。 例如，如果您的设置要求最多 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
- 100 Gbps 网络，双 NIC
我们还为您提供了一个方便的硬件 参考 指南和 清单，其中列出了 MinIO 推荐硬件的一些配置以及我们背后的推理和计算。
此外，在将配置部署到生产环境之前，请务必使用上面提到的工具对基础设施进行压力测试，以获得基线性能。 执行 Chaos Monkey 类型的操作，以确保基础设施尽可能具有弹性，并且您的团队已准备好应对意外故障。
在最终确定硬件之前，请务必联系我们的工程团队，了解根据您的应用程序需求为您集群提供的最佳配置。 我们随时为您提供帮助！ 因此，请通过 SUBNET、Slack 或发送电子邮件至 hello@min.io 联系我们。
擦除码计算器 
参考硬件 