There is but one recommendation for this level
of the configuration. It would be most efficient to allocate
database I/O activity disks, spindles or LUNs (logical units) as
physical disks think of it as raw devices. Then use Oracle ASM
to allocate, manage and control all such devices. There is no reason
to add the extra level of overhead because ASM is a perfect solution
for virtualization and worth recommending whether you are doing RAC
or just single instance databases. In fact, at the Oracle 11g
training, the Oracle instructor said that some 60+% of new RAC
cluster deployments were choosing ASM, and that even 25% of all
general purpose, non-RAC deployments were as well. Because VMware
Server ESX is so stripped down, you should also appreciate the free
LVM (Logical Volume Manager) and file system capabilities that ASM
makes available to your virtualized RAC database and all for no
additional cost.
Remaining Steps Same
From here on in the setup process is pretty much
the same, i.e. since you have abstracted the lower levels of the
configuration, the steps up to this point have covered all the
bases. Now the process is like any other multi-RAC node install and
configuration process. You will want to verify that each nodes
hardware, bios, firmware, operating system or hypervisor, device
drivers and optimizations are identical or as close as possible if
there are fundamental hardware differences across your RAC nodes.
You'll also need either SSH (Secure Shell) or RSH (Remote Shell)
configured so that both the Oracle Universal Installer and Database
Configuration Assistant can function for all the nodes.
Other Things that Matter
When asked if other things matter, of course the
answer can always be yes. That is just the nature of the beast in
the Oracle world. But are there any items that specifically warrant
being pointed out? Let us examine a few of the more urgent ones.
First, be careful not to create more than one
virtual machine on a specific physical server that services the same
RAC database. While there is actually nothing fundamentally wrong
with this (refer back to our pseudo-RAC chapter), this should
only occur in limited scenarios where you specifically dictate it.
For example, one way to dynamically manage or allocate excess
capacity for better load balancing might be to create additional RAC
nodes across whatever resources are currently available even if
that means creating more than one RAC instance on the same physical
server. However, it might be wiser to simply allocate additional
dynamic resources (e.g. CPU, RAM, priority and such) directly to the
RAC instance nodes as necessary. There is software on some
virtualization platforms to manage this and, in some cases, to even
automate it.
Second, you might want to take some additional
time to think about your computing centers network cabling and
switch setup. Remember the 200 network items you would have to
define in your twenty node RAC cluster? You
may want your physical switches to VLAN off segments of traffic.
You also might need to plan for more Ethernet segments given the
increased complexity and additional moving parts such a
virtualization strategy causes. The point is that your network and
its wiring may be much more involved and more closely concentrated
than you are generally accustomed to being. Who knows it might be
that virtualization is the last straw which breaks the camels
back, and finally gets you to upgrade to ten gigabit
Ethernet.
For no matter what the joke may be about it
size really does matter. It is not uncommon to leverage lower cost
components in the virtualized information center. But be very
careful not to accidentally create any artificial bottlenecks by
sizing hardware without properly accounting for the highly
concurrent nature and utilization of all your virtualized resources.
Most of us do not yet have enough practical experience in hardware
sizing for such heavy usage, so error on the side of caution when in
doubt because the entire virtual infrastructure can only be as
strong as its weakest link. Hence, there are now many major, hidden
interdependencies between your systems. Look again at this picture
from earlier this chapter. We have two physical servers each hosting
one half of two RAC clusters. This particular solution is more about
freedom to allocate resources rather than fault tolerance, so it is
a legitimate scenario that you may well encounter. As you think
about this diagram below in Figure 8, think about the interconnect
traffic and your desire to keep it humming along. That alone will be
your examples Achilles heel.
If you
try to reduce your now 400 network item count (200 network items per
physical server, and two physical servers) and attempt to use fewer
network cards or share the private network segment, you might slow
down both databases. Furthermore, you might introduce sporadic and
thus irreproducible performance issues where one database or its
nodes causes side effects on the other RAC database. The fundamental
point is virtualization means shared everything and that
necessarily means more dependencies outside your normal project
scope. In fact, it is not uncommon to relocate entire databases in
the virtual world once such performance issues arise. But that is
actually the key strategic benefit of this approach: you can
allocate whatever resources, wherever, and whenever they are needed.
That increases resource utilization,
reduces excess capacity, lowers total hardware costs and even yields
greener information centers.
The only other key area that is
significantly different is the monitoring, diagnostic and tuning
efforts, but that will be addressed in the next two chapters. Just
remember that in the virtualized world, you have many more moving
parts, and thus, more to watch and/or tweak.
Conclusion
In this chapter, we discussed the real world
applicability of virtualized databases specifically, for Oracle
RAC. The conclusion was that virtualization and RAC are compatible.
Furthermore, that this technology progression is really nothing more
than finally realizing the promise of grid. The key areas to
concentrate upon were the lower levels of the virtualization
technology stack, and expressly to rely upon VMware Server ESX for
production use for both performance and scalability reasons.
Moreover, we acknowledged that the configuration of key virtual
resources at this level is critical, especially when trying to limit
any unplanned consequences from interdependencies. Finally, that the
front and rear end processes, such as planning and monitoring,
require additional effort. But not to worry, because in the true
virtualized world where everything is just a resource, things can be
moved as needed. So the flexibility inherent within virtualization
can sometimes be the single most valuable reward and worth the price
of admission all by itself.
This is an excerpt from
Oracle on VMWare:
Expert tips for database virtualization
by Rampant TechPress.
and include the URL for the page.
