SPDK简介

SPDK（Storage Performance Development Kit）是Intel发布的存储性能开发工具集。

 

简介

固态存储设备正在取代数据中心。目前这一代的闪存存储，比起传统的磁盘设备，在性能（performance）、功耗（power consumption）和机架密度（rack density）上具有显著的优势。这些优势将会继续增大，使闪存存储作为下一代设备进入市场。

用户使用现在的固态设备，比如Intel® SSD DC P3700 Series Non-Volatile Memory Express（NVMe）驱动，面临一个主要的挑战：因为吞吐量和延迟性能比传统的磁盘好太多，现在总的处理时间中，存储软件占用了更大的比例。换句话说，存储软件栈的性能和效率在整个存储系统中越来越重要。随着存储设备继续发展，它将面临远远超过正在使用的软件体系结构的风险（即存储设备受制于相关软件的不足而不能发挥全部性能），在接下来的几年中，存储设备将会继续发展到一个令人难以置信的地步。

为了帮助存储OEM（设备代工厂）和ISV（独立软件开发商）整合硬件，Inte构造了一系列驱动，以及一个完善的、端对端的参考存储体系结构，被命名为Storage Performance Development Kit（SPDK）。SPDK的目标是通过同时使用Intel的网络技术，处理技术和存储技术来提高突出显著的效率和性能。通过运行为硬件设计的软件，SPDK已经证明很容易达到每秒钟数百万次I/O读取，通过使用许多处理器核心和许多NVMe驱动去存储，而不需要额外卸载硬件。Intel在BSD license许可协议下通过Github分发提供其全部的Linux参考架构的源代码。博客、邮件列表和额外文档可以在spdk.io中找到。

 

软件体系结构概览

SPDK如何工作？达到这样的超高性能运用了两个关键技术：运行于用户态和轮询模式。让我们进一步了解这两个软件工程术语。

首先，我们的设备驱动代码运行在用户态意味着，在定义上驱动代码不会运行在内核中。避免内核上下文切换和中断将会节省大量的处理开销，允许更多的时钟周期被用来做实际的数据存储。无论存储算法（去冗，加密，压缩，空白块存储）多么复杂，浪费更少的时钟周期总是意味着更好的性能和延迟。这并不是说内核增加了不必要的开销；相反，内核增加了那些可能不适用于专用存储堆栈的通用计算用例的相关开销。SPDK的指导原则是通过消除每一处额外的软件开销来提供最少的延迟和最高的效率。

其次，轮询模式驱动（Polled Mode Drivers, PMDs）改变了I/O的基本模型。在传统的I/O模型中，应用程序提交读写请求后睡眠，一旦I/O完成，中断就会将其唤醒。PMDs的工作方式不同，应用程序提交读写请求后继续执行其他工作，以一定的时间间隔回头检查I/O是否已经完成。这种方式避免了中断带来的延迟和开销，并使得应用程序提高了I/O的效率。在旋转设备时代（磁带和机械硬盘），中断开销只占整个I/O时间的一个很小的百分比，因此给系统带来了巨大的效率提升。然而，在固态设备的时代，持续引入更低延迟的持久化设备，中断开销成为了整个I/O时间中不能被忽视的部分。这个问题在更低延迟的设备上只会越来越严重。系统已经能够每秒处理数百万个I/O，所以消除数百万个事务的这种开销，能够快速地复制到多个内核中。数据包和数据块被立即分发，等待时间减小到最少，使得延迟更低，一致性延迟更多（抖动更少），吞吐量也得到提高。

SPDK由数个子组件构成，相互连接并共享用户态操作和轮询模式操作的共有部分。当构造端对端SPDK体系结构时，每个组件被构造用于克服遭遇到的特定的性能瓶颈。然而，每个组件也可以被整合进非SPDK体系结构，允许用户利用SPDK中使用的经验和技术来加速自己的软件。

 SPDK Architecture

我们从下往上构建：

硬件驱动

NVMe Driver：SPDK的基础组件，这个高优化无锁的驱动提供了高扩展性，高效性和高性能。

Inter QuickData Technology：也称为Intel I/O Acceleration Technology（Inter IOAT，英特尔I/O加速技术），这是一种基于Xeon处理器平台上的copy offload引擎。通过提供用户空间访问，减少了DMA数据移动的阈值，允许对小尺寸I/O或NTB的更好利用。

后端块设备

NVMe over Fabrics（NVMe-oF）initiator：从程序员的角度来看，本地SPDK NVMe驱动和NVMe-oF启动器共享一套共同的API命令。这意味着，比如本地/远程复制非常容易实现。

