Construction et exploitation d'un réseau anycast tolérant aux pannes

Bonjour, Habr! Ce qui suit est une transcription du rapport d'Evgeny error2407 Bogomazov (ingénieur R&D réseau) et Dmitry h8r Shemonaev (chef du CNO) du passé UPTIMEDAY. Vidéo à la fin du post.

Aujourd'hui, nous aimerions parler des problèmes qui se posent lors de la construction d'un réseau anycast. Pourquoi nous sommes-nous embarqués dans ce dossier et que faisons-nous là-bas.

Chez Qrator Labs, nous construisons notre propre réseau anycast pour résoudre des problèmes spéciaux qui diffèrent de ceux des opérateurs de télécommunications «ordinaires». En conséquence, nous avons des points de présence dans ces régions - nous avons juste oublié d'ajouter la Russie ici. Et cela signifie que nous avons de nombreuses histoires sur la façon de faire et de ne pas le faire. Aujourd'hui, nous partagerons avec vous certains d'entre eux.


Qu'allons-nous dire, étant donné que le sujet est initialement volumineux? Au début, nous voulions seulement faire des questions / réponses (questions et réponses), mais on nous demandait toujours de lire le rapport. Par conséquent, si nous ne disons rien, mais nous n'avons certainement pas le temps, rattrapez-nous après, en marge.

Dans le cadre de la planification, nous allons essayer de parler de la différence entre l'équilibrage à l'aide de DNS et BGP. Comment choisir de nouveaux sites et ce à quoi vous devez faire attention afin d'éviter des douleurs ultérieures. Comment soutenir tout cela et à quel point cette tâche difficile Dmitry dira.

Pour commencer, déterminons dans quelle mesure vous connaissez le sujet.
- Combien savent ce qu'est anycast et pourquoi il est nécessaire? (environ un tiers des mains se lèvent dans le hall)
- Et qui connaît le DNS et a configuré le serveur? (environ le même nombre de mains)
- Et BGP (deux mains dans le cadre)

Encore beaucoup.

