JEE6 – Glassfish 3.1, Clustering & Failover

En Java EE, on parle souvent de clustering de serveurs d’application pour évoquer la mise en relation d’un certain nombre de serveurs.

On parle également de failover pour parler de la capacité à rendre l’indisponibilité d’un ou de plusieurs serveurs du cluster complètement transparente vis à vis du client; cela se traduit par le fait de garantir au client la reprise du même contexte d’exécution qui existait en amont de l’apparition de la panne du serveur incriminé.

Glassfish V3, l’implémentation de référence de JEE6 (JSR 316), inclut à partir de sa version 3.1 des nouvelles fonctionnalités de clustering (synchronisation lors du démarrage d’une nouvelle instance, réplication des changements dynamiques de configuration,…), et offre également un mécanisme de réplication de la session http et des EJB statefull.

Au cours de cet article nous aborderons la mise en place d’un cluster glassfish, la configuration Apache avec le plugin Glassfish Load Balancer et le test du failover à travers une application web.

Il faut noter que toutes les étapes d’installation et de configuration peuvent être réalisées en mode console ou en mode GUI (à travers la console d’administration Glassfish). L’approche console (ligne de commande) a été adoptée.

Outils & téléchargements

Architecture cible

L’architecture présentée dans la figure ci-dessous fait apparaître les composants suivants:

  • Un cluster Glassfish de deux instances pilotées par le DAS (Domain Administration Server) et tournant sur un «MacOS».
  • Un serveur HTTP (Apache) intégrant un load balancer de type Glassfish Load Balancer et tournant sur une machine virtuelle «CentOS» dans un environnement virtualisé «VirtualBox».

La réplication de session: Principe de fonctionnement

La réplication de la session est assurée par un module OSGI, chargé uniquement lorsque la haute disponibilité est activée au niveau des applications déployées.

Le module de réplication permet de distribuer uniformément les états de la session sur les serveurs abonnés au cluster.

Il utilise GMS (Group Management Service) qui est également un module OSGI responsable des notifications concernant les instances joignant ou quittant le cluster; ces évènements, une fois consommés par le module de réplication, lui permettront de choisir l’instance la plus appropriée pour répliquer la session.

Il est utilisé par le conteneur web pour la réplication de la session HTTP et par le conteneur EJB pour la réplication des SFSB.

Load Balancing: Failover avec Apache & Glassfish LB Plugin

  • Instance1 OK:

La requête «Request1» émise par un utilisateur «Utilisateur1» arrive au niveau du LB qui la route vers l’instance «Instance1»

La session «Session1» ainsi créée, peut être répliquée par le module de réplication sur l’instance «Instance4».

La requête «Request2» peut être également routée vers l’instance «Instance1» par le LB. Le module de réplication répliquera la session «Session2» sur une autre instance dans la mesure du possible (dans le cas où l’on dispose de plus de deux instances dans le cluter), «Intance2» par exemple.

  • Le module de réplication ne réplique pas l’ensemble des sessions d’une instance donnée sur une même autre instance, il essayera de les répartir sur l’ensemble des instances du cluster.
  • La session est répliquée sur une seule instance et non pas sur la totalité des instances du cluster.
  • Instance1 KO:

Dans le cas où l’instance «Instance1» n’est plus accessible, Glassfish LB plugin routera la requête «Request1» vers l’instance «Instance4» vu qu’elle contient les données répliquées de la session «Session1» qui sera nouvellement répliquée sur une autre instance, en l’occurrence sur l’instance «Instance3». De même, la requête «Request2» sera routée vers l’instance «Instance2» et la session «Session2» sera répliquée sur l’instance «Instance4».

Load Balancing: Failover avec Apache LB & mod_jk

La politique de load balancing avec le load balancer Apache est différente de celle du load balancer Glassfish et elle est moins optimisée et moins performante. En effet le load balancer ne dispose pas des informations nécessaires pour router la requête vers une instance qui possède déjà la session répliquée.

