Websphere ND Dmgr - Application Server collocation advantages and disadvantages

Question

In a Websphere Network Deployment Architecture, what would be the drawbacks of collocating a deployment manager server with one or more managed application servers on the same host?

In other words, should I collocate Dmgr with other servers or have a dedicated host for it?

It would be interesting to hear about bad experiences anyone had while following the first approach.

Answer 1

The only time in which we're asked to put our DMGR in a seperate box is when my company deployed what IBM calls "stacked" products, like Websphere Process Server. In that case, that setup is quite complicated, to say the least, with the DMGR JVM doing quite a bit of work.

One thing NOT to do, however, is put the DMGR in a different box in a different OS. You're just asking for trouble in terms of the extra maintenance you will have to deal with.

Answer 2

In a basic 1-2 node environment, colocating the dmgr with the appserver node will work fine. Dependent on your resources of course, cpu and memory.

However I would not recommend having more than one appserver node on the same host, even if it's possible - you quickly run into problems with ports and manageability. And anyway, why have two nodes when you only have one host? Except in development, to test clustering maybe.

For cells larger than a couple of nodes, with several hosts, it would be highly recommended to decouple the dmgr from the appserver nodes, for consistency and scalability. You would want all your appserver hosts to look the same, and not have one of them run the Dmgr.

A Dmgr doesn't require much in in terms of resources, a virtual machine with a couple gigs of ram and maybe 10 gigs of disk would be plenty for small to medium sized cells.

Answer 3

I have found a complete answer in this IBM blog. In short the pros of having a Dmgr on a separate host are:

• Separating the administrative process from the runtime
• It can easily be backuped up
• It doesn't interfere with the application runtime (availability, memory, CPU, etc)
• Patching: it doesn't require taking an outage of the administrative process and a runtime server
• The critical time that you're likely to need access to the console to troubleshoot, rollback, monitor some issue, you don't want it maxed out by some "sick" server (Very important in my opinion)

The only disadvantage that this blog mentions is cost.