The obvious question or bone of contention
between these two key alternatives is performance. And yes, the
vendor provided hypervisor is probably always going to be faster
choice. This topic will be more thoroughly examined with empirical
benchmark results in Chapter 8.
The question really becomes one of total cost.
If I have Windows or Linux system administrators who already know
how to configure the database server hardware routinely used, if I
already have or know where to go for drivers and updates, and if I?m
just more comfortable with not introducing yet another new
technology to embrace, then the cost savings on the staffing side
alone could radically outstrip the meager savings on the software
itself. Also, VMware permits one to move up as business requirements
demand, so what's there to lose?
Besides, the recent trend of substantial and
growing hardware performance improvements, which also happens to be
why DBAs are now doing so much virtualization, means that reasonable
overhead is now quite acceptable. Also, the bar to clear for being
considered reasonable is lowering almost daily.
For example, a single database server from just
five to six years ago cost four to five times as much as a server
today - and today's servers come with multiple multi-core CPUs and
lots of memory. So a 10-20% overhead is not that big of a deal
anymore on a machine that has so much raw capacity that you?re going
to virtualize it into multiple machines. Today's hardware is just
too inexpensive and fast to make this the sole decision criteria
anymore. We truly live in great and interesting times.
An analogy might help here. Back in the 1970's
oil crunch, automobiles got much worse fuel mileage and air
conditioners were often an afterthought in terms of the car's
overall engineering, i.e. efficiency. So driving with the AC on was
doubly expensive. But today's cars get much better gas mileage and
the air conditioners now have been engineered from the ground up as
a key component of the vehicle. Hence, even though oil is nearing
$100 per barrel, I don't think we?d consider driving with the AC off
like we did back in the 1970's to save a few percentage points.
Today, we value our comfort more and the cost is far much less. In
short, we ignore the overhead because it's no longer relevant.
That's really not as cavalier an attitude as it
may seem. Person hours cost so much more now than computer hardware
(even with inexpensive offshore outsourcing), that it is sound
business these days to throw cheap hardware at problems. It is at
least, if not more, cost effective than having the staff tuned and
optimized for the same net effect.
Besides, a failed tuning and optimization
effort leaves you exactly where you started. At least the hardware
upgrade approach leaves you with a faster/better server experiencing
the same problem that may still have future value to the business
once the fundamental problem is eventually corrected. And if nothing
else, the hardware can be depreciated, whereas the time spent tuning
is always just a cost taken off the bottom line. So, with such cheap
hardware, it might be a wiser business bet to throw hardware at some
solutions sooner than we did in the past. We might even go so far as
to make an economic principle claim that the opportunity cost of
tuning is foregoing cheap upgrades that might fix the issue and also
possess intrinsic value. Stated this way, it is a safe bet that is
where the business people would vote to spend.
The only reason I am stressing this
hardware-first attitude is that, in the virtualized server world, it
is generally best to think of hardware resources as just assets that
are deployed when and where they are needed as they are needed.
Also, a viable business solution is simply to deploy more assets as
needed. Since the concept of the server (the asset) is now
virtualized, it could well mean just assigning more CPUs or memory
from a virtual pool to a particular virtual machine. In the virtual
world, we no longer have to think in terms of the physical
constraints of a particular server. We must also abstract our
thinking - which leads nicely into our next topic.
This is an excerpt from
Oracle on VMWare:
Expert tips for database virtualization
by Rampant TechPress.