When configuring Citect SCADA the following clustering rules apply:

• Each cluster needs to have a unique name.
• Each server process needs to have a unique name.
• Each server process needs to belong to one cluster.
• Each cluster can contain only one pair of redundant Alarm Servers. They need to reside on different machines.
• Each cluster can contain only one pair of redundant Reports Servers. They need to reside on different machines.
• Each cluster can contain only one pair of redundant Trends Servers. They need to reside on different machines.
• Each cluster can contain an unlimited number of I/O Servers.

The diagram below is an example of a system running with two clusters across three machines. Every server and client component have been deployed in accordance with the clustering rules.

The next diagram demonstrates circumstances where clustering is not configured correctly.

The Citect SCADA compiler or the Citect SCADA Runtime Manager detects when the rules of clustering are not being observed and advises the user accordingly.

The Cluster Name can either be explicitly specified when the item is called or displayed, or an item can use the default cluster context of the calling process or page. If your system has only one cluster, you don't need to specify a cluster name. Single cluster systems always use that cluster and will not require the use of cluster prefixes.

Cluster context, therefore, is the default cluster used for tag resolution and execution of expressions and Cicode functions. Citect SCADA will automatically resolve tags without a cluster context if every tag name in the project is unique.

In the case of tags and tag references, a cluster is explicitly supplied by prefixing the tag name or tag reference with the cluster name. For built-in Cicode functions ClusterName is usually an optional parameter. Variable Tags referenced in an Alarms, Reports or Trends Server context are implicitly resolved to that cluster unless explicitly stated otherwise using a cluster prefix such as ClusterName.TagName.

Server processes (Alarm, Trend, Report) have their default cluster context set to their own cluster, so that, for example, Alarm definitions that contain variable tags without clusters explicitly supplied will attempt to resolve those tags to their own cluster. Cicode tasks started from server code will inherit the servers cluster unless one is explicitly given. For built-in Cicode functions ClusterName is usually an optional parameter.

Graphics pages have no cluster context by default. A page's cluster can be supplied statically in the page appearance properties, can be inherited from a previous context, or can be applied dynamically using an optional parameter in the Cicode function that displayed the page. Any Cicode tasks started from a page will inherit the cluster context of that page. Graphics pages have no default cluster and will not inherit context in multi-cluster systems by default.

The TaskNew Cicode function inherits the caller's (either page or task) cluster context unless explicitly overridden.

Citect SCADA will allow tags or tag references without a cluster context specified to be automatically resolved if every tag name in the project is unique. This means if you use a unique naming convention for your tags, you will be able to configure a multi-clustered system without having to specify cluster context. For any tags that are not unique, #COM will be displayed if cluster context cannot be determined.

Note: This capability is enabled by default via the parameter[General]TagDB.