Keynote Presentation: How Storage Function Follows Architecture
Presented by Howard Marks, Founder and Chief Scientist, Deep Storage, LLC
Storage buyers today are faced with a broader variety of choices than ever before. Unfortunately, the architecture of the storage system they select will forever determine how well that system adapts to changes in their data center. While flash does make almost every storage system faster, the system's scalability, flexibility and manageability are determined not by the media but by the system's architecture.
This session will examine how storage system architectures predetermine how systems behave in the real world. We'll see how common storage architectures affect performance, scalability, quality of service, snapshots and vVol support.
2. • 30 years of consulting and
writing for trade press
– Now at NetworkComputing.com
• Chief Scientist DeepStorage, LLC.
– Independent test lab and analysts
• Co-Host Greybeards on Storage
podcast
Twitter:@DeepStorageNet
Email: Hmarks@deepstorage.net
Your not so Humble Speaker
3. Our Agenda
• A word on storage performance metrics
• A review of 20th century storage
• The changing demands of the modern data center
• 21st century storage requirements
• A survey of storage system architectures
4. We Live In Interesting Storage Times
• Users today have more storage choices than ever before
– Flash based storage systems for performance
– Many more viable vendors
• Expanding storage protocols
– Object and cloud storage
• Tightening integration with hypervisors
– VMware’s vVols
– Openstack Cinder
5. Understanding Storage Performance Metrics
• Latency
– Time to complete each request
– Really determines application performance
• Especially for chained I/Os
• IOPS (Input Output Operations Per Second)
– Measures aggregate work
– Meaningless without
• I/O size
• Latency
6. 20th Century Storage
• Servers own array LUNs
• Performance managed by spindle count
– 10K IOPS = 50 15K RPM drives
• 15TB if you need it or not
– Independent spindles isolate performance
• Array can optimize per application
• Dual controllers manage many disks
– Typically 100s to 1000
Controller
A Controller
B
7. 21st Century Data Centers Are Different
• Systems are different
– Hypervisors create the I/O blender
• Processes are different
– Applications come online in weeks not months
– Self service private cloud obscures applications
from IT
– Devops drives automation and APIs
8. “The I/O Blender” Strains Storage
• MultipleVMs share a datastore
• Virtualization throws I/O into a
blender… all I/O is now
random I/O!
– Multiple servers doing sequential I/O
multiplexed together
– Storage array can’t tell which is which
• Breaking read-ahead,other cache
management
9. So What Do We Need From StorageToday?
• Low cost snapshots and clones
• Consistently high performance
– With highly variable mixed workloads
• Efficient use of media
– Smart snapshots and clones, thin provisioning
– Data reduction
• Manageability
– Cinder, vVols,APIs
10. Storage Quality of Service
Quieting the Noisy Neighbor
• Some applications are more equal than others
• Storage allocates resources by policy not application demand
• Implementations include:
– Throttles – Limit workload to x IOPS
– Limits, minimums and/or bursts
– Prioritization
• Bronze, silver, gold
• Only really works at theVM/VMDK level
– Datastores are just smaller neighborhoods
Modern Infrastructure Seminar |
11. VMware’s vVols
• It’s like software defined networking
– VASA provider is out of band control plane
• SPBM (Storage Policy Based Management) simplifies
management
• Storage provides per-VMDK data services
– EachVMDK a µLUN
– Provides context for read-ahead etc.
• Implementations vary substantially
12. Per-VM Services
• In many ways data layout is destiny
• Log and metadata now table stakes
– Easy on flash
– Snapshots/clones are metadata – Low Impact
• Snapshots can be application consistent
– No timing issues quiescing multiple applications
– Good snapshots open new applications
• Backup replacement, Etc.
The Log
Incoming
Data
Storage
13. • Deduplication identifies duplicate blocks and
stores once
– Inline required for primary storage
• Post process makes capacity planning impossible
– Requires CPU and memory for hash tables
• Compression less computationally expensive
• Deduplication on spinning disk creates read
bottlenecks
Data Reduction for Efficiency
15. Updated Scale-Up Storage
• Vendors claim flash will fix everything
– SSDs do add performance
– But they’re not just faster disks
• Limited write endurance
– Standard RAID creates write amplification
• Data layout is destiny
– Older systems have limited metadata
• Creating large page sizes
• Limits snapshots & clones
• Inevitably bottlenecks at the controllers
15
Controller
A Controller
B
16. Scale-Out Storage
• Adds processing power with capacity
– Giving broader range of scale
• Typically 10-50X vs 2-10X for scale-up
• Should allow node add and evict online
– Eliminating data migration for upgrades
• Usually supports IP storage
17. Shared Nothing Scale-Out
• Each node contributes storage
• Data replicated across nodes
• Must reserve 1 node capacity as
spare
• For rebuild after node failure
– Nodes typically std servers
– Small step function for expansion
EST
EST
EST
EST
EST
EST
18. Shared Storage Scale-Out
• Nodes share storage media like
scale-up arrays
• RAID can be more media
efficient
• Bigger step function for scaling
• Typically proprietary hardware
12UUID
RESET
12UUID
RESET
12UUID
RESET
12UUID
RESET
12UUID
RESET
12UUID
RESET
19. Hyperconverged Infrastructure
• Storage management inVM or Hypervisor kernel process
– Pools SSD & HDD across multiple servers
– Shared nothing, scale-out storage
• Integrated hypervisor/storage management
• But:
– Storage software can be expensive
– CPU cycles on hypervisor costly
– Reduces VM density to run storage
20. • HCI not as attractive at scale
– 20 servers and storage cost less than
– 24 servers with HCI
– vVols make external storage easier
• Virtualization admins may not be paranoid enough
21. Modern Data Centers Need Modern Storage
• Flash optimized is just a start
• Data layout determines services like snaps
• Scale-up systems bottleneck at the controller
• Private cloud, Devops drive:
– Need for QoS
– APIs, including scripting and REST
• Scale-out makes upgrades, expansion eaiser
– Ending the buy the system full syndrome