This document describes the terminology used with IBM Tivoli System Automation for Multiplatforms.
IBM® Tivoli® System Automation manages the availability of applications running in Linux systems or clusters on xSeries® , zSeries®, iSeries™, pSeries®, and AIX® systems or clusters. It consists of the following features:
- High availability and resource monitoring
- Policy-based automation
- Automatic recovery
- Automatic movement of applications
- Resource grouping
The following terms are used with the Tivoli System Automation when describing IBM Tivoli System Automation for Multiplatforms:
Cluster / peer domain
The group of host systems upon which Tivoli System Automation manages resources is known as a cluster. A cluster can consist of one or more systems or nodes. The term "peer domain" is also used when referring to a cluster. (The two terms are interchangeable.)
A single host system that is part of a Tivoli System Automation cluster. Tivoli System Automation v1.2 supports up to 32 nodes within a cluster.
A resource is any piece of hardware or software that can be defined to Tivoli System Automation. Resources have characteristics, or attributes, that can be defined. For example, when considering an IP address as a resource, attributes would include the IP address itself and the net mask.
A resource attribute describes some characteristics of a resource. There are two types of resource attributes: persistent attributes and dynamic attributes.
The attributes of the IP address just mentioned (the IP address itself and the net mask) are examples of persistent attributes. They describe enduring characteristics of a resource. While you could change the IP address and net mask, these characteristics are, in general, stable and unchanging.
Dynamic attributes represent changing characteristics of the resource. Dynamic attributes of an IP address, for example, identify such things as its operational state.
A resource class is a collection of resources of the same type.
Resource groups are logical containers for a collection of resources. This container enables you to control multiple resources as a single logical entity. Resource groups are the primary mechanism for operations within Tivoli System Automation.
A managed resource is a resource that has been defined to Tivoli System Automation. To accomplish this, the resource is added to a resource group, at which time it becomes manageable through Tivoli System Automation.
The nominal state of a resource group indicates to Tivoli System Automation whether the resources with the group should be online or offline at this point in time. So setting the nominal state to Offline indicates that you wish for Tivoli System Automation to stop the resources in the group, and setting the nominal state to Online indicates that you wish to start the resources in the resource group. You can change the value of the NominalState resource group attribute, but you cannot set the nominal state of a resource directly.
An equivalency is a collection of resources that provides the same functionality. For example, equivalencies are used for selecting network adapters that should host an IP address. If one network adapter goes offline, IBM Tivoli System Automation selects another network adapter to host the IP address.
Tivoli System Automation enables the definition of relationships between resources in a cluster. There are two different relationship types:
Start-stop relationships are used to define start and stop dependencies between resources. You can use the StartAfter, StopAfter, DependsOn, DependsOnAny, and ForcedDownBy relationships to achieve this. For example, if a resource must be started only after another resource was started, you can define this by using the policy element StartAfter relationship.
Location relationships are applied when resources must, or should if possible, be started on the same or a different node in the cluster. Tivoli System Automation provides the following location relationships: Collocation, AntiCollocation, Affinity, AntiAffinity, and IsStartable.
The main goal of quorum operations is to keep data consistent and to protect critical resources. Quorum can be seen as the number of nodes in a cluster that are required to modify the cluster definition or perform certain cluster operations. There are two types of quorum:
Configuration quorum determines when configuration changes in the cluster will be accepted. Operations affecting the configuration of the cluster or resources are allowed only when the absolute majority of nodes is online.
Operational quorum is used to decide whether resources can be safely activated without creating conflicts with other resources. In case of a cluster splitting, resources can only be started in the subcluster that has a majority of nodes or obtained a tie breaker.
In case of a tie in which a cluster has been partitioned into two subclusters with an equal number of nodes, the tie breaker is used to determine which subcluster will have an operational quorum.
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.