Database Reference
In-Depth Information
vSphere Storage Design for Maximum SQL Performance
We have so far covered SQL Server VM storage architecture from the database down to
the data store. We are now ready to dive into VMware vSphere storage design and
physical storage design to achieve maximum performance. This section will build on
what we've covered already and help you to design an underlying storage architecture
that supports your high-performance SQL Server systems on top of it. We will cover the
impacts of number of data stores, data store queues, storage performance quality of
service (QoS), storage device multipathing, RAID, and storage array features such as
auto-tiering.
Number of Data Stores and Data Store Queues
The number of data stores you specify for your SQL Servers has a direct impact on the
number of VMs and hosts that you can support in a vSphere cluster. The maximum
number of data stores per host is 256, and all data stores should be visible to all hosts
in a single cluster to ensure features such as VMware HA and DRS function correctly.
For SQL Servers that will have a low IO requirement, you may be able to host a number
of them on a single data store. This is one of the great benefits of using VMFS data
stores over RDMs. Ultimately the number of data stores you need depends on how many
IOPS you can get from a single data store, the combined IOPS and queue depth (QD)
requirement of the VMs, and the queue depth you have configured per LUN on each
vSphere host. For example, if each SQL Server consumes six LUNs or data stores and
you can support four SQL Servers per host, your vSphere cluster would be limited to 10
hosts, plus one host for failure.
The IOPS for a particular data store is usually measured and specified in terms of IOPS
per TB. This makes it very easy to explain to application owners what performance they
should expect from their storage related back to the capacity. However, the calculation
 
 
 
Search WWH ::




Custom Search