OpenStack Block Storage 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 Colorado. Former PTL for the OpenStack Block Storage Project (Cinder) and member of the OpenStack Technical Committee

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?

What do you mean when you say Storage?

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

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

Let’s talk Cinder!

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.

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

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

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)

Look at a deployment

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

Only Slightly Different

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

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

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

Thoughts for those building OpenStack Clouds

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!

A few words from our sponsor...

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

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.

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.

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

Demos/Questions?

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

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

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