exemple de documentation

Infrastructure Exemple
Table des matières
1. Serveurs...........................................................................................2
1.1 Serveurs physiques .......................................................................... 2
1.2 Serveurs Virtuels.............................................................................. 2
2. Services............................................................................................3
2.1 Service mail.................................................................................... 3
2.2 Service MySQL................................................................................. 3
2.3 Service Web.................................................................................... 4
2.4 Cas particulier des limites d'utilisation :.................................................. 4
2.5 Service DNS.................................................................................... 5
2.6 Pré-production................................................................................. 5
3. Sauvegardes......................................................................................5
4. Monitoring.........................................................................................6
5. Sécurité............................................................................................6
Annexes................................................................................................7
A. Lexique :......................................................................................... 7
B. Accès aux serveurs............................................................................. 7
C. Attributions des IP............................................................................. 8
D. Informations utiles............................................................................. 9
Votre Contact Technique:
Nicolas Lafont
09 72 26 94 72
[email protected]
Votre Contact Commercial:
Margot Lafont
09 72 26 94 72
[email protected]
Version 1.1 du 17/04/12
Page 1/9
1. Serveurs
1.1 Serveurs physiques
L'infrastructure se répartit sur 2 machines physiques, louées chez OVH, de la
gamme EG 2011, disposant chacune de 24 Go de RAM, 2 To d'espace disque en sata
raid 1 soft.
➢
nsxxxxx.ovh.net
192.168.0.198
A
➢
nsyyyyy.ovh.net
192.168.0.199
B
Ces serveurs, utilisant une distribution Debian Squeeze (6.0) sont virtualisés avec
la technologie libre et éprouvée XEN, en version 4.0. Les machines virtuelles (VM)
sont montées sur des volumes logiques (Logical Volume – LVM).
Sur les deux serveurs hôtes sont installés les hyperviseurs, mais aussi Heartbeat
et Pacemaker, dont l'utilisation sera détaillée plus loin.
1.2 Serveurs Virtuels
Nous pouvons compter, à l'heure actuelle, 5 machines virtuelles, listées cidessous :
➢
mail BA , machine virtuelle chargée du service mail
2 Go de RAM, 2VCPU – 10.0.100.241
➢
web1 B , machine virtuelle web 1
4 Go de RAM, 2 VCPU – 10.0.100.244
➢
web2 A , machine virtuelle web 2
4 Go de RAM, 2 VCPU – 10.0.100.245
➢
mysql1B , machine virtuelle mysql 1
4 Go de RAM, 4 VCPU – 10.0.100.242
➢
mysql2 A , machine virtuelle mysql 2
4 Go de RAM, 4 VCPU – 10.0.100.243
Les ressources des serveurs physiques ne sont pas exploitées en totalité, ce qui
permet une souplesse pour augmenter le nombre de machines virtuelles, soit pour
augmenter la capacité de traitement des sites, soit pour avoir un environnement de
pré-production (test de php 6 par exemple) .
Ces machines virtuelles sont installées en Debian Squeeze (6.0)
Version 1.1 du 17/04/12
Page 2/9
2. Services
2.1 Service mail
La configuration pour la machine virtuelle mail (mail) est disponible sur les deux
serveurs hôtes.
Les volumes logique de données utilisés pour cette machine virtuelle sont des
supports pour une couche DRBD, entre les deux serveurs hôtes, ce qui nous permet
d'assurer, à tout instant, que les données sont à jours sur les deux serveurs.
L'un des deux serveurs est élu « maître » et peut donc lancer la machine virtuelle
mail. En cas de défaillance du serveur hôte maître à l'instant T, le second va prendre
la main, avec des données datant de quelques secondes au maximum. (perte de mail
possible et très limitée sur le papier, moindre que sur un serveur unique, jamais
rencontrée dans la pratique).
La machine virtuelle mail est donc en service sur l'un ou l'autre des serveurs
hôtes, mais pas sur les deux en même temps (sauf cas particulier exposé plus bas).
La machine virtuelle mail, 10.0.100.241, lance donc les services mails suivants :
➢
➢
➢
➢
➢
➢
Postfix
réception et envoi des mails serveur <=> internet
Postgrey
filtrage des mails par greylisting, pour limiter le spam
Amavis
filtre et gestion de filtrage
Spamassassin
antispam
Clamav
antivirus
Courier
pop et imap, réception des mails serveur => lecteur de mail
Tous ces logiciels sont dans leurs versions standard Debian.
2.2 Service MySQL
Les deux machines virtuelles MySQL (10.0.100.242 & 10.0.100.243) font tourner
un serveur MySQL, configuré en double réplication (donc chacun des serveurs copie
les transactions faites sur le second), avec un auto_increment décalé (par pas de 10
avec un offset différent).
Keepalived tourne sur les serveur maître, et gère l'IP flottante de service MySQL :
10.0.100.251 . Toutes les requêtes MySQL doivent donc se faire sur cette IP.
Les logs des requêtes lente est activé, pour toute requête d'une durée supérieure
à 2 secondes.
Version de MySQL utilisée : Perconna 5.5 .
Version 1.1 du 17/04/12
Page 3/9
2.3 Service Web
Les deux machines virtuelles web ont un comportement un peu différent, et se
caractérise comme l'élément « complexe » de l'infrastructure.
La partition de données des machines virtuelles web est basée sur une couche
DRBD, gérée par les deux serveurs.
Le serveur web élu « maître », via les logiciels Heartbeat et Pacemaker va donc
monter les données DRBD comme un système de fichier local, puis l'exporter par NFS.
Juste après, il va monter les IPs de services :
➢
➢
NFS : 172.16.0.150 (ip privée)
WEB : 10.0.100.250
Il va par ailleurs lancer Keepalived, utilisé ici uniquement comme un répartiteur de
charge (ipvs avec une surcouche de test pour savoir quel serveurs réel sont actifs).
Pour faire fonctionner Keepalived, il faut lancer une IP flottante de service, qui n'est
donc pas utilisée : 172.16.0.40 (ip privée). Apache sera aussi lancé sur le serveur
« maître ».
Sur le serveur esclave, les données seront montées par NFS (donc à jour en temps
quasi réel, les uploads de données peuvent se faire des deux serveurs), et Apache
sera lancé également.
En cas de défaillance du serveur « maître », le serveur esclave va démonter le
NFS, puis s’élire « maître » et suivre la procédure décrite ci dessus. Le temps de
reprise sur erreur est d'environ 1 minute, et 100% automatique.
En cas de modification de configuration de PHP ou Apache, les modifications
doivent être faites sur web1 , sur lequel doit ensuite être lancé la commande
/usr/local/bin/synchro-conf.sh pour que web2 prenne la nouvelle configuration.
2.4 Cas particulier des limites d'utilisation :
N'ayant que deux serveurs, et n'ayant pas la possibilité de faire de l'IPMI (reboot
hard à distance entre autre) sur ceux-ci, nous ne pouvons garantir que le cluster
(services web et mail) sera dans un état cohérent en tout instant, car le risque de
split-brain ne peut être écarté.
Cela pourrai être contourné par la mise en place de machine virtuelle externe
témoin, servant à vérifier que les serveurs ont accès au réseau. (il faut que le serveur
voit au moins 1 autre node du cluster pour être sur d'être légitime).Les coûts de ces
témoins seraient de 35 euros HT par mois, et ne sont pas justifiées, à notre sens pour
le moment.
Version 1.1 du 17/04/12
Page 4/9
En effet, en cas de split-brain (cas critique), en moins d'une heure de temps nous
pouvons repasser les clusters dans un état cohérent, avec un risque de perte de
données très faible (risque également limité par les sauvegardes), et sans coupure de
service notable (le plus gros risque étant un ralentissement de service). Nous
estimons l'occurrence des split-brain ne pourrait que difficilement atteindre 6 cas par
an, ce qui implique un coût de témoins plus important que le coût d'intervention en
cas de problème.
2.5 Service DNS
Le service DNS est assuré par l'infrastructure DNS de WDMedia, qui n'est pas liée
aux serveurs hôtes. Ceci permet une meilleure sécurisation de ce service.
Les demandes de changement de configuration DNS seront donc à faire auprès de
WDMedia, cette configuration ne pouvant se faire directement sur les serveurs hôtes
ou machines virtuelles.
2.6 Pré-production
Le serveur mail fait aussi office de serveur de pré-production, pour tester les
modifications à venir.
Pour utiliser le mode test, il faut modifier le fichier hosts de votre poste pour faire
pointer l'adresse du site désiré vers l'ip du serveur : 10.0.100.241 (il faut penser à
modifier le fichier dans l'autre sens après tests pour retourner sur la production).
Il existe deux scripts qui permettent de synchroniser les données de production
vers le serveur de pré-production, le premier synchronisant les fichiers différents (une
liste de fichier/répertoire à ne pas resynchroniser existe en début de fichier), le
second vidant et ré important les données mysql :
➢
➢
/usr/local/bin/synchro-apache.sh
/usr/local/bin/synchro-mysql.sh
3. Sauvegardes
Les sauvegardes MySQL sont effectuées sur le serveur primaire (détecté par la
présence de l'ip flottante) une fois par jour, dans la nuit (sauf pour la base data,
sauvegardée toutes les 2 heures), via un mysqldump de chaque table qui est
compressé et stocké dans une partition séparée (/backup/), puis envoyé sur le
serveur secondaire via rsync. La durée de conservation des sauvegardes MySQL est de
14 jours.
Les sauvegardes Web sont effectuées sur le serveur primaire (détecté par la
présence du montage de la partition drbd) une fois par jour, dans la nuit, en faisant
une archive tar.gz de chaque répertoire situé dans /home/web/ . Cette archive est
stockée dans une partition séparée (/backup/), puis envoyé sur le serveur secondaire
via rsync. La durée de conservation des sauvegardes Web est de 7 jours.
Version 1.1 du 17/04/12
Page 5/9
Les sauvegardes mail sont effectuées sur le serveur mail, une fois par jour, dans la
nuit, en faisant une archive tar.gz de chaque répertoire contenant un @ situé dans
/home/mail-data/ . Cette archive est stockée dans une partition séparée (/backup/).
La durée de conservation des sauvegardes mail est de 10 jours.
Chaque partition de sauvegarde fait 10 fois la taille de celle de production.
Les sauvegardes mysql et web ensuite synchronisées sur les serveurs de
sauvegarde OVH par FTP. L'accès a ces sauvegardes n'étant possible que depuis les
serveurs maîtres, le transfert se fait par création d'un snapshot des partitions de
backup sur le serveur maître, envoi ftp depuis le snapshot, puis destruction du
snapshot. La durée de conservation des sauvegardes vers le FTP OVH est de 5 jours.
4. Monitoring
Les serveurs sont monitorés par le logiciel shinken (réécriture de nagios), en
redondance sur deux réseaux différents.
➢
➢
➢
➢
➢
➢
➢
Les services supervisés sont :
mail: disk, imap, load, mailq, maj, ping, pop, procs, smtp, ssh
mysql1 : disk, load, maj, mysql, mysql-lock-cont, mysql-long, ping, procs, ssh
mysql2 : disk, load, maj, mysql, mysql-lock-cont, mysql-long, ping, procs, ssh
web1 : crm, disk, drbd0, http, http-speed, load, mailq, maj, ping, procs, ssh
web2 : crm, disk, drbd0, http, http-speed, load, mailq, maj, ping, procs, ssh
nsxxxxx.ovh.net : crm, disk, drbd0, drbd1, drbd2, load, mailq, maj, ping,
procs, raid, ssh
nsyyyyy.ovh.net : crm, disk, drbd0, drbd1, drbd2, load, mailq, maj, ping,
procs, raid, ssh
Il y a également un monitoring des services web et mysql sur les ip flottantes des
services correspondant.
.
5. Sécurité
Les serveurs (hors serveurs hôtes) sont protégés par un firewall (arno-iptablesfirewall), ainsi que par fail2ban (logiciel bloquant les attaques brute-force en
analysant les logs). Les ports ouverts sur les IP publiques sont :
web1 : 21, 80, 220, 443
web2 : 80, 220, 443
mysql1/mysql2 : 220
mail : 25, 80, 110, 143, 220, 443, 587, 993, 995
Des règles spécifiques sont définies pour autoriser les communications internes
nécessaires, ainsi que pour la supervision depuis nos serveurs.
Version 1.1 du 17/04/12
Page 6/9
Annexes
A. Lexique :



•
•






DRBD :
Raid 1 entre deux serveurs, utilisant le réseau pour propager les données.
Perconna :
Version de MySQL patchée par Google, afin d'avoir de meilleures performances InnoDB.
LVM :
Logical Volume Manager. Il s'agit de partition virtuelles, permettant entre autres :
les Snapshot
la ré-allocation de ressources disques (augmentation ou diminution de la taille)
NFS :
Network File System. Système de fichier pour le « partage » de données Unix via le réseau.
Heartbeat :
Logiciel de couche de communication cluster.
Pacemaker :
Logiciel gestionnaire de ressources pour un cluster.
Keepalived :
Logiciel de gestion de redondance et de répartition de charge.
IPMI :
Accès au bios du serveur à distance, et contrôle de certaines fonctions.
Split-brain :
Fait d'avoir son cluster coupé en deux, avec les services lancés sur chacune des machines en
parallèle, sans que les machines ne se voient l'une l'autre, se croyant donc chacun « maître ».
Ce cas se produit typiquement quand les machines ne se voient plus l'une l'autre mais voient
encore le reste d'internet. C'est un cas assez rare.
B. Accès aux serveurs
B.1 SSH
L'utilisateur exemple a été créé sur l'ensemble des serveurs. Il dispose d'un accès
root via sudoers. Le mot de passe attribué a cet utilisateur est : deo7ohn3Aqu8aey6
. L'accès a ssh se fait sur le port 220 (ceci limite les scans ssh).
B.2 SFTP/FTP
L'accès SFTP se fait sur les serveurs web1 ou web2 , avec les identifiants ci
dessous (l'accès FTP est également possible mais non recommandé). Le compte
exemple2 fonctionne également sur le serveur mail (preprod)
Nom d'utilisateur : exemple2
Mot de passe : AijaiLae5Coora2s
Répertoire de base : /home/ sur web1/web2 , /preprod_data/ sur mail
B.3 PhpMyAdmin
URL : https://www.lesiteexemple.fr/phpmyadmin/
URL preprod : https://mail.lesiteexemple.fr/phpmyadmin/
Nom d'utilisateur : exemplephpmyadmin
Mot de passe : OxeeyeeZ7woh2ui9
Version 1.1 du 17/04/12
Page 7/9
B.4 Mail
Adresse du serveur pop/imap/smtp : mail.lesiteexemple.fr
Port SMTP : 25 ou 587 (l'utilisation du SMTP nécessite une identification)
Administration des comptes mails :
URL :https://mail.lesiteexemple.fr/postfixadmin/login.php
Nom d'utilisateur : [email protected]
Mot de passe : eepoTohx6eex5azu
Webmail : https://mail.lesiteexemple.fr/roundcube/
B.5 Logs
Les principaux logs sont accessible via un utilisateur spécifique :
Nom d'utilisateur : exemplelog
Mot de passe : ahdeorahwaV5liil
Les logs apache sont accessible sur les serveurs web1 et web2, dans
/var/log/apache2/ . Ils ne sont pas centralisés, donc ils sont propres a chaque
machines.
Les logs des requêtes lentes mysql sont accessibles sur les serveurs mysql1 et
mysql2, dans /var/log/mysql/ . Ils ne sont pas centralisés, donc ils sont propres a
chaque machines, néanmoins seul le serveur maître mysql a un log rempli.
C. Attributions des IP
192.168.0.198 : nsxxxxx.ovh.net : serveur maître 1
192.168.0.199 : nsyyyyy.ovh.net : serveur maître 2
10.0.100.240
10.0.100.241
10.0.100.242
10.0.100.243
10.0.100.244
10.0.100.245
10.0.100.246
10.0.100.247
10.0.100.248
10.0.100.249
10.0.100.250
10.0.100.251
10.0.100.252
10.0.100.253
10.0.100.254
10.0.100.255
Version 1.1 du 17/04/12
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
réservée pour le réseau
mail
mysql1
mysql2
web1
web2
IP flottante (web1/web2) : service web
IP flottante (mysql1/mysql2): service mysql
réservée pour le réseau
réservée pour le réseau
réservée pour le réseau
réservée pour le réseau
Page 8/9
172.16.0.10 : ip privée web1
172.16.0.20 : ip privée web2
172.16.0.40 : ip privée flottante sans service (réservée keepalived)
172.16.0.150 : ip privée flottante (web1/web2) : service nfs
D. Informations utiles
•
•
•
•
Numéro
Numéro
Numéro
Adresse
d'astreinte : 09.72.26.94.72
standard : 09.72.26.94.72
support infogérance : 09.72.26.94.72
e-mail : [email protected]
Version 1.1 du 17/04/12
Page 9/9