Application Workload Management (page 1 of 2)

IT started with this centralised computing model. It then moved towards a distributed (Open system) model.

The main factor that facilitated this move towards the distributed computing model was the cost associated with the running of Mainframes and their associated software in comparison the cost of the open system and out of the box software was much cheaper.

Thus multiple UNIX (open systems) were deployed to solve a number of business problems that were traditionally handled by a single Mainframe. It now seems that the pendulum is swinging back towards a centralised model.

As open systems proliferated, IT managers became concerned with the impact of system outages on various business units. These concerns led to the development of tools to increase overall system availability. The Server and Storage vendors started to develop systems with no-single-points-of-failures (SPOF).

Storage systems were built with the ability to have multiple serves attached to the storage. By "dual-hosting" a given storage array, the spare server could be brought online quicker in the event of failure.

This evolutionary process continued with the development of Cluster Software to automate the discovery of failures and to failover applications to a stand-by server in the event of a failure.

Over the past four to five years, open systems have gained significant computing power and expandability. Rather than a single, or dual-processor system with memory measured in megabytes and storage in hundreds of megabytes, systems evolved to tens or even hundreds of processors, gigabytes of memory and terabytes of disk capacity.

This drastic increase in processing power allowed IT managers to begin to consolidate applications onto larger systems to reduce administrative complexity and hardware footprint.

These "enterprise-class" systems have replaced departmental and workgroup-level servers throughout organizations. Clustering Software has developed in tandem with Open System Servers and Storage. As a result most clustering packages are capable of managing multiple applications running on 2 or more servers connected to a SAN.

This recent trend of Hardware Consolidation is being driven by IT managers who wish to move from large numbers of small open systems with direct attached storage (many running at far less than capacity) to a much smaller number of large scale enterprise serves with SAN or NAS attached storage running at near max capacity. This is less expensive to operate but does lead to greater exposure to failures.

If a system goes down it's not just one business unit that's affected, but all the business units, that have applications running on that system, which are affected.

One possible solution is N+1clustering, where one enterprise class server can provide redundancy for multiple active servers. This partially solves the problem, as it reduces the cost of redundancy for a given set of applications.

N+1 also simplifies failover location choices, as all applications running on a failed server simply move to the spare server. However N+1 clustering starts to fall short in true Hardware Consolidation environments.

IT Managers require the ability to withstand multiple cascading failures, or take systems offline for maintenance and still have adequate redundancy in the server cluster.

Typical clustering packages are unable to meet this need, as the amount of flexibility is limited when it comes to choosing the proper hosts for potentially tens or hundreds of application groups.