Répartition de charge/tolérance aux pannes

avec HAProxy

Sommaire

1 PRESENTATION RAPIDE DE HAPROXY ............................................................................................. 1

2 EVOLUTION DE LA PLATE-FORME GSB ............................................................................................ 1
2.1 Cloner notre serveur web existant .......................................................................................... 2
2.2 Personnaliser le deuxième serveur ......................................................................................... 2
2.3 Conception du serveur HAProxy ............................................................................................. 3
2.3.1 Installation « matérielle » de la MV ................................................................................ 3
2.3.2 Installation logicielle de la MV......................................................................................... 3
3 LE SERVICE HAPROXY....................................................................................................................... 3
3.1 Configuration initiale de HAProxy ........................................................................................... 3
4 CONFIGURATION AVANCEE DE HAPROXY : SURVEILLANCE DU CLUSTER ....................................... 6
5 CONFIGURATION AVANCEE DE HAPROXY : REPARTITION INEGALITAIRE SUR SERVEURS
HETEROGENES ......................................................................................................................................... 8
6 CONFIGURATION AVANCEE DE HAPROXY : LE PROBLEMATIQUE DES SESSIONS ........................... 9
6.1 Supprimer les avertissements au démarrage........................................................................ 12
7 DOCUMENTATION COMPLEMENTAIRE ......................................................................................... 14
7.1 Document A : Clonage de la MV serveur web 1 .................................................................... 14
7.2 Document B : personnalisation de la MV serveur web 2 ...................................................... 14
7.3 Document C : Modification du fichier index.html ................................................................. 16
7.4 Document D : Création de la MV HAProxy ............................................................................ 17
7.5 Document E : Installation Debian pour HAProxy .................................................................. 18
7.6 Document F : La commande netstat ..................................................................................... 19
7.7 Document G : Exemples de code HTML pour les pages de test ............................................ 20
7.7.1 Exemple de code HTML pour la page index.html .......................................................... 20
7.7.2 Exemple de code HTML pour la page achat.html.......................................................... 20
1 PRESENTATION RAPIDE DE HAPROXY

Extrait de la documentation officielle

HAProxy est un relais TCP/HTTP offrant des facilités d'intégration en environnement hautement
disponible. En effet, il est capable :
 d'effectuer un aiguillage statique défini par des cookies ;
 d'effectuer une répartition de charge avec création de cookies pour assurer la persistance de
session ;
 de fournir une visibilité externe de son état de santé ;
 de s'arrêter en douceur sans perte brutale de service ;
 de modifier/ajouter/supprimer des en-têtes dans la requête et la réponse ;
 d'interdire des requêtes qui vérifient certaines conditions ;
 d'utiliser des serveurs de secours lorsque les serveurs principaux sont hors d'usage.
 de maintenir des clients sur le bon serveur d'application en fonction de cookies applicatifs.
 fournir des rapports d'état en HTML à des utilisateurs authentifiés, à travers des URI de
l'application interceptées.
Il requiert peu de ressources, et son architecture événementielle mono-processus lui permet
facilement de gérer plusieurs milliers de connexions simultanées sur plusieurs relais sans effondrer le
système.
Nous allons nous intéresser essentiellement à la répartition de charges, en tous cas dans un premier
temps.

2 EVOLUTION DE LA PLATE-FORME GSB

Pour mettre en pratique les fonctionnalités de répartition de charge et de tolérance aux pannes
proposées par HAProxy, nous allons travailler sur la DMZ de votre agence. Actuellement, cette dernière
se compose uniquement de votre serveur Web linux nommé 100ZDEB81 (100Z représente le numéro
de votre VLAN de DMZ)

L’objectif de ce support est d’utiliser un serveur HAProxy en amont pour qu’il puisse
distribuer/répartir, de manière intelligente les requêtes web envoyées par les clients web vers deux
serveurs web proposant les mêmes services.

Notre DMZ sera donc composée de deux serveurs web et du serveur HAProxy, tous les trois protégés
par le pare-feu IPFIRE déjà en place.

1
 2.1 Cloner notre serveur web existant

De manière à obtenir un deuxième serveur web rapidement et à l’identique de l’existant, nous allons
utiliser la notion de clonage proposée par la virtualisation.

