不再需要重新平衡对象存储！

MinIO 不采用传统的重新平衡技术来管理数据或增加容量。就像我们所做的一切一样 - 我们仔细研究了这种“传统智慧”，并确定在需要提供性能、规模以及最重要的规模性能的对象存储特定实现的上下文中，重新平衡不会有效. 因此，我们通过添加服务器池和擦除集以不同的方式解决问题。这篇文章讨论了重新平衡的权衡，并描述了我们构建可快速高效增长且无需停机的可扩展系统的方法。

再平衡的双刃剑

传统的分布式对象存储系统通过将数据分散到集群中的节点来平衡数据。他们通过编写策略来实现这一点，以根据对象、使用和资源的特征优化容量和/或性能。集群在节点之间平衡对象，因为它们被写入以符合策略。考虑平衡的一种方式是它类似于条带化，不同的是条带化是跨磁盘阵列而平衡是跨集群中的节点。

有时，需要重新平衡。平衡发生在对象被写入集群时，重新平衡尽可能快地对尽可能多的对象进行操作，因此是一个更加痛苦的过程。当节点或媒体被添加或停止服务以及策略改变时，重新平衡变得必要。在对象可以重新平衡到它们之前，系统无法使用新资源。重新平衡是一系列资源密集型任务，随着数据从节点推送到节点，从磁盘推送到磁盘，这些任务会将集群 CPU、内存、网络和物理存储推到极限。

重新平衡大规模分布式存储系统可能是一场噩梦。没有什么比添加一个存储节点并无助地看着用户响应时间增加而系统对自己的资源重新平衡以包括新节点征税更糟糕的了。有些系统甚至足够聪明，可以非常缓慢地或在非工作时间重新平衡，以最大限度地减少任务对整体性能的影响，但谁有数周时间将新节点投入使用？

一种常用的替代方法是实施容量过剩的存储系统。由于节点在机架中数月或数年未使用，这会浪费预算和更宝贵的数据中心空间。遗憾的是，当需要额外存储时，服务器和物理存储设备可能不再是最快或最密集的可用设备。

重新平衡给部署、操作和管理带来了复杂性，随着数据量的增加而增加。重新平衡 PB 比 TB 要求更高，而且考虑到数据增长的必然性，无法处理数十 PB 或更多的对象存储系统注定会失败。重新平衡不仅会影响性能 - 在网络中的许多节点之间移动许多对象可能存在风险。设备和组件出现故障，这通常会导致数据丢失或损坏。    

自由扩展

MinIO 在设计对象存储时考虑了这些权衡，并确定我们需要一种更好的扩展方式。

让我们来看看 MinIO 的架构，尤其是基础擦除编码。擦除编码类似于 RAID（记得我之前提到过条带化），因为它将对象拆分为数据和奇偶校验块，并将它们分布在MinIO 服务器池中的驱动器和服务器（硬件和 Kubernetes 软件节点的情况下）之间。与 RAID 或复制等技术相比，擦除编码以更少的开销提供对象级修复，并使 MinIO 能够在运行中自动重建对象，尽管集群中的多个驱动器或节点/服务器进程丢失。

一组驱动器是一个擦除集，MinIO 使用 Reed-Solomon 算法根据擦除集的大小将对象拆分为数据和奇偶校验块，然后将它们均匀地分布在擦除中的所有驱动器上，使得每个驱动器在该集合包含的每个对象不超过一个块。

为了实现快速增长，MinIO 通过添加服务器池和擦除集来扩展。如果我们构建 MinIO 以允许您向现有服务器池添加驱动器甚至单个硬件节点，那么您将不得不忍受重新平衡。擦除代码算法将读取擦除集中的所有对象，重新计算所有对象，并将数据和奇偶校验块重新条带化/重新平衡到包括新驱动器或节点在内的整个集合上。通过这种 I/O 阻塞和资源密集型任务来中断生产只是为了添加一个驱动器是不值得的。  

我们将 MinIO 设计为云原生对象存储，这意味着它必须能够快速、高效且透明地扩展。您无法通过添加驱动器或节点来实现云规模的快速增长。我们都见过数据中心为了扩展而逐个或什至成排地滚动存储。尝试逐个驱动器或逐个节点地增长云驱动器是没有运营效率的。

MinIO 通过添加服务器池快速扩展，每个池都是独立的计算、网络和存储资源集。MinIO 经常部署在多租户环境中，因为它具有快速增长的能力。每个租户是一组独立增长的服务器池。添加硬件，运行 MinIO 服务器以创建和命名服务器进程，然后使用新服务器池的名称更新 MinIO。MinIO 将现有数据保留在其原始服务器池中，同时将新服务器池暴露给传入数据。无需重新平衡 - 这意味着没有停机时间和数据损坏的风险。  

每个服务器池都由自己的硬件组成，使您能够构建具有灵活性和敏捷性的对象存储，以满足业务和技术需求。底层存储硬件通常针对性能或容量进行优化。MinIO 建议集群最少有 4 个，并且在一个服务器池中最多允许 32 个服务器，从而提供一次显着的增长。

停止重新平衡并开始扩展

构建受其可以增长的大小或速度限制的对象存储是没有意义的。重新平衡不再是必要的罪恶——它已成为过去。快速将新的对象存储投入使用，甚至可以满足最需要存储的用户和应用程序。