Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Les solutions et outils

Les solutions et outils

Il y a deux types de solutions pour mettre en œuvre une répartition de charge de niveau 4 ou 7 : solutions logicielles et solutions matérielles.

Les solutions logicielles tournent sur de l’infrastructure de serveur standard, soit sur une base OpenBSD, soit sur une base Linux. On les met en œuvre sur du matériel dédié et peu coûteux.

Les solutions dites matérielles sont des boîtiers dédiés, prêts à l’emploi. Bien sûr, ils incluent du logiciel, mais les boîtiers haut de gamme ne sont pas des serveurs standards, ils utilisent des circuits intégrés spécialisés pour de plus hautes performances.

Solutions logicielles

Des solutions logicielles de grande qualité et d’une robustesse extrême sont disponibles en open source.

Au niveau 4, deux solutions dominent le paysage :

  • OpenBSD avec relayd
  • Linux avec IPVS

La répartition de charge au niveau 4 appliquant des algorithmes très simples, et uniquement pour la phase de connexion, elle ne requiert que très peu de ressources CPU, et donc un matériel peu coûteux.

A partir des produits cités, on met en place un boîtier de répartition de charge en prenant un hardware relativement bas de gamme mais très fiable, sans disque dur, ni ventilateur, un équipement à moins de 500€.

IPVS

IPVS est une des composantes du projet LVS, Linux Virtual Server, qui réunit différentes fonctionnalités autour du load balancing, afin de construire des serveurs virtuels sur un ensemble de serveurs physiques.

IPVS est intégré au noyau Linux, depuis la version 2.5, et assure une répartition de charge au niveau 4 seulement. Rappelons que la répartition de niveau 4 est compatible avec une diversité de protocoles et donc d’applications au-delà du web.

Il est associé à d’autres outils tels que mon pour tester la disponibilité des serveurs et services sous-jacents, ldirectord ou heartbeat pour tester le load-balancer ( director) homologue.

LVS supporte tous les algorithmes de répartition évoqués plus haut : round-robin, weighted round-robin, least-connection scheduling, weighted least-connection, locality-based least-connection, locality-based least-connection with replication, destination hashing, source hashing, shortest expected delay, never queue.

Le load-balancer fournit un certain nombre de compteurs statistiques en temps réel, et peut être reconfiguré à chaud.

Deux load-balancer IPVS en normal/secours synchronisent les informations d’état associées aux connexions, de manière à offrir un passage en secours réellement transparent, sans nécessité de ré-établir les connexions en cours.

LVS offre aussi des outils de protections contre les attaques DoS.

Relayd

Si OpenBSD est un Unix moins répandu que Linux sur les serveurs applicatifs, il est très populaire pour construire des boîtiers appliance, du fait de sa grande robustesse et d’excellents outils de networking.

Relayd en fait partie. C’est un outil de routage et de load-balancing de niveau 4 et 7.

Pour le niveau 4, il s’appuie en fait sur un autre outil BSD : pf, packet filter, qui prend en charge le routage au niveau du noyau.

Relayd permet de définir des pools de serveurs, des « tables », qui sont surveillés.

Quelques fonctionnalités :

  • Il permet différents modes de répartition : round-robin, équilibrage des connexions, hashage sur des paramètres de la requête Http.
  • Il permet différents modes de test des serveurs : ICMP, simple connexion TCP, requête-réponse sur port TCP, requête HTTP. Possibilité de timeout sur les requêtes de tests.
  • Il peut adresser des alertes SNMP à un système de supervision.

HAProxy

HAProxy est l’une des solutions logicielles les plus utilisées au niveau 7. Solution très complète au plan fonctionnel, extrêmement robuste et performante, c’est de surcroît un projet particulièrement dynamique.

HAProxy peut fonctionner aussi au niveau 4, mais on l’utilise plutôt au niveau 7.

