Re: consolidation
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: Tim Gorman <tim@xxxxxxxxx>
- Date: Fri, 16 Oct 2015 11:02:54 -0400
On Tue, Oct 13, 2015 at 1:16 PM, Tim Gorman <tim@xxxxxxxxx> 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.
i'll have to learn some more about this. it still seems to me that
from a *memory* perspective you're going to win by consolidating
higher in the stack and single-OS would be more efficient than
virtualization. but i know that virtualization keeps advancing and
i'm out-of-date and there are a lot of tricks they do. but actually,
it's probably not relevant because...
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...
...this kinda killed any argument about memory anyway. <g>
two major costs to oracle shops:
1) licensing (impacted by cpu)
2) staff (impacted by manageability)
and i think you're dead right to put the focus on the main business
costs. frankly, memory is cheap in the grand scheme of things.
that said...
...I challenge anyone to
come up with a more manageable and efficient use of CPU than VM clusters,
for any use-case or scenario.
i'm inclined to think that virtualization itself is not inherently
more manageable than multiple instances on bare-metal OS's. it's
actually the tools. there are some great tools for managing
virtualized environments. for example, lets just randomly pick one...
if someone buys, say, delphix... well now they've got an jaw-dropping
advantage when it comes to managing those cpu resources efficiently.
:)
so i think it's the tools that are giving virtualization an edge here
- not some inherent property of virtualization itself. some enterprise
shops have been doing consolidation for awhile and already have built
very good standards and automation toolkits around the model of
multiple instances on single OS's. for these shops, i think that they
are probably able to get much of the same manageability and cpu
utilization benefits.
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.
there are a lot of people who *DO* manage thousands of Oracle
instances. and actually, most of them are probably not using
virtualization. because they have actually been doing this *since*
1995 and a few shops are even good at it. yes, cloud technology and
virtualization are closely related and they are coming of age. they
have broad industry momentum and they aren't pushed by a single
vendor. lots of people are making tools to manage virtual
infrastructure. there are developing related innovations like
containers. it's 2015 now and if i'm building a new company from the
ground up then it's a very different question than if i'm an
established business asking whether i need to rebuild my entire
infrastructure to "go virtual".
--
but wait just one minute. yes, there are some great tools for managing
virtualization. but lets be very careful not to fall into the same
trap that RAC fell into. like clustering, virtualization is still an
extra layer. it adds complexity. with RAC you're adding the GCS and
GES - with virtualization you're adding a hypervisor. even if you
have great tools, the bottom line is that you are still adding a new
layer to your stack.
mogens had to remind the world that "you probably don't need RAC" -
and even though people sometimes think i'm a big RAC fan, i am
actually biased against it for the reasons he outlined in that paper.
i've mentioned to you before - i hope that every time someone does a
rac attack lab, they do learn a lot about RAC - and gain a little
respect for the complexity of the software and hopefully get a little
fear of God about implementing it. :)
vmware cluster doesn't have a "global enqueue service" but it does
have its own complexities. if you're running a big, heavily utilized
cluster then you probably need someone who knows what they're doing to
manage the thing. just be careful that you don't expect virtualization
to be some magic manageability bullet. it's not apples-to-apples with
RAC (most importantly, virtualization is not single-vendor but rather
has broad industry momentum) but maybe it could still be said
sometimes that "you probably don't need virtualization"...
-J
--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l
Other related posts:
