Optimisation de serveurs LAMP et problématique de scalabilité

Transcription

Optimisation de serveurs LAMP
et problématique de scalabilité
28 mars 2016
IUT Nancy-Charlemagne
Licence Professionnelle ASRALL
Avcar Osman, Baltic Husref, Champain Bastien
1
TABLE DES MATIÈRES
Table des matières
1 Introduction
1.1 Présentation du projet . . . . . . . . . . . . . . . . . . . .
1.1.1 Problématique . . . . . . . . . . . . . . . . . . . . .
1.1.2 Organisation . . . . . . . . . . . . . . . . . . . . .
1.2 Contexte de mise en place des optimisations (e-commerce)
1.2.1 Contexte du projet . . . . . . . . . . . . . . . . . .
1.2.2 Serveur LAMP . . . . . . . . . . . . . . . . . . . .
1.2.3 Description technique du serveur . . . . . . . . . .
1.2.4 Modules apache . . . . . . . . . . . . . . . . . . . .
1.2.5 Configuration réseau . . . . . . . . . . . . . . . . .
1.3 Tests de performance du serveur . . . . . . . . . . . . . . .
1.3.1 Disques Durs . . . . . . . . . . . . . . . . . . . . .
1.3.2 Réseau . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 L’optimisation de serveur . . . . . . . . . . . . . . .
1.4.2 L’importance d’une optimisation . . . . . . . . . .
2 Cahier des charges
2.1 Présentation du projet . . . . .
2.1.1 Objet du projet . . . . .
2.1.2 Composition de l’équipe
2.1.3 Délai . . . . . . . . . . .
2.2 Suivi du projet . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Optimisation du serveur Web
3.1 Environnement critique . . . . . . . . .
3.2 Site web de e-commerce . . . . . . . .
3.2.1 Implication . . . . . . . . . . .
3.2.2 Système de gestion des contenus
3.3 Activité et traffic sur un serveur web .
3.4 Préparation de la plateforme . . . . . .
3.4.1 Backup . . . . . . . . . . . . .
3.4.2 Plateforme de test . . . . . . .
3.5 Optimisation de la couche middleware
3.5.1 Optimisation Apache . . . . . .
3.5.2 Optimisation Mysql . . . . . . .
Avcar Baltic Champain
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Projet SCAL
Page 2/54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
4
5
5
6
8
9
10
10
10
11
12
12
13
.
.
.
.
.
14
14
14
14
15
15
.
.
.
.
.
.
.
.
.
.
.
15
15
16
16
16
17
17
17
17
18
18
27
28 mars 2016
TABLE DES MATIÈRES
3.5.3
3.5.4
3.5.5
3.5.6
Les logs de requêtes lentes . . .
Ne pas utiliser d’index . . . . .
L’utilisation des requêtes lentes
Défragmentation . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
30
30
4 Benchmarks
4.1 Outils de benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
31
5 Suivi d’activité
5.1 SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
33
6 Infrastructure de Haute disponibilité
6.1 Schéma de l’infrastructure . . . . . . . . . . . .
6.2 HAProxy . . . . . . . . . . . . . . . . . . . . .
6.3 Installation et configuration . . . . . . . . . . .
6.4 Configurations réseaux des serveurs . . . . . . .
6.5 Load Balancing . . . . . . . . . . . . . . . . . .
6.6 Configuration serveurs web . . . . . . . . . . . .
6.7 Test de la répartition de charge . . . . . . . . .
6.8 MariaDB . . . . . . . . . . . . . . . . . . . . . .
6.9 Gelra Cluster . . . . . . . . . . . . . . . . . . .
6.10 Heartbeat . . . . . . . . . . . . . . . . . . . . .
6.10.1 Installation et configuration d’Heartbeat
6.11 Installation MariaDB et Galera Cluster . . . . .
6.11.1 Configuration Galera Cluster . . . . . .
6.12 Test de la réplication . . . . . . . . . . . . . . .
34
34
34
35
35
37
40
41
41
41
42
42
43
43
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Conclusion
45
8 Remerciements
45
9 Annexes
46
Projet SCAL
Page 3/54
28 mars 2016
1 INTRODUCTION
1
1.1
1.1.1
Introduction
Présentation du projet
Problématique
Pour notre projet, nous avions comme objectif d’optimiser un serveur web hébergeant un
site d’e-commerce afin de le rendre, d’une part, plus réactif et fluide, et, d’autre part, de
permettre à un maximum de client de pouvoir se connecter simultanément sur le serveur web
sans que celui-ci ne surcharge. Nous avons dû mettre en place des benchmarks afin d’évaluer
les performances du serveur web et penser à la mise en place d’une infrastructure de haute
disponibilité permettant la scalabilité du serveur web. Afin de mener à bien notre projet, nous
avons du répondre à la problématique que nous posait le sujet : Comment optimiser une
plateforme de type LAMP dans un environnement critique type e-commerce ?
1.1.2
Organisation
Dates
Semaine du 25/01
Semaine du 01/02
Semaine
Semaine
Semaine
Semaine
Semaine
du
du
du
du
du
08/02
15/02
22/02
29/02
07/03
Semaine du 14/03
Semaine du 21/03
Objet(s)
Etude des solutions d’optimisations
Etudes des outils de benchmark et Récupération des données au niveau
du hardware
Mise en place de tests de benchmark
Mise en place d’optimisation au niveau du serveur web
Optimisation serveur web et serveur de base de données
Test de charge sur le serveur web et analyse des corrections à apporter
Mise en place de plateforme dédié au e-commerce et recherche sur une
mise en place d’un infrastructure de haute disponibilité
Mise en place d’une infrastructure de haute disponibilité et début de
rédaction du pré-rapport de projet
Finalisation du pré-rapport de projet
Figure 1 – Tableaux d’organisation du travail.
Il existe plusieurs façon d’arriver à la bonne optimisation d’un serveur web. Il nous a donc
fallut dans un premier temps, étudier les différentes solutions que l’on pouvait mettre en place
dans notre contexte d’environnement e-commerce. Par la suite, afin de pouvoir analyser les
performances du serveur web, nous avons récupérer diverses informations aussi bien au niveau du harware que du middleware. Une fois les données collectées, nous avons pu mettre en
place différents “stress test” afin d’analyser les performances du serveur web et ainsi trouver
Projet SCAL
Page 4/54
28 mars 2016
1 INTRODUCTION
les points faibles de celui-ci. Une fois cela effectué, nous avons procédés à la mise en place
d’optmisation du serveur web et du serveur de base de données afin d’améliorer les performance de ceux-ci et de répondre le mieux possible à notre problématque. Pour réussir notre
projet, il nous a aussi fallut nous pencher sur les domaines de la haute disponibilité pour les
plateformes web, les technologies qui existent pour gérer la répartition de charge et le gestion
de cache.
Nous devons également étudier les différentes solutions de benchmarks de plateformes
web existantes afin d’anticiper les évolutions de l’architecture proposée.
Nous aborderont également les notions de capacity planning et d’engagement des services
(SLA).
Afin d’optimiser au mieux notre temps de travail, nous avons décider de nous répartir
les tâches de façon équitables en fonction des préférances de chacun. Nous disposions d’un
serveur web où l’on pouvait mettre en place nos otpimisations et donc il était difficile pour le
groupe de travailler en même temps sur le serveur web. En effet, afin d’éviter que les erreurs
des uns impacte les autres, il nous a fallut faire un roulement au niveau de l’accès au serveur
web. Lorsqu’une personne avait accès au serveur web, les autres en profiter pour faire des
recherches sur les optimisations ou la résolution de problèmes liés aux optimisations.
1.2
1.2.1
Contexte de mise en place des optimisations (e-commerce)
Contexte du projet
Pour le projet, l’objectif est l’optimisation de serveur LAMP et problématique de scalabilité. Notre tuteur nous a mis à disposition un serveur web ayant un site avec un trafic réel,
le site est http ://www.trackmusik.fr.
Ce serveur web utilise l’ensemble de logiciel libre LAMP afin de mettre en place une solution complète permettant de construire un serveur de site web. De plus, le site web utilise
un système de gestion de contenu (CMS) afin de concevoir et de mettre à jour dynamiquement le site web.
Projet SCAL
Page 5/54
28 mars 2016
1 INTRODUCTION
Figure 2 – Capture d’écran du site Trackmusik
1.2.2
Serveur LAMP
LAMP est un ensemble de logiciels libres permettant la construction de serveur de sites
webs, d’applications métiers et de web services. Ainsi, grâce à ce type de solution, il sera
possible de mettre en place un serveur web optionnel rapidement et efficacement. Dans ce
type de solution, les différentes parties communiquent entre elles et sont directement liées.
Un changement sur une partie peut impacter directement une autre partie. Le gros avantage de ce type de serveur est que ses parties peuvent être changées en lieu et place d’autres
parties, par exemple, il est possible d’utiliser le language Perl ou lieu du PHP. Il est aussi possible de placer ces différentes partie sur plusieur machine afin d’assurer la haute disponibilité.
L signifie Linux. Il s’agit ici du système d’exploitation
dont le serveur sera basé. Cette partie fera en sorte de
gérer la gestion du hardware afin de répondre au mieux
à la couche software. Il existe d’autres variantes, comme
par exemple pour Windows ou MacOS. Pour notre projet,
Figure 3 – Logo Linux. notre serveur se base sur une distribution Debian, donc Linux.
Projet SCAL
Page 6/54
28 mars 2016
1 INTRODUCTION
A signifie Apache. Cette seconde lettre fait référence au
type de serveur HTTP utilisé. Le serveur web sera capable
d’interpréter les requêtes HTTP arrivant sur le port associé
au protocole HTTP (par défaut le port 80), et de fournir une
réponse avec ce même protocole. Dans notre cas il s’agit du
serveur Apache mais il est possible d’utiliser d’autre serveur
Figure 4 – Logo Apache. web, comme par exemple Nginx.
M signifie MySQL. Il s’agit ici du type de système de
gestion de bases de données. Ce genre de système va être
destiné à stocker et à partager des informations dans une
base de données, en garantissant la qualité, la pérennité et
la confidentialité des informations et le tout en cachant la
complexité des opérations. Les données du type, compte
utilisateur, achats effectués ou encore points de fidélités
Figure 5 – Logo MySQL. seront stockées et organisées dans des bases de données. Il
est aussi possible d’utiliser MariaDB ou en Postgre en lieu et
place de MySQL.
Figure 6 – Logo PHP.
P signifie PHP, Perl ou Python. Il s’agit du type de langauge script utilisé. Il va ainsi permettre la génération de
pages web dynamiques et la communication avec le serveur de
base de données. Comme toutes les parties, il est aussi possible d’utiliser différents languages comme le Perl ou encore
le Python.
Projet SCAL
Page 7/54
28 mars 2016
1 INTRODUCTION
1.2.3
Description technique du serveur
Système d’exploitation
Debian Jessie 8.3
Version noyau Linux
Version du système
Processeurs
3.16.7-ckt11-1+deb8u6
amd64 mais multiarch x86/x64
AMD Opteron™ 6338P (12 cœurs
x 2,3 GHz)
Mémoire vive
Disque dur
32 Go de RAM DDR3 ECC
2 x 2 To SATA
uname -a
cat /etc/debian_version
cat /etc/issue
cat /etc/proc/cpuinfo
cat /etc/proc/cpuinfo | grep processor | wc -l
free -t
fdisk -l /dev/sd*
Figure 7 – Description du serveur web.
Version Apache : 2.4.10
Commande
1
apachectl -V
Cela nous permet ainsi de savoir quelle version Apache est installé sur le serveur et ainsi nous
allons pouvoir nous référer à la bonne documentation Apache.
Version Mysql : 5.5.46
Commande
1
Mysql : >mysql -V
Connaitre le numéro de version de MySQL nous permettera d’appliquer les bonnes optimsations correspondant à la version.
Version PHP : 5.6.17-0+deb8u1
Commande
1
php -v
Le numéro de version de PHP nous permettera comme pour Apache et Mysql, se référer à la
bonne doc et appliquer les bonnes optimisations de la version.
Projet SCAL
Page 8/54
28 mars 2016
1 INTRODUCTION
Version Joomla : 3.4.8
1.2.4
1
Modules apache
apachectl –t –D DUMP_MODULES
core_module (static) so_odule (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
actions_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cache_module (shared)
cache_disk_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
expires_module (shared)
filter_module (shared)
headers_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
negotiation_module (shared)
pagespeed_module (shared)
php5_module (shared)
rewrite_module (shared)
setenvif_module (shared)
Projet SCAL
Page 9/54
28 mars 2016
1 INTRODUCTION
status_module (shared)
Grâce à cela nous savons quels modules Apache charge lors de son lancement. Ainsi nous
pouvons vérifier si tous les modules listés sont nécessaires et s’ils nécessitent une optimisation.
1.2.5
Configuration réseau
IPv4
IPv6
Masque
Passerelle
87.106.20.127
2001 :08D8 :087D :3100 :0000 :0000 :006B :D53D
FFFF :FFFF :FFFF :FFFF :0000 :0000 :0000 :0000
10.255.255.1
Figure 8 – Configuration eth0 du réseau.
1.3
Tests de performance du serveur
Afin d’avoir de savoir comment se comporte le serveur dans ces retranchements, nous
avons effectué certains tests. Cela nous permet ainsi d’obtenir des résultats de performance
que nous analyserons pour savoir si les différents matériels testés fonctionnent correctement
et s’il est nécessaire de changer de matériels ou non.
1.3.1
Disques Durs
Le serveur possède deux disques durs identiques de 2 To chacun. Ici nous allons tester
les performances en lecture et en écriture des disques durs pour savoir s’ils n’impactent pas
les performances du serveur. En effet, des disques durs avec des faibles taux d’écriture et de
lecture ralentiraient fortement le serveur et le traitement des requêtes des clients. Il est donc
nécessaire d’avoir des disques durs dotés de bonnes performances.
Lecture
Pour tester les performance en lecture on installe le logiciel hdparm qui va nous permettre
d’effectuer le test.
1
hdparm -t -T /dev/sd*
L’option “-t” permet d’effectuer des tests en lecture du disque dur et l’option “-T” permet
d’effectuer des tests en lecture des caches. Pour des résultats plus significatifs il aurait fallu
effectuer ses tests sur un système inactif (sans processus actifs). Nous n’avons pas pu réaliser
Projet SCAL
Page 10/54
28 mars 2016
1 INTRODUCTION
les tests dans les meilleures conditions, néanmoins cela donne une bonne idée de la performance en lecture. Nous avons effectué ses tests 3 fois par disque afin d’avoir une moyenne.
Résultat :
Les performances en lecture en moyenne sont de 138,653 MB/sec pour sda et 121,8 MB/sec
pour sdb. Ces performances sont bonnes et permettent donc un accès en lecture rapide et
donc cela permet de traiter les données rapidement.
Ecriture
Une fois la lecture vérifiée, il nous faut regarder du côté de l’écriture des disques durs. Une
mauvaise écriture impacterait le temps de traitement des requêtes clients et ainsi pourrait
faire chuter le chiffre d’affaires de l’entreprise. Pour effectuer ce test on utilise la commande
“dd”. Cette commande permet d’écrire sur des périphériques tels que des disques durs.
1
dd if=/dev/zero of=/tmp/test.data bs=1M count=1024 conv=fdatasync
Pour tester les performances en écriture des disques nous avons simulés l’écriture d’un fichier
de 1,1 GB sur chacun des disques et donc d’écrire des blocs de la taille de 1 MB 1024 fois.
Résultat :
Nous avons effectués les tests 7 fois de suite afin d’obtenir une moyenne nous permettant
d’avoir une idée de la performance d’écriture des disques. Pour sda, nous avons une moyenne
de 995 MB/s et 1,06 GB/s pour sdb. Ces performances nous permettent d’affirmer qu’il
s’agit de disques durs performants en écriture et donc idéaux pour un serveur de e-commerce
demandant souvent la sollicitation d’un disque dur.
1.3.2
Réseau
Les performances réseaux sont primordiales pour qu’un serveur web puisse communiquer
avec les clients rapidement et en grande quantité. En effet, quand bien même le serveur
web est optimisé, s’il ne dispose pas d’une bande passante suffisamment conséquente pour
accueillir un grand nombre de client simultanément, celui-ci sera toujours bridé par sa bande
passante qui nous pourra pas accueillir un trop grand nombre de connexions simultannées
dans son canal.
Pour simuler les performances du serveur dédié, nous avons utilisé l’application “iperf”. Iperf
doit être lancé sur deux machines se trouvant de part et d’autre du réseau à tester. La
première machine lance Iperf en "mode serveur" (avec l’option -s), la seconde en "mode
client" (option -c). Par défaut le test réseau se fait en utilisant le protocole TCP (mais il est
Projet SCAL
Page 11/54
28 mars 2016
1 INTRODUCTION
également possible d’utiliser le mode UDP avec l’option -u).
Commande serveur :
1
iperf -s
Commande client :
1
iperf -c 87.106.20.127 (Adresse IP du serveur)
Résultats :
1
2
[ ID] Interval
[ 3] 0.0-10.1 sec
Transfer
12.0 MBytes
Bandwidth
9.92 Mbits/sec
Les tests éffectué ont été très faibles et il s’agit là d’un problème assez conséquent. En effet,
s’il l’entreprise souhaite augmenter sa fréquentation, elle sera limitée par sa connexion réseau
qui ne lui permettera pas d’accepter tout le monde.
1.4
1.4.1
Optimisation
L’optimisation de serveur
L’optimisation d’un serveur consiste en amélioration des différentes couches dont dispose
le serveur. L’optimisation va avoir pour but général d’améliorer les performances du serveur
pour ainsi permettre au serveur d’effectuer un plus grand nombre de tâches dans un temps
plus réduit. Comme dit précédement, il existe différentes couches au niveau du serveur, la
couche hardware, qui va centraliser les composants physique du serveur, c’est-à-dire, les processeurs, les disques durs, la mémoire vive ou encore la carte réseau. L’optimisation pour cette
couche va consister au remplacement des composants pour de nouveaux plus performants.
La couche qui se trouve juste au dessus de la couche hardware et la couche du système d’exploitation. Celle-ci se compose du système d’exploitation et son optimisation se fait, d’une
part, par le choix d’un système d’exploitation qui va permettre de gèrer les composants de la
couche hardware de manière la plus optimale, et, d’autre part, par la bonne configuration des
composants hardware pour ainsi permettre une communication optimale des composants.
La couche suivante se nomme middleware et elle est composée de tous les paquets du système d’exploitation permettant de mettre en place l’application web souhaitée. Par exemple,
pour notre cas, celle-ci sera composée du serveur web Apache, du serveur de base de donnée
Mysql ou encore du PHP. Ici l’optimisation consistera en la configuration du fonctionnement
ce ceux-ci pour qu’ils puissent fonctionner de façon optimale grâce aux composants que la
Projet SCAL
Page 12/54
28 mars 2016
1 INTRODUCTION
couche hardware lui propose. Ainsi dans notre cas, en optimisant le serveur LAMP, les performances du serveur augmenteront et les sites webs hébergés sur le serveur pourront recevoir
plus de clients et la navigation sera plus fluide.
La dernière couche est la couche application qui se compose de l’application web ou du site
web en lui même. L’optimisation dans ce cas va consister en l’amélioration du code source
de l’applciation web pour éviter les traitements lourds et inutiles.
Figure 9 – Schéma des couches d’un serveur
1.4.2
L’importance d’une optimisation
La performance d’un serveur est importante, elle peut influencer le référencement d’un site
sur un moteur de recherche, par exemple le temps de réponse du serveur est pris en compte,
la fluidité d’un site web et la vitesse de chargement sont aussi prises en compte. Néanmoins
Projet SCAL
Page 13/54
28 mars 2016
2 CAHIER DES CHARGES
l’optimisation n’est pas forcement nécéssaire pour tout le cas de figure. En effet, une personnes
ayant un site web dans son réseau local pour partager des choses avec son entourage proche n’a
pas vraiment besoin d’une optimisation. L’optimisation s’adresse surtout aux sites web ayant
un grand nombre de visiteurs par jours ou souhaitant acquérir un grand nombre de visiteur.
Les sites webs ayant besoin d’optimisation seront plus dans cette optique. Par exemple, les
sites marchand de e-commerce, les sites communautaires ou bien les réseaux sociaux ont un
grand intêret à ce que leur plateforme web soit optimisée. Si un utilisateur attend plusieurs
secondes pour le chargement d’une page, celui-ci va quitter le site web en question et la
société dérrière perdra un potentiel client.
2
Cahier des charges
2.1
2.1.1
Présentation du projet
Objet du projet
Le projet consiste à étudier l’état de l’art en matière de disponibilité des plateformes
web, des technologies qui existent pour gérer la répartition de charge, la gestion du cache...
Il faudra proposer une architecture type qui répondra aux exigences de haute disponibilité
en environnement critique. Cette architecture devra être facilement scalable tout en restant
simple à administrer et à faire évoluer. Dans un second temps, il faudra étudier les solutions
de benchmarks de plateformes web qui existent sur le marché (ab, dareboost,...) pour pouvoir
anticiper les évolutions de l’architecture proposée et valider les performances attendues. Les
étudiants approfondiront durant ce projet leurs connaissances sur les architectures à haute
disponibilité et sur comment les dimensionner par rapport à des besoins précis. Ils aborderont
également les notions de capacity planning et d’engagement de services (SLA).
2.1.2
Composition de l’équipe
L’équipe est composée des étudiants suivants :
- Avcar Osman
- Baltic Husref
- Champain Bastien
Le tuteur est Yohan Parent.
Projet SCAL
Page 14/54
28 mars 2016
3 OPTIMISATION DU SERVEUR WEB
2.1.3
Délai
Nous avons commencé le projet le 25 Janvier 2016, et le rapport final sera à rendre pour
le 28 Mars 2016.
2.2
Suivi du projet
Pour le suivi du projet, nous renseignons à chaque fin de séance ce que l’on a fait sur
la page http ://suivi-projet-asrall.iutnc.univ-lorraine.fr/. Nous communiquons tous les jours
entre nous, et nous envoyons fréquemment des mails au tuteur. Chaque vendredi nous faisons
une réunion avec le tuteur afin de voir où on en est, et de lui poser des questions sur certains
points.
3
Optimisation du serveur Web
Nous allons donc devoir optimiser le serveur web hébergeant le site de e-commerce, TrackMusik. Pour cela nous allons mettre en application des optimisation sur la partie middleware
et nous analyserons les différents changements qu’il serait possible d’effectuer sur la couche
hardware et la couche OS. Nous excluons ici la couche applicative car celle-ci est plus de la
responsabilité du développeur que de l’administrateur système.
3.1
Environnement critique
Un environnement critique est un environnement où une panne, par exemple un serveur
qui tombe, aura de lourdes conséquences pour l’entreprise.
Dans notre cas ici, nous somme dans un environnement critique car, d’une part nous travaillons directement en production et donc cela peut impacter directement le client souhaitant
naviguer sur le site web. D’autre part, c’est un environnement critique car le site web est un
site de e-commerce générant des revenus financiers et donc cela met en place un gros enjeu
pour l’entreprise derrière le site web. En effet en cas de panne, et d’indisponibilité du serveur
web, l’entreprise risque de perdre des clients et les clients ne peuvent pas acheter sur le site.
Cela entraine donc une grosse perte d’argent pour l’entreprise tant que la panne n’est pas
résolue.
Projet SCAL
Page 15/54
28 mars 2016
3.2
Site web de e-commerce
Un site de e-commerce est un plateforme web permettant d’acquérir un bien ou service
en échange d’une somme d’argent. Des sites comme Amazon.com ou encore ebay.com sont
des sites de e-commerce.
3.2.1
Implication
Dans notre contexte nous devons optimiser un site de e-commerce et cela implique plusieurs choses. En effet, il est très important pour un site de e-commerce d’être au maximum
optimisé afin d’avoir de la visibilité et de la sécurité. Plus le site de e-commerce sera optimisé, plus celui-ci disposera d’un meilleur référencement web et sera plus fluide pour ainsi
augmenter sa clientèle.
Il est aussi nécéssaire de faire attention lors des différentes optimisations. En effet, un site de
e-commerce nécéssite une certaine sécurité étant donné que des informations bancaires sont
en transit sur le site. Il est donc nécéssaire de vérifier si certaines optimisations n’ouvrent pas
des failles de sécurité. De plus, il est aussi necéssaire de faire attention à ce qu’une optimisation n’entrave pas le bon fonctionnement du site web car cela pourrait avoir des répercutions
directs sur la clientèle.
3.2.2
Système de gestion des contenus
Il est souvent difficile et fastidieux de mettre en place un site de e-commerce codé en
dur. On peut donc passer par un sytème de gestion des contenus (CMS) spécialisé dans le
e-commerce. Le premier avantage est que cela facilite grandement la mise à jour du site web
et cela permet donc aussi à des personnes n’ayant que peu de connaissances informatique à
gèrer son contenu facilement. Le second avantage est le coût de développement. En effet, cela
réduit drastiquement le coût de développement par rapport à un site codé en dur. Le dernier
avantage est que cela permet de gestionner efficacement son contenu.
Joomla 3.4.8
Comme dit auparavant, nous utilisons le CMS joomla pour le site de e-commerce TrackMusik.
Ce CMS gère très bien les differents contenus car il s’agit là de son principale argument.
Néanmoins pour ce qui est d’un site de e-commerce, Joomla n’est peut être pas la meilleure
solution comme CMS car ce n’est pas sa spécialité première. Afin de pouvoir créer un boutique
de e-commerce avec Joomla, il faut d’abord rajouter des modules d’extensions supplémentaire
comme par exemple, VirtueMart.
Cela ne rentre donc pas dans notre optimique d’optimisation de platefrome web. Pour palier
Projet SCAL
Page 16/54
28 mars 2016
à cela on peut par exemple se tourner vers d’autres CMS spécialisés dans le e-commerce,
Prestashop est une bonne alternative.
Autre solution : Prestashop
L’aternative qui nous a semblé la plus crédible est Prestashop. En effet, comparé à Joomla,
ce CMS est spécilisé dans le e-commerce et permet de faire de la gestion de contenus lié au
e-commerce de façon plus otpimale et native. En effet, ce CMS permet de mettre tout un tas
de choses lié au commerce. Par exemple, il est possible de mettre en place des promotions
et des bons de réduction, de faire des catégories ou encore de mettre en place un système de
point de fidélité.
Nous avons testé les deux CMS afin de voir lequel s’adaptait le mieux au e-commerce. Nous
avons donc installé les deux CMS sur deux machines virtuelles identiques disposant d’un
serveur web Apache et nous avons constaté que Prestashop était bien plus adapté pour le
e-commerce grâce à toutes ces fonctions bien pensées et permettant la mise en place d’une
boutique en ligne rapidement et facilement. Ce CMS à était pensé pour que son administrateur ait la plus grande facilité à s’y retrouver et à gèrer son contenu. Il est donc préférable
pour notre contexte d’utiliser un CMS le plus nativement possible dédié au e-commerce pour
ainsi une correlation optimale avec notre objectif.
3.3
Activité et traffic sur un serveur web
3.4
Préparation de la plateforme
3.4.1
Backup
Avant d’effectuer toutes optimisations du serveur LAMP, il est préférable d’effectuer systématiquement une copie original du fichier que l’on souhaite modifier afin que si une erreur
survient, il y est toujours un fichier de backup disponible pour faire fonctionner le site. Le
backup s’effectue simple avec la commande cp :
1
sudo cp FICHIER_CONF FICHIER_CONF.BACKUP-DATE
3.4.2
Plateforme de test
Lors d’une optimsation d’un serveur web, il peut être intéréssant de mettre en place un
plateforme de test afin dans un premier temps d’effectuer les optimisations sur la plateforme
et ainsi voir les répèrecutions que cela engendre tant bien au niveau des erreurs que de
l’optimisation. Ainsi avec une plateforme de test on pourra éviter les conflits dû on différentes
Projet SCAL
Page 17/54
28 mars 2016
modifications pour l’optimisation et qui pourrait ouvrir des failles ou bien ralentir le site web.
De plus cela permet aussi d’éviter de rendre le site inaccessible à cause de relancement de
service de serveur et ainsi aussi éviter la perte de données qui pourrait être très dommageable
dans un environnement de e-commerce.
3.5
Optimisation de la couche middleware
Dans la couche middleware, il existe deux composantes à optimiser dans notre contexte
de e-commerce. Il s’agit en fait de deux des composantes du serveur LAMP, à savoir, le
serveur Apache via l’installation et la configuration des modules et le serveur MySQL avec
par exemple l’optimisation de la configuration ou encore l’utilisation du cache. Il est aussi
possible d’optimiser le PHP mais cela touche à la couche applicative qui n’est pas abordée
dans le projet.
3.5.1
Optimisation Apache
L’optimisation d’Apache va consister en la mise en place de différents modules et/ou de
reglès de configurations. Etant donné qu’Apache est un serveur web modulaire, il existe une
grande liste d’optimisation possible sur Apache.
Module Apache
Les modules sont donc des fragements de code particuliers que l’on peut greffer de différentes
façons au binaire représentant le serveur web Apache. Nous verrons ici seulement l’installation
de module via le manager de paquet apt-get.
Prefork
Il s’agit d’un module multi-processus (MPM) qui implémente un serveur web avec démarrage
anticipé de processus. C’est ce module MPM qui est nativement installé par Apache.
Un processus de contrôle unique a pour tâche de lancer les processus enfants qui attendent
les connexions et les traitent au fur et à mesure qu’elles arrivent. Apache essaie toujours
de maintenir plusieurs processus serveurs inactifs ou en réserve, afin de pouvoir traiter les
requêtes entrantes. De cette façon, les clients n’ont pas besoin d’attendre le démarrage d’un
nouveau processus enfant pour que leurs requêtes puissent être traitées.
Il s’agit du MPM le plus approprié si l’on souhaite isoler les requêtes les unes des autres, de
façon à ce qu’un problèmes concernant un requête n’affecte pas les autres.
Dans notre optique d’optimisation de serveur web, il ne s’agit pas forcement du module le
plus performant dans le traitement de plusieures requêtes successives. Néanmoins c’est celuici que l’on a décidé de garder faute de problème de compatibilité avec l’autre module MPM.
Projet SCAL
Page 18/54
28 mars 2016
Il existe plusieures façon de mettre en place une configuration pour le module MPM prefork.
Nous utiliserons ici une conditionnelle placée dans le fichier de configuration générale de
Apache, apache.conf :
1
2
3
4
5
6
7
8
9
10
<IfModule mpm_prefork_module>
MaxRequestWorkers 700
ServerLimit 700
StartServers 4
MinSpareServers 5
MaxSpareServers 10
MaxConnectionsPerChild 1000
</IfModule>
Ce module MPM dispose de plusieurs directives permettant la configuration du modules
et ainsi modifier son comportement.
• La directive MaxRequestWorkers permet de fixer le nombre maximum de requêtes
pouvant être traitées simultanément. Si la limite MaxRequestWorkers est atteinte, toute
tentative de connexion sera normalement mise dans une file d’attente.
• ServerLimit définit le nombre maximum que l’on peut affecter à la directive MaxRequestWorkers.
• StartServers permet de définir le nombre de processus enfants du serveur créés au
démarrage.
• La directive MinSpareServers permet de définir le nombre minimum désiré de processus
serveurs enfants inactifs.
• La directive MaxSpareServers permet de définir le nombre maximum souhaité de processus serveurs enfants inactifs.
• La directive MaxConnectionsPerChild permet de définir le nombre maximum de connexions
qu’un processus enfant va pouvoir traiter au cours de son fonctionnement.
Worker
Ce module multi-processus (MPM) implémente un serveur hybride multi-processus multithread. En utilisant les threads pour servir les requêtes, il peut en traiter un grand nombre
tout en consommant moins de ressources qu’un serveur à base de processus. Cependant, il
Projet SCAL
Page 19/54
28 mars 2016
conserve une grande partie de la stabilité d’un serveur à base de processus en maintenant
plusieurs processus disponibles, chacun de ces derniers possédant de nombreux threads.
Un processus de contrôle unique (le parent) a pour tâche de lancer les processus enfants.
Chaque processus enfant crée un nombre fixe de threads serveurs selon la valeur de la directive ThreadsPerChild, ainsi qu’un thread chargé d’attendre les connexions et de les passer à
un thread serveur pour traitement au fur et à mesure de leur arrivée.
Le principal problème auquel on se heurte, c’est le type d’installation standard d’un serveur web Apache avec PHP, qui consiste à brancher PHP en tant que module Apache. De
cette manière, les deux compères se retrouvent mariés et indissociables, mais ce n’est pas sans
inconvénient. En effet, PHP (ou plutôt ses nombreuses librairies) n’étant pas threadsafe, il
est indispensable d’utiliser le mode prefork-mpm d’Apache 2.4, l’évitant d’utiliser des threads
séparés en forkant ses processus à la place.
Pour palier à ce problème nous allons devoir avoir recours au FastCGi et à PHP-FPM.
FastCGI
FastCGI est une technique permettant la communication entre un serveur HTTP et un
logiciel indépendant. C’est-à-dire, c’est une évolution du vieux protocole CGI, qui offre notamment la possibilité de recycler les processus et donc d’éviter d’avoir à les réinitialiser à
chaque demande.
Nous utiliserons le module Apache mod_fastcgi qui offre la possibilité de définir un Process Manager externe. Ces modules permettent donc de faire le pont entre Apache et PHP
en lançant des processus (ou workers) PHP et de les recycler au besoin, sans pour autant que
PHP soit intégré à Apache. Ils ont donc 2 rôles :
• Passer les requêtes demandant une interprétation depuis le serveur vers un worker PHP.
• Gérer les workers, leur nombre et leur recyclage.
Ainsi on peut passer en mode worker-mpm, bien plus efficace.
PHP-FPM
FastCGI Process Manager (PHP-FPM) aide à réduire l’addition des ressources système utilisées en forçant le serveur à agir comme un proxy et à ne passer que les fichiers portant
l’extension .php à PHP-FPM.
Installation
Malheureseument nous n’avons pas pu mettre en place ce module car celui-ci rentrait avec
un conflit d’incompatibilité avec le module de recherche du CMS Joomla. Nous avons essayé
Projet SCAL
Page 20/54
28 mars 2016
de changer de module mais aucun ne fonctionnait comme convenu. Il s’agit d’un erreur CallStack et d’après nos recherches celui-ci viendrait de la mauvaise interprétation du code php
par FastCGI et PHP-FPM. Néanmoins nous avons quand même effectué des tests afin de
voir le potentiel d’optimisation et celui-ci est assez important. En effet nous avons réussi à
passer 950 personnes simultanément. Voir fichier Test Charge Compression Expire Worker
dans l’Annexe.
Compression gzip
Introduction
Ce qui est intéressant avec la compression, c’est quelle va permettre d’optimiser le site web
sur plusieurs point intéréssants. Tout d’abord envers la bande passante, en effet, comme les
données renvoyées sont moins importante, cela va réduire la bande passante et ainsi permettre
d’envoyer plus de requêtes vers les clients. Ensuite, cela un impact sur les performance du
serveur web. Les données seront moins longues à être envoyées et donc plus rapide à être reçu
par le client. Pour finir, le référencement. En effet, les moteurs de recherche comme google
ou encore yahoo attribuent une note aux sites référencés qui permet de positionner le site
web en fonction des résultats de recherche. Cette note peut être améliorer, si le site possède
une compression gzip sur ses pages. Il donc intéréssant d’un point de vue visibilité d’activer
la compression.
Fonctionnement
La compression des données est fait sur le serveur hébergeur du site. Les données compressées transitent ensuite par le réseau via HTTP(port 80) et ensuite le navigateur web du
client décompresse les données avant de les interpréter.
Optimisation
L’optimisation est gérée par le module deflate. Il est possible d’optimiser un serveur soit, via
le fichier .htaccess, via le fichier de configuration d’apache, apache.conf, ou, via le fichier de
configuration mod_deflate.conf. Nous nous attaderons sur cette troisième solution. Pour
débuter, nous allons d’abord activer mod_deflate et mod_headers. Ce dernier module
va fournir des directives permettant de contrôler et de modifier les en-têtes de requêtes.
1
2
sudo a2enmod deflate
sudo a2enmod headers
Projet SCAL
Page 21/54
28 mars 2016
Par la suite il va nous falloir modifier le fichier de configuration de mod_deflate, /etc/apache2/modsavailable/deflate.conf, afin d’optimiser la compression. Voir le fichier de configuration en annexe.
Une fois le fichier de configuration modifié, il nous suffit de redémmarrer Apache afin qu’il
prenne en compte la configuration.
1
sudo service apache2 restart
Test
En effectuant un test avec ab, on s’apercoit que le temps par requête est passé de 42 à
36 ms. Ce qui nous a permis d’optimiser le temps de le nombre de requête par second. Quand
au nombre de connexion simultanées, il a aussi été augmenté. Nous sommes passés de 200 à
250. Voir les fichiers Test Charge Compression et Test Charge en Annexe.
Temps d’expiration Expires
Introduction
Le mod_expires permet de contrôler le temps d’expiration d’un fichier récupéré par le
visiteur lors de la visite d’une page web en modifiant l’en-tête HTTP Expires. Cette entête
défini auprès du navigateur client le temps de validité et de persistence du document, lui
indiquant combien de temps il est souhaitable qu’il le conserve dans son cache local. Ainsi
en configurant correctement ces directives, cela permet d’abaisser le nombre de requêtes sur
le serveur. En effet, le client privilégiera son cache lors du rechargement d’un document qui
n’est pas considéré comme expiré. De plus cela permettra aussi au client une navigation plus
fluide.
Fonctionnement
Le client va récupérer des données via le serveur. Si ces mêmes données sont appelées de
nouveau et que le temps expiration de l’en-tête HTTP Expires n’est pas dépassé, alors les
données seront récupérées via le cache du client et non en refaisant une requête au serveur
de données. Si l’entête est expiré alors les données seront demandées de nouveau au serveur
de données.
Optimisation
La configuration de l’entête HTTP Expires se fait via le module mod_expires. Ainsi comme
Projet SCAL
Page 22/54
28 mars 2016
pour la compression gzip, il est possible de configurer via le fichier .htaccess afin de le définir
sur un répertoire donnée, soit via la configuration général avec le fichier apache.conf, ou,
soit via le fichier de configuration expires.conf. Nous allons ici, continuer la configuration
via cette troisième option. Mais avant la configuration, il faut s’assurer que le module est
bien activé.
1
sudo a2enmod expires
Ensuite, si le fichier de configuration, /etc/apache2/mods-available/expires.conf, n’existe pas,
il faut alors le créer. Sinon il suffit d’ajouter les lignes suivantes au fichier de configuration.
Cela permettra d’optimiser de façon intelligente la gestion du cache local du client. Voir le
fichier de configuration en annexe. Une fois le fichier de configuration modifié, il nous suffit
de redémmarrer Apache afin qu’il prenne en compte la configuration.
1
sudo service apache2 restart
Test
Après avoir optimisé les dates d’expiration. On peut aisement passer à 300 connexions simultannées. Voir le fichier Test Charge Compression Expires en Annexe.
Xcache PHP5
Introduction
XCache est un outil permettant de mettre en cache (en mémoire vive) le résultat de la
compilation des fichiers PHP. Cela entraine bien évidemment un gain en performance (en
terme de CPU et d’I/O). Il est possible de l’installer via le paque suivant :
1
sudo apt-get install php5-xcache
Fonctionnement
Lorsque l’on fait une requête sur une page php, le serveur web, via une librairie dédiée
au service de pages php récupère le code de la page, le fichier, et le compile sous forme de
bytecode (code binaire). C’est ensuite ce bytecode qui est exécuté pour générer le texte au
format HTML qui sera ensuite envoyé au client. Lorsqu’il n’y a qu’un ou deux fichiers php, et
peu de visites cette étape ne prend pas longtemps et donc cela ne se voit pas, mais dans notre
Projet SCAL
Page 23/54
28 mars 2016
contexte, il existe pas mal de fichiers php, qui entrent en jeu pour servir une seule page... et
cela prend du temps. Il est donc assez judicieux de vouloir sauvegarder en mémoire le résultat
de la compilation de ces fichiers php, de manière à les exécuter plus vite, dès réception de la
requète. C’est ce que fait Xcache.
Optimisation
Tout est préparé par default et l’on peut vérifier que l’outil est bien installé via un phpinfo().
Les seules valeurs intéressantes à modifier dans le fichier de configuration sont la valeur
xcache.size et la valeur de xcache.count. Les direcives se trouve dans le fichier /etc/php5/conf.d.xcache.ini
1
2
xcache.size =
xcache.count =
128M
12
Xcache.size va permettre de spécifier la quantité complète de mémoire utilisable. Nous fixons
à 128M car nous disposons de beaucoup de mémoire vive. Xcache.count permet de préciser
le nombre de processeurs sur le serveur. Ainsi le cache va être divisé pour une meilleur
optimisation des accès mémoire lors de la recherche du code précompilé d’un fichier PHP.
Etags
ETag sert à vérifier si un document a été mis à jour ou pas depuis la dernière fois. Un
identifiant unique pour chaque URL est transmis par requête HTTP. Le navigateur va demander au serveur si le document a été modifié. Le navigateur et le serveur vont comparer
leur identifiant. Si le document n’a pas été modifié, le serveur répondra "304 Not Modified",
et le navigateur utilisera son cache pour afficher le document. Si le document a été modifié,
le document sera à nouveau téléchargé. Le problème d’ETag est que si le site web est géré
par un cluster de serveurs, l’ETag peut être différent même si les documents ont tous été
mis à jour à la même date. Le navigateur risque donc de télécharger le document, et donc
d’utiliser de la bande passante, alors que sa version dans le cache est à jour. Voilà pourquoi
on va désactiver ETag. On rajoute donc dans le fichier de configuration général d’Apache,
apache.conf :
1
2
Header unset ETag
FileETag none
Timeout
Timeout définit le nombre de secondes entre l’envoie et la récupération maximum. Si le
Projet SCAL
Page 24/54
28 mars 2016
Timeout est trop élevé, cela forcera les visiteurs à attendre en ligne le chargement. Si le Timeout est trop faible, cela provoquera un script qui terminera plus tôt que prévu l’échange.
100 est une valeur raisonnable pour un Virtual Private Servers ou heavily loaded dedicated
servers. Pour un loaded didicated server normal, il faut laisser par défaut 300, ce qui est
suffisant. On modifie donc dans le fichier de configuration général d’Apache, apache.conf :
1
Timeout 100
KeepAlive
On laisse KeepAlive sur On afin de permettre de réutiliser une connexion ouverte pour
envoyer plusieurs documents au même client. Le navigateur va pouvoir télécharger les images
d’une page en économisant l’ouverture de connexions successives. En cas d’attaque et de
trafics trop lents importants, il est recommandé de désactiver cette fonctionnalité, juste le
temps de rétablir la situation.
KeepAliveTimeout
KeepAliveTimeout va définir la durée en secondes pendant laquelle le serveur attendra, après
avoir servi une demande, la demande suivante, avant d’interrompre la connexion. On passe
de la valeur par défaut 5 à 2.
HostnameLookups
Habituellement le serveur web va enregistrer le nom complet de chaque client, dans le fichier access.log Cette résolution de nom prend du temps. En désactivant cette option, ce qui
est le cas par défaut, on évite cette perte de temps et le serveur peur donc avoir un trafic
plus important.
Serveur Memcached
Introduction
Memcached est un serveur de cache permettant d’accélérer les requêtes des clients. Il permet
de garder en mémoire vive des portions de données, un accès plus rapide et soulager les accès
Projet SCAL
Page 25/54
28 mars 2016
à la base de données. Il peut également être utilisé pour une meilleure efficacité en complément du module ModPageSpeed. On traitera de ce dernier juste après. Ce module est utilisé
par de nombreux sites très fréquenté tel que, Youtube, Facebook ou encore Tweeter. Afin de
faire fonctionner Memcached, il est nécéssaire d’installer les paquets suivants :
1
2
sudo apt-get install memcached php5-memcached libmemcached-tools
sudo apt-get install php5-dev php-pear make
Ainsi dans le paquet memcached on retrouve toutes les librairies nécéssaires à son fonctionnement. Le paquet php5-memcached contient tout ce qui va permettre pour communiquer avec le serveur Memcached en se servant de la librairie libmemcached. Enfin le paquet
libmemcached-tools permettra la communication via une ligne de commande avec le serveur
Memcached.
Fonctionnement
Memcached fonction comme un serveur, au sens applicatif du terme. C’est à dire, comme
pour une base de donnée, les applications adressent des requêtes à memcached, qui leur
répond. Il fonctionne à la manière d’une table de hash, c’est à dire une correspondance clévaleur. De plus, memcached dispose d’un caractère distribué. C’est à dire que l’on peut lancer
autant d’instances de memcached, sur autant de serveurs que l’on veut, elles se repartiront
le travail et le stockage de manière totatlement automatique et transparente. Chaque paire
de clé-valeur ne sera stockée que dans une seule instance de memcached.
Optimisation
Une fois tous les paquets installés. Il est nécéssaire de vérifier si dans le fichier, /etc/php5/modsavailable/memcache.ini, ces deux lignes sont bien présentes. Sinon il faut les rajouter.
1
-m 8192
Cette ligne permet d’activer l’extension memcache.so.
Il ne s’agit pas vraiment d’optimisation dans ce fichier mais plus de vérification pour le
meilleur focntionnement de memcached.
Par la suite, il va nous falloir modifier la mémoire de memcached. Par défaut elle est de
64MB et il est possible de l’augmenter jusqu’à 1/4 de la RAM total. La mémoire est définit
via l’option "-m" dans le fichier de configuration de memcached, /etc/memcached.conf.
1
extension=memcache.so
Projet SCAL
Page 26/54
28 mars 2016
On décide de mettre cette valeur à 1/4 de la ram total du serveur c’est à dire 8192 pour notre
cas. Puisque que nous disposons de beaucoup de mémoire vive.
Pour finir, il est nécéssaire de redémarrer le service memcached afin qu’il prenne en compte
la nouvelle configuration
1
service memcached restart
On peut voir si le serveur de cache fonction bien via cette commande :
1
sudo netstat -tap | grep memcache
On devrait y retrouver la ligne suivant nous confirmant l’activité du port 11211 (port par
défaut de memcached).
1
tcp
0
0 localhost.localdo:11211 *:*
LISTEN
7013/memcached
Test
Lors de notre projet nous n’avons pas réussi à mettre en place le serveur memcached car
celui-ci rentrer en conflit avec Joomla pour une raison qui nous a été inconnue. Cependant
lors de mise place sur une plateforme de test, nous avons ressentie une certaines amélioration.
3.5.2
Optimisation Mysql
Pour l’optimisation de MySQL nous avons utilisé un outil qui s’appelle MySQLTuner.
Il s’agit en fait d’un script écrit en Perl qui va analyser le serveur MySQL et proposer des
améliorations et des recommandations à faire afin de l’optimiser.
On télécharge le script et on lui donne les droits d’exécution puis on l’exécute :
1
2
3
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
chmod +x mysqltuner.pl
./mysqlturner.pl
(Voir les résultats dans l’annexe)
Après l’analyse faite du résultat obtenu par le script, on constate qu’il y a quelques modifications à faire. Dans les recommandations il est indiqué d’activer les logs de requêtes
lentes, les requêtes qui n’utilisent pas d’index et de défragmenter les tables.
Projet SCAL
Page 27/54
28 mars 2016
3.5.3
Les logs de requêtes lentes
Le but de ce fichier de log sera de recenser requêtes lentes, c’est-à-dire toutes les requêtes
qui auront un temps d’exécution supérieur à la valeur de la variable « long-query-time ».
Ensuite les analyser et traiter.
Pour activer les logs de requêtes lentes on rajoute la ligne suivante dans le fichier /etc/mysql/my.cnf en précisant le chemin du fichier de logs créé :
1
slow\_query\_log\_file = /var/log/mysql/mysql-slow.log
La ligne suivante consiste, comme dit précédemment, à définir un temps (en seconde)
pour qualifier une requête de « requête lente ».
1
long\_query\_time = 3
Toutes les requêtes qui mettrons plus de 3 secondes à s’exécuter seront dans le fichier de logs
défini précédemment. On peut éventuellement modifier la valeur de « long_query_time »
depuis MySQL.
On affiche la valeur de la variable avec la commande suivante :
1
SHOW GLOBAL VARIABLE LIKE ‘long\_query\_time’;
On modifie la valeur de la variable avec la commande suivante :
1
SET @@global.long\_query\_time = 3};
Exemple de log de requêtes lentes :
1
2
3
4
5
\# Time: 160320 10:14:53
\# User@Host: db\_user[db\_database] @ localhost []
\# Query\_time: 4.485129 Lock\_time: 0.000065 Rows\_sent: 215 Rows\_examined: 226
SET timestamp=1425695147;
SELECT option\_name, option\_value FROM wp\_options WHERE autoload = ’yes’}
• La première ligne indique la date et l’heure où la requête a été enregistrée. Le format
est AAMMJJ pour la date et H :M :S pour l’heure. Ici la requête a été enregistrée le
20 mars 2016 à 10 heures 14 et 53 (heure du serveur).
• La seconde ligne indique l’utilisateur MySQL, la base de donnée et le nom d’hôte.
Projet SCAL
Page 28/54
28 mars 2016
• La troisième ligne indique le temps de recherche total, le temps de verrouillage, le
nombre de lignes envoyés ou retournés, et le nombre de lignes examinées lors de la
requête.
• La quatrième ligne indique le temps réel passé pour la requête.
• La dernière ligne indique la requête complète.
3.5.4
Ne pas utiliser d’index
Un index est une information présente sur une ou plusieurs colonnes qui va faciliter la
recherche de données. En effet le système de base de données va d’abord chercher l’index pour
retrouver plus facilement et plus rapidement des données précises. Cela fonctionne comme
un livre, des mots précis sont listés avec leur numéro de page là où ces mots sont évoqués.
Grâce à l’option log_queries_not_using_indexes les requêtes qui n’ont pas d’index
seront logués. Il suffit d’ajouter la ligne dans le fichier /etc/mysql/my.cnf. Par la suite nous
pourrons leur ajouter des index.
Il y a trois types d’index : PRIMARY KEY, UNIQUE et INDEX.
Un index PRIMARY KEY est unique, les valeurs NULL ne sont pas acceptées.
Un index UNIQUE est unique, les valeurs NULL sont acceptées.
Un index INDEX permet d’indexer une colonne qui peut contenir des doublons.
Pour créer un index UNIQUE on tape la commande suivante :
1
CREATE UNIQUE INDEX nom\_index ON nom\_table (nom\_colonne) ;
Pour créer un index INDEX on tape la commande suivante :
1
CREATE INDEX nom\_index ON nom\_table (nom\_colonne) ;
Les index PRIMARY KEY sont automatiquement indexés lors de la création des tables
mais on peut quand même en créer manuellement :
1
2
ALTER TABLES nom\_table
ADD CONSTRAINT table\_pk PRIMARY KEY (table\_id) ;
Projet SCAL
Page 29/54
28 mars 2016
4 BENCHMARKS
3.5.5
L’utilisation des requêtes lentes
Quand une requête n’a pas d’index, le serveur MySQL doit utiliser plus de ressources
donc plus de temps pour traiter la requête. C’est pour cela que ces deux options, les logs de
requêtes lentes et requêtes sans index, vont parfaitement en semble.
3.5.6
Défragmentation
La base MySQL faisant constamment des requêtes il est nécessaires de défragmenter
régulièrement les tables afin de les optimiser. Pour cela on peut utiliser la commande :
1
OPTIMIZE TABLE nom\_table ;
pour défragmenter une table précise. Mais pour défragmenter toutes les tables en même temps
on va utiliser la commande suivante :
1
mysqlcheck -u root -p --auto-repair --optimize--all-databases}
La commande OPTIMIZE TABLE détecte si la table est fragmentée et la compacte, trie
les index si nécessaires et met à jour les statiques.
Exemple de différents résultats obtenus à la fin de la défragmentation des tables :
table_x
table_y
table_z
Table is already up to date
OK
Table does not support optimize, doing recreate + analyze instead
« Table is already up to date » signifie que l’optimisation n’était pas nécessaire.
« OK » signifie que l’optimisation a été faite.
« Table does not support optimize, doing recreate + analyze instead » indique qu’il
y a un problème d’incompatibilité. En effet pour les tables en InnoDB la requête n’est pas la
même, il faut utiliser la requête : « ALTER TABLE nom_table ENGINE=’InnoDB’ ;
» afin de pourvoir optimiser les tables en InnoDB.
4
Benchmarks
Le benchmarking peut être défini comme un démarche de comparaison utilisée pour évaluer la performance des différentes applications.
Projet SCAL
Page 30/54
28 mars 2016
4 BENCHMARKS
4.1
Outils de benchmarks
• ab est un outil d’Apache qui permet de lancer plusieurs requêtes à la suite. Il affiche
ensuite les résultats sur le temps de réponse (min, max, moyen), le nombre de réponses
valides.
http ://httpd.apache.org/docs/2.2/programs/ab.html
• Curl Loader est un outil gratuit open source qui simule des connexions simultanées, il
peut aussi simuler des connexions depuis différentes adresses ip. Fwptt fonctionne aussi
avec plusieurs protocoles tels que HTTP/S, FTP/S, SCP, SSH, LDAP, TFTP, Telnet.
Il gère aussi les cookies.
http ://curl-loader.sourceforge.net/
• fwptt est un outil qui enregistre des requêtes à partir d’un navigateur. Il peut enregistrer des requêtes normales mais aussi des requêtes AJAX.
http ://fwptt.sourceforge.net/
• http_load est un outil qui permet de tester la charge pour une page en envoyant une
URL plusieurs fois avec plusieurs connexions simultanées. Il affiche ensuite les résultats : la durée des réponses, le temps de réponse, nombres de requêtes etc. . .
http ://www.acme.com/software/http_load/
• JMeter est un outil d’Apache qui permet de tester les performances de plusieurs serveurs/protocoles : Web – HTTP/S. SOAP / REST. FTP. SGBD via JDBC. LDAP.
Mail – SMTP/S, POP3/S, IMAP/S. MongoDB. TCP.
http ://jmeter.apache.org/
• Pylot est un outil open source, gratuit qui permet de tester les performances et la montée en charge de services web. Il créé des requêtes concurrentes et vérifie les types de
réponse.
http ://www.pylot.org/
• Selenium est à la base un outil qui permet de mettre en œuvre des tests afin de vérifier
les affichages des sites. On peut l’utiliser aussi comme outil de tests de charge puisqu’il
permet de d’enregistrer des séquences de navigation depuis le navigateur internet.
http ://www.seleniumhq.org/
Projet SCAL
Page 31/54
28 mars 2016
5 SUIVI D’ACTIVITÉ
• Siege est un outil qui permet de faire des tests de montée en charge en simulant un
nombre défini de connexions simultanées sur une ou plusieurs sites. Les résultats affichent le nombre totale de hits enregistrés, de bytes transférés, le temps de réponse,
les accès concurrents et retourne le statut du serveur.
https ://www.joedog.org/siege-home/
• Tsung est un outil open source, gratuit sous licence GPLv2 qui permet de faire des tests
sur HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP et Jabber/XMPP mais aussi
de mesurer l’utilisation de la RAM et du CPU.
http ://tsung.erlang-projects.org/
• Web Polygraph est un outil gratuit qui permet de tester plusieurs protocoles, tel que
HTTP, HTTPS, FTP. . .
http ://www.web-polygraph.org/
5
Suivi d’activité
Pour le suivi d’activité nous avons utilisé Google Analytics. Google Analytics est un
service que Google propose gratuitement qui permet d’analyser les statistiques d’audience du
site concerné.
Projet SCAL
Page 32/54
28 mars 2016
5 SUIVI D’ACTIVITÉ
Que peut-on faire principalement avec Google Analytics ? On peut suivre le trafic de notre
site, le nombre de visiteurs datés ou en temps réel, l’origine du trafic c’est-à-dire d’où l’utilisateur provient ? S’il provient d’un moteur de recherche, d’un réseau social ou directement en
ayant tapé l’URL du site. Il est également possible de savoir si l’utilisateur est sur mobile, sur
tablette ou sur ordinateur. Une carte indique aussi sa localisation géographique. Il est possible
de savoir les pages les plus visitées, le navigateur utilisé, le système d’exploitation utilisé, et
bien d’autres informations. Tout cela représenté sous différents types de diagrammes.
Quel est l’intérêt de Google Analytics ? Grâces aux informations récoltées on va pouvoir
optimiser le contenu du site par rapport aux utilisateurs. Par exemple s’il y a plus 70%
des utilisateurs qui vont sur le site via leur téléphone mobile, grâce à cette information on
adaptera le site pour qu’il soit un maximum compatible pour les mobiles. Un autre exemple,
si notre site est un site d’e-commerce, en déterminant le profil des utilisateurs (âge, zone
géographique, etc. . . ) on pourra cibler les produits vendus sur le site par rapport aux profils
des utilisateurs.
Google Analytics nous a été utile dans le sens où nous avons pu observer la chute et la
montée du nombre d’utilisateur en temps réel lors de nos tests et nos modifications. Cela est
pratique pour voir à quel degré on affecte le site.
5.1
SLA
Service level agreement (SLA) est un document qui va défnir la qualité de service requise
entre un prestataire et un client.
Le contrat va spécifier les niveaux de disponibilité, de performance, d’opération ou d’autres
choses concernant le service en question.
Les SLA ont commencé à être utilisés à la fin des années 1980 par les opérateurs téléphoniques.
Actuellement, les services informatiques des entreprises ont repris l’idée des SLA afin de comparer la qualité de service fournie avec celle promise.
Le contrat peut contenir plusieurs mesures, par exemple le taux de pannes résolues, le pourcentage de l’uptime de serveurs sur le réseau, le temps moyen de résolution d’un incident.
Pour améliorer ces mesures, on peut mettre en place de la haute disponibilité ainsi que
de la répartition de charges.
Projet SCAL
Page 33/54
28 mars 2016
6 INFRASTRUCTURE DE HAUTE DISPONIBILITÉ
6
Infrastructure de Haute disponibilité
La haute disponibilité va permettre d’augmenter le taux de disponibilité du serveur. Il
faut rendre les sites web accessibles le plus longtemps possible. Pour cela on peut mettre en
place des réplications de serveur apache et base de données. Par exemple si on a 2 serveurs
identiques, le risque que les sites web soient inaccessibles est réduit car si un serveur subit
une panne, le 2nd prendra le relais, la haute disponibilité est donc augmentée.
6.1
Schéma de l’infrastructure
Pour la haute disponibilité et répartition de charges, nous avons choisi de prendre 1
serveur HAProxy qui fait également routeur, 3 serveurs de base de données sous MariaDB
ainsi que 3 serveurs web où sera répartie la charge.
6.2
HAProxy
HAProxy est un logiciel libre, open source de licence GNU General Public License Version
2 écrit en langage C.
Le créateur de ce logiciel est Willy Tarreau.
La première version de ce logiciel date du 16 décembre 2001.
La dernière version stable est la 1.6.4, elle date du 14 mars 2016.
La dernière version en développement est la 1.7-dev.
HAProxy fonctionne sur les systèmes d’exploitations suivants : Linux, FreeBSD, OpenBSD,
Projet SCAL
Page 34/54
28 mars 2016
Solaris, AIX.
De nombreux sites utilisent HAProxy, comme par exemple GitHub, Bitbucket, Stack, Overflow, Reddit, Tumblr, Twitter et Tuenti.
Willy Tarreau, le créateur d’HAProxy, est un contributeur au noyau linux. Il continue de
maintenir le projet HAProxy.
HAProxy va permettre la répartition des connexions reçues d’un protocole sur plusieurs
serveurs. Il fonctionne avec les connexions TCP. HAPproxy peut également servir en tant
que reverse-proxy pour les sites webs.
HAProxy est très performant, il peut tenir des charges importantes, et les ressources matérielles nécessaires à son utilisation sont très faibles, cependant il possède quelques inconvénients. Il ne possède pas d’interface Web pour la configuration, et il est impossible de
reconfiguer à chaud.
6.3
Installation et configuration
Pour l’installation, on va simplement installer le paquet haproxy.
On va ensuite activer haproxy :
sed -i "s/ENABLED=0/ENABLED=1/g" /etc/default/haproxy
sed -i "s/ENABLED=0/ENABLED=1/g" /etc/init.d/haproxy
La configuration d’HAProxy se fait grâce au fichier haproxy.cfg
Voir fichier haproxy.cfg dans Annexe.
6.4
Configurations réseaux des serveurs
Les 3 serveurs web et les 3 serveurs mariaDB sont dans le réseau 10.1.0.0/24
Ils ont pour passerelle : 10.1.0.1
Ils ont pour masque : 255.255.255.0
Le serveur Hearbeat/HAProxy nous sert de routeur afin que les serveurs web et bases de
données ne soient pas joignables depuis un autre réseau.
Il possède donc 2 cartes réseaux :
eth0 qui a pour adresse IP 192.168.4.23
Projet SCAL
Page 35/54
28 mars 2016
Elle a pour masque 255.255.255.0
Elle a pour passerelle 192.168.4.1
eth1 qui a pour adresse IP 10.1.0.1
Elle a pour masque 255.255.255.0
Elle a pour passerelle elle même.
Son nom d’hôte est : serverhaproxy.
Les 3 serveurs webs ont pour configuration :
Dates
Nom d’hôte
web1
web2
web3
Objet(s)
Addresse IP
10.1.0.21
10.1.0.22
10.1.0.23
Figure 10 – Tableau récapitulatif des base de données.
Les 3 serveurs de base de données sous mariaDB ont pour configuration :
Dates
Nom d’hôte
mariadb1
mariadb2
mariadb3
Objet(s)
Addresse IP
10.1.0.24
10.1.0.25
10.1.0.26
Figure 11 – Tableau récapitulatif des base de données.
Projet SCAL
Page 36/54
28 mars 2016
6.5
Load Balancing
Le load balancing signifie répartition de charge en français. C’est un ensemble de techniques
qui va permettre de répartir une charge entre différentes marchines. Lorsqu’on a un serveur
web par exemple, et qu’on a une forte audience sur notre site on aura énormément de traffic
sur notre serveur, et la charge sera élevée.
Grâce au load balancing, on va pouvoir répartir cette charge élevée entre différents serveurs
webs.
Le fait de répartir correctement la charge sur plusieurs machines évite la saturation d’un
serveur web comme ce serait le cas par exemple lors d’une attaque par déni de service.
Avec HAProxy, on a 1 seule adresse IP, celle du serveur HAProxy, pour accéder au service demandé (ici web).
Il existe 3 types de solutions de load balancing : DNS Round-Robin, GeoDNS et Anycast.
DNS Round Robin est un système de tourniquet, c’est à dire lorsqu’une requete DNS arrive, le serveur DNS peut répondre en ne fournissant pas une, mais plusieurs IP dans une
liste et rangées dans un ordre précis.
La première adresse IP de cette liste est l’IP que le client doit utiliser, les autres IP de
la liste ne sont là qu’en cas de secours au cas où par exemple le serveur de la première IP ne
répond pas.
L’ordre des IP de la liste change à chaque requête du client. Ce n’est donc jamais la même
Projet SCAL
Page 37/54
28 mars 2016
adresse IP en tête de liste.
On peut attribuer sur chaque serveur un poids qui influence la répartition. Ce poids est
sur 100.
Prenons par exemple un serveur web qui a comme poids 20, et un autre serveur web qui a
comme poids 80. Lorsqu’un client fait une requete, celle-ci a 80%de chance d’arriver sur le
serveur web ayant comme poids 80.
Cette attribution de poids est utile car tous les serveurs n’ont pas exactement la même
puissance. Si on a un serveur avec peu de puissance et un serveur beaucoup plus puissant et
qu’on ne met pas de poids (dans ce cas ce sera 50 chacun), alors on a un risque que le serveur
avec peu de puissance se retrouve complétement saturé alors que le serveur beaucoup plus
puissant n’exploite même pas 40% de ses capacités.
Cette méthode de DNS Round-Robin présente quand même quelques incovénients.
En effet lors de la répartition, DNS Round-Robin ne tient pas compte de la charge propre à
chaque serveur et peut envoyer une requête d’un client vers un serveur momentanément en
état de surcharge.
Il y’a également un autre inconvénient, si on se trouve dans une situation avec plusieurs
serveurs distants répartis géographiquement dans le monde, le serveur DNS peut indiquer
l’adresse IP d’un serveur qui se trouve être le plus éloigné du client.
Le temps de réponse sera donc plus lent et la qualité de service se dégradera.
GéoDNS est un système qui va permettre de résoudre le problème vu précédément où on
a des serveurs distants répartis géographiquement dans le monde.
Le serveur DNS va d’abord localiser le client en analysant son adresse IP. Il fournira ensuite l’adresse IP du serveur étant le plus proche géographiquement du client.
La liste d’adresses IP de serveurs ne se fait plus de façon circulaire, mais avec un classement des serveurs allant du plus près géographiquement du client, jusqu’au serveur le plus
éloigné.
C’est le système le plus utilisé sur Internet et qui est intéressant dans le cadre d’une répartition mondiale.
Projet SCAL
Page 38/54
28 mars 2016
DNS Anycast est un système où on est dans un cas de plusieurs plateformes réparties mondialement.
Chaque plateforme possède un serveur DNS.
Tous les serveurs DNS possèdent la même adresse IP.
Quand un client va effectuer une requète, il atteindra le serveur DNS le plus proche, au
niveau topologie d’Internet, de chez lui.
Ce serveur DNS va ensuite lui fournir une liste d’adresses IP de serveurs de sa propre plateforme de la même manière qu’en DNS Round-Robin.
Ce système est utilisé par des gros sites web, comme par exemple Google, dont l’architecture
est réparties mondialement sur plusieurs plateformes.
Contrairement à ce que l’ont pourrait penser, cette méthode ne présente pas de risques.
Le fait d’avoir la même adresse IP sur les serveurs DNS ne posent pas de problèmes car
le protocole DNS repose sur UDP et donc ne nécessite pas l’établissement d’une session
contrairement à TCP.
Pour conclure, le load balancing est une bonne chose, mais il y’a tout de même 2 inconvénients non-négligeables :
- Le fait que le serveur va répartir sans vérifier si un serveur n’est pas déjà en surcharge.
- Le fait qu’il n’y ai pas de détection de panne. Le serveur continura de répartir même si un
serveur n’est pas disponible, un certain nombre de requêtes seront donc perdues.
Il y’a également un dernier inconvénient : le client ne peut pas toujours être en relation
avec le même serveur car chaque requète change de serveur.
Il n’est donc pas possible de garder une connexion permanente entre le client et un serveur.
On peut tout de même préciser que le client va conserver pendant quelques minutes dans son
cache l’adresse IP du serveur utilisé.
La répartition de charge dans ce cas là appartient à la couche numéro 4 du modèle OSI,
c’est à dire Transport.
Projet SCAL
Page 39/54
28 mars 2016
Il y’a donc une connexion entre la machine et les serveurs avant toute communication.
Le load balancing va également s’appuyer sur le principe de la translation d’adresse NAT
(Network Address Translation).
Les machines extérieures ne voient pas ce qu’il y’a dans l’autre réseau. Pour le client il n’y a
qu’un seul serveur web possédant une adresse IP unique et publique.
Comme expliqué précédement, la répartition se fait de plusieurs manières.
Il existe une multitude d’algorithmes pour la répartition de charges :
- Round-robin : l’affectation va se faire de manière circulaire( web1, puis web2, puis web3,
puis web1, ...)
- Weighed-round-robin : c’est l’affectation de la même manière qu’en Round-robin, mais
avec un système de poids. Le poids va influancer lors de la répartition.
- Least-connection : le choix va se faire sur le serveur ayant le moins de connexions en
cours.
- Weighed-least-connection : cela reprend le précédent principe, mais en rajoutant un système
de poids.
- Priority-activation : si un niveau de charge est dépassé sur des serveurs, d’autres serveurs
de secours seront alors activés et utilisés.
- Affinité : le client, identifié par son adresse IP et le port TCP, aura toujours le même serveur.
- Aléatoire : le choix du serveur va s’effectuer par tirage au sort, et donc de manière totalement aléatoire.
6.6
Configuration serveurs web
On installe le paquet apache2 sur tous les serveurs webs.
Projet SCAL
Page 40/54
28 mars 2016
6.7
Test de la répartition de charge
Pour tester si la répartition de charge est fonctionnelle, on modifie la page index.html de
chaque serveur web afin des les rendre unique.
On va ensuite utiliser une machine située à l’extérieur, et on se connecte depuis un navigateur
sur le serveur web en rentrant l’adresse IP du serveur Haproxy.
On devrait normalement tomber sur la page index.html d’un des serveurs web.
Quand on actualise la page, on devrait tomber sur la page index.html d’un autre serveur
web. Si on actualise une nouvelle fois, on tombe sur une autre page index.html, lorsqu’on a
configuré HAProxy en Round-robin.
6.8
MariaDB
MariaDB est un système de gestion de base de données (SGBD).
Il est édité sous licence GPL.C’est le fondateur de MySQL, Michael Widenius, qui quitte sa
société suite au rachat de MySQL par Sun Microsystems. Il a décidé de lancer MariaDB afin
de remplacer MySQL.
Le nom MariaDB vient du nom de la seconde fille du fondateur qui s’appelle Maria.
MariaDB est un fork communautaire de MySQL.
6.9
Gelra Cluster
Projet SCAL
Page 41/54
28 mars 2016
Gelra Cluster est une solution disponible uniquement sur Linux.
Cette solution va permettre un cluster multi-maître synchrome pour MariaDB.
Gelra Cluster se met en place un minimum 3 serveurs.
Lorsqu’un utilisateur écrit dans une des bases de données sur un serveur, les nouvelles données
seront répliquées sur les autres serveurs de base de données.
6.10
Heartbeat
Heartbeat est une application distribué sous licence GPL.
Cette application est compatible sous Ubuntu, Debian, FreeBSD, OpenBSD, Solaris et MacOS X.
Heartbeat est une application qui va pouvoir surveiller la disponibilité de serveurs.
Heartbeat signifie en français battements de coeur. C’est son nom car il va écouter les services
d’une grappe de serveurs lorsque ceux ci sont opérationnels.
Lorsqu’un serveur ne répond plus, Heartbeat va, grâce à des scripts, s’assurer qu’un serveur
prenne le relais.
Heartbeat fonctionne avec Pacemaker.
6.10.1
Installation et configuration d’Heartbeat
On installe le paquet heartbeat. On a 3 fichiers à configurer :
ha.cf
1
2
3
4
5
6
7
8
9
10
11
12
13
mcast eth0 239.0.0.11 694 1 0
logfile /var/log/ha-log
warntime 4
# le delai avant de declarer qu’un noeud est mort
deadtime 5
# c’est le temps avant qu’heartbeat ne demarre les ressources la premiere
#fois qu’il se lance: mariadb
initdead 15
keepalive 2
#Re-balance les services sur le lb primaire quand il revient en ligne
auto\_failback on
Projet SCAL
Page 42/54
28 mars 2016
14
15
16
#Serveurs du cluster
node serverhaproxy
haresources
1
serverhaproxy IPaddr::192.168.4.23/24/eth0 haproxy
authkeys
1
2
auth 3
3 md5 cluster-db-key
6.11
Installation MariaDB et Galera Cluster
Afin de mettre en place notre cluster de base de données MariaDB avec Galera Cluster,
il faut ajouter les dépôt Debian nécessaire. Sur les trois serveurs de bases de données, faire
les manipulation suivantes :
1
2
3
sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
sudo add-apt-repository ’deb [arch=amd64,i386] http://ftp.igh.cnrs.fr/pub/mariadb/rep
Par la suite il nous faut recharger le nouveau dépôt et on pourra installer le paquet mariadbserver :
1
2
sudo apt-get update
sudo apt-get install mariadb-server
6.11.1
Configuration Galera Cluster
Maintenant que MariaDb est installé, il faut configurer Galera Cluster afin de mettre en place
la réplication entre les serveurs. Il y’a un fichier à configurer : /etc/mysql/conf.d/galera.cnf
1
2
3
4
5
[mysqld]
#mysql settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
Projet SCAL
Page 43/54
28 mars 2016
6
7
8
9
10
11
12
13
14
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
#galera settings
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="mon_cluster_dbr"
#On définit ici les addresses des différentes BDD du cluster
wsrep_cluster_address="gcomm://10.1.0.24,10.1.0.25,10.1.0.26"
wsrep_sst_method=rsync
6.12
Test de la réplication
Pour tester la réplication des serveurs de base de données, il suffit de se connecter sur la
base de données d’un des serveurs et d efaire des modifications dessus, par exempler créer
une table. On se déconnecte ensuuite de ce serveur et on se connecte sur un autre serveur de
base de données. On affiche les tables de la base de données, et normalement si la réplication
fonctionne correctement, on devrait voir la table qui a été créée précédemment sur l’autre
serveur.
Projet SCAL
Page 44/54
28 mars 2016
8 REMERCIEMENTS
7
Conclusion
Pour conclure, ce projet nous aura appris comment optimiser un serveur web afin d’utiliser au mieux ses performances. On aura également vu ce qu’est un SLA et la manière dont
on peut l’améliorer en faisant de la répartition de charges de serveurs web, et la haute disponibilité. On aura appris à travailler sur un serveur web dans un environnement critique
de type ecommerce. Pour tester nos modifications sur le serveur web, nous avons utilisé des
outils de tests de performance. De plus cela nous à aussi permit de travailler en groupe et
ainsi de s’organiser afin d’optimiser notre notre travail.
Ainsi, l’optimisation d’une plateforme de type LAMP doit se préparer à l’avance, afin d’acquérir un maximum d’information sur le fonctionnement actuel du serveur et ainsi pouvoir
détecter les points faibles de celui-ci. En plus de cela, il existe plusieurs solutions lorsque
l’on travaille dans un environnement critique pour assurer du bon fonctionnement de celuici, le backup et un environnement de test font parties des solutions. Lorsque l’on souhaite
optimiser un serveur web, il faut garder à l’idée que tout est lié et qu’une modification sur
une composante peut impacter sur une autre composante et la rendre défaillante. Il est donc
nécéssaire quà chaque modification, il faille faire des tests afin de confirmer le bon fonctionnement du serveur. Enfin, la supervision du serveur est une chose très importante qui permet
de voir le bon déroulement de celui-ci et de réagir vite en cas de problème.
8
Remerciements
Nous tenons à remercier, dans un premier temps, notre tuteur de projet, Yohan Parent,
pour son aide lors de nos difficultés et pour ses conseils qui nous ont permis d’aller de l’avant.
Dans un second temps, nous remercions les propriétaires du site trackmusik.fr, qui nous ont
permis d’avoir accès à leur serveur pour pouvoir appliquer les différentes optimisations. Enfin
nous remercions aussi, tous les professeurs tout au long de l’année qui nous ont donnés les
enseignements nécessaires pour nous permettre de bien comprendre le sujet.
Projet SCAL
Page 45/54
28 mars 2016
9 ANNEXES
9
Annexes
Test Charge Compression Expire Workers
Projet SCAL
Page 46/54
28 mars 2016
9 ANNEXES
Test Charge Compression
Projet SCAL
Page 47/54
28 mars 2016
9 ANNEXES
Test Charge
Projet SCAL
Page 48/54
28 mars 2016
9 ANNEXES
Expires.conf
Projet SCAL
Page 49/54
28 mars 2016
9 ANNEXES
Test Charge Compression Expires
Projet SCAL
Page 50/54
28 mars 2016
9 ANNEXES
Script mysqltuner.pl
Projet SCAL
Page 51/54
28 mars 2016
9 ANNEXES
Projet SCAL
Page 52/54
28 mars 2016
9 ANNEXES
Fichier de configuration HAProxy
Projet SCAL
Page 53/54
28 mars 2016
9 ANNEXES
Projet SCAL
Page 54/54
28 mars 2016

Optimisation de serveurs LAMP et problématique de scalabilité

Transcription

Documents pareils

POSTE A POURVOIR -Tech Sup Opérateur serveur

business objects desktop intelligence xi expert

Serveurs 7days, Minecraft, Ark

Abri SONDERBORG 3 - Maison

Une architecture client léger mise en œuvre au Lycée

Télécharger mon CV en suivant ce lien.

Architecte systèmes, réseaux et sécurité

Configuration des hôtes virtuels (Apache) sous CentOS 6

Formation Business Objects WebI XI Niveau 2 - BD BOW

Carnet de Vol développe ses relations clients en mode multi