8.1.17 Redundancy Change

Ignition
1

Quote from the 8.1.17 blog:

Redundancy

Failover to a redundant node is now allowed if the nodes have different platform versions, which allows attached clients to remain connected to at least one node during a redundant pair upgrade.

Can someone from IA explain to me exactly how this would work? Say I upgrade the backup gateway in a pair first. Does this mean that I can still force a failover of my clients to that backup node once the upgrade is finished?

2

I’m also interested in how this is work.

Do both gateways have to be on 8.1.17+ before this change will be effective? I’m assuming if one is still below this change, it won’t want to establish due to the platform mismatch.

3

I’m disappointed I did not hear from IA about this change to redundancy.
@PGriffith can you shed some light on this change and what the implications are?

I will add what my experience moving to 7.9.20 was just a few minutes ago.

  1. Forced failover to backup gateway
  2. Updated primary gateway to 7.9.20
  3. When primary gateway came back up the backup reconnected to the gateway!
  4. After reconnecting the vision clients switched back to the primary gateway.
  5. The backup gateway restarted because the queued changes were greater than an online resync.
  6. I updated the backup gateway to 7.9.20 and as expected it eventually got reconnected to the primary

Steps 3,4, and 5 were the ones that were unexpected for me. I think overall it made the experience of updating the gateways a little easier, but I wonder how the resync is working since new alarm events could have come into the backup while the primary was updating. So did the new primary pull the events or did it force the backup to resync to it and therefore we may have lost some alarm events? I have no idea and that’s why I brought this topic up.

4

Well, I'll start with: this isn't my area, and there's no SLA for the forum :wink:
If you want a prompt answer, you should contact support.

That said, I looked into this bug ticket, and it looks like it's essentially restoring a 7.9 behavior. That is, there's now an 'intermediate' sync mode, where clients know about both sides, but which does not allow data changes:

Definition Of Done

  • Modify the redundancy code such that a redundant backup can become inactive after the master becomes active, even if the master is on a different version or has different modules/module versions. Clients should then be able to fail over back to the master. We have to set the expectation that if the master and backup are incompatible, then data sync can never occur between them.
  • Modify the redundancy section of the main status page such that a version incompatibility shows the peer node is incompatible instead of missing.
5

Gotcha. This is not what I seen on the 7.9 pair of gateways.