Highlighted
mkaberle
2 Bronze

Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Folks

Just looking for some obvious & not so obvious things to consider on why we would not run 2 DB instances in the same VMware VM.

Its ok to be Captain Obvious and state the obvious in a reply to this discussion question.

Labels (1)
Tags (1)
1 Solution

Accepted Solutions
jeff_browning
3 Argentium

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Matt:

The technique you are describing is called instance stacking. There are three approaches to consolidation, generally:

  • Instance stacking (running multiple instances per OS image).
  • Schema stacking (taking multiple logical databases and consolidating them into a single database using individual schemas to segregate the projects).
  • OS-level virtualization.

It is obviously possible (although not terribly common) to use any of these in combination. Thus, you could (theoretically) use instance stacking on a VM, as you indicate.

Problem is, both instance stacking and schema stacking are no longer recommended by Oracle as a best practice. I see these methods used occassionally (like Penske was using instance stacking in an EBC I attended recently). However, according to Oracle's own documentation (http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf), both instance stacking and schema stacking are now deprecated. The problem with instance stacking is that it provides no effective way to do things like load balancing and quality of service. Thus, one instance can run wild, and soak up all of the resources of the box, while the other instance is suffering performance issues. OS-level virtualization allows you to set resource sharing for VMs such that a production VM is guaranteed access to hardware resources, and a test / dev VM can never steal those resources away from the production VM. Similarly, with virtualization, you can use live migration to dynamically move a workload from one physical server to another, thus avoiding islands of capacity. Instance stacking provides none of these features.

As for schema stacking (which you did not ask about), that creates huge security concerns.

The way I usually put it in terms of both instance stacking and schema stacking is that they are not dead, but they are both smelling really bad.

Let me know if this helps.

Regards,

Jeff

6 Replies
vanbut
1 Copper

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Matthew let me be captain obvious. In terms of Load balancing and flexibility it seems easier to deploy within separate VM's. Also in terms of scaling within your instance it seems easier to have one instance per VM so you do not run into VM limitations (which fortunately are ample 64 Vcpu's and 1TB of memory)

0 Kudos
ichakrab
2 Bronze

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

I agree with Tony. If one instance uses more resources , the other may suffer in terms of performance. But the load needs to be really high in one instance. We should be very careful about the Virtual Memory OverCommitment here.

mkaberle
2 Bronze

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Thanks. Good points tony.

Sent from my iPhone, please excuse typo's

0 Kudos
mkaberle
2 Bronze

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Thanks indranil

Sent from my iPhone, please excuse typo's

0 Kudos
jeff_browning
3 Argentium

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

Matt:

The technique you are describing is called instance stacking. There are three approaches to consolidation, generally:

  • Instance stacking (running multiple instances per OS image).
  • Schema stacking (taking multiple logical databases and consolidating them into a single database using individual schemas to segregate the projects).
  • OS-level virtualization.

It is obviously possible (although not terribly common) to use any of these in combination. Thus, you could (theoretically) use instance stacking on a VM, as you indicate.

Problem is, both instance stacking and schema stacking are no longer recommended by Oracle as a best practice. I see these methods used occassionally (like Penske was using instance stacking in an EBC I attended recently). However, according to Oracle's own documentation (http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf), both instance stacking and schema stacking are now deprecated. The problem with instance stacking is that it provides no effective way to do things like load balancing and quality of service. Thus, one instance can run wild, and soak up all of the resources of the box, while the other instance is suffering performance issues. OS-level virtualization allows you to set resource sharing for VMs such that a production VM is guaranteed access to hardware resources, and a test / dev VM can never steal those resources away from the production VM. Similarly, with virtualization, you can use live migration to dynamically move a workload from one physical server to another, thus avoiding islands of capacity. Instance stacking provides none of these features.

As for schema stacking (which you did not ask about), that creates huge security concerns.

The way I usually put it in terms of both instance stacking and schema stacking is that they are not dead, but they are both smelling really bad.

Let me know if this helps.

Regards,

Jeff

sudhirbala
1 Copper

Re: Why would we not deploy 2 or more DBs in the same VMware VM?

Jump to solution

good explanation, Jeff

0 Kudos