Database Reference
In-Depth Information
VMDKs among the data stores will ensure quality of service and access to performance
of all the databases added to the data store cluster while making administration and
management significantly easier. We would recommend you leave the
IgnoreAffinityRulesForMaintenance advanced setting at 0, unless you are willing to
compromise your affinity rules and performance during data store maintenance
operations.
In
Figure 6.35
, we have combined storage policies with multiple data store clusters.
With the different virtual disks of each VM configured with a storage policy based on
the required capabilities, the storage policy then maps to a particular data store cluster.
Whenever a new VM is provisioned, its virtual disks will be provisioned in the correct
data store cluster. The advantage of this method is that you can have the different
VMDKs of a VM on a different class of storage—for example, where you want backup
on a lower tier, or the OS on a lower tier, while the database files and transaction logs
files are on a higher tier.
Figure 6.35
vSphere storage policies with data store clusters.
Having the flexibility of provisioning the VM to multiple storage clusters and different
classes of storage sounds okay at a distance, but it also introduces additional
management overheads. In storage platforms that already do automated block tiering,
there is limited benefit to this approach. This approach is also difficult in Infrastructure
as a Service (IaaS) environments or Cloud environments (including VMware vCloud
Director or vCloud Automation Center), in which case a single VM may only be
associated with a single storage profile, and automated tiering is used to manage the
performance of the particular VM within the defined physical storage policy.
