标签：
Facebook与卡内基梅隆大学最近在SIGMetrics ( June 15–19, 2015, Portland, OR, USA).发表一篇关于大规模应用下PCI-e flash失效研究的文章”A Large-Scale Study of Flash Memory Failures in the Field” 。基于对Facebook数据中心近4年来大量flash失效数据的总结，揭示了一些有趣的现象，对flash，存储软件，全闪存阵列，应用者以及基础架构运维者有启发意义。
原文在 http://users.ece.cmu.edu/~omutlu/pub/flash-memory-failures-in-the-field-at-facebook_sigmetrics15.pdf。以下做个综述和总结。
数据样本
看任何数据前很重要的要仔细明确基于什么样的样本。 论文中的样本主要来自Facebook数据中心部署的PCI-e flash，全部是MLC介质，来源有多家厂商，多批次（包括Fusion-io, Hitachi, Intel, OCZ, Seagate, Virident）。容量方面有720GB, 1.2TB和3.2TB。由于来源众多，需要合理分类以揭示区别。论文主要依据容量，PCI-e V1 还是V2， 以及单块还是双块使用等。其中使用1.5年以内，容量1.2TB/3.2TB的占样本多数71%。
类似SMART，Flash健康状况通过特殊的寄存器由Facebook的采集脚本每小时搜集一次，并导入Hive通过MapReduce-R语义进行归并分析和处理。可惜的是经过归并之后 研究没有保留足够多的时间戳信息。事实上Rawdata主要是基于2014年11月的快照点。
注意1): 控制器都会内置ECC校验和纠错，通常采用分级-渐进方式: 小范围错误(每KB几个bit)往往由控制器自己搞定；而更大粒度的错误往往交由host driver来调度处理。论文中的failure是指控制器自己无法处理和由host来处理的错误。
2)因为是累计最长达4年的数据，现在的flash，FTL和控制器和当时已经发生非常大的变化，所以比较新的ssd(如E/F)表现和特征应更有指导意义。
UBER： SSD不可纠错码率。其他在受控环境下Raw flash的错误率大概在1*10(-6) ~ 1*10(-8)之间，而实际环境下, 由于控制器优化和纠错 则更低：10(-9) ~10(-11). 同时数据倾斜现象非常明显(如图中的B)，出现10% 的设备贡献了95%的高错码率. 论文发现比较服务Weibull分布。猜测其中一个原因是高相关性, 本周发生了失效 下周很可能也失效，一台host内SSD-A发生失效，另一个SSD-B也很可能有失效报告。 (笔者猜测另一个可能性是产品批次工艺的良品率，但论文没有对比研究)。
数据写和失效模型
论文最重要的一个发现是3阶段失效模型：首先错码率并非单调递增，相比学者针对机械磁盘总结发现的bathtub(浴缸)2-阶段模型，它多了一个Early-Detection阶段(如下). 作者做了个简单的解释性说明，可以认为flash里block归属于2个pool: weaker/stronger pool: 早期weaker pool里总是迅速发现小的错误并纠正导致上升，之后错码率变得安分而下降；但之后强力失效的pool则主导了走势。GC/擦除和数据写入基本符合相同的模型和影响。
样本D和F看起来比较怪异(写入量增加了 错码率反而还下降)，其实这很可能是因为他们目前处于第1/2阶段(甜蜜期), 如果看样本分类表，这两组中总体写入量还是低于其他比如C/E，而后者可能已步入了老年期.
注: 这里的写入是指实际写入到flash cell的数据量 (不完全等于App/OS写入量，因为有各种写放大和消除技术)
读flash对寿命的影响
比较幸运，没有观察到明显的关联关系。
大块和小块和DRAM Buf
FTL内部维护logical offset-page address, 小写往往导致非连续和更多的元数据开销(DRAM buffer). 结论和磁盘类似，从元数据使用有效(注以及GC)，flash也更适合大块读写
温度和功耗影响
30-40度运行期间，各个平台表现一致(小幅上升)。超过了40度则进入3阶段失效模型。其中主要的影响因素 1)超过了一定温度，控制器开始彰显自己的存在，并试图降速稳定系统 类似CPU的降频。注意，一些老的控制器可能没有这样功能。 2) 系统中多块SSD往往功耗更大加快了温度上升。
写放大
毋庸置疑，App/OS的写入量和实际Cell的写入量不尽相同，中间有很多变数，不利的变数主要是写放大包括: 额外的元数据开销，replica，RAID等，常用的优化技术包括buffering, batch, append-log, dedup, compression, new-RAID等。正因如此，简单把磁盘替换成闪盘，而不做系统级别的优化是难以发挥SSD的优势的，尤其是全闪存 需要在系统软件(包括调度，CPU, Mem)和IO层面(合并, inline dedup, compression, RAID)等做深入的架构优化设计。
市面上几家典型的代表 (如EMC XtremIO, SolidFire, PureStorage)无不如此，出于产品定位，自身特长以及Time-To-Market等综合考虑，各家在架构和实现方面还是有很大差别的，如果想做更多深入了解全闪存，这里推荐2个非常不错的视频(TechField, 2014)。分别由XtremIO和SolidFire当家领袖或阐述自身特点 或 对比分析。当然，这里并没有一好百好，看场景，看需求，哪家更适合大众场景 哪家就有优势。
1, EMC XtremIO Architecture & EMC Evolving All-Flash Use Cases & Why Architecture Matters, Robin Ren, CTO, EMC XtremIO
- http://techfieldday.com/appearance/emc-presents-at-storage-field-day-5/
2, Comparing Modern All-Flash Architectures - Dave Wright, CEO, SolidFire
- http://techfieldday.com/video/comparing-modern-all-flash-architectures-dave-wright-solidfire
论文的不足和局限
作者做了简单的例举:
- 论文并没有针对分布式系统中常见的多份Replica可能带来的跨节点的SSD失效相关性进行深入研究
- SSD失效与性能的相关分析
- 受限于数据采集局限性，没法获得SSD内部各个flash上workload的分布和模式
- 纠错模型: 论文的错码率指的是控制器没法处理而交由host处理的，将来NVMe设备可能并非采用这种方式。
总结
1. Facebook大规模flash部署和实用是可以展开深入研究分析的前提，这一点和Big Data类似，谁握有数据 谁握有发言权！
由此想到一个类似领域的文章，今年FAST15上 EMC 发表一篇文章，主要搜集了5年多来，近1百万磁盘(都是基于RAID)失效log，论文从中发现了些若干前导性主因素，以此为切入点，设计出更有效的主动防御性保护，并已投入实用 减少近90%的3盘失效。 感兴趣的可以看看，怎么通过好的数据源 做些有意思的事情。 https://www.usenix.org/system/files/conference/fast15/fast15-paper-ma.pdf
2. 主要的发现点 1)3阶段失效模型 2)读影响和寿命不相关. 其他几点基本都是目前已确认或者形成了共识例如温度, 写放大，大块/小块等。
3. 遗憾点:
1) 数据没有做有效的时间序列标记，而更多的是一段时间aggregate之后的截屏(snapshot) 这就丢失了中间随时间变化而可能存在的现象，规律。
2) 没有更多围绕性能, workload而做深入的分析
3) 缺乏定量分析从而降低了现实指导性。论文的很多数据以及多因素 vs失效的对比分析，在我看来，更多的是抓到一兜数据，做把关联分析，恰巧展现了(或没有展现)某种相关性，但是没有定量性研究因果关系和主因素分析。比如，温度上升究竟是个初始因素还是因为R/W负载过大 导致的一个结果，如果是结果的话，自然而然，其对失效的影响也就保护在R/W的影响之内了。
欠缺深入的定量分析(其中一个受限因素是ssd没有提供更多API接口)，导致其他开发/研究者难以从本论文汲取到新的研究点 来开展更多的优化。
4) 论文没有提到要开放采集到的数据。我猜测似乎能挖的 都挖了，遗憾，守着大矿，没有形成我心目中更优质的Raw data source！
Facebook大规模Flash失效分析研究 - SIGMetrics, 2015
标签：
原文地址：http://www.cnblogs.com/zhaojp/p/4593981.html
