Répartition de charge

Plusieurs serveurs derrière un même site : ToutWAF répartit les requêtes, cesse d'utiliser un serveur qui tombe en panne et vous laisse mettre à jour sans couper une seule requête. Le détail est ici, avec ce qui est gratuit et ce qui demande une licence.

Toutes les fonctions

À quoi ça sert

Un site n'a que rarement besoin d'un seul serveur. Avec un groupe de serveurs derrière ToutWAF, une panne, une mise à jour ou un pic de trafic cessent d'être un incident.

Le site reste en ligne

ToutWAF répartit les requêtes entre vos serveurs selon le poids de chacun et cesse d'envoyer des requêtes à un serveur qui tombe en panne. Les visiteurs ne voient jamais la bascule.

Mettre à jour sans rien couper

Mettez un serveur en maintenance : il ne reçoit plus de nouvelle requête, celles en cours se terminent normalement, et il reprend sa charge progressivement.

Déployer avec confiance

Envoyez une part des requêtes vers les serveurs de la nouvelle version (canari), basculez tout d'un coup (bleu/vert) et revenez en arrière en remettant la part à 0 %.

Aiguiller selon la requête

Envoyez /api, un nom d'hôte, un en-tête, une méthode, un pays ou une part d'essai A/B vers son propre groupe de serveurs.

Protéger vos serveurs

Délais, nouvelles tentatives sûres et disjoncteur : ToutWAF cesse d'envoyer du trafic à un serveur qui échoue trop souvent, le réessaie plus tard, et répond vite au lieu de faire attendre les visiteurs.

Plusieurs nœuds ToutWAF

Retirez un nœud de la rotation sans couper une requête et vérifiez ce que répond réellement votre DNS.

Comment ToutWAF choisit un serveur

Chaque site a une liste de serveurs (origines), chacun avec un poids de 1 à 1000. Pour chaque requête, ToutWAF ne garde que les serveurs disponibles, puis applique l'algorithme choisi.

Seulement les serveurs disponibles

Un serveur est candidat sauf s'il est en maintenance, déclaré en panne par le contrôle actif, écarté par le contrôle passif ou derrière un disjoncteur ouvert.

Les serveurs de secours en dernier

Un serveur de secours n'est utilisé que si aucun serveur principal n'est disponible.

Un serveur seul n'est jamais coupé

Un site qui n'a qu'un serveur principal n'est jamais déclaré en panne par les contrôles : ses requêtes partent toujours vers lui, sauf maintenance ou disjoncteur ouvert.

VisiteursToutWAFinspection, puis choix d'un serveurServeur Apoids 3Serveur Bpoids 1Serveur desecoursutilisé seulementsi aucun autren'est disponible
Illustration : une requête arrive sur ToutWAF, qui choisit un serveur selon les poids ; le serveur de secours attend que les autres soient indisponibles.

Sept façons de répartir les requêtes

Le tourniquet pondéré, par défaut, est gratuit. Les autres algorithmes se choisissent par site dans la console, avec le réglage « Algorithme de répartition de charge ».

  • Tourniquet pondéré (par défaut) — Les proportions sont exactes sur un cycle complet, les serveurs sont intercalés, et un serveur qui tombe puis revient reprend sa part sans rafale.Gratuit
  • Moins de connexions — Le serveur qui a le moins de requêtes en cours par rapport à son poids.Pro et plus
  • Hachage d'IP — La même adresse atteint toujours le même serveur (en IPv6, le préfixe /64).Pro et plus
  • Hachage cohérent — Vous choisissez la clé : adresse, chemin de l'URL, un en-tête ou un cookie. Quand un serveur tombe, seules ses clés bougent, et elles reviennent avec lui.Pro et plus
  • Aléatoire — Tirage au hasard, pondéré par les poids.Pro et plus
  • Deux choix — Deux serveurs tirés au hasard (pondérés) : le moins chargé l'emporte.Pro et plus
  • Le plus rapide — Deux serveurs tirés au hasard (pondérés) : l'emporte celui dont le temps de réponse récent, qui suit les pics, multiplié par les requêtes en cours et rapporté au poids, est le plus bas. Un serveur sans mesure est essayé.Pro et plus

