FAMEL Yoan 08/10/2015PAYET YoannBTS SIO – SISR

SISR4Administration des systèmes

Haute disponibilité et répartition de charge des serveursHeartbeat / Redirection de port

Table des matièresIntroduction .......................................................................................................................................... 2Mise en place d'une solution de haute disponibilité avec Heartbeat .................................................... 3

Architecture réseau ......................................................................................................................... 3 Création des serveurs ...................................................................................................................... 4

Création d'une machine virtuelle dans le serveur ESXi ............................................................. 5Configuration des interfaces .......................................................................................................... 13Configuration du cluster ................................................................................................................ 14

Configuration d'Heartbeat ........................................................................................................ 16Test du cluster ................................................................................................................................ 21

Mise en place d'un routeur avec redirection de port ........................................................................... 23Tests de la solution finalisée .......................................................................................................... 25

1 / 25

Introduction

L'objectif de ce TP va être de comprendre le concept de haute disponibilité, de la répartition des charges ainsi que la complémentarité au niveau des serveurs.

Pour cela nous aborderons les concepts de manière à ce que nous sachions les mettre en œuvre de façon séparée ou conjointement en passant à travers les mécanismes qui les composent, nous pourrons donc en démontrer les limites et les avantages que ces solutions proposent.

Nous utiliserons la solution LVS – à proprement parler, Linux Virtual Server – qui comprend les logiciels ipvs, Heartbeat, Keepalived, etc.

Il est conseillé de visiter le site de LVS afin d'obtenir de plus amples informations à propos de ces solutions :

Ce que nous retiendrons : LVS est une technologie d'équilibrage de charge s'effectuant sur la couche 4 du modèle OSI.

« Une machine LVS est donc une sorte de répartiteur qui va capter tous les flux entrant pour les répartir sur un ensemble de serveurs, invisible au reste du monde, et ainsi répartir la charge. De ce fait, lorsque les clients contacteront notre API, ils contacteront notre LVS, qui se chargera de répartir le trafic à tour de rôle sur la machine API-01 et API-02. »

2 / 25

Mise en place d'une solution de haute disponibilité avec Heartbeat

Plaçons nous en contexte professionnel.

Lors de l'activité suivante nous allons mettre en place une architecture en deux temps, nous nous concentrerons tout d'abord sur le cluster (ensemble de deux serveurs) et sa haute disponibilité, pour enfin y ajouter un routeur avec une redirection d'adresse et de port suivit d'un accès à internet.

Architecture réseau

Nous nous baserons par rapport au plan d'adressage et schéma suivant,

3 / 25

Création des serveurs

Notre réseau nécessite deux serveurs basés sous Debian 7 et créés sur ESXi, Virtualbox ne permet pas ce genre de configuration.

Pour notre besoin nous importerons un master Debian depuis la banque de données (datastore) d'ESXi que nous clonerons avec 1Go de mémoire vive, 20Go de disque dur alloué en Thin provisioning afin d'en créer deux.

Nous procéderons en deux temps :

Création d'un serveur master ;

Effectuer sa duplication pour créer nos serveurs web.

L'interface de ESXi est la suivante :

Nous allons donc voir ensemble la façon dont il faut créer et configurer une machine sous ESXi afin de pouvoir par la suite la virtualiser et l'utiliser, nous préciserons que notre exemple est généraliste et qu'il ne fait pas référence à notre cas, cependant il s'applique dela même façon avec nos serveurs web actuels.

4 / 25

Création d'une machine virtuelle dans le serveur ESXi

Dans un premier temps, nous allons créer un répertoire pour notre future machine qui contiendra les données d’installation. Puis nous allons copier si possible l'image d'une machine modèle (Master) ayant l'extension .vmdk (cette dernière représente la décompression d'une image ISO), dans le répertoire créer précédemment (figure suivante),

Ainsi que comme indiqué dans l'exemple ci-dessous :

Dans cet exemple notre machine master Master-DB7.vmdk est copié dans le répertoire WEBNDF lui même compris dans le répertoire parent HM-PPE3.

L'image à bien été copiée.

5 / 25

Maintenant que nous avons copié notre image .vmdk nous allons créer notre machine virtuelle qui sera en référence avec cette même image. Pour cela un clique droit sur notre pool de ressource nous le permet :

Après avoir effectué cette action nous aurons une interface qui nous accompagnera tout au long de la création de la machine. Nous choisissons une configuration personnalisée :

On y précise ensuite le nom de la machine virtuelle que l'on va créer, dans notre cas le nomcorrespondra au serveur Web :

6 / 25