TRAVAIL A FAIRE (1)

- A l’aide du document A, clonez votre serveur web de manière à obtenir un deuxième serveur web
nommé 100ZDEB82.

Remarque : L’assistant de clonage à bien changer l’adresse MAC de la carte réseau.

2.2 Personnaliser le deuxième serveur

L’assistant de clonage VMware vSphere nous a cloné le serveur web mais il va nous falloir désormais
aller personnaliser certaines choses propres au paramétrage logiciel de manière à éviter la notion de
doublon (du côté OS).

TRAVAIL A FAIRE (2)

- Démarrez la MV 100ZDEB82
- A l’aide du document B, personnalisez cette nouvelle MV.

TRAVAIL A FAIRE (3)

- Démarrez la MV 100ZDEB81
- Copiez le fichier /var/www/html/index.html et renommez cette page indexorig.html
- Sur le serveur 100ZDEB81, Editez (ou refaites) la page /var/www/html/index.html et modifiez-la
(allégez-la) de manière à avoir une information indiquant sur quel serveur web se trouve cette page.
Un exemple vous est donné dans le document C.
- Faites de même sur le serveur web 100ZDEB82 en faisant les modifications qui s’imposent.
- Depuis le navigateur de la station XXX7ENT641, essayez d’accéder à ces deux pages d’index par les
liens suivants http://10.69.Z.1 et http://10.69.Z.2. Vous devriez obtenir les résultats affichés dans le
document C.

2
 2.3 Conception du serveur HAProxy

2.3.1 Installation « matérielle » de la MV

Nous allons installer une MV Debian version 8 en 64 bits classique.

TRAVAIL A FAIRE (4)

- Créez une MV nommée XXXDEB83 en suivant les indications du document D

2.3.2 Installation logicielle de la MV

Nous allons maintenant faire une installation basique de Debian 8 (64 bits)

TRAVAIL A FAIRE (5)

- Installez Debian 8 (64 bits) sur 100ZDEB83 en suivant les indications du document E.
- Installez le paquetage HAProxy en utilisant la commande apt-get install haproxy
- Vérifiez que l’exécutable haproxy se trouve bien dans /etc/init.d/

- Vérifiez que le fichier de configuration haproxy.cfg se trouve bien dans /etc/haproxy/

- Renommez ce fichier haproxy.cfg en haproxy.exemple

3 LE SERVICE HAPROXY
3.1 Configuration initiale de HAProxy

Nous allons procéder par étape de manière à complexifier la solution en validant chaque évolution.
Nous allons commencer par créer un nouveau fichier de configuration haproxy.cfg avec un minimum
vital, voire même moins …

TRAVAIL A FAIRE (6)

- Installez vim par la commande apt-get install vim
- Tapez la commande vim /etc/haproxy/haproxy.cfg en lui mettant comme contenu ce qui suit :

Remarque : pour la suite, les impressions d’écran de ce fichier seront prises pour l’agence 9, vous
ajusterez donc les valeurs à votre agence.
Pensez à adapter le fichier en remplaçant les valeurs exemples par les valeurs de votre agence.

3
- Vérifiez que la syntaxe du fichier est correcte par la commande suivante :
haproxy –c –f /etc/haproxy/haproxy.cfg
-c pour seulement « checher » (tester/valider) le fichier
-f pour spécifier le fichier de configuration

Remarque : le message final (voir figure ci-dessus) vous indique que le fichier de configuration est
valide, mais un avertissement signale, comme prédit ci-avant, que ce fichier est un « bâclé » : Aucun
timeout n’est précisé, ce qui peut poser problème. Nous traiterons ce paramétrage à la fin du support.
Quelques explications sur ce fichier de configuration :
L’essentiel est tiré de l’article sur Linux Magazine ou de la documentation en ligne

 listen permet de demander à HAProxy d’écouter sur l’IP et le port indiqué.

 Si on ne précise que « :80 », le HAProxy écoute sur toutes les IPs de la machine, dans
