This question keeps coming back around, looking for a definitive answer:
We are deploying Ignition on a VMware system that consists of 2 redundant servers. If one server fails, the other takes over, typical stuff. My question is, do I need to setup a master and backup gateway or can I use one gateway and let VMware handle the failover. The problem is cost - if I go with Master/ Backup gateways I assume I will need a second Ignition license (even if it's reduced cost for the backup). Will Ignition work with one license and one gateway and failover properly if VMware does the failover?
If VMWare is in charge of the failover then I imagine the backup gateway would go back to being unlicensed. I assume this loophole would have been discovered and closed a long time ago.
Given that you need redundancy, the 50% cost of the backup seems like a no brainer. Out of curiosity - how much money would you lose per hour if Ignition went down?
It's not really about Ignition going down, it's about hardware failures and having to pay additional costs to move an already licensed vm to another piece of hardware. I just need to price it for the customer, so want to make sure I do that properly and have the right answer if someone asks what the license cost entails and why moving a vm to another server would require another license since it is just one Ignition gateway running on one piece of hardware at any point in time. It's a big price jump for a FT site moving to Ignition even though I tell them how wonderful it is, so just want to have the proper explanation.
Proper redundancy (for Ignition) is having primary and backup ignition servers on physically separate machines, with both being licensed.
You will run into much headache trying to activate and un-activate your servers on demand during a failover. What happens if you are unable to reach the activation server during a failover?
Any failure mode on the primary server should sever that server's connection to all devices and the backup. If it only severs connection to the backup you'll get a split brain scenario.
Thanks, I understand, I need to be able to justify and explain it to the [potential] customers so appreciate the answer on what is required.
Perhaps you should involve IA sales engineering.
It's a big price jump for a FT site moving to Ignition even though I tell them how wonderful it is, so just want to have the proper explanation.
Compared to a redundant factorytalk server?
They probably have a license server that the active instance points at. Single license with a fast timeout or a forced return.
Right but now there is a single source of failure if your license server vm goes down
The existing site had no FT redundancy setup, so it's a big change for them and that's why I wanted to make sure I had the right info for what the proper setup should be. Believe me, I get it, but unfortunately many times the people reviewing the bids don't, so I need to make it clear to them.
unfortunately many times the people reviewing the bids don't
I hear you, Im on the sales and integration side too. The right way to do this is purchase a redundant backup license for ignition.
I wouldn't think a VM being moved to a new server would cause an issue, but your failover times would not be as fast as using true redundancy. You wouldn't need to deactivate or reactivate anything I wouldn't think as VMware should try to maintain the identity of the server, but I could be wrong as I haven't tested this with Ignition personally. Whenever you copy a VM, VMware gives it a new identity that would cause you to reactivate.
Are you using shared storage for VMware to ensure the data on the VM is consistent when it fails over?
You'd probably be using a leased license for this.
I strongly disagree. Leased licenses need a relatively reliable internet connection. If you are setting up redundancy in a local environment, I think a permanent license for both gateways is necessary.
It seems like the answer depends on the type of outage you are trying to mitigate. In a VM environment (or at least ours) there are multiple hardware nodes. If one fails, the workloads migrate to other nodes. This works fine for hardware outages, but not for software maintenance. To accommodate O/S patches and other software upgrades, you would need a redundant pair in order to maintain operations. Patch one, then fail over and patch the other.