On sélectionne ensuite le stockage de destination dans lequel les fichiers de la machine seront enregistrés après modification. Dans notre cas, ce sera le datastore se trouvant à la racine du serveur :

Puis nous choisissons la version compatible avec Vmware et ESXI :

À l'étape suivante, nous devons renseigner la version ainsi que l'OS que notre serveur utilisera :

L'utilisateur peut à sa guise changer l'OS de la machine, du moment que celle-ci est en adéquation avec l'image qu'il aura sélectionné au préalable.

7 / 25

Tout dépend ensuite du nombre de CPU compris par l'hôte. Généralement on choisis 1 dans les deux cas (figure suivante) :

La configuration de la mémoire vive dépendra du ou des services que nous allouerons à notre serveur. Pour ma part 1 GO de RAM sera alloué car la virtualisation actuelle ne nous poussera pas à utiliser une grosse configuration :

On peut définir également le nombre de carte réseau que va utiliser notre machine virtuelle. Dans notre cas 1 NIC (Network interface communication) est suffisante car la machine est de type serveur et non routeur logiciel :

8 / 25

On sélectionne le contrôleur SCSI par défaut :

En tenant compte qu'au début nous avons copié (si c'est le cas) notre image .vmdk, nous allons établir le lien avec cette dernière. Pour cela, il faut donc choisir, utiliser un disque virtuel existant.

On montre le chemin de l'image copié à l’assistance de création de machine virtuelle de ESXi :

Les étapes qui suivent sont à laisser par défaut, c'est donc après celle-ci que nous cliquons sur Terminer pour créer notre machine virtuelle.

9 / 25

Nous faisons bien évidemment la même manipulation pour chacun de nos deux serveurs web s'appliquant à notre cas.

Une fois nos deux serveurs créés nous les démarrons :

Nous utiliserons la passerelle de l'établissement afin de pouvoir mettre à jour les paquets grâce à :

apt-get update

Les deux serveurs se nommeront successivement srvweb1 et srvweb2.

Une fois les deux serveurs prêts à l'emploi, il nous suffit de les allumer et de leur attribuer une adresse IP différente de manière à ce qu'ils puissent accéder à Internet pour la suite.

Aucunes adresses du schéma n'est pour le moment configurée.

Nous installerons le service Apache2 sur les deux serveurs web avec :

apt-get install apache2

10 / 25

Nous constatons sa bonne installation par la commande suivante :

Nous adapterons également l'affichage de notre page web pour que par exemple, le programmeur puisse s'y retrouver lors de l'implantation de ses pages html/php :

nano /var/www/index.html

Cette configuration sera également utile plus tard pour la constatation du fonctionnement de la méthode Round Robin.

Par exemple sur srvweb1 :

11 / 25

Une fois ce test effectué nous constatons que localhost fonctionne, notre serveur est donc opérationnel.

Nous allons également renommer nos deux serveurs en leur attribuant un nom les différenciant des noms de machines virtuelles srvweb1 et srvweb2.

Pour cela la commande suivante est suggérée :

nano /etc/hostname

Nous installerons ensuite le package Heartbeat sur chacun des deux serveurs en faisant :

apt-get install heartbeat

Afin de respecter l'architecture du schéma et éviter les conflits d'adresses nous utiliserons le commutateur virtuel présent sur ESXi et représenté par la figure suivante,

12 / 25

Configuration des interfaces

Nos deux serveurs sont ainsi reliés au commutateur virtuel (sur la baie de brassage) qui sera lui-même relié au routeur (également connecté sur la baie de brassage) un peu plus tard dans la suite de ce TP, il s'agit maintenant d'attribuer l'adresse IP définitive renseignée sur le schéma en y ajoutant également la passerelle définitive pour chacun des serveurs :

SRV1

auto eth0iface eth0 inet static address 172.16.61.10 netmask 255.255.0.0 gateway 172.16.61.254

SRV2

auto eth0iface eth0 inet static address 172.16.61.40 netmask 255.255.0.0 gateway 172.16.61.254

Pour terminer la configuration des deux serveurs et que tout ces paramètres sois pris en compte nous les redémarrons avec la commande :

reboot

13 / 25

Configuration du cluster

Qu'est ce qu'un cluster ?

« Un « cluster » (en français « grappe ») est une architecture composée de plusieurs ordinateurs formant des nœuds, où chacun des nœuds est capable de fonctionner indépendamment des autres. »

Vous comprendrez donc pourquoi, dans la suite de ce TP, nous utiliserons le terme « node » signifiant « nœud ».

