核心运维概念

• 1: 部署架构
• 2: 可用性与韧性
• 3: 纠删码
• 4: 对象自愈
• 5: 对象扫描器
• 6: 阈值与限制

minio server https://minio{1...4}.example.net/mnt/disk{1...4}

             |                    服务器池                |

minio server https://minio{1...4}.example.net/mnt/disk{1...4} \
             https://minio{5...8}.example.net/mnt/disk{1...4}

             |                    服务器池                |

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{5...8}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}
https://minio-{13...16}.example.net/mnt/drive-{1...4}

1 - 部署架构

本页从生产视角概述 MinIO 的部署架构。 有关具体硬件或软件配置的信息，请参阅：

• 硬件检查清单
• 安全检查清单
• 软件检查清单
• 阈值与限制

分布式 MinIO 部署

生产级 MinIO 部署至少由 4 台具有同构存储和计算资源的 MinIO 主机构成。

MinIO 会将这些资源聚合为一个 pool，并以单一对象存储服务的形式对外提供。

使用本地直连存储时，MinIO 可提供最佳性能，例如连接到主机 PCI-E 控制器板上的 NVMe 或 SSD 驱动器。

存储控制器应以 XFS 格式化驱动器并采用 “Just a Bunch of Drives” (JBOD) 配置呈现，不使用 RAID、池化或其他硬件/软件韧性层。 MinIO 不建议使用缓存，无论是在驱动器层还是控制器层。 任意一种缓存都会在填充和清空时导致 I/O 尖峰，从而带来不可预测的性能。

MinIO 会自动将 服务器池中的驱动器分组为 纠删码集合。

纠删码集合是 MinIO 可用性与韧性 的基础组件。 MinIO 会在 服务器池的各节点间对纠删码集合进行对称条带化，以保持纠删码集合驱动器分布均匀。 随后，MinIO 会根据部署的 校验 将对象拆分为数据分片和校验分片，并将其分布到纠删码集合中。

如需更完整地了解 MinIO 的冗余和自愈机制，请参阅 纠删码 和 对象自愈。

MinIO 使用基于对象名称和路径的确定性哈希算法，为给定对象选择纠删码集合。

对于每个唯一对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION，MinIO 在读写操作中始终会选择相同的纠删码集合。 MinIO 会处理 服务器池和纠删码集合内部的所有路由，使选择、读取和写入过程对应用完全透明。

每个 MinIO server 都完整掌握分布式拓扑，因此应用可以连接到部署中的任意节点并对其发起操作。

响应请求的 MinIO 节点会自动处理对部署中其他节点的内部路由，并将最终响应返回给客户端。

应用通常不应自行管理这些连接，因为部署拓扑的任何变化都可能要求应用随之更新。 生产环境应部署负载均衡器或类似网络控制平面组件，以管理到 MinIO 部署的连接。 例如，你可以部署 NGINX 负载均衡器，对部署中的可用节点执行 “least connections” 或 “round robin” 负载均衡。

你可以通过 pool 扩容 增加 MinIO 部署的可用存储。

每个 服务器池都是由自身纠删码集合组成的独立节点组。 MinIO 必须查询每个 服务器池，才能确定读写操作应定向到哪个纠删码集合，因此每增加一个 服务器池，每次调用的节点间流量都会相应增加。 包含目标纠删码集合的 服务器池随后会响应该操作，而这一过程对应用完全透明。

如果你通过 服务器池扩容修改了 MinIO 拓扑，可以通过更新负载均衡器，将新 服务器池的节点纳入应用流量。 应用仍可继续使用该 MinIO 部署的负载均衡器地址，而无需更新或修改。 这样既能保证请求在所有 服务器池之间均匀分布，又能让应用继续使用单一负载均衡器 URL 访问 MinIO。

客户端应用可以使用任意兼容 S3 的 SDK 或库与 MinIO 部署交互。

MinIO 也发布了专门面向兼容 S3 部署使用的 SDK。

