C’est ce que permet de faire le protocole NTP (Network Time Protocol), nous allons dans ce petit tutoriel voir comment installer et configurer NTP sur un système Linux.

Tout d’abord, il faut installer le paquet NTP, il est généralement installé sous la plupart des distributions :

#Pour CentOS/Red Hat/Fedora
yum install ntp

#Pour Debian/Ubuntu
apt-get install ntp

Éditer le fichier de configuration pour spécifier les serveurs de temps à utiliser

vi /etc/ntp.conf

Nous pouvons par exemple utiliser les serveurs du projet pool.ntp.org

server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

Vous trouverez une liste complète de serveur à cette adresse ou encore ici

Il faut ensuite démarrer le service et lancer au démarrage du système

#Pour CentOS/Red Hat/Fedora
chkconfig ntpd on
service ntpd start

#Pour Debian/Ubuntu
update-rc.d ntp defaults
service ntp start

Pour forcer la mise à jour de l’heure, nous utiliserons la commande ntpdate il faudra d’abord arrêter le service puis le relancer après la mise à jour

#Pour CentOS/Red Hat/Fedora/Debian/Ubuntu
service ntpd stop
ntpdate 0.fr.pool.ntp.org
service ntpd start

Pour vérifier que le système est bien à l’heure, il suffira d’exécuter la commande date

date

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Lancer le test

Nous pouvons ensuite lancer le test avec la commande (qui par défaut chargera le fichier de configuration ~/.tsung/tsung.xml) :

tsung start

Pour utiliser un autre fichier de configuration, il faut passer le chemin de ce dernier à la commande, soit :

tsung -f ~/.tsung/tsung-second-test.xml start

Au lancement du test, Tsung crée un dossier contenant les logs, que nous utiliserons plus tard pour générer le rapport.

La montée en charge est maintenant lancée vous pouvez à tout moment l’arrêter en tapant la commande « Tsung stop » ou la combinaison de touche ctrl+c

2 – Générer le rapport

Une fois le test terminé, il faut se rendre dans le dossier contenant les logs :

Cd ~/.tsung/log/20130201-2348

Et ensuite générer le rapport avec la commande (notez qu’il sera plus pratique de créer un alias nommé par exemple « tsung-repport » que d’exécuter cette commande).

/usr/lib/tsung/bin/tsung_stats.pl

Le rapport se trouvera alors dans le même dossier que les logs, et se nommera « repport.html »

L’ouverture du rapport peut se faire entre autre avec la commande (A condition d’utiliser l’option –X de ssh)

firefox report.html

Le rapport possède deux parties, la première étant composée de statistiques,

et la seconde de graphiques.

Il ne reste maintenant plus qu’à analyser le rapport afin de tirer les conclusions de cette montée en charge. A noter que le rapport ci-dessus a été généré en quelques secondes de tests (d’où le peu d’informations qu’il contient).

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Copier un exemple basique dans ~/.tsung

Tsung propose plusieurs fichiers d’exemples de configuration, et nous allons ici en prendre un simple afin de l’adapter à notre application. Il faut tout d’abord vérifier l’existence du répertoire ~/.tsung qui est l’emplacement des fichiers de configuration et de journaux de Tsung.

Mkdir ~/.tsung

Copier ensuite le fichier d’exemple.

cp  /usr/share/doc/tsung/examples/http_simple.xml ~/.tsung/tsung.xml

2 – Enregistrement d’un scénario

A cette étape nous allons utiliser la commande « Tsung-recorder » pour enregistrer un scénario de navigation, c’est-à-dire l’activité d’un internaute sur notre application. Cette étape est néanmoins optionnelle puisqu’il sera possible d’écrire notre scénario directement dans le fichier de configuration de Tsung (un scénario peut être juste le chargement d’une page, un fichier etc.).

Pour lancer l’enregistrement d’un scénario il suffit de taper la commande :

tsung-recorder start

Tsung-recorder lancera un proxy qui écoutera sur le port 8090 et enregistrera la navigation dans un fichier. Il suffira ensuite de paramétrer un navigateur internet afin qu’il utilise ce proxy.

