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

2. Who is this guy? John Griffith, Senior Software engineer
at SolidFire Inc based out of Boulder
Colorado.
Former PTL for the OpenStack Block Storage
Project (Cinder) and member of the OpenStack
Technical Committee

3. 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?

4. What do you mean when you say Storage?

5. Number of different types of Storage in OpenStack, each serving a different use case
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
Block
Foundation for the other types
Think raw disk
Typically higher performance
Cinder

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

7. Let’s talk Cinder!

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

9. 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).

12. 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
How it works

13. 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)

14. Look at a deployment

15. Sometimes LVM Isn’t Enough
Plugin Architecture gives you choices (maybe too many) and you can mix them together:
* 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

16. Only Slightly Different

17. 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=
san_login=admin
san_password=solidfire
volume_backend_name=SolidFire

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

19. 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!!

20. Thoughts for those building OpenStack Clouds

21. 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….)
Making choices can be the HARDEST part!

22. A few words from our sponsor...

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

24. 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
SolidFire & OpenStack
Let’s move on to specific cloud orchestration projects. First up we have OpenStack. SolidFire has created a driver for OpenStack Cinder (the block storage project). This driver fully supports ALL the base Cinder requirements and is completely functional to Cinder specs. In addition, we have added a number of features to better integrate OpenStack with SolidFire storage. Specifically, we added SF QoS integration, multi-tenancy, bootable volumes, as well as cloning and snapshot offloading.

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

26. Related Resources OpenStack Solution Page Blogs
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

27. Demos/Questions?

28. Creating types and extra-specs
cinder type create super
| ID | Name |
| c506230f-eb08-4d4e-82e2-7a88eb779bda | super |
cinder type create super-dooper
| ID | Name |
| 918cf343-1f3d-4508-bb69-cd0e668ae297 | super-dooper |
cinder type-key super set volume_backend_name=LVM_iSCSI
cinder type-key super-dooper set volume_backend_name=SolidFire \ qos:minIOPS=400 qos:maxIOPS=1000 qos:burstIOPS=2000

29. End users perspective griff@stack-1: cinder type-list
| ID | Name |
| 918cf343-1f3d-4508-bb69-cd0e668ae297 | super-dooper |
| c506230f-eb08-4d4e-82e2-7a88eb779bda | super |
cinder create --volume-type super-dooper ……

30. How to get involved? It’s Easy, Start Here Any questions?
ute
Any questions?
@aarondelp