Database Reference
In-Depth Information
may be fewer SQL VMs of similar size; in large-scale environments (hundreds of SQL
VMs), this is generally less of a problem.
The next potential drawback is that although you may have isolated the storage logically
to each VM, if you share the same storage under the covers, each VM could impact the
performance of the others. When a single VM is using a storage device, you can't make
use of VMware vSphere features such as Storage IO Control (SIOC) to ensure quality of
service and fair IO performance between different VMs. This may place an additional
burden on storage administrators to try and isolate performance at the physical storage
level, which can often lead to limited and suboptimal overall performance.
Finally, the isolation approach doesn't lend itself easily to automation and policy-based
administration. It is also not possible to dedicate storage devices to SQL Server VMs in
this manner in most Cloud or Infrastructure as a Service environments. To make
automation and policy-based administration possible, you need standardization and you
need to share multiple data stores among many VMs. This then allows you to leverage
the features of VMware vSphere to ensure quality of service and fairness of IO
performance between the many SQL VMs if there is any contention.
The example in Figure 6.19 shows two SQL Server VMs sharing the same data stores
for the different types of Windows OS and SQL disks. This layout allows the SQL
VM's performance to be balanced with a standardized data store size and allows for
easier automation and policy-drive provisioning and load balancing. Because the data
stores are shared, VMware Storage IO Control can ensure fairness of IO and quality of
service for IO performance between the multiple SQL VMs.
SQL Failover Cluster Instance Storage Layout
In this section we have shown how you can efficiently lay out your virtual machine
storage for SQL and use fewer LUNs than you have VMDKs, while balancing
performance requirements. This is possible when using standalone instances or when
using AlwaysOn Availability Groups. However, when using SQL AlwaysOn Failover
Cluster Instances, you must use pRDMs and therefore bypass the VMFS data store and
the ability to share LUNs, as Figure 6.20 illustrates.
 
Search WWH ::




Custom Search