可用性与韧性

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

Note

本页内容旨在尽力帮助你理解 MinIO 在可用性与韧性方面的预期设计和理念。它不能替代 MinIO SUBNET 的能力。使用 MinIO SUBNET 可以在规划 MinIO 部署时与 MinIO Engineering 协同。

社区用户可以通过 MinIO Community Slack 寻求支持。社区支持仅为 best-effort，不提供关于响应时间的 SLA。

分布式 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 在其上放置的对象或文件执行任何操作。

除非得到 MinIO Engineering 的明确指示，否则不要使用脚本或工具直接修改、删除或移动这些磁盘上的任何数据分片、校验分片或元数据文件，包括在磁盘或节点之间迁移这些文件。这类操作极有可能导致大范围损坏和数据丢失，超出 MinIO 的自愈能力。

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

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

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

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

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

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

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

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