La suite va consister à permettre d'améliorer la disponibilité du service web en faisant fonctionner pour cela plusieurs machines en même temps (deux minimum).

Le principe du cluster est que chaque machine va vérifier l'activité d'une autre et ainsi de suite, de cette façon, si un des serveurs tombe en panne, un autre viendra assurer son service à sa place.

Un cluster possédera une adresse IP commune.

Pour récapituler, le cluster est composé de nodes, bien qu'il regroupe plusieurs ordinateurs, il ne comporte qu'une seule adresse IP.

Dans notre cas :

14 / 25

Nous allons à présent éditer le fichier hosts de nos deux serveurs avec la commande :

nano /etc/hosts

Pour le premier serveur,

Puis le deuxième,

Pour vérifier la bonne résolution des noms nous faisons un test ping entre les deux serveurs web :

15 / 25

La bonne réception des requêtes prouve la bonne configuration des deux machines virtuelles. On constate également que nous pouvons utiliser les noms des serveurs à la place de leurs adresses.

Configuration d'Heartbeat

Hearbeat est un logiciel qui se configure grâce à trois fichiers principaux, ces fichiers serontles mêmes sur les deux serveurs, il faut donc les copier sur chacune des machines composant le cluster (SRV1 et SRV2).

Nous allons donc créer sur le premier serveur son fichier de configuration selon l'arborescence suivante :

nano /etc/ha.d/ha.cf

16 / 25

Les valeurs chiffrées inscrites dans le fichier sont en secondes (mais peuvent être paramétrés en millisecondes avec ms).

En examinant de plus près les directives du fichier de configuration nous déterminerons que,

Elément Explicationsbcast Interface réseau par laquelle on effectue la prise de pouls.debugfile Fichier de débogage à utiliser.logfile Indique le log d'activité à utiliser (à consulter en cas d'erreurs).logfacility Indique que l'on utilise la facilité syslog en plus.keepalive Indique le délai entre deux battement de pouls (en secondes).deadtime Indique le temps nécessaire avant de considérer un nœud comme

étant mort. warntime Délai avant d'envoyer un avertissement pour les pouls en retard.initdead Délai spécifique pour les configurations où le réseau met un certain à

démarrer. udpport Indique le port à utiliser pour s'assurer de la continuité de service des

serveurs.node Nom des machines du cluster, similaire au contenu de /etc/hostname.auto_failback Comportement à adopter si le node maître revient dans le cluster.

On = tout est transféré sur le node maîtreOff = les services continuent de tourner sur l'esclave même quand le maître revient dans le cluster, cela permet un retour à la normale lorsque la charge de production est moins importante.

Nous allons maintenant définir le node maître, l'adresse IP du cluster ainsi que les services devant être assurés.

17 / 25

Dans un premier temps nous allons mettre en place uniquement l'adresse IP virtuelle du cluster selon notre schéma.

Toujours sur notre premier serveur nous créons le fichier suivant :

nano /etc/ha.d/haresources

Puis nous le complétons,

Il est également possible d'indiquer quel service est associé à l'IP virtuelle du cluster avec,

SRV1 Ipaddr::172.16.61.30 apache2

Ou de partager plusieurs adresses IP virtuelles au sein d'un même cluster en faisant,

SRV1 Ipaddr::172.16.61.30/16/eth0 Ipaddr::172.16.61.31/16/eth0

Mais nous n'en aurons pas l'utilité dans notre cas.

Il faut également gérer le fait que les nodes puissent se reconnaître entre eux grâce à une authentification mutuelle, cela pourrait éviter par exemple qu'un serveur pirate s'introduisedans le réseau.

18 / 25

Toujours sur le premier serveur, nous créons le fichier destiné à l'authentification,

nano /etc/ha.d/authkeys

Puis nous le complétons,

Nous protégeons également ses droits d'accès en réservant l'accès à un utilisateur unique :root,

En examinant de plus près les directives du fichier de configuration nous déterminerons que,

Elément Explicationsauth 1 Système d'authentification utilisé,

1 = choix md51 md5 « phrase secrete du cluster » Choix md5 comportant une chaîne de

caractère commune aux deux serveurs.2 crc Deuxième choix, non sécurisé.

19 / 25

À savoir qu'il est également possible d'utiliser une troisième option SHA-1 afin d'apporter une sécurité supplémentaire comme suit,

3 sh1 « autre phrase secrete du cluster »

Nous ne tiendrons pas compte de l'ordre des options dans le fichier.

Il est donc primordiale que les authentifications soit les mêmes sur les deux machines :

La configuration du premier serveur est maintenant terminée, le second node sera configuré exactement de la même façon.

