Number on CPUs on Enterprise Server

vivek_kaushal

Well Known Member
Hi Guys

We are using EnterpriseOne XE with Oracle database. Our current Enterprise server is dual CPU and databases are also running on Enterprise servers. We are planning to replace our old Enterprise server with new one but it has run into Oracle database licensing issue. We brought Oracle licensing about 6 years back ( based on CPU clock). The new licensing is based on number of CPUs. So basically we can transfer old licensing to One CPU only and need additional $$$ to buy second CPU license.

Now management is asking me why can not you run Enterprise server with database on a single CPU machine as the CPU speed of new CPU is equivalent/more than old CPUs. I am trying to find reasons. Is somebody running Enterprise server on single CPU? Are there performance implication running EnterpriseOne on single CPU? Has anybody done any performance benchmarks running Enterprise server with database on single vs dual CPU machine?

Any suggestions will be appreciated.

Thanks
 
The biggest issue with single-CPU machines - as I argued with in the past with big blue - is that a single process, if it becomes CPU bound (either purposefully or by mistake) will use 100% of the available CPU power of the machine, bringing your system to its knees.

With multiple processors, the likelihood of this occurring is substantially less - the more CPU's you have, the less chance that this will occur.

Secondly, remember all those functions outside of just the database process that need to be addressed. You really need at LEAST 1 CPU to handle "everything else". JDE MTR is a MINIMUM of two CPU's for a database/enterprise server - or at least it was the last time I looked ! This is to pretty much prevent customers attempting to run production E1 code on nothing more than a big workstation !
 
Any...gosh I can't believe I still need to say this going on 10 years...ANY hardware configuration should be certified by your hardware vendor. All of the certified partners and platforms have competency centers. Send in the answers on the survey, and they will give you the recommended configuration. If you or your management decide to cut...at least you have yourselves to blame. If you go with the recommendation and it is undersized, you have legal standing...as long as you were honest with the initial documentation.

