OpenStack Storage and Cinder an Interactive Discussion Aaron Delp Director of Solutions OpenStack Architect aarondelp Who is this guy John Griffith Senior Software engineer at SolidFire Inc based out of Boulder ID: 531294
Download Presentation The PPT/PDF document "OpenStack Block Storage" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
OpenStack Block Storage
OpenStack
Storage and Cinder an Interactive Discussion!!!
Aaron Delp, Director of Solutions,
OpenStack
Architect, @
aarondelpSlide2
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 OpenStackTechnical CommitteeSlide3
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?Slide4
What do you mean when you say Storage?Slide5
Ephemeral
Non-Persistent
Life Cycle coincides with an Instance
Usually local FS/QCOW file ObjectManages data as.. well, an ObjectThink photos, mp4’s etcTypically “cheap and deep”Commonly SWIFTShared FSWe all know and love NFSSoon to be Manila
Number of different types of Storage in OpenStack, each serving a different use case
Block
Foundation for the other types
Think raw disk
Typically higher performance
CinderSlide6
Most common question, difference between
Object and Block?
Cinder /
Block StorageSwift / Object StorageObjectivesStorage for running VM disk volumes on a host
Ideal for performance sensitive apps
Enables Amazon
EBS-like serviceIdeal for cost effective, scale-out storage
Fully distributed, API-accessible
Well
suited for
backup,
archiving, data retentionEnables 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 IOPSSlide7
Let’s talk Cinder!Slide8
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.Slide9
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).Slide10Slide11Slide12
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 fancyexpose differentiating features via custom volume-types and extra-specsSlide13
Reference Implementation Included
Includes code to provide a base implementation using LVM
Just add disks
Great for POC and getting startedSometimes good enoughMight be lacking for your performance, H/A and Scaling needs (it all depends)Can Scale by adding NodesCinder-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 eachTypical max size recommendations per VG/Cinder-Volume backend ~ 5 TBNo Redundancy (yet)Slide14
Look at a deploymentSlide15
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-xtremioeqlxglusterfchdsibm-gpfsibm-xiv
lvm
netapp
nexenta
nfs
Ceph RBDHP-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:Slide16
Only Slightly DifferentSlide17
Conf file entries
#Append to /etc/cinder.conf
enabled_backends=lvm,solidfire
[lvm]volume_group=cinder_volumesvolume_driver=cinder.volume.drivers.lvm.LVMISCSIDrivervolume_backend_name=LVM_iSCSI[solidfire]volume_driver=cinder.volume.drivers.solidfire.SolidFiresan_ip=192.168.138.180
san_login=admin
san_password=solidfire
volume_backend_name=SolidFireSlide18
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 ReplicationIntroduced support for Consistency Groups
Continued improvements to Cinder-Backup making way towards incrementalsSlide19
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!!Slide20
Thoughts for those building OpenStack CloudsSlide21
Making choices can be the HARDEST part!
Each has their own merits
Some excel at specific use cases
Maybe you already own the gearTCO, TCO, TCOAsk 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….)Slide22
A few words from our sponsor...Slide23
SolidFire’s Scale-Out Block Storage System
Designed from the start for OpenStack and other cloud platforms
Multi-Tenant architecture
Designed for “Cloud-Scale” DeploymentsLinear non-disruptive platform growth
Automation top priority in API design
Built to deploy in an OpenStack environment
Not an afterthought
Extreme fault toleranceSlide24
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 isolationSlide25
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.Slide26
Related Resources
OpenStack
Solution Page
OpenStack Solution BriefSolidFire/Cinder Reference ArchitectureOpenStack 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 MattersSlide27
Demos/Questions?Slide28
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
=2000Slide29
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 ……Slide30
How to get involved?
It’s Easy, Start Here
https://wiki.openstack.org/wiki/How_To_Contribute
Any questions?Aaron.delp@solidfire.com
@aarondelpSlide31