Information Technology Reference
In-Depth Information
Thin Provisioning: Should You Do It in the Array or in VMware?
h e general answer is that both are right.
If your array supports thin provisioning, it's generally more e cient to use array-level thin pro-
visioning in most operational models. If you thick provision at the LUN or fi le system level, there
will always be large amounts of unused space until you start to get it highly utilized, unless you
start small and keep extending the datastore, which operationally is heavyweight.
Also, when you use thin-provisioning techniques at the array level using NFS or block storage, you
always benefi t. In vSphere, the common default virtual disk types—both thin and fl at (with the
exception of thick provisioned, which in vSphere is used far more rarely)—are friendly to storage-
array-level thin provisioning since they don't pre-zero the fi les.
h in provisioning also tends to be more e cient the larger the scale of the thin pool. On an array,
this construct (often called a pool ) tends to be larger than a single datastore and therefore more
e cient because thin provisioning is more e cient at larger scales of thinly provisioned objects
in the oversubscribed pool.
One other benefi t of thin provisioning on the array, which is sometimes overlooked, is the extra
capacity available for nonvirtual storage. When you're thin provisioning within vSphere only, the
VMFS datastore takes the entire datastore capacity on the array, even if the datastore itself has
no VMs stored within it.
Is there a downside to thin on thin? Not really, if you are able and willing to carefully monitor
usage at both the vSphere layer and the storage layer. Use vSphere or third-party usage reports in
conjunction with array-level reports, and set thresholds with notifi cation and automated action
on both the vSphere layer and the array level, if your array supports that. (See Chapter 13 for more
information on creating alarms to monitor datastores.) Why? Even though vSphere 5.0 added
thin-provisioning awareness and support, thin provisioning still needs to be carefully managed for
out-of-space conditions because you are oversubscribing an asset that has no backdoor. Unlike the
way VMware oversubscribes guest memory that can use VM swap if needed, if you run out of actual
capacity for a datastore, the VMs on that datastore will be aff ected. When you use thin on thin, it
can be marginally more e cient but can accelerate the transition to oversubscription and an outage.
An example here is instructive. If the total amount of provisioned space at the virtual disk layer
in a datastore is 500 GB with thick virtual disks, then the datastore needs to be at least 500 GB
in size, and therefore the LUN or NFS exported fi le system would need to look as if it were at least
500 GB in size. Now, those thick virtual disks are not actually using 500 GB; imagine that they
have 100 GB of used space, and the remainder is empty. If you use thin provisioning at the storage
array level, you provision a LUN or fi le system that is 500 GB, but only 100 GB in the pool is used.
h e space used cannot exceed 500 GB, so monitoring is needed only at the storage layer.
Conversely, if you use thin virtual disks, technically the datastore needs to be only 100 GB in size.
h e exact same amount of storage is being used (100 GB), but clearly there is a possibility of quickly
needing more than 100 GB since the virtual disks could grow up to 500 GB without any administra-
tive action—with only the VMs writing more data in their guest OSes. h erefore, the datastore and
the underlying storage LUN/fi le system must be monitored closely, and the administrator must be
ready to respond with more storage on the array and grow the datastore if needed.
Search WWH ::




Custom Search