OpenStack with Shared Storage Series: No-dupe > dedupe

I have gotten lots of questions about openstack lately, and interestingly, most questions revolve around the value of using shared storage.  Instead of doing a boring checkbox comparison between shared storage and software on top of local DAS (I avoid using the term ‘software defined storage’ because shared storage could very well be classified as ‘software defined’), I decided to start a series on “OpenStack with Shared Storage”.  First up on the list is my favorite topic: NO-dupe is always better than dedupe.   Read on if you want to find out why…

One of the top use cases for OpenStack platform is private cloud for dev/test environments.  In such environments, VM instance cloning happens very frequently.  For example, the base software build is captured as an image in glance.  Each developer in the team can get his/her own instance based on the image – this can easily be done through Horizon by provisioning an instance based on an image.  To ensure code modification is not lost due to instance reboot, it is best to boot the instance from a volume through cinder.  In order to do that, one can simply select “Boot from Image (creates a new volume)” option in the instance launch wizard:

1

 

 

 

 

 

 

 

 

 

 

 

By selecting this option, a new cinder volume is created, followed by block by block copy of the source image in glance to the new cinder volume.  Once the copying is finished, the instance is booted off the cinder volume.  Here’s a quick video showing this in action (keep in mind my environment is running KVM on top of ESXi so expect much faster performance when Nova is backed by a physical machine)

Let’s say developers want to share updated builds with each other, or with QA or operations team to test or stage, the true value of shared storage backed by Nimble Cinder integration will shine.  The cloning of instances will be offloaded to the Nimble array through Cinder, and the end result is no duplication of data:

  • Cloning is instantaneous as Nimble Cinder driver offloads the clone operation to the array
  • Block by block copying from source to destination volume is eliminated, so no additional network bandwidth utilization
  • No additional space consumption for the clones (doesn’t matter if the source is 100GB, 200GB, 1TB, etc., the clones will consume 0B of space usage on the Nimble array)

This operation can be done easily through Horizon:

Step 1 Create snapshot for the running instance

2

 

Step 2 Launch instance and specify number of clones, along with source snapshot to boot clone(s) from:

3

 

 

 

 

 

 

 

 

 

 

 

 

 

Step 3 Sit back, relax and let Nimble Cinder offload cloning so you can enjoy rapid provisioning + space saving

Check this workflow out in action below (again, KVM on top of ESXi so real life performance will be much better J)

In the next post, I will share another enhancement we made in the Cinder driver that takes “no dupe” to the next level.  Stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *