2.1 Topologie
Le nombre d'instances de chaque sous-système principal et la manière dont ils peuvent être connectés sont potentiellement élevés. Toutes les configurations possibles ne sont pas prises en charge. Il est important d'en comprendre les possibilités mais également pourquoi certaines configurations sont préférables à d'autres.
2.1.1 Conception minimale
La configuration logique la plus simple de l'application utilisateur est l'installation « un de chaque », qui consiste en une arborescence du coffre-fort d'identité, une instance du moteur et des pilotes Identity Manager, et une instance de JBoss exécutant une instance unique de l'application utilisateur. En termes d'implémentation physique, vous pouvez, en théorie, exécuter l'ensemble dans une même machine. Mais ce n'est pas ce que l'on fait dans la réalité, pour plusieurs raisons (dont la sécurité, la maintenabilité et les performances). En décidant du nombre de machines nécessaires pour une installation réelle, vous devez prendre (au minimum) les éléments suivants en considération :
- Serveur Novell Audit : cet élément est responsable de la capture des informations sur les événements (et éventuellement d'un nombre important d'autres informations) de l'environnement de l'application utilisateur lors de l'exécution. Il peut également assurer une seconde responsabilité en servant de magasin de persistance pour d'autres applications de votre entreprise. Pour un ensemble de raisons, vous ne souhaiterez probablement pas installer d'autres composants principaux du système Identity Manager (par exemple, JBoss ou le coffre-fort d'identité) sur la même machine que le serveur Audit.
- Coffre-fort d'identité : il s'agit d'un composant soumis à un trafic élevé qui nécessite de bonnes performances et une bonne évolutivité. Selon toute vraisemblance, vous envisagerez de placer le coffre-fort d'identité sur une machine dédiée. Cela signifie que vous ne voudrez probablement pas qu'un autre système dont le trafic est élevé, tel que JBoss avec un déploiement de l'application utilisateur, soit exécuté sur la même machine que le coffre-fort d'identité.
- Base de données : si cette instance de MySQL (ou d'une autre base de données prise en charge) est également votre base de données Novell Audit, elle se trouvera probablement sur une machine dédiée. Prenez en considération que cet élément est utilisé par l'application utilisateur en tant que :
- magasin de persistance pour les données de configuration de portail ;
- magasin de persistance pour les informations d'état sur les workflows en cours (si le module de provisioning est installé) ;
- en option, magasin de consignation de Novell Audit.
- JBoss : pour des raisons de performances et de capacité, vous souhaiterez probablement exécuter cet élément sur une machine dédiée.
Ces considérations font ressortir la configuration minimale de 3 machines :
2.1.2 Conception haute disponibilité
La mise en grappe pour la haute disponibilité/capacité est abordée en détail dans une section ultérieure de ce chapitre. Pour l'instant, vous devez savoir que :
- Identity Manager prend en charge la haute disponibilité du coffre-fort d'identité, du moteur et des pilotes par l'intermédiaire de l'installation multi-noeuds et des mécanismes de stockage partagé décrits au chapitre consacré à la « Haute disponibilité » du Guide d'administration principal Identity Manager. La démarche complète de configuration d'un tel système avec SUSE Linux est fournie dans l'article qui se trouve à l'adresse :
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm
- La haute disponibilité de l'application utilisateur est possible grâce à la mise en grappe de JBoss. Vous pouvez configurer une grappe JBoss de telle manière que chaque noeud exécute une instance de l'application utilisateur. Les instances seront toutes égales (pairs). Quoi qu'il en soit, il n'y a pas de réplication de session dans les instances. Chaque instance est responsable de sa propre unité de travail et ne termine pas une session ayant démarré sur un noeud frère.
- La reprise automatique après échec n'est pas prise en charge (pour les raisons qui viennent d'être évoquées). Un workflow interrompu peut toutefois reprendre après la perte d'un noeud de la grappe, si un nouveau noeud est mis en ligne avec le même ID de moteur de workflow que celui qui a été interrompu. (Dans ce cas, la reprise du workflow interrompu se produit automatiquement au démarrage du nouveau moteur de workflow.)
Reportez-vous également à la Section 2.4, Mise en grappe (plus loin ci-dessous) pour une présentation plus détaillée de ces questions.
2.1.3 Contraintes de conception
En général, les deux contraintes d'architecture les plus importantes à prendre en considération sont les suivantes :
- Aucune instance de l'application utilisateur ne peut servir (rechercher/interroger, ajouter des utilisateurs à, etc.) plus d'un conteneur utilisateur. En outre, lorsqu'un conteneur utilisateur a été associé à l'application, cette association est censée être permanente.
- Aucun pilote d'application utilisateur ne peut être associé à plusieurs applications utilisateur, sauf lorsque ces dernières sont installées sur les noeuds frères de la même grappe JBoss. En d'autres termes, l'assignation « un à plusieurs » des pilotes aux applications utilisateur n'est pas prise en charge.
La première contrainte implique un degré élevé d'encapsulation dans la conception de l'application utilisateur.
Supposons que votre structure organisationnelle soit la suivante :
Au cours de l'installation de l'application utilisateur, vous êtes invité à spécifier le conteneur utilisateur de niveau supérieur que votre installation recherchera dans le coffre-fort d'identité. Dans ce cas, vous pouvez spécifier ou=Marketing,o=ACME ou (autre possibilité) ou=Finance,o=ACME. Vous ne pouvez pas spécifier les deux. L'étendue de toutes les recherches et requêtes de l'application utilisateur (et logins de l'administrateur) sera limitée au conteneur que vous spécifiez.
REMARQUE:En théorie, vous pouvez spécifier une étendue de o=ACME pour englober le Marketing et la Finance. Dans une organisation de grande dimension, avec potentiellement de nombreux conteneurs ou (plutôt que simplement deux associés au Marketing et à la Finance), par contre, cela risque de ne pas être pratique.
Il est possible, bien entendu, de créer deux installations indépendantes de l'application utilisateur (ne partageant aucune ressource en commun), l'une pour le Marketing et l'autre pour la Finance. Chaque installation doit avoir sa propre base de données, son propre pilote d'application utilisateur correctement configuré. Chaque application utilisateur doit en outre être administrée séparément, avec des thèmes uniques si possible.
Si vous devez vraiment placer le Marketing et la Finance dans la même étendue pour une installation de l'application utilisateur, vous devez envisager deux tactiques possibles. L'une consiste à insérer un nouvel objet conteneur (par exemple, ou=MarketingAndFinance) dans la hiérarchie, au-dessus des deux noeuds frères. Pointez ensuite vers le nouveau conteneur comme racine de l'étendue. Une autre tactique consiste à créer une réplique filtrée (un type spécial d'arborescence eDirectory) qui combine les parties nécessaires de l'arborescence ACME d'origine, et à pointer l'application utilisateur vers le conteneur racine de la réplique. Reportez-vous au Guide d'administration de Novell eDirectory pour plus d'informations sur les répliques filtrées.
Si vous avez des questions concernant une configuration particulière du système, contactez votre représentant Novell pour obtenir de l'assistance ou un conseil.