Ceph RADOS Block Device（RBD）：使Ceph成为SPDK的后端设备，比如这可能允许Ceph用作另一个存储层。

Blobstore Block Device：由SPDK Blobstore分配的块设备，是虚拟机或数据库可以与之交互的虚拟设备。这些设备得到SPDK基础架构的优势，意味着零拷贝和令人难以置信的可扩展性。

Linux Asynchrounous I/O（AIO）：允许SPDK与内核设备（比如机械硬盘）交互。

存储服务

Block device abstration layer（bdev）：这种通用的块设备抽象是连接到各种不同设备驱动和块设备的存储协议的粘合剂。还在块层中提供灵活的API用于额外的用户功能（磁盘阵列，压缩，去冗等等）。

Blobstore：为SPDK实现一个高精简的文件式语义（非POSIX）。这可以为数据库，容器，虚拟机或其他不依赖于大部分POSIX文件系统功能集（比如用户访问控制）的工作负载提供高性能基础。

存储协议

iSCSI target：建立了通过以太网的块流量规范，大约是内核LIO效率的两倍。现在的版本默认使用内核TCP/IP协议栈。

NVMe-oF target：实现了新NVMe-oF规范。虽然这取决于RDMA硬件，NVMe-oF的目标可以为每个CPU核提供高达40Gbps的流量。

vhost-scsi target：KVM/QEMU的功能利用了SPDK NVMe驱动，使得访客虚拟机访问存储设备时延迟更低，使得I/O密集型工作负载的整体CPU负载减低。

 

 

从流程上来看，spdk有数个子构件组成，包括网络前端、处理框架和存储后端。

前端由DPDK、网卡驱动、用户态网络服务构件组成。DPDK给网卡提供一个高性能的包处理框架；网卡驱动提供一个从网卡到用户态空间的数据快速通道；用户态网络服务则破解TCP/IP包并生成iSCSI命令。

处理框架得到包的内容，并将iSCSI命令翻译为SCSI块级命令。不过，在将这些命令送给后端驱动之前，SPDK提供一个API框架以加入用户指定的功能，即spcial sauce（上图绿框中）。例如缓存，去冗，数据压缩，加密，RAID和纠删码计算等，诸如这些功能都包含在SPDK中。不过这些功能仅仅是为了帮助我们模拟应用场景，需要经过严格的测试优化才可使用。

数据到达后端驱动，在这一层中与物理块设备发生交互，即读与写。SPDK包括了几种存储介质的用户态轮询模式驱动：

NVMe设备；
inux异步IO设备如传统磁盘；
基于块地址的内存应用的内存驱动（如RAMDISKS）；
可以使用Intel I/O加速技术设备。

四.编译使用

4.1下载代码

git clone https://github.com/spdk/spdk.git
git submodule update –init

4.2 编译dpdk

cd spdk/script
./pkgdep.sh //在编译之前，需安装依赖
make install T=x86_64-native-linuxapp-gcc DESTDIR=.

4.3 编译spdk

cd ..
make DPDK_DIR=./dpdk/x86_64-native-linuxapp-gcc

4.4 配置spdk

./scripts/setup.sh

至此，spdk的基本安装已经完成，下面要做的就是插入nvme ssd设备并进行测试。测试代码在examples下。

4.5 实现原理
通过UIO这个的驱动接口，将驱动中共性的一部分放在内核态实现，eal层次通过解析sysfs的相关节点获取设备信息（bar，function等）传递给用户态的设备模型，之后eal层次用mmap建立内核和用户空间的数据传递通道和同步机制，实现了驱动的用户态功能实现。
Spdk提供了多种存储接口（scsi，nvme等）不同层次的操作接口，可以供用户直接调用完成设备识别，控制，数据传输等。
---------------------
原文：https://blog.csdn.net/zlarm/article/details/79140299

 

SPDK不适应所有的存储体系结构。这里有一些问题可能会帮助用户决定SPDK组件是否适合你们的体系结构。

这个存储系统是否基于Linux或FreeBSD？
SPDK主要在Linux上测试和支持。硬件驱动被FreeBSD和Linux支持。

存储系统的硬件平台是否要求是Intel体系结构？
SPDK被设计为充分利用Intel平台的特性，并针对Intel芯片和系统测试和调整。

这个存储系统的高性能路径是否运行在用户态？
SPDK通过更多地在用户态下运行从网卡到磁盘的高性能路径，提高性能和效率。通过将具有SPDK功能（比如NVMe-oF目标，NVMe-oF启动器，Blobstore）的应用程序结合起来，整个数据通路可能能够在用户空间运行，从而提供显著的高效率。

