先有XPoint，继而Z-NAND：如今， SCM亦即将到来

目前，以Optane形式推出的存储级内存（SCM）已经与三星公司的Z-SSD齐头并进，且可供服务器设备加以使用。而这将意味着什么呢？

SCM——亦被称作持久性存储器（简称PEEM）——是采用英特尔/美光方面的3D XPoint介质或三星公司的Z-SSD构建的一款存储速度更快的非易失性存储器版本，其中三星方面的Z-SSD是经由NAND LLC（每单元1 bit）调整而来。此外，其存储速度高于闪存但低于DRAM，自然其市场定价也介于两者之间。

SCM的速度足够快，可将其作为DRAM的附属设备并通过应用程序与系统软件以将其转化为内存使用。然而，由于SCM的存储性质是持久性的，故而应用程序无需传统的IO堆栈代码即可从SCM中完成数据的读取与写入。

那么，SCM会对服务器与存储产生怎样的影响呢？

下面这张图即可揭示谜底：

服务器中SCM的作用解析（图片来源：Dave Hitz）

如图所示，图片顶端有一组应用程序（App）与虚拟机中的应用程序（App/VM），其中Apps在带有操作系统的物理服务器上运行，而App/VM则运行于配有管理程序的虚拟化服务器。

由于上图中没有展示容器，故而我们暂将其视为另一种服务器的虚拟化形式。如今，App与App/VM均使用DRAM将IO操作传送至本地直连或外部存储（如红色箭头所示）。

而如果安装了SCM，理论上其将与DRAM并行放置。那么一些软件则需要将DRAM + SCM作为一套单独的内存地址空间/实体呈现给App与App/VM（如蓝色箭头所示）。

该图将其作为介于O/S、虚拟机管理程序以及App之间的一套软件垫片机制。对于这些运行代码而言，SCM如同内存一般扩展DRAM并确保能够大幅提高IO受限的App与App/VM的运行速度。

另外，可将SCM看作一款带有缓存管理软件的透明缓存——简而言之即为“垫片”。

SCM适用于热门数据，其能够完成数据的初步加载并将新创建的数据转换为长期存储。因此，蓝色箭头表示其能够与服务器中的直连存储设备实现连接或通过网络以连接外部存储设备。

其中的缓存管理软件或垫片可能是系统级应用程序——例如NetApp的Plexistor，也可能是服务器操作系统或管理程序的一部分。那么在这种情况下，首当其冲的问题就是：物理服务器的操作系统——具体包括Windows、Unix与Linux——将如何支持SCM呢？

其次则是虚拟机管理程序——诸如vSphere、XEN与VM——又将如何实现其对SCM的支持呢？

硬件角度

提及硬件方面，那么这里还存在一个更为基础的问题，即SCM介质是如何在服务器内部完成安装的呢？是通过标准驱动架或PCIe插槽中的PCIe接口驱动器还是通过使用NV-DIMM形式直接安装至内存总线呢？

后者无疑是最快的连接方式，但却需要一套NV-DIMM标准以确保任何行业标准的X86服务器——即是指任一时期的服务器——能够使用，并且据了解，制造商方面正在考虑使用IBM POWER、富士通/甲骨文的 SPARC以及ARM处理器。

有关硬件方面的另一问题即是：由谁来完成安装呢？答案显然是服务器供应商。而如果是选用1U 刀片式服务器或2U x 24插槽主力机型，那么机箱内部可用于其他组件（例如SSD）的空间会进一步减少，所以DRAM、SCM与本地存储之间应该保持怎样的一个平衡呢？

这对现在市场上的服务器供应商而言将会是一个棘手的问题，而其中就包括了思科、戴尔、富士通、HPE、华为、联想、SuperMicro与Vantara等。

最后，SCM DIMM的生产制造又该由谁负责呢？迄今为止，尽管独立的NV-DIMM供应商（例如Diablo Technologies）已经为此背水一战，而结果却一目了然，其生产制造必然是由SCM介质制造商负责——目前即是指英特尔/美光与三星公司。美光与三星都生产DRAM、NAND以及DIMM，并且两家公司与服务器供应商都有一定的合作关系以出售其DRAM与NAND。

