文档

部署架构

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

分布式 MinIO 部署

生产 MinIO 部署至少包含 4 台具有同类存储和计算资源的 MinIO 主机。

MinIO 将这些资源汇总在一起,作为,并将其呈现为单个对象存储服务。

4 Node MinIO deployment with homogeneous storage and compute resources

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

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

存储控制器应以“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 部署,而无需任何更新或修改。这确保了请求在所有池中均匀分布,同时应用程序继续使用单个负载均衡器 URL 进行 MinIO 操作。

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 复制通过将要复制的对象排队来处理瞬态故障。