Home » Comment ça marche, Internet, Projets & Participations

C’est quoi, l’anycast ?

11 janvier 2011 7 commentaires
tags : ,
Download PDF

Vu qu’on commence doucement notre petit projet pour devenir les maîtres du monde, il est temps que je vous explique un peu mieux le principe d’anycast.

C’est une façon détournée de faire du réseau IP. Dans le monde normal des routeurs, chaque bloc d’IP est réparti sur un certain nombre de machines souvent situées au même endroit. Dans le monde anycast, le même bloc d’IP existe sur plein de machines un peu partout sur le réseau.

Comme vous le savez déjà si vous avez tout bien lu mon blog, pour retrouver son chemin sur internet, un paquet va suivre des routes que chaque routeur du réseau connait. A va dire a B quelles adresses il gère, B va le dire à C, C va le dire a D et D saura, du coup, joindre les IP de A en envoyant ses paquets à C qui lui même saura qu’il faut les envoyer à B qui les enverra à A.

Bien entendu, si vous mettez un lien entre D et A, ils pourront discuter directement sans passer par B et C.

Imaginez ce carré, sauf que le A qui est branché à B (on dira Ab) n’est pas le même groupe de machines que le A qui est branché à D (on dira Ad) et ces deux groupes n’ont aucun lien direct entre eux. Vous venez de mettre le pied dans le fabuleux monde de l’anycast : A peut être, au choix, constitué d’une multitude de réseaux interconnectés … ou pas.

Concrètement, dans notre exemple, B parlera avec les machines de Ab, D parlera aux machines de Ad et, selon sa configuration et ses préférences de routage, C parlera au choix à Ab ou à Ad.

Si Ab disparaît pour une raison quelconque (technique, financière, légale, ..), l’ensemble des routeurs B, C et D s’adresseront quasiment sans délais (quelques secondes au pire) à Ad. Du point de vue de l’utilisateur final, l’adresse IP n’aura pas changé. Si Ad distribue en tout points le même service que Ab, rien n’aura changé.

L’ensemble des machines qui, en tentant de joindre les IP d’un réseau anycast, s’adressent à une même plateforme sont appelés une cellule. Dans notre exemple, si C préfère B pour sortir son trafic, la cellule de Ab est constituée de B et de C et celle de Ad est constituée de D. Si C décide soudainement qu’il préfère D, il migrera instantanément de la cellule Ab à la cellule Ad.

Il existe deux contraintes majeures dans le monde anycast :

  • Ab et Ad doivent fournir strictement le même contenu. Si ce contenu est dynamique, il devra être synchronisé entre les deux plateformes en temps réel ce qui pose souvent problème dans le cas, par exemple, des bases de données si le nombre de noeuds constituant le réseau est important.
  • La connexion se faisant au plus proche, il est dangereux d’y faire fonctionner un service qui repose sur des connexions persistantes longues (par exemple l’IRC ou un appel VOIP) puisqu’une simple modification de politique de routage chez un opérateur fait bouger les limites des cellules anycast et on se retrouve donc, en plein milieu d’une session, en face d’une machine qui n’est plus la même qu’une seconde plus tôt.

Par contre, si le service est statique (par exemple les .CSS, .JS et les images d’un site à fort trafic ou des serveurs DNS), l’anycast est tout indiqué, puisqu’il permet de répartir sans aucun équipement spécifique le trafic en forçant les machines qui consultent le service à s’adresser « au plus proche » du point de vue de la topologie du réseau.

Les possibilités offertes par l’anycast sont encore peu exploitées, mais l’avenir risque d’être passionnant.

