Cloudflare Load Balancing peut diriger les réponses DNS vers des pools d'origine sains selon le comportement de steering et de failover configuré. Ce n'est pas un commutateur de trafic instantané et universel : le cache DNS récursif, la réutilisation des connexions client, la cadence des monitors, l'interprétation des monitors et la capacité d'origine influencent tous l'expérience utilisateur. Exploitez-le comme un plan de contrôle de gestion du trafic, avec une sémantique de santé explicite et un comportement de dégradation testé.

Ce tutoriel fournit aux ingénieurs DevOps et plateforme un workflow de production conservateur. Il ne suppose pas que les health checks prouvent la justesse de l'application ni qu'un failover se produira dans un délai fixe.

Prérequis

Préparez les éléments suivants avant de créer un load balancer de production :

• Un plan Cloudflare et une configuration de compte qui incluent les capacités Load Balancing que vous prévoyez d'utiliser. Confirmez les droits et contraintes produit actuelles dans Cloudflare Load Balancing.
• Au moins deux pools d'origine exploitables indépendamment lorsque la conception du service exige un failover. Un second pool qui partage le même domaine de défaillance n'apporte pas une résilience significative.
• Un endpoint d'origine adapté aux health checks synthétiques, avec des exigences d'authentification documentées, un code de statut, un corps et un périmètre de dépendances attendus.
• Des données de capacité pour chaque pool d'origine, incluant charge normale, charge soutenue sûre, comportement en rafale, limites de connexion, délai d'autoscaling et limites de base de données ou aval.
• Un accès à la configuration Cloudflare DNS et Load Balancing, ainsi qu'aux métriques et logs d'origine, et une fenêtre de changement coordonnée.

Étape 1 : définir la sémantique de route et de santé

Commencez par le hostname visible par l'utilisateur et le chemin de requête exact à protéger. Décidez si le load balancer répond à l'apex, à un sous-domaine tel que api.example.com ou à un hostname de service dédié. Le hostname doit disposer d'une configuration Cloudflare DNS compatible avec la configuration du load balancer.

Définissez ensuite ce que signifie « sain ». Un monitor vérifie la réponse observée depuis l'infrastructure de monitoring Cloudflare ; il ne prouve pas que chaque parcours applicatif, localisation utilisateur ou dépendance est sain. Cloudflare documente les champs des monitors et l'évaluation de statut dans Monitors.

Un endpoint de santé utile doit :

• Être rapide et non authentifié du point de vue du monitor, ou utiliser délibérément la configuration de requête prise en charge par le monitor.
• Valider les dépendances dont la perte doit déclencher un déplacement de trafic, sans rendre le contrôle si large qu'une dépendance non critique provoque un failover inutile.
• Renvoyer systématiquement le statut attendu configuré et, lorsqu'il est utilisé, le corps de réponse attendu.
• Éviter de muter des données, de réchauffer des caches coûteux ou de créer une charge significative à l'intervalle du monitor.

Documentez séparément la sémantique de route et la sémantique de santé. Une réponse 200 de /healthz ne garantit pas que chaque route, tenant, flux d'authentification ou opération d'écriture est utilisable.

Étape 2 : créer des pools avec des limites de capacité

Un pool regroupe des origines et associe un comportement de monitor et des métadonnées d'origine. Créez un pool pour chaque destination de trafic ou domaine de défaillance, puis ajoutez les origines avec l'adresse, le port, le poids et l'état d'activation corrects. Utilisez Pools comme référence de configuration.

Pour chaque pool, consignez :

• Le rôle prévu du pool : primaire, primaire régional, standby, maintenance ou cible d'évacuation.
• Les origines qu'il contient et les dépendances partagées sur lesquelles elles reposent.
• Le comportement du monitor sain et non sain, y compris l'endpoint, la méthode, la réponse attendue, le timeout, l'intervalle, les retries et le critère de passages consécutifs à down.
• La capacité de réception sûre pour le trafic transféré depuis un autre pool.
• Le signal côté origine qui indique aux opérateurs que le pool approche de la saturation.

Ne dimensionnez pas un pool standby uniquement pour son faible trafic normal. S'il peut recevoir du trafic de failover, validez sa capacité à l'accepter et tenez compte du délai d'autoscaling, des pools de connexions, des bases de données, des quotas tiers et des cold starts de cache. Cloudflare peut choisir un pool selon la configuration, mais ne peut pas créer de capacité d'origine.

Étape 3 : configurer le load balancer et le steering

