Migration from Hardware to VM without changing IP Address

[ASWINSASIDHARAN]

Hi all, I'm planning to migrate my H/W appliances to VMs.

Current Primary appliance - 192.168.1.1 (H/W)

Current Replica appliance - 192.168.1.2 (H/W)

If I attach a new VM replica with a new IP address (i.e 192.168.1.3) , I'll have 2 H/W and a VM in my enterprise.

When I promote the VM to Primary, my authentication agents will not be able to connect because they only know the original IP addresses (1.1 and 1.2) since this new IP is not configured on them unless I change all of them which I am trying to avoid. 

With this in mind, is it possible to do this AFTER promoting the new VM to primary?

1. Kill/unplug the original replica appliance (1.2) 

2. Change the IP/FQDN of the new VM replica from 1.3 to 1.2 

3. Test if this newly promoted VM can authenticate users and then Promote to Primary.

4. Assuming #3 is ok, set up another VM replica (192.168.1.4) 

5. Kill/unplug the old primary appliance (1.1) which is currently replica.

6. Change the IP of the new VM replica from 1.4 to 1.1 

7. Attach this 2nd VM replica (1.1) to VM primary (1.2)

Is the above procedure good to follow?

[_EricaChalfin]

ASWIN SASIDHARAN‌,

I've moved your question to the RSA SecurID Access" data-type="space space where it will be seen by the product's support engineers, other customers and partners.  Please bookmark this page and use it when you have product-specific questions.

Alternatively, from the RSA Customer Support" data-type="space‌ page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question.  From there, scroll to RSA SecurID Access" data-type="space and click Ask A Question.  That way your question will appear in the correct space.

Regards,

Erica

[EdwardDavis · Accepted solution]

That should work in general, as long as you delete the replica in step 1 and step 5 from the operations console of the Primary, so that there will be no conflict when you want to re-name / re-ip. If not deleted the database will still know about those IP's being allocated to a different (unreachable) system and won't agree to another system being re-ip to it.

[ASWINSASIDHARAN]

How can we achieve the Virtualization if we are using different IPs?

[StevenSpicer]

AS you add new instances, use the Security Console menu item "Access > Authentication Agents > Authentication Manager Contact List > Automatic Rebalance"  and the next time each Agent authenticates, it will get a new list of servers.  Don't take down the old instances for a day or two to give the Agents time to get the new list. Eventually issue and install a new sdconf.rec from the new primary.

[JayGuillette]

After you do the Automatic Rebalance (which really is not automatic but that's another discussion thread...)

1. IF you have TCP agents, which most sites have none but some sites have thousands, and include a few Partner products such as FoxT Boks server v. 7.x, and possibly some custom agents developed with the RSA agent API v. 8.5 or v. 8.6,

2. AND IF your new replica had the same name and/or IP as the old replica e.g. you updated the hardware or you migrated from one platform like hardware to another platform like VMWare 

Then You need to restart services on all AM servers, replicas and primary, in order to flush a cached entry of the old replica.  All items in the AM database have GUIDs, and when you deploy a new replica, it gets a unique GUID even if it has the same name and IP as the old replica.  The cached entry for replicas used by TCP agents includes the GUIDs, so if you do not restart AM services, you will have a situation where your failure rate from the TCP agents will increase from its historical rate due to agents trying to contact the old replica GUID in the Server cache, and the AM server will not respond to the authentication request from what it thinks is an unknown GUID replica.  TCP agents will log failed to contact ACE server, and TCPDump packet captures will show Authentication requests reaching a Primary or replica server on TCP port 5500 (not the standard agent UDP port 5500) and no reply is seen or sent by the AM server.  The AM server does not log these requests in the Authentication monitor or Authentication activity reports.