EJB et clusteringIntroduction Les EJB sont particulièrement nécessaires pour des applications critiques sur de grosses architectures matérielles, là où les ressources ne sont qu’un problème secondaire et où les avantages des EJB (gestion déclarative des transactions, distribution d’objets et support de la persistence automatique) prennent tout leur sens. Dans ce type de contexte, la tolérance aux pannes et la répartition de la charge sont des élements vitaux. Le clustering est la technologie permettant de répondre à ces 2 préoccupations. Ce document va donc s’intéresser à la bonne façon de le mettre en oeuvre en tentant de mettre en avant les pièges inhérents à l’utilisation d’un cluster. L’ABC du clustering Suivant sur les serveurs d’applications le clustering va permettre la réplication d’un certain nombre de types d’objets :
Bien entendu les Session beans sans etat (stateless) ne sont pas répliqués. En effet il n’y a aucun sens à essayer de répliquer un objet ne transportant pas d’ informations et anonyme (puisque ces objets sont gérés par le conteneur et activés/désactivés à la demande). On ne peut évoquer la réplication d’un objet sans en dire un petit mot. Qu’est ce que la réplication ? Quels mécanismes sont à la base de cette entité ? Basiquement, il faut voir la réplication comme une sérailisation de l’état d’un objet sur un réseau, ce qui sous entend (dans les grandes lignes) :
On vient donc de toucher un point sensible : la réplication est lente et verbeuse. Car en Java, elle s’appuie sur la sérialisation standard qui est à eviter quand on le peut... De plus l’utilisation de broadcasting sur un réseau, peut s’avérer problématique pour toutes les machines de ce même réseau. Architectures typiques Dans quel contexte va-t-on éprouver le besoin du clustering ? Comment le mettre en oeuvre concrétement dans un contexte J2EE ? Le Web étant devenu un point d’accès incontournable pour les applications d’ entreprise il faut supposer la présence d’un serveur Apache (ou autre) ,d’un serveur d’applications (contexte J2EE oblige) composé de 2 parties distinctes :
La partie traitements (affichage, présentation et exécutio ndes services métiers) étant nettement plus gourmande (et lente) que la simple obtention d’une page Web sur le disque. Il est logique de vouloir mettre en oeuvre, de manière transparente pour l’utilisateur, une toélrance aux pannes de notre serveur J2EE ( au sens du bloc des 2 serveurs). Pour cela il faut donc utiliser une architecture du type :
en l’occurence le répartiteur est classiquement le module Apache permettant la communication avec Tomcat :mod_jk. Pour les sites à très fortes charges et à très grosses exigences, il est aussi possible d’amenener un niveau supplémentaire de tolérance/répartition en ajoutant un répartiteur en amont d’Apache par un composant métariel (routeur Cisco) ou un composant logiciel (LVS sous Linux). La stack J2EE Stack est le nom donné à l’ensemble servlet-engine + serveur EJB. Il est bon en effet de prendre en compte l’importance de cet ensemble et d’ éviter de tomber dans des pièges classiques... Cohabitation naturelle... Typiquement une stack J2EE est composée de 2 gros produits, disons pour prendre des exemples du monde du logiciel libre Tomcat et JBOSS. Une première façon d’envisager la cohabitation est d’installer ces 2 produits de manière autonome. C’est la plus naturelle mais malheureusement celle posant aussi le plus de problèmes de performance puisqu’elle induit une communication entre 2 processus distincts (sur la même machine ou sur 2 machines différentes).
où les deux machines peuvent être la même machine physique. En effet ce positionnement de nos serveurs induit l’utilisation de la sérialisation et condamne donc vos serveurs à passer leur temps à sérialiser des objets Java et l’on a pas gagné grand chose... La collocation Dans ce mode de fonctionnement, le servlet engine n’est plus un processus autonome mais une fonctionnalité (service) embarquée du serveur EJB. Ces deux serveurs peuvent alors communiquer par des moyens beaucoup plus efficaces que la sérialisation Java : les pointeurs en mémoire. Comment choisir ? Il s’agit en fait dans ce cas entre choisir une manière souple (la première) s’ adaptant à tous les cas de figure et une option privilégiant la performance. A noter que la collocation exige des ressources mémoire importante mais permet d’économiser un PC !!! Le choix doit être avant tout guidé par des soucis d’ administration de son parc, car dans tous les cas la seconde est plus économique. Alors si vous êtes dans le cadre d’une mise en place d’une application ,optez pour la seconde façon de procéder et réservez la première option aux cas où vous devez composer avec des applications déjà en place... Les pièges liés au clustering Réplication de sessions HTTP En répliquant les sessions HTTP sur votre application (les dupliuqant ainsi de noeud en noeud), vous permettez à l’utilisateur ayant démarré une session de travail (au sens HTTP) de poursuivre sa visite sur votre site même si une machine (servlet engine) tombe... C’est parfait, très séduisant, mais en avez vous besoin ? Car cette fonctionnalité a un coût.... Les problèmes de réseau N’hésitez pas à placer les machines formant les noeuds de votre cluster sur un switch de votre réseau et à créer un sous réseau dédié. Sinon, vous vous exposez à des problèmes de gel de réseau pour des applications n’ayant rien à voir avec l’application déployée sous forme de cluster. Les tracas liés à la maintenance Un cluster peut s’avérer inmaintenable si vous ne veillez pas à adopter une politique claire d’exploitation de vos applications. N’essayez pas de déployer certaines applications sur ceratins noeuds et certaines autres sur d’autres noeuds du même cluster. Faites du tout ou rien , quitte à multiplier le nombre de grappes (clusters). A noter que ceci revient à créer ce que JBOSS appelle des groupes. On peut noter aussi que JBOSS permet via le ’farming’ de déployer une application automatiquement sur tous les noeuds d’un groupe. Et tout cela sans une once de configuration ,pas de fichiers de configuration complexes à maintenir, juste du broadcast et de la découverte automatique.... Auteur : Jérôme Molière
|
||
EJB entities
