Tech Note 109: How to Implement I/O and Object “Load Balancing” & “Redundancy”

Summary

There are multiple concepts concerning redundancy and load balancing when discussing the Wonderware Application Server solution. The purpose of this document is to clearly define the concepts of both I/O and Application Object failover and load balancing.

Procedure

1. The first objects you must create are Platforms; furthermore, a “Platform” simply represents a specific computer. For the example in this document we will create 3 Platforms, which are 1 for the GR (Galaxy Repository), 1 for our first AOS (Application Object Server), and finally 1 for our second AOS.

NOTE: All AOS Platforms should be configred identically, with exception to the “Network address” & “Redundancy message channel IP address” Fields.

2.Within the first AOS Platform configuration you will need to enter the RMC (Redundant Message Channel) IP address of that same computer.

3. Within the second AOS Platform configuration you will need to enter the RMC (Redundant Message Channel) IP address of that same computer.

4. Now create two stand-alone engines (one for each AOS node). These will be used for the DI (Device Integration) Objects. You should never place any DI Object, other than the RDIO (Redundant DI Object), under a redundant engine.

5. Under the new engines you will place your DI Objects. For every unique DI Object that exists under AOS_01 or AOS_02, there should be a duplicate on the other server. For the purpose of this document’s example, we have the DASMBTCP DAServer on both AOS nodes; however, both DAServers are pointing to the same device.

NOTE: The Device itself may have multiple NIC cards.

6. Below is an image from the “Topic” tab of each DI Object. The topic names should match up exactly for the purpose of the RDIOs.

7. Next will be the creation of two primary engines, which are one for each AOS node.

8. Within each new engine you will enable redundancy. These redundant engines will be used for Application Objects, Areas, and RDIOs.

9. Once you enable redundancy, the system will automatically create the “backup” engines for you. The backup engines will be placed under the “Unassigned Host” toolset. You will place the backup engines on the opposite AOS node.

For example: If the primary engine you created backup from exists on the first AOS, then you will place the backup on the second AOS.

10. Now create two new RDIO instances. Each new RDIO will exist under the newly created redundant engines. There will be one RDIO for the first AOS, and one RDIO for the second AOS.

11. You will create the “Primary” and “Secondary” sources opposite one another. Detailed information below:

11 a) For the RDIO on the first AOS, you will specify that Platform’s DI Object first.

11 b) For the RDIO on the second AOS, you will specify that Platform’s DI Object first.

12. To display how this concept fits into assigning the IO for your Application Objects, create two new Areas. One Area for each AOS node. Then you will create two example Application Objects. One Application Object for the Area on the first AOS, and one Application Object for the second AOS.

NOTE: For the purpose of the example in this document, the example objects used were derived from the “$Boolean” base template.

13. Within the Application Object on the first AOS, you will specify the IO to be derived from the RDIO on that Platform.

14. Within the Application Object on the second AOS, you will specify the IO to be derived from the RDIO on that Platform.

15. Below is a snapshot of what the end result of our example should look like. Using this concept you can create redundancy and load balancing for both the Application Objects and the I/O.

Additional References

Created by Nick Edgett.
All Wonderware PacWest Tech Notes are provided “as is” without warranty of any kind.