Re: consolidation

From: Tim Gorman <tim_at_evdbt.com>
Date: Tue, 13 Oct 2015 11:16:54 -0600
Message-ID: <561D3C86.1010903_at_evdbt.com>



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_at_evdbt.com> wrote:
>> Q: Why isn't the hosting team and vendor proposing a VM cluster to run VMs
>> 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).
> Definitely a good architecture, but there is still a case to be made
> 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
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Oct 13 2015 - 19:16:54 CEST

Original text of this message