Re: consolidation
From: MacGregor, Ian A. <ian_at_slac.stanford.edu>
Date: Tue, 13 Oct 2015 17:53:43 +0000
Message-ID: <095988BA-FCC2-4CB9-B32F-B635AFA24859_at_slac.stanford.edu>
I fall into Jeremy’s camp on this one. I imagine out of ignorance,. I don’t understand the hardware savings over carving a machine into multiple vms, each running its own database and listener, over running the same number of databases and a single listener on a “real” server I can see management advantages if for some reason you cannot use the same ORACLE_HOME for all the databases, but I don’t see how you save on hardware.
>> On Tue, Oct 13, 2015 at 11:25 AM, Tim Gorman <tim_at_evdbt.com> wrote:
>> 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
>>
>>
Date: Tue, 13 Oct 2015 17:53:43 +0000
Message-ID: <095988BA-FCC2-4CB9-B32F-B635AFA24859_at_slac.stanford.edu>
I fall into Jeremy’s camp on this one. I imagine out of ignorance,. I don’t understand the hardware savings over carving a machine into multiple vms, each running its own database and listener, over running the same number of databases and a single listener on a “real” server I can see management advantages if for some reason you cannot use the same ORACLE_HOME for all the databases, but I don’t see how you save on hardware.
Also if you run vmware don;t you have to license every CPU in the “vCenter” cluster. Perhaps not problem if the cluster is dedicated to Oracle
Ian
> On Oct 13, 2015, at 10:16 AM, Tim Gorman <tim_at_evdbt.com> wrote: > > 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 > >
i0zX+ n{+i^ Received on Tue Oct 13 2015 - 19:53:43 CEST