Print-friendly Version

Index des articles

La version 2 de GlassFish Java EE Application Server comporte de nombreuses nouvelles caractéristiques, notamment des capacités de clustering renforcées. Les nouvelles capacités de clustering renforcent la disponibilité et l'évolutivité des architectures de déploiement par réplication d'état de session en mémoire. Grâce à la réplication d'état en mémoire, les instances du serveur clusterisé répliquent l'état de session selon une topologie en anneau, stockant les informations répliquées en mémoire.

Cet article décrit les capacités de clustering de GlassFish version 2 et vous aide à commencer le déploiement de votre application vers un cluster GlassFish.

Sun Java System Application Server 9.1 représente la distribution supportée par Sun du serveur d'application Open Source GlassFish version 2. Cet article emploie le nom GlassFish version 2 pour englober les deux.

• Concepts de base
• Architecture d'administration de domaine
• Architecture de clustering
• Scénario de basculement type
• Changement de forme dynamique du cluster
• Service de gestion de groupe
• Configuration de la réplication de mémoire
• Implémentation de la réplication de mémoire
• Installation du serveur d'application
• Configuration du clustering
• Étude du domaine
• Support du cluster pour un domaine existant
• Plug-in d'équilibreur de charge HTTP
• Conclusion
• Remerciements
• Références

Dans un serveur d'application, les clusters renforcent l'évolutivité et la disponibilité, qui sont des concepts liés.

Afin d'offrir une haute disponibilité du service, un système logiciel doit posséder les capacités suivantes :

• Le système doit être capable de créer et d'exécuter plusieurs instances d'entités de prestation de service. Dans le cas de serveurs d'application, les entités de prestation de service sont des instances du serveur d'application Java EE configurées pour exécution en cluster, et le service est une application Java EE déployée.
   
  
• Le système doit être capable d'évoluer en déploiements plus conséquents par ajout d'instances de serveur d'application aux clusters afin d'accepter des charges de service croissantes.
   
  
• En cas de défaillance d'une instance de serveur d'application dans un cluster, il doit être capable de basculer sur une autre instance de serveur afin de ne pas interrompre le service. Bien que la défaillance d'une instance de serveur ou d'une machine physique soit susceptible de dégrader la qualité de service globale, l'interruption complète du service n'est pas acceptable dans un environnement de haute disponibilité.
   
  
• Lorsqu'un processus modifie l'état d'une session utilisateur, l'état de la session doit être préservé au cours des redémarrages du processus. Le mécanisme le plus simple consiste à maintenir une réplique fiable de l'état de session de sorte que, si un processus échoue, l'état de la session puisse être récupéré au redémarrage du processus. Le principe est similaire à celui utilisé dans les systèmes de stockage RAID de haute fiabilité.
  

Globalement, ces demandes résultent obligatoirement en un système qui sacrifie la haute efficacité pour atteindre la haute disponibilité.

Afin de supporter les objectifs d'évolutivité et de haute disponibilité, le serveur d'application GlassFish offre les entités suivantes côté serveur :

