RR DNS et VIP multiples :
répartir sans aucun composant central

2. La configuration, en pratique

C'est le même keepalived que pour une VIP unique, avec deux blocs au lieu d'un. Extrait du nœud 1 :

vrrp_instance VIP_A {
    state           MASTER
    interface       eth0
    virtual_router_id 51
    priority        150          # 100 sur le nœud 2
    advert_int      1
    virtual_ipaddress { 192.0.2.10/24 dev eth0 }
    track_script    { chk_service }
}

vrrp_instance VIP_B {
    state           BACKUP
    interface       eth0
    virtual_router_id 52         # identifiant DIFFÉRENT du premier
    priority        100          # 150 sur le nœud 2
    advert_int      1
    virtual_ipaddress { 192.0.2.11/24 dev eth0 }
    track_script    { chk_service }
}

Côté DNS, on publie ensuite un seul enregistrement portant les deux adresses. Le track_script reste indispensable : sans lui, keepalived ne surveille que lui-même — c'est détaillé au niveau 2 de la haute disponibilité.

4. Qui choisit réellement l'adresse

On lit souvent que « le client en prend une au hasard ». C'est faux aux trois étages — le serveur autoritatif, le résolveur, le client — et c'est le troisième qui décide si le montage vous apporte une redondance réelle ou rien du tout.

a. Le serveur autoritatif fait tourner l'ordre

BIND ne tire pas au sort : il fait tourner l'ordre du jeu d'enregistrements à chaque réponse. Avec trois adresses A, B et C :

C'est une permutation circulaire, déterministe. Le point est tranché à la source : BIND 9.21.14 a supprimé l'ordre aléatoire, l'ISC notant qu'il « n'offrait pas une distribution uniforme de toutes les permutations et n'était supérieur à l'ordre cyclique en aucune manière » — et que désormais « random ordering is now an alias for cyclic ordering^[1] ».

b. Le résolveur récursif s'interpose

C'est l'étage qu'on oublie. La rotation a lieu chez l'autoritatif, mais vos clients ne lui parlent jamais : ils interrogent un résolveur récursif, qui garde le jeu d'adresses en cache pendant toute la durée de vie. La granularité réelle n'est donc pas « par client » mais « par résolveur ». Un site entier derrière un seul résolveur d'entreprise peut recevoir le même ordre pendant tout le TTL. C'est la vraie raison pour laquelle le round-robin DNS répartit mal sur de petits effectifs : ce n'est pas un défaut de hasard, c'est le cache.

c. Le client fait ce qu'il veut — et l'écart est énorme

Le DNS retourne plusieurs adresses, mais il ne définit pas comment elles seront utilisées. Certains clients essaient la première jusqu'au succès, d'autres les mettent en concurrence avec un délai, et quelques-uns les transforment réellement en groupe de cibles.

Deux limites, sinon on vend du RR DNS pour de la haute disponibilité

6. Quand ça suffit, et quand ça ne suffit plus

Le cran suivant est la couche 4 avec IPVS, qui apporte la pondération et un test de santé — au prix d'un composant à redonder.