2. Who is this guy?
John Griffith, Senior Software engineer
at SolidFire Inc based out (soggy) Boulder
Colorado.
Current PTL for the OpenStack Block Storage
Project (Cinder)
3. SolidFire’s Scale-Out Block Storage System
Designed from the start for OpenStack and other cloud platforms
• Multi-Tenant architecture
• Designed for “Cloud-Scale” Deployments
• Linear non-disruptive platform growth
• Automation top priority in API design
• Built to deploy in an OpenStack environment
• Not an afterthought
• Extreme fault tolerance
4. SolidFire &
Cinder
• Full SolidFire driver integration with latest
OpenStack software release
• Set and maintain true QoS levels on a per-
volume basis
• Create, snapshot, clone, extend and
manage SolidFire volumes using
OpenStack clients and APIs
• Run instances on a SolidFire volume
• Web-based API exposing all cluster
functionality
• SolidFire integration with Cinder can be
configured in less than a minute all you
need is network connectivity, everything
else is in OpenStack packages.
5. OpenStack & Storage: Horses for Courses
Cinder / Block Storage Swift / Object Storage
Objectives
• Storage for running VM disk
volumes on a host
• Ideal for performance sensitive apps
• Enables Amazon EBS-like service
• Ideal for cost effective, scale-out storage
• Fully distributed, API-accessible
• Well suited for backup, archiving, data retention
• Enables Dropbox-like service
Use Cases
• Production Applications
• Traditional IT Systems
• Database Driven Apps
• Messaging / Collaboration
• Dev / Test Systems
• VM Templates
• ISO Images
• Disk Volume Snapshots
• Backup / Archive
• Image / Video Repository
Workloads
• High Change Content
• Smaller, Random R/W
• Higher / “Bursty” IO
• Typically More Static Content
• Larger, Sequential R/W
• Lower IOPS
6. How it works • plugin architecture, use your own vendors
backend(s) or use the default
• default implementation built on LVM and iSCSI
• mix and match, add and remove
• back end devices can be invisible to end-user/tenant
• consistent API regardless of backend selection
• filter scheduling to auto place newly create volumes
• or specific placement based on volume-type
selection
• expose differentiating features via custom volume-
types and extra-specs
8. What Cinder
offers, and
differentiators
for backing
device
• dynamic pool of block storage resources
• horizontally scalable
• well defined and easy to use API
• strict adherence to API compatibility regardless of backend
• differentiators between back-ends for admins/service
providers:
• cost
• management
• reliability
• Differentiators for end-users/customers
• performance
• reliability
9. Self Service
Only Please
• idea is for the end user to be able to request
resources on demand
• “give me 100 GB of block storage with XYZ
characteristics please”
• “it’s mine, now what can I do with it”
• attach it, boot it, clone it, back it up
10. Cinder Base Features
● extend volume
● migrate volume
● create/delete volumes
● specify custom "types/extra-specs"
● clone
● copy image to volume and volume to image (boot from volume)
● point in time copy (snapshots of volumes)
● create volume from snapshot
● backup volume (to object store, SWIFT and CEPH)
● transfer volume ownership
● customized scheduling filters
● per tenant usage quotas
11. Vendor Unique Features
• Exposed through custom types or extensions
• Different back-ends for different use cases
• Back-End selected by filter scheduler
• Back-End is setup based on desired capabilities and
characteristics
12. What the admin sets up
● Required:
○ Add some entries to the cinder.conf file
○ Restarts the volume-service
● The above changes will add the back-end, and enable the scheduler to
place volumes
● Based on weighing filters (capacity)
● Can add some more sophistication by creating types/extra-specs for things
like QoS, Thin Provisioning or whatever you like
○ Create volume-type
○ Associate extra-specs with the type including the backend name to
use
14. Creating types and extra-specs
griff@stack-‐1:
cinder
type
create
super
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐+
|
ID
|
Name
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐+
|
c506230f-‐eb08-‐4d4e-‐82e2-‐7a88eb779bda
|
super
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐+
griff@stack-‐1:
cinder
type
create
super-‐dooper
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
|
ID
|
Name
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
|
918cf343-‐1f3d-‐4508-‐bb69-‐cd0e668ae297
|
super-‐dooper
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
griff@stack-‐1:
cinder
type-‐key
super
set
volume_backend_name=LVM_iSCSI
griff@stack-‐1:
cinder
type-‐key
super-‐dooper
set
volume_backend_name=SolidFire
qos:minIOPS=400
qos:maxIOPS=1000
qos:burstIOPS=2000
15. End users perspective
griff@stack-‐1:
cinder
type-‐list
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
|
ID
|
Name
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
|
918cf343-‐1f3d-‐4508-‐bb69-‐cd0e668ae297
|
super-‐dooper
|
|
c506230f-‐eb08-‐4d4e-‐82e2-‐7a88eb779bda
|
super
|
+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+
griff@stack-‐1:
cinder
create
-‐-‐volume-‐type
super-‐dooper
……