Tsung recorder nous indiquera aussi le nom du fichier généré.

L’étape suivante est de lancer le navigateur (ici Firefox) installé sur le serveur. Si vous ne possédez pas d’interface graphique sur le serveur, il faudra rediriger la sortie graphique avec l’option –X de ssh.

Pour ce faire, il faut tout d’abord installer les paquets X Window.

yum groupinstall 'X Window System'

Ouvrir une nouvelle session SSH.

ssh –X utilisateur@serveur

Puis lancer Firefox via la commande.

Firefox

Votre navigateur doit alors s’ouvrir. Il suffit maintenant de configurer le proxy et de naviguer sur l’application que l’on souhaite tester.

Une fois terminé, taper la commande suivante pour arrêter l’enregistrement :

tsung-recorder stop

Nous pouvons visualiser l’enregistrement en ouvrant le fichier :

cat  ~/.tsung/tsung_recorder20130201-2335.xml

Voici un extrait du contenu :

<request><http url='/index.html' version='1.1' method='GET'></http></request>
<request><http url='/contact.html' version='1.1' method='GET'></http></request>

3 – Configuration du test

Maintenant que tout est installé et que notre scénario est enregistré, nous allons éditer la configuration de notre test afin de renseigner tous les paramètres de la montée en charge. Pour cela il faut éditer le fichier tsung.xml

Dans le XML de configuration, quatre nœuds vont nous intéresser :

• <Clients> : Il s’agit de définir les clients utilisés par Tsung. Il est possible de définir les IP, nombre d’utilisateurs maximum, nombre de processeurs etc.
• <Servers> : Défini le serveur cible (notre plateforme à tester).
• <Load> : Défini la/les phase(s) d’arrivée(s) de nos visiteurs, c’est-à-dire les étapes de notre montée en charge. Le nœud Load est donc composé d’un ou plusieurs nœuds arrivalphase.
  • <Arrivalphase> : Contient les détails d’une phase d’arrivée : durée, nombre d’utilisateurs à simuler, fréquence d’arrivée des visiteurs …
  • Généralement, plusieurs phases seront définies en accentuant la montée en charge, jusqu’à arriver à un stress intensif.
• <Sessions> : Contient les scénarios d’utilisation possible. Chaque scénario équivaut à un nœud « Session », et est composé de « Request ». A noter qu’il est possible de définir des probabilités pour les scénarios (le total des probabilités doit toujours être égal à 100).
  • Les boucles : permettent d’augmenter le nombre de requêtes à effectuer sur l’application. Tsung nous permet de boucler sur les balises <request>, via l’utilisation de <For> …
  • <for from= »1″ to= »10″ var= »i »><request>…</request></for> : Pour boucler 10 fois sur les <Request>, de façon à générer encore plus de requêtes sur notre plateforme.

Maintenant que nous avons présenté rapidement les principaux points du fichier de configuration, nous allons passer à l’édition. Pour ce faire, il suffit d’ouvrir le fichier ~/.tsung/tsung.xml, et de le modifier afin de créer la configuration de test idéale pour votre architecture, vos besoins, etc.

vi ~/.tsung/tsung.xml

Voici un exemple de fichier XML :

<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">

	<!-- Configuration du client -->
	<clients>
		<client host="localhost" use_controller_vm="true"/>
	</clients>

	<!-- Configuration du serveur -->
	<servers>
		<server host="192.168.1.11" port="80" type="tcp"></server>
	</servers>

	<!-- phases d'arrivée, 3 paliers de 10 minutes où l'on augmente la fréquence d'arrivée de 1 puis 10 puis 30 visiteurs par seconde -->
    <load>
        <arrivalphase phase="1" duration="10" unit="minute">
            <users arrivalrate="1" unit="second"></users>
        </arrivalphase>
        <arrivalphase phase="2" duration="10" unit="minute">
            <users arrivalrate="10" unit="second"></users>
        </arrivalphase>
        <arrivalphase phase="3" duration="10" unit="minute">
            <users arrivalrate="30" unit="second"></users>
        </arrivalphase>
    </load>

	<!-- Les scénarios -->
	<sessions>
		<!-- Scénarios 1 avec 70% de probabilité, l'internaute charge successivement 3 pages -->
		<session name="scenario1" probability="70" type="ts_http">
			<request><http url='/page1.html' version='1.1' method='GET'></http></request>
			<request><http url='/page2.html' version='1.1' method='GET'></http></request>
			<request><http url='/page3.html' version='1.1' method='GET'></http></request>
		</session>
		<!-- Scénarios 2 avec 30% de probabilité, l'internaute charge 10 fois la page 1 -->
		<session name="scenario2" probability="30" type="ts_http">
			<for from="1" to="10" var="i">
				<request><http url='/page1.html' version='1.1' method='GET'></http></request>
			</for>
		</session>
	</sessions>