CNC folks...myself included, can certainly debate and argue over what can or can not work...but if you, or your bosses behind is on the line over hardware...get the competency report for your platform (they don't make any money regardless of what you do or do not get), and make your choice from there.

No software or CNC consultant should be giving you any information about hardware other than the MTR's and the e-mail/number to the competency center.

That's my opinion...I could be wrong...
 
Sorry Stooge - I'm going to have to somewhat disagree (although I agree in principle !).

I'm not sure how much "legal credence" has successfully worked in the past through the competency center. I know a number of customers that tried to sue their vendors over bad sizing - and I don't believe I know of one that has been successful yet - even though the hardware was woefully undersized but met JDE's "Minimum Technical Requirements".

Obviously all customers should always work with the competency center of their vendor to identify the size of machine - thats a given. Then, use some common sense on top of that. I know that IBM competency center has made recommendations to use single processor iSeries machines - sometimes to customers with quite a number of users - and we've seen incidents on the list when the customer complains over bad perfomance while UBE's are running. I've been personally messaged from IBM staff over how they can "prove" single processor iSeries can work for customers - but they're not used to how customers run these boxes in a production environment.

Obviously the vendor is going to try and sell you a product that is as low-balled as possible to your configuration to ensure you purchase their hardware over competitors hardware.

Secondly, remember that whatever project you're working on for your companies implementation will more than likely encounter scope creep. Your project will expand into different areas unbeknown to your vendor at the time of sizing - and suddenly instead of running 20 users on "stock" financials, you've got barcode devices, web servers and all sorts of weird communications going on with your ERP system - not to mention the 2000 custom objects you created and the upgrade to the latest version running in parallel. Such is the life of JDE projects.

I say talk to your vendor. Then increase the size they tell you and work out if thats affordable or not ! I don't believe in "threatening" your vendor over competitor pricing - this is a sure-fire way to end up with a system that has been sized PRECISELY to your specifications and is unlikely to be useful when a new version comes out.

I've certainly made sizing recommendations above and beyond what hardware vendors have stated - and I explain precisely why they need additional storage or additional CPU power or additional redundancy. I've never gone UNDER a vendors sizing for an enterprise server - so I have always treated their sizing as a minimum.

However

I have gone under a vendors sizing for "ancillary" servers - such as the deployment server or Citrix/web servers. Often a vendor will identify these boxes as a place where they can make a little extra profit, so suddenly you see quad processor deployment servers with 2Gb RAM being recommended - or 8-way citrix boxes stuffed full of memory. In these cases, its absolutely prudent to question and negotiate with the vendor - use recommended server sizings that can be found anywhere for these products, including on JDEList !

Hope that explains my position. Make sure that whoever you're dealing with has actually sized and implemented JDE servers before - often its an unknown to the vendor dealers.
 
Hey...as long as you've got a good E&O insurance policy...size away!!

I agree you can always offer your experience, as do I. However, when I'm wearing my consultant hat there are legal issues. If I "certify" a hardware configuration and during the project it is found I either over sized or undersized, I could be in big time trouble, especially in the case of an undersizing that could cost not only new hardware expense, but also in project delays.

I know several IBM clients that came back at the their vendor after the sizing proved inadequate. And they got concessions with either refund or steeply discounted new hardware. Now, like I said, and you mentioned, many projects change scope, and if that change means that modules or functionality that wasn't put in the initial estimate are needed, causing a configuration change, well, you really can't blame the vendor at that point.

I didn't mean to imply that you can't get an informed opinion, or give one in your case, but if I were the person responsible for correct sizing, or I reported to the person that was...I would take ANY consultants advice as simply that, arm myself with the MTR's (just for a baseline), and work with my hardware vendor.

Even when consulting for JDE/PSFT/ORCL, and we all know they have the deep pockets, large legal staff, and lots of E&O...field people were always told "never give hardware sizing information, other than to direct a client to the MTR's".

And if that's legally needed by the big houses, it's certainly good enough for me and our crack legal team of Dewey, Chetham, and Howe.
smile.gif
 
Hee hee

Thats why I carry E&O insurance.

Of course, I always try to build the biggest and fastest performing piece of hardware to a customers budget - usually for the larger customers its not so much of an issue.

The issue comes with the smaller customers who have a limited hardware budget. They get a machine sized for them AT A POINT IN TIME - ie, five years ago it would have been a machine that worked EXACTLY with 20 users on Xe. The problem comes when the customer then tries to upgrade - or starts to use slightly different functionality.

I was in the technical marketing meeting in Denver back in 1997 when Ed walked into room and quietly sat at the head of the table. It was my first meeting in Denver - so it was a bit of a shock to see the big man himself sit down just to my right.

He started muttering to himself as he read through bits of paper - obviously his presence was being felt through the 30 or so in the room, as well as over the conference call (which had become strangely silent). Eventually Mike O - back then, the head of Technical Marketing, asked if anyone had any questions. Ed looked up and, in his booming voice, asked if anyone in the conference thought that we should be doing sizing any more at JDE.

There was a few minutes silence. Obviously nobody wanted to answer the question, and I myself kept pretty darn quiet - obviously Ed was annoyed at something. After a minute or so, Bill - at the time a Client Services senior manager - spoke saying JDE should be doing sizing and that it was a necessary exercise since only JDE really understood how large a database could become.

Well, poor Bill had taken the bait, and the avid fisherman that Ed is, had him reeling on his line. Ed didn't cuss - but he certainly made a point to everyone that he didn't want "his company wasting time sizing up prospective customers" and that "disk space is cheap these days - let the customer just buy more space".

Ed was right - but so was Bill. Only JDE consultants really know how large a database can get to, and only really understand the impact on an enterprise server. However, disk IS cheap - and going through several days of trying to size up a database server is a waste of time and is actually pointless since most implementations need far more than initially budgeted.

The hardware vendors, after that meeting, were eager to stand up and state they would do the sizing for JDE customers - of course that meant introducing the JDE prospects to vendors ahead of contract signing ! Sometimes that would cause a conflict of interest, and vendors like Oracle could walk in and try and persuade the prospect that their ERP system was better and used less space...

Anyway - the moral of this story is that you cannot 100% rely on the vendor to understand your sizing requirements. Nor can you fully trust JDE since they don't really want to put themselves on the line anymore over how big a database can and should be since thats the hardware vendors territory. Its a hard decision to make at the end of the day - so budget your hardware as high as possible and negotiate for as many discounts as possible !
 
I ain't gonna quarrel with a respected person who was involved in the actual creation...

I'll rest simply...Competency center = Hardware Vendor + Software Vendor + Test Bed.

Any DASD/DISK is cheap, even on the i5 comparatively...but you know as well as I do it is a small piece of the puzzle...

Simply my opinion...Vendors PLUS Oracle are on the line to certify what you need to run a solution. But again, the solution is only as good as the information given for the evaluation...

I bow to the power of the Quark...

smile.gif
 
Back
Top