jboss clustering et tuning (lab 2/3)
DESCRIPTION
- Définition d’une architecture à haute disponibilité- Mise en cluster de deux serveurs Red Hat via RHCS- Installation de JBoss EAP- Hébergement de services et création des failoverdomains- Configuration du load balanceur- Configuration de JBoss Clustring- Déploiement de l’application Hello world- TestTRANSCRIPT
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
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
2. Mise en cluster de deux serveurs Red Hat via RHCS
tux 1 tux 2
Storagetux0
Cluster: sharky
172.16.10.1 172.16.10.2
172.16.10.253
s
6
2. Mise en cluster de deux serveurs Red Hat via RHCS
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
2. Mise en cluster de deux serveurs Red Hat via RHCS
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
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
RHCS
Tux 1
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 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
2. Mise en cluster de deux serveurs Red Hat via
RHCS
Tux 1
Instanciation de la configuration du cluster (3/3)
La configuration du gestionnaire de cluster:
Une vue sur le contenu du fichier /etc/cluster/cluster.conf
s
15
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
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
2. Mise en cluster de deux serveurs Red Hat via
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
4. Hébergement de services et création des
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
4. Hébergement de services et création des
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
4. Hébergement de services et création des
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
4. Hébergement de services et création des
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
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
s
25
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)
s
26
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 JBoss/tux2.
s
27
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.
s
28
5. Configuration du load balanceur
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
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 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
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. -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
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 se sont bien reconnus
l’un à autre.
s
32
7. Déploiement de l’application Hello world
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
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.
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
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.
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