Database Reference
In-Depth Information
You wish to minimize the amount of storage provisioned up front and only
purchase and provision storage on demand.
When you are using Thick Provisioning Lazy Zero (the default), the VMDK's space is
allocated up front by vSphere, although like with thin provisioning, it is not zeroed out
until it's written to for the first time (or you select full format in Windows when
partitioning the disks). When you look at the data store, you may get a more accurate
view of free space and there may be less variance between provisioned space and
usage. The reason we say you may get a more accurate view of free space is that many
modern arrays will tell vSphere the storage is allocated or consumed but won't actually
do so until data is written to it, although it most likely will be reserved.
If you were considering using Thin or Thick Lazy Zero VMDKs for SQL Server, we
would recommend you choose the default of Thick Lazy Zero to minimize management
overheads. We would recommend using Thin where there are requirements that would
benefit from it and justify the management overheads. However, before you decide on
Thick Lazy Zero, you should consider Thick Eager Zero, which we cover next.
Using Thick Eager Zero Disks for SQL Server
The major difference between Thick Eager Zero and Thick Lazy Zero or thin
provisioning is when the blocks on the VMDK are zeroed out. As we've covered with
Lazy Zero and Thin VMDKs, blocks are zeroed on first write. With Eager Zero, the
blocks are zeroed when the VMDK is created as part of the provisioning process. This
means all blocks are pre-zeroed before Windows or SQL goes to access them. By doing
this, you are eliminating a first write penalty in the situations where that would occur.
This ensures there is no double write IO required to the VMDK after it is provisioned.
As you can imagine, it can take quite a bit longer to provision Thick Eager Zeroed
disks. Additionally, provisioning and zeroing out the blocks may impact the
performance of other VMs when using shared storage devices. The impact to your
environment will be dependent upon the type and utilization of your backend storage
devices. Some storage arrays will just throw away or ignore the zeros, and in these
cases, the provisioning operations will complete relatively quickly and have minimal
impact on performance.
In aggregate, over the life of a VMDK there is normally little difference in the amount of
IO generated when using Thin, Thick Lazy Zero, or Thick Eager Zero VMDKs. The
difference is all about the timing of when the IO is generated, either up front (in the case
of Eager Zero) or on demand (first write) with Thick Lazy Zero and Thin. Once a block
has been written to with Thick Lazy Zero or Thin, it has exactly the same performance
characteristics as if it were Eager Zeroed. However, with Eager Zero, even if a block is
never used, you have zeroed it out at the cost of a write IO operation.
 
Search WWH ::




Custom Search