Un nouveau thème, dont le principal objectif est d’avoir une largeur extensible sur toute la largeur de l’écran (du navigateur).

Cela va permettre plus de flexibilité sur les articles tutoriel, pour les captures d’écran.

./

Pour ceux qui ne connaissent pas YUM, ce dernier est un utilitaire bien pratique dans les distributions Linux utilisant les packages RPM, tel que RedHat ou CentOS.

YUM permet en effet de faire la gestion des packages sur ces types de distributions, en gérant les dépendances entre les packages, c’est-à-dire que si vous voulez installer par exemple PHP sur votre serveur Linux RedHat, il suffit de faire « yum install php » et hop, tous les packages nécessaires à PHP vont être installés (entre autres le serveur Apache HTTP ).

Mais pour cela, YUM a besoin d’une connexion à Internet pour 1/ localiser le package désiré, 2/ télécharger son entête pour voir ses dépendances, 3/ télécharger les entêtes de ses dépendances et générer également les dépendances de ses dépendances, 4/ puis quand il n’y a plus de dépendances à gérer, procéder au téléchargement et à l’installation.

Le problème est que parfois, la connexion à Internet n’est pas disponible pour faire des installations ou des mises à jour sur des serveurs dans des salles blanches sécurisées. Pas de problème, YUM avec un peu de configuration sait aussi travailler en « local », à partir du média d’origine ou d’une version de mise à jour.

Donc, pour pouvoir faire des installations ou des mises à jour depuis le DVD (ou les Cdroms) de Redhat, il faut bien entendu le media, ou mieux l’image ISO du media.

Ici c’est l’image ISO de la Redhat Linux Entreprise (RHEL) version 5.2 pour processeurs Intel avec les extensions 64 bits : rhel-5.2-server-x86_64-dvd.iso

Comme pré-requis, j’ai déposé l’image ISO dans le répertoire /root/dvd_redhat/

Etape 1 : Montage de l’image ISO sur le système de fichiers afin de récupérer les packages RPM qui serviront à l’installation ou à la mise à jour.

mkdir /root/dvd_redhat/disk/

mount -o loop /root/dvd_redhat/rhel-5.2-server-x86_64-dvd.iso /root/dvd_redhat/disk/

La commande « mount -o loop » qui commence à être de plus en plus connue, permet « d’ouvrir » une image ISO, et de la monter sur l’arborescence de fichiers. Ici, dans le répertoire /root/dvd_redhat/disk/

Etape 2 : Récupération des packages RPM dans un nouveau répertoire.

L’image ISO montée étant en mode lecture seule, il faut copier les fichiers RPM vers un répertoire en lecture/écriture (pour faire l’étape 4).

mkdir /root/dvd_redhat/RPM

cd /root/dvd_redhat/disk/Server/

cp *.rpm /root/dvd_redhat/RPM/

Etape 3 : Installation de l’utilitaire createrepo

On profite d’être dans le répertoire qui contient tous les packages RPM, pour installer manuellement l’utilitaire createrepo, ce dernier permettant de faire l’étape suivante.

rpm -i createrepo-0.4.11-3.el5.noarch.rpm

dans le cas d’une installation RedHat vide (sans aucun paquetage coché lors de l’installation), prendre cette ligne de commande :

rpm -i createrepo-0.4.11-3.el5.noarch.rpm libxml2-python-2.6.26-2.1.2.8.i386.rpm rpm-python-4.4.2.3-18.el5.i386.rpm
yum-metadata-parser-1.1.2-3.el5.i386.rpm yum-3.2.22-26.el5.noarch.rpm python-elementtree-1.2.6-5.i386.rpm
python-iniparse-0.2.3-4.el5.noarch.rpm python-sqlite-1.1.7-1.2.1.i386.rpm
python-urlgrabber-3.1.0-5.el5.noarch.rpm m2crypto-0.16-6.el5.6.i386.rpm

Etape 4 : Création du nouveau référentiel (repository) de fichier

On se place sur le nouveau répertoire contenant les RPM copiés de l’image ISO, et on va créer un nouveau référentiel (index) des fichiers RPM avec la commande createrepo.

cd /root/dvd_redhat/RPM/

createrepo ./

La commande createrepo prend comme argument le répertoire courant, ici /root/dvd_redhat/RPM/ .

Elle va créer un ensemble de fichiers dans un sous-repertoire ./repodata/

Tiens, on a plus besoin du montage de l’image ISO, on en profite pour démonter…

umount /root/dvd_redhat/disk/