• instance de serveur – Une instance de serveur est le processus de serveur Java EE (le serveur d'application GlassFish) qui héberge vos applications Java EE. Comme l'exige la spécification Java EE, chaque instance de serveur est configurée pour les différents sous-systèmes qu'elle peut être amenée à exécuter.
   
  
• agent de noeud – Un agent de noeud est un processus d'agent qui est exécuté sur chacun des hôtes physiques où une instance de serveur est exécutée. L'agent de noeud gère le cycle de vie d'une instance de serveur lorsqu'il est dirigé par le serveur d'administration de domaine (DAS, Domain Administration Server) décrit plus loin dans cet article.
   
  
• Cluster – Un cluster est une entité logique qui détermine la configuration des instances du serveur qui composent le cluster. Généralement, la configuration d'un cluster implique que toutes les instances du serveur au sein du cluster possèdent une configuration homogène. Un administrateur considère généralement le cluster comme une entité unique et utilise la console d'administration GlassFish ou une interface de ligne de commande (CLI, Command Line Interface) pour gérer les instances du serveur dans le cluster.
  

Les agents du noeud, les instances du serveur et les clusters peuvent être créés au moment de l'installation de GlassFish comme indiqué dans la dernière partie de cet article. Les clusters et les instances sont organisés en domaines administratifs, décrits ci-après, caractérisés par le serveur d'administration de domaine (DAS).

L'architecture centrale vers l'architecture de clustering GlassFish est le concept d'un domaine administratif. Le domaine administratif est une représentation des droits d'accès d'un administrateur ou d'un groupe d'administrateurs. La figure suivante présente une vue d'ensemble de l'architecture de domaine d'administration, dans le contexte d'un domaine unique.

Figure 1. Architecture d'administration de domaine

Un domaine administratif est une entité de nature double :

• Utilisé par un développeur, il offre un processus Java EE complet pour exécuter vos applications et services.
  
  
• Utilisé dans un déploiement pratique en entreprise, il offre un processus dédié à la configuration et à l'administration d'autres processus. Dans ce cas, un domaine administratif prend la forme d'un Serveur d'administration de domaine (DAS) que vous pouvez utiliser à des fins purement administratives.
  

Dans le système de fichiers, un domaine administratif est composé d'un ensemble de fichiers de configuration. A l'exécution, c'est un processus qui s'administre lui-même ainsi que les instances de serveur indépendantes, les clusters, les applications et les ressources.

Les installations de haute disponibilité nécessitent généralement des clusters au lieu d'instances de serveur indépendantes. Le serveur d'application GlassFish fournit des clusters homogènes et vous permet de gérer et de modifier chaque cluster comme s'il s'agissait d'une seule entité.

Comme illustré par la figure, chaque domaine possède un serveur d'administration de domaine (DAS, Domain Administration Server) qui sert à gérer les instances de Java EE Server dans le domaine. Le noeud d'administration au centre de la figure supporte le DAS. Les applications, les ressources et les informations de configuration sont stockées à proximité du DAS. Les informations de configuration gérées par le DAS sont appelées référentiel central de configuration.

Chaque processus du domaine doit être exécuté sur un hôte physique. Lors de l'exécution, le domaine se manifeste comme un DAS. De la même façon, chaque instance de serveur doit être exécutée sur un hôte physique et exige une machine virtuelle Java. Le serveur d'application GlassFish doit être installé sur chacune des machines qui exécute une instance de serveur.

Deux noeuds figurent sur le côté droit de l'illustration : le Noeud 1 et le Noeud 2, qui hébergent chacun deux instances de GlassFish.

Chaque agent de noeud contrôle les cycles de vie des instances qui sont configurées sur sa machine dans un domaine donné. Généralement, chaque cycle de vie est géré par le DAS conformément aux demandes de l'administrateur. Le DAS délègue la gestion du cycle de vie de chaque instance à son agent de noeud correspondant. Un agent de noeud est un processus léger qui n'exécute pas lui-même d'applications Java EE.

En plus de contrôler les cycles de vie de l'instance, un agent de noeud surveille ("chiens de garde") les instances du serveur dont il est responsable. En cas de défaillance d'une instance de serveur, son agent de noeud apporte sa sauvegarde — sans intervention de l'administrateur ou du DAS .

Plusieurs clients administratifs sont présentés sur le côté gauche de la Figure 1. L'infrastructure administrative dans le DAS est fondée sur la technologie Java Management Extensions (JMX). L'infrastructure dans le DAS suit le niveau d'instrumentation de la spécification JAX et emploie les informations de gestion sous forme de Managed Beans (MBeans), des objets Java qui représentent les ressources à gérer.

Les MBeans étant compatibles avec la norme JMX, vous pouvez les parcourir avec n'importe quel client JMX standard distant (notamment JConsole, distribué avec Java SE 5.0 et versions ultérieures). Les clients intégrés présentés dans la Figure 1 utilisent l'API JMX pour gérer le domaine. Ces clients doivent disposer de privilèges d'administrateur pour gérer le domaine. Les clients administratifs suivants sont intéressants :

• Console d'administration – La console d'administration est une interface par navigateur pour la gestion du référentiel central. Le référentiel central fournit la configuration au niveau du DAS .
   
  
• Interface de ligne de commande – La commande asadmin duplique la fonctionnalité de la console d'administration. En outre, certaines actions ne peuvent être effectuées que par l'intermédiaire d'asadmin, notamment la création d'un domaine ou d'un agent de noeud. Vous ne pouvez pas exécuter la console d'administration sans un DAS, ce qui présuppose un domaine et un agent de noeud. La commande asadmin fournit le moyen d'initialiser l'architecture.
   
  
• EDI – La figure présente un instantané de l'éditeur JSP (JavaServer Page), qui fait partie des NetBeans EDI. Les outils tels que l'EDI NetBeans peuvent utiliser le DAS pour se connecter à une application et la gérer pendant le développement. L'EDI NetBeans peut également supporter un déploiement en mode cluster. La plupart des développeurs travaillent avec un seul domaine et une seule machine, appelés profil développeur. Dans le profil développeur, le DAS proprement dit agit comme hôte de toutes les applications.
   
  
• Sun Provisioning Server – Sun Provisioning Server sert à l'installation et au provisioning d'un DAS sur les machines configurées de façon primitive. Par exemple, considérons un centre de données important dans lequel vous introduisez une nouvelle machine. Dans ce cas, vous initialisez la machine en installant un système d'exploitation, puis vous installez les logiciels nécessaires. Ensuite, vous pouvez créer un agent de noeud et peut-être un DAS, selon les besoins spécifiques. Enfin, vous intégrez la machine dans un domaine existant en démarrant l'agent de noeud. Sun Provisioning Server peut accomplir toutes ces tâches sans effectuer d'installation manuelle sur la nouvelle machine.
  

La Figure 2 présente l'architecture de clustering GlassFish du point de vue de l'exécution. Cette vue souligne les aspects haute disponibilité de l'architecture. Le DAS n'est pas représenté dans la Figure 2, et les noeuds et leurs instances de serveur d'application sont groupés sous forme d'instances clusterisées.

Figure 2. Présentation de l'architecture de clustering

En haut de la Figure 2, différents transports ( HTTP, JMS, RMI-IIOP) sont indiqués, communiquant avec les instances clusterisées par l'intermédiaire d'un niveau d'équilibrage de charge. Les ressources sur mesure comme les systèmes d'information de l'entreprise, sont connectées à l'équilibreur de charge par l'intermédiaire d'adaptateurs de ressources dans l'architecture de connecteur Java. Tous les transports peuvent faire l'objet d'un équilibrage de charge dans le cluster, à la fois en termes d'évolutivité et de stratégies de tolérance de panne implémentées par des unités redondantes disponibles en cas de point de panne unique.

En bas de la figure, se trouve un référentiel d'état d'application haute disponibilité, une abstraction de stockage d'état de session. Le référentiel stocke l'état de la session, y compris l'état de la session HTTP, l'état de cession EJB avec état et les informations de connexion unique. Ces informations d'état peuvent être stockées par réplication de mémoire ou au moyen d'une base de données.

Sun Microsystems offre historiquement une robuste solution haute disponibilité pour les serveurs d'application fondés sur la technologie de base de données haute disponibilité (HADB, High-Availability Database). HADB offre une disponibilité à 99,999 pour cent (“les cinq neuf”) pour le maintien des informations d'état de session. Toutefois, son coût d'implémentation et d'entretien est relativement élevé et, bien que librement disponible, elle n'a jamais été proposée en version Open Source.

Les demandes pour une alternative Open Source plus légère pour accompagner le serveur d'application Open Source GlassFish se sont traduites par une fonction de réplication de mémoire dans GlassFish version 2. La réplication de mémoire s'appuie sur des instances au sein du cluster pour stocker des informations d'état mutuelles en mémoire, et non dans une base de données. La solution HADB demeure toutefois disponible, et peut être préférable pour de nombreuses installations.

Plusieurs caractéristiques sont nécessaires pour un système compatible GlassFish à tolérance de pannes qui maintient les informations d'état en mémoire. Le système doit offrir une haute disponibilité pour l'état de session HTTP, l'état de connexion unique et l'état de session EJB . Il doit aussi être compatible avec les architectures HADB.

La fonction de réplication de mémoire tire parti de la fonction de clustering de GlassFish pour offrir la plupart des avantages de la stratégie HADB avec des charges d'installation et d'administration bien moindres.

Dans le serveur d'application GlassFish, les instances de cluster sont organisées selon une topologie en anneau. Chaque élément de l'anneau envoie des données d'état de mémoire à l'élément suivant de l'anneau, son partenaire de réplique, et reçoit des données d'état de l'élément précédent. Les données d'état étant actualisées dans n'importe quel élément, elles sont répliquées tout autour de l'anneau. La topologie est illustrée sous forme simplifiée dans la Figure 3.

Figure 3. Topologie de clustering

La façon dont la topologie est formée en anneau est déterminée par l'ordre alphanumérique des noms que vous attribuez à vos instances. Ainsi, si vous appelez vos instances comme dans la Figure 3, l'Instance 1 répliquera vers l'Instance 2, l'Instance 2 vers l'Instance 3, et ainsi de suite, autour de l'anneau.

Une topologie de cluster type est illustrée par la Figure 4. Dans la figure, les instances sont présentées hébergées sur différentes machines physiques. En plaçant les Instances 1 et 3 sur une machine et les Instances 2 et 4 sur une autre machine, vous optimisez la disponibilité. En cas de panne catastrophique de l'une des machines, toutes les données sont préservées sur l'autre machine, sous leur forme originale ou comme répliques des instances de la machine en panne.

Figure 4. Topologie de cluster type

Le serveur d'application GlassFish est conçu de sorte que le niveau d'équilibreur de charge ne nécessite aucune information spéciale pour fonctionner correctement en cas de panne. Par exemple, l'équilibreur de charge, ayant acheminé une session à l'Instance 1, n'a pas besoin de savoir qu'il doit acheminer la session à l'Instance 2 lorsque l'Instance 1 est en panne. L'équilibreur de charge peut émettre une demande de basculement vers n'importe quelle instance du cluster, situation souvent décrite comme transparence de localisation. La réponse à une panne intervient dans le cluster. Lorsque l'équilibreur de charge réachemine une session vers une instance qui fonctionne, cette dernière obtient les informations de session stockées nécessaires d'une autre instance, au besoin.

Les demandes de basculement provenant d'un équilibreur de charge relèvent de deux cas :

• Cas 1 : La demande de basculement arrive sur une instance qui stocke déjà des données de réplication de la session. Dans ce cas, l'instance prend possession de la session et le traitement continue.
   
  
• Cas 2 : La demande de basculement arrive sur une instance qui ne possède pas les données répliquées nécessaires. Dans ce cas, l'instance diffuse une demande sous forme d'enveloppe affranchie adressée à elle-même (SASE) demandant les données. L'instance qui possède les données répliquées les transfère vers le demandeur et supprime sa copie après qu'un message d'accusé de réception lui ait indiqué que les données ont bien été reçues. L'échange de données est effectué au moyen de la technologie JXTA (Juxtapose).
  

La Figure 5 présente le cluster plus en détail. Un niveau d'équilibrage de charge se trouve sur la gauche, peut-être sur un serveur web. Dans chaque instance de serveur, un cache local stocke les informations de session HTTP, et le cache est copié dans une réplique du cache dans l'instance suivante.

Figure 5. Topologie de cluster type avec équilibreur de charge Cliquez ici pour agrandir l'image

La Figure 6 illustre le Cas 1 de basculement, dans lequel l'instance réacheminée du serveur accède immédiatement aux données d'état de la session. Dans la figure, l'Instance 1 est en panne et la demande de service de l'équilibreur de charge se trouve acheminée vers l'Instance 2, qui possède une réplique des informations d'état de session voulues.

Figure 6. Basculement, Cas 1 Cliquez ici pour agrandir l'image

La Figure 7 illustre le Cas 2 de basculement, dans lequel le niveau d'équilibreur de charge réachemine une session vers une instance de serveur qui n'accède pas immédiatement aux données d'état de la session. Dans la figure, l'Instance 4 reconnaît qu'elle ne dispose pas des données d'état de session nécessaires et diffuse une SASE aux autres instances dans le cluster, demandant les données. La demande est illustrée par les flèches jaunes.

Figure 7. Basculement, Cas 2 Cliquez ici pour agrandir l'image

L'une des instances (l'Instance 2 dans la Figure 7) reconnaît que sa réplique contient les données voulues et répond à la demande par SASE. L'Instance 2 transfère les données de la session à l'Instance 4, qui rétablit ensuite la session.