</tsung>

Dans la troisième et dernière partie de ce tutoriel nous verrons comment lancer le test de montée en charge et générer un rapport.

Tsung est un outil permettant d’effectuer des tests de montée en charge sur une architecture. Une de ses particularités, est qu’il ne se limite pas au protocole HTTP, mais gère aussi WebDAV, SOAP, PostgreSQL, MySQL ou encore LDAP. Tsung est gratuit, distribué sous licence GPLv2 et dispose d’une documentation relativement claire.

Le principe est relativement simple : l’application va simuler l’arrivée de nombreux utilisateurs sur la plateforme. Le plus de Tsung par rapport à ses concurrent est de pouvoir créer des scénarios d’utilisation (et propose même un utilitaire d’enregistrement de scénario). Cela signifie que l’application ne se contente pas de charger une page à intervalle régulier, mais de simuler la navigation sur la plateforme.

Une fois le test terminé, Tsung nous permettra de générer un rapport contenant une série de graphiques ; l’analyse sera donc relativement simple.

L’utilisation d’utilitaires de montée en charge comme Tsung permet :

• De connaître la charge qu’une plateforme peut supporter
• Vérifier que la capacité d’accueil de la plateforme est conforme aux spécifications (et donc aux demandes d’un client par exemple)

Avant d’utiliser cet outil, il est bon de s’assurer de deux choses :

• Que le réseau est suffisamment dimensionné : en effet un réseau sous dimensionné créera un goulot d’étranglement en amont de notre plateforme.
• La plateforme doit vous appartenir. Dans le cas contraire, vous devez avoir un accord de l’hébergeur.

Nous allons ici nous intéresser à la mise en place d’un test simple sur une application web. Nous effectuerons les manipulations sous CentOS, les commandes seront donc identiques sous Fedora et Red Hat (RHEL). Pour les autres distributions, seuls les noms des paquets devraient changer ainsi que deux ou trois commandes.

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Installer CentOS

Comme dit précédemment, nous utiliserons CentOS, la version 6.3 minimale. Pour le téléchargement, c’est par ici.

La première étape sera donc l’installation de la distribution.

2 – Ajouter les dépôts additionnels

Nous installons ici les dépôts RPMForge, EPEL et Remi qui nous servirons à installer les paquets requis pour l’installation de Tsung.

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

3 – Mise à jour de la distribution et installation des paquets utiles

Nous allons maintenant mettre à jour la distribution et installer les paquets Man, Locate, Bash-Completion, Make et Wget.

yum update
yum install man mlocate bash-completion make wget

4 – Installer les pré-requis

Nous allons maintenant installer les paquets requis pour l’installation de Tsung. Il s’agit d’Erlang, Perl, Gnuplot ainsi que certains modules de Perl.

yum install erlang perl gnuplot perl-RRD-Simple.noarch perl-Log-Log4perl-RRDs.noarch perl-Template-Toolkit

Nous installerons aussi Firefox car il nous servira pour la visualisation des rapports.

yum --enablerepo=remi install Firefox

5 – Installation de Tsung

Nous allons maintenant passer à l’installation de Tsung à proprement parler. A l’heure de l’écriture de ce guide, Tsung est en version 1.4.2. La dernière version se trouve sur le site officiel.

Pour le téléchargement :

cd /tmp
wget http://tsung.erlang-projects.org/dist/tsung-1.4.2.tar.gz

