Database Reference
In-Depth Information
primitive, then the zeroing operation, depending on your array's implementation of this
primitive, may have little if any impact to the performance of the VMDK.
Thick Provisioned Eager Zeroed is the third and final type of VMDK provisioning type.
In this type, all VMFS spaced assigned to the VMDK is consumed. Also, zeroes are
written into each block of the VMDK file. This VMDK file type will take additional
time when created because it has to zero out every block. Just keep in mind what you
are doing when you create this type of VMDK file—you are sending a whole bunch of
zeroes to the disk subsystem. This is something you want to plan if you are creating a lot
of virtual machines with Thick Provisioned Eager Zeroed disks. As we have stated, you
need to understand what you are doing when you create this VMDK file type, because
the last thing you need is to have an angry storage admin hunting you down because you
just created 4TB worth of activity on the production array during the middle of the day.
So which type do you use? At a high level, it really does not matter which you decide to
use for your standalone or AlwaysOn Availability Group SQL Servers—remember, for
AlwaysOn Failover Cluster Instance (FCI), you must use RDMs. When we look into this
a bit more, if Thin Provisioned VMDKs are being considered, then management of
available disk space on the LUN must be managed. Trust us, you do not want to run out
of room on a LUN. From a Thick Provisioned Lazy / Eager Zeroed perspective, with the
Write Same / Zero VAAI primitive, the question now becomes when to take the First
Write Penalty tax. With Thick Provisioned Lazy, the tax is spread out across the life of
the virtual machine, and you only pay tax on the blocks accessed. With Thick
Provisioned Eager Zeroed VMDKs, the zeroing tax is paid up front. Also, you are
paying tax on every block in the VMDK, some of which you may never use. If your array
does not support the Write Same / Zero primitive, then our recommendation is to, at
minimum, use Thick Provisioned Eager Zeroed VMDK files for the database, log, and
tempdb VMDKs.
Thin Provisioning: vSphere, Array, or Both?
Storage arrays also offer the Thin Provision option. A common question we get is,
should one use Thin Provision at the vSphere layer or the SAN layer? Although we do
not have a definitive recommendation, it is our opinion that you understand the trade-
offs and implement the option that best fits your environment.
In our discussion, it is important to consider this at two levels: the virtualization layer
and the hardware layer. At the virtualization layer, you have three VMDK types, as
discussed in the previous section. At the SAN level, you have two options: Thick and
Thin Provisioned LUNs. Thick Provisioned LUNs are ones that consume the entire
amount of space assigned to them on the storage array. Thin Provisioned LUNs are ones
that present a given amount of space, but only consume what is actually used by the
virtual machines running on the data store assigned to those LUNs.
