文档

硬件清单

在规划生产环境的分布式 MinIO 部署的硬件配置时,请使用以下清单。

注意事项

在为您的 MinIO 实现选择硬件时,请考虑以下因素

  • 启动时要存储的预计数据量(以 tebibytes 为单位)

  • 至少在未来两年内预计的数据增长量

  • 按平均对象大小计算的对象数量

  • 数据的平均保留时间(以年为单位)

  • 要部署的站点数量

  • 预计的存储桶数量

生产硬件推荐

以下清单遵循 MinIO 的 推荐配置,适用于生产部署。提供的指导旨在作为基线,不能替代 MinIO 子网 性能诊断、架构审查和直接面向工程的支持。

与任何分布式系统一样,MinIO 从为给定 服务器池 中的所有节点选择相同配置中获益。确保在整个池节点中一致选择硬件(CPU、内存、主板、存储适配器)和软件(操作系统、内核设置、系统服务)。

如果节点具有不同的硬件或软件配置,部署可能会表现出不可预测的性能。从将陈旧数据存储在成本较低的硬件中获益的工作负载应该部署专用的“温”或“冷”MinIO 部署,并 转换 数据到该层级。

MinIO 不提供托管服务或硬件销售

请参阅我们的 参考硬件 页面,了解来自我们硬件合作伙伴的精选服务器和存储组件。

描述

最低

推荐

专用裸机或虚拟主机(“主机”)。

4 台专用主机

8 台或更多专用主机

每个主机都使用专用的本地连接驱动器.

每个 MinIO 服务器 4 个驱动器

每个 MinIO 服务器 8 个或更多驱动器

高速网络基础设施.

25GbE

100GbE

支持现代 SIMD 指令(AVX-512)的服务器级 CPU,例如 Intel® Xeon® Scalable 或更高。

每个主机 8 个 CPU/插槽或 vCPU

每个主机 16 个或更多 CPU/插槽或 vCPU

可用的内存以满足或超过每个服务器的使用量,并留有一定的缓冲区。

每个主机 32GB 可用内存

每个主机 128GB 或更多可用内存

重要

以下领域对 MinIO 性能影响最大,按重要性顺序排列

网络基础设施

吞吐量不足或有限会限制性能

存储控制器

旧固件、吞吐量有限或硬件故障会限制性能并影响可靠性

存储(驱动器)

旧固件或速度慢/老化/故障的硬件会限制性能并影响可靠性

在关注其他硬件资源(例如与计算相关的约束)之前,优先确保为这些领域中的每一个领域获取必要的组件。

以上最低推荐反映了 MinIO 在协助企业客户在各种 IT 基础设施上部署时保持所需 SLA/SLO 的经验。虽然 MinIO 可以在低于最低推荐拓扑的情况下运行,但任何潜在的成本节约都伴随着可靠性降低、性能下降或整体功能下降的风险。

网络

MinIO 建议使用高速网络以支持所连接存储的最大吞吐量(聚合驱动器、存储控制器和 PCIe 总线)。下表提供了一个关于给定物理或虚拟网络接口支持的最大存储吞吐量的通用指南。此表假设所有网络基础设施组件(如路由器、交换机和物理布线)也支持 NIC 带宽。

NIC 带宽 (Gbps)

估计的聚合存储吞吐量 (GBps)

10Gbps

1.25GBps

25Gbps

3.125GBps

50Gbps

6.25GBps

100Gbps

12.5GBps

网络对 MinIO 性能的影响最大,其中每主机带宽较低会人为地限制存储的潜在性能。以下网络吞吐量约束示例假设旋转磁盘的持续 I/O 约为 100MB/S

  • 1GbE 网络链路最多可支持 125MB/s,或一个旋转磁盘

  • 10GbE 网络可支持约 1.25GB/s,可能支持 10-12 个旋转磁盘

  • 25GbE 网络可支持约 3.125GB/s,可能支持约 30 个旋转磁盘

