硬件清单
规划生产环境、分布式 MinIO 部署的硬件配置时,请使用以下清单。
注意事项
为 MinIO 实现选择硬件时,请考虑以下因素
启动时需要存储的以 TiB 为单位的预期数据量
至少未来两年的预期数据大小增长
按平均对象大小计算的对象数量
数据的平均保留时间(年)
要部署的站点数量
预期的存储桶数量
生产硬件建议
以下清单遵循 MinIO 的 推荐配置,适用于生产环境部署。提供的指导旨在作为基线,不能取代 MinIO SUBNET 性能诊断、架构审查和直接工程支持。
与任何分布式系统一样,MinIO 也受益于为给定 服务器池 中的所有节点选择相同的配置。确保在池节点之间一致地选择硬件(CPU、内存、主板、存储适配器)和软件(操作系统、内核设置、系统服务)。
如果节点具有不同的硬件或软件配置,部署可能会出现不可预测的性能。从将陈旧数据存储在低成本硬件中获益的工作负载应改为部署专用的“温”或“冷”MinIO 部署,并 转换 数据到该层级。
MinIO 不提供托管服务或硬件销售
描述 |
最低 |
推荐 |
|
---|---|---|---|
专用的裸机或虚拟主机(“主机”)。 |
4 台专用主机 |
8 台及以上专用主机 |
|
每个 MinIO 服务器 4 个驱动器 |
每个 MinIO 服务器 8 个及以上驱动器 |
||
25GbE |
100GbE |
||
支持现代 SIMD 指令(AVX-512)的服务器级 CPU,例如 Intel® Xeon® 可扩展或更高版本。 |
每个主机 8 个 CPU/插槽或 vCPU |
每个主机 16 个及以上 CPU/插槽或 vCPU |
|
可用的内存,以满足或超过每个服务器的使用量,并留出合理的缓冲区。 |
每个主机 32GB 可用内存 |
每个主机 128GB 及以上可用内存 |
重要
以下领域对 MinIO 性能的影响最大,按重要性排序
网络基础设施 |
吞吐量不足或有限会限制性能 |
---|---|
存储控制器 |
旧固件、吞吐量有限或硬件故障会限制性能并影响可靠性 |
存储(驱动器) |
旧固件或速度慢/老化/故障的硬件会限制性能并影响可靠性 |
在关注其他硬件资源(例如与计算相关的约束)之前,优先确保每个领域的必要组件。
以上最低建议反映了 MinIO 在协助企业客户部署到各种 IT 基础设施并同时维护所需 SLA/SLO 方面的经验。虽然 MinIO 可以在低于最低推荐拓扑的配置下运行,但任何潜在的成本节约都存在可靠性、性能或整体功能下降的风险。
网络
MinIO 建议使用高速网络来支持所连接存储的最大吞吐量(聚合驱动器、存储控制器和 PCIe 总线)。下表提供了给定物理或虚拟网络接口支持的最大存储吞吐量的通用指南。此表假设所有网络基础设施组件(如路由器、交换机和物理布线)也支持网卡带宽。
网卡带宽 (Gbps) |
估计的聚合存储吞吐量 (GBps) |
10Gbps |
1.25GBps |
25Gbps |
3.125GBps |
50Gbps |
6.25GBps |
100Gbps |
12.5GBps |
网络对 MinIO 性能的影响最大,其中每个主机的低带宽会人为地限制存储的潜在性能。以下网络吞吐量约束示例假设旋转磁盘具有约 100MB/S 的持续 I/O
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 操作系统通常不会保留这些更改。您可以使用带有 @reboot
定时的 cron
作业在节点重新启动时运行上述脚本,并确保所有驱动器都禁用了错误重试。使用 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
的 10GB 文件。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=随机读/写 |
|
直接-IO 现代 |
|
线程数(\(numberOfDrives * 16\)) |
|
文件列表(上述命令每个驱动器测试 16 个文件) |