Embed Size (px)
DESCRIPTION
Slide set used at the Denver OpenStack meetup on Sept 26 at Fortress
Citation preview
OpenStack BlockStorage Introduction to Cinder John Griffith, Lead Open Source Developer, [email protected], @jdg_8
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)
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 & 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.
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
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
Design View
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
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
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
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
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
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
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 ……
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
How to get involved?
• It’s Easy, Start Here • https://wiki.openstack.org/wiki/
How_To_Contribute
• Any questions? • Technical
• Partnership • [email protected]
• Sales • [email protected]
Demos/Questions?
1620 Pearl Street, Boulder, Colorado 80302 Phone: 720.523.3278 Email: [email protected] www.solidfire.com
