by Don Bergal

Virtualization is certainly not a novel concept – in fact the idea of virtualization has been around since the 1960s. Today, virtualization of all the layers of a computing environment – hardware, operating system and applications – have become mainstream. But of all the tier one applications, large production databases lag behind other applications in their rate of migration to virtual servers.

Why the lag with databases?

Looking back, the reasons for the hesitancy were abundant but they are rooted in uncertainty – not true technical hindrances. For example, database vendors often are their own worst enemies because they discouraged the transformation. They did not want the support issues associated with databases, nor the requirement that they revise their database licensing models. Also, they were in competition with companies such as VMware, so marketing databases on virtual servers was verboten.

In addition, database performance is more complex than many other applications, and performance on virtual machines was not well understood. Failover provisions and redundancy are of paramount importance in database performance, and the interaction between proprietary mechanisms such as Oracle RAC and virtual machines were not well researched or documented. I/O was another big scare. There was fear that virtual machines could not provide the I/O bandwidth for the heavily used production database.

Downtime of any sort resulting from a migration was simply an unacceptable risk many CIOs were unwilling to take. For CIOs, a physical-to-virtual (P2V) migration could mean performance uncertainty. And for the DBAs, virtualization would mean losing control and visibility of their systems to VM managers, which could ultimately hinder their ability to deliver database-oriented business solutions. These fears – although not necessarily legitimate – prevented enterprises from embracing the benefits of databases on virtualized servers.

However, budget and resource realities began driving CIOs to greater acceptance of database virtualization and pushing them beyond their virtualization comfort zone. Examples of successful database on virtual server projects became available. Oracle and Microsoft both came around to endorsing virtual platforms for databases. In addition, maturation of recovery and high-availability tools for virtual servers peaked, giving DBAs better management tools and more comfort with their new role and performance. As a result, we’re just beginning to see the mad rush of enterprise database virtualization projects.

Generally, database P2V efforts mean that, primarily, DBAs experience the hassles – and the brunt – of transforming databases from physical to virtual servers. This is because, in a physical environment, DBAs had straightforward visibility to the servers hosting the databases. But in a virtualized environment the layers and the tools to manage them are typically off-limits to their management. DBAs have a valid concern regarding virtualizing this layer.

The problem stems from the fact that databases see only what happens within their individual virtual server, and when the DBA looks at key statistics such as CPU, memory or I/O utilization, the statistics revealed are artificial, created by the virtual machine to simulate an actual server.

If the database-monitoring tool says it is using 50 percent of CPU, the DBA must wonder, “Is that really accurate, or is there a larger pool of CPU resource actually available at the physical host level ready to be allocated?” With a conventional database monitoring a virtualized environment, which cannot tell the difference between a physical and virtual server, the DBA will never know whether key statistics are accurate. The underlying physical layers of actual memory, network, CPU and storage access are invisible to the DBA. Only the VMware administrators, with their specialized virtual system managers, can see what is really happening.

So what’s the big deal? Why not just connect to vCenter, or similar virtual layer management utilities and get the real picture. Not so easy. vCenter, the VMware management system, is both complex and secure. Within most IT organizations, only the VMware administrators have access and the knowledge to use the wealth of performance and availability information. Just as the DBAs have their own monitoring tools to control their databases, arcane and invisible to other groups, the DBAs generally do not have access to the VMware infrastructure management tools.

The stakes are high for the DBA, however. If changing virtual server resources or a new virtual machine on the host server causes a database slowdown, the DBA is the one responsible. Application performance is still directly tied to database output, and application owners will point to the DBA when there is a problem.

Fortunately, new technologies are on the market to help DBAs with this transition. IgniteVM from Confio is the first software designed specifically for DBAs to monitor and ensure database performance in a VMware environment. By offering DBAs an unprecedented level of visibility beyond the database and into the virtual server layers, IgniteVM reduces the risk of database performance issues and connects IT directors, VMware administrators and DBAs.

Having the security of consistent performance and DBAs who can effectively manage the database to meet the business’ expectations are critical success factors leading CIOs to take the plunge to virtualizing their databases. So much so that databases are now becoming one of the most popular virtualization efforts today.

Last year, Nathon Biggs, CEO of House of Brick Technologies a service provider widely recognized for its expertise in transitioning Oracle and other databases to VMware platforms said, "In our experience, migration of production databases to VMware continues to accelerate in 2011. A key success factor in these migrations is the ability to maintain performance and availability.” We can only assume that 2012 will continue – or even accelerate – this trend.

Don Bergal is the Chief Marketing Officer at Confio Software (Boulder, CO). www.confio.com