notre cas cela reviendrait au même puisque notre HAProxy ne possède qu’une
interface et une adresse IP.

 mode permet de spécifier que l’on va travailler sur des flux http
 HAProxy fera une analyse détaillée des requêtes clients avant de les faire suivre aux
« frontaux ». Ce mode permettra ultérieurement de faire du filtrage de niveau 7 (OSI).
Les autres modes possibles sont « tcp » (connexions TCP génériques) ou health (ancien
mode utilisé pour la surveillance par des composants externes).
A noter qu’on peut effectuer de la répartition de charge sur autre chose que le service
http.

 balance permet de choisir l’algorithme de la répartition vers les frontaux

 Le roundrobin est le plus classique et le plus simple : il consiste à utiliser les serveurs
un a un, chacun son tour.
Il est possible d’affecter des poids particuliers aux ressources, par exemple pour
utiliser deux fois plus souvent le serveur 1 (que le 2) car il dispose d’une plus grande
puissance CPU/RAM (que le 2).
Les autres modes possibles sont :
 leastconn : le serveur sélectionné sera celui ayant précédemment reçu le
moins de connexions
 source : le serveur est sélectionné en fonction de l’IP source du client

4
  uri : le choix du serveur est fonction du début de l’URI demandée
 url_param : le choix du serveur est fonction de paramètres présents dans l’URL
demandée
 hdr : le choix du serveur est fonction d’un champ présent dans l’en-tête HTPP
(Host, User-Agent, …)

 L’option httpclose force à fermer la connexion http une fois la requête envoyée au client. On
évite ainsi de conserver la connexion HTTP ouverte (« keep-alive ») et donc de renvoyer
systématiquement cette dernière vers le même serveur tant que la connexion reste ouverte.

Conserver la connexion ouverte pourrait être le comportant recherché, mais, dans le cadre de
notre installation, cela permettra de montrer facilement que l’algorithme « roundrobin »
fonctionne bien et que l’on tombe sur un serveur différent à chaque rafraîchissement de la
page.

 L’option httpchck, suivie d’une requête HTTP, permet de vérifier qu’un serveur web est
toujours en vie (vérification activée grâce à l’option check de server).

Si un frontal (serveurs web dans notre cas) venait à ne plus répondre (ou pas comme attendu)
à cette requête, il serait considéré comme hors service, et serait sorti du pool des frontaux ;
aucun utilisateur ne serait redirigé vers lui.

 La clause server déclare un serveur frontal, utilisé pour assurer le service. Chaque « server »
est nommé et suivi de son IP/port de connexion (port qui pourrait être différent du port
d’écoute de HAProxy).
L’option check est expliquée ci-dessus.

TRAVAIL A FAIRE (7)

- Vérifiez que le service peut (re)démarrer par la commande /etc/init.d/haproxy restart

- En tapant la commande suivante : netstat –tpnl | grep haproxy (Pour plus de détail sur netstat voir
document F), nous devrions avoir un résultat. Cette ligne résultat indique que le service HAProxy
écoute bien sur le port 80.

Conclusion : HAProxy est bien lancé et attend des requêtes sur le port 80 !

TRAVAIL A FAIRE (8)

