可用性与弹性
本页从生产角度概述了MinIO的高可用性和弹性设计及特性。
Note
本页内容旨在作为理解 MinIO 在可用性和弹性方面的设计理念和哲学的最佳实践指南。 它不能替代的功能MinIO SUBNET，这允许您在规划 MinIO 部署时与 MinIO 工程团队进行协调。
社区用户可以在以下平台寻求支持：MinIO Community Slack社区支持仅为尽力而为，不保证响应时间的服务等级协议。
分布式 MinIO 部署
- MinIO 实现了纠删码作为在驱动器或节点级别故障事件期间提供可用性和弹性的核心组件。
MinIO 将每个对象划分为数据和奇偶性分片并将这些分片分布在单个擦除集.
这个小型单节点部署在一个擦除集中有16个驱动器。 假设默认奇偶性 of
EC:4MinIO 将对象划分为 4 个（四个）奇偶校验分片和 12 个（十二个）数据分片。 MinIO 将这些分片均匀分布在纠删码集中的每个驱动器上。- MinIO 使用确定性算法来选择给定对象的纠删码集。
对于每个唯一的对象命名空间
BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSIONMinIO 始终为读写操作选择相同的纠删码集。 这包括所有版本同一对象的。
- MinIO 需要读写仲裁对擦除集执行读写操作。
仲裁数量取决于部署中配置的奇偶校验盘数量。 读取仲裁数始终等于配置的奇偶校验数，这样MinIO可以对任何丢失驱动器数量未超过奇偶校验数的纠删码集执行读取操作。
使用默认的奇偶校验位
EC:4该部署可以容忍每个擦除集丢失4（四）个驱动器，并且仍然能够提供读取操作。- 写入仲裁取决于配置的奇偶校验和擦除集的大小。
如果奇偶校验数量少于擦除集驱动器数量的一半，写入仲裁数等于奇偶校验数，其功能与读取仲裁数类似。
MinIO 会自动增加写入降级纠删码集合的对象的奇偶校验级别，以确保对象能够满足相同的SLA作为健康擦除集中的对象。 奇偶校验升级行为提供了额外的风险缓解层，但无法替代修复或更换受损驱动器以使擦除集恢复完全健康状态的长期解决方案。
这个节点有两个故障驱动器。 MinIO 以升级的奇偶校验级别写入对象
EC:6为确保此对象与其他对象满足相同的服务等级协议。使用默认的奇偶校验位
EC:4该部署可以容忍每个擦除集最多4个驱动器的故障，同时仍能正常处理写入操作。- 如果奇偶校验等于擦除集驱动器数量的 1/2（一半），则写入仲裁数应等于奇偶校验数 + 1（一），以避免因"脑裂"场景导致的数据不一致。
例如，如果纠删集中的驱动器恰好有一半因网络故障而被隔离，MinIO将认为仲裁丢失，因为它无法为写入操作建立N+1组驱动器。
此节点有50%的驱动器故障。 如果奇偶校验是
EC:8该擦除集无法满足写入仲裁要求，因此MinIO会拒绝对该集合的写入操作。 由于该擦除集仍保持读取仲裁，对现有对象的读取操作仍可成功执行。- 一个擦除集永久丢失的驱动器数量超过配置的奇偶校验数量时，即发生数据丢失。
对于最大奇偶校验配置，如果驱动器丢失数量等于奇偶校验数量，擦除集将进入"只读"模式。 对于最大擦除集大小为16且最大奇偶校验为8的情况，需要丢失9个驱动器才会发生数据丢失。
此擦除集丢失的驱动器数量已超过配置的奇偶校验数
EC:4因此已经失去了读写仲裁。 MinIO 无法恢复此擦除集上存储的任何数据。瞬态或临时驱动器故障，例如由于存储控制器或连接硬件故障导致的故障，可能会在纠删码集合内恢复正常运行状态。
- MinIO通过将纠删集驱动器在存储池的每个节点间对称"条带化"，进一步降低了纠删集故障的风险。
MinIO 会根据节点和驱动器数量自动计算最优的纠删集大小，其中最大集大小为 16（十六）。 随后，它会为每个纠删集从存储池中每个节点选取一个驱动器，如果纠删集条带大小超过节点数量，则会循环选取。 这种拓扑结构能够提供对单个节点故障、甚至该节点上存储控制器故障的容错能力。
在这个16 x 8的部署中，MinIO将计算8个擦除集，每个擦除集包含16个驱动器。 它会在可用节点中为每个节点分配一个驱动器来填充每个擦除集。 如果有8个节点，MinIO需要为每个擦除集在每个节点上选择2个驱动器。
在上述拓扑结构中，池包含8个纠删组，每个纠删组由16个驱动器组成，这些驱动器条带化分布在16个节点上。 每个节点在每个纠删组中会分配一个驱动器。 虽然丢失一个节点在技术上会导致8个驱动器失效，但每个纠删组仅会损失一个驱动器。 这种设计确保了在节点停机期间仍能维持仲裁机制。
- 每个擦除集在同一个池中都是相互独立的。
如果一个擦除集完全降级，MinIO仍然可以在其他擦除集上执行读/写操作。
一个池中有一个降级的擦除集。 虽然 MinIO 无法再对该擦除集提供读/写操作，但它可以继续对该池中健康的擦除集提供服务操作。
然而，丢失的数据仍可能影响那些依赖100%数据可用性假设的工作负载。 此外，每个纠删码集完全独立于其他集合，这意味着您无法使用其他纠删码集将数据恢复到完全损坏的纠删码集中。 您必须使用网站 or 桶复制以创建业务连续性/灾难恢复- 准备就绪的远程部署，用于恢复丢失的数据。
- 对于多池 MinIO 部署，每个池需要至少一个保持读/写仲裁的纠删码集才能继续执行操作。
如果一个池丢失了所有擦除集，MinIO 将无法确定给定的读/写操作是否会路由到该池。 因此，MinIO 会停止对部署的所有 I/O 操作，即使其他池仍处于运行状态。
此部署中的一个池已完全故障。 MinIO 无法再确定应将 I/O 路由到哪个池或纠删码集。 继续操作可能导致不一致状态，即对象和/或其版本驻留在不同的纠删码集中。 因此 MinIO 已暂停所有I/O在部署中，直到池恢复。
要恢复对部署的访问，管理员必须将存储池恢复正常运行。 根据故障严重程度，可能需要格式化磁盘、更换硬件或更换节点。 参见硬件故障后恢复获取更完整的文档。
使用复制的远程存储将丢失的数据恢复到部署中。 存储在健康存储池上的所有数据在磁盘上仍然安全。
驱动器独占访问
MinIO需要 独家对象存储所提供的驱动器或卷的访问权限。 任何其他进程、软件、脚本或人员均不得执行任何直接对提供给 MinIO 的驱动器或卷，或 MinIO 置于其上的对象或文件执行操作。
除非得到 MinIO 工程团队指示，否则不得使用脚本或工具直接修改、删除或移动所提供驱动器上的任何数据分片、校验分片或元数据文件，包括在不同驱动器或节点间的转移操作。 此类操作极有可能导致大范围损坏和数据丢失，超出 MinIO 的自我修复能力范围。
Replicated MinIO Deployments
- MinIO 实现了站点复制作为确保MinIO部署在发生小规模和大规模数据丢失时业务连续性和灾难恢复（BC/DR）的主要措施。 （说明：原文为英文技术文档内容，已按照要求翻译为中文。保持技术术语"MinIO"、"BC/DR"不变，确保技术概念准确传达，同时符合中文技术文档表达习惯。）
每个对等站点都部署在独立的数据中心，以提供大规模故障或灾难的保护。 如果一个数据中心完全离线，客户端可以故障转移到其他站点。
- MinIO 复制可以自动治愈因暂时或持续停机而导致部分或全部数据丢失的网站。
数据中心2已宕机，站点B需要重新同步。 负载均衡器负责将路由操作指向数据中心1中的站点A。 站点A持续将数据复制到站点B。
一旦所有数据完成同步，您就可以恢复该站点的正常连接。 具体时间取决于复制延迟量、站点间延迟以及整体工作负载。I/O您可能需要暂时停止写入操作，以便让站点完全同步。
如果对等站点完全故障，您可以从配置中彻底移除该站点。 负载均衡器配置也应移除该站点，以避免将客户端请求路由到离线站点。
然后，您可以在修复原始硬件或完全更换硬件后恢复对等站点，将其添加回站点复制配置MinIO 会自动开始重新同步现有数据，同时持续复制新数据。
- 站点可以通过代理在重新同步期间继续处理操作
GET/HEAD对健康对等站点的请求 
站点B没有请求的对象，可能是由于复制延迟。 它代理了
GET向站点 A 发出请求。 站点 A 返回对象，随后站点 B 将该对象返回给请求客户端。客户端接收第一个返回结果的对等站点任何所请求对象的版本。
PUT和DELETE操作通过常规复制过程进行同步。LIST操作不会进行代理，要求客户端必须专门针对健康节点发出这些操作。
