1 / 35

ONE DOES NOT SIMPLY CREATE MULTIPLE BACKENDS IN CINDER

Learn about Cinder's block storage management system, architecture, services, drivers, and future plans for handling multiple backends. Listen to our comprehensive presentation.

linden
Download Presentation

ONE DOES NOT SIMPLY CREATE MULTIPLE BACKENDS IN CINDER

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ONE DOES NOT SIMPLY CREATE MULTIPLE BACKENDS IN CINDER Walter Boring IV - HPE hemna - @hemna Jay Bryant - IBM jungleboyj - @jungleboyj Sean McGinnis - Dell smcginnis - @seantmcginnis Kendall Nelson - IBM diablo_rojo - @knelson92 • YOU HAVE TO LISTEN TO OUR PRESENTATION FIRST

  2. Agenda • What is Cinder? • How Does Cinder Fit? • Attaching a Volume Examples • Cinder Architecture • Cinder Services • Cinder.conf • Cinder Drivers • Multiple Backends!! • Volume Types • Retype vs. Migration • Future Plans

  3. What is Cinder? • Created in Folsom Release (~4 years ago) • Spun off from Nova volume • Cinder manages block storage • Different from file level storage- that’s Manila • Different from object storage- that’s Swift • Focuses on • Attaching volumes to VM instances • Booting from volumes • Volumes have life cycles independent of VM instances

  4. How Does Cinder Fit? • Cinder provides all commands and API’s to interact with vendors’ storage backends • Exposes vendors storage hardware to the cloud • Provides persistent storage to VM’s • Enables user to manage their storage • Create • Snapshot • Backup • Attach/Detach

  5. Attaching a Volume Ex. 1 Cinder Nova Note that iSCSI is just an example – several additional protocols are supported (e.g., FC, NFS) LVM VM instance /dev/vda iSCSI target Legend Persistent volume control Persistent volume data KVM iSCSI initiator

  6. Attaching a Volume Ex. 2 Cinder Nova Note that iSCSI is just an example – several additional protocols are supported (e.g., FC, NFS) Storage Controller VM instance /dev/vda iSCSI target Legend Persistent volume control Persistent volume data KVM iSCSI initiator

  7. Cinder Architecture client SQL DB REST cinder-api cinder-scheduler cinder-backup cinder-volume driver cinder-volume driver Storage

  8. Cinder Services • API • REST interface to Cinder • Generally runs on control node • Scheduler • Takes requests from API service • Works with volume services to satisfy requests • Generally runs on control node

  9. Cinder Services cont. • Volume • Interacts with vendor storage backends • Create • Manage • Export • Can run on control node, or some other node • Backup • Interface from backup volumes to storage like Swift, TSM, etc.

  10. Cinder Client /OpenStack Client • Cinder Client • python-cinderclient is the command line interface to Cinder • ‘ cinder <command> ’ • Uses REST to communicate with the cinder-api service • Generally runs of control node • OpenStack Client • All projects moving towards using the OpenStack Client • Deprecating all individual project CLI’s

  11. Cinder Client / API • Volume create/delete/list/show • Create from image/snapshot/volume • Attach/detach (called in Nova) • Snapshot create/delete/list/show • Backup create/delete/list/show/restore/import/export • Volume types create/update/delete • QoS • Quotas

  12. cinder.conf • Used by all of Cinder's services • Multi-backend support is enabled by a different section for each driver • enabled_backends is used to set which drivers you want actually running for your system • enabled_backends = lvmdriver-1,lvmdriver-2,lvmdriver-3

  13. cinder.conf (cont.) • Set debug=True and verbose=True to get additional logging output • By default Cinder's logs go to /var/log/cinder • When using devstack: /opt/stack/logs • When using iSCSI make sure the right iscsi_helper is set: tgtadm for ubuntu, lioadm for RHEL • Any changes made to the cinder.conf file require the Cinder services to be restarted before they can take affect

  14. Cinder Drivers • Block Device Driver (local) • Blockbridge (iSCSI) • CloudByte (iSCSI) • Coho (NFS) • Datera (iSCSI) • Dell Equallogic (iSCSI) • Dell Storage Center (iSCSI/FC) • Disco (disco) • DotHill (iSCSI/FC) • DRBD (DRBD/iSCSI) • EMC VMAX (iSCSI/FC) • EMC VNX (iSCSI/FC) • EMC XtremIO (iSCSI/FC) • EMC ScaleIO (scaleio) • Fujitsu ETERNUS (iSCSI/FC) • GlusterFS (GlusterFS) • HGST (NFS) • HPE 3PAR (iSCSI/FC) • HPE LeftHand (iSCSI) • HPE MSA (iSCSI/FC) • Oracle Zfssa (iSCSI/NFS) • Pure Storage (iSCSI/FC) • ProphetStor (iSCSI/FC) • Quobyte (quobyte) • RBD (Ceph) - Reference • Scality SOFS (scality) • Sheepdog (sheepdog) • SMBFS (SMB) • SolidFire (iSCSI) • Tegile (iSCSI/FC) • Tintri (NFS) • Violin (FC) • VMware (VMDK) • Virtuozzo Storage (NFS) • Windows (SMB) • X-IO technologies (iSCSI/FC) • HPE XP (FC) • Hitachi HBSD (iSCSI/FC) • Hitachi HNAS (iSCSI/NFS) • Huawei (iSCSI/FC) • IBM DS8000 (FC) • IBM Flashsystem (iSCSI/FC) • IBM GPFS (GPFS) • IBM Storwize SVC (iSCSI/FC) • IBM XIV (iSCSI/FC) • Infortrend (iSCSI/FC) • Lenovo (iSCSI/FC) • LVM (iSCSI) - Reference • NetApp ONTAP (iSCSI/NFS/FC) • NetApp E Series (iSCSI/FC) • Nexenta (iSCSI/NFS) • NFS (NFS) – Reference • Nimble Storage (iSCSI) (Drivers in bold are the reference for the architecture)

  15. Ex. cinder.conf with Multiple Backends

  16. Enabling Multiple Backends

  17. Volume Types • Only admins can create volume types • Control user’s access to different storage • Type can be associated with a particular backend • Type can have a list of desired capabilities • Users specify the volume type when they create a volume

  18. Volume Types (cont.) • In Horizon you can: • Create vol types • List vol_types • Set keys for a type • Show the keys set for a type • Using CinderClient you can: • Create vol types • List vol_types • Set keys for a type • Show the keys set for a type

  19. Volume Types (cont.)

  20. Volume Types (cont.)

  21. Volume Types (cont.)

  22. Volume Types (cont.)

  23. Volume Types (cont.)

  24. Volume Types (cont.)

  25. Retype Vs. Migration • CONFUSION • Retype is used to change settings of a volume on the same backend • i.e. Storwize SCSI disks to SSD disks on the same array • Some retypes can happen without the data moving • Migration is used to move a volume between two different backends • i.e. from LVM to Storwize • Retypes may require a migration

  26. Retype Change volume types: • cinder create 1 --name vol1 --volume-type dellsc1-nightly • cinder retype vol1 dellsc1-hourly

  27. Retype with Migration Change volume types: • cinder create 1 --name vol1 --volume-type dellsc1-nightly • cinder retype vol1 dellsc2-hourlyFAILS!

  28. Retype with Migration Change volume types: • cinder create 1 --name vol1 --volume-type dellsc1-nightly • cinder retype vol1 dellsc2-hourly \ --migration-policy on-demand

  29. Migration Migrating volume to new host: • cinder create 1 --name vol1 --volume-type lvm1 • cinder migrate vol1 Cinder2@VendorX#Pool1 Cinder1 Cinder2 LVM1 VendorX Pool1 Pool2

  30. Retype Vs. Migration (cont.)

  31. Retype Vs. Migration (cont.)

  32. Retype Vs. Migration (cont.)

  33. Retype Vs. Migration (cont.)

  34. DISCLAIMER: These are things being currently worked, but may not necessarily make it into Newton The Future! • Active/Active High Availability • Two cinder-volume services managing the same backend storage • Multi-attach • Attach the same volume to more than one host/instance • Scaleable Backup • Containerizing Cinder Services • Capability Reporting

  35. Thank You!

More Related