存储系统的缺失与弥补方案

存储系统的缺失与弥补方案

当今市面上的存储系统存在若干具有普遍性的问题。通常情况下,数据从外部接口进入,存储引擎则进行数据处理。每种存储引擎均有其各自的特性,可以进行数据应用,或压缩、加密及映射等。在存储引擎处理数据的同时,还要进行应答,并将应答发送给高层应用。为了实现这一点,所有的存储系统均采用某种写缓存来尽可能快地作出应答,使应用得以执行各自的任务。此外,数据处理部分还会产生许多元数据。对每一个进入系统的I/O,元数据处理均如影随形般进行着。显然,也需要元数据存储来辅助数据处理。因此,这两种负载成为了存储系统中的瓶颈:写缓冲缓存和元数据缓存,亟需解决。如图1所示。

图1现有存储系统架构中的瓶颈

这两种负载的主要特点决定其均需要存储设备具有尽可能高的性能才能应对。理想的目标是这两种负载都能达到与图2中最上层的内存相当的性能。同时,也希望其具备与图中底层所示的外存相当的非易失性来弥补内存在断电情况下数据容易丢失的问题。观察从内存到外存的存储层级,可以看出,这两种负载所需要的理想存储介乎外存与内存的层级之间——姑且称之为:关键型任务性能缺口(如图2所示)。

图2 性能缺口

如何应对这些挑战呢?自然而然的反应可能是:“用SSD来解决吧。”回头看看,这正是几年前多数存储系统采取的办法——将SSD用作写缓冲和元数据缓存。但随着技术的进步,闪存已然成为了占据主导地位的存储媒介,IOPS逐步提升,SSD而今已无法再满足这些性能需求。真正的挑战还在于SSD的耐写度。来看看这些负载所需要的耐写程度。图3的纵轴标示的是每日写入的次数。横轴从左至右,IOPS从50,000增至1,000,000,图中显示了维持各个IOPS水平所需的写入次数。

图3闪存的耐久度难题

几年前,50k IOPS的系统仍然非常高端,而今,却已连入门级水平都达不到。现在面对的是100k甚至更高的系统。以100k IOPS的系统为例,如果打算采用400GB SSD,即如图3中蓝线所示,那么,400GBSSD所需的耐久度是每天写100次。这显然是闪存无法达到的。即便将容量增至两倍甚至四倍,耐写度需求降至每天写入10次的范围,SSD也只是勉强可以应付,这样的SSD价格也十分高昂。放眼未来,发展趋势是右上角的绿色圆块部分。显而易见,由于耐写度的问题,目前闪存无法胜任不断攀升的IOPS速度。

既然闪存不行,多数人会回头求助于DRAM。那么,DRAM能否胜任呢?不言而喻,从性能的角度来看,DRAM非常理想,但DRAM的缺点在于其容易受到电源故障的影响。所以必须为DRAM提供保护。保护DRAM的办法通常是加入集成的UPS系统或电池备份单元。而电池本身就存在一系列问题如可靠性差、生命周期比系统短等等,从而产生了维护的巨大困难。此外,电池要占据大量空间。有电池备份的存储机架中,四分之一的位置都被电池所占据。显然,这些为电池所霸占的空间完全可以更好地利用。

审视摆在面前的这些问题,PMC创造出了独具匠心的NVRAM 加速卡解决方案。该方案完美填补了内存层与SSD层之间的空白。PMC的NVRAM 加速卡性能优异,因此不仅仅起到了填补空白的作用,还实现了若干独特的功能。

图4 PMC Flashtec NVRAM加速卡

首先,从硬件外观上来看,这是一款标准尺寸、半高半长的PCIe卡。其设计紧凑,可以置入任何服务器当中,基本上与所有服务器均能兼容。此外,PMC还在该方案之上与主机相连的接口层进行了若干创新。如图4所示,左边显示的是当前应用的原生接口,均是基于块。因此,我们提供了一个NVMe接口,这对一直采用块设备的应用而言是原生接口,易于整合。对于进出均使用大块数据的写缓存而言,这也是一个原生接口。此外,我们还提供了内存映射访问。在该模式下,我们将内存容量直接映射到应用的虚拟内存地址空间。因此,当应用需要访问时,就可以采用CPU的载入/存储命令将其作为原生内存来使用,而无须耗费任何存储周期,或触及任何软件层。对元数据应用而言,这种方式使之可以非常便利地访问内存。

