Database Reference
In-Depth Information
Data Stores and VMDKs
If you are going with VMDK files, the next topic that arises is whether to dedicate one
VMDK file per data store or to run multiple VMDKs per data store. The guidance we
provide here is to validate with the SAN team and or SAN vendor what VAAI
primitives the SAN you are working on will support and what the performance impact
is of having, or not having, certain VAAI primitives in your environment. One key VAAI
primitive is Atomic Test Set (ATS). This updates the way vSphere does locking to
perform metadata updates. ATS replaces SCSI locking, so check to see if your array
supports this primitive. In the end, as long as the data store is capable of delivering the
IOPS required by the virtual machine(s) using a particular LUN, then either option is
valid. One item for consideration, given that IOPS is met, is the management overhead
associated with presenting a lot of LUNs in the case of one VMDK per data store. The
reason this can be of concern is that vSphere 5.5 still has a configuration maximum of
256 LUNs per host.
VMDK File Size
It is important to also consider the size of the VMDK file you are creating. Although it is
possible to create a VMDK file that is 62TB on vSphere 5.5, it does not mean you
should, unless you have valid reasons. Our recommendation is to design the SQL Server
configuration for the best possible performance. Having more VMDKs as targets will
yield better performance than having one large VMDK file. In addition, SQL Server is
built to have a large database split among multiple disks. It is all about scaling and
going as wide as possible to achieve the best performance possible. We go into great
Another consideration is the service-level agreements (SLAs) you have established
with the business concerning database availability. If you have a Tier 1 database that
has an SLA of no more than two hours of downtime, then a very simple question to ask
is, “Can I restore a 62TB file in the time frame it takes to diagnose and restore this
file?” We have seen from a recovery perspective that smaller VMDK files allow for
faster recovery time and less likelihood of breaching your SLAs.
Networking
When we consider networking, we start with the virtual switch type. In terms of using a
standard virtual switch or a distributed virtual switch, the choice is yours. We, the
authors, recommend using the distributed virtual switch. The reasons for this come
down to ease of management and the additional features available with the distributed
virtual switch, such as network I/O control, which is discussed in the following
sections.