Si le load balancer Apache route la requête «Request1» vers l’instance «Instance3», un «pull» de la session «Session1» à partir de l’instance «Instance4» est donc nécessaire.

Création du cluster

Le cluster est composé de deux instances sur un même nœud (un nœud est une représentation logique d’un host). Pour ce faire déroulez la suite des commandes suivantes:

  • Démarrer le serveur d’administration:
    asadmin start-domain
    
  • Activer le mode SSL pour sécuriser la connexion entre les instances du cluster et le DAS (Domain Application Server):
    asadmin enable-secure-admin
    
  • Redémarrage du DAS pour prise en compte du mode SSL:
    asadmin restart-domain
    
  • Création du cluster «cluster1»:
    asadmin create-cluster cluster1
    
  • Afficher la liste nœuds:
    asadmin list-nodes
    
  • Créer «instance1» sur le noeud «localhost-domain1» dans le «cluster1»:
    asadmin create-instance --node localhost-domain1 --cluster cluster1 instance1
    
  • Créer «instance2» sur le noeud «localhost-domain1» dans le «cluster1»:
    asadmin create-instance --node localhost-domain1 --cluster cluster1 instance2
    
  • Vérifier la création du «cluster1»:
    asadmin list-clusters
    
  • Démarrer le «cluster1»:
    asadmin start-cluster cluster1
    

Déploiement de l’application clusterjsp

Il s’agit de déployer l’application clusterjsp.war sur le cluster «cluster1» précédemment créé en activant la haute disponibilité:

asadmin deploy --target cluster1 --availabilityenabled=true clusterjsp.ear

Il faut savoir que les applications de type «Servlet API Based Web Application» ne sont pas «clusterisables» par défaut. Pour qu’une application puisse être déployée sur un cluster, il faut qu’elle déclare un tag spécifique dans le web.xml: <distributable /> (Official Web App DTD 2.2). Ce tag fut intégré dans l’API Servlet à partir de sa version 2.2 (version introduite dans J2EE 1.2).

Test du failover sans load balancing:

  • Ajouter des variables de session à l’aide du formulaire suivant:

Préparation de la VM: CentOS 32 bits (Apache & Glassfish LB plugin)

Installation Apache en mode SSL: http://wiki.centos.org/HowTos/Https

  • Le SSL est nécessaire pour pouvoir utiliser l’option de déploiement automatique de la configuration LB à partir du DAS vers la machine sur laquelle est installé le Glassfish LB plugin.

Installation du Glassfish LB plugin

  • Lancer l’installation du plugin avec la commande suivante:
    java -jar glassfish-lbconfigurator-3_1.jar
    

  • Choisir «Apache serveur» et compléter la suite des instructions.
  • Le plugin n’est compatible qu’avec une version apache 2.2.x. La vérification la version d’apache installée est donc faite avant le lancement de l’installation en essayant d’exécuter la commande suivante:
    $APACHE_HOME/bin/apachectl
    
  • Si ce script n’existe pas à l’emplacement recherché par le plugin, la solution la plus simple consiste à en créer un avec les droits d’exécution (chmod 755 apachectl) qui pourrait contenir les lignes suivantes:

    $APACHE_HOME/bin/apachectl

    #!/bin/bash
    /usr/sbin/apachectl -v
    

Assurez-vous également d’avoir les fichiers «httpd-ssl.conf» et «httpd-vhosts.conf» sous le répertoire «$APACHE_HOME/conf/extra» qui seront enrichis par la configuration SSL nécessaire au LB.

