OpenStack Block Storage (Cinder) provides on-demand, self-service access to block storage resources through abstraction and automation of backend storage devices. Cinder uses a plugin architecture that supports various storage backends like LVM, SolidFire, EMC, etc. It allows users to dynamically create, attach, and detach disk volumes to Nova instances. The presentation discusses Cinder's architecture, common storage types, and demos creating volume types and extra specs to control which backend is used.

1. OpenStack Block Storage
OpenStack Storage and Cinder an Interactive
Discussion!!!
Aaron Delp, Director of Solutions
OpenStack Architect, @aarondelp

2. Quick Poll:
● How many of you are end-users of OpenStack?
● How many of you are OpenStack Operators?
● How many of you contribute to OpenStack?
● How many of you work for Vendor Organizations that contribute to OpenStack?
● How many are “all of the above”?
● How many just heard there was free Pizza?

3. What do you mean when you say Storage?

4. ● Ephemeral
● Non-Persistent
● Life Cycle coincides with an Instance
● Usually local FS/QCOW file
● Object
● Manages data as.. well, an Object
● Think photos, mp4’s etc
● Typically “cheap and deep”
● Commonly SWIFT
● Shared FS
● We all know and love NFS
● Soon to be Manila
Number of different types of Storage in OpenStack, each serving a different use case
● Ceph
● Block
● Foundation for the other types
● Think raw disk
● Typically higher performance
● Cinder

5. Most common question, difference between
Object and Block?
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. Let’s talk Cinder!

7. Cinder Mission Statement
To implement services and libraries to provide on demand, self-service
access to Block Storage resources. Provide Software Defined Block
Storage via abstraction and automation on top of various traditional
backend block storage devices.
To put it another way...
Virtualize various Block Storage devices and abstract them in to an
easy self serve offering to allow end users to allocated and deploy
storage resources on their own quickly and efficiently.

8. Huh?
So it’s simply allowing you to dynamically create/attach/detach disks to your
Nova Instance. Those are the basics, much more advanced capabilities
(see demo/questions section).

11. How it works
● Plugin architecture, use your own vendors
backend(s) or use the default
●Backend devices invisible to end-user
● Consistent API regardless of backend
● Filter Scheduler let’s you get get fancy
● expose differentiating features via custom
volume-types and extra-specs

12. Reference Implementation Included
● Includes code to provide a base implementation using LVM
● Just add disks
● Great for POC and getting started
● Sometimes good enough
● Might be lacking for your performance, H/A and Scaling needs (it all depends)
● Can Scale by adding Nodes
● Cinder-Volume Node utilizes it’s local disks (allocate by creating an LVM VG)
● Cinder Volumes are LVM Logical Volumes, with an iSCSI target created for each
➔ Typical max size recommendations per VG/Cinder-Volume backend ~ 5 TB
➔ No Redundancy (yet)

13. Look at a deployment

14. Sometimes LVM Isn’t Enough
* datera
* fujitsu_eternus
* fusionio
* hitachi-hbsd
* hauwei
* nimble
* prophetstor
* pure
* zfssa
* New as of Juno Release
coraid
emc-vmax
emc-xtremio
eqlx
glusterfc
hds
ibm-gpfs
ibm-xiv
lvm
netapp
nexenta
nfs
Ceph RBD
HP-3Par
HP-LeftHand
scality
sheepdog
smbfs
solidfire
vmware-vmdk
window-hyperv
zadara
Plugin Architecture gives you choices (maybe too many) and you can mix them together:

15. Only Slightly Different

16. Conf file entries
#Append to /etc/cinder.conf
enabled_backends=lvm,solidfire
[lvm]
volume_group=cinder_volumes
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[solidfire]
volume_driver=cinder.volume.drivers.solidfire.SolidFire
san_ip=192.168.138.180
san_login=admin
san_password=solidfire
volume_backend_name=SolidFire

17. Speaking of Juno!!!
● Just wrapped up the fifth release of Cinder!!!!
● Major emphasis on testing and compatibility
● Running Third Party CI on Vendors gear in their own labs against each Cinder commit
● Manage/Unmanage (or Import/Export) of Volumes widely available
★ Introduced support for Pools for those devices that still have that concept
★ Introduced support for Replication
★ Introduced support for Consistency Groups
★ Continued improvements to Cinder-Backup making way towards incrementals

18. Preview for Kilo
★ It’s all about QUALITY
★ Technical debt
★ De-emphasizing new features (ie finish the ones we have and make them rock solid)
★ Redundancy for base LVM implementation
★ Rolling Upgrades!!

19. Thoughts for those building OpenStack Clouds

20. Making choices
can be the
HARDEST part!
● Each has their own merits
● Some excel at specific use cases
● Maybe you already own the gear
● TCO, TCO, TCO
Ask yourself:
➔ Does it scale?
➔ Is the architecture a good fit?
➔ Is it tested, will it really work in OpenStack?
➔ Support?
➔ What about performance and noisy neighbors?
➔ Third party CI testing?
➔ Active in the OpenStack Community?
➔ DIY, Services, both/neither (SolidFire AI, Fuel, JuJu,
Nebula….)

21. A few words from our sponsor...

22. 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

23. SolidFire &
OpenStack
 SolidFire led the creation of Cinder (break out from Nova)
 Founding Cinder PTL (2.5 years)
 OpenStack Technical Committee Member
 Full SolidFire driver integration with latest OpenStack release
 Set and maintain true QoS levels on a per-volume basis
 Create, snapshot, clone and manage SolidFire volumes using
OpenStack clients and APIs
 Bootable SolidFire Volumes
 Web-based API exposing all cluster functionality
 SolidFire integration with OpenStack Cinder can be configured in
less than a minute
 Seamless scaling after initial configuration
 Full multi-tenant isolation

24. Related
Resources
● OpenStack Solution Page
● OpenStack Solution Brief
● SolidFire/Cinder Reference Architecture
● OpenStack Configuration Guide
● SolidFire/Rackspace Private Cloud
Implementation Guide
● Video: Configuring OpenStack Block Storage
w/SolidFire
● Blogs
● OpenStack Summit Recap: Mindshare
Achieved, Market Share Must Follow
● Separating from the Pack
● Why OpenStack Matters

25. Demos/Questions?

26. 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

27. 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 ……

28. How to get
involved?
● It’s Easy, Start Here
● https://wiki.openstack.org/wiki/How_To_Contrib
ute
● Any questions?
● Aaron.delp@solidfire.com
● @aarondelp

29. 1620 Pearl Street,
Boulder, Colorado 80302
Phone: 720.523.3278
Email: info@solidfire.com
www.solidfire.com