JBoss Clustering & Tuning

Fourat Z.
°2/3
Senior software architect
Lab Technique N fourat.zouari@tritux.com
 Qui sommes nous?

TRITUX S.A.R.L. est une SSII Tunisienne, créée en 2006

• Une équipe jeune (30 ingénieurs) orientée nouvelles technologies

• Prestations de pointe en Administration système Linux, clustering et haute

disponibilité, solutions VAS (telecom), mobile banking, SMS et SOA.
(c.f. http://tritux.com/services )

• Editeur de plusieurs logiciels dans divers domaines I.T.

(c.f. http://tritux.com/products )

• Mise en place d’architectures « enterprise », ex: Clusters, Firmes de données,

SOA (ESB), EAI

2
Plan
1. Définition d’une architecture à haute disponibilité
2. Mise en cluster de deux serveurs Red Hat via RHCS
3. Installation de JBoss EAP
4. Hébergement de services et création des failoverdomains
5. Configuration du load balanceur
6. Configuration de JBoss Clustring
s
7. Déploiement de l’application Hello world
8. Test

3
1. Définition d’une architecture à haute disponibilité

Problématique:
Dans une production informatique, certains services sont
particulièrement critiques.
Donc comment faire pour assurer la haute
disponibilité ce ces services ?

Solution:
Pour assurer la disponibilité de ces services, nous avons à notre
disposition les technologies de cluster de Red Hat: RHCS «  Red Hat
Cluster Suite » et JBoss Clustering

4
2. Mise en cluster de deux serveurs Red Hat via RHCS

172.16.10.1 172.16.10.2

Cluster: sharky

tux 1 tux 2

s
Storage
tux0

172.16.10.253

5
2. Mise en cluster de deux serveurs Red Hat via RHCS

Configuration de NTP:

Pour assurer la synchronisation entre les différents nœuds,

nous devons configurer le service NTP par l’édition du fichier
/etc/ntp.conf pour que tout les nœuds soient à la même heure.
Tux 1

6
2. Mise en cluster de deux serveurs Red Hat via RHCS

Mise ne places des gestionnaires de cluster

Red Hat fournit déjà des packages de gestion de cluster: les

packages à installer sont: openais, cman et rgmanager.

Tux 1

7
2. Mise en cluster de deux serveurs Red Hat via RHCS

Désactivation de l’ACPI

Il faut savoir que l’interruption logicielle des signaux ACPI peut

empêcher le fencing de fonctionner et donc entraîne un état instable
du cluster.
Tux 1
La meilleur façon pour désactiver la gestion de l’ACPI est niveau de
noyau comme décrit ci-dessous.
s

8
2. Mise en cluster de deux serveurs Red Hat via RHCS

Configuration du filtrage réseau (Firewall)

Pour simplifier cette procédure

on va se contenter par la

Tux 1 désactivation du firewall via la

commande system-config-
securitylevel ensuite par la
s
modification de la valeur de l’option
Security Level pour qu’elle prend
Disabled et la même chose pour
l’option SELinux elle doit êtres aussi
Disabled ,ensuite appuyiez sur OK.

9
2. Mise en cluster de deux serveurs Red Hat via RHCS

Configuration du disque iSCSI

installation et démarrage du service iSCSI.

Tux 1

Nous demandons la liste des cibles au serveur

s de stockage.

Retourne:

Nous nous connectons à la cible iqn.2011-02.com.tritux:tuxnas.target1.de18e9

Si tout a été bien passé vous devez avoir à la fin du message le mot « Successful ».

10
2. Mise en cluster de deux serveurs Red Hat via RHCS

Configuration du disque de quorum

Le périphérique utilisé comme disque de quorum est
/dev/sdb. Nous créons la structure du disque de quorum par la
commande suivante : [Etape 1]
Tux 1

[Etape 2]

Vérification de la création du
disque

11
2. Mise en cluster de deux serveurs Red Hat via RHCS

Instanciation de la configuration du cluster (1/3)

La configuration du cluster se fait par l’intermédiaire d’un seul

et unique fichier : /etc/cluster/cluster.conf .

Tux 1

 La configuration générale du cluster:

1. pour le nom du cluster nous mettons s

sharky.

2. La version config_version est une valeur

représentant le sérial de la configuration .
Elle doit être obligatoirement modifiée pour
que les autres nœuds la voient et soient
mis à jours à la même version du fichier de
configuration.

12
2. Mise en cluster de deux serveurs Red Hat via RHCS

Instanciation de la configuration du cluster (2/3)

 La configuration du gestionnaire de cluster:

3. Pour ce qui reste pour la configuration : la définition des membres

Tux 1 du cluster ici: tux1 et tux2 via clusternode.

Le contenu final de ce fichier de configuration est présent

sur le répertoire outils du CD LAB2 sous le nom
s
cluster.conf.VER1 , qui doit remplacer votre ancien fichier
« /etc/cluster/cluster.conf »

13
2. Mise en cluster de deux serveurs Red Hat via RHCS

Instanciation de la configuration du cluster (3/3)

 La configuration du gestionnaire de cluster:

Tux 1

Une vue sur le contenu du

fichier s
/etc/cluster/cluster.conf

14
2. Mise en cluster de deux serveurs Red Hat via RHCS

Démarrage du cluster (1/2)

Il nous reste plus qu’a démarrer les services et les configurés pour qu’ils
démarrent au boot.
Le premier services à démarrer est qdiskd, afin que le disque quorum soit
visible aux nœuds du cluster. Chaque service doit être démarrer sur tos les
Tux 1 nœuds du cluster avant de démarrer le suivant. On constate un service
supplémentaire qui s’appelle rgmanager qui gère les ressources hébergés par
le cluster.

La vérification de l’état du cluster peut être réalisée via la commande « cman_tool status »

15
2. Mise en cluster de deux serveurs Red Hat via RHCS

Démarrage du cluster (2/2)

La commande clustat renvoie des informations sur les services hébergés

par le cluster.
Tux 1

16
2. Mise en cluster de deux serveurs Red Hat via RHCS

Installation du service httpd

Dans notre cas le serveur httpd sera utilisé pour le load balancing pour
les deux serveur JBoss.
Tux 1 Ce sujet sera bien détaillé ultérieurement.

Remarque: Vérifier bien que le servie httpd ne soit pas lancé par le
processus init au démarrage du système, on faite c’est le cluster qui doit
approprié ce dernier et gérer son démarrage et son arrêt.

17
3. Installation de JBoss EAP

Pour l’installation de JBoss EAP cette fois il doit être présent sur chacun
des membres du cluster (tux1 et tux2) et j’usqu’au présent il n’ya rien de
spécial concernant son installation il suffit donc de suivre les mêmes étapes
Tux 1 d’installation du LAB précédent.

Il existe juste une petite différence concernant le script de démarrage

/etc/init.d/jboss_eap, car cet fois il prends s
en charge le mode cluster. Et chaque nœuds possèdent ses propres paramètres donc on aura
besoin de deux scripts de démarrage différents, un pour tux1 et l’autre pour tux2.

Copier chacun de ces deux scripts sur le nœuds correspondant, les deux scripts sont déjà
présents sur le support CD du LAB2: sous les répertoires JBoss/tux1 et JBoss/tux2.

18
4. Hébergement de services et création des failoverdomains

Lorsqu’un serveur du cluster défaille, il faut que les services qu’il hébergeait
soient relancés sur l’autre serveur. Dans cette partie on va se concentrer à la
reconfiguration du fichier /etc/cluster/cluster.conf et plus précisément
Tux 1 définir la section appelée <failoverdomains/>.
Cette section définit les services critiques, sur quel nœud ils doivent démarrer
au début, les priorités des nœuds… etc.
s

Le contenu final de ce fichier de configuration est présent sur le

répertoire outils du CD LAB2 sous le nom cluster.conf.VER2 , qui doit
remplacer votre ancien fichier « /etc/cluster/cluster.conf »

19
4. Hébergement de services et création des failoverdomains

Une vue sur la nouvelle section failoverdomains.

Tux 1

Pour mettre à jour ces modifications il faut tout d’abord incrémenter le champ config_version
ensuite lancer la commande « css_rool update /etc/cluster/cluster.conf. »

20
4. Hébergement de services et création des failoverdomains

Après quelques secondes, vous pouvez vérifier que le service est

connu du cluster via la commande « clustat ».
Tux 1
Vous constatez que le service n’est pa démarrer ?

21
4. Hébergement de services et création des failoverdomains

Pour démarrer le service httpd tapez la commande suivante :

Tux 1

Nous pouvons vérifier que le service est bien

s démarré via clustat.

22
4. Hébergement de services et création des failoverdomains

Migration du service

Pour finir avec cette partie, nous allons déplacer le service sur un
l’autre nœud du cluster (tux2) via ces commandes:
Tux 1

23
5. Configuration du load balanceur

Ajout de fichier /etc/httpd/workers.conf

Ce fichier est déjà présent sur ce CD support sous le répertoire httpd. Ce

dernier sert à décrire le mapping de requêtes http depuis httpd vers les
destinations :les deux membres JBoss EAP

24
5. Configuration du load balanceur

Configuration de load balancing: mod_jk

Ajouter ce code dans le fichier /etc/httpd/httpd.conf
(ce fichier au contenu finalisé est disponible dans le CD support sous le réperoire
httpd)

25
5. Configuration du load balanceur

Configuration de JBoss EAP

Sur les deux membres du cluster tux1 et tux2 éditer le fichier
$JBOSS_HOME/server/all/deploy/jbossweb.sar/server.xml en
ajoutant l’attribut jvmRoute dans l’entrée Engine qui prendra la valeur
correspondante aux membre comme le montre la figure de ci-dessous: (ici il
s’agit de server.xml du hôte tux1). Ces fichiers sont déjà présent au
contenu finalisé dans le CD de support sous les répertoires JBoss/tux1 et
s
JBoss/tux2.

26
5. Configuration du load balanceur

Test
Après avoir redémarrer le service httpd entrer l’adresse
http://172.16.10.10/jkstatus dans votre browser et vous allez normalement
constater que le load balanceur fonctionne correctement.

27
5. Configuration du load balanceur
172.16.10.10 (IP flottanate)

172.16.10.1 172.16.10.2
(AJP) 8009 (AJP) 8009
8080 8080
Cluster: sharky

tux 1 tux 2
s

Storage
tux0

172.16.10.253

28
6. Configuration de JBoss Clustring

Démarrage du cluster JBoss

Il n’est pas plus simple pour démarrer JBoss EAP en mode cluster, il suffit juste
d’ajouter quelques paramètres au script run.sh

Pour tux1:

-c all (all est profil dont le Clustring est out-of-the-box)

-g eapcluster(le nom du cluster : c’est au choix bien sur est doit être le même)
-u 239.255.100.100 c’est une adresse par la quelle JBoss se synchronise avec l’autre
membre du cluster en utilisant le mode non s connecté (udp) : elle doit être la même pour
l’autre membre.
-b 172.16.10.1 : pour autoriser touts connexions extérieurs envers lui à travers cette
adresse.
-D jboss.messaging.ServerPeerID=1 c’est l’identifiant du membre (ici: on choisit la
valeur 1)

29
6. Configuration de JBoss Clustring

Démarrage du cluster JBoss

Pour tux2:

-c all (all est profil dont le Clustring est out-of-the-box)

-g eapcluster(le nom du cluster : c’est au choix bien sur est doit être le même)
-u 239.255.100.100 c’est une adresse par la quelle JBoss se synchronise avec l’autre
membre du cluster en utilisant le mode non connecté (udp) : elle doit être la même pour
l’autre membre.
-b 172.16.10.2 : pour autoriser toutes connexions extérieurs envers lui à travers cette
adresse. s
-D jboss.messaging.ServerPeerID=2 c’est l’identifiant du membre (ici: on choisit la
valeur 2 et doit être différent de 1)

Il est noté que ces deux scripts ont étés expliqués juste pour comprendre ce qui est
derrière les nouveaux scripts de démarrage /etct/init.d/jboss_eap que vous venez de
copier. Donc pour déramer le serveur JBoss EAP en mode cluster il suffit de saisir
services jboss_eap start sur chacun des membres du cluster.

30
6. Configuration de JBoss Clustring

Vérification du cluster JBoss

Pour vérifier que les deux membres se sont bien reconnus l’un à l’autre vous devriez
consulter le contenue du server.log et avoir des messages comme le montre la figure de
ci-dessous.

Cet exemple concerne le log du serveur JBoss EAP de (tux1) vous notez bien
d’après son contenu que les deux serveurs sessont bien reconnus l’un à autre.
7. Déploiement de l’application Hello world

Modification de l’application pour supporter le Mode Cluster

1. Editer le fichier web.xml sous le répertoire /WEB-INF et ajouter la ligne

<distributable/> comme premier fis de <web-app id=…> : voir cette figure:

2. Editer le fichier components.xml sous le répertoire /WEB-INF et ajouter la

l’attribut distributable="true" dans l’entrée <core:init …> : comme le montre cette
figure:
7. Déploiement de l’application Hello world

En mode cluster le déploiement est un peu différent:

le déploiement n’est plus sur le répertoire $JBOSS_HOME/server/all/deploy mais plus
tôt sur $JBOSS_HOME/server/all/farm. C’est via cet emplacement que le serveur va
identifier qu’il s’agit d’un déploiement en mode cluster, donc logiquement ce qui a été
déployé dans cet répertoire doit automatiquement être sur celui de l’autre membre. Vous
allez notez ça en suivant les procédures ci-après.

s
Identifiez les deux fichiers helloworld-ds.xml et helloworld.war depuis le
répertoire Application du CD support de la formation puis vous les copiés sous le répertoire
$JBOSS_HOME/server/all/farm de tux1. Après quelques secondes vérifiez le contenu
du même répertoire de tux2 et vous allez remarquer que l’application  « hello wolrd » a
été de même déployée sur tux2.
7. Déploiement de l’application Hello world

En mode cluster le déploiement est un peu différent:

le déploiement n’est plus sur le répertoire $JBOSS_HOME/server/all/deploy mais plus
tôt sur $JBOSS_HOME/server/all/farm. C’est via cet emplacement que le serveur va
identifier qu’il s’agit d’un déploiement en mode cluster, donc logiquement ce qui a été
déployé dans cet répertoire doit automatiquement être sur celui de l’autre membre. Vous
allez notez ça en suivant les procédures ci-après.

s
Identifiez les deux fichiers helloworld-ds.xml et helloworld.war depuis le
répertoire Application du CD support de la formation puis vous les copiés sous le répertoire
$JBOSS_HOME/server/all/farm de tux1. Après quelques secondes vérifiez le contenu
du même répertoire de tux2 et vous allez remarquer que l’application  « hello wolrd » a
été de même déployée sur tux2.
8. Test

Vous notez bien que maintenant on peux accéder à notre application via l’adresse IP
flottante 172.16.10.10 et le port 80.
Donc pour conclure: le load balancer se charge de d’éguillage à un serveur Jboss soit de
tux1 ou de tux2 est si jamais le serveur JBoss de tux1 crashe, le second prend
systématiquement sa place. Tout ce mécanisme se déroule d’une façon transparent e à
l’utilisateur sans qu’il le constate.

s
8. Test
172.16.10.10 (IP flottanate)

172.16.10.1 172.16.10.2
(AJP) 8009
8080
Cluster: sharky

tux 1 tux 2
s

Storage
tux0

172.16.10.253

36
 more …
http://tritux.com/products/
http://tritux.com/services/
http://tritux.com/blog/1

9 Rue du Niger, Mont Plaisir / Tunis

info@tritux.com Centre Hanene, 4é étage