test

Présentation de Sun Identity Manager

Chapitre 3 Clustering et haute disponibilité

Ce chapitre explique la mise en œuvre d'un environnement Identity Manager haute disponibilité/à tolérance de pannes (HA/FT).

Remarque –

Veuillez consulter la documentation de vos serveurs Web et d'application ainsi que celle du fournisseur de votre base de données pour prende connaissance des pratiques recommandées pour assurer un déploiement hautement disponible avec chacune de ces technologies. Ce guide ne remplace pas les recommandations spécifiques des fournisseurs de vos serveurs Web.

Évaluation des besoins de disponibilité

Cette section explique comment évaluer l'ampleur de la disponibilité requise par votre déploiement spécifique.

Évaluation du coût de l'indisponibilité

Identity Manager ne se trouvant pas dans le chemin des transactions entre les utilisateurs généraux et les systèmes et applications auxquels ils ont déjà accès, l'indisponibilité d'Identity Manager n'est pas aussi dramatique que vous ne pourriez l'imaginer. Si Identity Manager n'est pas disponible, les utilisateurs finaux continuent à pouvoir accéder aux ressources au travers de leurs comptes provisionnés.

Le principal coût de l'indisponibilité d'Identity Manager est une faible productivité. Si Identity Manager est hors service, les utilisateurs finaux ne peuvent pas utiliser Identity Manager pour accéder aux systèmes qui sont verrouillés ou pour lesquels ils n'ont pas été provisionnés.

Pour calculer le coût de l'indisponibilité, le premier chiffre à prendre en compte est le coût moyen de la productivité perdue à cause de l'incapacité dans laquelle sont les utilisateurs d'accéder aux ressources informatiques au sein de l'entreprise. Dans le cadre de notre évaluation, ce chiffre est la productivité par heure-personne.

L'autre valeur à déterminer est le pourcentage d'utilisateurs finaux au sein de la population d'utilisateurs ayant besoin d'utiliser Identity Manager à l'instant t. Cette population se compose normalement des nouveaux embauchés devant encore être provisionnés et des utilisateurs finaux ayant oublié leur mot de passe, si la gestion de ceux-ci est incluse dans le déploiement.

Considérez la situation hypothétique suivante :

Nombre total d'employés 

20 000 

 

Nombre de réinitialisations de mots de passe par jour 

130 

 

Nombre de nouveaux embauchés par jour 

30 

 

Nombre d'heures dans un jour ouvrable 

8 

 

Dans ce cas de figure particulier, vous devez effectuer les calculs suivants :

Ces chiffres peuvent vous permettre d'estimer le coût d'une panne d'Identity Manager :

Productivité par heure-personne 

100 dollars 

   

Perte de productivité 

0,5 

 

(baisse de 50% de la productivité due à l'impossibilité d'accéder au système) 

Nombre de personnes concernées 

20 

   

Sous-total 

1000 dollars 

   
       

Durée de la panne 

2 heures 

   

Perte immédiate totale 

2000 dollars 

   

Cet exemple montre que même si le nombre des utilisateurs gérés par Identity Manager est élevé, celui de ceux qui ont besoin d'Identity Manager pour pouvoir accéder aux systèmes à un instant t est en général bas.

Un autre point à prendre en compte est le temps nécessaire pour remettre en ligne un système comme Identity Manager qui est normalement inférieur à celui nécessaire pour exécuter les processus de provisioning manuels qu'Identity Manager automatise. Ainsi, tout en ayant un coût, l'indisponibilité d'Identity Manager est en général moins onéreuse que le coût de l'utilisation de processus manuels pour octroyer aux utilisateurs l'accès aux ressources.

Comprendre les causes de l'indisponibilité

Dans le cadre de la planification d'un déploiement haute disponibilité d'Identity Manager, il convient d'examiner les causes d'indisponibilité.

Celles-ci incluent les éléments suivants :

Calcul du retour sur investissement

Identity Manager automatise les processus et réduit la perte de productivité. Le retour sur investissement d'une architecture Identity Manager hautement disponible s'obtient en minimisant l'indisponibilité et en évitant les pertes de productivité.

Vous pouvez utiliser le coût d'indisponibilité pour déterminer l'ampleur de la disponibilité nécessaire pour Identity Manager. En général, un investissement modéré visant à rendre Identity Manager hautement disponible est justifié.