Etape 5 : Création du fichier de référence du nouveau référentiel

Pour que YUM puisse utiliser notre nouveau référentiel, il faut lui ajouter sa référence dans sa configuration. Sous RHEL, il faut simplement créer le fichier suivant :

vi /etc/yum.repos.d/RedHat-Media.repo
======================CONTENU=====================================
[redhat-media]
name=RedHat-$releasever - Media
baseurl=file:///root/dvd_redhat/RPM/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
==================================================================

Etape 6 : utilisation de YUM

On va commencer par faire un nettoyage de YUM avec le commande suivante :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins clean all

On notera le « –disablerepo=\* » qui permet de désactiver toutes les références vers d’autres référentiels, le « –enablerepo=redhat-media » qui indique que l’on souhaite travaillait avec notre nouveau référentiel, et pour finir l’option « –noplugins » qui va désactiver tous les plugins, notamment celui du RHN qui nécessite une connexion Internet que nous n’avons pas.

Le « clean all » commandant le nettoyage du cache de YUM.

Voilà.

Ensuite, on peut utiliser YUM pour gérer les installations, les désinstallations, les mises à jour de ses packages en gérant les dépendances.

Pour une installation :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins install <nom_package(s)>

Pour une suppression :

yum --disablerepo=\* --enablerepo=redhat-media --noplugins remove <nom_package(s)>

Pour une mise à jour de version sur l’ensemble des packages (par exemple un passage de RHEL 5.1 à RHEL 5.2)

yum --disablerepo=\* --enablerepo=redhat-media --noplugins update

Bon courage.

./

Il fonctionne à ce jour (août 2008) avec Windows 95, la batterie est morte par contre (c’est bien normal). Evidemment ce n’est pas une bête de course, et avec ses 500 Mo de disque dur, je ne vais pas aller loin maintenant.

Bon, il faut aussi revenir dans le présent, j’ai fait l’aquisition du fameux eeePC d’Asus, j’ai pris le premier modèle, le numéro 701 livré avec la distribution Linux Xandros, ceci via le site de commerce Amazon (très bon prix).

Dès réception, j’ai installé à la place du Xandros, la version Ubuntu eee, histoire de capitaliser sur la distribution Linux que j’utilise sur mon portable actuel et principal (rappel : un Dell D820).

L’installation s’est passée sans problème, et il marche bien. Il est évidemment moins rapide que mon D820. L’impression la plus importante que j’ai, c’est sa petite taille. Sinon la qualité de l’écran est bonne, la taille reste petite aussi avec une résolution faible (800×600) qui nécessite de faire un Zoom Out dans Firefox pour voir les sites web dans toute leur largeur.

La raison de l’achat, est simplement, que vu son faible prix, j’avais envie d’avoir une machine pour s’amuser à tester des choses en dehors de mon ordinateur principal. Il est certain que je ne vais pas m’en servir pour travailler tous les jours avec. Cependant je me vois bien l’amener en vacances avec moi plutôt que le ‘gros’ D820.

Et pour finir une photo d’une petite comparaison de taille avec l’écran fermé entre le Asus eeePC et le Toshiba T2150CDS.

./

Par exemple, vous devez exécuter une requête chaque 20 secondes, le temps de réponse de la dite requête est 4,5 sec. Donc si on démarre à T0, on a T0+4,5 sec la requête, puis on demande à JMeter de faire une pause pendant (20 sec – 4,5 sec = 15,5 sec), puis une nouvelle requête, etc.

Voici comme le faire avec JMeter.

Dans l’élément User Defined Variables, on place une variable qui sera la durée fixe (en millisecondes) de l’intervalle.

On place également un élément Transaction Controller qui contient l’élément HTTP Request (ou plusieurs éléments HTTP Request). A l’intérieur de l’élément HTTP Request (ou du premier élément), on ajoute un élément User Parameters, dans lequel on ajoute une variable START qui sera initialisée à « ${__time(,)} », c’est à dire au temps en millisecondes de début de la requête.

Ensuite en dernier élément du Transaction Controller, on ajoute un élément Test Action, qui sera chargé de mettre en pause le thread group durant l’intervalle de temps d’attente. Pour cela on définit sa durée avec la formule suivante : « ${__longSum(${INTERVALLE},${START},-${__time()})} ». Cette dernière fait le calcul du temps à attendre par rapport à la variable START et la variable INTERVALLE.

