Customer is asking about putting the backup gateway at a DR site across a WAN link rather than co-located. The docs say both nodes should be on the same network but I want to confirm if this officially unsupported, or has anyone done it successfully? What's the recommended architecture when the requirement is site-level survivability, not just server-level?
If you have PLCs communicating to this gateway, this is a terrible idea. Most PLC communication protocols, if not all of them, will perform horribly if all across a WAN interface.
On top of that, yes the redundant servers MUST communicate to each other via the same network and the clients as well MUST be on the same network. The clients use that network as well to determine the active server.
2 Likes
Adding to this. The redundancy is for Ignition, not the connection to the PLCs. The worst thing you can have happen is the connection between the gateways to fail, while the PLC connection to each still works. Then you get a "Split Brain" setup where both gateways are acting as the master. Recovery is ugly.
Keep the gateways on the same switch if possible, so that the likelihood of their connection failing is as slim as possible.
5 Likes
One architecture I helped implement:
Redundant Edge Gateway (both on premise) —> Two Full GWs (Distant in proximity to Edge & each other)
Full GW1 is recipient of Edge sync, where a history splitter sends data to local SQL & remote GW2.
Remote tag providers are configured on each full GW, with EAM to sync the project between all three (uhhh, 4) gateways.
If Full GW1 goes down (HW or entire location), we rely on Edge S&F to collect historical data until GW1 is restored, whereby remote history collection resumes. In the meantime, operators have access to the project & live data via GW2.
This architecture is not a replacement for redundancy, but it quickly became an operational convenience for ours & operations’ needs (maintenance windows, power outages, etc).
2 Likes