In a month we plan to have a server upgrade from our old 4 CPU,5 GB RAM HP-UX server to a big one or buying a new server near to old one. Because in a 1-2 month we expect to have 50 new users for Baan ERP system running on HP-UX. And it will be required extra hardware resources. Our currnet Unix top command statistics below:

Load averages: 2.87, 2.99, 3.03
720 processes: 704 sleeping, 8 running, 8 zombies
Cpu states:
CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR
0 2.88 44.0% 0.0% 52.9% 5.1% 0.0% 0.0% 0.0%
1 2.88 65.4% 0.0% 33.5% 1.1% 0.0% 0.0% 0.0%
2 2.65 46.5% 0.0% 50.6% 2.9% 0.0% 0.0% 0.0%
3 3.06 77.9% 0.0% 20.1% 2.0% 0.0% 0.0% 0.0%
--- ---- ----- ----- ----- ----- ----- ----- ----- -----
avg 2.87 54.2% 0.0% 38.3% 7.5% 0.0% 0.0% 0.0% 0

Above CPU affinity as CPU 0 for OS and Application Baan IV and others (CPU 1,2 and 3) for Informix RDMS.

When we bought the server 3 years ago technicians in HP adviced us to assign 3 CPU s (540 Mhz) for application and 2 CPUs ( 540 Mhz) for DB. But according to above top statistics,despite we assigned 3 CPU for only DB (CPU 1,CPU 2 and CPU 3) nearly it havent satisfied our transaction load,means that their foresight isnt true for now.At that time they said 2 CPU for DB was enough.

CPU 1,2 and 3 is assigned to Informix IDS 7.31 and CPU 0 for OS.
According to statistics there will be CPU bottleneck if we add the new 50 users.To avoid this bootleneck in the future we plan to buy a new big server (maybe with 8 CPU) on single host mode will run Application and DB together or buying a new middle-scale server(with 4 CPU) near to old one.In this combination,we want to run them in clustered mode,old one only for DB and new one as Application server(Baan ERP software).

I want to ask that if we should decide selecting the new server
depond on the current performance values and statistics or
rely on again the technician advices?

And which server combination we should choose? Buying a big new server on host mode,or buying a new server as the old one for connecting them at clustered mode and using one of them as DB server and the other as application server? Should we prefer the single host server option for just only it is economical than the other option?

Any suggestion will be appreciated.top

A long question with a potentially very long answer. A lot depends on what your targets are in terms of system availability, performance etc. Personally I would go for a host mode solution as it will provide the best performance and more importantly, the proposed cluster solution is *not* a good one. For years now, HP has been selling MC/Serviceguard to customers as a product with full cluster capabilities and one that supports interdependant hot packages. This is not true, so don't let yourself be fooled by any smart sales rep. The only truely reliable (and supported!) MC/SG cluster configuration consists of having both application and database running in 1 hot package and providing a failover for that package to another server. In your case, that would mean you would have to buy 2 larger systems. I know there are plenty of customers using the classic database+application server in combination with MC/Serviceguard, but I would strongly advise against this, simply because the cluster product was never devised for this purpose and eventually you will run into difficulties. Hopefully with the addition of TruCluster functionalities into HP-UX, this will change in the future.

For once, I have to disagree with Patrick and defend HP here a bit.

(by the way, I was once an HP employee, so I might be a bit biased :-) )


1. It is conventional wisdom in ERP applications to give more CPU ressources to the application, then to the DB. This definietly is true for SAP. Unfortunately this is not the case for Baan, as it is creating a high load for the DB. So I would say, HP advised to their best knowledge, it was just not Baan specific.

2. To MC/SG
I know a lot of MC/SG installation with Baan on HP-Ux in the described configuration (One DB package on one server and one Application package on another server). The setup can become complex and you need a (very) good consultant from HP to set it up. You might ask what is the trick here?
Easy enough: The consultant needs to know MC/SG, Baan and the database to get it running in all scenarios.

3, Your choice

I would still advise you to go for a host mode installation.
Pat mentioned the performance benefits and he is absolutely correct here. Additionally right know it is cheaper to give your old server back to HP, buy a new bigger one and save on the support costs.

In recent years the CPU power in HP server have risen dramatically, so you should be able to cover all your needs on one server.

But in regards to high availibility there are so many choices, which can hardly be discussed here easily.

So long

Markus

Hey Markus,

I do not see that much disagreement. I know HP quite myself from the inside ;)

Let me state that there are plenty of MC/SG setups that use the classic application+database server approach and that work fairly well. (speaking from experience ;)) The point is that when you look at the architecture of MC/SG and talk to the MC/SG designers, they will completely disagree with that kind of setup. Even stronger, if you do get problems with your MC/SG setup for which you will need to consult your HP Support or Response Centre, you are guaranteed to get slapped over the head because of this. That doesn't mean that HP will refuse you support on these issues but if you have the choice I would still advice to use MC/SG what it was designed for and to put application and database in 1 hot package and provide failover on that. Of course, that is not the most cost-effective and saleable solution :)

Yep, Patrick is right (myself am biased, but...)

If you have any dependency whatsoever, then MC/SG should be rolled out, and since Baan depends on Oracle, I would bundle them into a single package, also the speed is higher in a single system than in a clustered node where Oracle is on one and Oracle on other.

(Note, it's still feasible - just avoid package dependency of an NFS package like the plague! -, I've been working on many like that, but you have to think on every possible scenario of package switching - like make dure that pdaemon6.1 is restarted on the other package by Oracle package when it starts, etc...).

In conclusion, MC/SG was not built for providing package dependency, but it's ok for all the other scenarios.

1. The common practice a few years ago to have a small number of CPUs for the DB and a larger number for the app was in part based upon published Baan benchmarks. A system that would run 900 Baan Reference Users (BRU) in host mode would run 1300 as an App server and >6000 as a DB server. This led some people to the conclusion that the DB server required less CPU. Unfortunately, the BRU numbers are a measure of CAPACITY not throughput or speed. And these numbers do not reflect batch performance.

A batch job can easily saturate a full CPU on a SMP server, so if I have a 2 proc DB server, you can see that with 2-3 batch jobs, I will start extending the number of jobs in the run queue and begin seeing performance degradation.

Indeed the errors were commonly caused by being too BRU specific and losing some basic, common-sense approaches to system capacity planning.

2. Okay -- I will disagree with Pat on this as well. MC/SG while not intended to handle inter-package dependencies well can be scripted to handle mutual failover very effectively. I worked with HP in developing a standard practice for Baan HA implementations a few years ago and we had a very good methodology developed for Baan MC/SG. Obviously, you have to test for Oracle to be up before starting the Baan package...

3. Absolutely -- run with host mode for the best performance. But if you cannot afford to have the downtime associated with a single server extended failure, then decide if the MC.SG HA implementation is a necessary overhead. I have scripted failover so that the tabledef6.1 file is different when running on one server, versus during failover so I have the best connection possible during the 99%+ of the time when I am running normally.

-- Jim

Thanks all of you for your advice and opinions :)