I'll argue that the use-case of many small-memory instances is precisely
the most advantageous use-case for VM clusters, especially when you
consider how VM clusters share memory (shm, heap, etc) between VMs based
on workload.
But I think it is more important to consider the right metrics, which
isn't necessarily memory, because it generally isn't licensed. Same
with IP addresses. CPU is a heavily-licensed resource, and I challenge
anyone to come up with a more manageable and efficient use of CPU than
VM clusters, for any use-case or scenario. Licensing doubles down (or
triples down, or more) on the cost of a compute resource, and licensing
unused CPU incurs a double- or triple-penalty (or more).
Of course manageability is never to be short-changed, as human time and
availability should also be considered heavily-licensed, in a way. It
is probably the most finite of resources, though sometimes elastic.
Having a farm of custom stacked servers to manage is bad enough, trying
to get some redundancy into that dog's breakfast is nobody's idea of a
good time.
Let's put it another way: if your own personal money was at stake to
make the most manageable and most cost-effective use of a limited amount
of physical resources to fulfill an open-ended current and future set of
workloads, would you really consider the "stacking" architecture that
the OP described? I would certainly have done so in 1995, and still did
in 2005, but definitely not in 2015. There's a reason that the cloud
has become economically viable, and the root cause is virtualization.
If someone is managing dozens, hundreds, or thousands of Oracle
instances and they're trying to hand-roll re-invent virtualization
(which is now a very mature and predominant solution) using decades-old
habits and assumptions, then my BS detector starts beeping softly.
On 10/13/15 10:32, Jeremy Schneider wrote:
On Tue, Oct 13, 2015 at 11:25 AM, Tim Gorman <tim@xxxxxxxxx> wrote:
Q: Why isn't the hosting team and vendor proposing a VM cluster to run VMsDefinitely a good architecture, but there is still a case to be made
on a template of one database instance and listener per VM instead?
A: Because then you wouldn't need as much hardware, and it would be too
easy to manage, and it would be more highly available, all of which results
in lower M2V (a.k.a. money to vendor) and M2H (a.k.a. money to host).
for other modes of consolidation!
1) i do think VM-based consolidation makes a strong manageability argument
2) every VM needs an IPs, and in some cases that might be a limited resource
3) if you have lots of small databases with small SGAs, then VM-based
consolidation might be very memory-inefficient. in that case you may
need *more* hardware to do VM-based consolidation that you'd need for
instance-level consolidation.
4) some apps support schema/tablespace-level consolidation which
probably beats everything else for efficiency. also 12c containers may
give these same efficiencies around RAM/SGA.
i had a blog post about this a few years ago...
http://ardentperf.com/2013/12/02/osp-2c-build-a-standard-platform-from-the-bottom-up/
but i've hijacked woody's thread now! changing the subject line...
--
http://about.me/jeremy_schneider
