Ignition - Redundant / Self-Contained Architecture - Design Recommendations

Ignition
1

I am on the hunt for a SCADA package that would suit my needs, i.e. looking for a self-contained redundant supervisory system with some data handoff links to external historian / DCS (as required).

The key here is redundancy: redundancy in the networks to the field device and redundancy in the communications link between the servers/external devices.

  • Field Device Communications Links Redundancy
    Most field devices will communicate using Modbus TCP or Modbus RTU-over-TCP. Each field device will have two network ports and will be connected to different networks (different subnets).
    As far as I can see Ignition does not support such a functionality out-of-the-box (redundant links to the same device). But I assume that with some scripted tag name manipulation, I would be able to switch between the tags from either of those links, based on the link status? Or is there a better way to do it?
  • Server-to-Server Redundancy
    I would like to run two network cables between the two Ignition Gateway nodes, each on its own dedicated subnet. But again, this does not appear to be supported?
    Do I have to use port teaming in this instance? Or could I still use two separate networks and then configure hosts file (on Windows) accordingly? Note that this system will not have a DNS server configured (unless absolutely necessary), hence why using hardcoded entries in a file.
  • Database Server Redundancy
    Assume that the easiest way of maintaining a redundant link to the SQL server is to implement two separate networks and then either use a DNS server or hardcoded hosts file entries.
    Or is SQL database link redundancy supported natively by Ignition?

Just trying to determine what would the best approach be for maintaining redundancy with minimal hardware and/or effort. Since I have little experience with Ignition, I do not want to over-engineer anything.

Essentially the system has to survive the loss of a single network and/or a single server.

Would architecture similar to the one shown on the attached drawing work? Or is there a better/easier way to achieve it?

Overview
Overview909×616 38.9 KB

2

My alternate Modbus module's client driver directly supports dual connections to devices.

Nope. Redundancy communications must happen on one subnet.

Consider using multiple-VLAN aka Trunk connections to your servers, and include a trunk between your primary and secondary switches, with all trunks using Rapid Spanning Tree Protocol for failover. Do the same with your 3rd and 4th switches, too.

No, use native DB clustering such that the IP address for the cluster is floating, assigned to whatever the current master instance happens to be. Make this the same subnet that the gateways use for redundancy, to avoid split brain scenarios.

3

Does this apply to both the end-device connections (Modbus), and server-to-server connections (server redundancy comms)?
So in your Modbus driver, the two IPs have to be on the same subnet and I could not have for example 192.168.0.1/24 and 192.168.1.1/24?

4

I'm not sure what you mean. If your redundant servers' network connections are trunks, then each carries multiple VLANs, presumably with separate subnets per VLAN. RSTP runs across the trunk, not per VLAN.

No, they can be in separate subnets, and should be, to make your routes push them through different paths at the boundary between RSTP-driven redundant trunks and non-redundant access ports to devices.

5

OK, makes sense now, I misunderstood your original comment regarding trunks. Thanks for all the suggestions.