1 / 40

Migrating Server Storage to SSDs: Analysis of Tradeoffs

Migrating Server Storage to SSDs: Analysis of Tradeoffs. Dushyanth Narayanan Eno Thereska Austin Donnelly Sameh Elnikety Antony Rowstron Microsoft Research Cambridge, UK. Solid-state drive (SSD). Block storage interface. Persistent. Flash Translation Layer (FTL). Random-access.

clea
Download Presentation

Migrating Server Storage to SSDs: Analysis of Tradeoffs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Migrating Server Storage to SSDs: Analysis of Tradeoffs Dushyanth Narayanan Eno Thereska Austin Donnelly Sameh Elnikety Antony Rowstron Microsoft Research Cambridge, UK

  2. Solid-state drive (SSD) Block storage interface Persistent Flash Translation Layer (FTL) Random-access NAND Flash memory Low power Cost, Parallelism, FTL complexity USB drive Laptop SSD “Enterprise” SSD

  3. Enterprise storage is different Laptop storage Low speed disks Form factor • Responsiveness • Ruggedness • Battery life Enterprise storage High-end disks, RAID Fault tolerance Throughput under load Capacity Energy ($)

  4. Replacing disks with SSDs Match performance Match capacity Disks $$ Flash $$$$$ Flash $

  5. SSD as intermediate tier? DRAM buffer cache Capacity Performance Read cache + write-ahead log $ $$$$

  6. Other options? • Hybrid drives? • Flash inside the disk can pin hot blocks • Volume-level tier more sensible for enterprise • Modify file system? • We want to plug in SSDs transparently • Replace disks by SSDs • Add SSD tier for caching and/or write logging

  7. Challenge • Given a workload • Which device type, how many, 1 or 2 tiers? • We benchmarked enterprise SSDs, disks • We traced many real enterprise workloads • And built an automated provisioning tool • Takes workload, device models • And computes best configuration for workload

  8. High-level design

  9. Devices (2008)

  10. Characterizing devices • Sequential vs random, read vs write • Some SSDs have slow random writes • Newer SSDs remap internally tosequential • We model both “vanilla” and “remapped” • Multiple capacity versions per device • Different cost/capacity/performance tradeoffs

  11. Device metrics

  12. Enterprise workload traces • I/O traces from live production servers • Exchange server (5000 users): 24 hr trace • MSN back-end file store: 6 hr trace • 13 servers from MSRC DC: 1 week • File servers, web server, web cache, etc. • 15 servers, 49 volumes, 313 disks, 14 TB • Volumes are RAID-1, RAID-10, or RAID-5

  13. Enterprise workload traces • Traces are at volume (block device) level • Below buffer cache, above RAID controller • Timestamp, LBN, size, read/write • Each volume’s trace is a workload • We consider each volume separately

  14. Workload metrics

  15. Workload trace  metrics • Capacity • largest LBN accessed in trace • Performance = peak (or 99th pc) load • Highest observed IOPS of random I/Os • Highest observed transfer rate (MB/s) • Fault tolerance • Same as current (= 1 redundant device)

  16. What is the best config? • Cheapest one that meets requirements • Capacity, perf, fault-tolerance • Re-run/replay trace? • Cannot provision h/w just to ask “what if” • Simulators not always available/reliable • First-order models of device performance • Input is device metrics, workload metrics

  17. Solver • For each workload, device type • Compute #devices needed in RAID array • Throughput, capacity scaled linearly with #devices • To match every workload requirement • “Most costly” workload metric determines #devices • Add devices for fault tolerance • Compute total cost

  18. Two-tier model

  19. Solving for two-tier

  20. Solving for two-tier model • Iterate over cache sizes, policies • Write-back, write-through for logging • LRU, LTR (long-term random) for caching • Inclusive cache model • Can also model exclusive (partitioning) • More complexity, negligible capacity savings

  21. Model assumptions • First-order models • Ok for provisioning  coarse-grained • Not for detailed performance modelling • Open-loop traces • I/O rate not limited by traced storage h/w • Traced volumes are well-provisioned

  22. Roadmap Introduction Devices and workloads Finding the best configuration Analysis results

  23. Single-tier results • Cheetah 10K best device for all workloads! • SSDs cost too much per GB • Capacity or read IOPS determines cost • Not read MB/s, write MB/s, or write IOPS • For SSDs, always capacity • Read IOPS vs. GB is the key tradeoff

  24. Workload IOPS vs GB

  25. When will SSDs win? • When IOPS dominates cost • Break even $/GB for SSD when • Cost of GB (SSD) = Cost of IOPS (disk) • Our tool also computes this point • New SSD  compare its $/GB to break-even • Then decide whether to buy it

  26. Break-even point CDF

  27. Break-even point CDF

  28. Break-even point CDF

  29. Capacity limits SSD • On performance, SSD already beats disk • $/GB too high by 1-3 orders of magnitude • Except for small (system boot) volumes • SSD price has gone down but • This is per-device price, not per-byte price • Raw flash $/GB also needs to drop a lot

  30. SSD as intermediate tier • Read caching of little benefit • Servers already cache in DRAM • Persistent write-ahead log is useful • Can improve write latency with a little flash • But does not reduce disk tier provisioning • Because writes are not the limiting factor

  31. Power and wear • SSDs use less power than Cheetahs • But $ savings << cost difference • Flash wear is not an issue • SSDs have finite #write cycles • But will last well beyond 5 years • Workloads’ long-term write rate not that high • You will upgrade before you wear device out

  32. Conclusion • Capacity limits flash SSD in enterprise • Not performance, not wear • Workload IOPS/GB ratio is key metric • Might never get cheap enough [Hetzler2008] • All Si capacity today = 12% of HDD market • There are more profitable uses of Si capacity • Need higher density technologies (PCM?)

  33. This space intentionally left blank

  34. What are SSDs good for? • Mobile, laptop, desktop • Maybe niche apps for enterprise SSD • Too big for DRAM, small enough for flash • And huge appetite for IOPS • Single-request latency • Power • Fast persistence (write log)

  35. Assumptions that favour flash • IOPS = peak IOPS • Most of the time, load << peak • Faster storage will not help: already underutilized • Disk = enterprise disk • Low power disks have lower $/GB, $/IOPS • LTR caching uses knowledge of future • Looks through entire trace for randomly-accessed blocks

  36. Supply-side analysis [Hetzler2008] • Disks: 14,000 PB/year, fab cost $1B • MLC NAND flash: 390 PB/year, $3.4B • If all Si capacity moved to MLC flash today • Will only match 12% of HDD production • Revenue: $35B HDD, $280B Silicon • No economic incentive to use fabs for flash

  37. Device characteristics

  38. 9 of 49 benefit from caching

  39. Energy savings << SSD cost

  40. Wear-out times

More Related