S2C7D Répartition de charge

La petite histoire

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 juste 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 ...

Contextes

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 :

• Besoin de haute disponibilité
  • Angl. : High Availability
  • Garantire de service
• 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.

On part d'un contexte où nous avons deux serveurs web placés sur un même réseau.
Le serveur principal est celui où sont redirigées toutes les requêtes des clients.

Répartition Couche L3 et services réseau

Répartition entre routeurs (couches 3 et 4)

<<
- What a fuking nice network!  
- Tu parles anglais, maintenant ?  
- Ben ouais, je speek very nice british.  
- Mouais.
- But is it quand même un fuking network!  
- pff. 
>>

C'est juste un réseau avec :

• deux routeurs en répartition de charge pour la connexion externe,
• deux switch L3 qui forment la colonne vertéblale du réseau (backbone),
• et deux niveaux de switch intermédiaires pour la structure du réseau.
• Les liens rouges ou oranges sont bloqués par des protocoles permettant d'éviter les boucles réseau.
• le LACP est un fasceau de liens qui bossent comme un lien unique, avec plus de débit.

config de ce réseau ?

Les deux routeurs sont configurés pour partager la charge de connexion vers internet. Ils sont configuré pour avoir :

• Une même adresse IP virtuelle dans le réseau (protocole HSRP, CARP ou VRRP) => répartition de charge sur des passerelles avec IP virtuelle,
• Privilégier la moitié des VLANs sur un routeur et l'autre moitié sur le second routeur (voir routage statique),
• Utiliser des routes "flottantes" dont la DA est supérieure à la DA normale (voir routage dynamique),
• Utiliser un service DHCP pour configurer les postes avec des passerelles différentes, un groupe pour chaque routeur (voir service DHCP),
• Des valeurs d'interfaces permettant de privilégier une route sur le premier, le second routeur servant de secours,
• Etc.

<<
- Wouah !! C'est balèze, ce truc.  
- Meuh non, c'est juste de la méthode.
- ...
- Tiens ? t'en perds ton anglais ?
>>

Répartition entre serveur DHCP

<<
- 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.  
- (chef) C'est pour ça que je suis chef!   
- Il suffit de mettre des plages différentes à chaque serveur et le tour est joué. Tadaaaa!   
- (chef) Ah. Ouais, pas bête ... aussi.  
>>

Oui mais voilà, les serveurs aussi sont intelligents et ils n'ont pas toujours besoin de plages différentes ou autre artifice de sécurité sur les adresses IP.
Les serveurs DHCP font souvent 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.

Répartition de serveurs DNS

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.
Selon le serveur DHCP contacté, on a la possibilité d'imposer :

• le routeur A ou B
• La DNS 1 avant le DNS 2 ou l'inverse.

On obtient, en fonction du DHCP contacté, une forme de répartition de charge sur les passerelles et les DNS en divisant les ressources affectés aux DHCP.

Répartition de système de fichiers

Windows server (© Microsoft) 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 disques durs en lignes qui seraient montés de façon transparente dans l'arborecence des fichiers.
Cette fonction permet :

• de faire une réplication des données sur plusieurs serveurs (comme du RAID),
• de faire une "externalisation" des données sur un autre serveur.

Répartition de charge sur des serveurs web

À notre niveau, nous utiliserons un service, facile à installer, qui permet de faire de la répartition de charge entre des serveurs web HTTP.
Le service permettant de faire ça est basé sur la notion de Proxy, ou plustôt de reverse proxy.

Répartir la charge entre plusieurs serveurs : pourquoi ?

<<
- 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épechent, 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. En attendant, y aurait pas un café dans le coin ? 
>>

Ça ressemble à un certain serveur pour choisir ses formations ...

Tout est dans le dialogue : on répartit la charge pour permettre plus de connexions, plus de charge globale et moins de charge locale.

Répartir la charge en couche transport (L4)

