Samuel1 (Customer) to rsaSFDCadmin (RSA): asked a question.
Question about RSA Authentication Manager Server Failover Process
This is probably pretty basic, but I wanted that the failovers from the
Primary Authentication Manager Server to the Replica occur while the primary
is down? I wanted to make sure there would not need to be any manual process I
would need to kickoff from the Security or Operations console in case it goes
down. I also wanted to confirm it the replica would revert as soon as it is
able to confirm the primay is up again or if that process has any manual
steps? I see there's a promotion operation, but that looks more like for a
long term change of roles.
Primary Authentication Manager Server to the Replica occur while the primary
is down? I wanted to make sure there would not need to be any manual process I
would need to kickoff from the Security or Operations console in case it goes
down. I also wanted to confirm it the replica would revert as soon as it is
able to confirm the primay is up again or if that process has any manual
steps? I see there's a promotion operation, but that looks more like for a
long term change of roles.
I moved your question to the SecurID discussions page, where it will be seen
by our tech support engineers, members of our Professional Services team,
engineers and other customers who use Authentication Manager.
To answer your question, your Authentication Manager servers are in an active-
active state where they all accept authentication requests at all times
(except if you manually add an sdopts.rec, but that is for another time). It
is not true failover where auth requests go only to one server and if it goes
down, another server in your deployment automatically takes over.
We have two options to promote one of your replicas to be a primary. The
options are either to **promote a replica for disaster recovery(DR)** or to
**promote a replica for maintenance**.
* In a DR scenario the primary is dead, or for some other reason will not come back online. You would select one of your replicas to be the new primary. In this scenario if the old primary does come back online at some point, is permanently cut off from working with the rest of the servers in the deployment ever again. It would need to be reinstalled as a new replica if you want it to be in use. Review the Authentication Manager Administrator's Guide for your version for information on how to promote a replica instance using the Replica Instance Promotion for Disaster Recovery option.
* For maintenance purposes, you can promote a replica instance to a primary instance while the original primary
instance is online and functioning. Review the Authentication Manager
Administrator's Guide for your version for information on how to promote a
replica instance using the Promotion for Maintenance option.
If your primary goes offline you will not be able to do any administrative
tasks like running reports, creating new users and assigning tokens. As soon
as a replica is promoted to primary, the replica will take over and you will
again be able to administer the deployment. Your replicas will handle all
authentication requests while the primary is down. Once a replica is promoted,
all replicas will send any authentication information to the primary so all of
the servers will be in synch.
In either of the scenarios above if the old primary comes back online, you can
attach it to the new primary as a replica then use the promote for Maintenance
option and promote it back to be the primary.