Lorsqu'une instance utilise des données répliquées pour rétablir une session (comme dans les cas 1 et 2), les données répliquées sont préalablement testées pour vérifier qu'il s'agit de la version actuelle.

Lorsqu'une instance d'un cluster est en panne ou a été délibérément mise hors ligne par un administrateur, la topologie du cluster change obligatoirement.

Dans notre exemple, l'Instance 1 étant en panne, la topologie du cluster doit changer pour maintenir la réplication de cache de la session. Dans la Figure 8, l'Instance 2 et l'Instance 4 apprennent que l'Instance 1 a disparu. L'instance 1 étant en panne, les tentatives pour communiquer avec elle échouent avec exceptions E/S. Lorsqu'une instance est délibérément retirée, la technologie JXTA envoie des messages indiquant que l'Instance 1 a été fermée.

Figure 8. Le cluster découvre l'instance en panne Cliquez ici pour agrandir l'image

En réponse à la disparition de l'Instance 1, l'Instance 4 sélectionne un nouveau partenaire de réplication, comme illustré par la Figure 9. L'Instance 4 nettoie ses anciennes connexions et établit la connexion avec l'Instance 2. Le cluster est maintenant réduit de 4 à 3 instances du serveur.

Figure 9. : Changement de forme dynamique du cluster Cliquez ici pour agrandir l'image