Lorsque vous calculez le coût de cet investissement, n'oubliez pas que l'achat de matériel et de logiciels HA/FT n'est qu'une partie de la mise en œuvre d'une solution disponible. La nécessité d'avoir une équipe compétente en mesure de maintenir la solution activée et en fonctionnement constitue un coût supplémentaire.

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

Diagramme logique représentant l'architecture de système Identity Manager standard.

Remarque –

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.

Remarque –

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.

Remarque –

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.

Comprendre l'architecture HA recommandée

Le diagramme suivant illustre l'architecture d'Identity Manager recommandée par Sun en l'absence d'infrastructure d'application Web existante.

Figure 3–2 Architecture haute disponibilité d'Identity Manager

Diagramme logique représentant l'architecture haute disponibilité recommandée d'Identity Manager.

Dans un développement réel, l'infrastructure de serveur d'application redondante existante doit être utilisée autant que possible. L'avantage de cette architecture est qu'elle utilise uniquement des équilibreurs de charge pour assurer la redondance au niveau du serveur d'application. Les équilibreurs de charge avec affinité de session détectent les instances de serveur d'application en panne et basculent sur des instances actives. Les équilibreurs de charge sont également utilisés pour fournir une mise à l'échelle horizontale dans l'environnement Web en répartissant les demandes des utilisateurs dans un cluster de serveurs.

Même s'il s'agit là d'une architecture simple, les caractéristiques de temps de disponibilité sont comparables à celles de déploiements plus complexes. Compte tenu par ailleurs de cette simplicité, il y a moins d'éléments logiciels à actualiser et contrôler et moins d'éléments risquant de tomber en panne. Par ailleurs, l'erreur humaine étant la première cause d'indisponibilité, une solution relativement simple peut permettre d'obtenir de meilleures caractéristiques de temps de disponibilité qu'une autre plus complexe. Ces réponses ne sont toutefois pas universellement valides. L'essentiel est de comprendre toutes les causes d'indisponibilité et de choisir l'architecture se traduisant par la meilleure disponibilité pour l'investissement envisagé.

Remarque –

Il serait impossible de décrire toutes les architectures HA différentes possibles avec une application Web telle qu'Identity Manager.

Étant donné qu'Identity Manager peut être déployé selon tout un éventail de combinaisons, il pourra être plus économique d'identifier l'infrastructure existante et de l'utiliser le plus possible pour déployer Identity Manager.

Comprendre l'architecture HA recommandée de Service Provider

Si la fonctionnalité Identity Manager Service Provider doit être utilisée, Sun recommande d'ajouter un niveau Web entre le niveau utilisateur et le niveau d'application. Ce niveau Web sera constitué de un ou plusieurs serveurs Web résidant dans une zone démilitarisée (DMZ) séparée par un pare-feu du niveau d'application.

Un référentiel LDAP est obligatoire si la fonctionnalité Service Provider est utilisée. Si Identity Manager prendra uniquement en charge des clients de l'extranet, un référentiel Identity Manager standard est recommandé mais pas obligatoire. Sinon, si Identity Manager doit prendre en charge à la fois les utilisateurs de l'intranet et ceux de l'extranet, un référentiel LDAP et un référentiel Identity Manager standard sont nécessaires.

Figure 3–3 Architecture haute disponibilité d'Identity Manager Service Provider

Diagramme logique représentant l'architecture haute disponibilité recommandée d'Identity Manager pour une implémentation de Service Provider.

Comprendre les scénarios de panne

Cette section contient huit scénarios de panne et compare deux déploiements, l'un avec persistance des sessions, l'autre sans.

Scénario 1 : Scénario Pas de flux de travaux

Description du scénario

L'utilisateur final ou l'administrateur édite un formulaire ne faisant pas partie d'un flux de travaux. L'instance sur laquelle l'utilisateur a une session établie tombe en panne.

Sans persistance des sessions

Expérience utilisateur : basculement non transparent. Lorsqu'il envoie le formulaire, l'utilisateur est ramené à la page de connexion.

Étapes de reprise : l'utilisateur entre de nouveau son nom d'utilisateur et son mot de passe. Identity Manager traite alors le formulaire et présente les résultats dans la page suivant immédiatement la connexion.

Avec persistance des sessions

Expérience utilisateur : le formulaire de l'utilisateur est envoyé et les résultats sont retournés sans que l'utilisateur ne soit déconnecté ni doive consécutivement se reconnecter.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Autres exemples de scénarios

