Published by Issam El Fatmi

Il y a 11 ans -

Temps de lecture 12 minutes

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

Glassfish 3.1 : http://dlc.sun.com.edgesuite.net/glassfish/3.1/release/glassfish-3.1.zip (en édition Open source sous licence CDDL ou GPLv2, la version commerciale est disponible ici)
clusterjsp.ear : http://blogs.sun.com/arungupta/resource/glassfish/clusterjsp.zip (Application web qui nous permettra d’illustrer le mécanisme de la réplication de session)
Glassfish Load Balancer plugin: http://download.oracle.com/otn-pub/java/ogs/3.1//glassfish-lbconfigurator-3_1.zip

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:

Saisir l’URL suivante: http://localhost:28080/clusterjsp/HaJsp.jsp:

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

Arrêter «instance1»:
```
asadmin stop-instance instance1
```
Accéder à «instance2»: http://localhost:28081/clusterjsp/HaJsp.jsp:

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

Le plugin n’est pas compatible avec tous les OS notamment MacOs et HP-UX (Supported Operating Systems and Web Servers).

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:

Saisir l’URL suivante: http://glassfishlb/clusterjsp/HaJsp.jsp et ajouter quelques variables de session:

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

Rafraichir la page http://glassfishlb/clusterjsp/HaJsp.jsp

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}
```