• 01/21/2010
    12:24 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

The Do's And Don'ts Of Virtualizing Database Servers

Virtualization conveys numerous benefits to traditional x86/64 bit server environments, but everybody knows that virtualization and heavily utilized databases don't tango; at least that's the consensus. By utilizing some simple best practices and taking advantage of smart features in vSphere, you can harness the flexibility, load balancing and high availability features of virtualized database servers.

Given the fact that a typical virtualization host system has abundant CPU and memory resources available, let's talk about minimizing hypervisor involvement in disk writes and assuring that your database has enough resources to handle whatever we're going to throw at it. By following the following recommendations, you can relax about database issues on virtual platforms.

First, we need to minimize the involvement of the hypervisor in making writes to storage. There are two ways to accomplish this: we can either allow the virtual machine exclusive access to the raid datastore, or we can give the database virtual machine a Raw Device Mapping (RDM) to the storage. Giving the VM exclusive access to the datastore is just that, we create a datastore on top of the physical array or LUN, and we provision all the available space into in a single disk. This minimizes hypervisor involvement in storage I/O because there are no other virtual machines using the array. The second option is to grant the virtual machine a Raw Device Mapping. Raw device mappings in vSphere allow a particular virtual machine unrestricted and exclusive access to an underlying storage medium. In short, the RDM prevents nearly any interference by the hypervisor in storage utilization. For moderately utilized databases, the first method is probably sufficient, but if your database is a monster, then RDMs are your only option. RDMs require additional configuration and zoning or masking to implement on the storage side, but VMware makes it easy to allocate them to a virtual machine.

Finally, we need to make sure your database server has the CPU and memory resources necessary to do its job. In VMware, we can do this with simple CPU and Memory reservations. Windows Perfmon and VMware capacity planner are both great for getting a starting point for what's required on a physical database server, and the next step is just to set a reservation for disk and CPU commensurate with your sample data. If you're really dead set on giving exclusive CPU access to your database server, set affinity for the server to a particular core or cores and unset affinity on all other virtual machines from that core or cores; this prevents any other machines from using that CPU and guarantees exclusive access.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.

Log in or Register to post comments