Notez que chaque instance du cluster réduit travaille dorénavant davantage pour un même niveau d'activité globale de la session. Pour la planification des ressources, considérez que la réplication en mémoire utilise énormément de mémoire. Pour offrir une haute disponibilité, vérifiez que vous disposez d'une marge suffisante de mémoire pour chaque instance en cas de réduction du cluster.

Lorsqu'une instance rejoint (ou revient) dans le cluster, le processus est inversé. Lorsqu'une nouvelle instance du cluster reçoit une demande du niveau d'équilibreur de charge, elle diffuse une demande pour un partenaire de réplication, en choisit un, et la topologie s'ajuste automatiquement pour englober la nouvelle instance.

Le service de gestion de groupe (GMS, Group Management Service) fournit des informations d'appartenance dynamiques sur un cluster et les instances qui en font partie. Sa conception doit beaucoup au Projet Shoal, un cadre de clustering fondé sur la technologie Java. Au fond, le GMS est également basé sur la technologie JXTA.

Le GMS gère les événements de changement de forme du cluster dans GlassFish, en les coordonnant comme éléments arrivant, éléments fermés gracieusement ou éléments en panne. Par l'intermédiaire du GMS, la réplication de mémoire prend les mesures nécessaires en réponse à ces événements et fournit une disponibilité ininterrompue du service.

