采用对象存储的“三要素”

虽然私有对象存储并不适合所有人,尤其当你没有使之可行的规模的时候。但另一方面,我们一直都在堆放大量数据,而用户则需要随时从很多不同的位置,应用和设备来访问它。

对于这类工作,对象存储的特性是建立一个横向平台的不二之选,有时它对于实现一个本地基础设施很有帮助,尽管处理能力更小,这种情况下,所谓的小是大约100TB。

如果你现在没有用对象存储,将来可能有机会。我们先回顾一些对象存储的好处,然后分享一些关于在何地以及如何开始考虑它的想法。

为什么是对象存储?

现在你可以在市场找到很多对象存储产品,一些开始时相对较小,而其他则只对处理多PB级容量有意义。不同的基础架构能积极推动管理更小或更大的对象或特殊工作负载。但如今随着Amazon S3 API争取到Swift,它们现在都在支持一组类似的API访问数据。

事实上,支持S3 API是终端用户通常寻求的第一特性,因为它大大简化了前端解决方案的搜索。一个对象存储基础设施被视为一个提供不同的服务的公共横向平台。有时候对象存储可以提供其中一些服务,比如向外扩展NAS,但主要服务都是通过外部设备或应用利用API实现的。

对象存储系统通常有一些基本特性如多租户,安全,地理分布,自动数据复制,基于策略的数据保护,极高的弹性和可靠性还有高可用性。就其性能而言不是首选,但可根据使用案例或具体实现而改变。基础设施都是建立在商品硬件之上,而架构设计通常包含分布式节点。

这些特性相结合大大降低了总拥有成本和总购置成本。这是另一个大众会对其感兴趣的理由。

何时何地使用对象数据?

适合对象存储的使用案例有很多,尤其当你的组织正在开发新的应用,你又有能力利用它的时候。但我们现在吧重心集中在基础设施和主要地现有解决方案上。其实,许多对象存储终端用户开始将对象存储用于传统协议或应用,未来还会有更多。

如果不采取类似策略,那么对象存储将只是一个小的独立存储孤岛,从长远来看,可能得不偿失。如果是这样,对象存储简直就不是解决方案而是一个麻烦了。

回到可能采用的方案:

1.NAS优于其它。这听起来有些不可思议但确实是终端用户想要的——传统NAS,分布式NAS和向外扩展型NAS,其中说得不只是容量。通过从前端(拥有高速闪存和效率的外部设备)去耦电容,能服务任何种类高性能工作负载而不考虑与传统NAS的连接问题。这包括备份,灾难恢复,容量管理等。

有一个生动例子——Avere System,它只用前端一堆设备就能够服务HPC工作负载,即使是远程部署而且在高延迟对象存储系统上。

2.同步&共享(S&S)是拥有后端对象存储的最常见应用之一,比如Dropbox和所有其他基于对象存储的公司。这个解决方案有很多好处,尤其对有许多远程办公和移动工作者的企业。在这种特殊情况下,无关于数据量,而是在提供用户最佳数据可流动性的同时更多的保持控制数据。

3.其他所有数据。在这个类别里你可以找到很多不同从动态归档到备份的应用,形式多样,事实上,主存储供应商支持S3 API克隆或做数据副本的越来越多,同样备份供应商现在也将支持对象存储作为目标。相同的类别,尽管应用完全不同,一些分析应用已经开始利用这些类别存储库来存储数据了。在最先进的开发中,他们也正在这些来进行就地数据分析。

对象存储是不是太晚了?

如果你看一看市场,很容易看到一些正在发生的事,很多新创业公司正在建立新一代存储系统,可以被视为传统对象存储的开发,尤其是企业组织,比如Hedvig。

上述文中讨论了很多特性,除了提供块,文件和对象接口,也在同样产品中整合与发展数据服务。有时候 ,对于Cohesity,这些数据服务都特别的先进并打算取代传统备份产品和类似嵌入式功能。

我们谈到拥有以上服务并准备使用的产品,没有你通常需要的传统对象存储产品的整合。有时当对象存储成为了一个大型生态系统的一部分——正如HDS或DDN,尽管它不是现在的一个普遍特征,但我们已经发生过这种情况。

收尾

一个服务许多(辅助)存储的横向平台所需要是什么。基于API对象存储是第一个构建块,但是现在似乎要整合成更复杂的产品。这就意味着它们的复杂度会降低,使用会更简单,推动了其在更小环境的采用,而不仅仅是游走于超大规模的环境。

其实新的方案并不适合许多“传统”对象存储初创公司,其中有一些是专业的,而他们的文件/块协议不及核心部件,因此数据服务是不存在的。

在过去的几年里我们已经看到了很多收购——比如HGST收购Amplidata——但对于其他人而言,找到一个退出策略难上加难。加之这些新的初创公司推出了许多先进的产品(如Nutanix的向外扩展型存储),会让对象存储供应商的日子不太好过。对于他们而言,唯一的方法就是建立更好的文件协议接口,同时创新数据服务。当然问题在于,他们能否在大势未去之时力挽狂澜?