RE: consolidation

From: Iggy Fernandez <iggy_fernandez_at_hotmail.com>
Date: Tue, 13 Oct 2015 16:29:55 -0700
Message-ID: <BLU179-W522B62477D910A2260C0F3EB300_at_phx.gbl>

re: if you run vmware don't
For rebuttal see http://houseofbrick.com/managing-oracle-licensing-in-a-shared-storage-environment/ Also see this long post on the "entire agreeement" concept at http://houseofbrick.com/oracle-licensing-soft-partitioning-on-vmware-is-your-contractual-right-2/ Iggy

-- 

Iggy Fernandez

Email: iggy_fernandez_at_hotmail.com

Blog: Explaining
the Explain Plan

Author of Beginning
Oracle Database 12c Administration

Editor of the NoCOUG Journal



> From: ian_at_slac.stanford.edu


> To: oracle-l_at_freelists.org


> Subject: Re: consolidation


> Date: Tue, 13 Oct 2015 17:53:43 +0000


> 


> 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


> > 


> > 


> 


> ��i��0���zX���+��n��{�+i�^


 		 	   		  
--
http://www.freelists.org/webpage/oracle-l

Received on Wed Oct 14 2015 - 01:29:55 CEST