Misconfiguration #1 - Not turning on dedupe right away (or forgetting
the -s or scan option)
As Dr. Dedupe pointed out in a recent
blog,
NetApp recommends dedupication on all VMware workloads. You may have noticed
that if you use our
Virtual
Storage Console (VSC) plugin for vCenter that creation of a VMware datastore
using the plugin results in dedupe being turned on. We recommend enabling dedupe
right away for a number of reasons but here is the primary reason why;
Enabling dedupe on a NetApp volume (ASIS) starts the controller tracking the
new blocks that are written to that volume. Then during the scheduled
deduplication pass the controller looks at those new blocks and eliminates any
duplicates. What if, however, you already had some VMs in the volume before you
enabled deduplication? Unless you told the NetApp specifically to scan the
existing data, those VMs are never examined or deduped! This results in the low
dedupe results. The good news, this is a very easy fix. Simply start a
deduplication pass from the VSC with the “scan” option enabled or from the
command line with the “-s” switch.
Above, where to enable a deduplication volume scan in
VSC. Below, how to do one in Systems Manager;
For you command line guys its
"sis start -s /vol/myvol" note the -s,
amazing what 2 characters can do!
This is by far is the most common mistake I come across but thanks to more
customers provisioning their VMware storage with the free VSC plug-in it is
becoming less common.
Misconfiguration #2 - LUN reservations
Thin Provisioning has gotten a bad reputation in the last few years. Storage
admins who have been burned by thin provisioning in the past tend to get a bit
reservation happy. On a NetApp controller we have multiple levels of
reservations depending on your needs but with regard to VMware two stand out.
First there is the volume reservation. This reserves space away from the large
storage pool (the Aggregate) and insures whatever object you place into that
volume has space. Inside the volume we now create the LUN for VMware. Again you
can choose to reserve the space for the LUN which removes the space away from
the available space in the volume. There are two problems with this. First,
there is no need to do this. You have already reserved the space with the volume
reservation, no need to reserve the space AGAIN with a LUN reservation. Second,
the LUN reservation means that the unused space in the LUN will aways consume
the space reserved. That is, a 600GB LUN with space reservation turned on will
consume 600 GB of space with no data in it. Deduping a space reserved LUN will
yeild you some space from the used data but any unused space will remain
reserved.
For example say I had a 90GB LUN in a 100GB volume and the LUN was reserved.
With no data in the LUN the volume will show 90GB used, the unused but reserved
LUN. Now I place 37 GB of data in the LUN. The volume will still show 90GB used.
No change. Next I dedupe that 37 GB and say it dedupes to 10GB. The volume will
no report 63 GB used since I reclaimed 27GB from deduping. However when I remove
the LUN reservation I can see the data is actually taking up only 10GB with the
volume now reporting 90GB free. [I updated this section from my orginal post,
Thanks to Svetlana for pointing out my error here]
In these occasions, a simple deselection of the LUN reservation reveals the
actual savings from dedupe (yes this can be done live with the VMs running).
Once the actual dedupe savings are displayed (likely back in that 60-70% range)
we can adjust the size of the volume to suit the size of the actual data in the
LUN (yes, this too can be done live)
Misconfiguration #3 - Misaligned VMs
The problem with some guest operating systems being misaligned with the
underlying storage architecture has been well
documented.
In some cases though this misalignment can cause lower than expect deduplication
numbers. Clients are often surprised (I know I was) at how many blocks we can
dedupe between unlike operating systems. That is, between say Windows 2003 and
2008 or Windows XP and 2003. However if the starting offset of one of the OS
types is different that the starting offset of the other then almost none of the
blocks will align.
In addition to lowing your dedupe savings and using more disk space that
required, misalignment can also place more load on your storage controller (any
storage controller, not a NetApp specific problem). Thus it is a great idea to
fix this situation. There are a number of tools on the market that can correct
this situation including the MBRalign tool which is free for NetApp customers
and included as part of the VSC. As you align the misaligned VMs, you will see
your dedupe savings rise and your controller load decrease. Goodness!
Misconfiguration #4 - Large amounts of data in the VMs
Now this one isn’t really a misconfiguration, it's more of a design option.
You see, most of my customers do not separate their data from their boot VMDK
files. The simplicity of having your entire VMs in a single folder is just too
good to mess with. Customers are normally still able to achieve very high
deduplication ratios even with the application data mixed in with the OS data
blocks. Sometimes though customers have very large data files such as large
database files, large image file repositories or large message datastores mixed
in with the VM. These large data files tend not to deduplicate well and as such
drive down the percentage seen. No harm is done though since the NetApp will
deduplicate the all the OS and other data around these large sections. However
the customer can also move these VMDKs off to other datastores which can then
expose the higher dedupe ratios on the remaining application and OS data. Either
option is fine.
So there it is, the 4 most common misconfigurations I see with deduplication
on NetApp in the field. Please feel free to post and share your savings, we
always love to hear from our customers directly.
