2. MIKE
PEREZ
senior developer for DreamHost
•Maintain Cinder setup.
•Maintain interactions between
Nova and Cinder.
•Working with 900 Ceph OSD
setup comes out to around 4
petabytes.
•Contribute fixes upstream.
3. MIKE
PEREZ
cinder core developer
•Wrote the start of Cinder
V2 API
•Cinder API documentation
•Cinder API references
•Compatibility hammer
•More code reviews than I
know what to do with
http://www.flickr.com/photos/nooccar/5844185400
4. WHAT
• project exists since Folsom release,
spun off Nova-volume
• cinder manages block storage
• not an object storage
• not a file level storage
• volumes attach to VM Instances
• boot from volume
• volumes have a lifecycle
independent of VM instance
http://www.flickr.com/photos/neilhinchley/294337822/
5. VOLUME
TYPES
•
Admin can create tiers of storage. e.g. two LVM
backends, one with SSD’s and the other with HDD’s.
•Users can specify a tier they want when creating a
volume.
7. CINDER
API
•Volume create/delete/list/show
•Create from image, snapshot
•Snapshot create/delete/list/show
•Backups create/restore/list/delete/show
•Volume attach/detach (called by Nova)
•Manage volume types
•Manage quotas
•Volume extend
•Volume migrate
•Transfer volumes from tenant to tenant
8. CINDER
SCHEDULER
•Chooses which back-end to place a new volume on
•Configurable plugins for schedulers
•Filter scheduler has filters and weighers
•Filter scheduler Flow Example:
•Starts with list of all back-ends
•Filters according to capabilities
•Drivers report capabilities and state (e.g., free space)
•Default filters
•Volume types
•Sorts according to weights e.g., available free space
•Returns best candidate
9. CINDER
VOLUME
•Drivers: Called by Manager, contains back-end-specific code
to communicate with various storage types (e.g., Linux LVM,
storage controllers from various vendors, distributed file
systems, etc.)
•Admin can run multiple cinder-volume instances, each with
its own configuration file describing settings and the storage
back-end
•One cinder-volume instance can manage multiple back-ends
•Each back-end driver is generally configured to interact with
one storage pool
•“Multi-threading”
10. CINDER
BACKUP
•
A backup is an archived copy of a Volume stored in a
object store.
•A backup is just the data that was written, unlike a
snapshot which is the entire block.
•Use Swift, Ceph, or IBM Tivoli Storage Manager
11. ATTACH
THAT
VOLUME
•
Nova calls Cinder via its API, passing connection information.
e.g., host name, iSCSI initiator name, FC WWNNs
•
Cinder API passes message to Cinder Volume.
•
Manager does initial error checking and calls volume driver.
•
Volume driver does any necessary preparation to allow the connection.
e.g., give the nova host permissions to access the volume.
•
Volume driver returns connection information, which is passed to Nova.
e.g., iSCSI iqn and portal, FC WWNN.
•
Nova creates the connection to the storage using the returned information.
•
Nova passes the volume device/file to the hypervisor.
16. ICEHOUSE
BOUND
General Features
•FC SAN Zone / Access Control
management
•State machine
•Volume retype
•Volume Replication
•Multiprocess API
•Disaster recovery
New Drivers:
•Federator Storage
•ProphetStor
•Generic ZFS ISCSI
•HP Lefthand array iSCSI
•HP MSA 2040
17. THANK
YOU!
Web: http://thing.ee
Github: thingee
Twitter: @thingee
IRC: thingee
Email: thingee@gmail.com
•Get started with Cinder:
•https://wiki.openstack.org/wiki/Cinder
•Source Code:
•http://github.com/openstack/cinder
•REST API Docs:
•http://docs.openstack.org/api/openstack-blockstorage/2.0
•Thanks Avishay Traeger from IBM for letting me
copy things out of his slides.
