Para proporcionar funcionalidades de conmutación por error si el centro de datos de Omnissa Access principal no se encuentra disponible, debe implementar Omnissa Access en un centro de datos secundario.
Al usar un centro de datos secundario, los usuarios finales pueden iniciar sesión y usar las aplicaciones con un periodo de inactividad mínimo. Además, con un centro de datos secundario, se puede actualizar Omnissa Access a la versión siguiente con un periodo de inactividad mínimo. Consulte Actualizar Omnissa Access con un tiempo de inactividad mínimo.
A continuación se muestra una implementación típica con un centro de datos secundario.
Si desea obtener información sobre la versión correcta del conector que se debe utilizar con el repositorio de ThinApp para aplicaciones empaquetadas de ThinApp, Integration Broker para recursos publicados de Citrix, y Horizon Connection Server para aplicaciones y escritorios de Horizon, consulte la nota correspondiente en Preparar la instalación de Omnissa Access.
Siga estas instrucciones para realizar una implementación con varios centros de datos.
-
Implementación de clúster: debe implementar un conjunto de dispositivos virtuales de Omnissa Access en dos centros de datos separados.
- Un conjunto de tres o más dispositivos virtuales de Omnissa Access como un clúster en un centro de datos.
- Otro conjunto de tres o más dispositivos virtuales de Omnissa Access como otro clúster en un segundo centro de datos. Para obtener más información, consulte Configurar un centro de datos secundario para Omnissa Access.
-
Base de datos: Omnissa Access usa la base de datos para almacenar información. Para realizar una implementación con varios centros de datos, es crucial la replicación de la base de datos entre los dos centros de datos. Consulte la documentación de la base de datos para obtener más información sobre cómo configurar una base de datos en centros de datos múltiples. Por ejemplo, con SQL Server, la implementación de AlwaysOn es preferible. Consulte Grupos de disponibilidad AlwaysOn (SQL Server) en el sitio web de Microsoft para obtener más información. Las funciones de Omnissa Access están diseñadas para una latencia mínima entre la base de datos y el dispositivo de Omnissa Access. Por lo tanto, los dispositivos en un centro de datos están diseñados para conectarse a la base de datos del mismo centro de datos.
-
No activo-Activo: Omnissa Access no es compatible con una implementación Activo-Activo donde se puede proporcionar usuarios desde ambos centros de datos al mismo tiempo. El centro de datos secundario es un método de espera activa y se puede usar para proporcionar a los usuarios finales una continuidad del trabajo. Los dispositivos de Omnissa Access en el centro de datos secundario están en modo de solo lectura. Por lo tanto, después de producirse una conmutación por error en ese centro de datos, no funcionarán la mayoría de las operaciones de administrador, como agregar usuarios o aplicaciones o autorizar usuarios.
-
Conmutación por recuperación en el primario: en la mayoría de los escenarios de error, puede realizar una conmutación por recuperación en el centro de datos primario cuando vuelva a la normalidad. Para obtener más información, consulte Realizar una conmutación por recuperación en el centro de datos principal para Omnissa Access.
-
Ascender el secundario a primario: si se produce un error generalizado del centro de datos, el centro de datos secundario puede pasar a ser primario. Para obtener más información, consulte Ascender un centro de datos secundario a principal para Omnissa Access.
-
Nombre de dominio completo: el nombre de dominio completo para acceder a Omnissa Access debe ser el mismo en todos los centros de datos.
-
Auditorías: Omnissa Access usa OpenSearch incrustado en el dispositivo de Omnissa Access para realizar informes de la auditoría y para los registros de sincronización de los directorios. Cree clústeres de OpenSearch independientes en cada centro de datos. Para obtener más información, consulte Configurar un centro de datos secundario para Omnissa Access.
-
Active Directory: Omnissa Access puede conectarse a Active Directory con la API LDAP o con la Autenticación de Windows integrada. En ambos métodos, Omnissa Access puede utilizar los informes SRV de Active Directory para acceder al controlador de dominio apropiado de cada centro de datos.
-
Aplicaciones de Windows: Omnissa Access admite acceder a las aplicaciones de Windows con ThinApp, así como a los escritorios y las aplicaciones de Windows con las tecnologías Horizon o Citrix. Es importante enviar estos recursos desde un centro de datos cercano al usuario, también denominado Geo-Affinity.
Importante: Si desea obtener información sobre la versión correcta del conector que se debe utilizar con el repositorio de ThinApp para aplicaciones empaquetadas de ThinApp, Integration Broker para recursos publicados de Citrix, y Horizon Connection Server para aplicaciones y escritorios de Horizon, consulte la nota correspondiente en Preparar la instalación de Omnissa Access.
Tenga en cuenta los siguientes aspectos sobre los recursos de Windows:
- ThinApp: Omnissa Access admite Windows Distributed File Systems como un repositorio de ThinApp. Use la documentación de Windows Distributed File Systems para configurar las directivas específicas de la ubicación.
- Horizon (con Arquitectura Cloud Pod): Omnissa Access admite la Arquitectura Cloud Pod de Horizon. La Horizon Arquitectura Cloud Pod proporciona Geo-Affinity con autorizaciones globales. Consulte "Integrar las implementaciones de la Arquitectura Cloud Pod" en Configurar recursos en Omnissa Access para obtener más información. No son necesarios cambios adicionales para una implementación con varios centros de datos de Omnissa Access.
- Horizon (sin la Arquitectura Cloud Pod): si la Arquitectura Cloud Pod de Horizon no está habilitada en su entorno, no puede habilitar Geo-Affinity. Después de un evento de conmutación por error, puede cambiar de forma manual Omnissa Access para ejecutar los recursos de Horizon desde los pods de Horizon configurados en el centro de datos secundario. Para obtener más información, consulte Configurar el orden de conmutación por error de los recursos publicados en Citrix y Horizon.
- Recursos de Citrix: como con Horizon (sin la Arquitectura Cloud Pod), no puede habilitar los recursos de Citrix para Geo-Affinity. Después de un evento de conmutación por error, puede cambiar de forma manual Omnissa Access para ejecutar los recursos de Citrix desde las instancias de XenFarm configuradas en el centro de datos secundario. Para obtener más información, consulte Configurar el orden de conmutación por error de los recursos publicados en Citrix y Horizon.
¿Le resultó útil esta página?