Visibility, Control and Automation

On demand businesses require high availability and SAMP (Tivoli System Automation for Multi platforms) addresses pain points such as:

• Application availability
• Complexity and operations costs
• Automation implementation and maintenance costs
• Education requirements related to automation
• Rapid changes to an IT landscape

SAMP overcomes these problems through policy-based automation that supports grouping of resources and relationships. SAMP can do this in environments where applications run on diverse platforms. SAMP helps you to remain competitive, flexible, and responsive to operate in a cost effective manner.

SAMP provides high availability and policy-based automation for applications and services across heterogeneous environments. It ensures continuous high availability and reduces frequency and duration of service disruptions for critical applications and middle ware running on heterogeneous platforms and virtualization technologies.

Tivoli System Automation for Multi platforms is a high-availability cluster solution that provides several monitoring mechanisms to detect system failures and a set of rules to initiate the correct action without any user intervention. The set of rules is called a policy, This policy describes the relationships between applications or resources. This provides System Automation for Multi platforms with extensive up-to-date information about the system landscape so that it can restart the resource on the current node or move the whole application to another cluster node.

Fault tolerance relies on specialized hardware to detect a hardware fault and instantaneously switch to a redundant hardware component whether the failed component is a processor, memory board, power supply, I/O subsystem, or storage subsystem. The fault tolerant model does not address software failures, by far the most common reason for downtime.


High availability views availability not as a series of replicated physical components, but rather as a set of system-wide, shared resources that cooperate to guarantee essential services. High availability combines software with industry-standard hardware to minimize downtime by quickly restoring essential services when a system, component, or application fails. While not instantaneous, services are restored rapidly, often in less than a minute.


The difference between fault tolerance and high availability is that a fault tolerant environment has no service interruption but a significantly higher cost, while a highly available environment has a minimal service interruption. Many sites are willing to absorb a small amount of downtime with high availability rather than pay the much higher cost of providing fault tolerance. Additionally, in most highly available configurations, the backup processors are available for use during normal operation. High availability systems are an excellent solution for applications that must be restored quickly and can withstand a short interruption should a failure occur. A few industries have time-critical applications and cannot withstand even a few seconds of downtime. However, many other industries can withstand small periods of time when their database is unavailable. For those industries, SAMP can provide the necessary continuity of service without total redundancy.

People are generally confused about the level of redundancy they need to provide while designing a HA solution. The cardinality of the primary to secondary components can be described in the following way and this decides the deployment topology of the various components:

• N+1 — provides a single additional node that is brought online to take over the role of the node that has failed. In the case of heterogeneous software configuration on each primary node, the additional node must be universally capable of assuming any of the roles of the primary nodes it is responsible for. This normally refers to clusters which have multiple services running simultaneously; in the single service case, this degenerates to Active/Passive.
• N+M — in cases where a single cluster is managing many services, having only one dedicated failover node may not offer sufficient redundancy. In such cases, more than one (M) standby servers are included and available. The number of standby servers is a tradeoff between cost and reliability requirements.
• N-to-1 — allows the failover standby node to become the active one temporarily, until the original node can be restored or brought back online, at which point the services or instances must be failed-back to it in order to restore High Availability.
• N-to-N — A combination of Active/Active and N+M clusters, N to N clusters redistribute the services or instances from the failed node among the remaining active nodes, thus eliminating (as with Active/Active) the need for a 'standby' node, but introducing a need for extra capacity on all active nodes.

Clustering is the most common technique to achieve High availability for any services by introducing redundancy in software, hardware and data. In a failure the clustering software immediately start the application on the standby system without requiring administrative intervention. Depending on the type of redundancy in software to be provided for High Availability, clusters can be configured in any of the following configurations:

• Cold Standby: The secondary node acts as backup of another identical primary system. It will be installed and configured only when the primary node breaks down for the first time. Subsequently, In the  case of a failure in the primary the secondary node is powered on and the data restored before finally starting the failed component. Data from primary system can be backed up on a storage system and  restored on secondary system as and when required. This generally provides a recovery time of a few hours.
• Warm Standby: The software component is installed and available on the secondary node. The secondary node is up and running. In the case of a failure on the primary node, these software components are started on the secondary node. This process is usually automated using a cluster manager.Data is regularly mirrored to secondary system using disk based replication or shared disk. This generally provides a recovery time of a few minutes.
• Hot Standby: Software components are installed and available on both primary and secondary nodes. The software components on the secondary system are up but will not process data or requests. Data is mirrored in near real time and both systems will have identical data. Data replication is typically done through the software’s capabilities. This generally provides a recovery time of a few seconds.
• Active-Active (Load Balanced): In this method both the primary and secondary systems are active and processing requests in parallel. Data replication happens through software capabilities and would be bi-directional. This generally provides a recovery time that is instantaneous.