7 Comments »

  • Tanéléo said:

    À tord ou à raison, je me demande si la généralisation de l’anycast ne va pas entraîner une dérive vers une «régionalisation» de l’Internet. On ne verrait plus le même Internet selon où on se trouve sur le réseau.

    Bien sûr, on nous dira que c’est pour proposer de nouveaux services aux utilisateurs. Par exemple une régie publicitaire à l’adresse IP 1.2.3.4 délivrera un contenu différent selon que j’effectue une requête depuis Sarlat ou depuis Roubaix.

    Peut-être que ce pourrait être une bonne chose. Une sorte de réponse à l’uniformisation des individus par un seul et même Internet, en en proposant divers visages selon les régions, les coutumes, les cultures. Peut-être.

    Mais l’anycast a aussi l’inconvénient de devoir multiplier les machines en divers points du réseau. Et du coup, cette technique ne peut être utilisée que par de grosses sociétés.

    [Les réponses différentes en fonction de qui demande, ça se fait déjà de façon très large. Avec des cookies, avec des bases geoip, etc .. L’anycast n’y changera rien. Par contre, coté problématique de flux de plus en plus gros à transporter parce que l’infrastructure d’hébergement est a babeloued, c’est une solution très propre]

  • Pierre Beyssac said:

    Jolie explication.

    Une remarque : « peu exploitées », les possibilités de l’anycast ? Il ne faut pas oublier que la plupart des serveurs racines DNS l’exploitent intensément, ainsi que pas mal de TLD nationaux (c’est le cas de .fr à ma connaissance) : le DNS est idél pour ça : données relativement statiques et majoritairement UDP ou sessions TCP très courtes. De même que les gros CDN comme Akamai qui le mettent en œuvre depuis des années…

    [Même si les racines DNS utilisent l’anycast et sont des composantes .. capitales .. d’internet, il n’en reste pas moins que l’usage n’est pas très répandu, comparé à l’hébergement à Papa sur un serveur, un cloud or whatever. Sur le coté « sessions TCP très courtes », j’adorerais avoir des stats de probabilité de changement de cellule et donc une estimation globale de la durée maxi d’une session envisageable en anycast. Des idées ? :)]

  • Dodot said:

    Plus je lis des articles sur anycast, plus je trouve ça dérangeant.

    Une même adresse IP attribuée à plusieurs machines, en plusieurs points du réseau, juste comme ça, parce que ça permet d’optimiser le temps de réponse ou d’augmenter la fiabilité du service, et parce que c’est possible de le faire avec BGP, je ne comprends pas que ça puisse devenir une « bonne pratique ».

    Je comprends très bien les avantages que ça apporte, et j’imagine que quand ça marche, c’est fabuleux. Mais je pense que ça devrait être géré par une couche supérieure du réseau. Est-ce que je suis le seul à penser que « c’est le mal » ?

  • Pierre Beyssac said:

    @Dodot : l’anycast n’est pas le premier cas où une adresse IP est attribuée à plusieurs machines… c’est déjà pratiqué couramment pour les configurations de « failover ». Si c’est pensé et fait correctement, il n’y a aucun souci. Il faut penser à l’adresse anycast non plus comme une adresse de machine mais comme une adresse de service ou un groupe de machines. C’est exactement ce qui se passe pour les serveurs DNS racines. C’est également ce qui se passe pour le service 6to4 (tunnels automatiques v6 dans v4) qui utilise 192.88.99.1. Pour des protocoles « sans état », à mon avis il n’y a pas photo, anycast est de loin la méthode la plus simple et la plus propre, surtout comparée aux bidouilles absolument infâmes que sont beaucoup d’appliances de failover/load balancing/etc.

    Cf http://en.wikipedia.org/wiki/Anycast qui discute tout ça plus en longueur.

    @Turblog : typiquement une session TCP pour du DNS est ultra-courte, je ne saurais te dire qui a fait des stats là dessus. Le sujet a très probablement été étudié et documenté par au moins un des projets d’anycastisation des serveurs racines :-) (les projets ISC et RIPE étaient les deux premiers si j’ai bonne mémoire).

  • jerome said:

    Je crois que j’ai la question con du jour (ou du soir)…

    Pourquoi les services DNS ne sont pas sur une plage d’adresse MULTICAST ?

    On aurais plus besoin de définir un serveur DNS…
    On indiquerait une ip classe D et on pourrait facilement mettre deux ou trois serveur DNS sur chaque réseaux qui seraient synchronisés entre eux (plus de DNS « secondaire »…)
    ils répondraient au requêtes multicast via une réponse unicast, où même multicast.

    Je ne parle pas des serveurs tld (encore que…) mais des serveur DNS locaux…

  • Bruno (author) said:

    Pour la simple raison que peu de réseaux gèrent le multicast en interne, et encore moins en externe.

    Accessoirement, je suis pas certain de bien voir toutes les conséquences possibles d’une adaptation du DNS au multicast qui est plutôt fait pour balancer la même chose à plein de gens. Et perso, j’en ai rien à secouer de savoir l’IP du site que mon voisin va aller visiter :)

  • jerome said:

    Le truc c’était juste de plus avoir à renseigner une ip DNS, les serveurs écoutent sur une route multicast et répondent un message unicast.

    Cela faciliterait les déploiement et la gestion des serveurs secondaires.

    Mais bon c’est vrai que c’est pas forcément si intéressant que ça, surtout si personne ne gère le multicast…

    Y a t ‘il des avancées au niveau IPv6 pour la prise en charge du multicast et de l’anycast ?

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.


trois + = 10