Previous  |  Next  >  
Product: Cluster Server Guides   
Manual: Cluster Server 4.1 User's Guide   

Attribute Dimensions

Dimension Description

Scalar

A scalar has only one value. This is the default dimension.

Vector

A vector is an ordered list of values. Each value is indexed using a positive integer beginning with zero. A set of brackets ([]) denotes that the dimension is a vector. Brackets are specified after the attribute name on the attribute definition. For example, an agent's ArgList is defined as:

static str ArgList[] = { RVG, DiskGroup, Primary, SRL, RLinks }

Keylist

A keylist is an unordered list of strings, and each string is unique within the list. For example, to designate the list of systems on which a service group will be started with VCS (usually at system boot):

AutoStartList = { SystemA, SystemB, SystemC }

Association

An association is an unordered list of name-value pairs. Each pair is separated by a comma. A set of braces ({}) denotes that an attribute is an association. Braces are specified after the attribute name on the attribute definition. For example, to designate the list of systems on which the service group is configured to run and the system's priorities:

SystemList = { SystemA=1, SystemB=2, SystemC=3 }

Type-Dependent Attributes

Type-dependent attributes apply to a particular resource type. For example the MountPath attribute applies only to the Mount resource type. Similarly, the Address attribute applies only to the IP resource type.

Type-Independent Attributes

Type-independent attributes apply to all resource types. This means there is a set of attributes that all agents understand, regardless of resource type. These attributes are coded into the agent framework when the agent is developed. Attributes such as RestartLimit and MonitorInterval can be set for any resource type.

Resource-Specific Attributes

Resource-specific attributes apply to a specific resource. They are discrete values that define the "personality" of a given resource. For example, the IP agent knows how to use the Address attribute. Setting an IP address is done only within a specific resource definition. Resource-specific attributes are set in the main.cf file.

Type-Specific Attributes

Type-specific attributes are set for all resources of a specific type. For example, setting MonitorInterval for the IP resource affects all IP resources. The value for MonitorInterval would be placed in the types.cf file. In some cases, attributes can be placed in main.cf or types.cf. For example, setting StartVolumes = 1 for the DiskGroup types.cf would default StartVolumes to True for all DiskGroup resources. Setting the value in main.cf would set StartVolumes on a per-resource basis.

In the example below, StartVolumes and StopVolumes are set in types.cf. This sets the default for all DiskGroup resources to start all volumes contained in a disk group when the disk group is brought online. If no value for StartVolumes or StopVolumes is set in main.cf, they will default to True.


type DiskGroup (
  static int NumThreads = 1
  static int OnlineRetryLimit = 1
  static str ArgList[] = { DiskGroup, StartVolumes, StopVolumes,
   MonitorOnly }
    str DiskGroup
  str StartVolumes = 1
  str StopVolumes = 1

)Adding the required lines in main.cf allows this value to be modified. In the next excerpt, the main.cf is used to override the default type-specific attribute with a resource-specific attribute:


DiskGroup shared_dg1 (
  DiskGroup = shared_dg1
  StartVolumes = 0
  StopVolumes = 0
)

Static Attributes

Static attributes apply for every resource of a particular type. These attributes are prefixed with the term static and are not included in the resource's argument list. You can override some static attributes and assign them resource-specific values. See Overriding Resource Type Static Attributes for more information.

Global and Local Attributes

An attribute whose value applies to all systems is global in scope. An attribute whose value applies on a per-system basis is local in scope. The "at" operator (@) indicates the system to which a local value applies. An example of local attributes can be found in the MultiNICA resource type where IP addresses and routing options are assigned per machine.


MultiNICA mnic (
Device@sysa = { lan0 = "166.98.16.103", lan0 = "166.98.16.103" }
Device@sysb = { lan0 = "166.98.16.104", lan0 = "166.98.16.104" }
NetMask = "255.255.255.0"
ArpDelay = 5
Options = "trailers"
RouteOptions@sysa = "default 166.98.16.1 1"
RouteOptions@sysb = "default 166.98.16.1 1"
)

Temporary Attributes

You can define temporary attributes in the types.cf file. The values of temporary attributes remain in memory as long as the VCS engine (HAD) is running. These attribute values are not stored in the main.cf file.

The command haattr -add -temp adds the temporary resource into memory. VCS does not require the configuration to be in read/write mode to add or delete these attributes using the command line. If temporary attributes are defined and the configuration is dumped, all temporary attributes and their default values are saved to types.cf. When HAD is restarted, the temporary attributes are defined and available. If HAD is stopped completely within the cluster without an intervening dump, values of temporary attributes are not available when HAD is restarted.

The scope of these attributes is local or global. If the scope is local on any node in the cluster, the value remains in memory after the node fails. Also, local attributes can be defined prior to HAD starting on the node. In the case when HAD is restarted and the node rejoins the cluster, the value remains the same as when the node was running.

You must have the same permissions required to run modification commands from the command line, or the Cluster Manager Java and Web Consoles, regardless of whether an attribute is temporary or not. Some modifications require the configuration be opened; for example, changing an attribute's default value. See Adding, Deleting, and Modifying Resource Attributes for command-line instructions. You can define and modify these attributes only while the VCS engine is running. Temporary attributes cannot be converted to permanent, and vice-versa, but they can persist when dumped to the types.cf file.


Note   Note    Duplicate names are not allowed for temporary attributes on a per-type basis. If a temporary attribute cannot be created, verify that the name does not already exist for that type in the types.cf file.
 ^ Return to Top Previous  |  Next  >  
Product: Cluster Server Guides  
Manual: Cluster Server 4.1 User's Guide  
VERITAS Software Corporation
www.veritas.com