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

1. JBoss Clustering & Tuning Fourat Z. Lab Technique N°2/3 Senior software architect fourat.zouari@tritux.com

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

4. Editeur de plusieurs logiciels dans divers domaines I.T.(c.f. http://tritux.com/products )

5. Mise en place d’architectures « enterprise », ex: Clusters, Firmes de données, SOA (ESB), EAI2

6. Plan 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 Test s 3

7. Définition d’une architecture à haute disponibilité s 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

8. Mise en cluster de deux serveurs Red Hat viaRHCS s Cluster: sharky 172.16.10.2 172.16.10.1 tux 1 tux 2 Storagetux0 172.16.10.253 5

9. Mise en cluster de deux serveurs Red Hat viaRHCS s 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.confpour que tout les nœuds soient à la même heure. Tux 1 6

10. Mise en cluster de deux serveurs Red Hat via RHCS s 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

11. Mise en cluster de deux serveurs Red Hat via RHCS s 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. Tux 1 8

12. Mise en cluster de deux serveurs Red Hat via RHCS s 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. Tux 1 9

13. Mise en cluster de deux serveurs Red Hat via RHCS s Configuration du disque iSCSI installation et démarrage du service iSCSI. Tux 1 Nous demandons la liste des cibles au serveur 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

14. Mise en cluster de deux serveurs Red Hat via RHCS s 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 dudisque 11

18. Mise en cluster de deux serveurs Red Hat via RHCS s 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. Tux 1 La vérification de l’état du cluster peut être réalisée via la commande « cman_toolstatus » 15

19. Mise en cluster de deux serveurs Red Hat via RHCS s Démarrage du cluster (2/2) La commande clustat renvoie des informations sur les services hébergés par le cluster. Tux 1 16

20. Mise en cluster de deux serveurs Red Hat via RHCS s 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. Tux 1 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

21. Installation de JBoss EAP s 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. Tux 1 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. 18

22. Hébergement de services et création des failoverdomains s 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.confet 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 » Tux 1 19

23. Hébergement de services et création des failoverdomains s 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

24. Hébergement de services et création des failoverdomains s 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 ? Tux 1 21

25. Hébergement de services et création des failoverdomains s Pour démarrer le service httpd tapez la commande suivante : Tux 1 Nous pouvons vérifier que le service est bien démarré via clustat. 22

26. Hébergement de services et création des failoverdomains s 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

27. Configuration du load balanceur s 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

28. Configuration du load balanceur s Configuration de load balancing: mod_jk Ajouterce code dans le fichier /etc/httpd/httpd.conf(cefichier au contenufinaliséestdisponibledans le CD support sous le réperoire httpd) 25

29. Configuration du load balanceur s 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. 26

30. Configuration du load balanceur s 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

31. Configuration du load balanceur 172.16.10.10 (IP flottanate) s Cluster: sharky 172.16.10.2 172.16.10.1 tux 1 tux 2 (AJP) 80098080 (AJP) 80098080 Storagetux0 172.16.10.253 28

32. Configuration de JBoss Clustring s 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) 29

33. Configuration de JBoss Clustring s 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. 30

34. Configuration de JBoss Clustring s 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. 31

35. Déploiement de l’application Hello world s 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: 32

36. Déploiement de l’application Hello world s 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/deploymais 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/farmde 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. 33

37. Déploiement de l’application Hello world s 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/deploymais 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/farmde 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. 34

38. Test s 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. 35

39. Test 172.16.10.10 (IP flottanate) s Cluster: sharky 172.16.10.2 172.16.10.1 tux 1 tux 2 (AJP) 80098080 Storagetux0 172.16.10.253 36

40. more … http://tritux.com/products/ http://tritux.com/services/ http://tritux.com/blog/1 9 Rue du Niger, Mont Plaisir / TunisCentre Hanene, 4é étage info@tritux.com