Para proporcionar funcionalidades de conmutación por error si el centro de datos de VMware Identity Manager primario no se encuentra disponible, es necesario que VMware Identity Manager se implemente en un centro de datos secundario.
Al usar un centro de datos secundario, los usuarios finales pueden iniciar sesión y usar las aplicaciones sin tiempo de inactividad. Un centro de datos secundario también le proporciona a los administradores la capacidad de actualizar VMware Identity Manager a la siguiente versión sin ningún tiempo de inactividad. Consulte Actualizar VMware Identity Manager sin tiempo de inactividad.
A continuación se muestra una implementación típica con un centro de datos secundario.
Siga estas instrucciones para realizar una implementación de centro de datos múltiple.
- Implementación del clúster: es necesario implementar como un clúster un grupo de tres o más dispositivos virtuales de VMware Identity Manager en un centro de datos y otro grupo de tres o más dispositivos virtuales como otro clúster en el segundo centro de datos. Consulte Configurar un centro de datos secundario para obtener más información.
- Base de datos: VMware Identity Manager usa la base de datos para almacenar información. Para realizar una implementación de un centro de datos múltiple, es crucial la replicación de las bases 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, se recomienda la implementación de AlwaysOn. Consulte Grupos de disponibilidad AlwaysOn (SQL Server) en el sitio web de Microsoft para obtener más información. Las funciones de VMware Identity Manager esperan una latencia muy baja entre la base de datos y el dispositivo de VMware Identity Manager. Por lo tanto, se espera que los dispositivos en un centro de datos se conecten a la base de datos del mismo centro de datos.
- No activo-Activo: VMware Identity Manager 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 VMware Identity Manager 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 una vez que vuelva a la normalidad. Para obtener más información, consulte GUID-2575C431-543E-4BFB-84F3-C606DA1FF1DD.html#GUID-2575C431-543E-4BFB-84F3-C606DA1FF1DD.
- Ascender el secundario a primario: en caso de un error extendido 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 primario.
- Nombre de dominio completo: el nombre de dominio completo para acceder a VMware Identity Manager debe ser el mismo en todos los centros de datos.
-
Auditorías: VMware Identity Manager usa Elasticsearch incrustado en el dispositivo de VMware Identity Manager para realizar informes de la auditoría y para los registros de sincronización de los directorios. Se deben crear clústeres de Elasticsearch independientes en cada centro de datos. Consulte Configurar un centro de datos secundario para obtener más información.
- Active Directory: VMware Identity Manager puede conectarse a Active Directory con la API LDAP o con la Autenticación de Windows integrada. En ambos métodos, VMware Identity Manager puede utilizar los informes SRV de Active Directory para llegar al controlador de dominio apropiado de cada centro de datos.
- Aplicaciones de Windows: VMware Identity Manager admite acceder a las aplicaciones de Windows con ThinApp, así como a los escritorios y las aplicaciones de Windows con las tecnologías Horizon View o Citrix. Suele ser importante enviar estos recursos desde un centro de datos cercano al usuario, también denominado Geo-Affinity. Tenga en cuenta los siguientes aspectos sobre los recursos de Windows:
- ThinApp: VMware Identity Manager 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 View (con Arquitectura Cloud Pod): VMware Identity Manager admite la Horizon Arquitectura Cloud Pod. La Horizon Arquitectura Cloud Pod proporciona Geo-Affinity con autorizaciones globales. Consulte "Integrar las implementaciones de la Arquitectura Cloud Pod" en Configurar recursos en VMware Identity Manager para obtener más información. No son necesarios cambios adicionales para la implementación de un centro de datos múltiple de VMware Identity Manager.
- Horizon View (sin la Arquitectura Cloud Pod): si la Horizon Arquitectura Cloud Pod 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 VMware Identity Manager para iniciar los recursos de Horizon View desde los pods de View configurados en el centro de datos secundario. Consulte Configurar el orden de conmutación por error de los recursos basados en Citrix y en Horizon View para obtener más información.
Recursos de Citrix: como con Horizon View (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 VMware Identity Manager para iniciar los recursos de Citrix desde XenFarms configurados en el centro de datos secundario. Consulte Configurar el orden de conmutación por error de los recursos basados en Citrix y en Horizon View para obtener más información.