Le GMS est utilisé dans le serveur d'application GlassFish pour surveiller l'état de santé du cluster et pour supporter le module de réplication de mémoire.

En résumé, le GMS offre le support suivant :

• Notifications de changement d'appartenance au cluster et d'état du cluster
   
  
• Messagerie dans l'ensemble du cluster ou entre éléments
   
  
• Calcul orienté reprise, y compris sélection d'un élément de reprise, séparation en cas d'échec, et enchaînement de reprise en cas de pannes multiples
   
  
• Cache distribué, une implémentation légère adaptée à l'échange de messages sur les éléments du cluster
   
  
• Une interface de fournisseur de service (SPI) pour connecter les fournisseurs de service de groupe ; le fournisseur par défaut est basé sur la technologie JXTA
   
  
• Migrations d'horloge – le GMS sélectionne une instance pour reprendre les horloges d'une instance en panne si nécessaire
  

Pour configurer la réplication de mémoire du cluster, vous devez procéder à trois étapes :

1. Créer un domaine administratif. Une fois le domaine créé avec ses agents du noeud sur les machines hébergeant le cluster, un profil administratif du cluster est créé. Le profil définit les valeurs par défaut de réplication, active le GMS et définit la propriétépersistance-type comme replicated.
    
   
2. Créer un cluster et ses instances selon la description présentée plus loin dans cet article.
    
   
3. Déployer vos applications web avec la propriété disponibilité-activée réglée sur true.

Vous pouvez effectuer ces étapes avec l'IG ou la CLI.

