JDE on VMWare

Marshy

Member
I have been searching around for anyone who has expereience in succesfully setting up and running JDE OW on VMWare infrastructure (VI3).
Does anyone know if it has been done in a production environment?
What are the issues with running JDE on VMWare?
 
Stuart,

First, I want to say that neither Oracle nor TomorrowNow support JDE on VMware in production environments. Open a support case and see how it goes...

Second, regardless of what I just said, I know of a customer that has been running Xe on VMware ESX Server 3.0.1 (VI3) in production for 4 months now. JDE does in fact work on VMware (Workstation, Server and ESX). However, they have seem major performance fluctuations (batch processes, package builds, security authentication,etc). Because of its virtual nature, sharing JDE on a VMware host with other server/apps causes issues in many areas like disk i/o contention, CPU contention and network bandwidth contention. I've seem all three. The key is putting non demanding VMs alongside JDE. JDE is a resource hog. Also, out of experience, when the ESX host utilization reaches or surpasses 75%, all hell breaks loose! Servers lock up, hang for VERY long periods of time and users start to come at you with pitchforks and other pointy objects, if you know what I mean... After four months, they are still trying to find the right recipe for this newly imposed architecture.

Oh, I almost forgot, trying to hot migrate a JDE VM from one host to another host (a.k.a. VMotion) does not work well with JDE application servers at all. As a side note and not related to their current JDE infrastructure (they use the iSeries for the database server), VMotion has caused many of the customer's SQL Server databases to corrupt. Just something to look out for if you are on SQL Server.

JDE in development and testing environments is acceptable. However, I would not run JDE on VMware in any production environment. Keep in mind that you can only allocate a MAXIMUM of four CPU (vCPUs actually) to your virtual machine. My production experience comes from going from an 8 way physical monster to a 4 way virtual machine, which in turn share CPU cycles with other VMs. You will not get the same performance out of a virtual box than you would with the same configuration from a physical. This is important to understand.

Just my 2 cents CAD.
 
I have running on VMware (ESX server) a production instance of JDE since the beginning of the year. Two enterprise app servers, and two web servers. The deployment server is the only physical box. The reasons I went this route were really business driven. All of our equipment is on two year leases. With the system being based on VMware, you don't have to worry about switching out server names, the physical boxes hosting the instance may change, but the server names do not..thus lowering the amount of admin of switching server names, ocms, etc, is drastically reduced. Second, the way that the software charges are billed at the company, using a VMware based server almost eliminates the software costs (gotta ask the bean counters on 'how', but it is just the way corporate bills software licenses at our company).

The system has low usage currently (only 10-20 users on concurrently, tops, few batch jobs) as we are only running the HR module on this instance.

That said, it has been very reliable, no issues. Now, someone did state about the resources being dynamic. This is very true. If you are going to place your machines on VMware instances, you should verify how many Vmware instances are going to be placed on the physical servers, and also what kind of load they expect those other instances will require. If the other instances require big CPU or memory, that will pull from what is available from the pool and your instance may suffer.

I would say the big unknown is how VMware would act on a high demand/high volume system. I don't know of any clients running a demanding system on VMware - running an HR module is hardly taxing.

One cool thing with VMware is that it does add to high availability. If a physical server should have issues, your instance can be rolled off ('Vmotioned' off I believe is the term) to other physical servers..so in a way it is kindof clustered.

From my understanding, the big thing against VMware is the cost associated with it. In order to justify VMware's cost, you have to slice up the given hardware so many ways to get a cost savings ROI..only your group can determine how many instances are required on a given box(es) to get back postiive ROI.


Sorry for the ramblings, just spitting out things as they come to mind (and before the coffee kicks in).

-John
 
John,

this is my experience : VMware development/testing environment has about 200 users total, 20 users concurrent and launch about 100 UBEs/day. VMware production environment has about 2,000 users total, 600 users concurrent and launch about 10,000 UBEs/day.

I agree with your statements about OneWorld running fine in a low usage setup in VMware.
 
I think this has been covered in many threads already.

Don't do VMWare in production. DO do VMWare in Development and Testing. End of story (today). Once Drive architecture improves, then I can imagine VMWare working in production in the future - maybe as more and more SSD's come out onto the market ?
 
VMWare can work for Citrix, WAS and anything in Development/Test.

NEVER use it for a Database Server. Very bad things will happen!

Low usage systems are the only exception but in a high use/heavy transaction based system the database will have severe issues.

Colin
 
Back
Top