Application Workload Management

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.

This is a perfect place for true N-to-N clustering. N-to-N refers to multiple Service Groups (application groups) running on multiple servers, with each Service Group capable of being failed over to different servers in the cluster. For example, imagine a 4-node cluster, with each node supporting 3 critical database instances.

On failure of any node, each of the three instances is started on a different node, ensuring no node gets overloaded. This is a logical evolution of N + 1, where there is not a need for a "standby system" but rather "standby capacity" in the cluster.

Traditional N-to-N clustering required that each server had enough "standby capacity" to be able to run any of the applications in the cluster. This takes the IT manager back to the same issue that they had before they started Hardware Consolidation - under utilization of hardware resources.

What is required to truly utilize the capabilities of N-to-N clustering is an advanced ability to proactively determine the absolute best node to run an application at time of failure and scalability to handle this decision for unlimited groups simultaneously.

VERITAS Cluster Server provides a unique new feature called Service Group Workload Management to address these issues

Service Group Workload Management (SGWM) is an advanced capability in VCS to proactively determine the best possible system to host an application during start up or following an application or server fault.

At the highest level, SGWM provides necessary tools to make intelligent decisions on start up or failover location based on system capacity and finite resource availability.

At it's most granular level it is capable of proactively managing a cluster consisting of tens or hundreds of application groups by integrating with third party performance measuring tools.

VERITAS Cluster Servers SGWM enables IT Manager to take full advantage of the pendulum swinging back to a (consolidated) centralised computing model and still have the benefits of using Open System Hardware and out of the box software.

VERITAS Cluster server gives the IT managers the application availability that the users are demanding as well as centralized management that IT Manager need. With the SGWM feature in VERITAS Cluster Server IT Manager can be sure that in the event of a failure the applications, VCS will be able to proactively determine on which of the surviving nodes the applications need to start, so the users will not be affect by any performance degradation after a failure to a server in the cluster.