Large Topologies Recipe

1. Use clusters to scale horizontally and vertically, and to support failover and easier administration. If using WAS >= 8.5, consider using dynamic clusters.
   • Very large topologies also employ multiple cells for the same application(s). This allows for deployment of new application versions or configurations to only one of the cells; if the change breaks, it affects only that cell. Multiple cells can be problematic if significant database schema changes are made.
2. If using the High Availability Manager or any functions that require it (e.g. EJB WLM, SIB, etc.):
   1. Processes such as application servers and node agents must be in the same core group, or part of bridged core groups.
   2. In general, the number of processes in a single core group should not exceed 200. Practically, this number is limited by the CPU usage, heartbeat intervals, and number of available sockets.
   3. The members of a core group should be on the same LAN.
   4. The members of a cell should not communicate with one another across firewalls as that provides no meaningful additional security and complicates administration.
   5. Create dedicated preferred coordinators for a core group with a large default maximum heap size (e.g. -Xmx1g).
   6. If using core group bridges, create dedicated bridge servers with a large default maximum heap size (e.g. -Xmx1g).
   7. Start or stop groups of processes at the same time to reduce the effects of view changes.
   8. Change the HAM protocols to the latest versions: IBM_CS_WIRE_FORMAT_VERSION and IBM_CS_HAM_PROTOCOL_VERSION
3. If you are not using the High Availability Manager, it is not recommended to disable it, but instead to create multiple cells or bridged core groups.

For details, see the Scaling and Large Topologies section of the WAS traditional Profile chapter.

Previous Section (General WAS traditional Performance Problem) | Next Section (Request Metrics Recipe) | Back to Table of Contents