I’m continuing with my thoughts about deduplicated storage for VMs and how it is different and requires different thinking. Today I will look at cloning VMs and some thoughts. In particular how other data efficient cloning technologies work compared to deduplication.
First off data efficient clones are not in every storage array. If you are still assembling disk groups into RAID arrays and carving LUNs out of those arrays you probably don’t have efficient clones. Most modern array architectures abstract away the RAID and LUNs. Rather than these fixed layouts they use more complex metadata to lay VMs dynamically across a collection of physical disks. The metadata lists the data blocks that make up a VM’s disk. The array uses the metadata and disk blocks to make up the VM disk. If you are using a storage array that was designed in the last ten years, you probably don’t care about LUNs. You do get metadata based clones using offloading like VMware’s VAAI. This offload allows VM cloning to happen inside the array, the exact technique is invisible to the hypervisor.
The starting concept is this metadata can be used to clone the VM, sometimes called pointer based cloning. This is where the storage array clones an existing VM by simply cloning its metadata. Then the data blocks are shared by the two VMs, so the blocks become read-only. When each VM writes to disk the writes cannot overwrite the shared blocks and are written elsewhere. The metadata is typically around 5% of the size of the data it represents. These clones are at least 20 times faster than full copy clones. In addition, the clone process only consumes capacity from the array for storing another copy of the metadata, not the full set of blocks. Immediately after the clone both source VM and copy VM use exactly the same data blocks on the array. This clone process is exactly the same whether the array is deduplicated or not and its mechanics are hidden from the hypervisor. The difference comes when the VMs start writing data to disk.
When each VMs writes to it’s disk the changed data blocks must go to a new location, they cannot overwrite the shared blocks. Every block that each VM writes to is stored by the array. Over time more data will be written by the VMs and each VM will rely on less of the shared data blocks. While the initial copy was space efficient, over time each VM’s disk consumption will increase. Without deduplication, the array must separately store every block that is written by every VM. The array must store the differences for each VM, leading me to call this differencing. With deduplication only the unique blocks that the VMs write will need to be stored. Just the same as if the VM was created from scratch rather than cloned.
Let’s consider cloning ten VMs to test an upgrade, maybe a service pack, before upgrading in production. After cloning the ten VMs, we run the installer. The installer starts by backing up existing files before writing the updated files. Without deduplication we get ten VMs times the backed up files then ten VMs times the new files. That could be quite a lot of capacity used up to store redundant data. Even if we delete the backup files the blocks in the array will still be used! With deduplication, we don’t need to store copies of the backed up files since we already have them. Then when ten VMs write the updated files we only need to store the first copy, all the other VMs will use identical (deduplicated) data blocks. The deduplicated array will use significantly less capacity for the ten VMs.
There is also a philosophical difference here in deduplicated arrays. Without deduplication, some of the cloned VM’s disk blocks are read only and some are writable. This makes the VMs involved in metadata cloning different to VMs that are not involved. The use of shared and read-only blocks feels like a bolt on. With a deduplicated array, the unique data blocks on disk aren’t overwritten ever. Every data block is read only until it’s no longer required by any VM. A metadata cloned VM accesses the underlying storage exactly the same way as any other VM.
It is worth being aware that there are times when VAAI is not used even if the array supports VAAI. Without VAAI, there is no metadata based cloning. One is when VMs are cloned from one array to another, maybe from the production array to a test/dev array for that upgrade testing. Since VAAI cannot be used the whole VM disk will be copied from the source array through the hypervisor and to the destination array. Naturally this full copy is going to take far longer than a metadata based copy. At the destination a deduplicated array will still be space efficient, non-deduplicated arrays will not be so efficient. There are also times when VAAI is turned off in an environment. This is often for some (misguided) security concern. Without VAAI copies within the same array will still pass through the hypervisor and require a slow full VM copy. I’ll talk later about why inline dedupe helps speed this up, but it is still slower and less efficient than offloading the copy to the array.
Metadata based cloning is a great function of modern storage arrays and hypervisors. It saves capacity and time when you need to clone a lot of VMs. Using metadata clones then storing each VM’s changes separately is a less space efficient solution than deduplication in the array. This applies to any deduplicated storage used to store running VMs. I’ve been working a lot with SimpliVity who use inline deduplication in their hyperconverged platform.
© 2015, Alastair. All rights reserved.
RSS - Posts