Database Reference
In-Depth Information
single host. Once you know what the likely blended peak is, you can design your
host platforms accordingly.
“Every millisecond of storage IO latency is potentially a millisecond that SQL
can't respond to an application request.” —Michael Webster
Number of Virtual Disks per Data Store
This section is only relevant if you're building standalone SQL Server or using
AlwaysOn Availability Groups with virtual disks (VMDKs). SQL FCI requires RDMs,
and therefore each drive is mapped to a LUN and you can't share the LUN with multiple
VMDKs. You can, however, share the LUN and drive with more data files and achieve
the balance of outstanding IOs to queue depth that way.
The number of VMDKs per data store will be limited by the performance
characteristics of the data store and the performance requirements of the VMs and their
VMDKs. Our primary goal when we decide on the number of VMDKs per data store is
to try and balance the average number of active outstanding IOs per host with the queue
depth of the data store. In most cases, not all VMDKs will use all their available queue
depth all of the time, and not all VMs will use their available queue depth all the time
either, but they may have peaks. We need to be able to handle these peaks within a
reasonable time in terms of the IO latency or service time.
The example in
Figure 6.25
shows a configuration where two VMDKs are on each data
store. Each VMDK has a queue depth of 64, resulting in an over-commitment in queue
depth of 2:1 from the VMDKs to the data store. On average, each VMDK will be able to
issue 32 outstanding IOs (assuming they're on the same vSphere host) before any
additional queuing occurs in the vSphere kernel. If one VMDK is idle, the other VMDK
can issue the maximum number of outstanding IOs to the data store and make use of the
full queue depth. This may seem to be a rather conservative number of VMDKs per data
store, but for very-high-performance systems this (or even 1:1 VMDK to data store)
may be necessary to achieve the performance requirements.
Figure 6.25
Two VMDK per data store.
The example in
Figure 6.26
shows a queue depth over-commitment of 4:1, assuming all
