Pour permettre le basculement si le centre de données VMware Identity Manager principal devient indisponible, VMware Identity Manager doit être déployé dans un centre de données secondaire.
En utilisant un centre de données secondaire, les utilisateurs finaux peuvent se connecter et utiliser des applications sans temps d'arrêt. Un centre de données secondaire permet également aux administrateurs de mettre à niveau VMware Identity Manager vers la version suivante sans temps d'arrêt. Voir Mise à niveau de VMware Identity Manager sans temps d'arrêt.
Voici un déploiement classique utilisant un centre de données secondaire.
Suivez ces directives pour un déploiement de plusieurs centres de données.
- Déploiement de cluster : vous devez déployer un ensemble de trois dispositifs virtuels VMware Identity Manager ou plus sous la forme d'un cluster dans un centre de données et un autre ensemble sous la forme d'un autre cluster dans le second centre de données. Voir Configuration d'un centre de données secondaire pour obtenir plus d'informations.
- Base de données : VMware Identity Manager utilise la base de données pour stocker des données. Pour un déploiement de plusieurs centres de données, la réplication de la base de données entre les deux centres de données est essentielle. Consultez la documentation de votre base de données sur la configuration d'une base de données dans plusieurs centres de données. Par exemple, avec SQL Server, il est recommandé d'utiliser un déploiement Always On. Consultez Vue d'ensemble des groupes de disponibilité Always On (SQL Server) sur le site Web Microsoft pour obtenir plus d'informations. Les fonctionnalités de VMware Identity Manager prévoit une latence très faible entre la base de données et le dispositif VMware Identity Manager. Par conséquent, il est prévu que les dispositifs dans un centre de données se connectent à la base de données dans le même centre de données.
- Pas Actif-Actif : VMware Identity Manager ne prend pas en charge le déploiement Actif-Actif dans lequel les utilisateurs peuvent être servis depuis les deux centres de données en même temps. Le centre de données secondaire est un serveur de secours et il peut être utilisé pour offrir une continuité d'activité aux utilisateurs finaux. Les dispositifs VMware Identity Manager dans le centre de données secondaire sont en mode lecture seule. Par conséquent, après un basculement vers ce centre de données, la plupart des opérations d'administrateur, comme l'ajout d'utilisateurs ou d'applications, ou l'autorisation d'utilisateurs, ne fonctionneront pas.
- Restauration automatique du principal : dans la plupart des scénarios d'échec, vous pouvez effectuer une restauration automatique vers le centre de données principal une fois qu'il revient à la normale. Voir Restauration automatique vers le centre de données principal pour plus d'informations.
- Promouvoir secondaire en principal : en cas d'échec prolongé d'un centre de données, le centre de données secondaire peut être promu en centre de données principal. Voir Promotion du centre de données secondaire en centre de données principal pour plus d'informations.
- Nom de domaine complet : le nom de domaine complet pour accéder à VMware Identity Manager doit être le même dans tous les centres de données.
-
Audits : VMware Identity Manager utilise Elasticsearch intégré dans le dispositif VMware Identity Manager pour l'audit, les rapports et les journaux de synchronisation de répertoire. Des clusters Elasticsearch séparés doivent être créés dans chaque centre de données. Voir Configuration d'un centre de données secondaire pour obtenir plus d'informations.
- Active Directory : VMware Identity Manager peut se connecter à Active Directory à l'aide de l'API LDAP ou de l'authentification Windows intégrée. Dans ces deux méthodes, VMware Identity Manager peut exploiter des enregistrements SRV Active Directory afin d'atteindre le contrôleur de domaine approprié dans chaque centre de données.
- Applications Windows : VMware Identity Manager prend en charge l'accès à des applications Windows à l'aide de ThinApp et à des applications et des postes de travail Windows à l'aide des technologies Horizon View ou Citrix. En général, il est important de fournir ces ressources à partir d'un centre de données plus proche de l'utilisateur, également appelé Géo-affinité. Notez ce qui suit à propos des ressources Windows :
- ThinApps : VMware Identity Manager prend en charge les systèmes de fichiers distribués Windows comme référentiel ThinApp. Utilisez la documentation des systèmes de fichiers distribués Windows pour configurer des stratégies spécifiques à l'emplacement appropriées.
- Horizon View (avec Architecture Cloud Pod) : VMware Identity Manager prend en charge Architecture Cloud Pod d'Horizon. Architecture Cloud Pod d'Horizon fournit la Géo-affinité à l'aide des droits globaux. Consultez « Intégration des déploiements d'Architecture Cloud Pod » dans Configuration des ressources dans VMware Identity Manager pour plus d'informations. Aucun changement supplémentaire n'est requis pour un déploiement de plusieurs centres de données VMware Identity Manager.
- Horizon View (sans Architecture Cloud Pod) : si Architecture Cloud Pod d'Horizon n'est pas activée dans votre environnement, vous ne pouvez pas activer la Géo-affinité. Après un basculement, vous pouvez manuellement changer VMware Identity Manager pour lancer des ressources Horizon View à partir des espaces View configurés dans le centre de données secondaire. Voir Configurer l'ordre de basculement des ressources Horizon View et Citrix pour obtenir plus d'informations.
Ressources Citrix : semblables à Horizon View (sans Architecture Cloud Pod), vous ne pouvez pas activer la Géo-affinité pour les ressources Citrix. Après un basculement, vous pouvez manuellement changer VMware Identity Manager pour lancer des ressources Citrix à partir des XenFarms configurés dans le centre de données secondaire. Voir Configurer l'ordre de basculement des ressources Horizon View et Citrix pour obtenir plus d'informations.
