Towards Application Driven Storage Optimizing RocksDB for - PowerPoint PPT Presentation

Towards ¡Application ¡Driven ¡Storage Optimizing ¡RocksDB ¡for ¡Open-­‑Channel ¡SSDs Javier ¡González ¡<javier@cnexlabs.com> LinuxCon ¡Europe ¡2015 Contributors: ¡Matias ¡Bjørling ¡and ¡Florin ¡Petriuc 1

Application ¡Driven ¡Storage: ¡What ¡is ¡it? RocksDB App-­‑specific ¡opt. User ¡Space Standard ¡Libraries Kernel ¡Space Metadata ¡Mgmt. FS-­‑specific ¡logic Page ¡cache Block ¡I/O ¡interface 2

Application ¡Driven ¡Storage: ¡What ¡is ¡it? • Application ¡Driven ¡Storage ¡ RocksDB - Avoid ¡multiple ¡(redundant) ¡ translation ¡layers ¡ ¡ - Leverage ¡optimization ¡ App-­‑specific ¡opt. User ¡Space opportunities ¡ ¡ Standard ¡Libraries - Minimize ¡overhead ¡when ¡ Kernel ¡Space Metadata ¡Mgmt. manipulating ¡persistent ¡data ¡ FS-­‑specific ¡logic - Make ¡better ¡decisions ¡regarding ¡ latency, ¡resource ¡utilization, ¡and ¡ Page ¡cache data ¡movement ¡(compared ¡to ¡ Block ¡I/O ¡interface best-­‑effort ¡techniques ¡today) Generic ¡<> ¡Optimized ➡ Motivation: ¡Give ¡the ¡tools ¡to ¡the ¡applications ¡ that ¡know ¡how ¡to ¡manage ¡their ¡own ¡storage 3