至此，我们已然明确物理供应链与SCM介质制造商以及服务器供应商之间的依存关系。所以，处于这一生态系统以外的任何一方都将很难以任何形式——无论是2.5英寸驱动器、附加卡还是NV-DIMM等——完成SCM介质驱动器的销售。

软件角度

软件方面的问题在于操作系统与虚拟机管理程序供应商是否需要提供所需的SCM软件或创建一套独立的软件系统——如同NetApp的Plexistor、Hazelcast或其他未知的开源项目（如Memcached）——以提供一套独立的SCM系统。

无论结果如何，可以肯定的是，为了快速推进SCM的实施，相关应用程序皆应无需作出任何对应变更。

超融合方面

超融合型基础设施（HCI）设备供应商会对SCM的采用做出怎样的反应？答案很有可能是：a）HCI设备供应商为避免其性能落后，从而希望能够采用SCM；b）希望在HCI节点上完成SCM的整合。

这对于思科、戴尔EMC（VxRack/Rail）、HPE以及如今的NetApp、Nutanix、Pivot3、Scale与各软件HCIA供应商——诸如DataCore、Maxta等——而言将会是一个难题。

据悉，由于Nutanix收购了Pernixdata，故而其在这方面具有一定的优势。Pernixdata方面的技术提供了管理程序级别的缓存。那么，SCM可以实现跨服务器（或HCI节点）整合以提供单个逻辑SCM资源池吗？

目前，对于以上问题我们还尚未得出一个较为明确的答案。

网络角度

SCM后端能够将冷门数据转移至长期存储设备，此即意味着在传统IO堆栈意义上，SCM后端可作为一套IO使用——除采用NVMe over Fabrics连接的场景下。所以，以上所提及的数据存储转移工作需要由组成SCM后端的代码完成，而目标设备则可以是服务器本地或远程设备（文件管理器、SAN或公共云）。

上文展示的图表展示了包括HCI与集群节点在内的网络列表，我们认为这对于HCI与集群供应商将会是一个难题。此外，与存储阵列的网络连接也将成为存储阵列行业与存储阵列互连生态系统——指以太网/iSCSI/NFS、光纤通道与InfiniBand供应商等——即将面临的一大难题。

网络互连需要一套成熟的NVMe over Fabrics标准，以便前端的服务器与后端的阵列能够使用一套标准的NVMeoF HBA或适配器实现对通路中任一端的连接。然而，由于NVMeoF将作为必要的网络管道，因此诸如博科或Mellanox这样的供应商则无需再为SCM作出任何针对性调整。

存储阵列角度

存储阵列方面的相关人员可能认为其需要为此做出一定的贡献以确保能够将热门数据作为SCM缓存的最佳使用区间。然而，由于端对端的NVMe连接可能会让数据绕过其控制器，从而导致他们对于驱动器的状态失去控制，并且如果服务器中的应用程序无法响应，他们就无法准确地将数据服务应用于驱动器内的数据，所以综合以上的原因看来，存储阵列方面的研究人员可能不会在服务器与其阵列之间建立端到端的NVMe连接。

Datrium、Excelero以及其他存储阵列都配有一个服务器，所以原则上是可以完成的。

阵列供应商可以做的就是对来自于控制器缓存的NVMe fabric传入请求提供服务并以此获得NVMeoF级的速度，而在此过程中无需将其阵列转换化为实质上的闪存JBOD——即纯粹的、控制器旁路的端到端NVMe。

事实上，阵列控制器可以使用SCM以完成此类缓存，而NetApp正在致力于研究这一课题。

SAN、文件管理器以及对象存储对SCM的态度与应用方式可能会存在一定的差异，但在这里我们就不再一一进行介绍了。

Nirvana即将推出——但仍需要一段时日

在安装SCM之后再配合NVMe，无疑能够令长期存储服务器获得比当今服务器更高的执行效率。机器学习、数据库响应与分析也将会随着服务器能够承载的与实时处理的数据量提升而彻底改变。

然而，仅仅是安装SCM介质并不足以直接完成上述效能。这一系列的技术领域与技术供应商都必须团结一致，共同努力才能够完成这个颠覆性的技术革命。

SCM似乎已经不再是一个不可企及的目标，而是一个能够实现的可能——尽管还需要时间以进一步发展相关技术。我们相信，在2019年或之后的某个时间点上，我们终将真正迎来SCM Nirvana 1.0。