Databases Reference
In-Depth Information
those considering deploying these on virtual servers running SQL Server, my recommendations are
as follows:
➤
Coni gure the “server afi nity” settings for your virtual servers such that the hypervisor
ensures that the virtual servers that are part of your cluster or AlwaysOn availability groups
are never run on the same physical host server at the same time. The idea is to protect
against host server failure, so you want to remove any single points of failure.
➤
If you deploy any synchronous database mirroring, then ensure that you have adequate
network bandwidth available on all the host servers on which you will run virtualized SQL
Server instances.
➤
Likewise, for any servers involved in synchronous mirroring, ensure that you have adequate
free physical CPU resources available on the host servers so that any latency to which
vCPUs are exposed as they wait for physical CPU time is kept to a minimum.
➤
Finally, although a discussion of this is beyond the scope of this topic, will your virtualization
environment have any SAN-level replication deployed in order to replicate your storage
system to another SAN infrastructure, typically off-site, for disaster recovery purposes?
If so, you should consider whether it is using synchronous or asynchronous mirroring and
what performance and data consistency impact that may have on SQL Server. It is
critical to maintain storage-level transactional consistency between all the drives a SQL
Server database uses; there is no point to having an updated data i le drive at a storage level
at the remote site if the transaction log drive is a few write transactions behind.
Operating System Enhancements
When an instance of Windows is deployed on a virtual server, other than ensuring that you have the
correct hardware device drivers, there's nothing specii c to virtualization that needs to be coni gured
within the operating system other than to make sure the hypervisor's tools we discussed earlier are
installed.
SQL Server Memory Confi guration
Like Windows, SQL Server can also be installed on a virtual server and will operate quite
successfully without any specii c tuning or coni guration. This is further proof of just how well a
virtual server can emulate a physical server, assuming you have the resources, such as CPU and
memory, available to SQL Server that it needs to run optimally for your workload.
However, you may want to consider coni guring the Max Server Memory setting within SQL Server,
although you'd probably do this on a well-tuned physical server as well. In SQL Server 2012 this
setting now places a working limit on the total memory SQL Server uses, whereas in previous
editions this only inl uenced the size of the buffer pool.
If you are using VMware, their recommendation is to set SQL Server's max server memory value to
be based on the size of the memory reserved for the virtual server. For example, allow 2GB of
memory for the operating system and assign the rest to SQL Server on a dedicated database server.
If you are deploying your virtual servers in a Microsoft Hyper-V environment, then the advice
is slightly different. If you are not using Microsoft's Dynamic Memory feature, then you can be
assured that whatever memory your virtual server appears to have, it actually does have, so you
should coni gure you max server memory setting based on that value.
Search WWH ::
Custom Search