Database Reference
In-Depth Information
and page file may be on the same data store or hosted on another data store.
Figure 6.16
Multiple VMDK to a single data store.
The performance of SQL in this example will be limited to the performance of a single
data store, and it will have access to the queue depth of a single data store, even though
the individual virtual disks may be trying to issue many IOs in parallel. This example is
the simplest from a management perspective, though, because there is only a single data
store to manage. This sample layout assumes that not all of the virtual disks will be
issuing IOs at the same time and that the aggregate amount of outstanding IOs will not
exceed the available queue depth of the data store. If the available queue depth of the
data store and the underlying storage device is exceeded, the result will be additional
IO latency in the hypervisor and slower response times for your database. Another
impact of this choice is that all IOs from SQL will be blended together and become
completely random, as we show in the “IO Blender Effect.”
The example in
Figure 6.17
shows two VMDKs per data store. This layout may be
suitable for production SQL databases, provided the underlying data store could support
the performance requirements of the VMDKs. This assumes that the data store has
sufficient queue depth for the peak number of outstanding or parallel IOs from the
VMDKs; otherwise, additional latency will result and response times will be degraded.