- Dans le navigateur web de la station XXX7ENT641, taper http://10.69.Z.3/index.html
- Relancez plusieurs fois cette requête en appuyant sur F5 (rafraichissement) si vous êtes sur Firefox
ou Ctrl+F5 pour IE11, vous devriez constater un basculement d’un serveur web vers l’autre.
- Où devrions-nous intervenir pour pouvoir interroger notre HAProxy avec son nom DNS
(XXXDEB833.<votreagence>.coop ? Proposez votre solution à votre enseignant avant de le faire.
__________________________________________________________________________________

5
__________________________________________________________________________________
- Faites la ou les manipulations nécessaires pour pouvoir interroger les trois serveurs de la DMZ depuis
le LAN1 avec leur nom DNS.

4 CONFIGURATION AVANCEE DE HAPROXY : SURVEILLANCE DU

CLUSTER

Notre « cluster » fonctionne merveilleusement, certes, mais on peut encore faire mieux. Comment
savoir ce qui se passe, et comment sont sollicités dans le temps les différents frontaux ? Comment
connaître les éventuels temps d’indisponibilités ? etc…
Peut-être pensez-vous à nagios, Centreon ES ou shinken si vous connaissez ces outils de supervision,
mais haproxy dispose de sa propre interface de statistiques et de surveillance.
La question est donc :
 Comment paramétrer HAProxy pour pouvoir accéder aux statistiques de fonctionnement ?
 Comment accéder aux statistiques faites sur le fonctionnement de HAProxy ?

Nous allons maintenant faire évoluer le fichier de configuration de HAProxy pour découvrir d’autres
possibilités de ce service de répartition de charge.

TRAVAIL A FAIRE (9)

- Sauvegardez votre première configuration en copiant le fichier haproxy.cfg en haproxy.cfg1

- Modifiez le fichier haproxy.cfg de manière à obtenir un contenu similaire à celui-ci (adaptez le

contenu à votre HAProxy) :

- Vérifiez que la syntaxe du fichier est correcte par la commande suivante :

haproxy –c –f /etc/haproxy/haproxy.cfg

6
- Vérifiez que le service peut redémarrer par la commande /etc/init.d/haproxy restart

- Tapez http://<@IPHAProxy>/stats (authentification obligatoire ;-) depuis votre navigateur, vous

devriez avoir un résultat similaire à celui-ci-dessous :

Vous pouvez visualiser, dans la partie FRONTEND le nombre de sessions reçues sur HAProxy (dans la
figure ci-dessus le nombre est de 81). Dans la partie BACKEND, on constate que la répartition a été
bien faite (de manière équitable) par HAProxy, 39 de ces 81 sessions ont été envoyées et gérées par le
serveur 1 et 39 sessions par le serveur 2. Les 3 restantes correspondent aux interrogations statistiques
faites sur HAProxy et donc traitées uniquement par lui-même puisqu’il est le destinataire final de ces
requêtes statistiques.

La configuration est un peu plus complexe, mais reste lisible et compréhensible :

 Les paramètres par défaut sont définis dans le premier bloc
 Le bloc frontend décrit la partie publique, vue par les internautes ou
clients au sens large, autrement dit le port d’écoute et le backend associé à ce
port d’écoute, qui gèrera les connexions sur ce port.
 Le backend, c’est le moteur de la bête, le cluster web (les serveurs web) à
proprement parlé.
On retrouve à peu près toutes les options de la première configuration, mais une
nouvelle a été ajoutée :
 stats uri permet d’activer la page de statistiques, en définissant l’endroit où les statistiques
pourront être consultées (ici http://<@IPHAProxy>/stats)

7
  stats auth en sécurise l’accès en le protégeant par un nom d’utilisateur et un mot de passe,
séparés par « : »

5 CONFIGURATION AVANCEE DE HAPROXY : REPARTITION

INEGALITAIRE SUR SERVEURS HETEROGENES

Il est possible d’avoir un cluster composé de serveurs disparates, et que l’on ne souhaite pas leur faire
porter la même charge. Imaginons par exemple un processeur 2 fois moins puissant, une mémoire
moins importante, etc …
Exemple : Le serveur XXXDEB82 est trois fois plus puissant que le serveur XXXDEB81
La question est donc :
 Comment paramétrer HAProxy pour répartir la charge sur les serveurs, en fonction de leur
puissance ?

La réponse est :
 On va affecter aux serveurs une pondération différente, reflet de leur puissance : par exemple
50 pour XXXDEB81 et 150 pour XXXDEB82 (la valeur doit être comprise entre 0 et 255).

Nous allons maintenant faire évoluer le fichier de configuration de HAProxy pour prendre en compte
cette nouvelle possibilité.

TRAVAIL A FAIRE (10)

- Sauvegardez votre configuration actuelle en copiant le fichier haproxy.cfg en haproxy.cfg2

- Modifiez le fichier haproxy.cfg de manière à obtenir un contenu similaire à celui-ci (adaptez le

contenu à vos serveurs) :

- Vérifiez que la syntaxe du fichier est correcte par la commande suivante :

haproxy –c –f /etc/haproxy/haproxy.cfg

8
- Rechargez le fichier de configuration /etc/init.d/haproxy restart

- Dans le navigateur web de la station XXX7ENT641, taper http://10.69.9.3/index.html

- Relancer plusieurs fois cette requête en appuyant sur F5 (rafraichissement) ou Ctrl+F5, vous devriez
constater une répartition cyclique (une connexion envoyée sur XXXDEB81 pour trois connexions
envoyées sur XXXDEB82).
- Consultez les statistiques pour visualiser le nombre de connexions respectives sur chaque serveur en
naviguant sur http://10.69.9.3/stats, la répartition des sessions se fait désormais avec cette différence
de poids.

6 CONFIGURATION AVANCEE DE HAPROXY : LE PROBLEMATIQUE DES

SESSIONS

Notre site de test est simplissime, et ne nous permet pas de détecter cette problématique qui pourtant
poser quelques soucis au gérant d’un site de commerce en ligne.
Nous allons ajouter une 2ème page html (achat.html), accessible depuis la page d’accueil (index.html),
censée permettre d’effectuer des achats en ligne. (Voir document G pour les exemples de code HTML).
TRAVAIL A FAIRE (11)
- Sur les deux serveurs web, modifiez les pages index.html et créez les pages achat.html avec les
contenus proposés dans le document G.

9
Que pensez-vous de la succession de pages suivantes ?

L’utilisateur clique sur le lien « ici » pour obtenir :

L’utilisateur clique ensuite sur le lien de retour à l’accueil :

L’affichage n’a aucune importance, car l’internaute ne verrait pas la différence, car la page dans la
réalité serait bien identique quelque soit le serveur ; le nom du serveur a été indiqué à des fins de
démonstration uniquement.
En revanche, sans être un expert des sites web, vous vous doutez bien que cela posera quelques
problèmes.
 D’une part il est probable que le changement de serveur d’une page à l’autre soit
couteux, alors qu’il n’est pas vraiment nécessaire, car ce n’est pas une nouvelle
connexion d’internaute mais une simple navigation d’une page à l’autre.
 D’autre part, vous avez sans doute entendu parler de session utilisateur. Lorsque vous
réalisez des achats en lignes, votre connexion sur un serveur est une connexion
« suivie » et le changement de serveur implique obligatoirement l’arrêt de la
connexion sur un serveur et une nouvelle connexion sur un nouveau serveur.
 Enfin une authentification sur un serveur aura du mal à être valide pour un autre
serveur HTTP.
En effet, lorsqu’un utilisateur s’authentifiera sur le site, en fait il s’authentifiera sur un des frontaux.
Une session sera créée pour lui permettre d’accéder à tous les services, en tous cas à ceux auxquels il
a droit, d’après le statut que son authentification lui a donné.
Le problème, c’est qu’à sa prochaine requête, notre « load-balancer » fera son travail et redirigera
l’utilisateur sur un des frontaux, mais pas forcément le même que celui sur lequel il s’est authentifié.

10
Si ce n’est pas le même serveur, l’utilisateur se retrouvera alors déconnecté du site. Il pourra certes se
ré-authentifier, mais avec un peu de chance il retombera illico sur un autre serveur, et ainsi de suite.
On pourrait le vérifier facilement tout cela en créant une simple variable de session en PHP, mais ce
n’est pas notre tasse de thé le développement ;-) en tous cas pas notre préoccupation ici.
Maintenant que nous avons compris le problème, nous allons tenter de pallier à ce dernier par une
nouvelle version du fichier de configuration.
Comment faire ? Il faudrait que HAProxy puisse effectuer une répartition de charge sur les différents
frontaux, mais qu’un même utilisateur soit toujours redirigé vers le même frontal, afin de gérer
correctement sa session, et donc le cas échéant sont authentification.
HAProxy peut le faire pour vous ! Il suffit d’utiliser une astuce permettant de mémoriser sur le client
le serveur sur lequel on s’est connecté, et de communiquer cette information à chaque nouvelle
requête. Cela s’appelle un cookie ! (si ce n’est pas notre tasse de thé, en revanche c’est bien notre
cookie ;-)  Blague de mon ami David, je n’en porte aucune responsabilité … pour une fois.

TRAVAIL A FAIRE (12)

- Sauvegardez votre configuration actuelle en copiant le fichier haproxy.cfg en haproxy.cfg3

- Modifiez le fichier haproxy.cfg de manière à obtenir un contenu similaire à celui-ci (adaptez le

contenu à vos serveurs) :

- Vérifiez que la syntaxe du fichier est correcte par la commande suivante :

haproxy –c –f /etc/haproxy/haproxy.cfg

- Relancez le fichier de configuration : /etc/init.d/haproxy restart

11
  Une ligne cookie est apparue, ainsi qu’un paramètre cookie dans les lignes server.
Le principe est très simple :
 A la première connexion de l’utilisateur sur le site, HAProxy va déterminer, selon l’algorithme
sélectionné dans la configuration (ici roundrobin), vers quel frontal le rediriger.
 Quand HAProxy récupère auprès du frontal la copie de la page demandée par l’utilisateur, il la
renvoie en y insèrant un cookie QUELSERVEUR valant W1 ou W2 selon le frontal utilisé.
 Ainsi à la prochaine requête de notre utilisateur, son navigateur renverra également ce cookie
avec la requête.
 HAProxy, en fonction de la valeur, saura déterminer vers quel frontal renvoyer l’utilisateur.
Ainsi, plus de problème de session !
Oui mais si le frontal avait un problème et venait à planter ? L’utilisateur ne pourrait plus se connecter
à notre site !
… MAIS NON !
Bien sûr que si, car HAProxy saura déterminer que QUELSERVEUR pointe vers un serveur qui n’est plus
actif dans le cluster. Il détruira le cookie en lui réassignant une nouvelle valeur pour rediriger
l’utilisateur vers un nouveau frontal.
Certes la session qui était en cours sera alors perdue : il faudra se ré-authentifier. Mais le service sera
toujours rendu et notre cher$$ client aura toujours accès à son site favori !

6.1 Supprimer les avertissements au démarrage

Il suffit de rajouter les options proposées par défaut dans le fichier de config comme la figure ci-
dessous vous l’indique :

A noter que les warning n’empêchent pas le démarrage du service « à la main », mais empêchent le
« démon » de démarrer lors du boot de la machine.
TRAVAIL A FAIRE (13)
- Modifiez le fichier haproxy.cfg de manière à obtenir un contenu similaire à celui-ci ci-dessus.
- Vérifiez que la syntaxe du fichier est correcte par la commande suivante :
haproxy –c –f /etc/haproxy/haproxy.cfg

- Rechargez le fichier de configuration /etc/init.d/haproxy reload

12
Désormais le balancing ne se fait plus puisque le navigateur
utilise le cookie à chaque fois, il faut supprimer l’historique à
chaque fermeture d’IE et le balancing reprendra. Nous testons
ici avec un seul client.

Pensez à remettre les valeurs d’origine dans votre navigateur à

la fin de vos tests.

13
7 DOCUMENTATION COMPLEMENTAIRE

7.1 Document A : Clonage de la MV serveur web 1

Voici la procédure pour cloner votre serveur web.

- Arrêtez proprement votre MV 100ZDEB81 à l’aide de la commande shutdown –h now
- Faites un clic droit sur la MV et sélectionnez « Cloner… »
- Renseignez l’assistant avec les informations
suivantes :
o Nom et emplacement : Nom :
100ZDEB82, emplacement d’inventaire :
toujours le premier répertoire de votre
agence : VLANXXX (XXX est à adapter à
votre agence = LAN1).
o Hôte/Cluster : Sélectionnez Cluster-SIO
o Pool de ressources : VLANXXX
o Stockage : Format de disque virtuel : Sélectionnez « Thin Provision », pour le stockage
de destination : choisissez « SIO-STUDENT »
o Personnalisation client : Passez sans rien cocher
o Prêt à terminer : cliquez sur « Terminer »
A la fin de la procédure, vous devriez voir apparaitre une nouvelle MV dans votre pool.

7.2 Document B : personnalisation de la MV serveur web 2

Le clonage a personnalisé automatiquement la partie « physique » de la MV (@MAC par exemple) mais

rien n’a été fait au niveau logiciel, il va donc falloir changer le nom système de la MV ainsi que son
adresse IP. Voici les différentes tâches à réaliser sur la 100ZDEB82:
- Démarrez la MV concernée
- Connectez-vous en root (rappel : P@ssw0rdGSB)
- Editez le fichier /etc/hostname et modifiez le nom de la MV (« …1 » va devenir « …2 »)
- Editez le fichier /etc/hosts et modifiez le également (attention deux remplacements « …1 »
par « …2 » doivent avoir lieu, une fois dans le nom netbios et une fois dans le nom DNS, il
faudra également incrémenter de 1 le dernier octet de l’adresses IP, notre serveur 2 aura
l’adresses IP 10.69.Z.2 (la valeur de Z dépend de l’agence concernée). Vous devriez obtenir un
résultat similaire à celui-ci (exemple de paramétrage pour l’agence 9). Nous en profiterons
également pour ajouter les correspondances noms/@IP des deux autres serveurs web.
Expliquez pourquoi sans ces deux derniers ajouts, HAproxy et les deux serveurs Web ne
pourrons communiquer que par leur adressage IP ? _________________________________
____________________________________________________________________________
____________________________________________________________________________

14
- Tapez la commande hostname 100ZDEB82 (remarque : La modification de la valeur de l’invite
de commande ne se fera qu’après une reconnexion). Elle évitera un redémarrage de l’OS
- Tapez la commande exit pour vous déconnectez et reconnectez-vous en root (votre invite de
commande devrait être à jour désormais avec le nom du serveur web 2.
- Editez le fichier /etc/network/interfaces et incrémentez de 1 l’adresses IP de la MV de
manière à obtenir une valeur conforme à 10.69.Z.2.

Exemple ci-dessous pour l’agence 9 :

- Pour que la modification IP soit effective sans redémarrage du système, il faut taper les
commandes suivantes :
o Ifdown eth0 // Pour désactiver la carte eth0
o Ifup eth0 // Pour réactiver la carte eth0 (en lisant sa config dans le fichier
interfaces)

15
 7.3 Document C : Modification du fichier index.html

Contenu du fichier /var/www/html/index.html (sur le serveur 100ZDEB81)

Contenu du fichier /var/www/html/index.html (sur le serveur 100ZDEB82)

Affichage web résultant de la navigation http://10.69.Z.1

Affichage web résultant de la navigation http://10.69.Z.2

16
 7.4 Document D : Création de la MV HAProxy

Dans l’assistant de création de la MV, renseignez les informations de la manière suivante :

- Faites un clic droit sur votre dossier VLANXXX (XXX étant le chiffre lié au LAN1 de votre agence
que vous gérez) et choisissez « Nouvelle machine virtuelle… »
Dans Configuration
- Choisissez « Personnalisée »
Dans Nom et emplacement
- Nom : 100ZDEB83 (Z étant le numéro de votre agence)
- Emplacement d’inventaire : VLANXXX (vous ne devriez pas avoir à le sélectionnez puisque vous
l’avez fait au départ).
Dans Hôte/cluster
- Sélectionnez « Cluster-SIO »
Dans Pool de ressources
- Sélectionnez le VLANXXX
Dans Stockage
- Sélectionnez « SIO-STUDENT »
Dans Version de machine virtuelle
- Sélectionnez « Version de machine virtuelle : 8 »
Dans Système d’exploitation client
- Choisissez « Linux » puis « Debian GNU/Linux 6 (64 bits) »
Dans CPU
- Nombre de sockets virtuels : 1
- Nombre de noyaux par socket virtuel : 1
Dans mémoire
- RAM : 1 Go
Dans réseau
- NIC1 : <Indiquez votre VLAN correspondant à votre DMZ d’agence valeur en 100Z>
Dans Contrôleur SCSI
- Contrôleur SCIS : LSI Logic Parallel (par défaut)
Dans Choisir un disque
- Sélectionnez « Créer un disque virtuel »
Dans Créer un disque
- Taille disque : 40 Go
- Provisionnement disque : Thin Provision (Bien choisir cette valeur ATTENTION !!!!!!!!!)
- Emplacement : Stocker avec la machine virtuelle
Dans Options avancées
- Nœud périphérique virtuel : SCSI (0 :0) (valeur par défaut)
Prêt à terminer
- Cliquez sur « Terminer »

17
 7.5 Document E : Installation Debian pour HAProxy

Voici une brève synthèse des différentes étapes de l’installation de Debian, cette installation est
identique à celle que vous avez déjà réalisée plusieurs fois au long de votre cursus.

- Utilisez l’iso nommé « debian-8.1.0-amd64-DVD-1.iso »

- Choisir « Install »
- Langue : « French »
- Pays : « France »
- Clavier : « Français »
- Message « La configuration auto a échoué », c’est normal « Continuer »
- Configuration réseau « Configurer vous-même le réseau »
- Adresse IP : 10.69.Z.3 (voir votre plan d’adressage IP dans la DMZ)
- Valeur du masque : 255.255.255.0
- Passerelle : 10.69.Z.254 (votre IPFIRE côté DMZ)
- Adresse(s) des serveurs de noms : 8.8.8.8
- Nom de la machine : 100ZDEB83
- Domaine : <VotredomaineGSBenmajuscule>.coop (Exemple GSB-LILL-D.coop)
- Mot de passe root : P@ssw0rdGSB
- Nom complet du nouvel utilisateur : userdebian
- Identifiant pour le compte utilisateur : userdebian
- Mot de passe pour le nouvel utilisateur : P@ssw0rd
- Méthode de partitionnement : Assisté – utiliser un disque entier
- Disque de partitionnement : <sélectionner le seul disque présent sur la MV>
- Schéma de partitionnement : Partition /home séparée
- Choisir « Terminer le partitionnement et appliquer les changements »
- Faut-il appliquer les changements sur les disques ? « Oui »
- Faut-il analyser un autre CD ou DVD ? « NON »
- Faut-il utiliser un miroir sur le réseau ? « NON »
- Souhaitez-vous participer à l’étude statistique sur l’utilisation des paquets ? « NON »
- Dans sélections des logiciels : décocher « Environnement graphique de bureau » et « serveur
d’impression » puis « Continuer »
- Installer le programme de démarrage GRUB sur le secteur d’amorçage ? « OUI » puis
« /dev/sda »
- Installation terminée : « Continuer ».

Votre MV avait accès à Internet, elle a donc téléchargée les derniers paquetages en ligne, il n’est
donc pas nécessaire de lancer les commandes apt-get update et apt-get upgrade.

18
 7.6 Document F : La commande netstat

netstat affiche les connexions réseau, les tables de routage, les statistiques des interfaces, les
connexions masquées, les messages netlink, et les membres multicast.
Facile (on le trouve en faisant man netstat)
-n -- numeric
affiche les adresses en format numérique au lieu d’essayer de déterminer le nom symbolique
d’hôte, de port ou d’utilisateur
-p -- programs
affiche le nom et le PID des processus propriétaires de chaque socket décrite.
Il faut être le propriétaire d’un processus ou être l’utilisateur root pour disposer de toutes les
informations
Moins facile (on le trouve si on fait netstat –help ou on connaît bien l’ami google ;-)
-t -- tcp
montre uniquement les connexions TCP
-l -- listen
montre uniquement les sockets en attente (listen sockets)
HAproxy attend les requêtes sur les ports 80 ; il écoute donc bien sur le port 80 ; le socket en question
est donc bien « en attente ».
Résultat de la commande netstat –tpnl sur la machine virtuelle HAproxy :

En appliquant la commande grep au résultat de la commande précédente, on peut afficher

uniquement la ligne qui nous intéresse.

Si HAProxy fonctionnait correctement, vous devriez avoir le résultat suivant à la commande netstat -
tpnl | grep haproxy, je répète si vous n’aviez pas de problème ;-) :

Conclusion : HAProxy est bien lancé et attend des requêtes sur le port 80 !

19
 7.7 Document G : Exemples de code HTML pour les pages de test

7.7.1 Exemple de code HTML pour la page index.html

Sur XXXDEB81

Sur XXXDEB82

7.7.2 Exemple de code HTML pour la page achat.html

Sur XXXDEB81

Sur XXXDEB82

20