Database Virtualization Do's And Dont's

Virtualizing your company's database servers can be an especially tricky process. Here are some tips on what to do -- and what not to do -- in order to get the results you want.NetworkComputing's recent article on the "Do's and Dont's of Virtualizing Database Servers" starts by addressing the first key obstacle: the DBA. 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.

Before we talk about getting everything virtualized, let's talk about the objections of the average educated database administrator. Your DBA knows his databases, their user counts, and the type of I/O they typically perform. He knows that storage I/O characteristics rule the day, and if he knows anything about virtualization, he knows this little thing called the hypervisor interferes with the ability of his database to make writes to storage. With management buying in to a serious virtualization initiative, he feels cornered and he's ready to fight. In order to disarm his objections, we need to be armed with facts.

Fair enough -- if a hypervisor turns a critical database into a 72 Pinto, the DBA is the one who takes the heat

Don't Miss: NEW! Virtualization How-To Center

The article points out, however, that it is possible to address these concerns by focusing on a few key IT practices, such as:

- Storage configuration, including the impact of storage arrays on database I/O, and the advantages of splitting database reads and writes across separate arrays.

- How to minimize the role that the hypervisor plays in database disk writes.

- Ensuring that a physical server has appropriate CPU and memory resources, and configuring a hypervisor to allocate these resources effectively.

I will throw in another suggestion: Get your DBA involved with a database virtualization project at the very start, rather than simply dropping it on them as a fait accompli. "Disarming" someone is a lot easier if they don't see any reason to fight in the first place.