Our customer has recently implemented redundancy for their Ignition gateway and is currently soak testing running the backup to monitor if there are any issues (firewalls, hardcoded hostnames, etc)
I am trying to connect with the designer but am unable to connect to either primary or backup gateways.
current situation:
primary gateway
hostname: ign-app01
status: cold
backup gateway
hostname: ign-app02
status: active
I know I can’t connect designer to the backup server by design but it appears that because I haven’t connected to the primary with my designer since before the implementation of redundancy, it has an old configuration cached that thinks it is independent and refuses to connect (presumable as it is not the active gateway)
It looks like @pturmel is right in that this isn’t allowed.
I get not wanting to break synchronisation, but it is frustrating to be locked out from even viewing designer level config/diagnostics while the backup is active. /whinge
Don’t suppose there is a ‘read-only designer access for backup gateways’ feature in the pipeline in the near future?
For now, I’ll just share my findings with my customer so they know to jump back to master gateway ASAP when failing over.
Some background information: the traditional idea of redundancy in Ignition is that running on the redundant backup mode is considered an emergency situation. The role of the backup gateway was to keep clients/sessions functional while the master was down and being fixed or perhaps being upgraded. We know that this design is sometimes frustrating to customers who are expecting the backup gateway to become a fully functional alternate gateway when activated. We have long term plans to implement this type of design, but that is a ways off right now.
I know this is an older post, but this just happened to me last week. If my primary server goes down and I have a production stoppage I need to troubleshoot, getting the primary back up is not my #1 concern. And being forced to troubleshoot without Designer is extremely short sighted in my very humble opinion.
In my situation, a previous integrator used the wrong RAID configuration and one hard drive failed, taking the primary server down. We had no way to fix it without shipping new drives to the site, so getting the primary server running was not an option. We had to deal with troubleshooting a failed SQL query to a cloud server without being able to see the code. They ended up cancelling the third shift production for that night because of how long it took to troubleshoot the issue.
It may be by design, but that doesn't mean the design can't be improved. I consider this a major hole in a product I consider the best on the market and sincerely love working with. Access to the application was not available when I needed it and it cost my customer money. I truly hope your dev team considers giving us at least read only access to the application in the future. I don't need to edit or sync changes, just let me look at the code and live values.
I am going to make sure backups of their gateways are kept available on a workstation VM so we can at least open the code on a separate computer in demo mode, even if we can't trace the error live.
Sorry for the diatribe, but I thought it was important to make sure you know this design can have a serious impact on our ability to troubleshoot when we need it the most, and request that it is improved.
If an outage will be extended, you can ask IA support to help you move the master license to the backup gateway. (A disk failure would require their help to recover that license anyways.)
The Ignition configuration model simply does not support designer access to the backup gateway, and this is unlikely to change.
Consider making UI projects that offer troubleshooting information.
