硬件清单
在规划生产环境的分布式 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 的修复能力。
推荐的存储介质
MinIO 建议对所有工作负载类型和规模使用基于闪存的存储(NVMe 或 SSD)。需要高性能的工作负载应该优先选择 NVMe 而不是 SSD。
使用基于 HDD 的存储的 MinIO 部署最适合用作 对象转换(“分层”) 的冷层目标,用于存放陈旧数据。HDD 存储通常无法提供满足现代工作负载预期的性能,并且任何规模上的成本效益都将被该介质的性能限制所抵消。
使用直接连接的“本地”存储 (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。
推荐的硬件测试
MinIO 诊断
运行内置的健康诊断工具。如果您有权访问 SUBNET,您可以将结果上传到那里。
mc support diag ALIAS --airgap
将 ALIAS 替换为为部署定义的 alias
。
MinIO 支持诊断工具
对于已在 MinIO SUBNET 上注册的部署,您可以运行内置的支持诊断工具。
运行三个 mc support perf
测试。
这些服务器端测试验证网络、驱动器和对象吞吐量。使用默认选项运行所有三个测试。
网络测试
对别名为
minio1
的集群运行网络吞吐量测试。mc support perf net minio1
驱动器测试
对别名为
minio1
的集群,运行所有节点上所有驱动器的驱动器读写性能测量。该命令使用默认的 4MiB 块大小。mc support perf drive minio1
对象测试
测量别名为
minio1
的对象上的 S3 读写性能。MinIO 自动调整并发性以获得最大吞吐量和 IOPS(每秒输入/输出操作)。mc support perf object minio1
操作系统诊断工具
如果您无法运行 mc support diag
或结果显示意外结果,您可以使用操作系统的默认工具。
独立测试所有服务器上的每个驱动器,以确保它们的性能相同。使用这些操作系统级工具的结果来验证存储硬件的功能。记录结果以备将来参考。
测试驱动器在写入操作期间的性能
此测试通过创建指定数量的块(一次最多一定数量的字节)来模拟驱动器在写入未缓存数据时的工作方式,从而检查驱动器将新数据(未缓存)写入驱动器的能力。这使您能够看到具有持续文件 I/O 的实际驱动器性能。
dd if=/dev/zero of=/mnt/driveN/testfile bs=128k count=80000 oflag=direct conv=fdatasync > dd-write-drive1.txt
将
driveN
替换为您要测试的驱动器的路径。dd
用于复制和粘贴数据的命令。
if=/dev/zero
从
/dev/zero
读取,这是一个系统生成的无限 0 字节流,用于创建指定大小的文件of=/mnt/driveN/testfile
写入
/mnt/driveN/testfile
bs=128k
一次写入最多 128,000 字节
count=80000
写入最多 80000 个数据块
oflag=direct
使用直接 I/O 写入以避免数据从缓存中获取
conv=fdatasync
在完成之前实际写入输出文件数据
> dd-write-drive1.txt
将操作输出的内容写入当前工作目录中的
dd-write-drive1.txt
该操作按字节返回写入的文件数量、总写入大小、操作的总持续时间(以秒为单位)以及写入速度(以每秒字节数为单位)。
测试驱动器在读取操作期间的性能
dd if=/mnt/driveN/testfile of=/dev/null bs=128k iflag=direct > dd-read-drive1.txt
将
driveN
替换为您要测试的驱动器的路径。dd
用于复制和粘贴数据的命令
if=/mnt/driveN/testfile
从
/mnt/driveN/testfile
读取;替换为用于测试驱动器读取性能的文件路径of=/dev/null
写入
/dev/null
,这是一个虚拟文件,在操作完成后不会持久保存bs=128k
一次写入最多 128,000 字节
count=80000
写入最多 80000 个数据块
iflag=direct
使用直接 I/O 读取并避免数据从缓存中获取
> dd-read-drive1.txt
将操作输出的内容写入当前工作目录中的
dd-read-drive1.txt
使用足够大的文件来模拟您的部署的主要用例,以获得准确的读取测试结果。
以下指南可能在性能测试期间有所帮助
小文件:< 128KB
普通文件:128KB – 1GB
大文件:> 1GB
您可以使用
head
命令创建一个要使用的文件。以下命令示例创建一个名为testfile
的 10 GB 文件。head -c 10G </dev/urandom > testfile
该操作返回读取的文件数量、总读取大小(以字节为单位)、操作的总持续时间(以秒为单位)以及读取速度(以每秒字节数为单位)。
第三方诊断工具
IO 控制器测试
使用 IOzone 测试输入/输出控制器和所有驱动器组合。记录部署中每个服务器的性能指标。
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
|
每个文件的大小为 1G |
|
4m 4MB 块大小 |
|
0=写入/重写,1=读取/重新读取,2=随机读写 |
|
Direct-IO modern |
|
线程数 (\(numberOfDrives * 16\)) |
|
文件列表(以上命令使用每个驱动器 16 个文件进行测试) |