Créez le load balancer pour le hostname et attachez des pools de fallback ordonnés. Configurez le steering selon l'objectif de gestion du trafic, puis examinez le comportement applicable dans Steering. Les politiques de steering disponibles et leurs résultats dépendent de la configuration choisie ; vérifiez la représentation dashboard ou API Cloudflare au lieu de déduire un comportement depuis le nom d'une politique.

Lors du choix d'une politique de steering, définissez la question opérationnelle à laquelle elle répond :

• Le steering orienté géolocalisation peut guider les utilisateurs vers des pools désignés, mais ne prouve pas à lui seul que le pool choisi est le plus rapide pour chaque chemin réseau.
• Le steering dynamique utilise les mesures et la configuration Cloudflare pour influencer la sélection, mais la latence client observée inclut toujours le comportement DNS, de connexion, applicatif et d'origine.
• Les approches aléatoires ou pondérées peuvent prendre en charge une distribution contrôlée lorsque les pools sont intentionnellement équivalents, à condition que les poids reflètent la capacité réelle.
• Un ordre de fallback fixe convient lorsque le service a une relation claire de primaire et standby.

Configurez délibérément les pools de fallback. Confirmez le comportement attendu lorsqu'une origine devient non saine, lorsqu'un pool entier est non sain et lorsque tous les pools candidats sont indisponibles. Les concepts Load Balancing de Cloudflare décrivent la relation entre load balancers, pools, monitors et steering.

Étape 4 : tenir compte du cache DNS et du TTL

Cloudflare Load Balancing influence les réponses DNS. Il ne force pas chaque résolveur récursif ou client à abandonner immédiatement une réponse antérieure. Le DNS TTL et le comportement du résolveur influencent le moment où une nouvelle réponse est demandée, tandis que les connexions existantes peuvent rester épinglées à un chemin d'origine antérieur.

Définissez le TTL du load balancer comme un compromis entre agilité et volume de requêtes DNS, puis vérifiez la valeur sélectionnée par rapport aux conseils DNS TTL pour Load Balancing actuels de Cloudflare. Ne promettez pas un délai de failover exact fondé uniquement sur l'intervalle du monitor ou le TTL.

Prévoyez ces effets :

• Les résolveurs récursifs peuvent conserver une réponse jusqu'à l'expiration de son TTL en cache ; le comportement du client et du résolveur peut ajouter une variation supplémentaire.
• Les utilisateurs disposant de connexions persistantes existantes peuvent ne pas observer une réponse DNS modifiée tant que la connexion n'est pas réessayée ou remplacée.
• Des TTL plus courts peuvent rendre de nouvelles réponses DNS disponibles plus tôt, mais n'éliminent pas le délai de détection du monitoring, le comportement du résolveur ou les contraintes de récupération côté origine.
• Les changements DNS guidés par la santé ne réparent pas les requêtes en cours déjà envoyées à une origine dégradée.

Si le service exige un proxy au niveau de la requête, une affinité de session ou un comportement au-delà du steering de réponses DNS, évaluez séparément l'architecture Cloudflare pertinente. Ne supposez pas que Load Balancing seul fournit ces propriétés.

Étape 5 : tester le chemin de défaillance complet en toute sécurité

Utilisez d'abord un hostname de staging et des pools représentatifs. Testez avec un volume de trafic contrôlé et un responsable de rollback présent. Ne commencez jamais par désactiver la seule origine de production saine.

Exécutez ce plan de test :

1. Confirmez que chaque origine sert directement la route applicative attendue et que son endpoint de monitor renvoie la réponse de succès configurée.
2. Confirmez que le hostname équilibré renvoie une réponse DNS associée au pool actif prévu et que les requêtes réelles l'atteignent.
3. Introduisez une défaillance réversible et visible par le monitor sur une origine. Vérifiez que le monitor la marque non saine selon ses seuils configurés, puis que la sélection de trafic évite cette origine lorsque la configuration l'exige.
4. Restaurez l'origine. Vérifiez la récupération du monitor et le comportement de retour configuré ; ne supposez pas que la récupération déplace nécessairement le trafic immédiatement ou automatiquement sans vérifier les règles de steering et fallback choisies.
5. Introduisez une défaillance réversible affectant le pool actif uniquement après avoir confirmé que le pool de fallback dispose d'une capacité suffisante. Observez à la fois les réponses DNS et les résultats applicatifs dans plusieurs contextes de résolveur ou clients contrôlés.
6. Faites un load test du pool récepteur au niveau de trafic transféré prévu, y compris les lectures, écritures, authentifications et appels aval critiques.
7. Testez une dégradation partielle qui renvoie 200 depuis l'endpoint de santé tandis qu'une route critique échoue. Utilisez le résultat pour décider si le monitor est intentionnellement étroit ou insuffisant pour l'objectif du service.

