Il était une fois une base de données qui devait être sauvegardée sur un réplica.

« - Ouais, quelle galère, du SQL, encore du SQL, toujours du SQL ! Pffff.
- Pffff ? Ne recommence pas, s'il te plait !
- Ben, tu ne trouve pas ça terrible, le SQL ?
- Ben non, c'est jeuste utile d'avoir une sauvegarde de la base de données sans devoir gérer le truc. une fois que c'est en place, plus besoin d'y toucher.
- Watch, v'là le chef !
- (chef) Dites les collègues, vous ne trouvez pas que c'est dommage d'avoir un réplica qui ne soit pas productif ?
Avec l'augmentation des connexions, on pourrait le mettre en ligne, non ?
Essayez voir de me trouver une solution afin de répartir les connexions sur les deux serveurs.
Allez, au boulot !

 

- Pffff.
- Ouais : Pffff.

 

Bon, la répartition est une très bonne solution pour réduire la charge individuelle de chaque serveur.
En plus, il existe des solutions très simples dans notre cas : HA Proxy

 

Cependant, la répartition n'est pas seulement visible dans le domaine des connexions au serveurs web. Il existe de multiples répartitions

 

Le cours sur la répartition va explorer rapidement plusieurs technlogies de répartition

Les organisations sont très concernées par des répartitions de charges face à la montée en puissance des connexions.

Pas de nouveauté sur les organisations. Cependant, la répartition est un enjeu de sûreté du SI pour éviter les surcharges des serveurs, des accès aux services, tant du LAN vers internet que d'internet vers nos services en DMZ.

 

Pour le particulier, cela est moins important côté client, mais les entreprises doivent assurer une bonne capacité de connexion pour offrir des services fluides et largement disponibles

Personne n'admettrait que les grand serveurs afficheraient une page du type : Erreur 501 Erreur interne, service non disponible pour l'instant, réessayez plus tard.

Ah bon ? ça vous est arrivé ? avec les impôts ou parcoursup, la veille de l'échéance de paiment ou d'inscription ...

 

Contraintes

Ce phénomène est souvent dû à la limitation de la puissance des serveurs pour avoir un débit réseau correct, une capacité de traitement suffisante en charge, complexité des traitements (chiffrement, maintien des sessions, etc.).

OK, Cela touche essentiellement les service web (http)

