My Guidelines for Combining Applications

Audience: All

Date: November 4, 2002

Here are some of my guidelines for combining applications when consolidating servers. The goal is to reduce the total cost of ownership. This includes not only hardware costs, but also software, facilities and administration. So the guidelines lead to a lower costs, but not necessarily a technically optimum solution.

Combine applications that

• Stress different system resources. (Combine a CPU intensive with an I/O intensive application)
• Have similar service levels (backup, maintenance windows)
• Use same authentication methods (mixing methods on one server can cause problems)
• Have peak utilizations at different times
• Provide the same functionality (ie more than 2 DNS, or application servers)
• Use HACMP. Consolidating 2 clusters (each having a primary/backup server) to 1 cluster, eliminates 2 servers.
• Use 1:1 HACMP clusters (one primary, one backup). Use n:1, multiple primaries, one backup.
• Have multiple components. Client/server became popular when a single server didn't have enough performance to run both application and database. No longer true today.

Avoid combining applications that

• Have high maintenance requirements
• Are unstable (ie memory leaks, frequent reboot)
• Have incompatible OS/patch requirements
• Have large nightly, month end processing requirements

Suggestions

• Co-locate data that use the same database engine. Run multiple instances. Potential for large database cost savings
• Target 60-70% utilization on servers with multiple applications. Peaks tend to be smaller running multiple applications. This is because individual applications utilize less of the overall capacity. (ie if an application averages 10%, peaks at 20%,
• theoverall impact is smaller. ) Use AIX's work load manager to minimize peak contention.
• Run sequentially large batch jobs that contend for the same resources. Can reduce "wall clock time".
• Standardize hardware, applications, and databases. Reduces maintenance, training, support.
• Improve availability. Combining applications will help justify high availability in situations where an individual application doesn't justify HA.

Again, these are guidelines. Every situation is different. Use your best judgement.

Bruce Spencer,
baspence@us.ibm.com

Feedback

11/8/02

There are a few other considerations that may impact your ability to consolidate workload:

Security Issues

• Does the application live outside of a firewall, on a DMZ or another restricted network?
• Does the application require support by an outside 3rd party? If they need to dial into the box, you probably want to isolate them.
• Does the application have highly confidential data such as payroll information that you want to keep isolated?
• Does the application required UNIX shell accounts that could compromise security? I have seen passwords appear as part of the ps output.

Other

• Is the application growing in a significant way? If large growth is expected, let it stabilize before combining with out workloads?
• Does the application require kernel extensions to operate? These run as root and if not written well can cause outages.
• Does the application have hard coded path names, TCP/IP ports, or shared memory segments? These need to be considered.
• Are there multiple instances of an application for availability reasons? For example, you would most likely not combine multiple DNS servers as you want more than one for redundancy purposes.
• Will the ISV support the application if it is on the same server with other workload?
• Are there any contractual or legal issues that force applications to be separate? This may be the case for service bureaus.
• Does the cost of an outage hit the business hardware than the potential savings from consolidating workload?

Thank You
John Banchy
pSeries Technical Support Manager - Central Region (West)