MinIO 严格实现 S3 API，包括要求客户端对所有操作使用 AWS Signature V4 或 legacy Signature V2 进行签名。 AWS 签名计算依赖客户端提供的 header，因此负载均衡器、代理、安全程序或其他组件若修改这些 header，就会导致签名不匹配错误并使请求失败。 请确保任何此类中间组件都支持将 header 从客户端到服务器原样透传。

虽然 S3 API 的所有操作都使用 GET 和 POST 等 HTTP 方法，应用通常仍会使用 SDK 来执行 S3 操作。 特别是签名计算的复杂性，通常使通过 curl 或类似 REST 客户端直接交互变得不切实际。 MinIO 建议使用能够自动完成签名计算的兼容 S3 SDK 或库。

复制型 MinIO 部署

MinIO 站点复制 支持在彼此独立的部署之间进行同步。

你可以将对等站点部署在不同机架、数据中心或地理区域，以支持 BC/DR，或为全球分布式 MinIO 对象存储提供地理就近的读写性能。

复制性能主要取决于各对等站点之间的网络延迟。

当对等站点跨地理区域分布时，站点间的高延迟可能导致显著复制滞后。 如果工作负载已经接近或达到部署的总体性能上限，这一问题会进一步放大，因为复制过程本身也需要足够的空闲 I/O 来同步对象。

部署支持站点间故障切换协议的全局负载均衡器或类似网络设备，是多站点部署正常工作的关键。

负载均衡器应支持 health probe/check 设置，以检测某个站点故障，并自动将应用重定向到其他健康对等站点。

在连接均衡和 header 保留方面，负载均衡器应满足与单站点部署相同的要求。 MinIO 复制会通过排队对象来处理瞬时故障。

2 - 可用性与韧性

本页从生产视角概述 MinIO 在可用性与韧性方面的设计和特性。

分布式 MinIO 部署

MinIO 将 纠删码 作为在驱动器级或节点级故障期间提供可用性与韧性的核心组件。

MinIO 会将每个对象拆分为数据分片和 校验 分片，并将这些分片分布到单个 纠删码集合 中。

MinIO 使用确定性算法为给定对象选择纠删码集合。

对于每个唯一对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION，MinIO 在读写操作中始终会选择相同的纠删码集合。 这也包括同一对象的所有 版本。

MinIO 需要满足 读写仲裁 才能对纠删码集合执行读写操作。

仲裁取决于部署配置的校验值。 读仲裁始终等于配置的校验值，因此只要某个纠删码集合丢失的驱动器数不超过校验值，MinIO 就可以对其执行读操作。

当默认校验值为 EC:4 时，部署中的每个纠删码集合最多可容忍 4 块驱动器丢失，同时仍能继续提供读操作。

写仲裁取决于配置的校验值和纠删码集合大小。

如果校验值小于纠删码集合驱动器数量的 1/2，则写仲裁等于校验值，其行为与读仲裁相似。

MinIO 会自动提高写入降级纠删码集合的对象校验值，以确保该对象能够满足与健康纠删码集合中对象相同的 SLA。 这种校验升级行为提供了额外的风险缓解层，但无法替代修复或更换损坏驱动器这一长期解决方案，后者才是让纠删码集合恢复到完全健康状态的根本方法。

当默认校验值为 EC:4 时，部署中的每个纠删码集合最多可容忍 4 块驱动器丢失，同时仍能继续提供写操作。

如果校验值等于纠删码集合驱动器数量的 1/2，则写仲裁等于校验值加 1，以避免因 “split brain” 场景导致数据不一致。

例如，如果纠删码集合中恰好一半驱动器因网络故障而被隔离，MinIO 会认为仲裁丢失，因为它无法为写操作建立一个 N+1 驱动器组。

纠删码集合如果永久丢失的驱动器数量超过配置校验值，就意味着已经发生数据丢失。

对于最高校验配置，如果驱动器丢失数量等于校验值，纠删码集合就会进入 read only 模式。 对于最大纠删码集合大小 16 和最大校验值 8 的情况，需要丢失 9 块驱动器才会发生数据丢失。

某些瞬时或临时驱动器故障，例如由存储控制器或连接硬件故障引起的情况，仍可能在该纠删码集合内恢复到正常运行状态。

