Openstack Denver Meetup - Intro to Block Storage

OpenStack BlockStorage
Introduction to Cinder
John Griffith, Lead Open Source Developer, john.griffith@solidfire.com, @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

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
•  john.griffith@solidfire.com
•  Partnership
•  mcclain.buggle@solidfire.com
•  Sales
•  sales@solidfire.com

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

Openstack Denver Meetup - Intro to Block Storage

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Destaque

Destaque (12)

Semelhante a Openstack Denver Meetup - Intro to Block Storage

Semelhante a Openstack Denver Meetup - Intro to Block Storage (20)

Último

Último (20)

Openstack Denver Meetup - Intro to Block Storage