图5 Flashtec NVRAM应用模型

有了这两个接口:基于块的接口和内存映射接口,就为写缓存以及元数据的负载问题找到了解决方案。那么,该方案在块模式中提供的性能如何呢?测试结果显示,该NVRAM 加速卡能提供一百万次IOPS。将之与SSD相比——与SSD的持续性能水平相比,该产品的性能比SSD要高出10倍。

图6 Flashtec NVRAM性能十倍于SSD

图5中展示出将该产品与一款极其先进的PCIe SSD的结果。众所周知,SSD的性能基本取决于闪存。闪存的性能有可能很高,但就持续性而言,闪存存在不够耐写的问题,因此,闪存的性能也是不均衡的。相比之下,PMC的NVRAM 加速卡持续性地提供均衡的性能,达到1 百万IOPS读/写,并且没有任何耐久度的问题。

再来看看内存映射接口的情况。在内存映射端口,该卡的性能远远不止这个数值,对64B随机写,能够持续地提供一千五百万次IOPS。文中开篇时讲到,对于每个需要处理的数据缓冲,都有多次元数据I/O。因而,若要持续维持一百万次写IOPS,就需要处理相应的多份元数据。而有了一千五百万次随机读/写IOPS,该解决方案的性能是游刃有余。

图7 Flashtech对64B数据处理的随机写IOPS可达1.5m

最后一个性能指标是CPU利用率。与基于内存的解决方案相比,采用NVMe驱动的核心优势在于能够高效进行DMA处理。NVMe协议在这一方面的效率惊人。用NVMe将数据从内存移至NVRAM解决方案,效率比利用CPU周期要高出四倍。这一点至关重要。进行内存备份基本上就要消耗CPU周期,而这些时间本可以用于上层应用软件的处理,这才是最需要CPU资源的地方。

图8 CPU利用率优于NV-DIMM

PMC的NVRAM 加速卡创立了一个独特的存储层级——DRAM和SSD之间的高性能存储层级。该产品能提供千万次写IOPS及百万次IOPS(4k块),从而实现了多种应用所需的性能与耐写程度。该产品采用行业标准的接口,PCIe接口,NVMe接口以及原生内存映射访问接口,因此,可以缩短系统上市的时间,降低总体拥有成本。此外,此项设计也是针对“企业级”关键型任务应用,可靠性优异。如今的存储市场日新月异,应用场景多样化,数据类型繁多,NVRAM加速卡的推出提供给设备厂商以及数据中心用户一个全新的选项,完美填补了存储系统中的空白。

时间: 2024-11-12 19:19:38

存储系统的缺失与弥补方案的相关文章

JAVAWEB项目报"xxx响应头缺失“漏洞处理方案