MinIO 还会通过在 pool 的每个节点间对纠删码集合驱动器进行对称条带化，进一步降低纠删码集合故障风险。

MinIO 会根据节点数和驱动器数自动计算最佳纠删码集合大小，其中最大集合大小为 16。 随后，它会跨 pool 为每个纠删码集合从每个节点选择一块驱动器；如果纠删码集合条带大小大于节点数，则会循环选择。 这种拓扑可对单节点故障，甚至该节点上的单个存储控制器故障提供韧性。

在上述拓扑中，该 pool 具有 8 个跨 16 个节点条带化的 16 驱动器纠删码集合。 每个节点都会为每个纠删码集合分配 1 块驱动器。 虽然丢失一个节点在技术上意味着丢失 8 块驱动器，但每个纠删码集合实际上只会各丢失 1 块驱动器。 这使得即使节点停机，系统仍能保持仲裁。

同一 pool 中的每个纠删码集合彼此独立。

即使一个纠删码集合完全降级，MinIO 仍可对其他纠删码集合执行读写操作。

不过，丢失的数据仍可能影响依赖 100% 数据可用性假设的工作负载。 此外，每个纠删码集合都与其他集合完全独立，因此你不能使用其他纠删码集合来恢复一个完全降级的纠删码集合中的数据。 你必须使用 站点 或 存储桶 复制，创建一个具备 BC/DR 能力的远端部署，用于恢复丢失的数据。

对于多 pool MinIO 部署，每个 pool 都至少需要有一个纠删码集合保持读写仲裁，才能继续提供操作能力。

如果某个 pool 丢失了全部纠删码集合，MinIO 就无法再判断某次读写操作原本是否应被路由到该 pool。 因此，即使其他 pool 仍然可用，MinIO 也会停止整个部署中的所有 I/O。

要恢复对该部署的访问，管理员必须将该 pool 恢复到正常运行状态。 这可能需要根据故障严重程度执行磁盘格式化、硬件更换或节点更换。 更完整的文档请参阅 硬件故障恢复。

你可以使用复制远端将丢失数据恢复回该部署。 存储在健康 pool 中的所有数据仍会安全保留在磁盘上。

复制型 MinIO 部署

对于 MinIO 部署中发生的小规模或大规模数据丢失，MinIO 将 站点复制 作为保证业务连续性和灾难恢复 (BC/DR) 的主要手段。

MinIO 复制可以在站点因瞬时或持续停机而发生部分或全部数据丢失时，自动 自愈 该站点。

一旦所有数据同步完成，你就可以恢复对该站点的正常连接。 根据复制滞后量、站点间延迟以及整体工作负载的 I/O 情况，你可能需要临时停止写操作，让各站点完全追平。

如果某个对等站点彻底故障，你可以将其从配置中完全移除。 负载均衡器配置也应移除该站点，以避免将客户端请求路由到离线站点。

然后，你可以在修复原始硬件或完全更换硬件后，通过 将其重新加入站点复制配置 来恢复该对等站点。 MinIO 会在持续复制新数据的同时，自动开始重同步已有数据。

站点在重同步期间仍可通过将 GET/HEAD 请求代理到健康对等站点来继续处理操作

客户端会收到首个返回所请求对象任意版本的对等站点结果。

PUT 和 DELETE 操作通过常规复制流程进行同步。 LIST 操作不会代理，客户端必须只对健康对等站点发起这类请求。

3 - 纠删码

• MinIO 纠删码概览

MinIO 将纠删码作为提供数据冗余和可用性的核心组件。 本页介绍 MinIO 的纠删码机制。

有关 MinIO 如何在生产部署中使用纠删码的更多信息，请参阅 可用性与韧性 和 部署架构。

纠删码基础

MinIO 会将每个 服务器池 中的驱动器分组为一个或多个相同大小的纠删码集合。

MinIO 会在初始化 服务器池 时确定纠删码集合的最佳数量和大小。 初次设置完成后，便无法再修改这些参数。

对于每次写操作，MinIO 都会将对象切分为数据和校验分片。