Hélas, mettre des serveur en cluster n'est pas simple et l'évolution de la demande nécessite une scalabilité importante (augmentation de l'architecture en suivi de la charge, innovations soft et hard).

 

Besoins

Les besoins sont donc assez bien identifiés :

1. Besoin de haute disponibilité
   • Angl. : High Availability
   • Garantire de service
2. Réponse avec la répartition de charge
   • Angl. : Load Balancing
   • Distribuer le travail
   • Répartir les connexions

 

Attention

Couche 3 ou 2 : pour le routage ou pour le switching. Mais il ne s'agit pas vraiment de ça ici.

Couche 5 et plus ...

DFS : ce n'est pas ça, même si je le détaille plus loin.

On est sur la redondance de machines, de services.

Ça entre dans les plans de reprise et de continuité d'activité (PRA, PCA) pour l'aspect de continuté du service en mode dégradé quand l'un des serveur/service redondant est en panne.

« - What a fuking nice network!
- Tu parles anglais, maintenant ?
- Ben ouais, je speek very nice british.
- Mouais.»

 

Ici, on va utiliser deux routeurs et les configurer pour qu'ils se partagent la charge de connexion vers internet :

• En ayant une même adresse IP virtuelle dans le réseau (protocole HSRP) : répartition de charge sur des passerelles avec IP virtuelle.
• En ayant une configuration qui privilégie la moitié des VLANs sur un routeur et allouer l'autre moitié au second routeur (voir routage statique)
• En utilisat des routes "flottantes" dont la DA est supérieure à la DA normale (voir routage dynamique)
• En utilisant le DHCP pour configurer les postes avec des passerelles différentes (voir service DHCP)
• En configurant des valeurs d'interfaces permettant de privilégier une route, le second routeur servant de secours au premier
• Etc.

« - Facile, il suffit d'avoir plusieurs serveurs DHCP dans le réseau
- Ouais! et le plus proche du client, celui qui répond le plus vite, sera adopté par le client.
- (chef) Eh les gens! Vous pensez pas au risque de conflit d'adressage ?
- Ah. ouais, pas bête.
- C'est pour ça que je suis chef!
- Il suffit de mettre des plages différentes à chaque serveur et le tour est joué. Tadaaaa! »

 

Oui mais voilà, les serveurs sont aussi intelligents et ils n'ont pas besoin de plages différentes ou autre artifice de sécurité sur les adresses IP.
Les serveurs DHCP font un ping avant de louer une adresse. Et si celle-ci est déjà prise, il ne la donnent juste pas.

 

« - Mais alors pas de problème de conflit d'adresse IP ? »

Normalement, on est à l'abri des adresses en double sauf dans le cas où une réservation, par exemple pour un serveur, doit obtenir une adresse qui est dans une plage dynamique. Alors, si le serveur démarre après le DHCP, celui-ci pourrait louer l'adresse du serveur à un client temporaire et le serveur n'aurait pas son adresse. Dommage pour l'accès aux services!

 

Par ailleurs, la répartition se fait vraiment toute seule sur la "proximité" réseau du serveur DHCP le plus proche du client.

Ici, nous sommes associés à la répartition de serveurs DHCP vue ci-dessus.
Les serveurs DHCP fournissent une adresse IP durant un certain bail aux clients et indiquent aussi l'adresse de la passerelle ainsi que les DNS du réseau.

 

On obtient, en fonction du DHCP contacté, une forme de répartition de passerelle et de DNS.

Windows server propose une fonctionnalité nommée DFS (Distribued file system) qui permet de répartir le système de fichier sur plusieurs serveurs.
Un peu comme des disque durs en lignes qui seraient montés de façon transparente dans l'arborecence des fichiers.

Cette fonction permet aussi de faire une réplication des données sur plusuieurs serveurs (comme du RAID).

Il existe un outil peu connu pour cet usage, à notre niveau, qui permet de faire de la répartition de charge entre des serveurs web.

C'est cette répartition de charge que nous allons développer ci-après.

« Hello!, Dans la famille des pages web, je voudrais le grand-père
- Ok, ne quitte pas, je vais la chercher sur le net ...
- Bon, alors, ça vient ?
- Euh, j'ai trouvé ça : 501-Internal server error. A mon avis vous êtes plusieurs à demander cette page
- C'est quoi ce site ? Ils dorment là bas ?
- JSP. Il doit sûrement n'y avoir qu'un seul serveur et il est overbooké. J'y retourne.
- Mouais. Mais qu'ils se dépèchent, le chef me tanne pour cette doc'. Grmblmbl. Si c'est pas la base de données, c'est le serveur web!
- On verra, seul le hazard des connexions me permettra d'obtenir la page. (hm. Jamais content, c'ui-là)
- Bon, j'attend. Y aurait pas un café dans le coin ? »

 

Rotation DNS (round robin)

Le serveur DNS est capable d'adresser des requêtes à différents serveurs, en rotation sur la liste des serveurs indiqués

Inconvénient : incapacité de traiter les session et les clés de chiffrement (SSL/TLS)

On envoie les requêtes tour à tour au 1er, au 2nd, au troisième, etc. … jusqu'au dernier et on recommence au 1er serveur.
Cette rotation est faite avec un DNS en donnant plusieurs adresses à un même nom de serveur (serveurs réels en réplication).

L'algo de rotation est nommé round robin.

 

Répartir les utilisateurs par serveur, les données aussi

NAT routé

L'adresse du service est changée en adresse du serveur physique

Avantage : aucune config de serveur à prévoir

Inconvénient : charge importante pour le routeur/répartiteur en NAT bidirectionnel.

 

NAT logiciel

Le serveur de nat se subtitue aux serveurs physiques.

Avantage : le serveir n'est pas directement accessible => 1 niveau de protection supplémentaire

Inconvénient : charge importante pour le serveur de NAT : le servuer doit être plus puissant qu'un routeur ou switch dans le domaine du routage/NAT/PAT.

 

 