« Le plus rapide » suit le temps de réponse mesuré par le nœud ; il ne mesure pas la distance entre le visiteur et le nœud. Les poids vont de 1 à 1000 : un serveur de poids 3 reçoit trois fois plus de requêtes qu'un serveur de poids 1.

Contrôles de santé et nouvelles tentatives

Contrôle actif

Pro et plus

ToutWAF interroge chaque serveur : un chemin comme /health, ou une simple connexion TCP ; GET ou HEAD ; les codes de réponse attendus ; le nombre d'échecs avant « hors service » et de succès avant le retour ; un en-tête Host facultatif. Un serveur qui revient est réutilisé automatiquement.

Contrôle passif

Gratuit

Des requêtes réelles qui échouent (erreur de connexion, délai dépassé, 502, 503, 504, ou réponse plus lente qu'une limite que vous fixez) écartent le serveur de la rotation pendant un délai.

Nouvelles tentatives sûres

Gratuit

Une requête qui échoue est rejouée sur un autre serveur, mais seulement quand c'est sans risque : un POST qui a pu atteindre un serveur n'est jamais rejoué, ni un gros envoi transmis en flux.

Disjoncteur

GratuitPro et plus

Actif par défaut pour tout le monde. Quand un serveur échoue trop souvent dans une fenêtre de temps, ToutWAF l'écarte, répond vite au lieu de faire attendre les visiteurs, puis laisse une seule requête de test décider de son retour. Par défaut : une fenêtre de 30 secondes, au moins 20 requêtes, la moitié en échec, 15 secondes d'écart. Ces valeurs se règlent (sous licence).

Ferméle trafic passeOuvertserveur écartéEn testune requêtedécidetrop d'échecsaprès le délaile test échouele testréussit
Illustration : les trois états du disjoncteur d'un serveur.

Garder un visiteur sur le même serveur

Pro et plus

Nommez un cookie et ToutWAF fixe chaque visiteur sur le serveur qui l'a servi en premier. Le cookie contient un identifiant opaque du serveur, jamais son adresse ; il est HttpOnly, SameSite=Lax et Secure en HTTPS. Vous choisissez sa durée de vie, ou il s'arrête avec le navigateur.

  • Si le serveur tombe ou passe en maintenance, le visiteur est dirigé vers un autre serveur et reçoit un nouveau cookie.
  • Sans cookie : le hachage d'IP, ou le hachage cohérent sur un en-tête ou un cookie existant, garde aussi un visiteur en place, sur tous les nœuds.

Maintenance sans couper une requête

Pro et plus

Depuis la console, mettez un serveur (ou un nœud entier) en maintenance. Rien n'est coupé : les visiteurs sont servis par les autres.

Lancer la maintenance

Plus aucune nouvelle requête n'est envoyée au serveur, même aux visiteurs qui portent le cookie de persistance.

Les requêtes en cours se terminent

Téléchargements, flux d'événements et connexions WebSocket vont jusqu'au bout ; la console indique combien il en reste.

Intervenir sur le serveur

La console vous dit quand plus rien n'est en cours.

Reprise progressive

Remis en service, le serveur reçoit une part croissante de son poids pendant le nombre de secondes que vous fixez (montée en charge), au lieu de tout d'un coup.

Le dernier serveur en service ne peut pas être mis en maintenance : ajoutez-en d'abord un autre.

Déploiements canari et bleu/vert

Pro et plus

Donnez un nom de groupe aux serveurs de la nouvelle version (par exemple green), puis choisissez ce groupe et sa part des requêtes, de 0 à 100 %. La part compte des requêtes, quel que soit le nombre de serveurs de chaque groupe.

  • Canari : commencez par une petite part et augmentez-la à mesure que vous gagnez confiance.
  • Bleu/vert : 100 % bascule tout d'un coup, 0 % revient en arrière.
  • Avec un algorithme à hachage, un visiteur reste du même côté tant que la part ne change pas, et augmenter la part ne le renvoie jamais en arrière.
  • Si tous les serveurs d'un groupe sont en panne, l'autre groupe sert tout : aucune requête n'est perdue.
Groupe blueversion actuelleGroupe greennouvelleversionla part que vous choisissez0 % : retour en arrière100 % : toutbascule
Illustration : la part des requêtes envoyée au groupe de la nouvelle version.

Pools de routes : un groupe de serveurs par type de requête

Gratuit

Une route envoie les requêtes qui lui correspondent vers un pool qui lui est propre. Elle peut cibler un chemin, un nom d'hôte, un en-tête, une méthode, le pays du visiteur ou une part d'essai A/B.

  • Les serveurs d'un pool ont les mêmes options que ceux d'un site : poids, secours, groupe, maintenance.
  • Une route peut choisir son propre algorithme ; tout le reste (contrôles de santé, nouvelles tentatives, disjoncteur, déploiement progressif) est hérité du site.
  • Chaque route a son propre cookie de persistance : un visiteur qui passe d'un pool à l'autre garde sa session.
  • Une route peut aussi rediriger ou répondre directement.
  • Une liste de routes illisible est refusée avec un message d'erreur ; l'ancienne politique reste en place, au lieu de supprimer des routes en silence.

Exemple d'une route, dans le réglage « Règles de routage » du site

JSON
[{"name": "api",
  "match": {"path_prefix": "/api"},
  "origins": [
    "http://10.0.0.7:8080",
    {"url": "http://10.0.0.8:8080", "weight": 3},
    {"url": "http://10.0.0.9:8080", "backup": true}]}]

Plusieurs nœuds ToutWAF

GratuitPro et plus

Quand plusieurs nœuds protègent les mêmes sites, les visiteurs les atteignent par un nom DNS qui liste leurs adresses, une adresse virtuelle (VRRP, par exemple keepalived) ou un répartiteur de charge à vous. ToutWAF ne modifie pas votre DNS et ne déplace pas d'adresse : il montre l'état réel et fait sortir un nœud de la rotation proprement.

  • L'état de chaque nœud : en service, dégradé (un site n'a plus aucun serveur qui répond depuis ce nœud), en maintenance, hors ligne ou désactivé.
  • Les enregistrements DNS qui correspondent aux nœuds en service (durée de vie courte proposée : 60 secondes), comparés à ce que votre DNS répond vraiment : nœud manquant, enregistrement périmé, adresse inconnue, ou proxy de type Cloudflare reconnu.
  • Un nœud en maintenance répond 503 à son contrôle de disponibilité (/readyz), celui que testent keepalived ou un répartiteur, demande à ses connexions de partir (GOAWAY en HTTP/2, Connection: close en HTTP/1.1) et laisse finir les requêtes en cours.
  • Des fichiers keepalived d'exemple sont fournis avec le produit (dossier deploy).

