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.
Laisser un commentaire