Deploying Omnissa Access in a Secondary Data Center for Failover and Redundancy

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

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 Omnissa Access to the next version with minimal downtime. See Upgrading Omnissa Access with Minimal Downtime.

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

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 Omnissa Access.

Follow these guidelines for a multiple data center deployment.

• Cluster Deployment: You must deploy a set of Omnissa Access virtual appliances in two separate data centers.

  • A set of three or more Omnissa Access virtual appliances as one cluster in one data center.
  • Another set of three or more Omnissa Access virtual appliances as another cluster in a second data center. See Setting up a Secondary Data Center for Omnissa Access for more information.

• Database: Omnissa 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. Omnissa Access functionalities are designed for minimal latency between the database and the Omnissa Access appliance. Therefore, appliances in one data center are designed to connect to the database in the same data center.

• Not Active-Active: Omnissa 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. Omnissa 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 Omnissa 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 Omnissa Access for information.

• Fully Qualified Domain Name: The fully qualified domain name to access Omnissa Access must be the same in all data centers.

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

• Active Directory: Omnissa Access can connect to Active Directory using the LDAP API or using Integrated Windows Authentication. With both of these methods, Omnissa Access can use Active Directory SRV records to reach the appropriate domain controller in each data center.

• Windows Apps: Omnissa 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 Omnissa Access

  Note the following about Windows resources:

  • ThinApps - Omnissa 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) - Omnissa 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 Omnissa Access for information. No additional changes are required for a Omnissa 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 Omnissa 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 Omnissa 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.