Certains réglages supplémentaires peuvent être nécessaires. Par exemple, la taille par défaut du tas pour le profil administratif du cluster est de 512 Mo. Pour un déploiement d'entreprise, cette valeur doit être augmentée jusqu'à 1 Go ou davantage. Cette opération est facilement accomplie par l'intermédiaire du serveur d'administration du domaine en réglant les options JVM avec les balises suivantes :

<jvm-options>-Xmx1024m</jvm-options>
<jvm-options>-Xms1024m</jvm-options>

Vous devez aussi veiller à ajouter la balise <distributable /> au fichier web.xml de votre application web. Cette balise indique que l'application est compatible avec les clusters.

La nécessité d'insérer la balise <distributable /> est un rappel pour tester votre application dans un environnement de cluster avant de la déployer dans un cluster. Certaines applications fonctionnent bien lorsqu'elles sont déployées en une seule instance et échouent lorsqu'elles sont déployées dans un cluster. Par exemple, avant de réussir le déploiement d'une application dans un cluster, tous les objets tels que les beans de session avec état qui appartiennent à la session HTTP de l'application doivent être sérialisables de sorte que leurs états puissent être conservés sur un réseau. Les objets non sérialisables peuvent fonctionner lorsqu'ils sont déployés dans une seule instance de serveur, mais échouent dans un environnement de cluster. Examinez le contenu de vos données de session pour vérifier qu'elles fonctionneront correctement dans un environnement distribué.

Dans le serveur d'application GlassFish version 2, la fonction de réplication de mémoire est basée sur les capacités de transport et de messagerie de la technologie JXTA.

Pour beaucoup, la technologie JXTA est connue sous l'appellation peer-to-peer. Elle est définie comme un ensemble de protocoles XML qui permettent aux appareils connectés d'échanger des messages et de collaborer quelle que soit la topologie du réseau. Dans le développement du serveur d'application GlassFish version 2, la technologie JXTA a été rationalisée pour traiter les demandes de gros volume et haut rendement de réplication de mémoire. Pour améliorer l'évolutivité et les performances, les développeurs de la fonction de réplication de mémoire ont également profité d'une collaboration avec le projet Grizzly, qui aide les développeur à élaborer de robustes serveurs évolutifs avec l'API Java New I/O (NIO).

Les abstractions d'appartenance de groupe de la technologie JXTA correspondent bien au cluster de serveur d'application GlassFish et au modèle d'instance : les groupes JXTA correspondent aux clusters GlassFish et les pairs JXTA correspondent aux instances du serveur GlassFish. Le GMS profite de ces abstractions d'appartenance de groupe et fournit des composants consommables tels que la réplication de mémoire, un modèle d'événement de notification pour les événements d'exécution dans le cluster.

Dans le développement du serveur d'application GlassFish version 2, les topologies de clustering ont été limitées à un seul sous-réseau. Les futurs projets comprennent l'exploitation de la technologie JXTA pour inclure la dispersion géographique des topologies de clustering.

Enfin, les API directes de la technologie JXTA ont rendu possible les simples exigences de configuration pour le clustering de GlassFish.

Pour installer le serveur d'application GlassFish :

1. Tapez la commande suivante :
    
   

   java -jar filename.jar

    
   Par exemple :
    
   

   java -jar glassfish-installer-v2-b58g.jar

   
    
   
2. Acceptez le contrat de licence. Une fois la licence acceptée, le fichier se décompresse dans le répertoire d'installation GlassFish, intitulé glassfish par défaut.

Vous devez maintenant configurer le serveur d'application GlassFish.

Le répertoire d'installation contient deux scripts de construction ant que vous pouvez utiliser pour créer des domaines par défaut. Les deux scripts sont setup.xml et setup-cluster.xml.

Le script setup.xml crée le fichier du développeur ; le script setup-cluster.xml crée un profil de cluster. Vous pouvez convertir un fichier de développeur en profil de cluster avec la console d'administration de serveur d'application Sun Java System, comme indiqué ci-dessous.

Pour créer un domaine par défaut avec un profil de clustering :

• Tapez la commande suivante dans le répertoire d'installation de GlassFish :
   
  

  lib/ant/bin/ant -f setup-cluster.xml

   
  Le script de configuration décompresse les archives et crée un sous-répertoire domains ainsi qu'un domaine compatible clustering intitulé domain1.

Le configuration de GlassFish est terminée.

