Comprendre l'ensemble des fonctionnalités haute disponibilité d'Identity Manager

Identity Manager est conçu pour tirer parti d'une eventuelle infrastructure HA existante. Par exemple, Identity Manager ne nécessite pas de cluster de serveurs d'application pour atteindre une haute disponibilité mais peut utiliser un cluster s'il y en a un.

Le diagramme suivant montre les principaux composants d'Identity Manager déployés dans une architecture non redondante. Les sections qui suivent décrivent la façon dont le référentiel, le serveur d'application et la passerelle d'Identity Manager peuvent être rendus hautement disponibles.

Figure 3–1 Architecture de système Identity Manager standard

Reportez-vous à Comprendre les directives de séparation des systèmes et de proximité physique pour savoir quels composants doivent être installés à proximité l'un de l'autre pour minimiser les problèmes de performance susceptibles de se poser suite à la latence et à l'engorgement du réseau.

Rendre le référentiel hautement disponible

Identity Manager stocke l'ensemble de ses informations de provisioning et d'état dans le référentiel d'Identity Manager.

La disponibilité de l'instance de la base de données stockant le référentiel d'Identity Manager est l'élément le plus critique pour réaliser un déploiement hautement disponible d'Identity Manager. Le référentiel est la représentation de l'ensemble de l'installation d'Identity Manager et les données qu'il contient doivent être protégées comme dans le cas d'autres applications de base de données importantes. Au minimum, il faut effectuer des sauvegardes régulières.

N’hébergez pas le référentiel d’Identity Manager sur un système virtuel tel qu'une machine virtuelle VMware car la performance (le nombre de transactions par seconde) serait considérablement réduite.

Il ne peut y avoir qu'une image du référentiel. Il n'est pas possible d'avoir deux bases de données séparées pour Identity Manager et de tenter de les synchroniser de nuit. Sun recommande d'utiliser les capacités de clustering ou de mise en miroir de votre base de données pour assurer la tolérance de pannes.

Rendre le serveur d'application hautement disponible

Identity Manager peut s'exécuter au sein d'un serveur d'application et profiter de la disponibilité accrue et de l'équilibrage de charge fournis par un cluster. Identity Manager n'utilise cependant aucune fonctionnalité J2EE nécessitant le clustering.

Identity Manager utilise l'objet de session HTTP disponible au travers de l'API Servlet. Cet objet de session suit la visite de tout utilisateur qui se connecte et effectue des actions. Dans un cluster, vous pouvez en option avoir plusieurs nœuds gèrant les demandes d'un utilisateur au cours d'une session donnée. Cela n'est toutefois en général pas recommandé et la plupart des installations sont configurées pour envoyer l'ensemble des demandes d'un utilisateur pour une session donnée au même serveur.

Il est possible d'accroître la disponibilité et la capacité du serveur d'application exécutant Identity Manager même si vous ne configurez pas de cluster. Pour cela, vous devez installer plusieurs serveurs d'application connectés via Identity Manager au même référentiel et mettre un équilibreur de charge avec affinité de session devant tous les serveurs d'application.

Pour plus d'informations sur l'affinité de session, consultez la Foire aux questions relative à l'affinité de session et à la persistance des sessions.

Identity Manager exécute certaines tâches en arrière-plan. C'est le cas, par exemple, des tâches de réconciliation programmées. Ces tâches sont stockées dans la base de données et peuvent être sélectionnées par n'importe quel serveur Identity Manager qui les exécutera. Identity Manager utilise la base de données pour assurer que ces tâches sont toujours exécutées jusqu'à la fin même en cas de basculement sur un autre nœud.

Configuration d'Active Sync Clustering sur les nœuds de serveur d'application

Le paramètre sources.hosts du fichier Waveset.properties contrôle les hôtes qui, dans un environnement multi-instance, sont utilisés pour exécuter les demandes Active Sync. Ce paramètre fournit la liste des hôtes sur lesquels les adaptateurs de ressources peuvent s'exécuter. Mettre ce paramètre sur localhost ou null permettra aux adaptateurs de source de s'exécuter sur tout hôte de la ferme de serveurs (ceci est le comportement par défaut). En listant un ou plusieurs hôtes, vous pouvez restreindre l'exécution à cette liste. Si vous avez des mises à jour entrantes provenant d'un autre système allant vers un hôte particulier, utilisez le paramètre sources.hosts pour enregistrer les noms des hôtes.

De plus, vous pouvez définir une propriété nommée sources. nomRessource.hosts, qui contrôlera où la tâche Active Sync de la ressource sera exécutée. Remplacez nomRessource par le nom de l'objet ressource que vous voulez spécifier.

Rendre la passerelle hautement disponible

Identity Manager requiert une passerelle légère pour gérer les ressources auxquelles il n'est pas possible d'accéder directement depuis le serveur. Ces ressources peuvent être, par exemple, des systèmes qui requièrent des appels d'API côté client spécifiques de la plate-forme. Par exemple, si Identity Manager s'exécute sur un serveur d'application UNIX basé sur UNIX, il n'est pas possible d'effectuer des appels NTLM ou ADSI en direction de domaines NT ou Active Directory gérés. Étant donné qu'Identity Manager a besoin d'une passerelle pour gérer ces ressources, il est important de s'assurer qu'Identity Manager Gateway a été rendu hautement disponible.

Pour empêcher que Gateway ne constitue un point de panne unique, Sun recommande d'avoir plusieurs machines exécutant une instance de Gateway. Un périphérique de routage réseau doit être configuré pour assurer le basculement si l'instance principale de Gateway s'arrête. Le périphérique de basculement doit être configuré pour l'affinité de session et utiliser un modèle à tour de rôle. Ne placez pas Gateway derrière un périphérique qui procède à l'équilibrage de charge ! Une telle configuration ne serait pas prise en charge et entraînerait l'échec de certaines fonctionnalités d'Identity Manager.

Tous les domaines Windows gérés par un Gateway doivent faire partie de la même forêt. La gestion de domaines à travers les limites d'une forêt n'est pas prise en charge. Si vous avez plusieurs forêts, installez au moins un Gateway dans chacune.

Les outils de contrôles Win32 peuvent être configurés pour observer le processus gateway.exe sur l'hôte Win32. En cas de panne de gateway.exe, le processus peut être redémarré automatiquement.