纠删码集合的条带大小决定了部署可用的最大 校验 值。 生成数据分片和校验分片数量的公式如下：

N (ERASURE SET SIZE) = K (DATA) + M (PARITY)

你可以将校验值设置在 0 到纠删码集合大小的 1/2 之间。

对象一旦按某个校验设置写入，即使之后修改校验值，也不会自动更新。

MinIO 至少需要 K 个任意类型的分片才能读取对象。

这里的 K 构成部署的读仲裁。 因此，纠删码集合中至少要有 K 块健康驱动器，才能支持读操作。

对于已经失去读仲裁的对象，MinIO 无法进行重建。 这类对象可能需要通过其他方式恢复，例如 复制重同步。

MinIO 至少需要 K 块纠删码集合驱动器才能写入对象。

这里的 K 构成部署的写仲裁。 因此，纠删码集合中至少要有 K 块可用驱动器在线，才能支持写操作。

当校验 EC:M 恰好等于纠删码集合大小的 1/2 时，写仲裁为 K+1。

这样可以防止 split-brain 场景，例如网络故障导致纠删码集合中的一半驱动器与另一半完全隔离。

K+1 逻辑可确保客户端不会把同一个对象分别写入纠删码集合的两个“半边”，从而避免潜在的不一致。

对于仍满足读仲裁的对象，MinIO 可以使用任意数据分片或校验分片来 自愈 受损分片。

你可以使用 MinIO 纠删码计算器，为计划中的拓扑探索可能的纠删码集合大小和分布方式。 如无特殊原因，建议使用偶数个节点和每节点偶数块驱动器，以简化拓扑规划以及驱动器和纠删码集合分布的理解。

纠删码校验与存储效率

为部署设置校验值，本质上是在可用性与总可用存储之间做平衡。 更高的校验值会提高对驱动器或节点故障的容忍度，但会减少可用存储；更低的校验值则提供更高的可用存储，但对驱动器或节点故障的容忍度也更低。 你可以使用 MinIO 纠删码计算器，查看不同校验值对计划中集群部署的影响。

下表列出了由 1 个节点和 16 块 1TB 驱动器组成的 MinIO 部署在不同纠删码校验级别下的结果：

位腐化防护

Bit rot 是一种静默数据损坏，由存储介质层面的随机变化引起。 对于数据驱动器而言，它通常来自表示数据的电荷衰减或磁取向变化。 成因可以从停电时的微小电流尖峰，到导致比特翻转的随机宇宙射线。 这种“bit rot”会在不触发监控工具或硬件告警的情况下，对数据介质造成细微错误或损坏。

MinIO 对 HighwayHash algorithm 的优化实现，确保其能够在运行时捕获并自愈受损对象。 它通过在 READ 时计算哈希并在 WRITE 时进行校验，确保从应用、网络到内存或驱动器的端到端完整性。 该实现专为速度设计，在 Intel CPU 上单核即可达到超过 10 GB/sec 的哈希速度。

4 - 对象自愈

什么是自愈？

自愈是 MinIO 恢复受损、损坏或部分丢失对象的能力。 这类丢失或损坏可能来自多种情况，包括但不限于：

• 驱动器级错误或故障
• 操作系统或文件系统错误或故障
• bit rot

自愈与纠删码

MinIO 恢复受损对象的能力，直接取决于以下因素：

• 对象所在 纠删码集合 的驱动器总数

• 保留对象完整分片的可用驱动器数量

