部署架构
此页面从生产角度概述了 MinIO 部署架构。有关特定硬件或软件配置的信息,请参见
分布式 MinIO 部署
- 生产 MinIO 部署至少包含 4 台具有同类存储和计算资源的 MinIO 主机。
MinIO 将这些资源聚合在一起作为池,并将其自身呈现为单个对象存储服务。
- 当使用本地附加存储(例如连接到主机上 PCI-E 控制器板的 NVMe 或 SSD 驱动器)时,MinIO 可提供最佳性能。
存储控制器应以“Just a Bunch of Drives”(JBOD)配置呈现 XFS 格式化的驱动器,不使用 RAID、池或其他硬件/软件弹性层。MinIO 建议不要使用缓存,无论是在驱动器层还是控制器层。任何类型的缓存都可能导致I/O 尖峰,因为缓存会填充和清除,从而导致性能不可预测。
- MinIO 会自动将池中的驱动器分组到擦除集中。
擦除集是 MinIO可用性和弹性的基础组件。MinIO 在池中的节点之间对称地跨越擦除集,以保持擦除集驱动器的均匀分布。然后,MinIO 根据部署的奇偶校验将对象划分为数据和奇偶校验分片,并将它们分布在擦除集中。
- MinIO 使用基于对象名称和路径的确定性哈希算法来选择给定对象的擦除集。
对于每个唯一的对象命名空间
BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION
,MinIO 始终为读/写操作选择相同的擦除集。MinIO 处理池和擦除集内的所有路由,使选择/读取/写入过程对应用程序完全透明。- 每个 MinIO 服务器都具有分布式拓扑的完整视图,因此应用程序可以连接并针对部署中的任何节点执行操作。
响应的 MinIO 节点会自动处理内部请求到部署中其他节点的路由以及将最终响应返回给客户端。
应用程序通常不应管理这些连接,因为部署拓扑的任何更改都需要应用程序更新。生产环境应改为部署负载均衡器或类似的网络控制平面组件来管理与 MinIO 部署的连接。例如,您可以部署 NGINX 负载均衡器来对部署中可用的节点执行“最少连接”或“轮询”负载均衡。
- 您可以通过池扩展扩展 MinIO 部署的可用存储。
每个池由一组独立的节点组成,这些节点具有自己的擦除集。MinIO 必须查询每个池以确定它将读写操作定向到的正确擦除集,这样每个额外的池都会增加每次调用的节点间流量。包含正确擦除集的池然后响应操作,对应用程序保持完全透明。
如果通过池扩展修改 MinIO 拓扑,则可以通过修改负载均衡器以包含新池的节点来更新应用程序。应用程序可以继续使用 MinIO 部署的负载均衡器地址,而无需任何更新或修改。这确保了请求在所有池中的均匀分布,同时应用程序继续使用 MinIO 操作的单个负载均衡器 URL。
- 客户端应用程序可以使用任何与 S3 兼容的 SDK 或库来与 MinIO 部署进行交互。
MinIO 发布了自己的SDK,专门用于与 S3 兼容的部署。
MinIO 严格实施 S3 API,包括要求客户端使用 AWS Signature V4 或旧版 Signature V2 对所有操作进行签名。AWS 签名计算使用客户端提供的标头,因此负载均衡器、代理、安全程序或其他组件对这些标头的任何修改都将导致签名不匹配错误和请求失败。确保任何此类中间组件都支持从客户端到服务器的未更改标头的直通。
虽然 S3 API 对所有操作都使用 HTTP 方法(如
GET
和POST
),但应用程序通常使用 SDK 进行 S3 操作。特别是,签名计算的复杂性通常使通过curl
或类似的 REST 客户端进行交互变得不切实际。MinIO 建议使用与 S3 兼容的 SDK 或库,这些库会自动执行签名计算作为操作的一部分。
复制的 MinIO 部署
- MinIO 站点复制 提供了支持不同独立部署同步的功能。
您可以在不同的机架、数据中心或地理区域部署对等站点,以支持诸如BC/DR 或全球分布式 MinIO 对象存储中的地理位置读/写性能等功能。
- 复制性能主要取决于每个对等站点之间的网络延迟。
对于地理位置分布的对等站点,站点之间的高延迟会导致明显的复制延迟。这可能会与接近或达到部署整体性能容量的工作负载相结合,因为复制过程本身需要足够的空闲I/O 来同步对象。
- 部署支持站点到站点故障转移协议的全局负载均衡器或类似的网络设备对于多站点部署的功能至关重要。
负载均衡器应支持运行状况探测/检查设置以检测一个站点的故障并自动将应用程序重定向到任何剩余的健康对等节点。
负载均衡器应满足与单站点部署相同的连接平衡和标头保留要求。MinIO 复制通过将对象排队以进行复制来处理瞬态故障。