VMware: True RAC Setup

Overview

Up until now we have been examining virtualization of Oracle databases in two key modes: single instance deployments and pseudo-RAC deployments on a single virtual node. But with the obvious future slant of companies moving more aggressively towards utilizing RAC to leverage lower cost hardware, we need to explore doing true RAC in the virtual world as well. That leads us first to decide whether RAC and virtualization even belong together in the same sentence.

RAC and VM Compatibility

Some people are of the opinion that Oracle RAC and grid architecture are exclusive of virtualization. In fact, many of those people would go so far as to argue that database servers in general should not ever be virtualized. The thought is that database servers are so specialized, high demand (especially for I/O) and mission critical that they are not reasonable candidates for virtualization. That might have been true a year or two ago when virtualization was still relatively new and the hardware had not branched so pervasively into multi-core CPUs with tons of cheap memory. But times have changed and so have the limitations, if they ever actually existed at all.

Most database servers these days are overkill in terms of CPU capacity versus their average needs and often more than their peak needs as well. So, as has always been true, I/O is your limiting factor of gravest concern when dealing with databases. Even with today's powerful SAN, NAS and iSCSI disk subsystems, I/O still remains the greatest limiting factor in most cases. You still have higher bandwidth and capacity on the CPU and memory side of the equation. That is why the average database server has extra and, therefore, underutilized capacity.

What has happened is that the fundamental grid concept has been fully realized through virtualization. You really can afford to treat servers, even database servers, as nothing more than resources that can be allocated and load balanced as necessary. You no longer have to build stand-alone islands of server functionality, so you can better utilize all of your computing resources. And in the process, actually lower your total hardware costs to boot. Plus, you get a greener solution as well, which is highly desirable these days. It is truly a win-win scenario from many different angles and worth doing.

Here is a diagram (Figure 1) that just a few years ago might not have seemed too reasonable, but which has become more comfortable in the industry today. Look closely at what this picture below describes mixing database platforms and database instances across your virtualized I/O subsystem. This actually has been done for quite some time and people do not think too much about such configurations anymore other than generally agreeing that gone are the days of walking into a server room and pointing to your databases disks. So now assume for sake of argument that we can all generally agree on this picture. Note that while the I/O workload is mixed (SQL Server and Oracle on same disks); you still have the database platforms physically separated across physical servers.

Figure 1:  Mixing Database Platforms and Instances 1 Side

So what happens if you make the following very minor change to the diagram as shown in Figure 2 (next page) and now allow mixing the database platforms on the left hand side as well? Some of the people I mentioned earlier might argue that this is the first step onto a very slippery slope. I simply believe that this next level of abstraction and virtualization has already been generally accepted and you can both effectively and efficiently mix database platforms and database instances across your hardware on both sides of the equation. So please look closely at this picture, because the water is going to be muddied up a wee bit more.

Figure 2:  Mixing Database Platforms and Instances on Both Sides

The next logical step along this virtualization progression might well be something along the lines of the diagram on the following page (Figure 3). At first glance this picture may seem odd:  why would anyone host multiple RAC nodes on the same physical servers like this? But do not jump too quickly to any conclusions. If all you are primarily worried about is load balancing, then what is really wrong with this concept? My desktop computer has a quad core CPU with 8 GB memory and I built it for about $500. Many of today's servers come with dual quad core CPUs and at least 8 GB of memory with eight core and greater CPUs already being designed for next year and beyond. This growth of the gap between CPU vs. I/O bandwidth really shows no indication of slowing anytime soon. So this picture becomes a reasonable reality in the very near future, if it is not already. One should not arbitrarily try to stand in the way of hardware evolutions or revolutions occurring around us. You should embrace the picture below as being both reasonable and likely to occur sometime soon.

Thus, RAC and virtualization are indeed compatible and make sense in many and ever growing scenarios. From here, you will now learn how one would construct such a setup. As with the prior chapter, I will keep the instructions to a minimum under the assumption that you have read the prior two chapters and fully understood all the steps therein explained. Feel free to return to those chapters as you read the rest of this chapter.

This is an excerpt from Oracle on VMWare: Expert tips for database virtualization by Rampant TechPress.