Vision Client Redundancy in Ignition 8.3

I recently upgraded the Ignition Gateway, Designer Launcher, and Vision Client Launcher from version 8.1 to 8.3.4 The upgrade was performed by running the installer directly on the device without removing the old version. Our SCADA system has two IO servers: IO1 hosts the Ignition Master Gateway, and IO2 hosts the Ignition Backup Gateway. Designer Launcher and Vision Client Launcher are installed in different workstation.

After upgrading to Ignition 8.3, we encountered issues during gateway failover between the Master and Backup. Specifically, when launching the Vision Client connected to the Master Gateway, it fails to reconnect to the Backup Gateway if the Master is powered off or switched over. Both gateways show “Peer Connected” with synchronization status as good, but the Vision Client keeps searching for an available node. The same issue occurs when failing over from Backup to Master.

The behavior seems like that the Vision Client does not automatically reconnect to the active gateway during failover:

  1. Launch Vision Client → connected to Master Gateway (IO1).

  2. Failover to Backup Gateway (IO2) → Vision Client cannot connect.

  3. Re-launch Vision Client → connects successfully to Backup Gateway.

  4. Failover back to Master Gateway → Vision Client cannot connect again.

  5. Re-launch Vision Client → connects successfully to Master Gateway

Anyone facing similar issue in Ignition 8.3?

Have you tried re-creating the Vision client connection? The redundancy information is passed to the client when it's first setup.

This sounds like the opposite. Like, the saved launch settings have both servers correct, but the runtime update from the servers is wrong. The public HTTP address settings may be wrong, or the redundancy address configured in the master is only correct from the master's network environment.

(Master and Backup are supposed to be on the same subnet, along with critical clients and and the inbound route path from other subnets. Some restrictions can be avoided if using DNS names everywhere instead of IP addresses.)

I am using a self-signed certificate to enable HTTPS for both gateways, which are in the same subnet (https://XX.XX.1.X:8043). From my view, this behavior seems unusual, the Vision Client can connect to the Master Gateway, but it fails to connect to the Backup Gateway during failover. However, if I relaunch the Vision Client, it successfully connects to the Backup Gateway. Which mean I should not be facing connection issue, but rather that the client is unable to detect the active node of the Backup Gateway.

Same goes to when I launch Vision Client with the Backup Gateway active and then failover to the Master Gateway.

Above is the Diagnostic tab when I re-launch Vision Client when Backup Gateway is active. (Master Gateway does not power off)

Does this certificate include a domain name? If not, fix that, and use domain names everywhere instead of IP addresses. (HTTPS is not well-designed for bare IP addresses.)

Be sure to set the gateways to report these DNS names as their public addresses, instead of automatic. And point the master and backup at each other with the DNS names.

I had update Self-Signed SSL Certificate with both IP address and Domain however the issue does not resolve.

During the failover, I had tried to logout and login (does not close the launched client) and there`s an error popup — RPC call requires active node. I think the Vision client launcher cannot determine the change of the active node.

I think you misunderstand the launcher's role. It only launches the client, using whichever configured URL is active. Once launched, the actual client draws its failover information from the connected gateway, based on how the gateways talk to each other. If that information isn't applicable to your client, failover won't work.

You haven't stated whether you configured everything with DNS names as I recommended. Until you do, I have no further guidance to offer.