文档

部署架构

本页从生产的角度概述了 MinIO 部署架构。有关特定硬件或软件配置的信息,请参阅

分布式 MinIO 部署

生产 MinIO 部署至少包含 4 个 MinIO 主机,具有同质存储和计算资源。

MinIO 将这些资源聚合在一起作为一个 ,并以单个对象存储服务的身份呈现自己。

4 Node MinIO deployment with homogeneous storage and compute resources

此池中的每个 MinIO 主机都具有匹配的计算、存储和网络配置

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

存储控制器应以“Just a Bunch of Drives”(JBOD)配置呈现 XFS 格式的驱动器,不使用 RAID、池化或其他硬件/软件弹性层。MinIO 建议不要使用缓存,无论是在驱动器层还是控制器层。任何类型的缓存都可能导致 I/O 尖峰,因为缓存已满并清空,从而导致性能不可预测。

MinIO Server diagram of Direct-Attached Storage via SAS to a PCI-E Storage Controller

每个 SSD 通过 SAS 连接到以 HBA 模式运行的 PCI-E 连接存储控制器

MinIO 会自动将池中的驱动器分组到 擦除集 中。

擦除集是 MinIO 可用性和弹性 的基础组件。MinIO 以对称的方式跨池中的节点条带化擦除集,以保持擦除集驱动器的均匀分布。然后,MinIO 会根据部署 奇偶校验 将对象划分为数据和奇偶校验分片,并将它们分布到擦除集中。

有关 MinIO 冗余和修复的更完整讨论,请参阅 擦除编码对象修复

Diagram of object being sharded into eight data and eight parity blocks, distributed across sixteen drives

使用最大奇偶校验 EC:8 时,MinIO 将对象划分为 8 个数据块和 8 个奇偶校验块,并将它们分布到擦除集中的驱动器上。此池中的所有擦除集都具有相同的条带大小和分片分布。

MinIO 使用基于对象名称和路径的确定性哈希算法来为给定对象选择擦除集。

对于每个唯一的对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION,MinIO 始终为读/写操作选择相同的擦除集。MinIO 处理池和擦除集内的所有路由,使选择/读/写过程对应用程序完全透明。

Diagram of object retrieval from only data shards

MinIO 会在将对象返回给请求客户端之前,从数据或奇偶校验分片中透明地重建对象。

每个 MinIO 服务器都拥有分布式拓扑的完整视图,因此应用程序可以连接并针对部署中的任何节点执行操作。

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

应用程序通常不应管理这些连接,因为对部署拓扑的任何更改都需要应用程序更新。相反,生产环境应部署负载均衡器或类似的网络控制平面组件来管理与 MinIO 部署的连接。例如,您可以部署 NGINX 负载均衡器来执行“最少连接”或“循环轮询”负载均衡,以针对部署中的可用节点执行负载均衡。

Diagram of an eight node MinIO deployment behind a load balancer

负载均衡器将请求路由到部署中的任何节点。接收节点随后会处理任何节点间请求。

您可以通过 池扩展 来扩展 MinIO 部署的可用存储空间。

每个池由一组独立的节点组成,每个节点都有自己的擦除集。MinIO 必须查询每个池以确定要将其定向读取和写入操作的正确擦除集,这样每个额外的池都会增加每次调用时的节点间流量。包含正确擦除集的池将响应操作,对应用程序保持完全透明。

如果您通过池扩展修改了 MinIO 拓扑,可以通过修改负载均衡器以包含新池的节点来更新您的应用程序。应用程序可以继续使用负载均衡器地址用于 MinIO 部署,无需任何更新或修改。这确保了请求在所有池中的均匀分布,同时应用程序继续使用用于 MinIO 操作的单个负载均衡器 URL。

Diagram of a multi-pool minio deployment behind a load balancer

PUT 请求需要检查每个池以找到正确的擦除集。一旦确定,MinIO 将对对象进行分区,并将数据和奇偶校验分片分布到相应的集中。

客户端应用程序可以使用任何与 S3 兼容的 SDK 或库与 MinIO 部署进行交互。

MinIO 发布了自己的 SDK,专门用于与 S3 兼容的部署一起使用。

Diagram of multiple S3-compatible clients using SDKs to connect to MinIO

使用各种与 S3 兼容的 SDK 的客户端可以对同一个 MinIO 部署执行操作。

MinIO 严格实现了 S3 API,包括要求客户端使用 AWS Signature V4 或传统的 Signature V2 对所有操作进行签名。AWS 签名计算使用客户端提供的标头,因此负载均衡器、代理、安全程序或其他组件对这些标头的任何修改都会导致签名不匹配错误和请求失败。确保任何此类中间组件都支持从客户端到服务器的未经修改的标头的直通。

虽然 S3 API 对所有操作使用 HTTP 方法,如 GETPOST,但应用程序通常使用 SDK 进行 S3 操作。特别是,签名计算的复杂性通常使得通过 curl 或类似的 REST 客户端进行交互变得不切实际。MinIO 建议使用与 S3 兼容的 SDK 或库,这些库在操作过程中自动执行签名计算。

复制的 MinIO 部署

MinIO 站点复制 提供对同步不同的独立部署的支持。

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

Diagram of a multi-site deployment with three MinIO peer site

具有三个对等节点的 MinIO 多站点部署。对一个对等节点的写入操作会自动复制到配置中的所有其他对等节点。

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

对于地理位置分布的对等站点,站点之间的高延迟会导致明显的复制滞后。这可能会与接近或达到部署整体性能容量的工作负载相叠加,因为复制过程本身需要足够的可用 I/O 来同步对象。

Diagram of a multi-site deployment with latency between sites

在此对等配置中,站点 A 与其对等站点之间的延迟为 100 毫秒。对象完全同步到所有站点的最早时间至少为 110 毫秒。

部署支持站点到站点故障转移协议的全局负载均衡器或类似网络设备对于多站点部署的功能至关重要。

负载均衡器应该支持健康探测/检查设置,以检测一个站点的故障,并自动将应用程序重定向到任何剩余的健康对等节点。

Diagram of a site replication deployment with two sites

负载均衡器使用配置的逻辑(地理位置、延迟等)自动路由客户端请求。写入一个站点的數據會自動複製到另一個对等站点。

负载均衡器应满足与单站点部署相同的连接平衡和标头保留要求。MinIO 复制通过将对象排队以进行复制来处理瞬态故障。