Kinetic——希捷的新分布式对象存储平台

　　我们已经知道Kinetic具有很多好处，那么问题来了……我们怎么样能获得这样的好处？或者说，我们怎么样能用到Kinetic？由于Kinetic架构当中，Application需要通过LibKinetic才能访问Kinetic存储网络，因此，用户的Application必须针对LibKinetic进行改写。

　　改写Application，或者改写其中其底层的一部分就是Seagate最需要做，并且已经在做的工作，目前，Seagate已经完成了一些分布式存储系统的适配工作，一个明显的例子就是HDFS。HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）是Hadoop大数据处理系统中的重要组成部分：文件系统部分，它同时是一个分布式的文件系统，准确地说，是一个集中式的分布式文件系统：

HDFS：传统驱动器（左下） vs Kinetic驱动器（右下）

　　集中式的意思是HDFS当中具有一个叫做Namenode的中央节点来管理Metadata，其它的Datanode则负责存取实际的数据——在传统架构当中是这样。在Kinetic HDFS架构当中，Namenode仍继续存在，但一系列的Datanode被少量的Datanode Daemon代替，Client客户端在存取实际数据的时候，不再需要经过Datanode（如左下的传统架构），而是可以直接和Kinetic驱动器通信（如右下的Kinetic架构那样），从而获得扩展性和性能上的提升。

　　分布式存储系统当中，除了集中式之外，还有一种是去中心化，或者说是真正的分布式存储系统，一个典型的例子就是Ceph。根据James的介绍，（当时）对HDFS的支持集成已经完成，而对Ceph的支持集成也在进行当中。Ceph是笔者很看好的一种分布式存储系统，曾经，笔者以为Kinetic和Ceph采用了一样的去中心化结构，在Ceph当中，这个结构的核心是DHT（Distributed Hash Table，分布式哈希表），DHT可能了解的人并不多，但人们可能已经使用它已经比较久了：我们大都用过BitTorrent或者eMule，在较近代的版本当中存在的一个功能就是无Tracker下载，这就是一种DHT网络（Tracker是一个中心化的存储节点，无Tracker就是一种去中心化），BT和eMule使用的DHT算法略有不同，但原理是一样的，都是每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。

所有的DHT算法都差不多基于一个环形哈希空间

　　笔者曾经认为Kinetic当中包含了DHT算法，但James给出了否定的回答，问答比较长，感兴趣的读者可以翻看后面的专访记录。在Ceph中，DHT算法负责实现将用户的数据映射到具体的存储（OSD），而在Kinetic只负责通过Key/Value的接口提供存储功能，也就是说，它极为适合搭配Ceph进行使用。Ceph是笔者很看重的分布式存储系统，在2015版的数据中心的报告当中我们还会继续谈到它。

Kinetic和DFS（分布式文件系统）的通用搭配框架

　　就Kinetic原理可以知道，Kinetic最合适的场景就是云计算、大数据等需要大容量、高吞吐量的存储场合，除了HDFS和Ceph，Seagate也在进行其他Swift、BASHO Riak、Scality等分布式存储系统的适配工作，Seagate还组建了一个开放社区，用户也可以根据上面提供的文档和工具进行专有系统的适配工作。