Redundancy
The OPC Router offers various approaches to mitigate outages and ensure that systems remain accessible.
Depending on the selected approach, either the OPC Router itself is operated in a redundant configuration, or the connection to an external target system is switched to an alternative destination. If the OPC Router itself is to be operated in a redundant configuration, Secure Redundancy is the intended approach. You configure this in the OPC Router settings. Additional redundancy and failover options are configured in the appropriate locations, such as within the relevant plug-in or via an upstream reverse proxy.
| Aspect | Secure Redundancy | 3rd-Party Redundancy with Enterprise+ | External HTTP(s) Failover for Server Endpoints |
|---|---|---|---|
| Purpose | Makes the OPC Router itself redundant. | Used to provide a redundant connection to an external target system, such as an alternative OPC server. | Adds a stable external address to the internal OPC Router redundancy. |
| Configuration | Configured in the OPC Router settings. | Configured in the respective plug-in. | Is set up via an upstream reverse proxy. |
| Distinctions and Special Features | Depending on the version, supports additional functions within the redundancy setup, such as project synchronization. | Does not make the OPC Router itself redundant and requires the "Redundant Connection of Third-Party Systems" feature from the Enterprise+ add-on. | Applies to REST, Web Management, and suitable HTTP(s)-based access paths and replaces neither the internal OPC Router redundancy nor the third-party redundancy of an external target system. |
| Using the redundancy settings, a pair of OPC Routers can be configured so that the secondary service takes over in the event of a failure of the primary service. The OPC Router operates in hot standby mode: The secondary service establishes connections to the endpoints while in standby mode and can therefore immediately assume the active role in the event of a failover. Additionally, project synchronization can be used to transfer project states between the two systems. |
This section is divided into the following topics:
- Redundancy Configuration describes the first and second generations of redundancy, with a clear recommendation for the second generation.
- Troubleshooting and Migration provides support for transitioning from legacy to secure redundancy and for addressing typical error scenarios.
- HTTP(s) Failover Concepts describe external access via reverse proxies to REST, OPC UA servers, and web management.
Operational Behavior
As long as the primary service is available, the secondary service remains on standby. If the primary service fails, the secondary service takes over the active role. In the secondary service’s status display, the active state is shown in green and the standby state in blue.
Project synchronization and failover serve different purposes: Project synchronization transfers project states between two OPC routers. HTTP(s) failover, on the other hand, ensures that clients can continue to reach an active endpoint via a stable address.
Topics in this section
Redundancy Configuration
- Current secure redundancy with heartbeat, role switching, and optional project synchronization (2nd generation)
- Differences between 1st and 2nd generation directly in the context of the respective settings
Migration and Troubleshooting
- Differences between Legacy and Secure Redundancy
- Common errors related to firewalls, certificates, and pre-shared keys
Troubleshooting and Migration from Legacy Redundancy to Secure Redundancy
SAP in Redundancy Mode
- Overview of SAP-Specific Considerations in Redundancy Mode
- Notes on Triggers, User Concepts, and Failover Tests
HTTP(s) Failover Concepts
- External failover for RESTful web service, OPC UA server, and web management functions in the OPC Router
- Examples using reverse proxies such as Nginx and Traefik
HTTP(s) Failover Concepts for REST, OPC UA Server, and Web Management in the OPC Router