Scénario 2 : Scénario Flux de travaux en cours

Description du scénario

L'utilisateur final ou l'administrateur a édité un formulaire qui a déclenché un flux de travaux. L'instance sur laquelle le flux de travaux s'exécute est en général la même que celle sur laquelle la session de l'utilisateur se trouve sauf dans le cas de certaines tâches programmées où ces instances peuvent différer. Ces instances tombent en panne alors que le flux de travaux est en cours.

Sans persistance des sessions

Expérience utilisateur : basculement non transparent. L'envoi du formulaire ramène l'utilisateur à la page de connexion. L'instance de la tâche de flux de travaux en cours d'exécution devrait figurer dans le référentiel mais comme le nœud d'exécution est en panne, le statut du flux de travaux sera « arrêté ».

Étapes de reprise : le flux de travaux doit être envoyé de nouveau. Cela doit se faire en revenant au même formulaire et en entrant de nouveau les informations déjà utilisées pour déclencher le flux de travaux avant la défaillance du nœud.

L'envoi des mêmes données de demande peut fonctionner dans certains cas mais pas dans tous. Si le flux de travaux provisionne pour plusieurs ressources pendant son exécution et que certaines de ces ressources étaient provisionnées avant la défaillance, le nouvel envoi du flux de travaux par l'utilisateur devra tenir compte des ressources « déjà provisionnées ». Vous remarquerez que le flux de travaux arrêté reste dans le référentiel jusqu'à ce que resultLimit expire sur l'objet TaskInstance.

Avec persistance des sessions

Expérience utilisateur : basculement non transparent. L'utilisateur n'est pas déconnecté car sa session est continuée et rétablie dans la nouvelle instance. L'envoi du formulaire, toutefois, se traduira probablement par une erreur car le flux de travaux sera arrêté. Ce basculement n'est pas transparent car des actions de reprise sont nécessaires.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions. L'utilisateur doit envoyer de nouveau la demande qui a déclenché le flux de travaux précédent avec des paramètres identiques ou modifiés.

Autres exemples de scénarios

Scénario 3 : Scénario Flux de travaux en suspens ou endormi

Description du scénario

Ce scénario couvre les cas de figure dans lesquels le flux de travaux a démarré mais attend une action manuelle de la part d'un approbateur.

Sans persistance des sessions

Expérience utilisateur : basculement transparent en ce qui concerne l'approbateur, du moment que ce dernier ne s'est pas encore connecté. Après la défaillance du nœud, l'approbateur se connectant verra quand même la demande d'approbation dans sa boîte de réception et ce, même si cette demande a été déclenchée depuis un nœud qui n'est plus activé.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise :identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

Scénario 4 : Scénario Édition d'un élément de travail

Description du scénario

Ce scénario inclut les cas de figure dans lesquels un utilisateur est en train d'éditer un élément de travail et où le nœud sur lequel l'utilisateur a une session tombe en panne avant qu'il puisse envoyer l'élément de travail en question.

Sans persistance des sessions

Expérience utilisateur : basculement non transparent. Lorsque le formulaire d'édition de l'élément de travail est envoyé, l'utilisateur est déconnecté et ramené à la page de connexion.

Étapes de reprise : lors du renvoi des données d'identification de connexion, l'élément de travail de l'utilisateur est marqué comme étant terminé et le flux de travaux peut reprendre à partir de ce point. Le flux de travaux doit être sélectionné par le nouveau mode pour l'exécution à partir du point où l'action manuelle de l'utilisateur est marquée comme étant terminée.

Avec persistance des sessions

Expérience utilisateur : lorsque le formulaire d'édition de l'élément de travail est envoyé, l'utilisateur voit l'effet de son envoi, par exemple le formulaire suivant dans le flux de travaux personnalisés s'il y en a un, ou un message de réussite.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Autres exemples de scénarios

Scénario 5 : Scénario Tâches programmées en cours

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels une panne de nœud se produit alors qu'une réconciliation est en cours ou qu'un rapport est en cours d'exécution.

Sans persistance des sessions

Expérience utilisateur : la tâche programmée s'arrête en cours.

Étapes de reprise : la tâche programmée qui était en cours doit être redémarrée. La tâche recommencera au début (pas à partir du point de panne). Cela revient à créer et démarrer une nouvelle tâche.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

