放宽对MinIO的32节点限制

MinIO以前对每个群集强加了一个备受争议的32节点限制，我们在12月取消了该限制。对于32个节点的限制，没有严格的技术理由-您可以使用MinIO创建1,000个节点集群。我们施加限制的原因是为了推动良好的架构决策。但是，我们了解到，有人认为这是一个限制（实际上，一些竞争对手建议我们可以扩展到32个节点），所以我们取消了它。我们了解使用开放源代码软件的一部分是摆弄尽可能多的活动部件。许多用户想要尽可能多的灵活性，甚至想要执行我们不建议做的事情的灵活性。

尽管如此，从体系结构的角度来看，由32个节点组成的集群仍具有一些实质性的好处，我们希望通过这篇文章指出它们。现在是正确的时机，因为它不再存在，因此我们似乎没有为旧的限制辩护。

我们之所以受到限制，是为了鼓励良好的建筑设计。仅仅因为可以构建1,000个节点集群并不意味着它是一个好主意-特别是与Kubernetes配对时。MinIO通常由可能没有创建或管理存储体系结构经验的开发人员使用。我们以32个节点为限制的目标是创建保护栏，以使用户不会在不知不觉中创建不可能长期支持的存储集群。

为什么只有32个节点？

对于具有32个以上节点的集群，主要的挑战是可支持性。对于较大的故障域，进行维护活动将变得更加困难，从故障中恢复将变得更加困难，而成功备份数据的可能性将越来越大。此外，每个群集有32个节点，您可以存储很多数据。一个32节点的群集最多可以存储200 PB。如果用户需要200 PB以上的数据才能像在同一集群中那样工作，则创建多个集群并扩展您现有的部署很简单，每个集群都有适当数量的节点（同样，我们希望有32个）提供相同的节点。功能而不会违反最佳实践。

在单个群集上管理超过200 PB带来的复杂性开始令人生畏。当您的故障域非常大时，如果有几台服务器出现故障，则整个基础架构都可能发生故障。故障是支持的噩梦，更可能导致数据丢失。让我们清楚一点-故障是“何时”而不是“如果”的问题，尤其是在处理大量节点时。较小的节点配置使可管理性和根本原因分析更加容易。

单个大故障域的另一个问题是备份或移动数据所需的时间。数据并非凭空存在的-还需要考虑网络问题。故障域越大，如果将数据存储在非常大的块中，公司具有有效备份或移动数据的网络容量的可能性就越小。

Cloud Native Infrastructure的工作方式

无论是用于计算还是用于存储，云本机体系结构的基本前提是消耗小的离散块中的资源。扩展时，您将添加其他实例并将其尽可能密集地打包在基础结构中，而不是无限扩展一个实例。

即使在公共云中，基础架构也可以处理一些物理限制（存储桶数量，每小时API请求数量等）。忽略这些限制是造成数据丢失和/或停机的原因。

虽然关于32个节点没有什么神奇的，但我们发现它是平衡故障域和规模的良好代理。忽略该建议开始与运行容器化工作负载的基本前提相矛盾：应将应用程序（及其关联的存储）分解成尽可能小的组件。

MinIO的尺码建议

自从限制限制被删除以来，MinIO的大小建议没有改变。理想情况下，群集应至少具有4个节点以满足冗余要求，并且最多32个节点。如果需要额外的存储容量，最佳实践是在扩展时部署MinIO的新实例。即使每个群集只有32个节点，也可以将这些群集联合在一起，使它们可以作为一个巨型群集运行（并扩展到无穷大），同时仍保持体系结构的可管理性。

与庞大的集群相比，此架构在规模上进行管理较为简单，但仍具有无限扩展的潜力。

放宽32个节点的限制

我们的成长创造了数量惊人的配置和用例，这导致社区中的一些人要求放宽32节点限制以支持其特定部署。此外，它还分散了人们的注意力，常常使那些不了解故障域最佳实践的人分心。

开源软件的优点之一是人们可以自由地游玩并以艰难的方式学习它-因此，如果您强烈地认为运行1,000节点的存储集群适合您的生产应用程序，欢迎您尝试一下出来。刚开始时您可能不会遇到任何问题，但是当您尝试备份，移动数据或管理维护时-很好...我们确实告诉过您。

想开始使用MinIO进行实验吗？立即下载。