tp6 : mise en œuvre d’une solution de haute disponibilité pour un … · 2016-05-22 ·...

LYCEE OZENNE

TP6 : Mise en œuvre d’une solution de haute disponibilité pour un serveur Web

HIFDI SAMI

17/02/2016


HIFDI SAMI

Sommaire

1ère étape : Installer configurer le serveur répartiteur de charge sisr4-lbs-nn ................................................................. 3

2ème étape : Installer et configurer le premier serveur Web sisr4-web1-nn ..................................................................... 4

3ème étape : Installer et configurer le deuxième serveur Web sisr4-web2-nn .................................................................. 5

4ème étape : Installer et configurer le service KEEPALIVED sur le serveur sir4-lbs-nn ...................................................... 6

5ème étape : Valider le fonctionnement du cluster de répartition de charge ................................................................... 9

6ème étape : Installer et configurer sur les deux serveurs Web les services DRBD ......................................................... 10

7ème étape : Valider la synchronisation des données par DRBD ..................................................................................... 12

8ème étape : Configuration le système de fichiers en cluster OCFS2 .............................................................................. 13

9ème étape : Valider le bon fonctionnement du cluster OCFS2 ...................................................................................... 15

10ème étape : Les tests de fonctionnement du cluster serveur Web hautement disponible ......................................... 15


HIFDI SAMI

1ère étape : Installer configurer le serveur répartiteur de charge sisr4-lbs-nn

Configuration du serveur répartiteur de charge sisr4-lbs-13 :

Modifier le nom de l’ordinateur :

o Nano /etc/hostname

o Renseigner « sisr4-lbs-13 »

Créer l’utilisateur sisr-13 (mot de passe : Btssisr4)

Configurer les 2 cartes réseaux :

o Carte « Réseau local »

Adresse : 172.16.76.229

Masque de réseau : 255.255.0.0

Passerelle : 172.16.0.1

Serveurs DNS : 172.16.224.10, 172.16.224.45

Domaines de recherche : bts-sio.ozenne.fr

o Carte « Réseau du cluster »

Adresse : 192.168.76.229


Passerelle : 192.168.76.229

Domaines de recherche : lbs-13.ozenne.fr

o Configurer le fichier hosts (pour résolution de nom) : « nano /etc/hosts » 192.168.76.232 sisr4-web2-13 192.168.76.231 sisr4-web1-13 192.168.76.229 sisr4-lbs-13

o Configurer le domaine : « Nano /etc/resolv.conf »

# Generated by NetworkManager domain bts-sio.ozenne.fr search bts-sio.ozenne.fr localdomain nameserver 172.16.224.10 nameserver 172.16.224.45


HIFDI SAMI

2ème étape : Installer et configurer le premier serveur Web sisr4-web1-nn

Avoir 2 disques durs pour les 2 serveurs web, de tailles identiques.

Configuration du serveur répartiteur de charge sisr4-web1-13 :



o Renseigner « sisr4-web1-13 »




Adresse : 172.16.76.231



Serveurs DNS : 172.16.224.10 , 172.16.224.45



Adresse : 192.168.76.231


Passerelle : 192.168.76.229


Configurer apache2 :

o Installer apache2 : « apt-get install apache2 »


Domain sisr-13.ozenne.fr Search bts-sio.ozenne.fr localdomain Nameserver 172.16.224.10 Nameserver 172.16.224.45

o Modifier « /etc/apache2/ports.conf » NameVirtualHost * :8001 Listen 8001

o Modifier /etc/apache2/sites-available/default <VirtualHost * :8001>



HIFDI SAMI

3ème étape : Installer et configurer le deuxième serveur Web sisr4-web2-nn

Configuration du serveur répartiteur de charge sisr4-web2-13 :



o Renseigner « sisr4-web2-13 »




Adresse : 172.16.76.232



Serveurs DNS : 172.16.224.10 , 172.16.224.45



Adresse : 192.168.76.232


Passerelle : 192.168.76.229


Configurer apache2 :

o Installer apache2 : « apt-get install apache2 »


Domain sisr-13.ozenne.fr Search bts-sio.ozenne.fr localdomain Nameserver 172.16.224.10 Nameserver 172.16.224.45

o Modifier « /etc/apache2/ports.conf » NameVirtualHost * :8001 Listen 8001

o Modifier /etc/apache2/sites-available/default <VirtualHost * :8001>



HIFDI SAMI

4ème étape : Installer et configurer le service KEEPALIVED sur le serveur sir4-lbs-nn

Installer les paquets :

Vérifier que les sources listes sont correctes.

Effectuer une upgrade : apt-get upgrade

Installer le paquet ipvsadm : apt-get install ipvsadm