Une fois l’installation terminée, vous devez les déplacer dans le répertoire «$APACHE_HOME/conf.d» de manière à ce qu’ils soient inclus dans le fichier de configuration principale «httpd.conf» par le biais de la directive <Include> qui existe déjà (Include conf.d/*.conf), ou éventuellement, rajouter le <Include> qui va bien.

  • Exporter le certificat de glassfish:

    L’upload de la configuration LB est réalisé en Https. Il est donc nécessaire d’exporter le certificat de Glassfish et de l’intégrer au niveau de la configuration Apache SSL du LB.

    Sur la machine du serveur Glassfish, exécutez le script suivant:

    export_certificate.sh

    keytool \
    -export \
    -rfc \
    -alias s1as \
    -keystore $GLASSFISH_HOME/glassfish/domains/domain1/config/keystore.jks \
    -file ./glassfish.crt \
    -storepass changeit
    
  • Copier le certificat sur la machine du LB:
    scp glassfish.crt root@glassfishlb:/etc/httpd/conf/ssl.crt/
    
  • Récupérer le subject et le serial number du certificat avec la commande suivante:
    keytool -printcert -file glassfish.crt
    

Les valeurs concernant l’organisation (O), l’unité d’organisation (OU) et le serial number seront utilisées par la suite pour compléter la configuration SSL du LB. Le serial number devrait être saisi en majuscule.

  • Renseigner les informations liées au certificat dans le fichier «httpd-ssl.conf»
    
      SSLVerifyClient require
      SSLVerifyDepth 1
      SSLRequireSSL
      SSLCACertificateFile /etc/httpd/conf/ssl.crt/glassfish.crt
      SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
       and %{SSL_CLIENT_S_DN_O} eq "Oracle Corporation" \
       and %{SSL_CLIENT_S_DN_OU} eq "GlassFish" \
       and %{SSL_CLIENT_M_SERIAL} eq "4D5A2F07" )
    
    
      SSLVerifyClient require
      SSLVerifyDepth 1
      SSLRequireSSL
      SSLCACertificateFile /etc/httpd/conf/ssl.crt/glassfish.crt
      SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
       and %{SSL_CLIENT_S_DN_O} eq "Oracle Corporation" \
       and %{SSL_CLIENT_S_DN_OU} eq "GlassFish" \
       and %{SSL_CLIENT_M_SERIAL} eq "4D5A2F07" )
    
    ##END GlassFish Load-Balancer Plugin Configuration
    
  • Apache aura du mal à redémarrer et principalement à cause de l’absence des librairies nécessaires au module «mod_loadbalancer.so» dans le path et/ou sur le disque:
httpd: Syntax error on line 1011 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_loadbalancer.so into server: libicuuc.so.2: cannot open shared object file: No such file or directory
  • Assurez-vous de la disponibilité de toutes les dépendances du module «mod_loadbalancer.so» et ajoutez la variable d’environnement «LD_LIBRARY_PATH» dans le fichier «/etc/init.d/httpd»
    					export LD_LIBRARY_PATH=/etc/httpd/glassfish-lbplugin/lib/
    					
  • Vous pouvez également déclarer cette variable d’environnement au niveau du fichier «$APACHE_HOME/bin/envvars» s’il est bien chargé au niveau du démarrage du demon httpd.
  • Vous pouvez également anticiper le problème lié au listener https lors de la communication ssl entre le serveur glassfish et le LB qui se manifeste par le warning ci-dessous dans les logs apache:
[warn] lb.healthchecker: HLCK3003: Listener: [http://192.168.1.16:24849] is detected to be still unHealthy in cluster: cluster1
  • Rajoutez également ces lignes pour permettre le NSS (Network Security Services) forking.
    					export NSS_STRICT_NOFORK=DISABLED
    					

Création du LB et déploiement de la configuration à partir du DAS

  • Créer le LB
    asadmin create-http-lb --devicehost glassfishlb --deviceport 443 --target cluster1 cluster_lb
    
  • Déployer le configuration sur la VM de Glassfish LB plugin:
    asadmin apply-http-lb-changes cluster_lb
    
  • Dans le cas où vous êtes confrontés à des problèmes de certificat SSL lors du déploiement du fichier de configuration LB vous pouvez toujours l’exporter et remplacer le contenu du fichier $APACHE_HOME/conf/loadbalancer.xml.
  • Exporter le fichier de configuration
    asadmin export-http-lb-config --lbname cluster_lb
    

$GLASSFISH_HOME/glassfish/domains/domain1/load-balancer/loadbalancer.xml.cluster_lb_LB_CONFIG

<!--?xml version="1.0" encoding="UTF-8"?-->
<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN" "glassfish-loadbalancer_1_3.dtd">
<loadbalancer>
  <cluster name="cluster1" policy="round-robin">
    <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://$HOSTNAME:28080 https://$HOSTNAME:28181 http://$HOSTNAME:24848" name="instance1" weight="100"/>
    <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://$HOSTNAME:28081 https://$HOSTNAME:28182 http://$HOSTNAME:24849" name="instance2" weight="100"/>
    <web-module context-root="/clusterjsp" disable-timeout-in-minutes="30" enabled="true"/>
    <health-checker interval-in-seconds="10" timeout-in-seconds="30" url="/"/>
  </cluster>
  <property name="response-timeout-in-seconds" value="60"/>
  <property name="reload-poll-interval-in-seconds" value="60"/>
  <property name="https-routing" value="false"/>
  <property name="preferred-failover-instance" value="true"/>
  <property name="require-monitor-data" value="false"/>
  <property name="rewrite-location" value="true"/>
  <property name="number-healthcheck-retries" value="3"/>
  <property name="active-healthcheck-enabled" value="false"/>
  <property name="rewrite-cookies" value="false"/>
</loadbalancer>

Test du failover avec load balancing:

  • Arrêter «instance1»:
    asadmin stop-instance instance1
    

Conclusion

Au cours de cet article nous avons pu voir la mise en place d’un cluster d’instances vivants dans un même nœud. Il faut savoir qu’il est également possible de faire cohabiter dans un même cluster, des instances créées sur des nœuds différents. La gestion centralisée des nœuds au niveau du DAS est assurée par accès en SSH aux différentes machines; elle remplace la notion de «node-agent» dans Glassfish V2.

Si vous êtes dans ce cas d’utilisation, les principales commandes à utiliser pour la création des nœuds et des instances du cluster seraient les suivantes:

  • Configurer SSH
    asadmin setup-ssh ${node-host}
    
  • Installer le serveur glassfish sur la machine distante:
    asadmin install-node --installdir ${install-dir} ${node-host}
    

    Cette commande effectuera une copie du zip d’installation du serveur glassfish sur la machine distante; ce qui permettra d’exécuter par la suite les commandes «asadmin» à distance.

  • Créer le noeud
    asadmin create-node-ssh --installdir ${install-dir} --node ${node-host} ${node-name}
    
  • Désormais, les opérations de création d’instances sont possibles. Il suffit de spécifier le cluster et le target node
    asadmin create-instance –cluster ${cluster-name} --node ${node-name} ${instance-name}
    

26 commentaires

  • Merci pour cet article détaillé!
    La dernière version stable de GlassFish est la 3.1.1 – http://glassfish.java.net/downloads/3.1.1-final.html

  • Merci de m’avoir éclairé sur le clustering avec la référence Glassfish.

  • « Java EE », not « JEE ».

  • Quel gain de temps ! Merci, vraiment !

  • Salut à vous,
    merci pour ce brillant article
    juste un petit pépin d’ordre technique : le fichier de test « clusterjsp.zip » n’est plus accessible en téléchargement
    est ce possible de réactiver le lien ? ou de me l’envoyer par mail
    merci

  • Salut Thomas,

    Effectivement le lien n’est plus accessible.
    L’application de test « clusterjsp.ear » vous a été envoyée par mail.

  • Salut Issam,
    J’espère que tu vas bien.
    je reprends les travaux que j’avais suspendu.
    J’ai une petite question : y a t il un moyen pour installer le glassfish LB sans mode graphique ?
    je ne trouve pas vraiment de solution…
    je suis en SSH sur un debian 6 lui même sur une VMware…et je n’utilise pas de mode graphique…

    Merci d’avance pour ton aide

    A bientôt.

  • Salut Thomas,

    Essaie de l’installer sur n’importe quel environnement linux disposant d’un mode graphique. A la fin de l’installation, sélectionne l’option qui permet de générer le script d’installation. Tu pourrais donc par la suite l’exécuter sur la machine cible.

  • Merci pour ta dispo à cette heure avancée Issam !
    c’est vraiment cool.
    merci pour le truc mais il faut que je trouve une machine linux en environnement graphique… je n’ai pas çà moi ! ;-))

    cependant, quand je me connecte sur mon hyperviseur VMware (ESXi5) avec le client local prévu à cet effet, je peux accèder à mon serveur et à mes machines virtuelles et je peux lancer mon debian en mode graphique.

    je lance un terminal sur cette interface mais ça me sort les mêmes erreurs, c’est curieux.

    Merci beaucoup Issam.

  • Hello Issam
    je suis enfin parvenu via VmWare et ma machine virtuelle à lancer un mode graphique et donc à lancer le jar
    pour l’installation du load balancing.
    Je fais face à un nouveau petit pb.
    à l’install on a un mandatory field pour le webserver install dir : je mets /etc/apache2
    je ne mets rien pour l’info DAS qui n’est pas obligatoire.
    l’installation commence et arrive à ce stade avec ces messages :
    INFO : started installation of GF load balancer plugin
    WARNING : commande /etc/apache2/bin/apachectl execution failed … (normal apachectl est dans /usr/sbin/ )
    SEVERE : GF load balancer plugin failed. unable to get web server version … must be 2.2.x

    je peux modifier cela après en laissant ces erreurs à l’install …à priori non puisque c’est failed

    Merci pour ta précieuse aide

  • Hello,
    ce point a été évoqué au niveau du paragraphe « Installation du Glassfish LB plugin » qui présente également la solution au problème.

  • Hello Issam
    Mince, je comprends pourquoi je n’ai pas eu de réponse de toi, je vois que mon post d’avant hier n’est pas passé. ;-(
    Je recommence..
    —-
    Tu as complètement raison quant à ta remarque, et désolé pour cette question stupide.
    Bon, je suis allé jusqu’au bout du tuto en pensant avoir les choses plutôt correctement, mais çà ne fonctionne pas encore pour moi avec le load balancing via ma VM…
    Je ne lâche pas l’affaire..;-)
    Première question (un peu stupide) mais bon :
    lorsque l’on export le fichier à la main (si le SSL ne fonctionne pas correctement)
    on obtient bien ce fichier :

    $GLASSFISH_HOME/glassfish/domains/domain1/load-balancer/loadbalancer.xml.cluster_lb_LB_CONFIG

    Cependant tu écris que tu copies ça dans : $APACHE_HOME/conf/loadbalancer.xml.

    donc ma question bête: on copie dans un fchier appelé « loadbalancer.xml » ou plutôt « loadbalancer.xml.cluster_lb_LB_CONFIG »

  • suite :
    question 2 : très importante :
    tu écris :
     » Assurez-vous également d’avoir les fichiers «httpd-ssl.conf» et «httpd-vhosts.conf» sous le répertoire «$APACHE_HOME/conf/extra» qui seront enrichis par la configuration SSL nécessaire au LB. »

    En fait, apache 2.2.16 ne semble pas réellement fonctionner de base avec ces fichiers.
    j’ai apporté les modifications décrites dans ces fichiers httpd-ssl.conf et httpd-vhosts.conf dans les fichiers
    /etc/apache2/sites-available/default et default-ssl

    Apache semble fonctionner avec ces fichiers et j’ai eu des mess de « redondance » lorsque j’ai voulu utiliser ceux que tu décris.

    Suis je dans l’erreur à ton avis Chef ?

  • Salut Issam,
    Excuse moi pour toutes ces questions mais elles sont importantes pour finaliser mes installations.
    J’ai finalement suivi exactement l’utilisation des fichiers que tu décris.

    Ma question bête subsiste au sujet de loadbalancer.xml » ou plutôt de« loadbalancer.xml.cluster_lb_LB_CONFIG » à placer dans le repertoire /conf de apache

    Une autre remarque importante que j’aurais certainement dû soulever plus tôt est la suivante :
    Je me suis aperçu que ton install est finalement en réseau local 192.168.X.X pour les 2 machines.
    Moi c’est un peu différent :
    – j’ai un premier serveur Debian (non virtuel) en 88.190.X.Y où est installée Glassfish 3.1.2 avec l’appli clustejsp (entre autres)
    – une seconde machine virtuelle cette fois en IP Failover 88.190.A.B (une debian 6 sur un hyperviseur VMWare) ou j’ai mis le LB Apache 2

    Elles sont toutes 2 chez Online (dedibox).

    Dans ce cas de figure puis je toutefois suivre ta procédure pas à pas ?
    ou dois je m’inspirer ce que tu décris à la fin ? ( sauf que mes instances sont bien créées sur le même serveur réel et pas sur des noeuds différents)

    Merci grandement car là je suis bloqué… je n’arrive pas à lancer l’application sur la VM , rien ne passe du tout…

  • Hello,
    Any help for my last post please Issam ?
    thx

  • Hello,
    Un ptit coup de main pour mon dernier post ? ;-)
    thx

  • hello.
    si vous pouviez me filer chti coup de main car je pense que j’approche du but…mais je perds bp de temps … ;-)
    tout semble bien configuré côté Apache SSL sur ma VM ainsi que côté serveur Glassfish sur l’autre serveur.
    voilà les commandes que je lance :

    asadmin create-http-lb –devicehost 88.190.207.33 –deviceport 443 –target cluster1 cluster_lb
    Command create-http-lb executed successfully.
    puis :
    asadmin apply-http-lb-changes cluster_lb
    remote failure: String index out of range: -56String index out of range: -56
    Command apply-http-lb-changes failed.

    exporter la config et la copier dans /etc/apache/conf avec cette commande :
    asadmin export-http-lb-config –lbname cluster_lb
    ne semble rien changer.

    J’ai l’impression que la communication ne se fait pas bien alors que cette commande (depuis le serveyr GFish) semble renvoyer des éléments corrects :

    openssl s_client -connect 88.190.207.33:443
    CONNECTED(00000003)
    depth=1 /C=FR/ST=RPARIS/L=PARIS/O=HW360/OU=HW360/CN=debian605/emailAddress=catty_thomas@yahoo.fr
    verify error:num=19:self signed certificate in certificate chain
    verify return:0

    ….
    Serait ce du à ma config que je décris dans mon post 14 ci dessus ?

    THANKS A LOT IN ADVANCE GUYS.

  • Bonjour Thomas,

    Si je comprends bien la commande « asadmin apply-http-lb-changes cluster_lb » est en echec (remote failure).

    Essaie donc d’extraire le fichier de config LB avec la commande suivante:
    asadmin export-http-lb-config –lbname cluster_lb

    Désormais, tu pourrais récupérer le fichier à l’endroit suivant:
    $GLASSFISH_HOME/glassfish/domains/domain1/load-balancer/loadbalancer.xml.cluster_lb_LB_CONFIG

    et remplacer le contenu du fichier $APACHE_HOME/conf/loadbalancer.xml (sur la machine Apache) par celui du loadbalancer.xml.cluster_lb_LB_CONFIG.

  • salut Issam,

    merci pour ta réponse. j’ai essayé plusieurs fois ce que tu me dis Chef
    puisque tu l’as expliqué dans ton blog là haut. rien n’y fait.

    J’ai refait toute l’install : lors de ‘linstall du loadbalancer j’ai 2 erreurs SEVERE qui sont importantes :
    httpd.conf et envars not found
    alors qu’ils sont bien dans mon répertoire d’install d’apache : /etc/apache2/

    why ? alors qu’ils me trouvent bien les fichiers httpd-ssl et httpd-vhosts dans /conf/extra/

    a devenir fou…

    Merci vraiment pour tes réponses en tous cas;
    bien à toi.

  • Issam,

    si cela fonctionnait, je devrais voir une ligne « http load balancer » dans mon admin glassfish (via le navigateur) , non ?

    Je ne vois pas ce qui peut clocher.
    Il faut que je trouve le pb rapidement désormais.

    Bien à toi

  • coucou,

    même en modifiant ce fichier xml à la main il ne se passe rien du tout
    l’application ne se lance même pas depuis le lb

    le test que tu décris tu l’as fait sur une seule et même machine on est bien d’accord ?
    sur ta machine en dur est installée GFish et dans une VM sur cette même machine un centOS avec un LB c’est bien cela ?

    Moi c’est vrai que c’est un peu différent mais la logique reste la même.
    Déjà je travaille sur un serveur hébergé chez online disant en SSH sur lequel j’ai installé hyperviseur VMWARE. (IP publique fixe : A)
    Au dessus j’ai installé 2 VM, une debian contenant GF 3.1.2 avec l’appli .ear
    Et une autre debian contenant apache 2 / SSL et le LB.
    ma VM glassfish est en IP locale 192.168.1.2 (avec une IP failover : B)
    ma VM LB est en locale 192.168.1.1 (ip failover C=> que je dois utiliser pour lancer le LB à distance depuis un navigateur client)

    voilà ma config.
    si çà peut éclairer pkoi je n’arrive pas à faire comme toi ! ;-)

  • clôture du post : Merci Issam.
    Pour info, j’ai abandonné la config avec Apache 2 et me suis tourné vers Iplanet Web Server 7.
    Apache 2 n’était pas le pb, je l’ai découvert par la suite. ;-)
    Cependant pour ceux que ce la intéresse, ma config étant différente voilà le genre de commande que j’ai du faire notamment pour la création du cluster :
    asadmin –host glassfish –port 4848 –secure create-http-lb –devicehost debian605 –deviceport 8082 –httpsrouting –target cluster1 cluster_lb

    Enfin, le plus imortant est que mon install glassfish était un peu trop secure (changement du masterpassword + de la keystore par défaut), à éviter apparemment en tous cas pour la comm SSL avec LB) et empechait la communication avec le lb

    voilà en qques mots
    j’en oublie certainement. Bref çà marche très bien avec mes clusters et mes VM.
    merci encore

  • Salut Issam,
    J’epsère que tu vas bien.
    une petite question au sujet du tag spécifique dans le web.xml: ?
    quand doit on le mettre précisément ? pourquoi ne pas le mettre dans chaque fichier ?
    j’ai en effet déployé un .war tout simple et çà n’a pas l’air de fonctionner… il est vrai que je l’ai rajouté après le déloiement en direct dans les fichiers du serveur mais bon… ça devrait le faire qd même …

    merci d’avance de ton aide Chef.

  • Coucou Issam,
    Je ne sais pas si tu as un peu de dispo pour lire ces qques lignes. J’ai 3 questions au sujet de tout cela :
    1. il semblerait que lorsqu’on enregistre des variables en session, puis que l’on coupe l’instance en question, la seconde instance retrouve bien ces variables. MAIS j’ai l’impression que si sur cette 2nde instance, j’ajoute de nouvelles variables en session, celles ci ne soient pas maintenues et seules les toutes premières restent. Je voulais m’assurer que le LB fonctionnait correctement en stoppant et redémarrant des instances tout en ajoutant des var de sessions de temps à autre.

    2. Je vais être dans le cas de ta « conclusion » avec des instances sur des noeuds différents. Aurais tu un post encore plus détaillé à ce sujet ?

    3. As tu déjà rencontré des pbs de firewall avec le loadbalancing ? j’ai plusieurs VM sur un même serveur physique pour simuler un foncionnement rééel : l’une fait le LB, un autre contient GF V3 mais quand je lance me règles IPtables le LB d’instante ne se fait plus correctement. J’ai ouvert beaucoup de ports concernés mais rien n’y fait.

    Si tu as des idées sur tout çà, elles sont les bienvenues.
    Merci d’avance Issam.

  • Salut

    Mon problème réside dans le fais que je n’arrive pas a démarrer l’instance distante d’un cluster glassfish sous un os linux (Redhat 6).

    Ma config est la suivante:

    j’ai deux machine das_cluster et cluster_2 (avec une machine pour la base de donnée) avec les paramètres suivants:

    pour la config ssh pour un utilisateur glassfish,je procède comme suite:

    1-la génération des la paire des clés (public id_dsa.pub & privée id_dsa) sur la machine du DAS :
    [user glassfish @ das_cluster] ssh-keygen -t dsa

    2-la publication de la clé public sur les autres instances:
    [user glassfish @ das_cluster] scp ~/.ssh/id_dsa.pub cluster_2:.ssh/authorized_keys

    3-refaire les mêmes opérations au niveau de chacune des instances
    [user glassfish @ cluster_2] ssh-keygen -t dsa
    [user glassfish @ cluster_2] scp ~/.ssh/id_dsa.pub das_cluster:.ssh/authorized_keys

    4-se connecter en multimode apartir du DAS :
    [user glassfish @ das_cluster] asadmin
    asadmin> setup-ssh das_cluster cluster_2

    machine das: das_cluster, node-1,inst-1

    /etc/hosts (das_cluster)

    10.6.2.47 Das_cluster
    127.0.0.1 localhost.localdomain localhost
    ::1 Das_cluster localhost6.localdomain6 localhost6
    10.6.2.60 cluster_2
    10.6.2.49 cluster_bdd

    machine distante:cluster_2, node-2,inst-2

    /etc/hosts (cluster_2)
    127.0.0.1 localhost.localdomain localhost
    ::1 cluster_2.localdomain6 localhost6
    10.6.2.47 Das_cluster
    10.6.2.49 cluster_bdd
    10.6.2.60 cluster_2.localdomain cluster_2

    En fin tous semble marche bien mais a ma surprise quand je tente de démarer les deux instances via le das, inst-1 démarre et inst-2 échoue avec le message de retour suivant:

    inst-2: Could not start instance inst-2 on node 2 (cluster_2). Command failed on node 2 (cluster_2): CLI801 Instance is already synchronized There is a process already using the admin port 24848 — it probably is another instance of a GlassFish server. Command start-local-instance failed. To complete this operation run the following command locally on host cluster_2 from the GlassFish install location /APP/glassfish3: asadmin start-local-instance –node 2 –sync normal inst-2 The command start-instance executed successfully for: inst-1 The command start-instance failed for: inst-2

    Et quand je tente de lancer l’instance en local c’est toujours le même problème, sachant que il n’y a aucun autre processus glassfish qui est lancer sur cette machine et j’ai vérifier ça par les commandes suivantes:

    ps aux | grep glassfish
    netstat -aon | grep 4848
    netstat -atunp | grep 24848
    netstat -ln –program | grep 24848.

    Je vous remercie a l’avance pour l’attention que vous accorderai a ce message et je serai attentif a vos suggestions.

  • Bonjour,

    J’ai crée un cluster avec deux instances sur un même noeud. Je veux voir comment le déploiement des applications est géré sur les différentes instances du cluster.
    J’essaie d’obtenir l’équivalent de la commande  » asadmin list-applications -l nom-cluster » pour les instances mais j’y arrive pas il ne considère comme target que le nom du cluster mais pas les instances alors est ce que quelqu’un pourrait m’aider ?

Laisser un commentaire