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.
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.
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.
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.
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.
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 %.
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.
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.
Retirez un nœud de la rotation sans couper une requête et vérifiez ce que répond réellement votre DNS.
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.
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.
Un serveur de secours n'est utilisé que si aucun serveur principal n'est disponible.
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.
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 ».
« 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.
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.
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.
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.
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).
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.
Depuis la console, mettez un serveur (ou un nœud entier) en maintenance. Rien n'est coupé : les visiteurs sont servis par les autres.
Plus aucune nouvelle requête n'est envoyée au serveur, même aux visiteurs qui portent le cookie de persistance.
Téléchargements, flux d'événements et connexions WebSocket vont jusqu'au bout ; la console indique combien il en reste.
La console vous dit quand plus rien n'est en cours.
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.
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.
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.
Exemple d'une route, dans le réglage « Règles de routage » du site
[{"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}]}]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.
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).
Les réglages de la liaison entre ToutWAF et vos serveurs sont libres : aucune licence n'est nécessaire.
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
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.
| État | Serveur | Groupe | Poids | Secours |
|---|---|---|---|---|
| En service | http://10.0.0.11:8080 | blue | 3 | - |
| En service | http://10.0.0.12:8080 | blue | 1 | - |
| En maintenance | http://10.0.0.13:8080 | green | 1 | - |
| Montée en charge | http://10.0.0.14:8080 | green | 1 | - |
| En service | http://10.0.0.15:8080 | - | 1 | oui |
Illustration : les adresses sont des exemples.
Deux serveurs se partagent la charge ; un troisième, de secours, ne prend le relais que si les deux tombent.
Un serveur passe en maintenance, les requêtes en cours se terminent, puis il revient en douceur.
Une petite part des requêtes va vers les serveurs du groupe canari ; vous augmentez la part ou revenez à 0 %.
Une route envoie /api vers un pool dédié, avec son algorithme, sans toucher au reste du site.
Un cookie de persistance fixe chaque visiteur sur son serveur tant qu'il est disponible.
Le nœud passe en maintenance, ses connexions partent, votre répartiteur ou keepalived le retire, vous intervenez.
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.
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.
Installez-le sur votre propre serveur, ou écrivez-nous pour parler de licences.