系统体系结构可以合并无锁的PMDs到它的线程模型吗？
因为PMD持续运行在它们的线程中（而不是睡眠或者不用时让出处理器），所以它们有特殊的线程模型需求。

系统现在是否用DPDK处理网络数据包的工作负载
SPDK和DPDK共享早期的编程模型，所以现在使用DPDK的用户可能会发现与SPDK紧密整合非常有用。同样地，如果正在使用SPDK的用户为网络处理添加DPDK功能可能是个重要的机遇。

开发团队自己是否具有理解和解决问题的专业技能？
Intel没有为相关软件提供支持的义务。当Intel和围绕SPDK的开源社区将付出商业上合理的努力去调出未修改的发布版本软件的潜在错误，任何情况下Intel都没有任务义务为用户提供针对该软件任何形式的维护和支持。

（出处： http://aidaiz.com/spdk/）

 

spdk动机

　　市售的基于NVMe硬盘动辄可达到单盘GB级的读写带宽和十万量级的随机IOPS，为SATA固态硬盘的5~10倍。然而，由于Linux内核驱动实现与调度机制的限制，一般存储软件的表现，相对于NVMe来说，在整个IO事务中消耗的时间百分比就显得太多了。换言之，主流的软件定义存储系统并不能完全释放其性能，存储软件协议栈的性能和效率在存储整体系统中的地位就显得越来越关键了。

　　我们可以把NVMe看做一个硬件进步推动软件革新需求的例子，随着后续比它更快的存储介质投入市场，这种推动力将更为急迫。

spdk基本原理

　　SPDK(Storage Performance Development Kit)，包含一套驱动程序，以及一整套端到端的存储参考架构。SPDK的目标是能够把硬件平台的计算、网络、存储的最新性能进展充分发挥出来。自芯片而上进行设计优化，SPDK已展示出超高的性能指标。

　　它的高性能实际上来自于两项核心技术：第一个是用户态运行，第二个是轮询模式驱动。

用户态运行：降低指令周期

　　将设备驱动代码运行在用户态，是和运行在“内核态”相对而言的。把设备驱动移出内核空间避免了内核上下文切换与中断处理，从而节省了大量的CPU负担，允许更多的指令周期用在实际处理数据存储的工作上。无论存储算法复杂还是简单，也无论进行去重(deduplication)，加密(encryption)，压缩(compression)，还是简单的块读写，更少的指令周期浪费意味着更好的整体性能。

轮询模式驱动：

　　中断式IO处理模式：有IO需要处理时就请求一个中断，CPU收到中断后才进行资源调度来处理IO，采用的是被动的派发式工作。当硬盘速度上千倍的提高后，将随之产生大量IO中断，Linux内核的中断驱动式IO处理(Interrupt Driven IO Process)就显得效率不高了。

　　定点轮询(polling)模式：使用专门的计算资源(特定的CPU核)用来主导存储设备的轮询式处理——就像专门的出租车道和车流用来处理乘客任务，数据包和块得到迅速派发，等待时间最小化，从而达到低延时、更一致的延时(抖动变少)、更好的吞吐量的效果。

　　关于两种方式的比较和讨论，参考这里...，注意：spdk使用轮询模式的前提是高性能的磁盘设备，最终是终端驱动处理还是轮询驱动处理，取决于系统硬件的搭配方式，不同的条件会匹配不同的优化策略

基本组件：

　　SPDK中大概有三类子组件：网络前端、处理框架、后端。

 

图1 spdk基本架构

网络前端

　　网络前端子组件包括DPDK网卡驱动和用户态网络服务UNS（这是一个Linux内核TCP/IP协议栈的替代品，能够突破通用TCP/IP协议栈的种种性能限制瓶颈）。DPDK在网卡侧提供了一个高性能的发包收包处理框架，在数据从网卡到操作系统用户态之间提供了一条快速通道。UNS代码则接续这一部分处理，“crack”了TCP/IP数据包的标准处理方式，并形成iSCSI命令。 

处理框架

　　“处理框架”部分拿到了数据包内容，将iSCSI命令转换为SCSI块级命令。然而，在它将这些命令发到“后端”驱动之前，SPDK提供了一套API框架，让厂商能够插入自己定义的处理逻辑(架构图中绿色的方框)。通过这种机制，存储厂商可在这里实现例如缓存、去重、压缩、加密、RAID计算，或擦除码(Erasure Coding)计算等功能，使这些功能包含在SPDK的处理流程中。在SPDK的开源软件包里，会有这些功能的实现样例。

后端