Répartition des données

Un serveur frontal fait l'assemblage de données statiques (images, fond de page, textes fixes, etc.) et un serveur de données statiques (données client, résultats de filtres, etc.).

Avantage : les serveurs ont une charge limitée mais le serveur fonrtal supporte beaucoup de charge de calcul

Inconvénient : charge importante pour le serveur frontal, répartir les données en données dynamiques ou statiques n'est pas à la mode et devient de plus en plus difficile à réaliser si c'est la seule technique utilisée.

1. La surveillance des serveurs :
   • Angl. : Healt check
   • test réguliers : ping = réponse matérielle, tentatives de connexion TCP : réponse service, requête de test : réponse du service et de l'application
   • requête spécialisée pour le répartiteur
   • Analyse de mots clé dans le contennu : détournement du contenu, erreur de fonctionnement
2. Cela implique une charge réseau conséquente
3. Le timing des tests est important pour :
   • éviter la surcharge
   • effectuer des détections rapides

 

La répartition différentiée

• Charger plus le serveur le plus rapide
  • déséquilibre des accès aux serveurs
  • le serveur le moins chargé ne fait rien
• si les sessions sont longues, c'est bien
• si les sessions sont courtes, forte fluctuation des connexion => pas très bon, augmentation de la charge de gestion des sessions

 

Méthode cyclique

• 1 serveur après l'autre (comme dans la répartition DNS)
• l'adresse IP du client est liée au serveur, sinon la session est perdue (transaction en cours, cookie temporaire, chiffrement
• Difficile à gérer dans un environnement à faible clients (intranet), les clients risquent de changer de serveur entre deux connexions à cause de la rotation. Meilleur si le nombre de client est élevé (internet).

Persistance des sessions

• Il faut maintenir l'association client/serveur à cause du maintien des sessions
• cookies de session
• environement client sur un seul serveur
• maintenance d'une table d'association cookie/serveur
• si la durée de vie du cookie est longue : gros fichier de cookies => saturation du serveur
• si la durée de vie du cookie est courte : basculement sur un autre serveur => perte de l'environnement client

Persistance des sessions avec des cookies

• Il faut maintenir l'association client/serveur à cause du maintien des sessions
• cookies de session
• environement client sur un seul serveur
• maintenance d'une table d'association cookie/serveur
• si la durée de vie du cookie est longue : gros fichier de cookies => saturation du serveur
• si la durée de vie du cookie est courte : basculement sur un autre serveur => perte de l'environnement client

Insersion de cookie serveur

1. Le répartiteur envoie un cookie avec id du serveur
2. Le client accepte plusieurs cookies (pas sûr)
3. Cache frontaux qui peuvent envoyer le même cookie à tout le monde = surcharge d'1 seul serveur

 

- Ah (gratt, gratt, gratt, tilt!) ben, c'est simple. On inverse le proxy !
- ?? (il est fou ?)
- Ben oui, le serveur distant, c'est nous, les clients, c'est les autres
- Euh, c'est ce que je viens juste de dire ...
- Et notre "proxy renversé", il stocke les pages les plus demandées ou fait les calculs les plus compliqués, comme le chiffrement et la gestion des session et le tour est joué!
- Ah ouaaais, pas bêêête »

« Hello!, Dans la famille des pages web, je voudrais le grand-père
- Ok, ne quitte pas, je vais la chercher sur le net ... Ah! Tiens, la voilà.
- Euh, on est plusieurs. Euh vraiment
- Bon, j'y retourne pour chacun de vous et je vous la redonne.
- Euh, sûr ? parce qu'on est vraiment beaucoup là. Et on la veut souvent, cette page.
- Et puis quoi encore, je ne suis pas votre esclave ! M'enfin.
- Euh, enfait, tu pourrais en garder une copie, que tu mettrais à jour de temps en temps, comme ça, pas besoin de courrir sur le serveur à chaque demande.
- Eeeh. Mais tu es un petit malin, toi. C'est pas bête, ça. Je vais garder les pages courantes dans mon cache, à proximité de vous, les demandeurs fous.
- Waaa. Merci "proxy-cache"
- 'pas de quoi. Aplus »