Configurer le redirecteur :

Le directeur d’un LVS en NAT pouvant être

considéré comme un routeur, la redirection

de paquets IP (IP Forwarding) entre les

différents adaptateurs doit être activée

comme ceci :

Soit par la commande : echo 1 >

/proc/sys/net/ipv4/ip_forward

La modification peut être rendue

permanente en modifiant le fichier

/etc/sysctl.conf :

Soit en décommanter la ligne : net.ipv4.ip_forward = 1

Puis recharger ce fichier avec la commande : sysctl –p ou au redémarrage du serveur.

Configurer le fichier /etc/keepalived/keepalived.conf

Installer le paquet keepalived : apt-get install keepalived

Contenu du fichier : /etc/keepalived/keepalived.conf:

! Configuration File for keepalived global_defs { notification_email { acassen } notification_email_from

[email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_1 } virtual_server 172.16.76.230 80 { lb_algo rr


HIFDI SAMI

lb_kind NAT persistence_timeout 300 protocol TCP delay_loop 30 real_server 192.168.76.231 8001 { weight 1 inibit_on_failure delay_loop 30 TCP_CHECK { connect_port 8001 connect_timeout 3 } } real_server 192.168.76.232 8001 { weight 1 inibit_on_failure delay_loop 30 TCP_CHECK { connect_port 8001 connect_timeout 3 } } } static_ipaddress { 172.16.76.230/24 dev eth0 label eth0:0 scope

global }

Activer le service ipvsadm :

Commandes à exécuter une seule fois : Il faut d’abord, configurer le fichier /etc/default/ipvsadm avec les options :

auto=true

daemon=master Puis exécuter ces commandes :

update-rc.d ipvsadm defaults

service ipvsadm start (Ce chargement peut être effectué à la main avec la commande modprobe : modprobe ip_vs)

Keepalived : Lancer le service


HIFDI SAMI

Commande : service keepalived start Ou /etc/init.d/keepalived start (Si le script n’est pas présent, keepalived peut être démarré ainsi à la main : keepalived –D )

Contrôle de keepalived : Quelques moyens permettant de vérifier que keepalived a bien démarré :

Tout d’abord, on vérifie la présence des processus associés : Commande : pgrep keepalived

keepalived utilise syslog pour écrire ses traces, généralement dans /var/log/messages ou dans /var/log/syslog

La commande ifconfig ne permet pas de voir la VIP car elle a été définie par la commande ip sans étiquette (label).

La commande IP permet de la voir ainsi en utilisant la syntaxe longue : o Commande : ip addr show eth1

Voir si keepalived fonctionne et sa configuration : o Commande : ipvsadm -Ln

Arrêt de keepkalived: service keepalived stop

La modification du fichier de configuration de keepalived nécessite un rechargement de celui-ci ce qui se fait par l’envoi du signal 1 SIGHUP au premier processus keepalived lancé. C’est celui dont le PPID est 1. Commande : service keepalived reload ps –ef | grep keepalived Puis kill -1 numéro de processus donné par la commande ps.

Le paquet ipvsadm sert à gérer les adresses IP virtuelles avec la commande : ipvsadm

Configuration de la VIP :

o La VIP doit être déclarée sur l’adaptateur réseau qui ici fait partie du réseau local, ici

172.16.0.0/16.

o Si l’IP du LVS est 172.16.76.230, elle doit être configurée sur l’adaptateur de l’IP

172.16.76.229. Pour cela le moyen le plus simple est de créer un alias sur l’adaptateur

réseau à l’aide de la commande ifconfig comme ceci, si l’adaptateur est bien eth0 :

ifconfig eth0:0 172.16.76.230 netmask 255.255.0.0

o Pour pérenniser l’adaptateur sous Debian, le fichier /etc/network/interfaces sera complété

ainsi :

# The loopback network interface auto lo iface lo inet loopback # VIP auto eth0:0 iface eth0:0 inet static address 172.16.76.230 netmask 255.255.0.0 broadcast 172.16.255.255


HIFDI SAMI

network 172.16.0.0 # The primary network interface allow-hotplug eth0 #NetworkManager#iface eth0 inet dhcp

Les commandes ifup et ifdown suivit de l’interface (eth0:0 ou etho0:1) permettent

de monter ou démonter l’interface réseau.

5ème étape : Valider le fonctionnement du cluster de répartition de charge

Depuis un poste client et via un navigateur Web, une connexion doit être établie sur l’IP de la VIP.

Si tout se passe bien, alors la page Web correcte doit s’afficher :

Je suis le serveur réel 1 ou Je suis le serveur réel 2

Sur le redirecteur

Taper : ipvsadm -Ln

La réponse doit ressembler à :

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn

InActConn

TCP 172.16.76.230:80 rr

-> 192.168.76.231:8001 Masq 1 1 0

-> 192.168.76.232:8001 Masq 1 0 0


HIFDI SAMI

6ème étape : Installer et configurer sur les deux serveurs Web les services DRBD

DRBD (Distributed Replicated Block Device) est un outil qui permet de synchroniser (par réplication) des

périphériques de stockage (disque dur, partition, volume logique) entre deux serveurs via le réseau. Celui-

ci s'apparente à du RAID1 sur IP

Créer une partition identique sur les 2 serveurs web, sur le 2em disque:

Lancer l’utilitaire de disque

o Sélectionner le 2em disque

o Formater le disque : Master boot record

o Créer une nouvelle partition

Capacité : 5 Go

Format : ext3

Nommer : sdb1

Entrez les commandes suivantes :

- Fdisk /dev/sdb

- n

- P

- p

- 2048

- 10485760 (=5*2048*1024)

- w

Installer et configurer drdb8 :

Installer le paquet drdb8 : apt-get install drbd8-utils

Configurer les fichiers : /etc/drbd.d/global_common.conf et /etc/drbd.d/cluster.res o /etc/drbd.d/global_common.conf :

global { usage-count yes; # minor-count dialog-refresh disable-ip-verification } common { protocol C; handlers { } startup { degr-wfc-timeout 120; become-primary-on both; # wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb; }


HIFDI SAMI

disk { # on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes # no-disk-drain no-md-flushes max-bio-bvecs } net { allow-two-primaries; after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; # sndâ€•buf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers # max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret # after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork } syncer { verify-alg md5; rate 1000M; # rate after al-extents use-rle cpu-mask verify-alg csums-alg } }

o /etc/drbd.d/cluster.resf

resource r0 { protocol "C"; on sisr4-web1-13 { device /dev/drbd1; disk /dev/sdb1; address 192.168.76.231:7789; meta-disk internal; } on sisr4-web2-13 { device /dev/drbd1; disk /dev/sdb1; address 192.168.76.232:7789; meta-disk internal; } }

Ces manipulations doivent être effectuées à l’identique sur les deux serveurs web :

drbdadm create-md r0 pour initialiser r0 définie dans le fichier cluster.res.

/etc/init.d/drbd start pour démarrer le service drbd.

drbdadm connect r0 pour connecter la ressource r0 au serveur.


HIFDI SAMI

cat /proc/drbd permet d’afficher l’état de la ressource r0. Sur le serveur web1 : Lancer les commandes :

Pour initialiser la synchronisation des données entre les deux serveurs : drbdadm -- --overwrite-data-of-peer primary r0

Pour vérifier que le serveur est connecté et déclaré primary : cat /proc/drbd version: 8.3.7 (api:88/proto:86-91) srcversion: EE47D8BF18AC166BE219757 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r---- ns:4300921 nr:3429 dw:110206 dr:8403592 al:39 bm:260 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Pour forcer la ressource r0 à primary : drbdadm primary r0

Sur le serveur web2 : Lancer les commandes :

Pour forcer la ressource r0 à primary : drbdadm primary r0

Pour vérifier que les serveurs sont connectés et déclarés primary : cat /proc/drbd version: 8.3.7 (api:88/proto:86-91) srcversion: EE47D8BF18AC166BE219757 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r---- ns:4300921 nr:3429 dw:110206 dr:8403592 al:39 bm:260 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

7ème étape : Valider la synchronisation des données par DRBD

Pour pouvoir écrire sur les disques des deux serveurs et synchroniser immédiatement les données sur la

ressource des deux serveurs, ces ressources doivent être déclarées primary.

Ainsi la commande cat /proc/drbd lancée sur chaque serveur doit fournir un résultat de la forme :

version: 8.3.7 (api:88/proto:86-91)

srcversion: EE47D8BF18AC166BE219757

0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----

ns:4300921 nr:3429 dw:110206 dr:8403592 al:39 bm:260 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

On peut aussi utiliser la commande : service drbd status.

Le service drbd est maintenant prêt à fonctionner, il faut configurer le système de fichiers à synchroniser.


HIFDI SAMI

8ème étape : Configuration le système de fichiers en cluster OCFS2

Ocfs2 est un système de fichiers qui permet l’écriture simultané sur un même fichier. Ici sa mise en place

est nécessaire afin de posséder des données parfaitement synchronisées.

Sur le serveur web1 et web2 :

Installer les paquets ocsf2 : o apt-get install ocfs2-tools ocfs2console

Configurer le fichier: « /etc/ocsfs2/cluster.conf »

Ce fichier doit être configuré à l’identique sur les deux serveurs web :

cluster: node_count = 2 name=ocfs2 node: ip_port = 7777 ip_address = 192.168.76.231 number = 1 name = sisr4-web1-13 cluster = ocfs2 node: ip_port = 7777 ip_address = 192.168.76.232 number = 2 name = sisr4-web2-13 cluster = ocfs2

Configuration OCFS2 :

o Exécuter la commande : dpkg-reconfigure ocsf2-tools

(Valable sous debian, sinon exécuter service o2cb configure)

Répondre aux questions comme ci-dessous, accepter les options par défaut :

Configuring the O2CB driver. This will configure the on-boot properties of the O2CB

driver. The following questions will determine whether the driver is

loaded on boot. The current values will be shown in brackets ('[]').

Hitting <ENTER> without typing an answer will keep that current

value. Ctrl-C will abort.


HIFDI SAMI

Load O2CB driver on boot (y/n) [y]: Cluster stack backing O2CB [o2cb]: Cluster to start on boot (Enter "none" to clear) [ocfs2]: Specify heartbeat dead threshold (>=7) [31]: Specify network idle timeout in ms (>=5000) [30000]: Specify network keepalive delay in ms (>=1000) [2000]: Specify network reconnect delay in ms (>=2000) [2000]: Writing O2CB configuration: OK Cluster ocfs2 already online

o Redémarrer le service ocfs2 :

service ocfs2 restart

service o2cb restart

o Effectuer les tests pour ocfs2 :

Pour vérifier que le service est activé : ps –ef | grep o2

Sur le serveur web1 uniquement :

Formater la ressource /dev/drdb1 au format ocsf2 : o mkfs.ocfs2 /dev/drbd1

Créer un répertoire sur le système de fichiers du serveur Web sur lequel on « montera » le système de fichier déclaré par la ressource DRBD au format OCSF2.

o mkdir /mnt/Donnees_Web

Monter la ressource sur l’arborescence et la rendre disponible : o mount.ocfs2 /dev/drbd1 /mnt/Donnees_Web

Script de démarrage sur les serveurs web1 et web2 : La ressource DRBD doit être impérativement connectée et déclarée primary avant le lancement des services ocfs2 puis o2cb. Pour être sûr que le système prenne en compte la ressource DRBD comme ressource PRIMARY et que le système de fichier OCSFS2 /dev/drbd1 soit bien « monté » sur l’arborescence : Générer le script suivant : /etc/init.d/mountdrbd.sh

# connexion en primary de la ressource DRBD drbdadm primary r0 #lancement du service O2CB /etc/init.d/o2cb start # montage du disque sur le systeme de fichier mount.ocfs2 /dev/drbd1 /mnt/donnees_web


HIFDI SAMI

Le rendre exécutable et créer le lien symbolique vers /etc/rc3.d/S99mountdrbd.sh afin que celui-ci soit exécuté au démarrage du serveur.

Chmod +x /etc/init.d/mountdrbd.sh update-rc.d mountdrbd.sh defaults

9ème étape : Valider le bon fonctionnement du cluster OCFS2

Validation la synchronisation des modifications de données sous le contrôle de DRBD + OCSF2 : Sur le serveur Web1 : Copier le fichier index /var/www/index.html vers /mnt/Donnees_Web :

cp /var/www/index.html /mnt/Donnees_Web Modifier le fichier /etc/apache2/sites-available/default :

La directive DocumentRoot doit ponter vers : /mnt/Donnees_web

Sur le serveur Web2 : Modifier le fichier /etc/apache2/sites-available/default :

La directive DocumentRoot doit ponter vers : /mnt/Donnees_web Vérifier la synchronisation dans le répertoire /mnt/Donnees_Web par la présence du fichier index.html. Modifier le contenu du fichier HTML afin que les deux serveurs web affichent une page Web identique

10ème étape : Les tests de fonctionnement du cluster serveur Web hautement disponible

A partir d’un poste client : o Effectuer une connexion au site web : http://172.16.76.230

Sur le serveur sisr4-web1-13 : o Modifiez le contenu du fichier /mnt/Donnees_web/page1.html

Sur le poste client : o Effectuer une connexion au site web : http://172.16.76.230 o Constater que la page affichée a été modifiée.

Arrêter le serveur web sisr4-web1-13.

Sur le poste client : o Constater que la connexion au site web est toujours active après rafraichissement (Ctrl+F5). o

http://172.16.76.230/

http://172.16.76.230/

tp6 : mise en œuvre d’une solution de haute disponibilité pour un … · 2016-05-22 ·...

Documents