Vous pouvez découvrir et gérer les domaines depuis la CLI (la commande asadmin) ou l'IG (la console d'administration de serveur d'application Sun Java System).

L'étape de configuration a créé un sous-répertoire domains dans le répertoire d'installation. Ce répertoire stocke tous les domaines GlassFish.

Vous pouvez intervenir sur les domaines depuis la CLI avec la commande asadmin située dans le sous-répertoire bin sous le répertoire d'installation. La commande asadmin peut être utilisée en mode batch ou interactif.

Par exemple, vous pouvez lister tous les domaines et leurs états avec la commande suivante :

bin/asadmin list-domains 

Si vous n'avez pas encore démarré domain1, la commande émet la sortie suivante :

domain1 not running

Pour démarrer domain1, tapez la commande suivante :

bin/asadmin start-domain domain1

L'argument domain1 est facultatif s'il n'existe qu'un domaine. La commande démarre domain1 et fournit des informations sur la localisation du fichier journal, la version du serveur, le nom de domaine, les contextes web disponibles, les applications déployées, les ports utilisés, etc.

Au lieu de la commande asadmin vous pouvez utiliser la console d'administration de serveur d'application Sun Java System pour contrôler le serveur d'application. La section suivante indique comment démarrer la console.

La console d'administration facilite le déploiement des applications depuis les fichiers .war ou .ear ou même les assemblages de service JBI (Java Business Integration). Depuis la console, vous pouvez surveiller l'utilisation des ressources, rechercher les fichiers journaux, démarrer et arrêter le serveur, accéder à l'aide en ligne et effectuer de nombreuses autres fonctions administratives et de gestion du serveur.

Vous pouvez ajouter le support de clustering à un domaine existant. Un domaine avec profil développeur ne supporte pas le clustering si vous ne modifiez pas sa configuration. Depuis le répertoire d'installation de GlassFish, vous pouvez créer un domaine de profil développeur avec la commande suivante :

lib/ant/bin/ant -f setup.xml

Pour permettre le clustering à partir d'un domaine de profil développeur :

1. Depuis le répertoire d'installation de GlassFish, démarrez le domaine à reconfigurer pour le clustering en tapant la commande suivante :
    
   

   bin/asadmin start-domain domain_name

    
   

   Par exemple :

   bin/asadmin start-domain domain1

    
   

   La commande démarre le serveur d'application GlassFish et fournit des informations dans la fenêtre de shell de commande. La dernière ligne d'informations indique les capacités du domaine ; dans le cas présent :

   Domain does not support application server clusters and other standalone instances.

    
   
2. Démarrez la console d'administration en dirigeant votre navigateur web sur l'URL :
    
   

   http://hostname:port

    
   

   Le port par défaut est 4848. Par exemple :

   http://kindness.sun.com:4848

    
   

   Si la console d'administration est exécutée sur la machine où le serveur d'application a été installé, spécifiez le nom d'hôte localhost. Sous Windows, démarrez la console d'administration de serveur d'application depuis le menu Démarrer.

   La connexion par défaut est

   Nom d'utilisateur : admin
   Mot de passe : adminadmin

3. Dans l'arborescence Tâches courantes sur la gauche de la fenêtre, sélectionnez Serveur d'application. Sur la droite de la fenêtre, sélectionnez l'onglet Général.
    
   
4. Cliquez sur le bouton Ajouter le support de cluster, comme illustré dans la figure ci-dessous.
    
   

   Figure 10. : Ajout du support de cluster Cliquez ici pour agrandir l'image

    
   
5. Une page de confirmation est affichée pour vous signaler les conséquences du changement vers le support de clustering. Parmi les aspects à considérer :
    
   
   • La configuration du domaine change pour le support des clusters. La modification comprend l'ajout de quelques propriétés système et configurations de modèles.
      
     
   • Le serveur compatible clustering supporte les clusters et les instances autonomes du serveur.
      
     
   • La présence d'un cluster augmentant souvent les demandes en termes de ressources, vous pouvez modifier les paramètres JVM du serveur d'administration, notamment la taille du tas.
      
     
   • Toutes les application actuellement déployées sur le serveur dans le domaine compatible clustering continueront à fonctionner.
      
     
   • Le changement pour supporter le clustering prend effet après redémarrage du serveur de domaine et de la CLI asadmin.
      
     
   • Vous pouvez sauvegarder le fichier domain.xml du domaine avant de continuer, pour le cas où vous souhaiteriez revenir en arrière.
      
     
