Databases Reference
In-Depth Information
With Hyper-V, a virtual server could be coni gured to boot with 16GB assigned to it but have an
upper limit memory of 32GB. If while running, the virtual server gets close to using all its initial
16GB of memory, the Hyper-V hypervisor will respond by increasing the memory allocated to the
virtual server if sufi cient free physical memory is available. It won't immediately assign the full
32GB, but it will slowly increase the amount the virtual server needs to eliminate the low-memory
condition. As we mentioned earlier, SQL Server will then respond to the extra memory becoming
available by expanding the buffer pool.
While it's good that extra memory might be available when it's most needed, care should be taken
not to assume that it will always be available; or that if extra memory has been allocated, it won't
be taken back by the balloon driver if a virtual server with a higher weighting needs the memory
instead.
Dynamic Memory is a good way to size a new database server's memory requirement as if after a
few weeks or a complete cycle of business activity the memory allocated to a database server hasn't
increased above 17GB, you could be coni dent that 18GB, rather than 16GB, is an acceptable
memory allocation for that virtual server.
VMware's memory overcommitting feature works slightly differently as the virtual server is told it
has an amount of memory assigned to it but only has the memory it's currently using allocated to
it. You can still size a database server's potential memory requirement, but the memory utilization
data will have to come from VMware's performance counters rather than straight from those
provided in Windows.
Storage
Storage is usually the second most important part of a virtual server's design in order to ensure
SQL Server has the performance it needs to deliver the results expected of it.
Assigning storage to a virtual server is accomplished by attaching a virtual hard drive to it. A virtual
drive is just a l at i le stored and managed by the hypervisor but presented to the virtual server's
operating system as though it were a physical disk. From that point, Windows can create a partition
on it that is then mounted as drive D, formatted as NTFS, and so on.
When you deploy SQL Server in a physical environment you know it can benei t hugely by having
multiple sets of unshared and uncontended hard drives available for its data storage. You typically
see these used to distribute the system i les, data i les, log i les, and in tempdb across different sets
of spindles. The same consideration should be given to your virtualization environment's storage
design, if at all possible multiple uncontended groups of physical disks should be used to place each
virtual hard drive for SQL Server on. Of course, that's not always possible as some SAN's now like
to pool all of their disks into one large group, in which case you should work with your storage
team or vendor to understand how to get the best possible concurrent performance out of it.
Even though hypervisors have different ways of presenting storage to virtual servers, whether they
use i xed or dynamic virtual disks, or raw device mappings, you ultimately need to ensure that SQL
Server's I/O activity isn't negatively affected by competing workloads at the spindle level. Another
possible performance impact, which is unique to virtual environments, can occur when the same set
of spindles holds not only the database server's virtual hard drives but also the virtual hard drives and
entirely separate virtual servers. This is a typical deployment practice for virtual environments,
and for most virtual servers it is usually acceptable. However, SQL Server sometimes doesn't i t in
Search WWH ::
Custom Search