On ajoute les autres éléments restants (cookie manager, http request defaults, etc). Puis, on peut lancer un petit tir de contrôle de bon fonctionnement. Ici le Thread Group est à 1-1-4 (1 user, ramp-up à 1 sec, 4 boucles).

Le résultat est ci-dessous. On voit que les requêtes durent en moyenne 5,7 secondes, et que chaque requête est appelée chaque 20 secondes (l’élément Transaction Controller donnant le temps passé de la requête HTTP + du Test Action).

Et voilà, avec ce type de scénario, on peut répondre à un besoin du type « je veux que mon utilisateur exécute chaque 20 secondes une requête quelque soit le temps de réponse de la requête« 

Le script JMeter est téléchargeable ici.

./

On aura ainsi :

• les « tireurs » ceux qui vont faire le tir de charges avec un outil dédié,
• les fonctionnels qui assistent les tireurs pour la scénarisation du tir,
• les préparateurs de données qui sont chargés de fournir des données aux injecteurs pour le tir,
• les gens du réseau pour la surveillance du trafic et de la bande passante,
• les DBA pour la surveillance de l’activité de la base de données,
• les superviseurs des serveurs d’applications pour monitorer l’activité de l’application,
• l’équipe de développement de l’application qui croisent les doigts,
• et bien sur les chefs du fonctionnel et les chefs de la technique

Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.

Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…

Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :

• configuration de la taille minimum et maximum idéale pour ce type d’application
• modification des paramètres de JVM pour avoir notamment un fonctionnement du Garbage Collector en (quasi) parallèle (Concurrent Mark Sweep)
• réglage des unités d’exécution min et max, temps d’inactivité
• réglage du pool de connexions à la base de données, avec activation du cache des requêtes SQL préparées
• réglage du gestionnaire de sessions
• activation du monitoring,
• et d’autres petits réglages de derrière les fagots : taille des files d’attente TCP, nombre des requêtes keep-alive, etc

Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges…

Voici quelques cas, dont le problème est visible sur le serveur d’applications, mais l’origine est ailleurs :

1/ le serveur d’applications explose en OutOfMemory… C’est en général de la faute à l’application développée ou de l’utilisation du framework de persistence (genre Hibernate). Un exemple, c’est le chargement de plusieurs fois un million d’enregistrement dans la mémoire (car plusieurs centaines d’utilisateurs simulés et non plus les quelques développeurs et testeurs de la recette). On aura ainsi par exemple, 100 fois 10 Mo dans la mémoire soit au moins 1Go, donc des OutOfMemory si la taille maximum de la mémoire JVM est à 1024 Mo.

2/ le nombre maximal des unités d’exécution est atteint. C’est en général de la faute de l’application développée ou bien de la base de données. En effet si le nombre max est atteint, mais que la CPU du serveur n’est pas utilisée, on peut en déduire que les unités d’exécution sont en attente de quelque chose… Et souvent c’est de résultat de la base de données. Soit cette dernière est surchargée, soit il manque quelques index quelque part ou tout simplement il faut régénérer les statistiques de la base de données.

3/ Tout va bien sur le serveur d’application, sur la base de données, etc, mais l’application est « lente » à la réponse. Et bien là on peut se poser la question du réseau. Il convient de s’assurer que toutes les cartes réseaux soient configurées en 100 Mbits/s Full Duplex (ou en gigabit), que les switchs d’interconnexion également (port par port), et les routeurs si il y a lieu. Le mieux est de faire un test FTP (via un client classique vers le serveur, ou via JMeter). En effet, on verra que si l’une des interfaces est en 10 Mbits/s half duplex, par exemple celle du répartiteur de charges, et l’ensemble des serveurs derrière ne seront pas surchargés, mais l’application sera désespérément lente (goulot d’étranglement sur le lien réseau). (pour l’histoire, une interface réseau peut basculer en 10 Mbits/s HD tout simplement car l’auto négociation de vitesse avec le switch a échoué, et ainsi la carte prend la valeur la plus basse…

4/ Les pages de l’application affichent des erreurs 500… c’est en général un problème applicatif engendré par un problème externe. Par exemple l’atteinte du nombre maximum autorisé de fichiers ouverts pour un processus, ou bien la base de données n’accepte plus de nouvelles connexions…

Par ailleurs, on peut aussi avoir un cumul de ces problèmes, et chaque tir de charges montrent un nouveau problème…

Mais quand tout est bien réglé, c’est à dire que l’ensemble des composants de la solution est bien paramétré, avec de la logique, et bien le tir de charges se passe à merveille !

./