文档

可用性和弹性

本页面从生产的角度概述了 MinIO 的可用性和弹性设计以及功能。

注意

本页面内容旨在尽力而为地指导您了解 MinIO 的预期设计和可用性与弹性背后的理念。它不能替代 MinIO SUBNET 的功能,该功能允许在规划 MinIO 部署时与 MinIO 工程团队协调。

社区用户可以在 MinIO 社区 Slack 上寻求支持。社区支持仅为尽力而为,不包含任何响应时间 SLA。

分布式 MinIO 部署

MinIO 实施 擦除编码 作为在驱动器或节点级故障事件期间提供可用性和弹性的核心组件。

MinIO 将每个对象划分为数据和 奇偶校验 分片,并将这些分片分布到一个 擦除集 中。

Diagram of erasure coded object partitioned into twelve data shards and four parity shards

此小型单节点部署在一个擦除集中包含 16 个驱动器。假设默认 奇偶校验EC:4,MinIO 将对象划分为 4 (四个) 个奇偶校验分片和 12 (十二) 个数据分片。MinIO 将这些分片均匀地分布到擦除集中的每个驱动器上。

MinIO 使用确定性算法为给定对象选择擦除集。

对于每个唯一的对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION,MinIO 始终为读写操作选择相同的擦除集。这包括该同一对象的 所有版本

Diagram of erasure set selection based on object namespace

MinIO 使用完整的对象命名空间计算目标擦除集。

MinIO 需要 读写配额 才能对擦除集执行读写操作。

配额取决于部署配置的奇偶校验。读取配额始终等于配置的奇偶校验,这样 MinIO 就可以对任何尚未丢失比奇偶校验更多驱动器的擦除集执行读取操作。

Diagram of degraded erasure set, where two parity shards replace two data shards

此节点有两个失效驱动器。MinIO 使用奇偶校验分片自动替换丢失的数据分片,并将重构的对象提供给请求的客户端。

使用默认的奇偶校验 EC:4,部署可以容忍每个擦除集丢失 4 (四个) 个驱动器,并且仍然可以提供读取操作。

写入配额取决于配置的奇偶校验和擦除集的大小。

如果奇偶校验小于擦除集驱动器数量的一半,写入仲裁等于奇偶校验,其功能类似于读取仲裁。

MinIO 自动增加写入退化擦除集的对象的奇偶校验,以确保该对象可以满足与健康擦除集中的对象相同的服务级别协议 (SLA)。奇偶校验升级行为提供了额外的风险缓解层,但不能替代修复或更换损坏驱动器以使擦除集恢复到完全健康状态的长期解决方案。

Diagram of degraded erasure set, where two drives have failed

此节点有两个失效驱动器。MinIO 使用升级的 EC:6 奇偶校验写入对象,以确保该对象满足与其他对象相同的 SLA。

使用默认的 EC:4 奇偶校验,部署可以容忍每个擦除集中 4 个驱动器丢失,并且仍然可以提供写入操作。

如果奇偶校验等于擦除集驱动器数量的一半,写入仲裁等于奇偶校验 + 1(一个),以避免由于“脑裂”场景导致的数据不一致。

例如,如果擦除集中正好有一半的驱动器由于网络故障而被隔离,MinIO 将认为仲裁丢失,因为它无法为写入操作建立 N+1 组驱动器。

Diagram of erasure set where half the drives have failed

此节点的驱动器故障率为 50%。如果奇偶校验为 EC:8,此擦除集将无法满足写入仲裁,并且 MinIO 会拒绝对该集的写入操作。由于擦除集仍然保持读取仲裁,因此对现有对象的读取操作仍然可以成功。

一个永久丢失的驱动器数量超过配置的奇偶校验的擦除集已遭受数据丢失。

对于最大奇偶校验配置,如果驱动器丢失等于奇偶校验,则擦除集将进入“只读”模式。对于 16 的最大擦除集大小和 8 的最大奇偶校验,这将需要丢失 9 个驱动器才能发生数据丢失。

Diagram of completely degraded erasure set

此擦除集丢失的驱动器数量超过了配置的 EC:4 奇偶校验,因此已丢失读取和写入仲裁。MinIO 无法恢复存储在此擦除集上的任何数据。

瞬态或临时驱动器故障(例如由于存储控制器或连接硬件故障)可能会在擦除集中恢复到正常运行状态。

MinIO 通过在池中的每个节点上对称地“条带化”擦除集驱动器来进一步降低擦除集故障的风险。

MinIO 会根据节点和驱动器的数量自动计算最佳擦除集大小,其中最大集大小为 16(十六)。然后,它从池中跨所有节点选择每个擦除集中的一个驱动器,如果擦除集条带大小大于节点数量,则循环选择。这种拓扑结构提供对单个节点甚至该节点上的存储控制器丢失的弹性。