• 该纠删码集合的 校验设置

  Parity 指 MinIO 在写入对象时创建的专用恢复分片数量。 例如，一个纠删码集合可能总共有 8 块驱动器，其中 3 块用于校验。 在这种情况下，MinIO 会把对象拆分为 5 个数据分片和 3 个校验分片。 MinIO 会将这 8 个分片分布到纠删码集合中的各块驱动器上。 不会有某一块驱动器只包含校验分片或只包含数据分片。 相反，MinIO 会以随机化方式写入每个对象的分片，以便将读取均匀分散到各块驱动器上。

  当 MinIO 需要返回该对象时，它会查找对象对应的数据分片。 如果某些数据分片丢失或损坏，MinIO 会使用一个或多个校验分片来恢复对象。 如果在查找校验分片时发现某些校验分片也丢失或损坏，只要仍有足够的其他分片可供返回对象，MinIO 也会一并恢复这些校验分片。 在上述场景中，即使最多有 3 个数据分片丢失或损坏，MinIO 仍然可以成功恢复并返回该对象。

  保留对象完整数据分片或校验分片的可用驱动器数量，必须大于或等于该纠删码集合中用于数据分片的驱动器数量。 在上述场景中，至少需要 5 块保留完整分片的驱动器在线且可用，MinIO 才能成功返回该对象。

MinIO 何时对对象执行自愈？

MinIO 提供了一套健壮的对象自愈机制。

在 GET 请求期间自愈

每当你通过 GET 或 HEAD 请求对象时，MinIO 都会自动检查该对象数据分片的一致性。 对于启用了版本控制的存储桶，MinIO 在 PUT 操作期间也会执行一致性检查。

如果所有数据分片都完好无损，MinIO 会直接从数据分片返回对象，而不会检查对应的校验分片。

如果对象存在丢失或损坏的数据分片，MinIO 会先使用可用的校验分片对对象执行自愈，然后再作为本次操作的一部分返回。 每个丢失或损坏的数据分片都 必须 有一个完好的校验分片可用，否则对象无法恢复。 如果某些校验分片丢失或损坏，只要仍有足够的其他校验分片可用于返回对象，MinIO 也会恢复这些校验分片。

通过对象扫描器自愈

MinIO 使用 对象扫描器 执行多项与对象相关的任务。 其中一项任务就是检查对象完整性，并在发现损坏或损毁时执行自愈。

在每一轮扫描中，MinIO 会根据对象名称的哈希值，从每 1,024 个对象中选择 1 个进行检查。

如果发现对象存在分片丢失，MinIO 会使用可用分片对对象执行自愈。 默认情况下，MinIO 不会 使用扫描器检查 bit rot 损坏。 这类操作的成本较高，而多个磁盘同时发生 bit rot 的概率较低。

通过手动请求自愈

管理员可以使用 mc admin heal 发起一次全系统自愈。 该过程会大量消耗资源，通常并非必需。

在部署上手动启动自愈流程之前，请先与 MinIO 工程师沟通。

自愈指标

MinIO 提供了若干自愈指标（英文），用于监控部署中的自愈过程状态。

有关可用 endpoint 和配置的更多信息，请参阅 指标与告警。

5 - 对象扫描器

概览

MinIO 使用内置扫描器检查对象是否需要自愈，并执行任何已计划的对象操作。 这类操作可能包括：

• 计算驱动器上的数据使用量
• 评估并应用已配置的 生命周期管理 或 对象保留 规则
• 执行 存储桶 或 站点 复制
• 检查对象是否存在丢失或损坏的数据分片或校验分片，并执行 自愈

扫描器在两个层级执行这些功能：集群层级和存储桶层级。 在集群层级，扫描器会将所有存储桶划分为多个组，并一次扫描其中一组。 扫描器会先处理自上次扫描以来新增的存储桶，然后再以随机顺序扫描其他存储桶。 在完成所有存储桶组的检查后，扫描器会重新开始新一轮扫描。

在存储桶层级，扫描器会对存储桶内条目分组，并从该存储桶中选择部分条目进行扫描。 扫描器会根据对象名称的哈希值来选择要扫描的对象。 在 16 轮扫描的周期内，MinIO 会检查命名空间中的每个对象。 对于自上次扫描以来确认新增的任何前缀，MinIO 会执行完整扫描。

扫描时长

影响一次扫描完成时间的因素有很多。

其中包括：

• 提供给 MinIO 的驱动器类型
• 可用吞吐量和 iops
• 对象数量和大小
• MinIO Server 上的其他活动

例如，默认情况下，MinIO 会暂停扫描器，以便将 I/O 资源让给读写请求。 这会拉长扫描完成所需的时间。