Scénario 6 : Scénario Tâche programmée en suspens

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels le flux de travaux personnalisé d'un utilisateur a programmé une tâche pour qu'elle s'exécute à une date ultérieure sur un nœud spécifique. Le nœud sur lequel la tâche a été programmée tombe en panne avant la date prévue.

Sans persistance des sessions

Expérience utilisateur : le basculement est transparent en ce qui concerne les actions de reprise requises pour assurer que la tâche en question s'exécute à l'heure programmée.

Étapes de reprise : la tâche programmée est reprise par un nœud actif lorsque l'heure d'exécution programmée arrive.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

Scénario 7 : Scénario Demande de services Web pas encore reçue par Identity Manager

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels l'IUG d'Identity Manager n'est pas utilisée pour lancer le provisioning. À la place, l'interface utilisateur est fournie par une application qui émet en interne un appel vers Identity Manager en utilisant SPML ou une autre interface de service Web personnalisée. Ici, la session utilisateur relative à l'utilisateur qui suit l'IG est gérée au moyen de l'application appelante. Pour Identity Manager, les demandes sont toutes lancées en tant qu'objet « soapadmin ».

Dans un tel cas d'utilisation, ce scénario de panne couvre le cas dans lequel la demande par l'intermédiaire du point d'extrémité Identity Manager n'a pas encore été reçue et où le nœud ciblé est tombé en panne.

Sans persistance des sessions

Expérience utilisateur : basculement transparent. Les données d'identification de l'administrateur SOAP sont transférées pour chaque demande SOAP, soit via câble soit au sein d'Identity Manager par le biais du paramètre Waveset.properties. Du moment que le nœud qui devait recevoir cette demande SOAP ne l'a pas reçue avant de tomber en panne, le basculement est transparent avec ou sans persistance des sessions.

Étapes de reprise : aucune action n'est nécessaire. La demande SOAP est envoyée à un nœud actif qui l'exécute.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Scénario 8 : Scénario Demande de services Web en cours par Identity Manager

Description du scénario

Ce scénario est similaire au scénario sept. La seule différence est que le flux de travaux est en cours quand le nœud tombe en panne, ou que le nœud a reçu la demande SOAP avant de tomber en panne.

Sans persistance des sessions

Expérience utilisateur : ce scénario est similaire au scénario deux (flux de travaux en cours). Le flux de travaux est marqué comme étant arrêté et l'utilisateur voit une erreur en tant que résultat de la demande SOAP.

Étapes de reprise : l'utilisateur doit renvoyer le formulaire avec des paramètres similaires ou modifiés (selon le point du flux de travaux auquel la panne s'est produite) en utilisant l'interface utilisateur dans l'application tiers.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Foire aux questions relative à l'affinité de session et à la persistance des sessions

L'affinité de session doit-elle être activée lors de la mise à l'échelle horizontale des serveurs d'application ?

Oui.

Devez-vous activer la persistance des sessions lors de la mise à l'échelle horizontale des serveurs d'application ?

À moins que les exigences de votre entreprise ne mettent l'accent sur la nécessité d'un basculement transparent dans les situations limitées où la persistance des sessions peut faire une différence, Sun recommande de ne pas utiliser la persistance des sessions. La persistance des sessions a un coût en matière de performance et à moins que les basculements transparents ne soient strictement requis par les exigences de fonctionnement, laissez la persistance des sessions désactivée.

Si vous étudiez les scénarios de panne documentés dans Comprendre les scénarios de panne, dans six des huit scénarios il n'y a pas de différence au niveau de l'expérience de l'utilisateur final ou des actions de reprise requises, que la persistance des sessions soit activée ou non. Seuls les scénarios un et quatre comprennent des différences entre les scénarios avec persistance des sessions et ceux sans persistance des sessions.

Dans ces deux scénarios, la persistance des sessions peut fournir une certaine transparence des basculements mais elle influe négativement sur la performance. Selon la taille des objets de session, le référentiel utilisé pour la persistance des sessions et l'optimisation du code de gestion de sessions de votre serveur d'application spécifique, la baisse de performance peut être comprise entre 10 et 20 %, voire plus.

Devez-vous avoir plusieurs instances du serveur d'application dans un cluster en cas de mise à l'échelle horizontale ?

Il n'est absolument pas nécessaire d'avoir plusieurs instances du serveur d'application à moins que vous ne vouliez bénéficier de la persistance des sessions. Un basculement sans persistance des sessions peut être obtenu même si tous les nœuds de serveur d'application ne sont pas dans un cluster.