A surprisingly high number of database administrators attended last week’s New England VMware User Group meeting in Brunswick, Maine. Maybe they came for the free lobster bake, but more likely, their appearance signaled growing interest in virtualizing tier-one applications.
The VMUG’s “What DBAs need to know about virtualization” session had about 25 attendees — more than a similar session I sat in on at last year’s VMworld, which is obviously a much bigger show. In Maine, VMware’s tier-one database specialist, George Trujillo, talked about how it’s easier than ever to virtualize databases, and he shared some tips for getting management on board with such projects.
“I am absolutely swamped going into large companies, showing them how to virtualize their Oracle databases,” he said.
The first question, of course, is why virtualize databases? Trujillo said DBAs spend 60% of their time on tasks such as creating new databases, moving data and applications between databases and migrating databases to new environments — all actions that virtualization can simplify, using technologies such as live migration, templates and clones.
Most of the discussion, however, focused on the many roadblocks to database virtualization — especially virtualizing Oracle databases. Oracle’s support and certification policies have a bad reputation among virtualization users, but Trujillo said they shouldn’t be deterrents.
Oracle has supported its databases on VMware for years and added support for RAC on VMware in November. Oracle does not certify on VMware, but that’s because the company only certifies to the OS level — not to the hardware level, which is what VMware is viewed as, Trujillo said.
Troubleshooting a virtualized Oracle database is another area that users shouldn’t be overly concerned about, Trujillo said. If you have a problem running Oracle on VMware, Oracle makes you replicate the problem on physical hardware, to show that VMware isn’t the cause. But Oracle does the same thing for problems on physical hardware implementations; if you’re using IBM hardware, Oracle makes you replicate the problem on a Dell or Hewlett-Packard box, to show that IBM isn’t the cause.
“There is not one known error in the Oracle knowledge base that they can attribute to VMware,” Trujillo said.
The final roadblock is an internal one: IT managers and CIOs who fear that virtualizing databases will lead to more trouble than it’s worth. To overcome this challenge, the key is to make a good first impression, because if the performance of the first database you virtualize isn’t up to par, you may not get the chance to virtualize another, Trujillo said.
He noted that the performance hit on virtualized Oracle databases has dropped from 30% to 60% on ESX 2 to 2% to 10% on vSphere 4, but that’s if you do everything right. Avoid memory overcommit and over-consolidation, which can create a fight for resources among your database VMs, and monitor your VMs closely to identify potential problems before they affect performance, he said.
If DBAs can get their higher-ups to be more comfortable with database virtualization, it will be a big step on the road to 100% virtualization. But there’s still another mountain to climb: SAP virtualization, which I asked several VMUG attendees about. They all said they don’t know of any shop that’s doing that.