What is the recommended best practice for a Secure ID DR architecture for a total site failure?

[JHardiman]

What is the recommended best practice for a Secure ID DR architecture for a total site failure? We currently have our primary and replication server in the same physical location. We are looking to re-architecture for a total site failure. What is the recommended design for this use case?

[PiersB]

There are a number of options depending on your budget.

Clearly creating an Replica server at another physical location would be beneficial. Many customers also do this to make sure there are servers locally available to agents that can process authentications. This is a simple, low-cost solution. The drawback is that there is some administrative down-time while the server in the remote location is "promoted".

Another option could be to use a virtualization infrastructure such as VMware. Authentication Manager is qualified with VMware's "vMotion" functionality allowing the primary server to transparently moved/re-created on hardware within a VMware cluster. This is clearly a more high-end solution and "virtually eliminates" (pun intended) any administrative down-time.

Look for some future announcements that may provide additional options in this area.

[JHardiman]

Thank you for the information Piers. Is there a way to have two primary servers running at the same time in two different physical location? Our current Secure ID environment is virtualized, Is there any documentation on the vMotion functionality you mentioned?

[PiersB]

The previous comment has a link to information on vMotion.

I believe VMware "vSphere Fault Tolerance" may provide functionality closest to that you're seeking. It "provides continuous availability for applications (with up to four virtual CPUs) by creating a live shadow instance of a virtual machine that mirrors the primary virtual machine".

While it is possible to have two Primary servers, but they would not share or control the same set of users. They would be two separate deployments that could be connected with "remote trust". Each primary would manage two different sets of users and tokens.