# Round-robin DNS pour répartir la charge entre plusieurs serveurs WordPress > Un client refuse le coût d'un répartiteur de charge mais possède deux serveurs. Le DNS round-robin peut suffire, à condition d'en connaître précisément les limites. - Auteur : Clément Hadrot - Publié le : 2021-10-01 - Mis à jour le : 2021-10-01 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/round-robin-dns-repartir-charge-wordpress/ ## L’essentiel - Le round-robin DNS distribue sans jamais vérifier l'état des serveurs - Le cache des résolveurs casse l'équilibre théorique de la répartition - Les sessions et le contenu doivent déjà être partagés entre les serveurs Le client possédait déjà deux serveurs, hérités d'une ancienne architecture jamais rationalisée, et refusait catégoriquement d'ajouter un répartiteur de charge dédié à son budget, jugé disproportionné pour son trafic. La demande était directe : « Peut-on simplement faire pointer le domaine vers les deux serveurs, et que ça se répartisse tout seul ? » La réponse technique existe, elle s'appelle le round-robin DNS, mais elle mérite d'être présentée avec ses limites avant d'être présentée comme une solution. Le round-robin DNS consiste à publier plusieurs enregistrements A pour un même nom de domaine, chacun pointant vers un serveur différent. Les résolveurs DNS, en recevant la requête, retournent généralement ces adresses dans un ordre différent à chaque requête, ce qui répartit statistiquement les visiteurs entre les serveurs disponibles, sans aucun logiciel ni matériel de répartition dédié. ## La configuration technique, très simple en apparence ``` exemple.fr. IN A 203.0.113.10 exemple.fr. IN A 203.0.113.20 ``` Avec cette configuration, un résolveur DNS interrogé pour `exemple.fr` reçoit les deux adresses, dans un ordre qui varie généralement d'une requête à l'autre selon l'implémentation du serveur DNS faisant autorité. Sur un grand nombre de visiteurs, cette rotation tend statistiquement vers une répartition à peu près équilibrée entre les deux serveurs, sans configuration supplémentaire ni coût matériel. ## La limite qui casse tout : aucune vérification d'état > L'essentiel à retenir : Le round-robin DNS distribue sans jamais vérifier l'état des serveurs ; Le cache des résolveurs casse l'équilibre théorique de la répartition ; Les sessions et le contenu doivent déjà être partagés entre les serveurs C'est ici que le round-robin DNS révèle sa faiblesse structurelle : il ne sait absolument rien de l'état réel des serveurs qu'il liste. Si l'un des deux serveurs tombe en panne, ses adresses continuent d'être distribuées par le DNS exactement comme avant, puisque le DNS n'a aucun mécanisme natif de vérification de disponibilité. Une partie des visiteurs continuera donc d'être dirigée vers un serveur en panne, sans aucun basculement automatique vers le serveur encore fonctionnel. - Un vrai répartiteur de charge (load balancer) vérifie en continu l'état de chaque serveur via des sondes de santé et retire automatiquement un serveur défaillant de la rotation. - Le round-robin DNS ne fait rien de tel : il faudrait modifier manuellement la zone DNS pour retirer l'adresse du serveur en panne, puis attendre la propagation, un délai incompatible avec une réaction rapide à un incident. - Le TTL des enregistrements A joue un rôle déterminant ici : plus il est court, plus une correction manuelle se propage vite, mais un TTL trop court augmente aussi la charge de requêtes DNS globale. ## Le piège du cache résolveur, invisible depuis le serveur Une seconde limite, moins connue, concerne le comportement réel des résolveurs DNS intermédiaires (ceux des fournisseurs d'accès, des box internet, ou des résolveurs publics). Beaucoup de résolveurs mettent en cache la première adresse reçue pour la durée du TTL, et certains clients (navigateurs, systèmes d'exploitation) mettent eux-mêmes en cache leur propre résolution DNS localement. Un même visiteur, revenant plusieurs fois sur le site pendant une session, sera donc souvent redirigé systématiquement vers le même serveur, ce qui casse en pratique l'équilibre théorique attendu de la répartition. Ce comportement n'est pas un défaut de configuration : c'est un comportement normal et attendu du DNS, pensé à l'origine pour limiter la charge sur les serveurs faisant autorité, pas pour servir de mécanisme de répartition de charge fin et réactif. ## Les prérequis applicatifs, souvent oubliés Avant même de considérer les limites propres au DNS, une architecture à deux serveurs WordPress impose des prérequis applicatifs indépendants de la méthode de répartition choisie : 1. Les fichiers de `wp-content/uploads` doivent être identiques sur les deux serveurs, via une synchronisation ou un stockage partagé, sous peine d'afficher des images manquantes selon le serveur qui répond. 2. La base de données doit être partagée ou répliquée entre les deux serveurs, faute de quoi chaque serveur travaillerait avec un contenu différent. 3. Les sessions utilisateur (connexion à l'administration, panier WooCommerce) doivent être gérées de manière cohérente entre les deux serveurs, sous peine de déconnexions intempestives si un visiteur bascule d'un serveur à l'autre en cours de navigation. ## Dans quel cas le round-robin DNS reste défendable > Le round-robin DNS n'est pas une solution de répartition de charge à proprement parler : c'est une solution de distribution statistique de trafic, acceptable seulement quand une panne partielle temporaire reste tolérable pour l'activité du client. Pour ce client précis, la solution retenue a été un compromis : round-robin DNS activé pour la répartition du trafic en fonctionnement normal, combiné à une supervision externe des deux serveurs capable d'alerter rapidement en cas de panne, permettant une intervention manuelle de retrait de l'adresse concernée en quelques minutes plutôt qu'un basculement automatique instantané. Ce n'est pas la solution la plus élégante, mais elle correspondait au budget et au niveau de risque accepté par le client. ## En résumé Le round-robin DNS distribue le trafic sans jamais vérifier l'état des serveurs qu'il liste, et son équilibre réel est brouillé par le cache des résolveurs. Il peut suffire pour un besoin de répartition simple, à condition d'accepter ses limites et de les compenser par une supervision externe réactive. Dès que la tolérance à la panne devient stricte, une solution de répartition applicative plus avancée, avec vérification de santé en continu, devient nécessaire.