Pas encore essayée en conditions réellesLa maintenance d'un nœud est testée automatiquement, mais le déplacement d'une vraie adresse virtuelle keepalived entre deux nœuds n'a pas encore été essayé en conditions réelles.

Ce que ToutWAF ne fait pas : gérer votre DNS, déplacer une adresse virtuelle, ou répartir lui-même la charge entre les nœuds. Le nombre de nœuds dépend de votre offre (voir les tarifs).

VisiteursNom DNS àplusieursadressesAdressevirtuelle (VRRP)VotrerépartiteurNœud 1en serviceNœud 2en maintenancerépond 503 sur /readyzVos serveurs
Illustration : trois façons d'atteindre les nœuds ; un nœud en maintenance sort de la rotation sans couper de requête.

La connexion à vos serveurs

Gratuit

Les réglages de la liaison entre ToutWAF et vos serveurs sont libres : aucune licence n'est nécessaire.

  • Délais de connexion et de réponse, connexions persistantes (keep-alive).
  • HTTP/1.1, HTTP/2 négocié, ou h2c vers des serveurs en http:// (gRPC est reconnu automatiquement).
  • TLS vers le serveur vérifié, avec votre propre autorité de certification, et certificat client (mTLS) présenté au serveur.

Le cache, la compression, les réécritures, les redirections, les pages d'erreur et la vraie adresse du visiteur font aussi partie de la distribution du trafic. Voir le détail

