Each Server maintains a list of ServerUrisfor all redundant Serversin the Redundant Server Set. The list is provided together with the Failovermode in the ServerRedundancy Objectdefined in OPC 10000-5. To enable Clients to connect to all Serversin the list, each Serverin the list shall provide the ApplicationDescriptionfor all Serversin the Redundant Server Setthrough the FindServers Service. This information is needed by the Clientto translate the ServerUriinto information needed to connect to the other Serversin the Redundant Server Set. Therefore a Clientneeds to connect to only one of the redundant Serversto find the other Serversbased on the provided information. A Clientshould persist information about other Serversin the Redundant Server Set.

Table 111defines a list of Clientactions for initial connections and Failovers.

Table 111– Redundancy Failover actions

Failover mode and Clientoptions

Cold

Warm

Hot (a)

Hot (b)

HotAndMirrored

On initial connection in addition to actions on Active Server:

Connect to more than one OPC UA Server.

X

X

X

Optional for status check

Create Subscriptionsand add monitored items.

X

X

X

Activate sampling on the Subscriptions.

X

X

Activate publishing.

X

At Failover:

OpenSecureChannel to backup OPC UA Server

X

X

CreateSession on backup OPC UA Server

X

ActivateSession on backup OPC UA Server

X

X

Create Subscriptionsand add monitored items.

X

Activate sampling on the Subscriptions.

X

X

Activate publishing.

X

X

X

Clientscommunicating with a non-transparent Redundant Server Setof Serversrequire some additional logic to be able to handle Server failures and to Failoverto another Server in the Redundant Server Set. Figure 28provides an overview of the steps a Clienttypically performs when it is first connecting to a Redundant Server Set. The figure does not cover all possible error scenarios.

image031.png

Figure 28– Client Start-up steps

The initial Server may be obtained via standard discovery or from a persisted list of Serversin the Redundant Server Set. But in any case the Client needs to check which Server in the Server set it should connect to. Individual actions will depend on the Server Failovermode the Server provides and the Failovermode the Client will use.

Clients once connected to a redundant Server shall be aware of the modes of Failoversupported by a Serversince this support affects the available options related to Client behaviour. A Client may always treat a Server using a lesser Failovermode, i.e. for a Server that provides Hot Redundancy, a Client might connect and choose to treat it as if the Server was running in Warm Redundancyor Cold Redundancy. This choice is up to the Client. In the case of Failovermode HotAndMirrored, the Clientshall not use Failovermode Hotor Warmas it would generate unnecessary load on the Servers.

A Cold Failovermode is where the Clientcan only connect to one Serverat a time. When the Clientloses connectivity with the Active Serverit will attempt a connection to the redundant Server(s) which may or may not be available. In this situation the Clientmay need to wait for the redundant Serverto become available and then create Subscriptionsand MonitoredItemsand activate publishing. The Client shall cache any information that is required related to the list of available Serversin the Redundant Server Set. Figure 29illustrates the action a Client would take if it is talking to a Server using Cold Failovermode.

image032.png

Figure 29– Cold Failover

NOTE There may be a loss of data from the time the connection to the Active Serveris interrupted until the time the Clientgets Publish Responsesfrom the backup Server.

A Warm Failovermode is where the Clientshould connect to one or more Serversin the Redundant Server Setprimarily to monitor the ServiceLevel. A Clientcan connect and create Subscriptionsand MonitoredItemson more than one Server,but sampling and publishing can only be active on one Server. However, the active Serverwill return actual data, whereas the other Serversin the Redundant Server Setwill return an appropriate error for the MonitoredItemsin the Publishresponse such as Bad_NoCommunication. The one Active Servercan be found by reading the ServiceLevel Variablefrom all Servers. The Serverwith the highest ServiceLevelis the Active Server. For Failoverthe Clientactivates sampling and publishing on the Serverwith the highest ServiceLevel. Figure 30illustrates the steps a Client would perform when communicating with a Server using Warm Failovermode.

image033.png

Figure 30– Warm Failover

NOTE There may be a temporary loss of data from the time the connection to the Active Serveris interrupted until the time the Clientgets Publish Responsesfrom the backup Server.

A Hot Failovermode is where the Clientshould connect to two or more Serversin the Redundant Server Setand to subscribe to the ServiceLevelvariable defined in OPC 10000-5to find the highest ServiceLevelto achieve load balancing; this means that Clientsshould issue Servicerequests such as Browse, Read, Writeto the Serverwith the highest ServiceLevel. Subscriptionrelated activities will need to be invoked for each connected Server. Clientshave the following choices for implementing Subscriptionbehaviour in a Hot Failovermode:

  1. The Clientconnects to multiple Serversand establishes Subscription(s) in each where only one is Reporting; the others are Samplingonly. The Clientshould setup the queue size for the MonitoredItemssuch that it can buffer all changes during the Failovertime. The Failovertime is the time between the connection interruption and the time the Clientgets Publish Responsesfrom the backup Server. On a Failoverthe Clientshall enable Reportingon the Serverwith the next highest availability.
  2. The Clientconnects to multiple Servers and establishes Subscription(s) in each where all Subscriptionsare Reporting. The Clientis responsible for handling/processing multiple Subscriptionstreams concurrently.

Figure 31illustrate the functionality a Client would perform when communicating with a Server using Hot Failovermode (the figure include both (a) and (b) options)

image034.png

Figure 31– Hot Failover

Clientsare not expected to automatically switch over to a Serverthat has recovered from a failure, but the Clientshould establish a connection to it.

A HotAndMirrored Failovermode is where a Clientonly connects to one Server in the Redundant Server Setbecause the Serverwill share this session/state information with the other Servers. In order to validate the capability to connect to other redundant Serversit is allowed to create Sessionswith other Serversand maintain the open connections by periodically reading the ServiceLevel. A Clientshall not create Subscriptionson the backup Serversfor status monitoring (to prevent excessive load on the Servers). This mode allows Clientsto fail over without creating a new context for communication. On a Failoverthe Clientwill simply create a new SecureChannelon an alternate Serverand then call ActivateSession; all Clientactivities (browsing, subscriptions, history reads, etc.) will then resume. Figure 32illustrate the behaviour a Client would perform when communicating to a Server in HotAndMirrored Failovermode.

image035.png

Figure 32– HotAndMirrored Failover

This Failovermode is similar to the transparent Redundancy. The advantage is that the Clienthas full control over selecting the Server. The disadvantage is that the Clientneeds to be able to handle Failovers.