Each Server maintains a list of ServerUris for all redundant Servers in the RedundantServerSet. The list is provided together with the Failover mode in the ServerRedundancy Object defined in OPC 10000-5. To enable Clients to connect to all Servers in the list, each Server in the list shall provide the ApplicationDescription for all Servers in the RedundantServerSet through the FindServers Service. This information is needed by the Client to translate the ServerUri into information needed to connect to the other Servers in the RedundantServerSet. Therefore a Client needs to connect to only one of the redundant Servers to find the other Servers based on the provided information. A Client should persist information about other Servers in the RedundantServerSet.

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

Table 111 – Redundancy Failover actions

Failover mode and Client options	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 Subscriptions and 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 Subscriptions and add monitored items.	X
Activate sampling on the Subscriptions.	X	X
Activate publishing.	X	X	X

Clients communicating with a non-transparent RedundantServerSet of Servers require some additional logic to be able to handle Server failures and to Failover to another Server in the RedundantServerSet. Figure 28 provides an overview of the steps a Client typically performs when it is first connecting to a RedundantServerSet. The figure does not cover all possible error scenarios.

Figure 28 – Client Start-up steps

The initial Server may be obtained via standard discovery or from a persisted list of Servers in the RedundantServerSet. 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 Failover mode the Server provides and the Failover mode the Client will use.

Clients once connected to a redundant Server shall be aware of the modes of Failover supported by a Server since this support affects the available options related to Client behaviour. A Client may always treat a Server using a lesser Failover mode, 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 Redundancy or Cold Redundancy. This choice is up to the Client. In the case of Failover mode HotAndMirrored, the Client shall not use Failover mode Hot or Warm as it would generate unnecessary load on the Servers.

A Cold Failover mode is where the Client can only connect to one Server at a time. When the Client loses connectivity with the Active Server it will attempt a connection to the redundant Server(s) which may or may not be available. In this situation the Client may need to wait for the redundant Server to become available and then create Subscriptions and MonitoredItems and activate publishing. The Client shall cache any information that is required related to the list of available Servers in the RedundantServerSet. Figure 29 illustrates the action a Client would take if it is talking to a Server using Cold Failover mode.

Figure 29 – Cold Failover

NOTE There may be a loss of data from the time the connection to the Active Server is interrupted until the time the Client gets Publish Responses from the backup Server.

A Warm Failover mode is where the Client should connect to one or more Servers in the RedundantServerSet primarily to monitor the ServiceLevel. A Client can connect and create Subscriptions and MonitoredItems on more than one Server, but sampling and publishing can only be active on one Server. However, the active Server will return actual data, whereas the other Servers in the RedundantServerSet will return an appropriate error for the MonitoredItems in the Publish response such as Bad_NoCommunication. The one Active Server can be found by reading the ServiceLevel Variable from all Servers. The Server with the highest ServiceLevel is the Active Server. For Failover the Client activates sampling and publishing on the Server with the highest ServiceLevel. Figure 30 illustrates the steps a Client would perform when communicating with a Server using Warm Failover mode.

Figure 30 – Warm Failover

NOTE There may be a temporary loss of data from the time the connection to the Active Server is interrupted until the time the Client gets Publish Responses from the backup Server.

A Hot Failover mode is where the Client should connect to two or more Servers in the RedundantServerSet and to subscribe to the ServiceLevel variable defined in OPC 10000-5 to find the highest ServiceLevel to achieve load balancing; this means that Clients should issue Service requests such as Browse, Read, Write to the Server with the highest ServiceLevel. Subscription related activities will need to be invoked for each connected Server. Clients have the following choices for implementing Subscription behaviour in a Hot Failover mode:

1. The Client connects to multiple Servers and establishes Subscription(s) in each where only one is Reporting; the others are Sampling only. The Client should setup the queue size for the MonitoredItems such that it can buffer all changes during the Failover time. The Failover time is the time between the connection interruption and the time the Client gets Publish Responses from the backup Server. On a Failover the Client shall enable Reporting on the Server with the next highest availability.
2. The Client connects to multiple Servers and establishes Subscription(s) in each where all Subscriptions are Reporting. The Client is responsible for handling/processing multiple Subscription streams concurrently.

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

Figure 31 – Hot Failover

Clients are not expected to automatically switch over to a Server that has recovered from a failure, but the Client should establish a connection to it.

A HotAndMirrored Failover mode is where a Client only connects to one Server in the RedundantServerSet because the Server will share this session/state information with the other Servers. In order to validate the capability to connect to other redundant Servers it is allowed to create Sessions with other Servers and maintain the open connections by periodically reading the ServiceLevel. A Client shall not create Subscriptions on the backup Servers for status monitoring (to prevent excessive load on the Servers). This mode allows Clients to fail over without creating a new context for communication. On a Failover the Client will simply create a new SecureChannel on an alternate Server and then call ActivateSession; all Client activities (browsing, subscriptions, history reads, etc.) will then resume. Figure 32 illustrate the behaviour a Client would perform when communicating to a Server in HotAndMirrored Failover mode.

Figure 32 – HotAndMirrored Failover

This Failover mode is similar to the transparent Redundancy. The advantage is that the Client has full control over selecting the Server. The disadvantage is that the Client needs to be able to handle Failovers.