Dans la console

Sites, votre site, onglet Serveurs : la liste des serveurs avec leur état en direct, la maintenance et les réglages. Flotte et licence, onglet Répartition : l'état des nœuds, les enregistrements DNS et leur vérification.

Illustration : les adresses sont des exemples.

Cas d'usage

Une boutique qui doit rester en ligne

Deux serveurs se partagent la charge ; un troisième, de secours, ne prend le relais que si les deux tombent.

Mettre à jour en pleine journée

Un serveur passe en maintenance, les requêtes en cours se terminent, puis il revient en douceur.

Essayer une nouvelle version

Une petite part des requêtes va vers les serveurs du groupe canari ; vous augmentez la part ou revenez à 0 %.

Une API sur ses propres serveurs

Une route envoie /api vers un pool dédié, avec son algorithme, sans toucher au reste du site.

Garder les connectés en place

Un cookie de persistance fixe chaque visiteur sur son serveur tant qu'il est disponible.

Sortir un nœud ToutWAF

Le nœud passe en maintenance, ses connexions partent, votre répartiteur ou keepalived le retire, vous intervenez.

Ce qui est inclus, par édition

La base est gratuite ; les options avancées demandent une offre payante. Une option sous licence reste visible dans la console, verrouillée, jamais cachée.

ÉditionGratuit Inclus dans toutes les offres, dont les deux offres gratuites (Free et Free +)Pro et plus Offres payantes : visible dans la console, verrouillé sans licence. À partir de Pro, sauf mention Agency ou Enterprise
Pas encore essayée en conditions réelles Fonctionne dans les tests du produit, mais n'a pas encore été essayée avec le vrai service, le vrai système ou le vrai matériel. La console affiche la même mention à l'endroit où vous la configurez.
  • Tourniquet pondéré, serveurs de secours, contrôles de santé passifs, nouvelles tentatives sûres et disjoncteurGratuit
  • Pools de routes : envoyer un chemin, un hôte, un en-tête, une méthode, un pays ou une part A/B vers son propre groupe de serveursGratuit
  • Délais, connexions persistantes et HTTP/1.1, HTTP/2 ou h2c vers l'origine ; TLS vers l'origine avec votre propre autoritéGratuit
  • Plusieurs nœuds de protection : enregistrements DNS proposés pour les nœuds en service et vérification de ce que répond votre DNS ; fichiers keepalived pour une adresse virtuelle ; ToutWAF ne gère pas le DNS Pas encore essayée en conditions réellesGratuit
  • Autres algorithmes : moins de connexions, hachage d'IP, hachage cohérent, aléatoire, deux choix, le plus rapidePro et plus
  • Persistance de session par cookie, par adresse ou par en-têtePro et plus
  • Contrôles de santé actifs et réglage fin du disjoncteurPro et plus
  • Maintenance d'un serveur ou d'un nœud sans couper une seule requête (vidage)Pro et plus
  • Déploiements canari et bleu/vert par part des requêtes, et démarrage progressifPro et plus

Revenir à la valeur par défaut d'une option avancée est toujours possible. Ce qui se passe à la fin d'une licence payante est décrit dans la FAQ des tarifs : 48 h de grâce, 48 h de lecture seule, puis protection WAF désactivée jusqu'au renouvellement.

Tarifs Lire la documentation

Placez un bouclier devant vos applications dès aujourd'hui

Installez-le sur votre propre serveur, ou écrivez-nous pour parler de licences.