Les deux serveurs étant prêts nous les relançons tout les deux dans un ordre précis, c'est àdire SRV1 en premier, puis SRV2, grâce à la commande suivante,

service heartbeat stopservice heartbeat start

Puis nous vérifions l'activité du service pour constater que tout va bien :

20 / 25

Test du cluster

Nous allons dans un premier temps effectuer un test localement pour déterminer si le service est opérationnel, à partir du client B.

Nous branchons donc notre station au commutateur auquel sont raccordés les deux serveurs, le système d'exploitation n'a aucune importance.

Nous choisirons donc Windows.

Nous configurons l'adresse IP du client ainsi que sa passerelle comme indiqué sur le schéma, puis nous envoyons une requête ping sur l'adresse IP virtuelle du cluster,

La requête aboutie, la communication fonctionne bel et bien entre les deux matériels.

Il s'agit maintenant de tester le fonctionnement depuis notre navigateur, pour cela, nous saisissons l'adresse IPV du cluster dans le champ URL :

21 / 25

Nous remarquons que la page présente sur le serveur maître s'affiche.

Cependant, si nous simulons une panne sur ce dernier en éteignant la carte réseau et que nous actualisons la page web nous remarquons alors que le serveur esclave prend le relais et cela toujours avec la même adresse IP du cluster :

La redondance de serveur est donc opérationnelle et avantageuse pour la société.

En rallumant la carte, le serveur maître reprend alors son service et la page web affiche à nouveau « SRV1 ».

22 / 25

Mise en place d'un routeur avec redirection de port

La solution de cluster que nous venons de mettre en place ne sera pas accessible directement via le net, les serveurs sont en général placés dans un réseau dédié ou encore dans une DMZ derrière un ou plusieurs routeurs.

Via Internet, l'adresse IP privé du cluster ne sera pas accessible par un utilisateur, ce sera l'adresse IP publique qui sera sollicitée (NAT), ce sera donc le routeur qui va assumer le rôleet la redirection des requêtes web provenant des internautes vers le serveur web.

C'est ce que nous appellerons la redirection d'adresse (ou de port).

Pour illustrer nos propos nous utiliserons le tableau ainsi que le schéma suivant,

Cluster Routeur

IP : 172.16.61.30 IP : 192.16.193.20

Port 80 Port 80

23 / 25

Nous allons donc maintenant mettre en place notre routeur et le configurer.

Physiquement, nous le relions depuis son interface f0/1 au commutateur puis de son interface f0/0 à la station Client A.

Configuration de RTR

Router(config)#hostname RTR# On configure son nom

RTR(config)#interface fastEthernet 0/0RTR(config-if)#ip address 192.16.193.20 255.255.255.0RTR(config-if)#no shut# On attribue une adresse et on active l'interface f0/0

RTR(config)#interface fastEthernet 0/1RTR(config-if)#ip address 172.16.66.254 255.255.0.0 RTR(config-if)#no shut # On attribue une adresse et on active l'interface f0/1

RTR(config)#ip routing # On active le routage

RTR#show ip route C 192.16.193.0/24 is directly connected, FastEthernet0/0 # On vérifie la route sur la table de routage

Une fois les différentes interfaces activées, nous vérifions la connectivité avec un test ping entre le client A et B.

RTR(config)#$static tcp 172.16.193.30 80 interface fastethernet 0/0 80 # On configure la redirection d'adresse et de port

RTR(config)#interface fastEthernet 0/0 RTR(config-if)#ip nat outside# On active la redirection en sortie RTR(config)#interface fastEthernet 0/1 RTR(config-if)#ip nat inside# On active la redirection en entrée

Il est intéressant de comprendre le fonctionnement de la redirection en s'aidant du schémaainsi que des commandes de RTR.

24 / 25

Tests de la solution finalisée

Lorsque nous testons à présent le fonctionnement du service avec le navigateur, nous saisissons l'adresse IP externe du routeur dans l'URL :

Nous constatons alors que la page web du cluster s'affiche.

Nous déclenchons une panne et constatons une fois de plus que le serveur secondaire prend le relais.

Conclusion

Je recommande l'utilisation du service Heartbeat en entreprise qui permettra ainsi de déterminer si un service est hors d'usage ou non. Il permet aussi de changer d'adresse IP entre les deux machines (ou plus) à l'aide de mécanismes ARP avancés.

Le basculement qui s'effectuera grâce à l'aide d'un Load-Balancer (TP suivant) sera alors transparent, la disponibilité permanente des serveurs sera alors respecté et mise en place et le système d'information passera outre la panne.

25 / 25