Redundancy

From UaCapabilities
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Introduction

OPC UA enables Servers, Clients and networks to be redundant. OPC UA provides the data structures and Services by which Redundancy may be achieved in a standardized manner.
Generally speaking, we can apply redundancy to: servers/clients, communication paths and signals. Although the specification limits redundancy support to client/server redundancy, product vendors can incorporate other kinds of redundancy into the framework proposed by the specification. For example, a server can establish wireless connection as the means of recovery from cable connection failure or a server can use many data sources bound to a variable to provide continuous updating of the variable value even if one of the sensors has been damaged.
Note – Redundancy is defined in OPC UA Part 4, the Information Model is specified in OPC UA Part 5.

Redundancy Capabilities

Server Transparent Failover

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#Server_Transparent_Failover

Description
Server failover is transparent to the Client: the Client does not care or even know that failover has occurred.

Usage Considerations

  • No Client code required to keep connection operational.
  • Clients able to determine
    • which Servers are in the redundant set
    • the service level of each server
    • which Server is currently responsible for the client session
    • Client-Server connection information is synchronized across servers

Conformance Testing

Client Server

Nothing needed in the Client.

Transparent failover

Server Non-Transparent Failover

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#Server_Non-Transparent_Failover

Description
Client is aware that Server failover has occurred. When a Server fails, the number of actions required by Client depends on the failover mode supported by the Server.
There are four failover modes: Cold, Warm, Hot and HotAndMirrored. Failover for this type of redundancy requires the Client to monitor Server status and to switch to a backup Server if it detects a failure. The failover method tells the Client what it must do when connecting to a Server and when a failure occurs. Cold redundancy requires a Client to reconnect to a backup Server after the initial Server has failed. Warm redundancy allows a Client to connect to multiple Servers, but only one Server will be providing values. In hot redundancy multiple Servers are able to provide data and a Client can connect to multiple Servers for the data.


Usage Considerations
Client must use failover mode to determine required actions to take when Server fails.


Conformance Testing

Client Server

Switch to a backup Server if failure is detected

Non-transparent redundancy

Backup Client

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#Backup_Client

Description
Enables backup clients to monitor the active client’s session with the server. Backup clients are able to instruct the server to transfer subscriptions if the active client has failed.

Usage Considerations

  • Client failover requires server capabilities.
  • Possible to achieve no data loss upon recovery from client failover

Conformance Testing

Client Server

Client redundancy

Server support for redundant Clients

Multiple Network Paths

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#Multiple_Network_Paths

Description
Enables access to the same Server via different network paths.

Usage Considerations

  • If transparent, then handled by the network infrastructure
  • If non-transparent, then a Server exposes different endpoints for each path.

Conformance Testing

Client Server

TBD

TBD