Disaster Recovery Process

TIP:

Find your location and Contact Us in case of emergency.

In a PAS deployment, failover is the process of switching operations from a primary (active) system to a secondary (Disaster Recovery, DR) system when the primary becomes unavailable.

On the other hand, failback is the process of returning operations from the Disaster Recovery (DR) environment back to the primary system after the original issue has been resolved.

This guide provides the high-level guide for failing over VPAM services to a Disaster Recovery environment.

IMPORTANT:

Failover is not available as a customer-driven workflow.

To initiate a failover for disaster recovery, you must Contact Imprivata Support by phone and Raise a Support Ticket.

To perform a failover test, you must also contact Imprivata Support.

NOTE:

Imprivata Support performs active monitoring of all appliances, and they may reach out to you if they identify a production server outage.

Failover Process Requirements

Before requesting failover, ensure your environment is properly designed and prepared:

To support failover, your VPAM deployment must include:

  • An Imprivata-licensed Disaster Recovery (DR) appliance. Other implementations for DR are not supported.

  • A primary VPAM appliance to handle access, sessions, and audit logging in day-to-day operations.

  • A Disaster Recovery (DR) VPAM appliance that functions as a standby or secondary system. The DR appliance maintains synchronized configuration and data.

  • Applications installed in your internal networks. These access points must be able to reconnect to both appliances (the primary and the DR appliance).

  • Recent backups of your configuration, credentials (if applicable), and audit data.

  • DNS hostname mappings for all your VPAM components.

NOTE:

Load balancers are not supported in VPAM.
Virtual IPs (VIPs) are only required for High Availability configurations.

To support failover, ensure the disaster recovery appliance supports the same connectivity as the primary appliance in production. Read the System Requirements for more information.

Failover Process Guide

The following steps outline a typical failover procedure. Exact steps may vary depending on your architecture.

  1. Validate the Failure Condition: Confirm the primary appliance is unavailable. Signs include inaccessible UI, Applications do not check in, or sessions continuously fail.
    Ensure the issue is not related to connectivity or DNS before proceeding.

  2. Notify Stakeholders: Inform your internal IT, Security, Vendors, Internal Users, and Customers that service may be affected.

  3. Contact Imprivata Support:

    1. Contact Imprivata Support by phone for failover for disaster recovery.

    2. Raise a Support Ticket for failover for disaster recovery and when performing failover testing.

  4. Redirect DNS to the DR Node: Coordinate with Support to modify your DNS to redirect traffic to the DR node.

    After DR node is in use, continue with the next steps.

  5. Validate Core Functionality: Test the following features:

    • User login, including local authentication, SSO, and AD.

    • Vendor access and Internal Access workflows.

    • Applications connectivity.

    • Connection Manager session launch.

    • Browser-Based sessions (if configured).

    • Credential injection (if configured).

  6. Validate Connections and Integrations (if configured): Ensure your integrations persisted the failover, including:

    1. Nexus connections for CPAM and VPAM integration.

    2. Syslog connection for log transfers.

    3. AD, LDAP, or SAML integrations for authentication.

  7. Resume Operations: Inform stakeholders and users, and continue to monitor session activities, system performance, and audit logs.

To reduce down time and prevent risks, ensure you comply with the following best practices:

  • Keep Gatekeepers and Gateways Updated and Registered: Updated components ensure compatibility and security, while proper registration guarantees they can reconnect to the DR system without manual intervention.

  • Document DNS Records, IPs, and Access Credentials: Clear documentation reduces delays and confusion during an outage, enabling faster and more accurate execution of failover steps.

    IMPORTANT:

    Customers that manage their own DNS-A record should ensure TTL is at 10 minutes or less to ensure enough time for DNS to settle in the event of a DNS change.

NOTE:

Failback to primary systems follows the exact same process as failover, with the target environment being the primary appliance, instead of the secondary.