Controlled Redundancy

With GenBroker, you can add a point that controls whether a classic OPC server should be considered alive for redundancy switching. You can gain this level of control for the following types of redundant servers:

AlarmWorX64 Server
OPC DA Servers
AlarmWorX32 Server
TrendWorX32 HDA

(For a better understanding of how redundancy for these servers is configured, refer to the Classic OPC Redundancy topic.)

How Redundancy Works

To understand how this feature works, first you need to understand how redundancy works in GENESIS64. Let's look at a redundant pair of classic OPC servers that have been paired using the Redundancy Node Pairs tab in GenBroker. With this pair of servers, the active server always has a stand-by or backup server that can take over if the active server becomes unavailable. In this simple scenario, if the device fails but the OPC server continues to run, GENESIS64 has no reason to switch over to the backup OPC server and device because GENESIS64 can continue to communicate with the OPC server and the OPC server keeps responding. GENESIS64 is unaware that the device has failed. Or if you plan to do a maintenance on your OPC DA server you may want to make sure the values of OPC tags from the server do not get propagated to the ICONICS OPC Clients.

You can easily address these issues. Each OPC server in the pair has a point that indicates whether the underlying device is working properly. If the underlying device fails, you can force GENESIS64 to switch over to the backup OPC DA server even though the active OPC DA server is still alive. To do this, you must define a point to be used as the controlling point for the redundant server. When the controlling point returns a 0 (zero) value or bad quality, GENESIS64 will consider the server offline (not available), even if the server continues to respond. When setting up controlled redundancy, you can define any GenClient point as the controlling point - it doesn't have to be a point from the same server as the node being monitored.

Controlled Switch Over

When you are using controlled redundancy for a server that is part of a redundant pair, the active server switches over to the stand-by server when either of the following occurs:

A controlling point that has been defined for the active server returns a 0 or bad quality.
The active server stops responding.

Note this works only when redundancy has been set up for the server you're assigning a controlling point to and the active license contains DWX32 Pro license bit. If the server specified is not in a redundant pair, then the controlling point will not do anything with it.

Steps

Follow these steps to set up this controlled switch over for servers that are configured for redundancy on the Redundancy Node Pairs tab of GenBroker:

In the classic Workbench, select the FrameWorX Server bar from the Project Explorer.
Expand the server node, and expand Classic OPC, then double-click GenBroker. GenBroker opens with its Channels tab on top. (Note the GenBroker communication options can be set here, too.)
Go to the Redundancy Node Pairs tab and confirm that the servers for which you are controlling a switch over are defined in node pairs on this tab.
Go to the Controlled Redundant Servers tab (shown below) and complete the following information for each server:
- Node: The node being monitored for redundancy that requires the added control of the controlling point.
- Server ProgID: The OPC server where the controlling point is based.
- Controlling Point: Specify the point that forces a switch over even if the server is still running. If this point returns a 0 (zero) value or bad, the server will be considered offline and GENESIS64 will switch over to the node's backup node. This must be a point that comes from GenClient, i.e., it must be a point starting with the @ character. The syntax for this point is as follows: @\\node_name\OPC_driver\controlling_tag.Value
Click Apply when you are done.

GenBroker's Controlled Redundant Servers Tab

Client-Side Control Points Updated

The following client-side control points were changed between V10.5 and V10.7. They have different names and slightly different meanings). All these points are read-only.

#Fwx.PrimaryLoadBalancer - address of primary load balancer. In non-load-balancing setups, this is the address of the primary server. This is the primary node set in Workbench - Tools - Default FrameWorX Server location.
#Fwx.ActiveLoadBalancer - address of the currently active load balancer. It is the address of the FwxServer that tells the client what FwxServer it should connect to (in load-balancing scenarios). In non-load-balancing setups, this is the address of the active server.
#Fwx.ActiveLoadBalancerIndex - zero-based index of load balancer (0 for primary, 1 for secondary). Corresponds to #Fwx.ActiveLoadBalancer.
#Fwx.ActiveServer - address of FwxServer the client is connected to. In non-load-balancing setups this is the same as #Fwx.ActiveLoadBalancer. In load-balancing scenarios, this is the address the client was forced to connect to (by the active load balancer).

Also, the old names have been mapped to the new ones with the updated meanings.

For compatibility with V10.5, the following points were implemented in V10.7. Note that the meaning may be slightly different from 10.5, because load-balancing has been introduced. Also note #Session.FwxActiveUrlIndex in no longer writeable.

#Session.FwxPrimaryUrl - same as #Fwx.PrimaryLoadBalancer
#Session.FwxActiveUrl - same as #Fwx.ActiveServer
#Session.FwxActiveUrlIndex - same as #Fwx.ActiveLoadBalancerIndex

The points are not browseable and must be manually typed in. This is by design.