Production Virtualization techniques and Performance Oracle

[timothy carroll]

I have a simple question - If I have an Oracle application server and database - why not just buy some inexpensive rx2600's for the app server and maybe an rx6600 for the database server - rather than buy a 6600 and slice it up in virtualization....

Seems with cost of servers the only advantage to VM is if you already have a large box

[Duncan Edmonstone]

Simple answer?

Flexibility and ease/cost of management

Are you completely sure you understand the workload of your application to the level where you might never need to change it? What if you find your app needs more grunt and your database less? If you bought seperate machines you're stuck with what you bought - if you bought one larger system and carved it up, you can change that.

Its interesting that people get really hung up on the acquisition cost of servers without considering the cost to manage and maintain (TCO in other words). Acquisition costs are such a small part of the overall TCO, people should really concentrate on managing that. Speak to any CFO and offer him a choice between a larger one-off capital cost now vs. a smaller capital cost with ongoing undefined expense costs and most will take the option of going with whats better defined. Of course capital costs are easier to measure... but a little work should help you figure out the management savings of running a smaller number of systems.

HTH

Duncan

[timothy carroll]

I guess I am having a hard time understanding this: say I have 2 application servers load balanced across 2 physical machine and then want to add another one - so in total the 2 machines cost 6k - or I have 1 machine I bought for 6k and carved it up into 3 vm's - does not the VM take up memory, etc - then I decide to add a 4th application node - do I go out and buy another 6k machine -

[unixdaddy]

there is not a simple answer to your question.

However using your example, traditionally you would have spec'd for peak performance (even if that was only hit once a month!!) therefore you would spec 3 boxes that would be bigger than your actual needs and would be wasted for 30 days out of the month.

Now using virtualisation you spec'd for average/shared performance and pick a box that could house all 3 performance requirements. Then as Duncan said you are then able to flex resources up and down for each as their peaks required (good planning is required)

So using real boxes - you might spec 3 separate rx3600 for you application, (now depending on performance stats) you might only need 1 (possible 2 for failover) to house your 3 applications. if you are running oracle using 3 separate fully loaded rx3600 you pay for 12 cores, on the single rx3600 (running virtual machines) you'd pay for 4 cores!!!

In addition do you really need multiple separate boxes to hold you development and testing environments??!!?? virtualise them and reduce your costs - sounds like a winner.

In terms of overhead - yes virtualisation adds an overhead (not that significant if spec'd right), but it shouldn't be so much as to require you to go and buy a whole new box (on top of your virutalised server) if you've planned you virtualisation requirements i.e. memory, storage, CPU, IO requirements.

It all depends on the number/type of environments you require, applications you are using and good planning. there maybe times when you want to keep environments totally separate on the otherhand if you have a choice of a number of overspec boxes or fewer boxes, flex resources and add physical memory/CPU/IO if required then i think it makes sense.

[Hein van den Heuvel]

While I can appreciate Duncan's TCO concerns and the relative simplicity of a single larger box I am firmly in the camp of rack-and-stack-em small boxes, workload characteristics allowing. (If you need 512GB in a single box, then I'll have to be a big box... today).

* Blades would be the most manageable extension for higher initial purchase but potentially lower operations cost.

* Oracle RAC potentially allows DB scaling with small boxes.

- Smaller boxes are easier to design and inherently faster (cache coherency, local memory).

- Incremental following of the technology curve. DB server becomes latest and greatest box. The old DB servers become the new app servers. The old app servers become QA systems and so on

- vendor independence (more as leverage than actual).

- Emergency reconfiguration / redeployment : Even with multiple redundancies and and isolation tools, one can still imagine scenarios (operators, forklifts :-) where a whole server fails. It is easy enough to have a spare little one or two, not so for a big one.

- incremental upgrades... increasing the memory or IO adapters in a server means taking down just that server and the application may stay up. Yeah several big boxes allow for hot reconfigs... but would you?

fwiw,
Hein van den Heuvel
HvdH Performance Consulting

[timothy carroll]

Lets review the TCO in my example -

I buy 4 26000 for say 20k - I load balance 2 of them and leave one for failover and 1 idle.

Or in your case I buy 3 6600's at 60k and VM one into 2-3 app servers and other 2 sit idle waited for expansion

How is this saving me TCO

[unixdaddy]

interesting. i don't agree or disagree with hein. personally i've become a big fan of blades, however where appropriate i'd use small rack mount or larger rack mount servers.

I'm sure that any well designed combination of small boxes will work. At the same time any well designed larger (virtualised) configuration can work.

i'm not sure that smaller boxes are 'inherently' faster - a badly speced box is a badly spec'd box, a well spec'd box is.... a well spec box whether large or small.

Vendor independance is not something that i think makes a difference much now. The question is what can you get out of your vendor.

As for crash and burning a box again i can't see the difference as it can happen to either - a forklift truck hits a rack all the rack servers are in danger. Whilst a dumb operator simply needs educating or firing.

for example if you have multiple app boxes connected to a db and he takes out the DB - the whole environment is down and the apps are useless - the business sees the applicaiton is down, if it is virtualised and he takes out the physical server, what do the business see.. the environment is down - can't see the difference really. you recover from ignite or fix the server.

Emergency reconfiguration would be via ignite or a decent sysadmin - so that works to virtual or physical servers. however you can't increase memory on the fly to non-virtualised rack server, therefore you have to spec' for peak which often means underutilised resources.

if you spec your virtual host correctly you can increase memory, CPU HBA's on the fly (no outage)and adjust workloads (WLM)and assign additional HBA to your virtual machine with only an outage on that virtual machine

virtualised servers reduce power, floorspace and cabling (all should be part of TCO analysis).

Finally if you buy 4 rx2660 and load balance them then that is great it will use more cabling, more power and take up more space in your rack than a single rx6600.

Like i said it depends on what you want to do, maybe you have a number of windows boxes so you virtualise them as well onto the rx6600 - one HW vendor (good or bad take your choice).

Personally I'm against buying kit and leaving it idle, but again some business prefer to have that physical item.

I'd add again do you really need test/dev on their own servers??!!?? yes keep production on a number of small boxes, but with lower SLA's combine dev/test onto a slightly bigger platform (not talking superdome).

The point is that you can buy 4 rx2660 or 2xrx6600 or 3 rx3600 or 2xBL860c + c7000 enclosure(with VC)or whatever you like, it is a choice based on your needs. remember however (as duncan said), it is not just the cost of the physical server - power, floorspace, cabling, the cost of managing plethora of servers, the ability to adjust virual servers on the fly, the reduction in maintance costs - one box on support with HP as opposed to 4 boxes???

what spec would you go for on the rx2660? can they combined in x number of rx3600? are these production or dev/test? what are the IO requirements? the rx2660 for example is 3 IO slots do you need more? would a slightly bigger box (rx3600) allow you more options as it has more IO slots and then you can combine 2 rx2660? i suspect that if you need 4 rx2660, with good design you probably get away with 2 rx3600 and have HA which means recovery (to your business) is faster those TCO is imporoved.

Really it is all about analysis, no right or wrong answer.