内存

内存主要限制每个节点的并发连接数。

您可以使用以下公式计算每个节点的最大并发请求数

\(totalRam / ramPerRequest\)

要计算每个请求使用的 RAM 量,请使用以下公式

\(((2MiB + 128KiB) * driveCount) + (2 * 10MiB) + (2 * 1 MiB)\)

10MiB 是默认的擦除块大小 v1。1 MiB 是默认的擦除块大小 v2。

下表列出了基于主机驱动器数量和可用系统 RAM 的节点上的最大并发请求数

驱动器数量

32 GiB 的 RAM

64 GiB 的 RAM

128 GiB 的 RAM

256 GiB 的 RAM

512 GiB 的 RAM

4 个驱动器

1,074

2,149

4,297

8,595

17,190

8 个驱动器

840

1,680

3,361

6,722

13,443

16 个驱动器

585

1,170

2.341

4,681

9,362

下表提供了一些关于根据节点上的本地存储总量分配用于 MinIO 的内存的通用指南

主机存储总量

建议的主机内存

最多 1 Tebibyte (Ti)

8GiB

最多 10 Tebibyte (Ti)

16GiB

最多 100 Tebibyte (Ti)

32GiB

最多 1 Pebibyte (Pi)

64GiB

超过 1 Pebibyte (Pi)

128GiB

重要

RELEASE.2024-01-28T22-35-53Z 开始,MinIO 在分布式设置中每个节点预分配 2GiB 的内存,并在单节点设置中预分配 1GiB 的内存。

存储

对驱动器的独占访问

MinIO 需要对提供用于对象存储的驱动器或卷进行独占访问。任何其他进程、软件、脚本或人员都不应对提供给 MinIO 的驱动器或卷或 MinIO 在其上放置的对象或文件执行任何直接操作。

除非 MinIO 工程指导,否则不要使用脚本或工具直接修改、删除或移动提供驱动器上的任何数据分片、奇偶校验分片或元数据文件,包括从一个驱动器或节点移动到另一个驱动器或节点。此类操作极有可能导致广泛的损坏和数据丢失,超出 MinIO 的修复能力。

使用直接连接的“本地”存储 (DAS)

DAS,例如本地连接的 JBOD(Just a Bunch of Disks)阵列,与联网存储(NAS、SAN、NFS)相比,提供了显著的性能和一致性优势。

网络文件系统卷破坏一致性保证

MinIO 的严格写入后读取写入后列出一致性模型需要本地驱动器文件系统。如果底层存储卷是 NFS 或类似的网络连接存储卷,则 MinIO 无法提供一致性保证。

使用带有标签的 XFS 格式化驱动器

将驱动器格式化为 XFS,并将其作为 JBOD 阵列呈现给 MinIO,没有 RAID 或其他池化配置。使用任何其他类型的后备存储(SAN/NAS、ext4、RAID、LVM)通常会导致性能、可靠性、可预测性和一致性下降。

格式化 XFS 驱动器时,请为每个驱动器应用一个唯一的标签。例如,以下命令将四个驱动器格式化为 XFS 并应用相应的驱动器标签。

mkfs.xfs /dev/sdb -L MINIODRIVE1
mkfs.xfs /dev/sdc -L MINIODRIVE2
mkfs.xfs /dev/sdd -L MINIODRIVE3
mkfs.xfs /dev/sde -L MINIODRIVE4

使用 /etc/fstab 挂载驱动器

MinIO 需要驱动器在重启时保持其在挂载位置的排序。MinIO 不支持将具有现有 MinIO 数据的驱动器任意迁移到新的挂载位置,无论是故意的还是由于操作系统级别的行为所致。

必须使用 /etc/fstab 或类似的挂载控制系统将驱动器挂载到一致的路径。例如

$ nano /etc/fstab