6. Cliquez sur OK pour activer le support de clustering pour le domaine. Une page s'ouvre pour vous rappeler de redémarrer l'instance de serveur pour le domaine.
    
   
7. Cliquez sur le bouton Stop Instance (Arrêter l'instance).
    
   
8. Si la commande asadmin est exécutée dans votre shell de commande, quittez-la en tapant quit à l'invite asadmin>.
    
   
9. Redémarrez le domaine depuis la CLI en tapant la commande suivante :
    
   

   asadmin start-domain domain_name

    
   

   par exemple,

   asadmin start-domain domain1

    
   

   Si l'activation du clustering pour ce domaine a réussi, la ligne finale de sortie dans le shell de commande affiche :
    
   

   Domain supports application server clusters and other standalone instances

    
   

Un équilibreur de charge distribue la charge de travail parmi plusieurs instances du serveur d'application, augmentant ainsi le rendement du système. Bien que le niveau de l'équilibreur de charge ne nécessite aucune connaissance spéciale pour acheminer les demandes de session vers les instances du serveur, il doit maintenir une liste des noeuds disponibles. Lorsqu'un noeud ne répond pas à une demande comme prévu, l'équilibreur de charge en choisit un autre.

Les équilibreurs de charge peuvent être implémentés en logiciel ou matériel. Consultez les informations données par les fournisseurs de matériel pour implémenter leurs appareils.

Un plug-in d'équilibreur de charge HTTP est disponible pour le serveur d'application GlassFish version 2. Il fonctionne avec le serveur d'application Sun Java System 9.1 ainsi qu'avec Apache Web Server et Microsoft IIS. L'équilibreur de charge permet également le basculement des demandes entre les instances de serveur, contribuant à la haute disponibilité des installations.

Pour des informations plus détaillées sur la configuration du plug-in d'équilibreur de charge, consultez l'aide en ligne disponible depuis la console d'administration de serveur d'application Sun Java System 9.1 Admin. Pour des informations plus détaillées, consultez le Chapitre 5, Configuration de l'équilibrage de charge HTTP dans le Guide d'administration haute disponibilité de Sun Java System Application Server 9.1

Le serveur d'application GlassFish version 2 offre une architecture de clustering souple composée de domaines administratifs, de serveurs de domaine administratif, d'instances de serveurs et de machines physiques. L'architecture associe la facilité d'emploi à un haut degré de contrôle administratif pour améliorer la haute disponibilité et l'évolutivité horizontale.

• Haute disponibilité - Plusieurs instances de serveur, capables de partager l'état, réduisent les points de panne unique, en particulier lorsqu'ils sont associés à des programmes d'équilibrage de charge. La réplication en mémoire des données de session du serveur réduit les interruptions d'utilisation en cas de panne d'une instance de serveur.
   
  
• Évolutivité horizontaleÀ mesure que la charge d'utilisation augmente, des machines, des instances de serveur et des clusters peuvent être ajoutés et facilement configurés pour traiter la charge croissante. Le GMS soulage la charge administrative du maintien d'un cluster haute disponibilité.

Merci à Larry White, Abhijit Kumar et Dinesh Patil pour leur aide dans la préparation de cet article.

• Guide d'administration haute disponibilité de Sun Java System Application Server 9.1
• Collection de guides Sun Java System Application Server 9.1
• Page de téléchargement pour la communauté GlassFish
• The Aquarium — Wiki de la communauté GlassFish
• Blog de Kedar Mhaswade — ajouter le support de clustering à un domaine
• Blog de Prashanth Abbagani — configuration de l'équilibrage de charge et clustering dans GlassFish version 2
• Page de Sun Java System Application Server — avec liens vers le site de la communauté GlassFish
• Support et services pour Sun Java System Application Server
• Support pour Sun Java System Application Server 9.1
• Java EE Learning Path — catalogue des cours de formation
• Assistance développeur expert Sun
• Formation et certification Java — développement professionnel pour renforcer vos compétences
• Support Développeur — conseils de programmation en ligne basés sur les incidents, assistance produit par téléphone, cours de formation développeur, programmes de service