Contexte Haute Disponibilité de Squid

I ) Présentation
Dans la continuité de notre projet Squid, afin de garantir la continuité de service en cas de défaillance
matérielle ou logicielle, nous souhaitions apporter une solution de haute disponibilité.

a) Qu'est-ce que la Haute Disponibilité ?

 En cas de défaillance, un système informatique peut se retrouver paralysé. La haute

disponibilité consiste alors à la mise en place d'une infrastructure matérielle spécialisée,
généralement en se basant sur de la redondance matérielle. Est alors créé un cluster de
haute-disponibilité c’est-à-dire une grappe d'ordinateurs dont le but est d'assurer un service
en évitant au maximum les indisponibilités ;

Dans la pratique cela signifie que chaque élément du « cluster » (à partir de 2 serveurs) émet ainsi sur
le réseau des signes de vie de façon à ce que les autres éléments ayant la même adresse IP virtuelle,
prennent le relais lorsque l'élément défaillant (ou en maintenance) ne donne plus ces signes de vie.
 Il s'accompagne parfois par la mise en place de processus adaptés permettant de réduire les
erreurs, et d'accélérer la reprise et en cas d'erreur de prévoir une solution. Cette partie ne
sera pas abordée dans notre projet.

b) La solution Ucarp.

Après avoir comparé avec d'autres solutions : Heartbeat Keepalived, Pacemaker couplé avec
Corosync

Une recherche internet indique que la solution Pacemaker corosync bug à cause de Pacemaker peu
fiable . Qui plus est elle a des fichiers de configuration en XML peu intuitif d'usage . Keepalived a
une réputation de fiabilité mais est plus complexe a installer que ucarp.

Nous avons donc décidé d'utiliser Ucarp. Ucarp est une solution linux utilise le protocol CARP créé
initialement pour freebsd. C'est une alternative sécurisée et libre aux protocoles Virtual Router
Redundancy Protocol (VRRP), Hot Standby Router Protocol (HSRP) et Foundry Standby Router
Protocol (FSRP)

Il s'agit d'un système de « failover » automatique sécurisé, simple et efficace. C'est un logiciel libre
sous linux qui a bonne réputation et dispose de nombreux tutoriaux sur internet.

On l'a évoqué, Ucarp permet :

– d'adresser des IP virtuelles communes à plusieurs machines qui ont des fonctions identiques
sur le réseau.
– d'effectuer un "failover" ou basculement automatique en cas de problème sur la machine
principale dite "maître" vers la machine secondaire dite "esclave".

c) Besoins matériels
 - une machine principale

- une machine secondaire

- un câble croisé RJ45 entre les deux machines

- un switch

Schéma réseau du projet

II) Installation

En premier lieu il convient d'installet ucarp en faisant un apt-get install ucarp

1) Installation de la machine esclave

Pour avoir une machine esclave qui prenne le relais, il faut une deuxième machine.
Dans cette optique, nous avons monté une nouvelle machine physique de marque NEC. Nous
l'avons équipé de:
- 2 barrettes de 2 Go de RAM
- un disque dur de 350 Go

2) Installation de Debian
Pour avoir la même machine, nous avons monté un système d'exploitation Debian dessus.
Lors de l'installation, nous avons nommé la machine "slaveSquid".
Nous avons ensuite paramétré la machine en statique avec l'adresse IP 172.16.90.65

3) Installer et configurer Ucarp

Pour installer Ucarp, nous avons fait une installation similaire sur les deux machines (le
maître et l'esclave)
Dans un terminal, on se met en super-utilisateur puis on fait les mises à jour de Debian:
apt-get update && apt-get upgrade
Ensuite, on peut commencer l'installation d'Ucarp.
Il faut dépaqueter Ucarp:
 apt-get install ucarp

Capture de l''apt-get install

On crée un nouveau répertoire nommé interface

mkdir -p /etc/ucarp/interface
On crée le fichier contenant les paramètres généraux d'Ucarp
 nano /etc/default/ucarp
Dedans on y insère les lignes suivantes
fichier des paramètres généraux Ucarp

On sauvegarde puis on quitte

On crée le fichier d'interface pour l'adresse virtuelle

 nano /etc/ucarp/interface/ucarp0

fichier de configuration de l'adresse virtuelle

On crée un fichier de service de façon à pouvoir activer les adresses virtuelles simplement.
 nano /etc/init.d/ucarp

On enregistre puis on quitte

On doit rendre le script exécutable. On change donc les droits
chmod 744 /etc/init.d.ucarp
On peut lancer le service
 /etc/init.d/ucarp start
On vérifie si la configuration est bonne par un ifconfig
 ifconfig
4) La phase de test
Pour savoir si notre haute-disponibilité fonctionnait, nous avons procédé à plusieurs
tests:

a) un test de ping :
Nous avons pingué les machines pour savoir si elles communiquaient entre elles. Elles se
voient. Mais aussi à partir d'une machine cliente pour la même raison.

b) un test en débranchant le maître, puis l'esclave.

Lorsque le serveur esclave est débranché, si on va sur un site interdit par Squid, il est
bloqué. "Normal. C'est le premier projet !".
Nous avons débranché le maître (util1) et rebranché l'esclave (slaveSquid). Les sites qui
sont interdits par Squid sont interdit, les autre restent autorisés et se connecte à internet. La
haute-disponibilité a fonctionné.

IV-SECURITE PHYSIQUE
Dans l'optique de se prémunir des risques électriques de coupures brèves nous avons
mis en place un onduleur où nous avons branché les deux serveurs Squid, le poste Windows
physique, ainsi que le serveur ESXI.

C'est un EATON ellipse PRO 650

- Il préserve contre les risques de surtension électrique.
- Sa batterie permet de garder les PC allumer environs 9 minutes en charge complète. Ce qui
permet de ne avoir les ordinateurs qui se coupent brusquement mais aussi laisse assez de
temps pour que le courant soient rétabli.
Nous avons branché les deux serveurs Squid, l'ESXI et le poste client sur l'onduleur.