AnsweredAssumed Answered

Procedure to Migrate RSA Authentication Manager Appliance to Virtual Appliance

Question asked by Kenneth Franco on Mar 4, 2018
Latest reply on Mar 12, 2018 by Kenneth Franco

Like • Show 0 Likes0
Comment • 3

Hi.

We currently have two RSA AM appliances (8.1.1.4) - one is Primary and one is Replica and having a base license.

We have a requirement to migrate these appliances to a virtual appliance (VMware). I would like to seek your help on how to do this. I have a basic idea but could you please confirm if this is correct? Or advise if you have a simpler approach with less risk?

1. Shutdown the current Replica appliance

2. Install a new virtual instance (also 8.1.1.4) on VMWare and make it as a new Replica. I will use the IP address and FQDN of the previous replica appliance

3. Once set up, I will sync (need some details here) this Replica instance to the existing Primary appliance

4. On the Primary appliance, promote this new virtual Replica instance to Primary. So users will be able to use this new vm to authenticate. The Primary appliance will then demote itself and become a Replica

5. Shutdown the previous Primary appliance

6. Set up a second virtual appliance with the same version (8.1.1.4). Assign the FQDN and IP address of the previous Primary appliance. Set this up as a Replica.

7. Sync this new virtual Replica with the virtual Primary

Your feedback is appreciated.

Thanks.

Edward Davis

Mar 5, 2018 9:29 AM

Correct Answer

If you have a primary and replica now, just install a 2nd replica as a new vmware replica, patch

it up to match the version of the primary, then do a planned promotion so it becomes the new

primary and the others are now replicas. Then delete one and install a new replica vmware.

This also works on a base license where we only allow 1 replica. On a base, you can add 1 more replica

(there will be an exceed replica limit warning, but it does not affect the systems)

so moving from hardware to vmware by 'leapfrogging' can be pretty seamless, and you are never without 1 replica.

See the reply in context

No one else had this question

Outcomes

Jeff Shurtliff

Mar 5, 2018 8:50 AM

Hi Kenneth,

I have moved this thread to the RSA SecurID Access so that you can get an answer to your question.

You can post future questions and discussions directly to that community by clicking on the Ask a Question or Start a Discussion button on the RSA SecurID Access page.

Thanks,
Jeff

Actions

Edward Davis

Mar 5, 2018 9:29 AM

If you have a primary and replica now, just install a 2nd replica as a new vmware replica, patch

it up to match the version of the primary, then do a planned promotion so it becomes the new

primary and the others are now replicas. Then delete one and install a new replica vmware.

This also works on a base license where we only allow 1 replica. On a base, you can add 1 more replica

(there will be an exceed replica limit warning, but it does not affect the systems)

so moving from hardware to vmware by 'leapfrogging' can be pretty seamless, and you are never without 1 replica.

Actions

Kenneth Franco @ Edward Davis on Mar 12, 2018 3:18 AM

Thanks Edward.

Current Primary appliance - 192.168.1.1

Current Replica appliance - 192.168.1.2

If I install the new vm replica, I will provide it with a new IP address (i.e 192.168.1.3) . And when I promote it to become 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

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

5. Kill/unplug the original primary appliance (1.1)

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)

8. Promote this 2nd vm to become primary

End state:

Primary vm - 192.168.1.1

replica vm - 192.168.1.2

Does this look logical? Appreciate your thoughts.

Thank you.

Regards,

Kenneth

Actions

3 Replies

Jeff Shurtliff Mar 5, 2018 8:50 AM
Mark Correct
Correct Answer
Hi Kenneth,

I have moved this thread to the RSA SecurID Access so that you can get an answer to your question.

You can post future questions and discussions directly to that community by clicking on the Ask a Question or Start a Discussion button on the RSA SecurID Access page.

Thanks,
Jeff
Like • Show 0 Likes0
Actions
Edward Davis Mar 5, 2018 9:29 AM
Unmark Correct
Correct Answer
If you have a primary and replica now, just install a 2nd replica as a new vmware replica, patch
it up to match the version of the primary, then do a planned promotion so it becomes the new
primary and the others are now replicas. Then delete one and install a new replica vmware.

This also works on a base license where we only allow 1 replica. On a base, you can add 1 more replica
(there will be an exceed replica limit warning, but it does not affect the systems)
so moving from hardware to vmware by 'leapfrogging' can be pretty seamless, and you are never without 1 replica.
Like • Show 0 Likes0
Actions
- Kenneth Franco @ Edward Davis on Mar 12, 2018 3:18 AM
  Mark Correct
  Correct Answer
  Thanks Edward.
  
  Current Primary appliance - 192.168.1.1
  Current Replica appliance - 192.168.1.2
  
  If I install the new vm replica, I will provide it with a new IP address (i.e 192.168.1.3) . And when I promote it to become 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
  4. Assuming #3 is ok, set up another vm replica (192.168.1.4)
  5. Kill/unplug the original primary appliance (1.1)
  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)
  8. Promote this 2nd vm to become primary
  
  End state:
  Primary vm - 192.168.1.1
  replica vm - 192.168.1.2
  
  Does this look logical? Appreciate your thoughts.
  Thank you.
  
  Regards,
  Kenneth
  Like • Show 0 Likes0
  Actions

Procedure to Migrate RSA Authentication Manager Appliance to Virtual Appliance

Outcomes

Related Content

Recommended Content