　　数据到达了“后端”驱动层，在这里SPDK和物理块设备交互(读和写操作)。如前所述，SPDK提供了用户态的PMD[2]，支持NVMe设备、Linux AIO设备(传统spinning硬盘)、RAMDISK设备，以及利用到英特尔I/O加速技术的新设备(CBDMA=3D XPoint?)。这一系列后端设备驱动涵盖了不同性能的存储分层，保证SPDK几乎与每种存储应用形成关联。事实上，英特尔在2015年9月首先开源的SPDK部分就主要包含支持NVMe的用户态轮询模式驱动。

spdk在ceph中的使用

　　Ceph长期以来就其计算资源占用率和性能方面，虽不断提高，但在闪存环境下仍难觅突破性进展。顺应业界趋势，将SPDK的支持在Ceph中实现势在必行。

Ceph与SPDK结合架构图

 (http://www.cnblogs.com/yunlion/p/5742141.html)

 

Blobstore和BlobFS

 

Blobstore的设计目标

Blobstore是由Twitter开发的一个低成本和可扩展的的存储系统，可以用来存储图片以及其他的二进制对象（称为“blob”-- binary large object, 典型的BLOB是一张图片或一个声音文件，由于它们的尺寸，必须使用特殊的方式来处理）。在开始构建Blobstore时，Twitter有三个设计目标：
• 低成本：可以大大减少花费在添加图片到Tweet中的时间和成本。
• 高性能：图片延迟保持在几十毫秒之内，同时保证每秒上千万张吞吐量的图片请求。
• 易于操作：随着Twitter基础设施的不断增长，能够扩展操作开销。

 

Blobstore是如何进行工作的？
当用户推送一张照片，就会把照片发送到一组Blobstore前端的服务器。前端服务器解析后会给该照片一个特定的写地址，接下来将其转发到具体的服务器进行实际的数据存储。其实可以把这些存储服务器称之为存储节点，它们把照片信息存储到一个磁盘上，然后通知元数据存储——图像已经存储完毕并记录所需要的信息以便进行照片检索。元数据存储库，这是一个非关系型键/值存储集群，它可以自动的进行多数据中心（multi-data-center）的同步功能，更重要的是可以跨所有的Twitter的数据中心，进而在Blobstore上提供的一致性的视图数据。
Blobstore核心是Blob Manager，它运行在前端，用于存储节点以及索引集群。Blob Manager充当系统中心“协调员”的角色，对集群进行管理。它是所有前端信息（决定应该把文件存储到哪个地方）的源。不仅如此，它还负责更新映射，在增加存储节点或者由于添加失败节点被移除时，协调数据的迁移。
还有一点比较重要，就是依靠Kestrel。这是Twitter现有的异步队列服务器，主要用来处理任务，比如说复制图像以及确保数据中心中数据的完整性。
Twitter确保一旦图像上传成功，用户就可以立即从数据中心中进行读取，而且绝对是最原始的图像。而且在如此之短的时间内，图像已经复制到Twitter所有其他的数据中心之内，并且可以从这些数据中心进行读取。此功能主要依赖于Blobstore内的多数据中心元数据存储对文件的中央索引。Twitter高度关注短时间内一个图像是否被已经被写入它最初的数据中心，他们使用路由请求，确保该Kestrel队列能够进行数据复制。

 

BlobStore和SPSK
BlobStore 的定义是一个持久化的，数据安全的块设备管理引擎，用来提供一个高层的逻辑 API 来利用块设备，可以理解为是一个简陋版的文件系统。
SPDK BlobStore 主要目标是在为 NVME 设备提供一个异步接口，没有缓存，并行读写的 Blob 接口，这个 Blob 可以是任意 block size 对齐的范围。
SPDK BlobStore 提供了一个相比纯粹块接口，更佳丰富的语意，方便应用使用，同时，它的特点是利用了 SPDK 进行高性能访问写入。
跟 BlobStore 一起推出的还有 BlobFS，顾名思义，就是给予 BlobStore 之上，提供一个伪文件系统接口到 RocksDB，因为很难定义这种接口语意，所以 BlobFS 目前只是深度跟 RocksDB 集成。

 

与 GAE (Google App Engine)相关的3种存储方法
1. Bigtable 使用很简单，但是它有 1MB 文件大小限制。
2. Blobstore 的大文件最高可以支持 2GB，但是一次 URL 在 Web 服务中很难实现。
3. Google Storage for Developers 是三种 GAE 存储方法中最强大的一种，但是最复杂，需要付费。
Datastore（即 Bigtable）负责保存一般保存到数据库的常规数据，而 Blobstore 则负责保存大型的二进制文件。

详见http://www.uml.org.cn/sjjm/201204054.asp