We will be testing our disaster recovery site. Our replica instance is our disaster recovery backup. During testing, we need both the primary and replica instances serving authentications. Our plan was to sever the network connection between the primary and secondary instance. Will simply severing the connection between primary and secondary make the authentication managers work autonomously? If not, how can we make the replica work for testing purposes keeping in mind that theoretically our primary instance would have been destroyed by a disaster and the replica would need to be used BUT in reality, the production side will be functioning as normal.
They already act autonomously.
In a normal setup, any primary and replica each behave like a single server and works with the database that is on itself....and will attempt to authenticate what hits it. The replica will attempt to send logs to primary if it can, and the primary will replicate changes to replica, and replica to primary. If you sever the connection between the two, you do not change how they each behave, they will continue to look up usernames and passcodes on their own database as usual. But the replica will now start storing it's own logs (until it can offload them to a primary) and the replica will not be up to date for new administrative work done on the primary. If the primary is not ever coming back online for some reason, a replica can be promoted to become a primary and then you can do administrative work on that server. If the primary comes back (network is fixed) then the replica and primary will start to update each other on what activity and changes have occurred to get caught up.
Replicas and primaries use their own internal database and their own ldap connections to authenticate users, so are largely independent all the time except for the logs and and administrative work that needs to replicate so they are always up to date. RSA AM servers also do not load balance, it is the agents that load balance and determine which of the known RSA servers to choose to send an authentication request.
NOTE: I've seen some DR tests where replica cannot authenticate, due to the fact the ldap connections the replica was using, were on the other side of the DR test, effectively cutting off the ability of the replica to look up ldap users. When you set up a replica the first time, it has no choice but to inherit the identical ldap connections the primary server is using. But later once running, you can go back to the primary Operations Console, and edit the connections the replica is using, and change them to ldap connections that are closer to the replica and would be available in a DR scenario.