Migrate VIP from existing grid HA pair to another newly-added grid HA pair, replacing new pair's VIP

[#1]

Hi - we are replacing Infoblox appliances, but because we're putting the replacement hardware in different racks, are unable to follow the recommended approach of reusing the existing cabling.  This is also occurring in a remote data center, for which it's very inconvenient to deploy personnel.

But to avoid changing all our firewalls. clients, and helper IPs, we would still like to end up with the same IPs for DNS and DHCP services.

To accommodate this, and to minimize downtime for the existing VIPs, our general plan was to rack and cable the new hardware, added each new HA pair to our existing grid (with new, unique VIPs), setup the appropriate services on each, add them to name server groups as needed - then update/replace the VIP on the new HA pair with the existing VIP from the HA pair it's replacing.

But, is there a procedure for doing that?  In digging through the documentation, I haven't been able to find such a procedure (though one of our support engineers seemed to indicate it should be doable). Nor have I been able to find any way to edit the VIP in the web GUI. Is there perhaps a CLI command for changing the VIP?

If there IS such a "update VIP" procedure, are there any issues with employing that general approach for the new HA pairs to replace our existing grdmaster and gridmaster candidate pairs?

If it's simply impossible to do so - how, in general, do people replace HA pairs, whilst minimizing downtime?

Thank you!

[#2]

Whilst your approach may seem sound, the reality is that you will experience a lot of pain doing it this way. The problem is mainly to do with DHCP and the way that every network has to have the two members assigned, and that each range will also have a member, or failover association assigned. It's quite hard to update them all and you'll end up have to use the CSV export and import tool to perform bulk updates, multiple times, as you replace each HA pair with the new kit.

What I would try and do is use the same server definitions so you don't end up having to make all these changes. So long as the old and new devices are on the same VLAN then you can rebuild the HA pair across the switches, they don't need to be plugged into the same switch. So you could power down the passive node and replace that with one of the new devices, do a HA failover and then replace the old active node. Just check which version of NIOS you are running against the release note upgrade path, because the new device will sync it's NIOS version from the old device, so you need to make sure the new hardware can run the old NIOS version - if the version of NIOS is too old you will have to upgrade NIOS to a newer version before you can do this.

If it's not possible to switch the hardware out like this, you could power down both nodes in the HA pair and then just configure the new devices with the same IPs and join them to the grid. Obviously this will take a service out, but if you're running DHCP failover then that's not a big deal, for DNS, then you should either be using anycast or the clients should have more than IP address configured in their resolvers.

This is a much easier way to do this rather than faff about with updating member assignments on the neworks and ranges.

[#3]

Thank you, Paul - ugh, didn't think about all the network definitions (though no worries on the NIOS version issues, i can get the new units to the same version first). I assumed I couldn't do a 1-by-1 swap-in of the new hardware because of the difference in models ... can you HA-pair across hardware types?  For example, we have old IB-1410s being replaced by IB-805s.  (We also will be replacing some with VMs, but for now, i'm dealing with just the hardware swaps).  Is your first approach workable, given that?

Thank you.

[#4]

Yes you can mix hardware models whilst doing this, it's not supported for long term production running, but fine for short periods whilst doing the swapout, I have used this approach many times now.