To provide failover capabilities if the primary Workspace ONE Access data center becomes unavailable, you must deploy Workspace ONE Access in a secondary data center.

For disaster recovery, the recommendation is to use VMware Site Recovery Manager. See Performing Disaster Recovery for Workspace ONE Access Using Site Recovery Manager. If you do not meet the requirements for Site Recovery Manager, implement the following approach.

By using a secondary data center, end users can log in and use applications with minimal downtime. Also, with a secondary data center, you can upgrade Workspace ONE Access to the next version with minimal downtime. See Upgrading Workspace ONE Access with Minimal Downtime.

A typical deployment using a secondary data center is shown here.

Diagram of typical deployment using a secondary data center

For information about the correct version of the connector to use with the ThinApp repository for ThinApp packaged applications, Integration Broker for Citrix published resources, and Horizon Connection Server for Horizon desktops and applications, see the corresponding important note in Preparing to Install Workspace ONE Access.

Follow these guidelines for a multiple data center deployment.

  • Cluster Deployment: You must deploy a set of Workspace ONE Access virtual appliances in two separate data centers.
    • A set of three or more Workspace ONE Access virtual appliances as one cluster in one data center.
    • Another set of three or more Workspace ONE Access virtual appliances as another cluster in a second data center.
    See Setting up a Secondary Data Center for Workspace ONE Access for more information.
  • Database: Workspace ONE Access uses the database to store data. For a multiple data center deployment, replication of the database between the two data centers is crucial. Refer to your database documentation about how to set up a database in multiple data centers. For example, with SQL Server, using Always On deployment is preferable. See Overview of Always On Availability Groups (SQL Server) on the Microsoft website for information. Workspace ONE Access functionalities are designed for minimal latency between the database and the Workspace ONE Access appliance. Therefore, appliances in one data center are designed to connect to the database in the same data center.
  • Not Active-Active: Workspace ONE Access does not support an Active-Active deployment where users can be served from both data centers at the same time. The secondary data center is a hot stand-by and can be used to provide business continuity for end users. Workspace ONE Access appliances in the secondary data center are in a read-only mode. Therefore, after a failover to that data center, most admin operations, like adding users or applications, or entitling users, will not work.
  • Fail-Back to Primary: In most failure scenarios, you can fail back to the primary data center after that data center is back to normal. See Failback to Primary Data Center for Workspace ONE Access for information.
  • Promote Secondary to Primary: If an extended data center failure occurs, the secondary data center can be promoted to primary. See Promoting Secondary Data Center to Primary Data Center for Workspace ONE Access for information.
  • Fully Qualified Domain Name: The fully qualified domain name to access Workspace ONE Access must be the same in all data centers.

  • Audits: Workspace ONE Access uses Elasticsearch embedded in the Workspace ONE Access appliance for auditing, reports, and directory sync logs. Create separate Elasticsearch clusters in each data center. See Setting up a Secondary Data Center for Workspace ONE Access for more information.

  • Active Directory: Workspace ONE Access can connect to Active Directory using the LDAP API or using Integrated Windows Authentication. With both of these methods, Workspace ONE Access can use Active Directory SRV records to reach the appropriate domain controller in each data center.
  • Windows Apps: Workspace ONE Access supports accessing Windows apps using ThinApp, and Windows Apps and Desktops using Horizon or Citrix technologies. Delivering these resources from a data center that is closer to the user, also called Geo-Affinity, is important.
    Important: For information about the correct version of the connector to use with the ThinApp repository for ThinApp packaged applications, Integration Broker for Citrix published resources, and Horizon Connection Server for Horizon desktops and applications, see the corresponding note in Preparing to Install Workspace ONE Access
    Note the following about Windows resources:
    • ThinApps - Workspace ONE Access supports Windows Distributed File Systems as a ThinApp repository. Use the Windows Distributed File Systems documentation to set up appropriate location-specific policies.
    • Horizon (with Cloud Pod Architecture) - Workspace ONE Access supports Horizon Cloud Pod Architecture. Horizon Cloud Pod Architecture provides Geo-Affinity using global entitlements. See "Integrating Cloud Pod Architecture Deployments" in Setting up Resources in VMware Workspace ONE Access for information. No additional changes are required for a Workspace ONE Access multiple data center deployment.
    • Horizon (without Cloud Pod Architecture) - If Horizon Cloud Pod Architecture is not enabled in your environment, you cannot enable Geo-Affinity. After a fail-over event, you can manually switch VMware Workspace ONE Access to run Horizon resources from the Horizon pods configured in the secondary data center. See Configure Failover Order of Horizon and Citrix-published Resources for more information.

    • Citrix Resources - Similar to Horizon (without Cloud Pod Architecture), you cannot enable Geo-Affinity for Citrix resources. After a fail-over event, you can manually switch Workspace ONE Access to run Citrix resources from the XenFarms configured in the secondary data center. See Configure Failover Order of Horizon and Citrix-published Resources for more information.