# <file system>        <mount point>    <type>  <options>         <dump>  <pass>
LABEL=MINIODRIVE1      /mnt/drive-1     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE2      /mnt/drive-2     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE3      /mnt/drive-3     xfs     defaults,noatime  0       2
LABEL=MINIODRIVE4      /mnt/drive-4     xfs     defaults,noatime  0       2

您可以在初始设置期间使用 mount -a 将这些驱动器挂载到这些路径。否则,操作系统应该在节点启动过程中挂载这些驱动器。

MinIO 强烈建议使用基于标签的挂载规则而不是基于 UUID 的规则。基于标签的规则允许用具有匹配格式和标签的替换驱动器替换不健康或无法工作的驱动器。基于 UUID 的规则要求编辑 /etc/fstab 文件以将映射替换为新的驱动器 UUID。

注意

依赖于挂载外部存储的云环境实例可能会遇到启动失败,如果一个或多个远程文件挂载返回错误或失败。例如,如果一个或多个 EBS 卷无法挂载,则使用挂载持久性 EBS 卷的 AWS ECS 实例可能无法使用标准 /etc/fstab 配置启动。

您可以设置 nofail 选项以在启动时静默错误报告,并允许实例在存在一个或多个挂载问题的情况下启动。

您不应该在具有本地连接磁盘的系统上使用此选项,因为静默驱动器错误会阻止 MinIO 和操作系统以正常方式响应这些错误。

禁用 XFS 错误重试

MinIO 强烈建议使用 max_retries 配置禁用以下错误类别中的 错误重试 行为

  • EIO 读取或写入时出错

  • ENOSPC 设备上没有剩余空间

  • default 所有其他错误

默认的 max_retries 设置通常会指示文件系统无限期地重试错误,而不是传播错误。MinIO 可以适当地处理 XFS 错误,因此错误重试行为最多会引入不必要的延迟或性能下降。

以下脚本遍历指定挂载路径下的所有驱动器,并将 XFS max_retries 设置设置为 0 或“立即出错”以用于推荐的错误类别。该脚本会忽略任何未挂载的驱动器,无论是手动挂载的还是通过 /etc/fstab 挂载的。修改 /mnt/drive 行以匹配用于 MinIO 驱动器的模式。

#!/bin/bash

for i in $(df -h | grep /mnt/drive | awk '{ print $1 }'); do
      mountPath="$(df -h | grep $i | awk '{ print $6 }')"
      deviceName="$(basename $i)"
      echo "Modifying xfs max_retries and retry_timeout_seconds for drive $i mounted at $mountPath"
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/EIO/max_retries
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/ENOSPC/max_retries
      echo 0 > /sys/fs/xfs/$deviceName/error/metadata/default/max_retries
done
exit 0

您必须在所有 MinIO 节点上运行此脚本,并将脚本配置为在重启时重新运行,因为 Linux 操作系统通常不会持久保存这些更改。您可以使用 cron 作业,使用 @reboot 定时来在节点每次重启时运行上述脚本,并确保所有驱动器都已禁用错误重试。使用 crontab -e 创建以下作业,修改脚本路径以匹配每个节点上的脚本路径

@reboot /opt/minio/xfs-retry-settings.sh

使用一致的驱动器类型和容量

确保 MinIO 部署中底层存储的一致驱动器类型(NVMe、SSD、HDD)。MinIO 不会区分存储类型,也不支持在单个部署中配置“热”驱动器或“温”驱动器。混合驱动器类型通常会导致性能下降,因为部署中最慢的驱动器会成为瓶颈,而与速度更快的驱动器的功能无关。

在每个 MinIO 服务器池 中的所有节点上使用相同容量和类型的驱动器。MinIO 将每个驱动器的最大可用大小限制为部署中最小的尺寸。例如,如果一个部署有 15 个 10TB 驱动器和 1 个 1TB 驱动器,则 MinIO 将每个驱动器的容量限制为 1TB。