- Eh bien, la dernière question - qui connaît NOC? Qui a eu des problèmes avec les fournisseurs et qui a essayé de les résoudre? (la main de l'administrateur système Habr est visible dans le cadre)

Super. Dans ce cas, j'espère que ce que nous allons vous dire arrivera.

Avant de passer à anycast, voyons pourquoi cela est nécessaire. Vous disposez d'une application avec laquelle vous souhaitez traiter les demandes des clients. Vous êtes hébergé quelque part - alors que vous n'y pensez pas particulièrement. Achetez le nom DNS, résolvez-le, etc. Ensuite, signez le certificat, car HTTPS. Votre application grandit.

Tout d'abord, vous devez gérer la charge. Si votre application "tire" en même temps, c'est-à-dire qu'elle devient très populaire, beaucoup plus d'utilisateurs viennent à vous. Vous devez acheter du fer et équilibrer la charge.

De plus, des clients particulièrement exigeants peuvent surgir avec les mots: "Les gars, vous devriez être disponible toujours et partout pour ce genre d'argent!" Ce qui conduit au fait que vous posez la redondance des ressources informatiques non seulement pour le traitement des pics de charge, mais simplement comme réserve.

De plus, aujourd'hui, il a déjà été mentionné dans d'autres apparences, vous ne pouvez pas placer les glandes dans un centre de données - une catastrophe naturelle peut se produire, ce qui signifie que l'application se mettra en arrêt, ce qui entraînera des pertes financières et autres. Par conséquent, si votre application s'est suffisamment développée, vous devriez déjà être situé dans plusieurs centres de données, sinon ce sera mauvais.

Le problème a un revers: si votre application est sensible au temps, comme en analyse financière ou en trading, il est important que vous envoyiez des demandes à vos utilisateurs le plus rapidement possible. La latence notoire avec laquelle deux points sont connectés. La première - si vous souhaitez envoyer une demande le plus rapidement possible, alors pour cela, le nombre de demandes et de réponses doit être aussi petit que possible. Encore une fois, le fait est que lorsque l'utilisateur se connecte à vous pour la première fois - tout ne fonctionne pas et il est obligé de traverser tous les cercles de l'enfer. Le deuxième point est la vitesse de la lumière. Un paquet de l'Europe occidentale à la Russie ne peut pas aller plus vite qu'un certain nombre de millisecondes, il n'y a rien à faire.

Il est nécessaire d'être situé dans plusieurs centres de données car nous voulons la redondance et nous devons nous rapprocher des clients potentiels. Si, par exemple, votre principale région cliente est l'Amérique, vous y placerez votre équipement afin que le trafic ne passe pas par d'autres pays et parties du monde.

Il s'avère qu'à partir d'un moment donné, vous devrez être présent dans toutes les régions du monde sur différents sites. Et ce n'est toujours pas diffusé.

Vous avez donc besoin de quelques sites. D'une manière ou d'une autre, vous devez les choisir, tous deux initialement nouveaux, et comprendre leur capacité à évoluer - pendant une surcharge, vous devrez acheter du matériel supplémentaire.

Si vous avez déjà plusieurs sites, vous devez apprendre à répartir les utilisateurs entre eux. Il y a deux chaises: BGP et DNS.

À partir de deux points, nous commencerons par le dernier. Et encore deux approches principales. Dans le premier, vous avez différents sites avec différentes adresses IP et, par conséquent, lorsqu'un utilisateur présente une demande - il obtient l'IP d'un site spécifique et les mappe dessus.

Que décidons-nous ici? Nous voulons qu'un utilisateur d'une certaine région accède à un site situé dans la même région. La solution la plus simple et la plus stupide consiste à utiliser GeoDNS. Vous comprenez les régions dans lesquelles se trouvent les préfixes - vous prenez ces données, les transférez dans un serveur DNS, mappez les utilisateurs en conséquence, si l'IP source provient du bon préfixe, vers le bon site. Mais il y a un problème - les résolveurs. Et environ 15 à 20% des demandes proviennent de résolveurs - c'est-à-dire que l'IP source sera 8.8.8.8. Où mettre ça?

Pour ce faire, il existe EDNS, qui permet dans le cadre de la demande de transférer le sous-réseau client d'origine d'où il provient. Comme vous le savez, le 1er février 2019, le jour du drapeau DNS s'est produit - à partir de ce jour, tous les serveurs DNS doivent prendre en charge cette extension.

Dans cet exemple, vous pouvez avoir un ou plusieurs sites où se trouvent des serveurs DNS qui mappent les utilisateurs - et les serveurs eux-mêmes peuvent être distribués dans le monde entier. Et déjà dans le cadre du DNS, il est possible d'utiliser anycast - nous en parlerons un peu plus tard.

Dans le schéma général, vous mappez l'utilisateur vers le site le plus proche de lui, en donnant l'adresse de ce site particulier. Il est utilisé moins fréquemment.

La troisième approche est liée au fait que même si l'utilisateur vient de la même région où se trouve le site, cela ne signifie pas que le problème des retards soit résolu. Il peut être encore plus rentable de transférer l'utilisateur vers un autre site, car la région peut être surchargée si des itinéraires alternatifs sont disponibles. Serait-il agréable de l'utiliser? Malheureusement, il n'y a presque pas de solutions actuelles pour faire quelque chose de similaire. Facebook a montré en quelque sorte qu'il avait fait cela - mais il n'y a pas de boîte, tout devra être fait de vos propres mains.

Qu'avons-nous avec DNS?

Les avantages sont que différents utilisateurs peuvent recevoir des adresses différentes et qu'un utilisateur spécifique peut être envoyé vers un site strictement défini - c'est-à-dire que vous pouvez travailler avec des utilisateurs individuels. Eh bien, le DNS est facile à configurer.

Quels sont les inconvénients? Si vous effectuez un ajustement granulaire, la configuration se développe assez rapidement, ce qui est impossible à supporter avec vos mains. Besoin d'automatisation. Et si l'automatisation est mal effectuée, alors tout tombera en panne - si le DNS se trouve, alors l'application est inaccessible.

D'un autre côté, si vous effectuez un équilibrage DNS, l'utilisateur mappera vers un site spécifique et son IP deviendra vulnérable. C'est la raison pour laquelle nous n'utilisons pas d'équilibrage DNS à la maison, car dans ce cas, tout le trafic de l'attaque peut circuler exactement en un point, le désactivant.

Et comme déjà mentionné, DNS ne prend pas en charge l'équilibrage de latence prêt à l'emploi. Et le faire vous-même est très difficile.

Venons-en enfin aux choses plus fines, à savoir BGP anycast.

C'est exactement notre cas. À quoi ça sert? Tous les sites ont la même IP, ou plutôt, ils annoncent le même préfixe. L'utilisateur mappe vers le site "le plus proche" de celui-ci. «Le plus proche» du point de vue de BGP - un tel préfixe est annoncé en utilisant différentes routes, et si l'opérateur a plusieurs routes vers le site annoncé, il choisira le plus souvent la plus courte. Toujours du point de vue de BGP. Bientôt, nous expliquerons pourquoi c'est mauvais.

BGP fonctionne également avec la disponibilité des préfixes, donc vous opérez toujours sur un sous-réseau et ne pouvez pas manipuler des IP individuelles.

En conséquence, comme le même préfixe est annoncé sur tous les sites, tous les utilisateurs d'une même région seront dirigés vers le même site. L'attaquant n'a aucun moyen de transférer la charge d'une région à une autre, vous devez donc gagner autant de puissance à chacun des endroits que l'opérateur qui a choisi cette route le voulait. Même si vous ne marquez pas, il peut toujours être protégé.

Le même préfixe est annoncé - quoi de plus simple? Mais il y a aussi des problèmes.
La première est qu'en raison de la nécessité d'annoncer le même préfixe dans le monde, vous êtes obligé d'acheter des adresses indépendantes du fournisseur, qui sont plusieurs fois plus chères.

La seconde se résume au fait que les utilisateurs d'une région ne peuvent pas simplement être jetés dans une autre, si soudainement certains d'entre eux sont illégitimes ou dans le but de diversifier le trafic d'attaque en utilisant d'autres sites, parce que certains font mal. Il n'y a pas de tels stylos.

Le troisième problème est que dans le cadre de BGP, il est très facile de choisir le "mauvais" site et les "mauvais" fournisseurs. Il vous semblera que vous avez une redondance et une disponibilité, mais en réalité il n'y aura ni l'un ni l'autre.

Vous avez plusieurs sites entre lesquels vous souhaitez disperser les utilisateurs. Quelles sont les poignées pour restreindre une certaine région, attirer les utilisateurs vers un site spécifique?

Il y a Geo Community. Pourquoi le sont-ils? Permettez-moi de vous rappeler - vous choisissez l'itinéraire le plus proche du point de vue de BGP. Et vous avez un opérateur de niveau 1, par exemple Level3, qui a son propre tronc dans le monde. Le client Level3, si vous y êtes directement connecté, se trouve à deux espoirs de vous. Et un opérateur local - sur trois. En conséquence, un opérateur américain sera plus proche de vous qu'un opérateur russe ou européen, car du point de vue de BGP, il en est ainsi.

En utilisant Geo Community, vous pouvez limiter la région dans laquelle un opérateur aussi important et international annoncera votre itinéraire. Le problème est également qu'ils ne sont pas toujours disponibles (Geo Community).

Nous avons plusieurs cas en ce qui nous concerne. Dim?

(Dmitry Shemonaev prend la parole)


Hors de la boîte, de nombreux opérateurs ne fournissent pas cela et disent que, disent-ils, nous ne restreindrons rien pour la neutralité du réseau, la liberté, etc. Nous devons expliquer aux opérateurs depuis longtemps et qui nous sommes, pourquoi nous le voulons et pourquoi c'est si important pour nous, et aussi expliquer pourquoi cela ne s'applique pas à la neutralité qu'ils ont en tête. Parfois, cela fonctionne - et parfois non, et nous refusons simplement de coopérer avec des opérateurs potentiellement intéressants car une telle coopération entraînera de nouvelles douleurs dans le fonctionnement de notre service.

De plus, nous rencontrons souvent le fait qu'il existe un certain nombre d'opérateurs qu'Eugene a déjà mentionnés - ce sont des Tier-1, qui n'achètent du trafic à personne et n'échangent que du trafic entre eux. Mais, à côté d'eux, il y a au moins une douzaine d'opérateurs qui ne sont pas de niveau 1 - ils achètent du trafic, mais en même temps, ils ont également des réseaux déployés dans le monde entier. Vous n'avez pas besoin d'aller loin - du plus proche de nous, c'est Rostelecom ou ReTN, un peu plus loin il y a les merveilleux télécoms de Taipei, China Unicom, Singtel et ainsi de suite.

Et en Asie nous sommes assez souvent confrontés à une telle situation que, semble-t-il, nous avons plusieurs points de présence en Asie, nous sommes connectés à plusieurs opérateurs assez importants, du point de vue de cette région. Cependant, nous sommes constamment confrontés au fait que le trafic en provenance d'Asie va vers notre site via l'Europe ou effectue un voyage transatlantique. Du point de vue de BGP, c'est tout à fait normal, car il ne prend pas en compte la latence. Mais l'application souffre dans de telles conditions, ses utilisateurs aussi - en général, tout le monde souffre, mais du point de vue de BGP, tout va bien.

Et vous devez faire quelques changements avec vos mains, faire de l'ingénierie inverse sur la façon dont l'acheminement de tel ou tel opérateur est organisé, parfois négocier, demander, mendier, s'agenouiller. En général, faites n'importe quoi pour résoudre ces problèmes. Avec cela, notre CNO est confronté à une régularité enviable.

En règle générale, les opérateurs répondent à leurs besoins et, dans certains cas, sont prêts à fournir un certain ensemble ... Mais en général, ceux qui ont travaillé avec BGP au niveau communautaire peuvent-ils lever la main? (Sourires) Génial! Autrement dit, les opérateurs sont prêts à fournir un ensemble de gestionnaires de communauté afin, par exemple, de réduire les préférences locales dans une certaine région, ou d'ajouter des préfixes, ou de ne pas bien annoncer ou autre chose.

Par conséquent, il existe deux façons d'équilibrer la charge dans BGP. Le premier est de savoir comment il est écrit sur la diapositive, le soi-disant se prépare. Nous pouvons imaginer le chemin vers BGP comme une petite ligne répertoriant les systèmes autonomes par lesquels passe le chemin du paquet de l'expéditeur au destinataire. Vous pouvez ajouter un nième nombre de systèmes autonomes à ce chemin, et par conséquent, le chemin sera étendu et ne deviendra pas très prioritaire. Il s'agit d'une méthode frontale et elle ne fonctionne pas pour tout - si vous ajoutez du préfixe, il n'est pas granulaire, c'est-à-dire que tout le monde le verra dans le cône de l'opérateur dans lequel vous effectuez cette manipulation.

D'autre part, il y a aussi la communauté BGP, qui en marque, pour comprendre d'où vient tel ou tel préfixe, dont il s'agit par rapport à l'opérateur - c'est-à-dire une fête, un client ou en amont, et aussi à quel endroit il est pris et ainsi de suite. Et il y a des gestionnaires de communauté qui vont au routeur vers l'opérateur et il prend certaines actions avec ce préfixe.

La plupart des opérateurs ont des communautés restrictives. Prenons par exemple l'opérateur russe abstrait, qui est connecté à un certain nombre d'opérateurs russes dans le vide. Certains d'entre eux ont des relations d'égal à égal, ce qui implique un échange paritaire du trafic, et certains les achètent. En conséquence, ils fournissent la communauté afin de faire des préfixes dans cette direction, en étendant le chemin AS, ou de ne pas annoncer ou changer de préf local. Si vous travaillez avec BGP - regardez la communauté et découvrez ce que le demandeur peut faire pour devenir votre fournisseur. Parfois, les communautés sont cachées et vous devez communiquer soit avec les gestionnaires des opérateurs, soit avec des experts techniques afin de nous montrer un certain ensemble pris en charge.

Par défaut, la communauté, dans le cas de la région européenne, est décrite dans RIPE DB. Autrement dit, vous faites une demande de whois les numéros du système autonome et le champ Remarques indique généralement ce que l'opérateur a en termes de marquage et de gestion de la communauté. Tout le monde ne l'a pas, il faut donc souvent chercher différents endroits intéressants.

Dès que vous commencez à utiliser BGP, vous dites essentiellement que le réseau fait partie de votre application et non quelque chose d'abstrait, vous devez donc tenir compte des risques.

Par exemple, nous avons eu un cas avec une institution financière lettone, dont le préfixe, s'il était inclus dans notre réseau, est devenu indisponible dans environ la moitié de la Lettonie. Bien qu'il semble que rien n'a changé - le même préfixe que nous annonçons chez les opérateurs de niveau 1, en Europe, il semblerait que tout y soit, y compris la redondance. Mais nous ne pouvions même pas imaginer qu'environ la moitié des opérateurs lettons avaient comme périphériques frontaliers qu'ils ne pouvaient pas digérer le volume complet de la vue complète (la table de routage BGP entière), qui à l'époque était d'environ 650 000 préfixes. Ils se tenaient là, eh bien, si quelqu'un sait ce qu'est le Catalyst 3550, c'est exactement là qu'il se trouvait, il ne pouvait que 12 000 préfixes. Eh bien, ils ont obtenu un certain nombre de préfixes de IX'a, sur lesquels, bien sûr, il n'y avait pas de défaut. Parallèlement à cela, d'un autre opérateur - la télévision lettone, dont le préfixe dans le IXème n'était pas / 24, mais / 22 dans lequel se trouvait ce / 24.

En conséquence, il est allé dans un endroit où il ne savait pas où l'acheminer et tout a volé dans le tuyau. Pour résoudre ce problème, il nous a fallu environ deux jours et une correspondance persistante avec les opérateurs lettons jusqu'à ce qu'ils nous montrent la sortie de leur périphérique frontalier et nous n'avons remarqué que le nom d'hôte là-bas. Bonjour à tous, c'est tellement amusant parfois.

Il existe de nombreux opérateurs avec du vieux fer. Il existe de nombreux opérateurs avec une étrange compréhension du fonctionnement du réseau. Et maintenant c'est aussi votre problème si vous allez jouer avec BGP. Eh bien, en fin de compte, de nombreux opérateurs sont unijambistes (un fournisseur de connectivité supérieur), ils ont donc leurs propres jeux de béquilles.


(Evgeny Bogomazov continue)



Comme vous pouvez le voir, même ce sujet peut être développé pendant longtemps et il est difficile de le garder dans les 40 minutes.

Donc, vous avez des stylos avec lesquels vous voulez limiter la région. Voyons maintenant ce que vous devez regarder et ce qui est important à considérer lorsque vous souhaitez héberger sur un nouveau site.

Le meilleur cas n'est pas d'acheter votre matériel, mais d'accepter un cloud sur l'hébergement. Alors déjà, il sera possible de convenir avec lui que vous vous connecterez indépendamment à certains prestataires.

D'un autre côté, si vous avez quand même emprunté ce chemin, vous devez comprendre approximativement quelle région, avec ou sans poignées, sera rapprochée de ce site. Pour ce faire, vous avez besoin d'une modélisation, ou plutôt, vous devez comprendre que s'il existe plusieurs itinéraires à partir de sites différents, lequel sera choisi comme le meilleur. Pour ce faire, vous devez avoir une idée du fonctionnement de BGP et de la circulation des itinéraires dans la situation actuelle.

Deux points principaux sont la longueur du chemin, influencée par les préfixes et la préférence locale, qui dit que les itinéraires des clients sont préférables aux itinéraires d'ailleurs. En principe, ces deux points suffisent pour comprendre quelle région sera rapprochée et où se lever.

, , — , , (« ») Tier-1 , .

, IPv4 IPv6 , .

. : « ?» . — IX . , , , , , , IX' . , IX' , , — .

— , . — , , , IX'.

, , , ?

( )

. , . - , , , BGP anycast — .

, , RTT , . , , , , RTT , . — .

, , — .
, — «», . , , — , IGP , , . , — , , .

, «» , SDN , . . , SDN-, (CenturyLink) . - . NOC . - .

— .

, , — . — «», — «» ( ). , , «». , , . , , , -, , . - .

. community, NOC. , , , - - - DE-CIX . blackhole community.

, , . , , , - , - , . , . , — NOC , NOC , . . .

NOC'. Network Operations Center — , , , . , . ? - . . .

, « - » , . , — , . NOC' , . , , — RIPE Atlas . , . , .

community , . : , . , , . , , - community, . , - — community . community, . , , . community , . Qu'est-ce que cela signifie? latency — . - , , .

— 10 , , Ansible, Chef, Puppet, . ? BGP : « BGP-, ». .

, , , . — - . , . , , — , : « -!» — , ( ) — . , , . — .

, .

( )

. anycast' , , , .

, . , — , . , , , . RTT .

, , — . , anycast , — .

- — - , , . . anycast , — - , .

, - , , , . - , - - , , , — .

, — . — , — . , , BGP . , - , , .

, . — , DNS — . SDN' - , , , .

— DNS. Dyn — , 2016 , . DNS , . DNS- , , IETF , , DNS-.

, DNS. , , . RTT, , DNS- , , - . — DNS.

anycast DNS , DNS- .

? , latency, , .
, . - . , .

. , . - — , .

90% . 10% — . . «» ? , , . , , .

Il est donc préférable de déléguer que d’acheter votre propre matériel. Même une partie des fonctionnalités que nous avons décrites aujourd'hui dans le cadre d'anycast et les problèmes qui se posent sont faciles à résoudre de manière incorrecte. Donc, s'il est possible de ne pas résoudre ces problèmes et de les transférer à des étrangers, cela vaut probablement la peine. Sinon, vous devez répondre avec précision à la question de savoir pourquoi vous devez implémenter tout cela.

Eh bien, en cas d'attaque, tournez-vous vers les nuages ​​qui se spécialisent dans la résolution de tels problèmes. Eh bien, ou vous pouvez toujours discuter avec nous.

Je vous remercie! Des questions?