以OpenStack为关注重点的开源对象存储初创企业SwiftStack公司已经率先引入了希捷的对象存储Kinetic磁盘驱动器--这类驱动器需要服务器驻留软件来管理其I/O操作。
OpenStack能否吸引力到Kinetic磁盘驱动器的关注与支持？
以OpenStack为关注重点的开源对象存储初创企业SwiftStack公司已经率先引入了希捷的对象存储Kinetic磁盘驱动器--这类驱动器需要服务器驻留软件来管理其I/O操作。
我们通过一封电子邮件与SwiftStack公司创始人、总裁兼首席产品官Joe Arnold取得了联系，并与之探讨了一系列议题。
根据Joe的说法，用户在使用Kinetic驱动器时，实际感受与使用普通磁盘驱动器几乎别无二致。下面来看他对此做出的解释：
记者 我想了解的是，SwiftStack用户是如何使用Kinetic磁盘驱动器（及其它直连键：值磁盘驱动器）的。
Joe Arnold 对于SwiftStack对象存储用户来讲，使用标准磁盘驱动器或者Kinetic驱动器在具体体验方面几乎没有区别。SwiftStack是第一家由希捷公司指定，有资格在Kinetic API于2013年10月正式发布之前利用其对向外扩展存储集群中的Kinetic驱动器进行管理的软件厂商。
我们刚刚参加了Linux基金会组织的Kinetic PlugFest会议。SwiftStack公司是少数几家使用由希捷、东芝以及西部数据所提供的Kinetic API的软件厂商。因此就目前而言，该设备的兼容性一切正常，并将在下个阶段提供完整的解决方案。为此，希捷与SwiftStack之间也在积极推进相关的商业发展机遇。
记者 SwiftStack是否会通过文件系统对原始（即非Kinetic）磁盘驱动器进行寻址或者访问？如果是这样，那么通过SwiftStack实现的Kinetic驱动器访问在速度方面是否高于标准磁盘驱动器访问？
Joe Arnold SwiftStack能够接纳原始块存储设备（即磁盘驱动器）并将其资源池创建为一套存储系统。各Kinetic驱动器分别能够响应多种来自Swift的API命令，在这方面的运作方式同SwiftStack节点与非Kinetic磁盘驱动器配合时完全一致。
记者如此说来，SwiftStack用户为什么要选择Kinetic驱动器而非标准磁盘驱动器呢？
Joe Arnold SwiftStack公司认为用户应当拥有自由选择权。这种选择空间包括服务器、驱动器甚至是具体的驱动器技术。事实上，我们对SwiftStack架构设计进行了构思，从而保证Kinetic与标准驱动器能够在同样的集群与命名空间当中正常使用。这一点非常重要，因为这意味着用户能够更为轻松地逐步实现这项新兴技术。
我之前曾经就Kinetic技术如何让新型存储拓扑结构成为现实这一议题发表过文章。着眼于短期范畴，其能够更轻松地将必要计算与网络资源加以结合，从而容纳存储工作负载。相较于运行在采用普通磁盘驱动器的标准服务器设备，Kinetic驱动器可以通过机柜中的嵌入式交换机直接与网络相对接--这意味着负责运行存储服务的服务器的自身体积能够得到进一步缩小。
记者 那么您是如何看待最新兴起的一种观点，即对象存储是一种功能特性而非产品？
Joe Arnold 如果先选取一套文件系统再为其匹配对象API，那么这套架构无疑属于本末倒置！
配合一套统一化命名空间的对象存储能够作为文件系统访问的基础，但文件系统则并非反过来扮演对象存储的前提性角色; 文件系统并不能无限度地扩展。这让我想起一句俗话--我们没办法把香肠再变回猪肉。
诚然，对象网关可以立足于一套文件系统之上以提供对象API。然而该API本身并不是重点。对象存储是一套架构，而非单纯的访问方法。这套架构能够在一套统一化命名空间之内实现高吞吐率向外扩展的高容量工作负载，同时对元数据加以利用。通过这种方式，由CIFS或者NFS实现的传统文件访问机制将成为统一命名空间内向外扩展存储体系的一种访问功能。
2015年当中，我们已经亲眼见证了大量备份相关的传统应用开始迎来重构，旨在支持对象API（例如Veritas NetBackup 7.7）以对接统一化命名空间之下的公有云存储以及可扩展型内部存储机制。与我们一样，其它对象存储供应商也在以功能方案的形式交付文件系统访问能力，但总体来讲整个行业并没能找到一种更加确切的分类名称来描述"对象存储"。
记者 那么Amazon S3与文件层级访问是否进一步推动了对象存储在开源道路上的发展？
Joe Arnold 应用程序工作负载确实推动了发展态势。如果没有这类需求作为依托，对象存储技术根本不会存在--应用程序将继续使用传统文件存储机制！文件层级访问面向的是过去与当下的应用程序，而对象API访问则面向当下与未来的应用程序。
OpenStack贡献者数量正在逐年增长
是的，在Amazon推出其S3存储服务之后，相关消费规模也开始快速增长。另外，也有众多应用程序完全以S3支持为前提进行构建。在SwiftStack起步之初，我们的一些"Web"客户希望将其作为S3的后备方案（具体包括eBay/PayPal以及Ancestry.com等等），但同时又希望实现其它对象存储解决方案所无法达成的、在标准硬件上实现内部存储资源按需扩展的效果。
现在我们正在着手其它行业对于消费易行性、按需规模扩展以及公有云规模资源供给等方面的需求。一部分应用程序无法将其全部数据迁移至公有云环境当中，具体包括媒体与娱乐、医疗卫生、生命科学、政府事务以及金融服务等等。在这些行业当中，文件系统访问一直扮演着重要角色。其中一部分新型工作负载已经开始使用对象存储机制，但其仍然需要同当初面向文件系统API所设计的现有应用进行互操作。
（顺带一提，SwiftStack对S3 API极为推崇。SwiftStack拥有非常完备的兼容性，且能够同Veritas NetBackup、CommVault Software以及Avere等应用程序通过S3 API实现对接。）
记者 与Caringo、Cleversafe（IBM）、Cloudian、EMC（Atmos与ECS）、HGST（Amplidata）、HDS、NetApp（StorageGRID）、Scality以及其它专有对象存储产品相比，开源对象存储方案恐怕仍然处于弱势地位。那么这种状况要如何得到扭转？
Joe Arnold 千万不要把发展过程同市场实现混为一谈。作为我们所参与的开源社区，Swift拥有庞大的规模、具备数百家活跃开发参与厂商且这一数量仍在不断增加。这意味着任何一款专有对象存储产品的开发团队规模都无法与之相匹敌（除非各专有厂商进行协作），因此从这个角度来看，任何一款专有产品都不能同开源对象存储方案相抗衡。
各供应商在OpenStack社区中的参与比例
为什么选择开源？因为各专有竞争厂商的方案"并不成熟"，而开源操作系统、中间件、应用框架以及数据库如今已经成为企业与Web基础设施当中的实际标准。事实上，开源模式已经非常完整，且能够从本质上将基础设施层转化为数据中心--而这一点是大多数专有基础设施平台技术所无法实现的。
分析人士也认为，AWS S3正是对象存储领域的实质性标准API，而OpenStack Swift API则是相关治理工作中的开放标准。以上提到的各款产品都舍弃了自己的专有API，转而使用开发人员及独立软件供应商所支持或者倾向于使用的API。其中很多甚至在产品当中添加了对Swift API的支持能力。从这个角度出发，整个市场态势已经发生了转变。
总结陈词
就目前来看，像SwiftStack这样的初创企业确实有机会率先采用新型磁盘驱动器技术方案，而且随着使用过程的不断推进，SwiftStack也将迎来令人鼓舞的发展高潮。
各以太网接入型磁盘驱动器供应商也将受到OpenStack相关发展成果的推动。而且在我们看来，企业用户将乐于将自己的数据保存在SwiftStack数据存储系统当中，包括软件、服务器、机柜乃至磁盘驱动器，并确保各组件拥有优于传统存储阵列系统的运行状态及成本水平。
也许像希捷与西部数据这样的巨头级磁盘驱动器与存储阵列厂商能够将上述目标转化为现实。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
