Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Consolidating Applications
Understanding which server resources applications use and understanding usage patterns is essential to the process of consolidating servers. This process is explained in detail in the chapters about assessment and architecture.
Everywhere we go to talk about consolidation, people always ask which applications they should or should not consolidate. There is no easy answer to this question, and you need to evaluate each application individually. The people who know the applications best are the developers, database administrators, and system administrators who take care of them on a daily basis. Talking with these people usually identifies good and bad consolidation candidates rather quickly.
Eliminating Consolidation Candidates
While it is not easy to make specific recommendations about which applications are good consolidation candidates, there are some general guidelines you can follow to eliminate candidates from consolidation.
First and foremost, consider eliminating all servers and storage that are deliberately isolated for other servers. This includes:
Firewalls
Intrusions detection servers
Sensitive databases
Geographically separated servers
Isolation and separation are vital attributes of many security-related servers. Unless you are specifically targeting these machines, they are probably too complex to consolidate without a complete reevaluation of the security architecture. After you have consolidated the rest of your environment, you can come back and look for opportunities for security consolidations. The same is true for servers or storage that are geographically separated. For instance, if you have separated servers for redundancy or wide area network (WAN) reasons, it hardly makes sense to try to consolidate these together.
Third-party applications developed and sold by independent software vendors (ISVs) may be problematic as consolidation candidates. In many cases, ISVs specify that their applications run in standalone mode on their own servers. If this is not done, they usually do not provide support for the application. Make sure you check with your vendors for their support requirements.
Other applications that do not qualify for consolidation include those that lock up system resources such as physical memory. If you aren't sure about an application's suitability for consolidation in this respect, make sure you analyze it with a performance tool such as TeamQuest or BMC's Patrol-Perform and Predict.
Applying Backward and Forward Consolidation Strategies
When most people begin their consolidation efforts, they often focus on existing applications. This process is known as a backward consolidation. In many cases, these consolidations are hugely successful. In others, organizational issues prevent them from achieving their goals. There is no doubt that some of the largest and most successful consolidations we have seen have been backward consolidations.
To avoid future server sprawl, it is also important to begin to develop new applications in a consolidated environment, referred to as forward consolidation. It's interesting to note that applications that are developed in a consolidated environment usually behave with each other, and can be moved into production in a consolidated environment.
Consolidating Application Sets
When you analyze a group of servers for consolidation, it is important to identify the applications that run on them. It is equally important to identify the servers and applications with which the consolidation candidates interact. It's very common to find groups of applications that receive data from other applications or that supply data to other applications. Because these applications process information sequentially, they are often excellent candidates for consolidation. These application sets don't usually compete for the same resources at the same time, and when you group them within a single instance of the OS, you often find that they perform better because of intra-domain communications. A decrease in network traffic is often a side benefit of consolidating application sets.
When deciding which application sets to consolidate, we generally categorize them as being tightly coupled or loosely coupled. In tightly coupled application sets, applications actively interact with each other. In loosely coupled sets, a group of applications acquire and process data and then pass them on to the next server.
As an example of a successful consolidation of tightly coupled applications, consider a situation where a customer gathered home-grown Enterprise Resource Planning applications, Tuxedo messaging, and an Oracle database server and moved them into a single instance of the OS. The results were extremely successful. Application throughput increased, and network usage decreased. From a scalability viewpoint, the transaction volume of the application set increased from roughly 40,000 sales order lines per day two years ago to over 400,000 sales order lines per day. This was obviously a successful consolidation and a successful application of vertical scalability.
As an example of a loosely coupled application set, consider a situation where a server runs an online transaction processing (OLTP) application during the day, then at night, passes the transaction information to a batch server for further processing and reporting. The batch server would then update a data warehouse server, which would, in turn, update multiple data mart servers. Each server depends on another, but not simultaneously.
Consolidating Multiple Database Instances
A very common example of server and application consolidation is to put multiple instances of a database in a single instance of the OS. This is a very common tactic with most major databases. It's important to note that you don't want to mix these two databases on the same instance of the OS; doing so may cause fatal application conflicts.
The success of this consolidation strategy depends heavily on development standards and practices. Where strict naming conventions are followed and each instance of the database is unique, consolidations are successful. However, on an occasion when we worked with a customer who wrote multiple Oracle applications and chose to use default naming conventions, multiple conflicts resulted between database instances. Obviously, this consolidation was not successful.
Consolidating Similar Workloads
Another consolidation technique that some consultants recommend is to consolidate similar workloads with like resource usage and time scheduling. If you do this, you need to understand the application's resource usage very clearly. When using this consolidation technique, the key to success is that you must offset the timing of resource usage for each workload. Otherwise, you simply end up with overlapping peaks and valleys of resource usage.