JBoss clustering et tuning (lab 2/3)

JBoss Clustering & Tuning

Lab Technique N°2/3Fourat Z.

Senior software [email protected]

2

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

http://tritux.com/services

http://tritux.com/products

s

3

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

7. Déploiement de l’application Hello world

8. Test

s

4

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

s

5


tux 1 tux 2

Storagetux0

Cluster: sharky

172.16.10.1 172.16.10.2

172.16.10.253

s

6


Tux 1

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.

s

7


Tux 1

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.

s

8

2. Mise en cluster de deux serveurs Red Hat via

RHCS

Tux 1

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.

La meilleur façon pour désactiver la gestion de l’ACPI est

niveau de noyau comme décrit ci-dessous.

s

9


RHCS

Tux 1

Configuration du filtrage réseau (Firewall)

Pour simplifier cette

procédure on va se contenter

par la désactivation du firewall

via la commande system-

config-securitylevel ensuite

par la 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.

s

10


RHCS

Tux 1

Configuration du disque iSCSI

installation et démarrage du service iSCSI.

Nous demandons la liste des cibles au serveur de stockage.

Nous nous connectons à la cible iqn.2011-

02.com.tritux:tuxnas.target1.de18e9

Retourne:

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

« Successful ».

s

11


RHCS

Tux 1

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]

[Etape 2]

Vérification de la création dudisque

s

12


RHCS

Tux 1

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 .

La configuration générale du cluster:

1. pour le nom du cluster nous mettons 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.

s

13


RHCS

Tux 1


La configuration du gestionnaire de cluster:

3. Pour ce qui reste pour la configuration : la définition des membres 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 cluster.conf.VER1 , qui doit remplacer votre ancien fichier « /etc/cluster/cluster.conf »

s

14


RHCS

Tux 1


La configuration du gestionnaire de cluster:

Une vue sur le contenu du fichier /etc/cluster/cluster.conf

s

15


RHCS

Tux 1

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 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 »

s

16


RHCS

Tux 1

Démarrage du cluster (2/2)

La commande clustat renvoie des informations sur les services hébergés par le cluster.

s

17


RHCS

Tux 1

Installation du service httpd

Dans notre cas le serveur httpd sera utilisé pour le load

balancing pour les deux serveur JBoss.

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.

s

18

3. Installation de JBoss EAP

Tux 1

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

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.

s

19

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

failoverdomains

Tux 1

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 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.

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 »

s

20


failoverdomains

Tux 1

Une vue sur la nouvelle section failoverdomains.

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. »

s

21


failoverdomains

Tux 1

Après quelques secondes, vous pouvez vérifier que le service est connu du cluster via la commande « clustat ».

Vous constatez que le service n’est pa démarrer ?

s

22


failoverdomains

Tux 1

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

Nous pouvons vérifier que le service est bien démarré via clustat.

s

23


failoverdomains

Tux 1

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:

s

24


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

s

25


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)

s

26


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 JBoss/tux2.

s

27


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.

http://172.16.10.10/jkstatus

s

28


tux 1

Storagetux0

Cluster: sharky

172.16.10.1 172.16.10.2

172.16.10.253

172.16.10.10 (IP flottanate)

tux 2

(AJP) 80098080

(AJP) 80098080

s

29


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 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)

s

30


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. -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.

s

31


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 se sont bien reconnus

l’un à autre.

s

32


Modification de l’application pour supporter le Mode

Cluster1. 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:

s

33


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.

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.

s

34


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.

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.

s

35

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

36

8. Test

tux 1

Storagetux0

Cluster: sharky

172.16.10.1 172.16.10.2

172.16.10.253

172.16.10.10 (IP flottanate)

tux 2

(AJP) 80098080

[email protected] Rue du Niger, Mont Plaisir / TunisCentre Hanene, 4é étage

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

JBoss clustering et tuning (lab 2/3)

Documents

Transcript of JBoss clustering et tuning (lab 2/3)