Diagram of a sixteen node by eight drive per node cluster, consisting of eight sixteen drive erasure sets striped evenly across each node.

在此 16 x 8 部署中,MinIO 将计算 8 个擦除集,每个擦除集包含 16 个驱动器。它将在可用的节点上分配每个节点的一个驱动器来填充每个擦除集。如果有 8 个节点,MinIO 需要为每个擦除集选择每个节点的 2 个驱动器。

在上述拓扑结构中,池有 8 个擦除集,每个擦除集包含 16 个驱动器,跨 16 个节点条带化。每个节点将为每个擦除集分配一个驱动器。虽然丢失一个节点在技术上会导致 8 个驱动器丢失,但每个擦除集只会丢失一个驱动器。这使得即使在节点停机的情况下也能保持仲裁。

每个擦除集独立于同一池中的所有其他擦除集。

如果一个擦除集完全退化,MinIO 仍然可以在其他擦除集上执行读/写操作。

Diagram of a MinIO multi-pool deployment with one failed erasure set in a pool

一个池有一个退化的擦除集。虽然 MinIO 无法再对该擦除集提供读/写操作,但它可以继续对该池中的健康擦除集提供操作。

但是,丢失的数据仍然会影响依赖于 100% 数据可用性假设的工作负载。此外,每个擦除集完全独立于其他擦除集,因此您无法使用其他擦除集将数据恢复到完全退化的擦除集。您必须使用站点复制来创建支持灾难恢复 (BC/DR) 的远程部署以恢复丢失的数据。

对于多池 MinIO 部署,每个池都需要至少一个保持读/写仲裁的擦除集才能继续执行操作。

如果一个池丢失了所有擦除集,MinIO 将无法确定给定的读/写操作是否已路由到该池。因此,MinIO 会停止对部署的所有 I/O,即使其他池仍然处于运行状态。

Diagram of a MinIO multi-pool deployment with one failed pool.

此部署中的一个池已完全失败。MinIO 无法再确定将 I/O 路由到哪个池或擦除集。继续操作可能会导致对象及其版本位于不同擦除集中的不一致状态。因此,MinIO 会在池恢复之前停止部署中的所有 I/O。

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

使用复制的远程服务器将丢失的数据恢复到部署。存储在健康池中的所有数据都将安全地保留在磁盘上。

对驱动器的独占访问

MinIO **需要** 对为对象存储提供的驱动器或卷进行 *独占* 访问。任何其他进程、软件、脚本或人员都不应对提供给 MinIO 的驱动器或卷或 MinIO 放置在其中的对象或文件执行任何操作。

除非 MinIO 工程师指示,否则不要使用脚本或工具直接修改、删除或移动提供的驱动器上的任何数据分片、奇偶校验分片或元数据文件,包括从一个驱动器或节点移动到另一个驱动器或节点。此类操作很可能导致广泛的损坏和数据丢失,超出了 MinIO 的修复能力。

复制的 MinIO 部署

MinIO 将站点复制作为在 MinIO 部署中出现大规模或小规模数据丢失的情况下确保业务连续性和灾难恢复 (BC/DR) 的主要措施。
Diagram of a multi-site deployment during initial setup

每个对等站点都部署到独立的数据中心,以提供对大规模故障或灾难的保护。如果一个数据中心完全脱机,客户端可以故障转移到另一个站点。

MinIO 复制可以自动修复由于瞬态或持续停机而导致部分或全部数据丢失的站点。
Diagram of a multi-site deployment while healing

数据中心 2 已关闭,站点 B 需要重新同步。负载均衡器负责将操作路由到数据中心 1 中的站点 A。站点 A 不断将数据复制到站点 B。

一旦所有数据同步,您就可以将该站点的正常连接恢复。根据复制延迟、站点之间的延迟和整体工作负载 I/O,您可能需要暂时停止写入操作以允许站点完全赶上。

如果对等站点完全失败,您可以从配置中完全删除该站点。负载均衡器配置也应删除该站点,以避免将客户端请求路由到脱机站点。

然后,您可以通过将其添加回站点复制配置来恢复对等站点,无论是在修复原始硬件后还是完全更换硬件后。MinIO 会自动开始重新同步现有数据,同时不断复制新数据。

站点可以通过将 GET/HEAD 请求代理到健康的对等站点来继续处理操作。
Diagram of a multi-site deployment while healing

站点 B 没有请求的对象,可能是由于复制延迟。它将 GET 请求代理到站点 A。站点 A 返回对象,然后站点 B 将对象返回给请求的客户端。

客户端接收来自第一个返回 *任何* 版本的请求对象的对等站点的结果。

PUTDELETE 操作使用常规复制过程同步。 LIST 操作不代理,要求客户端专门针对健康的对等方发出它们。