views:

1004

answers:

3

My company is planning to implement SAP HR in our organsization. We already have the other modules running. We plan to offer ESS/MSS to approximatly 200 000 users. Our current configuration is one machine with a Central Instance and 3 machines with Dialogue Instances. The DB is on the Central Instance machine. Enterprise Portal + DB is running on a separate machine. We are thinking of separating the HR module onto a separate DB so as to not to kill the other modules with load. Is this a valid concern? Is there any better way to architect the system? I was thinking along the lines of separating the DB and Cental instance onto two different machines. I've tried searching on SAP market place for any advice on SAP infrastructure architecture without any luck.

+2  A: 
  1. Separation the HR is a valid option. Its not only the load, but also the HR module has very strict security needs. That may cause some difficulties in system copy's for qa and development system.
  2. Separating the Central instance and DB to separate machines is a valid option. But I would not do it (We are doing it...). It cause some complication in future operation. Like upgrading and database maintenance. Its easier to remove as much load from the central instance. Just remove it from the logon group. So only the message server, enque process and update(optional but recommended) process are left on it.

Update 1: Its not uncommon to separate the db from the center instance. But it does introduce some complication. That, I think, are unnesesery.

Igal Serban
A: 

Are you saying its not a good idea to have the Central Instance on one machine and the DB on the other?

Asif
Asif, when you're replying to someone's answer, please do so as a comment to their own answer, not as an independent answer. For two reasons, this will allow the person to notice your response more easily, and it will keep the answers for what they really are - answers.
Daniel Daranas
+2  A: 

I'm not quite sure what is meant by "seperating" ...

I would through out the idea of two seperat SAP systems, one for HR and one (or possibly multiple others) for the rest. Each of these systems can then be sized/secured according to the different requirements (HR system many users, possibly high dialog use; the other system maybe a bit more "batch-oriented").

This would also be suggested by SAP's general strategy with almost every module being on it's own release schedule.

With regards to the DB and the Application server (central instance?) being on different machines .. that is indeed very common and one of the easiest tuning measures. You can mix and match pretty "ruthlessly" with the AppServer on Solaris and the DB on HP-UX.

IronGoofy