Attention, le proxy est un service de couche 5 et agit surtout sur les services web (http, https, ftp, ftps, etc.).

Le proxy a un rôle important en bloc 3 (cybersécurité) mais aussi en bloc 2 pour son cache mémoire dans lequel il stocke les pages les plus demandées durant un certain temps.

 

Il permet ainsi à de multiples clients de se connecter vers l'extérieur, sur un même serveur distant et réduire l'occupation de bande passante sur le réseau internet et la charge de travail du dit serveur distant tout en accélérant les échanges :

• Les pages sont déjà là, pas besoin de les rechercher à chaque fois
• Les pages sont à jour, le proxy les vérifie à ses heures perdues ou si la date est dépassée depuis longtemps (durée de vie = au moins quelques secondes, quelques minutes au plus)
• Les pages sont figées (html) et le serveur se met à dispo pour d'autres demandes.

Le proxy a donc un rôle essentiel dans notre réseau vers internet.

Le seul bémol est que ça demande plus de disque et de RAM que le simple contrôle des ports des segments TCP qui passent (Bloc3)

« Ok, mais on oublie quelque chose, le serveur, il est ici. Je veux dire : chez nous, dans notre DMZ. Et les clients, ils sont dehors, sur le web...
- Ah (gratt, gratt, gratt, tilt!) ben, c'est simple. On redirige les clients sur différentes machines
- Oui ? Comment ? »

Substitut : (angl.) surrogate, qui se subtitue, se met à la place de.

• Fonctionne en sens inverse du proxy-cache classique : l'extérieur est à l'intérieur et vis versa.
• Effectue le même travail : Cache des pages les + demandées et des objets statiques :
  Html, css, images, vidéos, audio, structure MVC, etc. …

Héberger ce service sous forme :

• Serveur matériels : Cisco, A10 network, Brocade, coyote end point, citrix system, juniper, pakteteer, etc. …
• Logiciel de service : HAProxy, Zeus load balancer, netfilter, keepalived

Terme	En anglais	Définition
Haute disponibilité	High availability	svc dispo., résistant => pannes, surcharges
Répartition de charge	Load balancing	connxions & ttmts données distribués sur +rs serveurs.
Évolutivité applicative	scalability	technique, fonctionnelle, des besoins.
Serveur mandataire	Proxy-Cache server	cache pages & objets statiques les plus recherchés.
Substitut de serveur	reverse proxy ou surrogate	serveur proxy effectuant travail inverse d'un proxy, répartit la charge des connexions, cache des pages demandées.
Adresse IP de service		adresse IP d'un service (pas d'un serveur). Peut être modifiée pour faire de la répartition de charge.
Test de présence, d'activité	Health checks	fait par un répartiteur pour savoir si un service est disponible : ping, connexion, requête ou autre.
Système de fichiers répartit, DFS	Distributed file system	Microsoft, Windows Server : FS répartit sur plusieurs serveurs

1. Créer les serveurs web de base
   • Créer un serveur web de référence (voir le contenu dans les cours de 1ère année)
   • Ajouter une application de test (applitest)
   • Cloner le serveur de référence en deux serveurs web de production
   • Configurer les serveurs prod (hostname, ..) et la couleur du fond de l'application pour les différentier visuellement
   • Configurer les serveurs prod (interfaces en lan interne, IP fixe, etc.)
2. Créer le serveur HAProxy
   • Cloner un serveur web de référence et ajouter une seconde carte réseau en lan interne
   • Télécharger et installer le logiciel via l'interface internet
3. Configurer le serveur HAProxy
   • IP interne, hostname, etc...
   • Configurer HA proxy
4. Tester les services
   • Tester l'accès aux serveurs internes à travers HAProxy
   • Tester l'accès à l'interface de statistiques de HAProxy avec un client graphique dans le réseau interne.
5. Compléter l'activité
   • Créer la réplication entre les bases de données des serveurs web
   • Placer HAP dans une DMZ, derrière un routeur virtuel (/ex pfSense) et configurer ce routeur pour effectuer une redirection du port 80 vers HAP en provenance du WAN