Quelques fonctionnalités :

  • Répartition sur la base d’un cookie existant, ou bien insertion de son propre cookie pour gérer l’affinité de serveur.
  • HAProxy peut tester la disponibilité des serveurs, soit en établissant une connexion TCP, soit en adressant une requête HTTP. En mode HTTP, la vérification peut porter sur une URI particulière, qui teste tous les composants requis au bon fonctionnement.
  • Le seul mode de répartition possible pour l’instant est le mode round-robin (permutation circulaire), avec toutefois la possibilité de permutation et de limitation du nombre de connexions par serveur.
  • La reconfiguration est possible à chaud.
  • Des statistiques sont disponibles en temps-réel.
  • La version 1.3, en développement apportera d’autres logiques de répartition et des fonctionnalités complémentaires telles que le content-switching, aiguillage basé sur l’analyse des URI.

HAProxy est généralement mis en œuvre couplé à heartbeat, un composant du projet Linux-HA, qui permet d’associer un HAProxy de secours, qui surveille le load-balancer principal, et reprend sa fonction, par son adresse IP, s’il détecte une défaillance.

Apache mod_proxy

L’extension Apache mod_proxy_balancer est aussi couramment utilisée dans une fonction de load balancer.

Il s’agit bien sûr d’une répartition de niveau 7, et il est possible en particulier de maintenir les sessions sur la base des cookies placés par les applications, de type JSesssionId ou PHPSESSIONID.

Il permet différents modes de répartition :

  • Répartition vers le serveur qui a le moins de requêtes en cours ( pending request counting)
  • Répartition visant à équilibrer le flux traité en termes de nombre d’octets en requête/réponse, avec pondération éventuelle. Ce type de répartition équilibre la bande passante, mais pas nécessairement la charge.

Dans l’ensemble, la répartition de niveau Apache est moins performante que celle d’un outil spécialisé tel que HAProxy. Mais si l’on dispose déjà d’un serveur Apache, par exemple pour servir les contenus statiques, alors on peut choisir de lui confier aussi la répartition de charge.

Les boîtiers dédiés

Les boîtiers dédiés sont plus robustes, ils peuvent atteindre de meilleures performances et offrir quelques fonctionnalités supplémentaires.

L’offre du marché est assez vaste (Foundry ServerIron, F5 BigIP, Citrix Netscaler, Cisco ACE, Nortel Alteon), mais ce sont des équipements très coûteux, par exemple de l’ordre de 15 k$ pour un boîtier Foundry ServerIron 4G-SSL.

La performance n’est pas le critère de choix premier, car les solutions logicielles ont déjà des performances satisfaisantes. La question est un peu différente pour une répartition de niveau 7, qui consomme plus de CPU.

Les boîtiers dédiés ont aussi en général une meilleure interface de configuration et de gestion.

Les boîtiers de répartition de charge tels que BigIP offrent quelques possibilités supplémentaires, telles que la sélection du serveur dont le temps de réponse observé est le plus bas, ce qui est interprété comme une moindre charge réelle (il s’agit d’une analyse de niveau 7). Mais là aussi, il peut y avoir des anomalies dans la mesure, un cas de plantage classique est celui où le temps de réponse d’un serveur est très faible parce que l’application est plantée et répond immédiatement par une page d’erreur. Ainsi, si le load-balancer est mal configuré, il dirige tout le trafic vers le serveur en panne, de sorte qu’une panne locale devient globale.

Fonctionnalités associées

En plus de sa fonction de répartition de charge, le composant de load balancing, qu’il soit logiciel ou boîtier, de par son positionnement en coupure du trafic HTTP, peut assurer quelques autres fonctions, et décharger du même coup le serveur web. Typiquement il s’agit des fonctionnalités de :

  • Cryptage SSL, qui est assez consommateur de CPU. On a vu qu’il était obligatoire pour répartir au niveau 7.
  • Cache. Côté serveur, elle peut être mise en œuvre au même niveau que la répartition de charge.
  • GZip. Nous avons décrit déjà l’intérêt de compresser les flux jusqu’au navigateur. C’est aussi une tâche qui consomme un peu de CPU et qui peut être prise en charge à un niveau frontal.
  • Maintien des connexions. Enfin, les boîtiers frontaux gèrent parfois le partage des connexions, en particulier pour les clients utilisant du HTTP 1.0. Dans ce cas, plusieurs requêtes HTTP, parvenant sur des connexions TCP distinctes, sont multiplexées sur une même connexion à destination du serveur web.
  • Protection contre les attaques « DOS », déni de service, en limitant le nombre de connexions autorisées.