SSD数据可靠性问题分析
前几个月对近两年Facebook和Google发表的两篇SSD故障分析的文章进行了阅读,并进行了整理。Google的在今年的FAST会议上发表了《Flash Reliability in Production: The Expected and the Unexpected》,在这篇文章中通过收集长达六年的数据对SSD可靠性进行了研究,并且对比了SSD与HDD之间的可靠性差别。Facebook在2015年发表了《A Large-Scale Study of Flash Memory Failures in the Field》,同样通过大数据的方式对Flash的故障进行了长时间的分析。这些研究工作实际上都在追问SSD在企业级应用的一些问题:SSD在实际的数据中心中是否可以安全部署?为了让SSD在数据中心大规模部署,我们还需要做哪些工作?
在Google的研究中对UE(Uncorrectable Error)进行了深入的研究分析。大家知道NAND Flash介质是不可靠的,经常会出现错误,用着用着就有可能遇到位错误,这是常态。尤其是15nm制程以及TLC/QLC的推广,使得NAND Flash的Bit Error问题变得更加严重。SSD一个重要的职责就是纠正这些Bit Error,让不可靠的NAND Flash变成可靠的SSD存储盘。
但是,尽管SSD内部具有强大的BCH或者LDPC编解码单元,以及RAIN等条带化数据保护机制,但是还是不可避免的发生UE这样的错误。NAND Flash发生故障,可以通过ECC、RAIN或者Firmware等手段解决,这类错误被称之为Correctable Error,属于Transparent Error的范畴,这类错误不会对应用产生影响。SSD内部机制无法解决的错误,那么这类错误将会对业务产生影响,被称之为UE,属于Non-Transparent Error范畴。对于UE故障,Google通过连续4年的数据表明,20% (20~63%)的SSD遇到会发生UE,这种UE在业务层表现为Bad Sector;和磁盘对比,在32月的时间内,3.5%的传统磁盘会遇到Bad Sector。这也就说明SSD在数据局部损坏方面会远远高于HDD,大致对比如下:
除了观察局部损坏故障之外,用户还会比较关注SSD的整盘损坏。Google的研究数据告诉我们,在4年的时间内,SSD的整盘更换率为4~10%,而传统机械磁盘的年更换率为2~9%。从这点上来看SSD的整盘故障更换率要比HDD低很多。这也表现为一旦SSD上线之后,比磁盘要具备更低的更换率,可以大大简化系统运维。
对于具体的错误类型,从上图我们可以看出,在Non-Transparent Error这块,绝大部分错误都是Uncorrectable Error,也就是读操作时发现bad sector,导致数据丢失。并且在大规模部署的情况下,这种错误导致的影响还是非常严重的。
除了分析SSD盘对外表现出来的局部以及整体故障之外,Google还对SSD数据可靠性因素进行了分析,影响SSD数据可靠性的因素大致有如下几点:
1, SSD磨损(Wear Out)
2, SSD技术类型(MLC、TLC)
3, 制造工艺
4, 使用时间(Age)
5, 温度
比较有意思的是,SSD的数据可靠性与使用时间相关,而不仅是使用寿命。如果一块盘在没有使用的情况下长时间存放,那么该盘的数据故障率要比一块新盘高。如下图所示:
对于一个全新的旧盘,由于长时间存放之后,SSD内部NAND Flash所产生的出错位数明显增加。这也说明SSD的数据可靠性与时间相关。此外,不同的制造工艺对SSD的数据可靠性也会产生重要影响,下图对比了不同NAND类型以及不同制造工艺情况下的数据可靠性:
总体来讲,从Google的统计数据我们可以发现SSD的故障模型和HDD相比发生了重要变化。SSD在整盘故障方面要优于HDD;但是在局部故障方面,SSD明显故障率要高于HDD。因此,在大规模部署SSD的情况下,上层的应用软件还是需要考虑SSD存储的容错机制,防止数据在SSD中丢失。由于SSD故障模型的变化,上层软件的容错机制也需要做出调整,适应SSD大量局部故障的问题。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
操作系统CnetOS_7—systemd管理实践指南
systemd管理实践指南 管理systemd CentOS 7 使用systemd替换了SysV。Systemd目的是要取代Unix时代以来一直在使用的init系统,兼容SysV和LSB的启动脚本,而且够在进程启动过程中更有效地引导加载服务。 systemctl命令是系统服务管理器指令,它实际上将 service 和 chkconfig 这两个命令组合到一起。 Systemd :系统启动和服务器守护进程管理器,负责在系统启动或运行时,激活系统资源,服务器进程和其它进程 Systemd 新特性: 系统引导时实现服务并行启动按需启动守护进程自动化 的 服务 依赖 关系管理同时 采用socket 式与D-Bus 总线式激活 服务系统状态快照 核心概念:unit unit 表示不同类型的systemd 对象,通过配置文件进行标识和配置;文件中主要包含了系统服务、监听socket 、保存的系统快照以及其它与init 配置文件: /usr/lib/systemd/system: 每个 服务最主要的启动脚本设置 ,类似于之前的/etc/init.d//run/systemd/system :系统执...
- 下一篇
Apache select和Nginx epoll模型区别
部分内容摘自跟老男孩学Linux运维:Web集群实战(运维人员必备书籍) http://oldboy.blog.51cto.com/2561410/1752270 1.select 和epoll模型区别 1.1.网络IO模型概述 通常来说,网络IO可以抽象成用户态和内核态之间的数据交换。一次网络数据读取操作(read),可以拆分成两个步骤:1)网卡驱动等待数据准备好(内核态)2)将数据从内核空间拷贝到进程空间(用户态)。根据这两个步骤处理方式不一样,我们通常把网络IO划分成阻塞IO和非阻塞IO。 ·阻塞IO。用户调用网络IO相关的系统调用时(例如read),如果此时内核网卡还没有读取到网络数据,那么本次系统调用将会一直阻塞,直到对端系统发送的数据到达为止。如果对端一直没有发送数据,则本次调用将永远不会返回。 ·非阻塞IO。当用户调用网络IO相关的系统调用时(例如read),如果此时内核网络还没有收到网络数据,那么本次系统调用将会立即返回,并返回一个EAGAIN的错误码。 在没有IO多路复用技术之前,由于没有一种好的方式来探测网络IO是否可读可写。因此,为了增加系统的并发连接...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7设置SWAP分区,小内存服务器的救世主
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路