How RSA redundancy works?

[xiaoyunqi]

Hi RSA support team,

We're deploying  the AM 8.1 in the project now. there's one issue we need to get your confirmation.

RSA uses builtin HA software shipped with the RSA appliance. The two appliances, the primary and the replica appliances, work in active/standby mode or active/active mode?

For now we got the 1 primary instance and 2 replica instance. if we can set the authentication priority for those 3 instances?

for example in the picture beolw:

if the NNOC01 instance broken down,then the NNOC01 users authentication traffic will be toke over by NNOC02;

if the NNOC01& NNOC02 instances Both broken down,then the traffic will be toke over by Laghar01;

Thanks

matt qi

[EdwardDavis]

RSA primary and replicas are always active to authenticate whatever traffic hits them. It is up to the agent to pick and choose which RSA server it wants to authenticate against. SID protocol will try to quasi-load balance, radius agents are typically 'primary' and 'failover'. Anyhow, all RSA servers are active, full copies of the primary, and replicas simply try to log what happens on them to the primary.

You can make contact lists for SID agents if you want to force them to only prefer to authenticate against certain RSA servers, but by default the contact list for all agents is 'all RSA servers'.

[JayGuillette]

Primary is used for both Administration and Authentication, while replica is used mostly for Authentication.  The replica sends logging information to primary so primary will have complete Admin, System and RunTime Authentication data for reports.  Since New PINs are created during authentication, Replicas can also handle Token PIN changes, and send that data the Primary.

If your replica is in a different physical location than your Primary, then you have both an online, real time backup of the Primary in the Replica as well as a Disaster Recovery site, as any replica can be promoted to become the primary, either for Maintenance (original primary will attach as a replica to the newly promoted primary) or for Disaster Recovery (indicating the original primary is unreachable or gone and will never attach as a replica)

Agents using the Native UDP based authentication protocol learn which AM server is closer based on response times and tend to prefer that AM server for authentication, but will time out and switch from unresponsive AM servers in 30 seconds by default.  This protocol is very mature and works great, and in my experience any site complaining that a distant replica was preferred over a local replica should not try to fix this through a contact list, they should troubleshoot with TCPDump network packets captures why this might be happening.

[ChristopherCott]

Edward I don't think that is true. We have several instances where our primary RSA server went down and the replica would not authenticate users. I would like for you to explain how this happens if the RSA's are truly set to active active by default. By looking at the screen shot you can see that they are synchronized. 

Waiting for your reply.