weblogic server capacity planning considerations

We need to consider below things while calculating server scaling:

How much flexibility do you wish to retain to run, manage and maintain applications independent of each other.
Very large number of applications and servers within a single domain can be more difficult to manage than applications that have been partitioned in some manner to run on separate management domains.
Clusters require inter process communication among cluster members. This is not a significant consideration for the vast majority of WebLogic Server clustered deployments. However, as the number of servers grows very large, and under heavy application load, inter process communication can affect application performance.

Example Considerations:

1) N number of apps( N >200) in a single cluster
— Maximum application interdependence.
Your entire architecture becomes vulnerable to the weakest link, or the most volatile application.

— Management scaling issues
There are a number of scaling issues driven by the (N apps) by (M managed servers) scaling problem.   For the sake of an example, let’s say that to support 200 apps you will need to scale up your cluster to 40 servers.

— Raw performance and cluster scaling issues
The aggregate performance requirements of all these apps may drive you to a cluster/domain deployment size of more than 50 managed servers.   While there are many WebLogic Server clusters that are larger than 50 managed servers, they are a typical, with most clusters being much smaller (8 servers or less). It’s recommended a 32-server cluster (and 32-server domain) as a nominal limit for an application architecture.

2) N apps in N individual domains (N = 100)

— More servers than really required
The recommended practice is to have a separate admin server (from the managed servers).  If you have HA or any scaling requirements in your apps you typically deploy 2+ managed servers.  So such a topological appraoch could lead to requirements for 3+ servers per domain.
As a starting point, applications with different business characteristics (and therefore different development teams, different business owners, different performance, HA, server patching, app maintenance, deployment, configuration management, monitoring and security requirements) should be segregated into different domains. For example keep your intranet apps, external but non-mission critical apps, and external mission-critical apps separate.

It’s recommended a 32-server cluster (and 32-server domain) as a nominal limit for an application architecture. Clusters and domains larger than this size are generally required only for the most demanding applications, and should be deployed only after specific analysis of application performance, management use cases, and long-term maintainability.  If necessary, assess further partitioning of these applications into separate domains.  In some cases an application may need this many servers, but this is rare and in any case such an app is typically mission critical and warrants special review.
It’s recommended using a (N apps) * (M managed servers) “metric” as part of your architectural evaluation, in order to highlight potentially problematic domains, and to identify opportunities for partitioning very large domains into smaller units, and to reduce this metric for any particular domain.  For example:

All 250 apps on a 40 managed server cluster/domain -> 10,000 apps*servers in this domain
250 apps into 4 different clusters/domains of 62 apps and 10 managed servers each -> 620 apps*servers per domain
250 apps into 10 different clusters/domains of 25 apps and 4 managed servers each -> 100 apps*servers per domain
250 apps into 25 different cluster/domains of 10 apps and 2 managed servers each -> 20 apps*servers per domain
250 apps into 200 different clusters/domains of 1 app and 2 managed servers each -> 2 apps*servers per domain

Some rough guidelines for what these metrics might indicate:
– 10,000 – An extremely complex domain environment which will be complex to maintain and manage over time, and should be partitioned into smaller domains.

– 1,000 – Moderately complex clusters/domains, further partitioning should be evaluated.

– 100 – Manageable environment if it meets customer needs

– 10 – Basic domains

– 1 – overly simplistic individual domains

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.