0037000001aZED9AAO (Customer) asked a question.
Hi,
I have some questions on the best way to do a RSA AM Hardware Migration with the following parameters:
The old hardware is already EoL and running old version 8.4 (1xPrimary and 1xReplica/base license). The new hardware we need to migrate to only supports 8.7SP2. Is it possible to only upgrade the Primary to 8.7SP2 and leave the Replica on 8.4 so users are not impacted if there is an issue with one of the upgrades? So take the Primary "offline" from auth requests and let the replica as is. Could an upgraded Primary influence the functionality of the 8.4 Replica? Should we block network traffic between Primary and Replica?
Is there a better, easier way to migrate to the new hardware?
How to "switch" the hardware when old Primary is on 8.7SP2 - Remove existing Replica and add new hardware with same data as old Replica, then promote the Replica and do the same with the second new Hardware?
thanks for helping on this.
br Hermann
Hermann: there are 2 paths you can follow.
#1, take 2 replicas offline. Upgrade the Primary and remaining replica to 8.5 > 8.6 > 8.7 > 8.7.1 > 8.7.2. Attach new replicas at .8.72. Once all your new hardware is online, you can promote one of the new replicas, then delete the old primary and old replica. Keeping one replica ensures that there will always be one machine to authenticate users.
#2, build a virtual machine as a stand-alone Primary at 8.4, matching the current Primary patch level. Take a backup of production and restore it to this VM. Patch the VM to 8.7.2. Build one of the new 8.7.2 appliances as a stand-alone Primary. Take a backup of the 8.7.2 VM and restore it to your new hardware appliance. You can now power down the old Primary, and change the hostname and IP of the new appliance to that of your old Primary. It will pick up all your authentication connections. If you power down each old replica, and stage the new replicas with the same hostname and IP as the replicas you replace, they should slide in with no additional effort.
With this second method, we are only powering down your old hardware. In a worst case scenario, if you disconnect the new appliances and power up the old ones, you should be right back where you were.
Hi David,
thanks for the fast response.
#1 we only have one replica available (only a base license)
#2 sounds better because there is no impact on the current system. If you switch between VM and hardware - are there known issues to consider?
All versions play the same, so you can have VM + hardware + cloud appliances all connect. You can take a hardware backup and restore to a VM, or vice versa. ALSO, your base license is for 2 permanent + 1 DR, so you could attach the new appliance to your upgraded systems, then promote.
Hi David,
#1: We only have 2 hardware appliances, one is Primary, one Replica. So what happens if I upgrade the Primary all the way from 8.4 to 8.7.2 and leave the Replica on 8.4. Should I block Radius and Replication Ports on the Primary while upgrading?
The replica needs to keep in lockstep with the Primary as the upgrades progress. One will always be online and authenticating while the other is being patched. There are problems patching the Primary if the replicas are offline, as well as trying to promote a replica if replication is broken --- which will always happen if the Primary and replicas are not on the same major version.
We are only doing the upgrade to get to 8.7.2 (a VM applicance is no option). What we want to do is to ONLY upgrade the primary all the way from 8.4 to 8.7.2 and leave the replica on 8.4 Because of the hardware migration we then will remove the old replica and attach a new one with the new hardware. Leaving the replica on 8.4 should ensure a functioning authentication. So what I would like to know. If I block traffic between Primary and Replica and also block authentcaction requests to the Primary with network ACLs. Should the upgrade still work? anything else you can think of - maybe remove the Replica on the Primary configuration before staring with the first upgrade?
The simple solution is always the best solution. You don't need to block traffic to the Primary, authentication requests will automatically fail over to the replica. There are several problems to consider. #1, if we don't patch the replica, none of the authentication history will be shared with the Primary. Any PIN changes will be lost as well. #2, if you delete the replica and just upgrade your Primary, you will have zero authentications while the patches are in progress, which will consume 3 to 5 hours total time. Patching the replica with the Primary will extend the upgrade by those same 3 to 5 hours, but the system will remain intact and there will be almost zero impact to users.
I totally understand. I would also do it like that. Unfortunately the customer doesn't accept it. I'm aware of things like lost PIN changes or loosing logs. On thing is still unclear to me: Traffic between primary and replica cannot be blocked during the upgrades. So again my question: Will upgrading the Primary all the way to 8.7.2 influence the funcionality of the Replica staying at 8.4 for the authentication of users? In the end I will remove the old replica and attach a new one with the new hardware.
The replica will continue to authenticate. The problem is in the Primary, it might not allow you to go from 8.5. to 8.6 while the replica is still at 8.4. If that's the case, you would have to patch the replica first, or else delete the replica and then deal with the outages on the rest of the upgrades.
I see. What happens if I delete the replica in the primary operations console so I can upgrade to 8.6? Will the replica still on 8.4 authenticate the users normally?