Openstack Denver Meetup - Intro to Block Storage

606 views
463 views

Published on

Slide set used at the Denver OpenStack meetup on Sept 26 at Fortress

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
606
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Openstack Denver Meetup - Intro to Block Storage

  1. 1. OpenStack BlockStorage Introduction to Cinder John Griffith, Lead Open Source Developer, john.griffith@solidfire.com, @jdg_8
  2. 2. 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)
  3. 3. 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
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. Design View
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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  
  14. 14. 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  
  15. 15. 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  ……  
  16. 16. 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
  17. 17. 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
  18. 18. Demos/Questions?
  19. 19. 1620 Pearl Street, Boulder, Colorado 80302 Phone: 720.523.3278 Email: info@solidfire.com www.solidfire.com

×