所有帖子

可扩展性神话

可扩展性神话

许多对象存储公司喜欢谈论可扩展性,同时讨论诸如EB和“ Infinite”之类的术语。不幸的是,许多用于描述可伸缩性的术语都做出了宏大而误导的承诺,无助于企业构建有效的存储平台。围绕最简单的用例(静态档案数据)提出的主张并不能转化为支持数据驱动型企业必须解决的全部用例。

实际上,将其放在冷存储中时,要达到EB甚至更高的可伸缩性并不难。但这不是现代企业想要的。他们需要安全性,可伸缩性和性能,因为他们需要能够与AI / ML工作负载和高级分析平台(如Splunk)进行大规模数据交互。他们希望存储被证明能够在不考虑数据量的情况下针对整个软件堆栈实现大规模性能,并希望在各种使用情况下(许多都是实时的)提供低延迟响应。

我们在数据中看到了它-来自The New Stack的民意调查就是一个很好的例子:


撇开市场营销的旋转(我在市场营销方面的免责声明),满足云对象存储需求的这种组合需要具备哪些属性?这是我们的看法:

  1. 系统规模-为了满足可扩展性要求,整个系统需要可扩展。正如我们之前所写的那样,一个不线性扩展的系统示例是其中Cassandra用作元数据数据库的系统这限制了您对数据的处理能力,因为在扩展规模方面,Cassandra在写入方面比在读取方面要好,而在进行大规模操作(如删除)时则表现不佳。整个系统需要优雅,无缝地扩展,并且对于从工件存储和快照到机器学习管道的各种工作负载都不会出现问题。

    应当指出,对于大规模的现代工作负载-每个人都在对象存储上构建。SAN / NAS被降级为越来越多的遗留应用程序。

  2. 绩效-可以跨多个维度评估绩效-原始绩效,直线绩效和大规模绩效。区别很简单-为您的对象存储运行基准测试和几TB的数据可能会产生一些不错的数字,但真正的测试是在各种访问模式和对象大小的多个PB上保持这种性能。之所以如此重要,是因为没有这种可扩展的性能-您只能对一部分数据进行实际操作。

    AI / ML中的用例不仅趋向于处理大量数据,而且还越来越关注所谓的“暗数据”,即具有机密但由于性能(太大)而被遗忘或存档的数据。成本。

    现代对象存储需要能够在整个规模范围内交付性能。选择一个可以做到的对象存储,可以确保组织可以解锁该数据中的所有值,而不是某些零碎组件。

    MinIO已通过基准测试建立了规模游戏性能领导者的声誉但是,并非所有基准都是平等创建的。许多供应商通过将加密和位保护设置为低保护级别或完全关闭来尝试对系统进行游戏。真是可耻的东西。我们邀请您使用Warp-我们的S3基准测试工具,它正在迅速成为标准。

  3. 安全-安全性是The New Stack调查中压倒性的#1答案,但这对任何人都不应该是新闻。存储数据包括对其进行保护。保护它免受损失。保护其免受未经授权的访问。就勒索软件而言,两者是并存的。未经授权的访问会导致丢失。在糟糕的连续性中,破坏是最严重的,因为一旦数据公开,问题就会加剧。  

    这就是为什么安全性也需要扩展的原因。这意味着安全性不会带来性能开销,从而使您无法一直运行它。可扩展的加密还应该在任何地方(飞行中(TLS证书)和静止时(KMS,加密))保护数据。安全性还包括访问管理(身份验证和授权)和对象锁定。如果要提供全面的保护,它们都必须扩展。综上所述,这些是大多数对象存储无法兑现的重要要求。因此,企业做出了妥协,并取得了可预见的结果。

  4. 运营规模-只需少数(甚至只有几个人就可以跨时区管理)管理大型基础架构的能力就是运营规模。

    有人称它为可维护性。我们也喜欢这个词。我们对总拥有成本不太感兴趣。原因是您无法“评估价值工程师”的可维护性。您可以让一个人负责多租户,peta规模的对象存储作为服务实例,也可以不这样做。如果上述需要六个人的团队来照顾安全性,网络,驱动器,CPU,弹性,SLA,停机时间,升级等,则该解决方案在我们的书中“无法保持”。该功能需要易于管理,透明和简单-且不牺牲控件或粒度。

    随着时间的推移,OPEX比CAPEX高出几个数量级。扩展能力是所选软件的功能。简单,功能强大的软件每次都会胜出,因为操作可伸缩性是软件问题,而不是人员问题。

  5. 定义软件-尽管设备供应商会积极争论这一点,但事实是,正确设计的软件定义解决方案可以更好地扩展。当我们说正确定义时,意味着它们可以在任何商品硬件,虚拟机或容器,流行的操作系统发行版上运行,而不仅仅是少数几个知名供应商提供的几个严格定义的框。是的,AWS控制其堆栈中的硬件,但是硬件方面有很大的不同。几乎所有的硬件兼容性列表(HCL)都已过时。当频繁发布软件而硬件也经常刷新时,几乎不可能保持此HCL的有效性。

    当您能够做到这一点时,硬件确实成为一种商品。该软件处理媒体,模型甚至品牌之间的异质性。去得到你最好的价格。充分利用季度末的井喷。使用SSD和HDD设计系统,并使用ILM在它们之间分层。将公共云用作冷存储。设计围绕数据的数据生命周期-而不是HW规范。

    Kubernetes是该软件定义规模的驱动力。软件不应该担心基础架构,无论是公共云还是裸机私有云。让Kubernetes抽象化基础架构并将对象存储作为软件容器推出。虽然我们之前已经说过,但需要再次提及-您不能将设备容器化。



总结
可伸缩性是一个多维问题。它没有得到应有的重视,因为很少有供应商希望在其特定的,狭窄定义的成功标准之外进行讨论。这对整个行业都是不利的,因为它忽略了真正重要的事情-安全性,性能和可维护性。我们邀请您考虑一个更全面的清单,希望它会给您当前的供应商带来更好的问题,并为以后的系统设计带来更好的效果。


上一篇 下一篇