新增一个拦截器,在拦截器doFilter()方法增加以下代码 public void doFilter(ServletRequest request, ServletResponse response,FilterChain chain) throws IOException, ServletException { //增加响应头缺失代码 HttpServletRequest req=(HttpServletRequest)request; HttpServletResponse res=(Ht

Kubernetes数据持久化方案

在开始介绍k8s持久化存储前,我们有必要了解一下k8s的emptydir和hostpath.configmap以及secret的机制和用途. 1.EmptydirEmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,EmptyDir主要作用可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件.如果Pod配置了emptyDir类型Volume, Pod 被分配到Node上时候,会创建emptyDir,只要Pod运行在Node上,emptyDir都会存在(容器挂掉不会导致

Go之FAQ(一)

纯粹业余兴趣翻译,能力有限水平业余,欢迎拍砖. 文中还有一些句子没作翻译,是因为我完全没弄懂:-) 问题较多, 分part翻译,本文为第一part. 原文: Frequently Asked Questions (FAQ) 起源 What is the purpose of the project? 非系统底层语言的出现已经有十多年的时间, 而在这期间计算环境已经发生了巨大变化.以下是几大发展趋势: - 计算机运算速度有极大提升, 但是软件开发效率没有明显提高. - 依赖管理是今天软件开发一个重

转发 GSLB概要和实现原理

What is GSLB Global Server Load Balancing 中文:全局负载均衡 SLB(Server load balancing)是对集群内物理主机的负载均衡,而GSLB是对物理集群的负载均衡.这里的负载均衡可能不只是简单的流量均匀分配,而是会根据策略的不同实现不同场景的应用交付. GSLB是依赖于用户和实际部署环境的互联网资源分发技术,不同的目的对应着一系列不同的技术实现. Why GSLB 总结为: 高可用性 更快的响应时间 多版本分发 具体: Disater re

《程序员修炼之道》---- 修的是什么

学习最好的方式,是有个好师傅.他根据你的不同阶段,教导你不同的技能,循序渐进:师傅不单教你练功,还会教你做人,使你内修于心,外化于形.教你的一些道理,你可能当时不太懂,但等你苦练多日,历经曲折,终有一日茅塞顿开,再去学艺做事,事半功倍,大有精进: 有一个位好导师自然是得之我幸的事情,但实际工作中很难得,也许有前辈们偶尔的点拨,有朋友的激励,但最平实可靠的方法还是来自于阅读 本书原名 "The Pragmatic Programmer",也就是"注重实效的程序员".本

Muduo网络库实战(二):实现服务器与客户端的连接

1. 方案的确定 1)基本需求 用户1000+, IO压力不大: 多个客户端打开网站,输入查询字符串strclient,发送给服务器=>服务器接收客户端发过来的数据并处理,将结果返回给客户端: 2)并发网络服务程序设计方案 详见:<Muduo_网络库使用手册>的1.6节-<详解Muduo多线程模型> @ muduo中TcpServer模式的选择:多线程模式 模式一:单线程,accept与TcpConnection用同一个线程做IO; 模式二:多线程,accept与EventL

写给立志做码农的大学生(蘑菇街你都挂了,你还要面腾讯? 我去,我一定要去)

先简单介绍一下我自己,我是一所普通大学的本科生,大学录取时的专业是非计算机系的,在大一下学期意识到自己喜欢敲代码以后,就提交了转专业申请.大二起开始在计算机系学习.大三时(2015年4月)拿到了腾讯暑期实习的offer,暑期实习的过程中获得留用offer,大四没跑秋招,几乎就在学校浪荡了一年. 我不是大牛,不是来传播鸡汤或成功学的,只是最近有感于学弟学妹们在学习以及规划方面严重不足,觉得这是一个共性问题,遂捉起纸笔,写点东西. 1. 确定方向 1.1 选择比努力更重要 关于方向的选择其实越早确定

将计算机思维故事化——之操作系统典型调度算法

在计算机正常工作中,后台有大量的进程在执行,但彼此"不争吵不争夺",这归功于操作系统中的调度算法. 通常.大多数进程的执行能够简单的分为两步走: 第一步,将须要运行的进程从外存(比如,电脑的硬盘)中选出来,送至内存"候旨",准备让CPU来运行: 第二步,CPU从那些在内存"候旨"的若干进程中选出一个.開始运行. 简单的说,调度就是选择的办法. [调度是多道程序操作系统的基础,是操作系统设计的核心基础.上述"两步走"中.第一步中

Chapter 6-03

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1 Welcome to my github: https://github.com/gaoxiangnumber1 6.6 详解muduo多线程模型 ?本节以Sudoku Solver为例,回顾了并发网络服务程序的多种设计方案,并介绍了使用muduo网络库编写多线程服务器的两种最常用手法.本节代码参见:examples/sudoku/. 6.6.1 数独求解服务器 ?假