Migrating AM from Hardware Appliances to Virtual Machines

[WalidAbdallah]

Hello,

We have 1 primary and 3 replica instances and we want to migrate them over to VMs, and we want to keep the same FQDN/IP to avoid doing any changes on the client side.

Note: Our network does not allow us to have anything in an isolated network.

We are planning one of the below approaches:

Method 1:

1. Deploy then connect the new 4 VMs as replicas to the existing environment

2. Promote one of the new VMs as a primary

3. Power off the hardware primary then change the IP/host of the new VM primary to that of the old primary that we just powered off

4. Then do the same for the 3 replicas where we replace them one by one

5. If anything wrong happens, we will change the host/IP of the VMs back and power on the old hardware appliances

Question:

Will that work, or will there be any issues, like the replication stopping?

Method 2:

1. Deploy one of the new VMs as a primary and take a back of the existing hardware instance and restore it to this VM

2. Connect the 3 other VMs as replicas to this new primary VM

3. Power off the hardware primary then change the IP/host of the new VM primary to that of the old primary that we just powered off

4. Then do the same for the 3 replicas where we replace them one by one

5. If anything wrong happens, we will change the host/IP of the VMs back and power on the old hardware appliances

Question:

Will this also work, or will the replication break on then new VMs as their primary is no longer there when we switch the IP/host?

And in either scenario is there anything that we need to do after changing the IP/host on these new VMs to ensure they work properly?

Thank you for your time.

Regards,

Walid

[DanielRobinson]

I would not do Method 2 because I think the first step would not work.  I would follow RSA's documentation for the steps on how to recover from a Primary failure.  Promote HW Replica to Primary, verify replication is working, remove Primary from RSA architecture.  Add VM as a Replica using the HW Primary's name/IP, verify replication is working, and then Promote it to be Primary, and verify replication is working.  That would get you to the point of having your VM Primary setup and maintain replication, authentication, and configuration during that part of the process.  For the individual Replica replacements, I would remove one HW Replica via RSA GUI so it no longer exists in the replication architecture, power it down, and then bring up its VM replacement, performing the steps to add it as a Replica, using the previous one's name/IP for it.  Then I would move on to removing the next HW Replica in similar fashion and add its VM replacement in similar manner, finishing each replacement one at time and verifying replication is working each time before moving to the next HW replacement.  Note once you remove a Replica from the architecture, if for some reason you wanted to use it again, you cannot just turn it on and it work, but you would have to go through all the steps like you were setting it up as a Replica for the first time and adding it to the RSA architecture for the first time.  Also, SSH host keys may have to be cleaned up in the event you had SSH'd between HW appliances in the past, and you try to SSH to a new VM using the same name/IP.  And, if you use the same hostname/IP, then your clients should be fine.  But, if you change an appliance name or introduce a new appliance, the clients will need to be updated with the new architecture information to utilize that particular new appliance.  The appliance names the clients know are just the ones you provided when you configured their agents.  At least, this is what I have observed from my experience.  Someone else may have better information.