Rotation DNS (avec 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 sessions et les clés de chiffrement (SSL/TLS)

Algo de répartition "round robin"

On envoie les requêtes tour à tour au 1er, au 2nd, au troisième, etc. … jusqu'au dernier et on recommence au 1er serveur.
L'algo de rotation est nommé round robin.
Cet algorithme est utilisé par différents répartitieurs. Il est parfois amélioré par une pondération des serveurs pour les cas où certains serveurs répondent plus vite que d'autres.

Dans un DNS, cette rotation est configurée en donnant plusieurs adresses à un même nom de serveur (serveurs réels en réplication).

NAT routé

L'adresse IP virtuelle du service est changée en adresse IP de serveur physique pour répartir les demandes des clients.
Le NAT peut envoyer les demandes vers différents serveurs.

Avantage : Aucune config de serveur à prévoir
Inconvénient : Charge importante pour le routeur/répartiteur en NAT bidirectionnel. Il est cependant possible d'utiliser du NAT de destination sans changer l'adresse source ce qui allège le traitement du routeur.

NAT logiciel

Le serveur de nat se subtitue aux serveurs physiques.

Avantage : Le serveur n'est pas directement accessible => 1 niveau de protection supplémentaire
Inconvénient : Charge importante pour le serveur de NAT : le serveur doit être plus puissant qu'un routeur ou switch dans le domaine du routage/NAT/PAT.

Répartition des données (voir détails plus loin)

La répartition des données consiste à utiliser plusieurs serveurs de fichiers et de données.

• Un serveur frontal fait l'assemblage final des pages et gère la sécurité (TLS, Sessions, token).
• Un serveur donne les données statiques (images, fond de page, textes fixes, etc.) et
• Un serveur donne les données dynamiques (données client, résultats de filtres, etc.).

Avantage : Les serveurs ont une charge limitée et, si le serveur frontal supporte beaucoup de charge de calcul, celle-ci est réduite au calculs de chiffrement.
Inconvénient : Charge (malgré tout) importante pour le serveur frontal.
Remarque : Répartir les données en données d'un coôté dynamiques et de l'autre statiques n'est pas à la mode, si c'est la seule technique utilisée, à cause de

• la puissance des machines est suffisament importante pour absorber la charge de travail,
• les applications deviennent de plus en plus complexes et la séparation des données statiques/dynamique, difficile à réaliser.

Il ne reste que les notions de tiers : serveur HTML/PHP frontal (contrôleur et vues), serveur middle ware (modèle de données et relation avec le SGBD) et le serveur de données (SGBD).

Les difficultés à résoudre

• 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
• Cela implique une charge réseau conséquente
• Le timing des tests est important pour :
  • Éviter la surcharge
  • Éffectuer des détections rapides

Conclusion

Au regard

• des difficultés à résoudre et de la charge de calcul que cela représente,
• de la capacité des machines actuelle en couche 7 (application) et des gains apportés par la répartition en couche 4 (transport),

La répartition en couche 4 transport est moins développée que la répartition en couche 7.
Cela se traduit par une répartition sur moins de matériels par les routeurs et plus de serveurs applicatifs par des proxy inverses.

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

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 (round robin, comme dans la répartition DNS) mais ...
• L'adresse IP du client est liée au serveur, sinon la session est perdue (sessions, transaction en cours, cookie temporaire, chiffrement, etc. ...)
• Difficile à gérer dans un environnement à faible clients (intranet), meilleur si le nombre de client est élevé (internet)
  • Les clients risquent de changer de serveur entre deux connexions à cause de la rotation.
  • La probabilité de changer de serveur est plus faible : allongement de la durée de session (attention aux risques d'attaque)

Persistance des sessions

Il faut maintenir l'association client/serveur à cause du maintient 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 et risques augmenté de vol de cookies/sessions
  • si la durée de vie du cookie est courte : basculement sur un autre serveur => perte de l'environnement client et des transactions en cours.

Insersion de cookie serveur

Le répartiteur envoie un cookie avec id du serveur mais :

• Le client doit accepter plusieurs cookies (pas sûr)
• Les cache frontaux peuvent envoyer le même cookie à tout le monde => surcharge d'1 seul serveur

Revoir le schéma ci-dessus.

<<
- 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, la gestion des session et alors, le tour est joué!
- Ah ouaaais, pas bêêête
>>

Proxy et Reverse Proxy : la théorie, rapidos

<<
 Bon, alors, 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, on est vraiment plusieurs ...   
- Bon, j'y retourne pour chacun de vous et je vous la redonne.  
- Euh, sûr ? parce qu'on est vraiment, genre, 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 &raquo;  
>>

Le rôle du proxy-cache

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 requête HTTP,
• Les pages sont à jour, le proxy les vérifie à ses heures perdues ou si la date de validité est dépassée
  durée de vie = de quelques secondes à quelques minutes
• Mais les pages sont figées (html) et le serveur se met à dispo pour d'autres demandes.

Le proxy a donc un rôle essentiel pour accélérer et alléger les communications vers internet.

<< 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, hm. (gratt, gratt, gratt, tilt!) Ben, c'est simple : on redirige les clients sur différentes machines :)  
- Oh. Comment ? >>

Le reverse proxy ou "substitut"

De multiples requêtes HTTP parviennent d'internet et on n'a qu'un seul serveur.
On va donc charger un reverse proxy de conserver les pages les plus souvent demandées afin de décharger le serveur et accélérer les réponses aux clients.

• 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. …

Le reverse proxy répartiteur

Le reverse proxy-répartiteur effecteus en plus de la répartition de charge sur des serveurs secondaires afin d'accélérer encore la réponse pour les données dynamiques.
Cela permet de confier le calcule de la page html en réponse à des serveurs applicatifs et conserver sur le serveur frontal la gestion des sessions et le chiffrement TLS.

Service hébergé 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

Quelques définitions

Canevas de l'activité

Démarche

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.)

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

Configurer le serveur HAProxy

• IP interne, hostname, etc...
• Configurer la répartition HA proxy
• configurer le service de statistiques de HAProxy

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.

Compléter l'activité (option)

• 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

Exemple de configuration HAProxy

Cet exemple de fichier de configuration est à vérifier et retravailler : /etc/haproxy/haproxy.cfg

# ===========================================
 
Frontend nom_de_la_config
Bind 192.168.24.100:80 	# 80=port d\'accès, ici http ; l'@IP est l@ publique de HAP
…
Use_backend nom_du_backend
 
Backend nom_du_backend
Mode http  # protocole géré
…
Server web_server1 192.168.40.1	#adresse IP du 1er serveur web
Server web_server2 192.168.40.2	#adresse IP du 2nd serveur web
…
# ===========================================

Voilà, c'est fini pour cet article, mais pas pour l'activité que vous pourrez présenter à l'épreuve pratique (E6), conjointement à d'autres.
Remarque, Il vient en association avec :

• PFSense,
• la réplication,
• la supervision,
• l'inventaire,
• l'Active directory et DNS,
• DHCP,
• etc.

A vous de choisir un contexte adapté
A bientôt pour de nouvelles aventures. Bye !