谈PCIessd在数据库优化中的作用II之颠覆性创新-吕智超

谈PCIessd在数据库优化中的作用II之颠覆性创新Apr2015ShannonSystems宝存科技关于摩尔定律•由于基于Flash闪存存储设备的出现;处理器,内存和存储设备终于都可以遵循摩尔定律实现快速的发展.12核心,24线程@3.2GhzDDR4DRAM@2133MHz768GB@2U500KIOPS,9us延迟50TB裸容量@2U当谈及数据库应用的存储方案时•容量•性能•安全性•应用成本•Flash存储起到的作用基于Host的PCIeFlash存储的优化与方案•超大容量高可用Flash存储(Ultra-capacityandhighlyavailableFlash)•原子写(AtomicWrite)•Redolog优化(Redologoptimization)大容量Flash存储(UltraCapacityFlashStorage)•常规方案:–HBA–软RAID•缺点–不支持Flash存储设备的高级特性,比如Trim,S.M.A.R.T信息等.–性能损耗–容错性差,风险高,如意外掉电数据安全性问题,连续故障等.大容量Flash存储(HugeCapacityFlashStorage)•轮转式校验数据存储,最多可有一个SSD故障•由于没有校验数据缓存,数据的随机写入会导致:–在系统层面,写放大系数一定大于2(过大).–更快速的寿命损耗.–会出现”写洞”现象,影响数据一致性.6RAID5处理随机数据写入的步骤•4K随机写第一步:写入待写数据7当磁盘A被数据填满时,会发生写放大现象RAID5处理随机数据写入的步骤•4K随机写第二步:读取原校验数据8RAID5处理随机数据写入的步骤•4K随机写第三步:计算出新的校验数据9RandomwritesinRAID-5•4K随机写第四步:更新校验数据10大容量Flash存储(HugeCapacityFlashStorage)•由于RMW(read-modify-write),RCW(read-reconstruct-write)导致了物理双写,使整个Array的WAF(写放大因子)远远大于2•在RMW,RCW过程中如果系统出现其他故障可导致交验数据更新不成功,WriteHole(写洞)现象产生,带来数据一致性问题.大容量Flash存储(HugeCapacityFlashStorage)•随机写性能不是随着阵列中的磁盘数量线性增长.128盘(RAID-5)vs4盘(RAID-5)PCIe-RAIDPCIe-RAID•目的:–满足应用程序的大容量需求–避免单点故障(硬件故障,多发性Flash芯片失效,主控失效等.)–解决传统的RAID5阵列写性能极差的问题–解决传统的闪存盘阵列会有很大的写放大现象.–解决传统SSD硬盘性能稳定性和性能一致性不足的问题•目标:在系统中提供一个集大容量,高性能和高可靠性的逻辑块设备.PCIe-RAID•技术关键点:–软件FTL层–跨设备FTL层–基于PBA的RAID–采用2维RAID,以达到最大的保护效果PCIe-RAID•Host-Based将FTL的实现从Flash存储设备中移至主机•统一FTL和RAID层,可以解决传统RAID存在的诸多问题16ConventionalRAID5ofSSDsThenewRAID5architecturePCIe-RAID•2维RAID,最大化数据保护DemoPCIe-RAID•性能(保守):•4KRW30W+IOPS•4KRR50W+IOPS•延迟:R:80us/W:15us•冗余度/维护:•PCIeRAID5允许一个PCIeFlash设备彻底失效.•未来有可能支持RAID10•PCIe接口支持热备设备,8639接口支持热插拔,热维护.•综合OP可以最多释放到15%以下,更大的用户空间PCIe-RAID•高密度–2U服务器,最多可以部署6张全高的PCI-E板卡,如HPDL380Gen9–~50TB裸容量,最高40TB的用户可用容量–3U服务器,最多可以部署11张全高的PCI-E板卡,如SupermicroGenX9DRX+-F–~90TB裸容量,最高80TB的用户可用容量PCIe-RAID•优势:–大容量,高性能–全局垃圾回收GC和磨损均衡(WL)–基于PBA的RAID构建实现,RAID5的全局写放大系数远远小于2,更高的Flash寿命–避免RMW/RCW–避免传统RAID5所带来的性能损耗.–Host-Base的UniFTL可以感知校验数据状态,避免”写洞”(WriteHole)21原子写(AtomicWrite)•原子操作:读/写•Page和Buffer.•FlashPage:Flash的原子读取,写入单位,多以4K为例,但是在现代Flash产品中实际多为16KB/32KB.•InnoDBPage:是InnoDB的原子读取,写入单位.一般为16KB.•PCIeFlashWriteBuffer(以Direct-IO产品为例):主控中的SRAM,3组,每组32KB.•InnoDBDoubleWritebuffer:主机内存中的空间,用来存储DoubleWrite数据,2MB原子写(AtomicWrite)•传统硬件和操作系统不能保证InnoDBPage写入这一操作的原子性•InnoDB使用Doublewrite这个特性来避免InnoDBPage写入不完整的问题.•DoubleWrite缺点:•数据写入量加倍(BadForFlash)•增加了写入负载(不是2倍)Doublewritebuffer(2MB)Doublewrite(1MB)Doublewrite(1MB)共享表空间PagePagecopy数据文件(.ibd)writewriterecovery原子写(AtomicWrite)Anandblock•InnoDBPageSize:16KB•FlashPageSize:32KB•对NANDFlash闪存的页进的行读写操作都是原子操作.•如果我们确保将每个InnoDBPage一次性的写入一个FlashPage(InnoDBPageSize=FlashPageSize),那么InnoDBPage写入就是原子操作.•保证InnoDBPage数据存储不跨FlashPage.FlashPage•Direct-IO产品中原子写的实现•InnoDBPageSize16KB•InnoDBWriteRequestSize16KB(多数情况)•Flash(主控)WriteBufferSize32KB*3•FlashPageSize32KB原子写(AtomicWrite)InnoDBPage16KWriteRequest16KWriteBuffer32KWriteRequest16KFlashPage32KflushAtomic原子写(AtomicWrite)•当RequestSize=FlashWriteBuffer(32KB)时•FlashWriteBuffer为空时•所有数据先入WriteBuffer,再刷入FlashPage.•在突然断电时,只有完全写入了FlashWriteBuffer的BIO(blockio)Request会被刷入NAND闪存的页•没有完全被写入FlashWriteBuffer的bio(blockio)会被丢弃.•保证小于32KB(InnoDBPage16K)写入操作的原子性.FlushonpowercutNandpageWritebufferbiobio原子写(AtomicWrite)•如果FlashWriteBuffer是HalfFull的.•WriteRequestSize=FreeSpaceofFlashWriteBuffer•同上•WriteRequestSizeFreeSpaceofFlashWriteBuffer•将本组WriteBuffer剩余空间用垃圾数据填充,新开一组WriteBuffer来承接这个新的WriteRequest.FlushonpowercutNandpageWritebufferbiobiobio原子写(AtomicWrite)•有时连续的写请求会被合并为一个大BIO(BlockIO)•WriteRequestFlashPageSize32K•数据会不经过WriteBuffer被直接写入一个新的FlashPage(延迟稍高).Writebufferbiobio原子写(AtomicWrite)•应用原子写的条件•WriteRequestSize=WriteBufferSize32KB•16KB=32KB√•不要在MySQL/InnoDB/文件系统/块设备层面,分割/合并任何BIO•O_DIRECT,DoubleWrite=0√•FlashFTL可感知BIO的相关信息,Host-BaseFlashOnly.•Shannon或Fusion-IO(SanDisk)√原子写(AtomicWrite)•应用原子写的效益–DoubleWrite=0–性能提升TPS~10%(ShannonSystemsLab)–延迟降低~50%(ShannonSystemsLab)–Flash存储产品的寿命200%,可靠性增强.ShannonvsFusion-IO1,必须要使用DFS2,使用特殊API(PatchedApp).1,可以在任何文件系统中被使用.2,与现有文件系统使用相同的API.Fusion-IOShannonRedoLog优化(Redologoptimization)•InnoDB具有先写日志特性.redolog落地后,就认为数据库完整.•redolog:写入单位512Byte,顺序写.•FlashStorage(以Direct-IO产品为例)•WriteBuffer:32KB*3•Direct-IO主控:2DataPipelines•每个DataPipeline独占一组WriteBuffer32KB•2个Pipelines共享最后一组WriteBuffer,抢占,锁•数据入WriteBuffer,向上汇报写入完成,后台FlushDatatoNand,掉电保护由硬件完成.RedoLog优化(Redologoptimization)•我们能做什么?•如果我们预留一组Pipeline和WriteBuffer.专门处理redolog•在Driver中调高此种BIO的优先级.•期望收益:性能提升•问题:•如何将redolog的IO请求,与其他的IO请求进行区分?•如何让Driver感知特殊类型的IO?RedoLog优化(Redologoptimization)•解决方法:•在应用/FS层对redolog的IO请求加入特殊的Flag,用来识别这种特殊IO请求.•PatchMySQL/InnoDB•PatchFS/EXT4RedoLog优化(Redologoptimization)•Flag的选择•Linux系统中所有的io请求都会用summit_bio()来进行下发•bio(bio_request)是在linux/bio.h中定义的结构体.RedoLog优化(Redologoptimization)•bio数据结构structbio{sector_tbi_sector;/*associatedsectorondisk*/structbio*bi_next;/*listofrequests*/structblock_device*bi_bdev;/*associatedblockdevice*/unsignedlongbi_flags;/*statusandcommandflags*/unsignedlongbi_rw;/*readorwrite?*/unsignedshortbi_vcnt;/*numberofbio_vecsoff*/unsignedshortbi_idx;/*currentindexinbi_io_vec*/unsignedshortbi_phys_segments;/*numberofsegmentsaftercoalescing*/unsig