MinIO 在每次扫描之间的等待时间，会按本次扫描操作耗时乘以一个系数来计算。 默认情况下，该系数为 10.0，表示 MinIO 会在一次扫描完成后等待相当于该操作耗时 10 倍的时间，再开始下一次扫描。 这个系数会根据配置的 扫描器速度设置 发生变化。

扫描器性能

影响扫描器性能的因素有很多。 其中包括：

• 可用节点资源
• 集群规模
• 纠删码集合数量相对于驱动器数量的关系
• 存储桶层级结构的复杂度（对象和前缀）

例如，在相同硬件和工作负载条件下，一个从 100TB 数据增长到 200TB 数据的集群，扫描完整个存储桶和对象命名空间所需的时间会更长。 同样地，单个包含 16 块驱动器的纠删码集合，其扫描耗时会长于把相同数量驱动器拆分为两个 8 驱动器纠删码集合的情况。

MinIO 将扫描器视为后台任务，并会暂停它以优先完成集群中的读写请求。 随着集群规模或工作负载增长，为保证普通 S3 操作的优先级，扫描器会更频繁地让出资源，因此其性能会下降。

你可以使用 MINIO_SCANNER_SPEED 环境变量或 scanner speed 配置项， 调整 MinIO 在扫描器性能与读写操作之间的平衡方式。

扫描器指标

MinIO 提供了若干与扫描器相关的指标（英文）。

使用 mc admin scanner info 可以查看扫描器当前状态，以及距离上次完整扫描所经过的时间。 这有助于理解扫描器操作提供的各项指标。

扫描器指标（包括 usage 指标）反映的是最近一次完成的扫描结果。 自上次扫描以来发生的 PUT 或 DELETE 操作，不会在 usage 中体现，直到受影响的存储桶完成下一次扫描。

输出类似如下：

Overall Statistics
------------------
Last full scan time:   0d0h14m; Estimated 2885.28/month
Current cycle:         70464; Started: 2024-04-19 20:02:34.568479139 +0000 UTC
Active drives:         2

Last Minute Statistics
----------------------
Objects Scanned:       620 objects; Avg: 124.929µs; Rate: 892800/day
Versions Scanned:      620 versions; Avg: 2.801µs; Rate: 892800/day
Versions Heal Checked: 0 versions; Avg: 0ms
Read Metadata:         621 objects; Avg: 88.416µs, Size:
ILM checks:            656 versions; Avg: 663ns
Check Replication:     656 versions; Avg: 1.061µs
Verify Deleted:        0 folders; Avg: 0ms
Yield:                 3.086s total; Avg: 4.705ms/obj

6 - 阈值与限制

本页列出了适用于 MinIO 的阈值与限制。

有关相关建议和要求，请参阅 hardware 和 software。

S3 API 限制

纠删码限制

对象名称限制

文件系统和操作系统限制

MinIO 中的对象名称主要受本地操作系统和文件系统限制。 Windows 和某些其他操作系统会限制包含特定特殊字符的文件系统名称，例如 ^、*、|、\、/、&、" 或 ;。

此列表并不完整，也不一定适用于你的操作系统和文件系统组合。

在类 Unix 操作系统上，路径名为 .、.. 或 / 的对象会返回 file access denied 错误。

请查阅你的操作系统供应商或文件系统文档，以获得适用于当前环境的完整列表。

MinIO 建议生产工作负载使用基于 XFS 文件系统的 Linux 操作系统。

冲突对象

应用必须为所有对象分配不冲突的唯一键。 这包括避免创建与父对象或同级对象名称发生冲突的对象。 当名称发生冲突时，MinIO 在该位置的 LIST 操作会返回空结果集。

例如，以下操作会创建命名空间冲突：

PUT data/invoices/2024/january/vendors.csv
PUT data/invoices/2024/january <- collides with existing object prefix

PUT data/invoices/2024/january
PUT data/invoices/2024/january/vendors.csv <- collides with existing object

虽然你仍然可以对这些对象执行 GET 或 HEAD 操作，但名称冲突会导致在 /invoices/2024/january 路径上的 LIST 操作返回空结果集。