Ensuite il faut décompresser l’archive et compiler Tsung. Cette dernière opération peut être un peu longue.

tar zxfv  tsung-1.4.2.tar.gz
cd tsung-1.4.2
./configure && make && make install

Partie 2 : La configuration de Tsung

yum install vixie-cron crontabs
chkconfig crond on
service crond start

Actuellement, la version 10 est disponibles sur les dépôts, nous allons donc installer les dépôt EPEL et Remi qui distribuent la dernière version du navigateur.

1 – Installer les dépendances

Nous commençons par installer la dépendance requise pour l’installation du dépôt Rémi. Cette étape n’est pas nécessaire pour les versions 16/17/18 de Fedora.

# Installer le dépôt EPEL sous RHEL/CentOS 6.3/6.2/6.1/6.0
cd /tmp
wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm

# Installer le dépôt RPMFusion sous Fedora 14/15
cd /tmp
wget http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
wget http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm
rpm -ivh rpmfusion-free-release-stable.noarch.rpm
rpm -ivh rpmfusion-nonfree-release-stable.noarch.rpm

2 – Installer le dépôt Remi

Nous allons maintenant installer le dépôt Remi, à noter que cette étape n’est pas nécessaire pour les versions 16/17/18 de Fedora.

# Pour CentOS 6.x
cd /tmp
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
rpm -ivh remi-release-6.rpm

# Pour Fedora 15
cd /tmp
wget http://rpms.famillecollet.com/remi-release-15.rpm
rpm -ivh remi-release-15.rpm

# Pour Fedora 14
cd /tmp
wget http://rpms.famillecollet.com/remi-release-14.rpm
rpm -ivh remi-release-14.rpm

3 – Vérifier les versions de Firefox disponibles

Nous vérifions maintenant que la dernière version de Firefox est bien disponible.

# Pour Fedora 18/17/16
yum list firefox

# Pour Fedora 15/14, CentOS 6.x et Red Hat 6.x
yum --enablerepo=remi list firefox

4 – Installer / Mettre à jour Firefox

Installer Firefox sur votre distribution Linux.

# Mise à jour pour Fedora 18/17/16
yum update firefox

# Installation pour Fedora 18/17/16
yum install firefox

# Mise à jour pour Fedora 15/14, CentOS 6.x et Red Hat 6.x
yum --enablerepo=remi update firefox

# Installation pour Fedora 15/14, CentOS 6.x et Red Hat 6.x
yum --enablerepo=remi install firefox

C’est fini vous pouvez dès maintenant utiliser la dernière version du navigateur (qui est à l’heure actuelle la version 18).

Il semble en effet que les additions VirtualBox ne se compilent pas correctement avec les dernières versions du noyau.

Cette procédure devrais fonctionner avec les versions récentes des distributions basé sur RedHat soit : CentOS (Supérieur à 5.8), RHEL (Supérieur à 5.8), Fedora (Supérieur à 12) …

1 – Obtenir les droits root

su -

2 – Monter les VirtualBox Guest Additions

Pour ce faire, il faut se rendre dans le menu périphérique et cliquer sur « Installer les Additions invité ».

Puis les monter

mkdir /media/VBoxAdditions
mount -r /dev/cdrom /media/VBoxAdditions

3 – On s’assure alors que l’on possède le dernier kernel

yum update kernel*
reboot

4 – Installation des paquets nécessaires

yum install kernel-headers kernel-devel gcc

5 – Ajouter la variable d’environnement KERN_DIR

Il faut tout d’abord récupérer la version du kernel avec la commande uname

uname -r

Créer la variable KERN_DIR, en remplaçant VERSION_DU_KERNEL par le résultat de la commande ce-dessus

KERN_DIR=/usr/src/kernels/VERSION_DU_KERNEL
export KERN_DIR

Par exemple

KERN_DIR=/usr/src/kernels/2.6.32-279.19.1.el6.x86_64

6 – Installer les VirtualBox Guest Additions

cd /media/VBoxAdditions
./VBoxLinuxAdditions.run

A la fin de l’installation il faut redémarrer la machine

reboot

Arrivé ici les VirtualBox Guest Additions devraient être fonctionnel.