可扩展性神话

许多对象存储公司喜欢谈论可扩展性，同时抛出EB级和“无限”等术语。不幸的是，许多用于描述可扩展性的术语做出了宏伟且误导性的承诺，无助于企业构建有效的存储平台。围绕最简单用例（静态归档数据）做出的声明无法转化为必须解决的全部用例，以支持数据驱动的企业。

现实地说，当您将数据放入冷存储时，扩展到EB级甚至更高级别并不难。但这并不是现代企业想要的。他们需要安全、可扩展性和性能，因为他们需要能够大规模地与数据交互，以满足AI/ML工作负载和Splunk等高级分析平台的需求。他们希望存储经过验证，能够为整个软件堆栈提供大规模的性能，无论数据量如何，并在各种用例（许多是实时用例）中提供低延迟响应。

我们在数据中看到了这一点——来自The New Stack的这个调查就是一个很好的例子。

撇开营销炒作不谈（声明一下，我从事营销工作），满足云对象存储这些需求组合所需的属性是什么？这是我们的看法。

1. 系统规模 - 为了满足可扩展性要求，整个系统都需要具有可扩展性。正如我们之前在博客中所述，一个不线性扩展的系统示例是使用Cassandra作为元数据数据库的系统。这限制了您可以对数据执行的操作，因为在扩展方面，Cassandra更擅长写入而不是读取，并且在大规模操作（如删除）方面非常糟糕。整个系统需要优雅、无缝且无问题地扩展，以适应从工件存储和快照到机器学习管道的各种工作负载。
   
   需要指出的是，对于现代大规模工作负载，每个人都在构建对象存储。SAN/NAS 逐渐被限制在越来越多的遗留应用程序中。
   
   
2. 性能 - 可以从多个维度评估性能——原始的、直线的性能以及大规模的性能。区别很简单——对您的对象存储和几个TB的数据运行基准测试可能会产生一些不错的数字，但真正的考验是在多个PB的数据上，针对各种访问模式和对象大小维持这种性能。如此重要的原因在于，如果没有这种可扩展的性能，您实际上只能操作一部分数据。
   
   AI/ML 中的用例不仅倾向于海量数据，而且越来越多地关注所谓的“暗数据”，即包含秘密但通常因性能（太大）或成本原因而被遗忘或归档的数据。
   
   现代对象存储需要能够在整个扩展范围内提供性能。选择能够做到这一点的对象存储可以确保组织能够释放数据中蕴藏的所有价值——而不是某个部分。
   
   MinIO 通过其基准测试赢得了作为大规模性能领导者的声誉。然而，并非所有基准测试都是平等创建的。许多供应商试图通过将加密和数据完整性保护设置为低保护级别或完全关闭来操纵系统。这真是可耻。我们邀请您使用Warp——我们的S3基准测试工具，它正迅速成为标准。
   
   
3. 安全 - 在The New Stack调查的受访者中，安全是压倒性的第一大答案，但这对任何人来说都不应该是什么新闻。存储数据包括保护数据。防止数据丢失。防止未经授权的访问。在勒索软件的情况下，两者是相辅相成的。未经授权的访问会导致数据丢失。在各种不良事件中，泄露是最糟糕的，因为一旦数据暴露，问题就会加剧。
   
   这就是为什么安全也需要扩展。这意味着安全不能产生性能开销，导致您无法始终运行它。可扩展的加密还应该在任何地方保护数据——在传输中（TLS证书）和在存储中（KMS，加密）。安全还包括访问管理（身份验证和授权）和对象锁定。如果您想提供全面的保护，所有这些都需要扩展。总而言之，这些都是大多数对象存储无法满足的巨大需求。因此，企业做出了妥协，并获得了可预见的结果。
   
   
4. 运营规模 - 能够仅用少数人（甚至只有一两个人跨时区管理）管理庞大的基础设施就是运营规模。
   
   有些人称之为可维护性。我们也喜欢这个词。我们不太热衷于总拥有成本。原因在于，您无法“价值工程”可维护性。您可以让一个人负责一个多租户、PB级、对象存储即服务实例，也可以不这样做。如果上述操作需要一个由六人组成的团队来负责安全、网络、驱动器、CPU、弹性、SLA、停机时间、升级等，那么在我们看来，该解决方案“不可维护”。该功能需要易于管理、透明且简单，而不会牺牲控制或粒度。
   
   从长远来看，运营支出比资本支出高出几个数量级。扩展能力是所选软件的功能。简单、强大的软件每次都能获胜，因为运营可扩展性是软件问题，而不是人员问题。
   
   
5. 软件定义 - 虽然设备供应商会坚决争辩这一点，但事实是，设计良好的软件定义解决方案扩展性更好。当我们说正确定义时，意味着它们可以在任何商品硬件、虚拟机或容器、流行的操作系统发行版上运行，而不仅仅是少数几个大牌供应商提供的几个严格定义的盒子。是的，AWS 控制其堆栈中的硬件，但硬件方面存在巨大的差异。几乎所有硬件兼容性列表 (HCL) 从一开始就已过时。当软件频繁发布，硬件也经常刷新时，几乎不可能保持此 HCL 的有效性。
   
   当您可以做到这一点时，硬件确实成为商品。软件处理媒体、型号甚至品牌之间的异构性。获取最优惠的价格。利用季度末的促销活动。使用 SSD 和 HDD 设计您的系统，并使用 ILM 在它们之间进行分层。将公共云用作冷存储。围绕数据而不是硬件规格设计数据生命周期。
   
   Kubernetes 是软件定义规模的驱动因素。软件不应该关心底层基础设施，无论是公共云还是裸机私有云。让 Kubernetes 抽象出基础设施，并将您的对象存储作为软件容器推出。虽然我们之前已经说过，但值得再次提及——您无法将设备容器化。
   
   
   
   

总结
可扩展性是一个多维问题。它没有得到应有的关注，因为很少有供应商愿意在其特定且狭义定义的成功标准之外讨论它。这对整个行业来说是不利的，因为它忽略了真正重要的事情——安全、性能和可维护性。我们邀请您考虑更全面的清单，希望这将有助于您向当前供应商提出更好的问题，并改进未来的系统设计。