This really isnât possible the way youâre describing. Think about this: If google.com is down, where would you expect to be getting a redirect to googlebackup.com from? By definition, if the gateway is down and the backup has taken over, thereâs no longer any webserver at <primary>/data/perspective/client/project to serve up even a redirect notice to <backup>/data/perspective/client/project. Itâs just fundamentally not possible to have a single webserver, in isolation, do what youâre describing. A URL always points to a specific âresourceâ (hence the name) - so in the ânaiveâ architecture, <primary>/data/perspective/client/project is always the exact location of the primary gateway.
What youâre actually looking for is to have <something>/data/perspective/client/project resolve to some other application, which is acting as a middleman - you would go to <somethingElse>/data/perspective/client/project/, and that other service would conditionally route you to <primary>/data/perspective/client/project or <backup>/data/perspective/client/project. There are infinite possibilities for this - look into load balancers, reverse proxies, etc - nginx is a solid choice for a Linux server. Crucially, this middleman must be at a separate network location - it doesnât matter to consumers of <yourServer>/data/perspective/client/project, but internally, the middleman itself must have unique addresses for both the primary and backup nodes (or however many nodes you have; true load balancers can scale âhorizontallyâ to multiple nodes). This also isnât an area Inductive Automation is interested in providing a solution first party - HTTP load balancers are a âsolvedâ problem, and nothing we can come up with would improve on existing open source, free solutions.
There is one caveat/wrinkle/exception to all this - if you are already in a Perspective session when the master -> backup transition happens, things (should) continue to work, âseamlesslyâ. How? Because the actual Perspective client is a so-called âSingle-Page Applicationâ - once youâve downloaded all the required resources (which happens as soon as you open a Perspective session), everything else is happening, from your web browserâs perspective, on a single page - the frontend is continually talking to some backend via an open websocket, but in the event of a failure on that connection, it will also have downloaded the address of the backup server, and thus the frontend can independently attempt to connect to the backup system. Vision clients work in much the same way. Crucially, though, the difference is in the scope of responsibility - the actual Ignition application (Vision or Perspective) âknowsâ how to find the backup - but a standalone web browser, pointed at <primary>/data/perspective/client/project, simply cannot know where the backup server is without something there to redirect it.
From a general http standpoint, makes complete sense. Itâs your last paragraph (seeing how open Perspective sessions behave) that made us wonder if there was some feature that made it doable within Ignition. Weâll take a look at our options. Thanks for the feedback.
Since it came up with a support rep - a small addendum to my last paragraph. Local client fallback, as it works in Vision, is basically not possible within a generic web browser. Browsers, for extremely good security reasons, donât allow a network location (ie, gatewayIp:8088 to suddenly start requesting local assets - imagine if a malicious website could start asking for local files or interact with local applications with open ports. See Same-origin policy for more information. There are specific customizations you could perform, both on your web browser and both Ignition gateways, to theoretically allow this, but itâs not something thatâs currently supported by actual Perspective sessions.
A browser shortcut/bookmark only points to one target location. If either the primary or backup, that shortcut/bookmark simply cannot work when the corresponding part of the redundant server pair is down. For shortcuts/bookmarks to work in either case, they must point at a HA proxy or similar server that can redirect to the currently running real server.
It is quite disappointing that Ignition does not have an internal solution for this.
The attitude that "IT can handle this" that I have seen across a few topics diminishes the value of the product compared to other vendors.