Application ¡Driven ¡Storage ¡Today • Arrakis ¡ (https://arrakis.cs.washington.edu) ¡ - Remove ¡the ¡OS ¡kernel ¡entirely ¡from ¡normal ¡application ¡execution ¡ • Samsung ¡multi ¡stream ¡ - Let ¡the ¡SSD ¡know ¡from ¡where ¡“I/O ¡streams” ¡emerge ¡to ¡make ¡better ¡ decisions ¡ • Fusion ¡I/O ¡ - Dedicated ¡I/O ¡stack ¡to ¡support ¡a ¡specific ¡type ¡of ¡hardware ¡ • Open-­‑Channel ¡SSDs ¡ - Expose ¡SSD ¡characteristics ¡to ¡the ¡host ¡and ¡give ¡it ¡full ¡control ¡over ¡its ¡ storage 4

Traditional ¡Solid ¡State ¡Drives High ¡throughput ¡+ ¡Low ¡latency Parallelism ¡+ ¡Controller • Flash ¡complexity ¡is ¡abstracted ¡away ¡form ¡the ¡host ¡by ¡an ¡ embedded ¡Flash ¡Translation ¡Layer ¡(FTL) ¡ - Maps ¡logical ¡addresses ¡(LBAs) ¡to ¡physical ¡addresses ¡(PPAs) ¡ - Deals ¡with ¡flash ¡constrains ¡(next ¡slide) ¡ - Has ¡enabled ¡adoption ¡by ¡making ¡SSDs ¡compliant ¡with ¡the ¡existing ¡I/O ¡stack 5

Flash ¡memory ¡101 • Flash ¡constrains: ¡ - Write ¡at ¡a ¡page ¡granularity ¡ • Page ¡state: ¡Valid, ¡invalid, ¡erased ¡ - Write ¡sequentially ¡in ¡a ¡block ¡ Page 0 Data OOB State Page 1 - Write ¡always ¡to ¡an ¡erased ¡page ¡ Page 2 • Page ¡becomes ¡valid ¡ … - Updates ¡are ¡written ¡to ¡a ¡new ¡page ¡ • Old ¡pages ¡become ¡invalid ¡-­‑ ¡need ¡for ¡GC ¡ - Read ¡at ¡a ¡page ¡granularity ¡(seq./random ¡reads) ¡ - Erase ¡at ¡a ¡block ¡granularity ¡(all ¡pages ¡in ¡block) ¡ • Garbage ¡collection ¡(GC): ¡ Page n -1 Move ¡valid ¡pages ¡to ¡new ¡block ¡ • Erase ¡valid ¡and ¡invalid ¡pages ¡-­‑> ¡erased ¡state • 6

Open-­‑Channel ¡SSDs: ¡Overview • Open ¡Channel ¡SSDs ¡share ¡control ¡responsibilities ¡with ¡the ¡Host ¡ in ¡order ¡to ¡implement ¡and ¡maintain ¡features ¡that ¡typical ¡SSDs ¡ implemented ¡strictly ¡in ¡the ¡SSD ¡device ¡firmware • Host-­‑based ¡FTL ¡manages: ¡ Data ¡placement ¡ - Physical flash exposed to the - I/O ¡scheduling ¡ host (Read, Write, Erase) Over-­‑provisioning ¡ - Garbage ¡collection ¡ - - Wear-­‑leveling ¡ • Host ¡needs ¡to ¡know: ¡ - SSD ¡features ¡& ¡responsibilities ¡ SSD ¡geometry ¡ - • NAND ¡media ¡idiosyncrasies ¡ • Die ¡geometry ¡(blocks ¡& ¡pages) ¡ • Channels, ¡timings, ¡etc. ¡ • Bad ¡blocks ¡& ¡ECC Host ¡manages ¡physical ¡flash Application ¡Driven ¡Storage 7

Open-­‑Channel ¡SSDs: ¡LightNVM • Targets ¡ User-space - Expose ¡physical ¡media ¡to ¡user-­‑ space ¡ Kernel • Block ¡Managers ¡ Key-Value/Object/FS/ File-System Block/etc. Manage ¡physical ¡SSD ¡ - characteristics ¡ LightNVM ¡Framework Software Block Target Vendor-Specific Target Direct Flash Target Evens ¡out ¡wear-­‑leveling ¡across ¡ - all ¡flash ¡ Managed ¡Geometry Block Manager (Generic, Vendor-specific, ...) • Open-­‑Channel ¡SSD ¡ Raw ¡NAND ¡Geometry - Responsibility ¡ - Offload ¡engines ¡ Hardware Open-Channel SSDs (NVMe, PCI-e, RapidIO, ...) Block Copy Metadata State Bad Block State Error Handling Engine Mgmt. Mgmt. XOR Engine ECC Engine GC Engine Etc. 8

LightNVM’s ¡DFlash: ¡Application ¡FTL Applica:on Data,placement Applica@on,Logic sync I/O,scheduling psync OverEprovisioning FTL libaio Provisioning,buffer Garbage,collection posixaio … Block0 Block1 BlockN WearEleveling … struct ¡vblock ¡{ ¡ ¡ ¡uint64_t ¡id; ¡ get_block(),/, USER*SPACE Normal,I/O ¡ ¡uint64_t ¡owner_id; ¡ put_block(),/ blockNE>bppa,*,PAGE_SIZE ¡ ¡uint64_t ¡nppas; ¡ erase_block() ¡ ¡uint64_t ¡ppa_bitmap ¡ Block,device ¡ ¡sector_t ¡bppa; ¡ Provisioning,interface struct&nvm_tgt_type&/_dflash&=&{ ¡ ¡uint32_t ¡vlun_id; ¡ ¡ ¡ &&[…] ¡ ¡uint8_t ¡flags ¡ KERNEL*SPACE &&.make_rq&&&&&&=&df_make_rq, DFlash*Target }; &&.&end_io&&&&&&&&=&df_end_io, &&[…] Block*Manager … }; vblock Managed,Flash … type%1 ,,E,Exploit,parallelism vblock … type%2 … ,,E,Serve,applica@on,needs vblock type%3 Open%Channel*SSD Lun0 LunN … CH0 Physical,Flash,Layout … CH1 ,,E,NAND,E,specific … ,,E,Managed,by,controller … CHN ➡ DFlash ¡is ¡the ¡LightNVM ¡target ¡supporting ¡application ¡FTLs 9

Open-­‑Channel ¡SSDs: ¡Challenges 1. Which ¡classes ¡of ¡applications ¡would ¡benefit ¡most ¡from ¡being ¡ able ¡to ¡manage ¡physical ¡flash? ¡ - Modify ¡storage ¡backend ¡(i.e., ¡no ¡posix) ¡ - Probably ¡no ¡file ¡system, ¡page ¡cache, ¡block ¡I/O ¡interface, ¡etc. ¡ 2. Which ¡changes ¡do ¡we ¡need ¡to ¡make ¡on ¡these ¡applications? ¡ - Make ¡them ¡work ¡on ¡Open-­‑Channel ¡SSDs ¡ - Optimize ¡them ¡to ¡take ¡advantage ¡of ¡directly ¡using ¡physical ¡flash ¡(e.g., ¡data ¡ structures, ¡file ¡abstractions, ¡algorithms). ¡ 3. Which ¡interfaces ¡would ¡(i) ¡make ¡the ¡transition ¡simpler, ¡and ¡(ii) ¡ simultaneously ¡cover ¡different ¡classes ¡of ¡applications? ➡ New ¡paradigm ¡that ¡we ¡need ¡to ¡explore ¡in ¡the ¡whole ¡I/O ¡stack 10

RocksDB: ¡Overview • Embedded ¡Key-­‑Value ¡persistent ¡store ¡ • Based ¡on ¡Log-­‑Structured ¡Merge ¡Tree ¡ • Optimized ¡for ¡fast ¡storage ¡ • Server ¡workloads ¡ ¡ • Fork ¡from ¡LevelDB ¡ • Open ¡Source: ¡ ¡ - https://github.com/facebook/rocksdb ¡ • RocksDB ¡is ¡not: ¡ The ¡Log-­‑Structured ¡Merge-­‑Tree, ¡Patrick ¡ O'Neil, ¡Edward ¡Cheng ¡ Dieter ¡Gawlick, ¡Elizabeth ¡O’Neil. ¡ Acta ¡Informatica, ¡1996. - Not ¡distributed ¡ - No ¡failover ¡ - Not ¡highly ¡available RocksDB ¡Reference : ¡The ¡Story ¡of ¡RocksDB, ¡ Dhruba ¡Borthakur ¡and ¡Haobo ¡Xu ¡ (link) 11

RocksDB: ¡Overview Active Write ¡Request Log MemTable Switch Switch ReadOnly Log Read ¡Request MemTable LSM sst sst sst Flush Compaction Blooms sst sst sst 12

Problem: ¡RocksDB ¡Storage ¡Backend ¡ • Storage ¡backend ¡decoupled ¡from ¡LSM ¡ - WritableFile(): ¡Sequential ¡writes ¡-­‑> ¡Only ¡way ¡to ¡write ¡to ¡ RocksDB LSM secondary ¡storage ¡ SequentialFile() ¡-­‑> ¡Sequential ¡reads. ¡Used ¡primarily ¡for ¡ - sstable ¡user ¡data ¡and ¡recovery ¡ Posix HDFS Win RandomAccessFile() ¡-­‑> ¡Random ¡reads. ¡Used ¡primarily ¡for ¡ - metadata ¡(e.g., ¡CRC ¡checks) - Sstable: ¡Persistent ¡memtable ¡ LSM Logic - DB ¡Log: ¡Write-­‑Ahead ¡Log ¡(WAL) ¡ - MANIFEST: ¡File ¡metadata ¡ Storage Backend - IDENTITY: ¡ Instance ¡ID ¡ User Data DB Log Metadata Other Current LOCK IDENTITY LOG (Info) - LOCK: ¡ use_existing_db ¡ sst sst sst WAL - CURRENT: ¡Superblock ¡ ¡ sst sst sst Manifest Manifest … Manifest … WAL WAL WAL - Info ¡Log: ¡Log ¡& ¡Debugging 13