Consignez les horodatages de l'injection de défaillance, du changement d'état du monitor, des observations DNS, des premières erreurs client, des signaux de capacité de fallback et de la récupération. Cela établit une plage observée pour cette architecture, et non un engagement de failover universel.

Étape 6 : observer la santé, le trafic et la capacité

Surveillez trois couches pendant le déploiement et les incidents :

• La santé des monitors et pools Cloudflare : quelles origines et quels pools Cloudflare considère sains, et les échecs de monitor qui ont changé l'état.
• La sélection DNS et trafic : réponses de requête de résolveurs représentatifs, distribution du trafic de pool et requêtes atteignant chaque origine.
• La santé de l'application et de l'infrastructure : taux de succès des requêtes, latence, saturation, impact sur le budget d'erreur, capacité de base de données, profondeur de file et disponibilité des dépendances.

Cloudflare fournit des workflows opérationnels propres au produit dans Load Balancing analytics and monitoring. Associez ces signaux à la télémétrie d'origine ; un monitor vert associé à une origine saturée n'est pas un service sain.

Déclenchez des alertes sur des conditions actionnables telles qu'un pool actif qui perd de la capacité, un pool de fallback qui reçoit du trafic inattendu, le flapping de monitor, des erreurs d'origine qui augmentent après un changement de steering et une capacité standby qui tombe sous la marge de transfert requise. Incluez la version de configuration active ou la référence de changement dans la chronologie opérationnelle.

Rollback

Avant de modifier un pool, monitor ou une politique de steering de production, capturez la configuration actuelle et nommez l'action de rollback. Gardez les changements suffisamment petits pour qu'une régression observée ait une cause claire.

Les choix de rollback dépendent du changement :

• Restaurez la politique de steering ou l'ordre des pools de fallback antérieurs si un changement de politique envoie le trafic de manière inattendue.
• Réactivez une origine auparavant saine uniquement après avoir confirmé qu'elle peut recevoir le trafic en toute sécurité.
• Rétablissez un monitor à son endpoint ou à ses seuils antérieurs si un nouveau contrôle crée de faux états non sains, tout en examinant si l'ancien contrôle masquait un risque de service réel.
• Déplacez le trafic hors d'un pool uniquement après avoir confirmé la capacité de destination et les limites de dépendance.

Après le rollback, vérifiez les observations DNS, la distribution des requêtes d'origine, le statut des monitors, les flux utilisateur représentatifs et la saturation du pool récepteur. Ne déclarez pas le rétablissement uniquement parce que la mise à jour de configuration Cloudflare a réussi.

Pièges fréquents

• Utiliser un endpoint uniquement de liveness pour prendre des décisions de failover pour une application riche en dépendances.
• Configurer un pool standby sans tester sa capacité à absorber le transfert.
• Supposer que le TTL configuré équivaut à une durée de failover client garantie.
• Traiter un monitor sain comme la preuve que toutes les routes applicatives fonctionnent.
• Modifier monitors, pools, poids et steering dans une même release, rendant les régressions difficiles à isoler.
• Effectuer le failover vers des origines qui partagent la même base de données, réseau, fournisseur d'identité ou dépendance tierce que le pool en échec.
• Interpréter la sélection de pool Cloudflare comme une garantie de latence end-to-end minimale pour chaque utilisateur.

Réserves techniques

Le comportement de Load Balancing est façonné par le monitor configuré, la santé des pools, la politique de steering, l'ordre de fallback, le DNS TTL, le cache du résolveur, les connexions client, les paramètres produit Cloudflare et le comportement d'origine. Consultez la documentation Cloudflare actuelle avant de vous engager sur la disponibilité d'une politique, la détection de santé, le mouvement de trafic ou le temps de récupération. Définissez les objectifs de service à partir de résultats utilisateur mesurés et d'une capacité testée plutôt que d'une valeur de configuration fournisseur seule.

Sources principales

• Cloudflare Load Balancing overview
• Cloudflare Load Balancing concepts
• Cloudflare Load Balancing pools
• Cloudflare Load Balancing monitors
• Cloudflare Load Balancing steering policies
• Cloudflare Load Balancing TTL