В numéro précédent J'ai décrit le cadre d'automatisation du réseau. Selon certains, même cette première approche du problème a déjà résolu certaines questions. Et cela me rend très heureux, car notre objectif dans le cycle n'est pas de dissimuler Ansible avec des scripts Python, mais de construire un système.

Le même cadre fixe l’ordre dans lequel nous traiterons la question.
Et la virtualisation des réseaux, à laquelle est consacré ce numéro, ne rentre pas particulièrement dans le thème ADSM, où nous analysons l'automatisation.

Mais regardons les choses sous un autre angle.

De nombreux services utilisent le même réseau depuis longtemps. Dans le cas d’un opérateur télécom, il s’agit par exemple de la 2G, de la 3G, du LTE, du haut débit et du B2B. Dans le cas d'un DC : connectivité des différents clients, Internet, stockage bloc, stockage objet.

Et tous les services nécessitent un isolement les uns des autres. C'est ainsi qu'apparaissent les réseaux superposés.

Et tous les services ne veulent pas attendre qu’une personne les configure manuellement. C'est ainsi qu'apparaissent les orchestrateurs et le SDN.

La première approche d'automatisation systématique du réseau, ou plutôt d'une partie de celui-ci, a depuis longtemps été adoptée et mise en œuvre dans de nombreux endroits : VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

C’est ce dont nous allons traiter aujourd’hui.

Teneur

• raisons
• Vocabulaire
• Sous-couche - réseau physique
• Superposition - réseau virtuel
  • Superposition avec les TdR
  • Superposition de l'hôte
  • Utiliser le tissu en tungstène comme exemple
    • Communication au sein d’une seule machine physique
    • Communication entre VM situées sur différentes machines physiques
    • Sortie vers le monde extérieur

• QFP
• Conclusion
• Liens utiles

raisons

Et puisque nous en parlons, il convient de mentionner les prérequis à la virtualisation des réseaux. En fait, ce processus n’a pas commencé hier.

Vous avez probablement entendu plus d’une fois que le réseau a toujours été la partie la plus inerte de tout système. Et cela est vrai dans tous les sens du terme. Le réseau est la base sur laquelle tout repose, et il est assez difficile d'y apporter des modifications - les services ne le tolèrent pas lorsque le réseau est en panne. Souvent, la mise hors service d’un seul nœud peut mettre hors service une grande partie des applications et avoir un impact sur de nombreux clients. C'est en partie pourquoi l'équipe du réseau peut résister à tout changement - parce que maintenant, d'une manière ou d'une autre, cela fonctionne (nous ne savons peut-être même pas comment), mais ici, vous devez configurer quelque chose de nouveau, et on ne sait pas comment cela affectera le réseau.

Afin de ne pas attendre que les réseauteurs insèrent des VLAN et n'enregistrent aucun service sur chaque nœud du réseau, les gens ont eu l'idée d'utiliser des overlays - des réseaux overlay - dont il existe une grande variété : GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Leur attrait réside dans deux choses simples :

• Seuls les nœuds d'extrémité sont configurés ; il n'est pas nécessaire de toucher aux nœuds de transit. Cela accélère considérablement le processus et vous permet parfois d'exclure complètement le service d'infrastructure réseau du processus d'introduction de nouveaux services.
• La charge est cachée au plus profond des en-têtes - les nœuds de transit n'ont pas besoin d'en savoir quoi que ce soit, ni sur l'adressage sur les hôtes, ni sur les routes du réseau superposé. Cela signifie que vous devez stocker moins d'informations dans les tableaux, ce qui signifie utiliser un appareil plus simple/moins cher.

Dans ce numéro pas tout à fait complet, je n'ai pas l'intention d'analyser toutes les technologies possibles, mais plutôt de décrire le cadre de fonctionnement des réseaux superposés dans les DC.

La série entière décrira un centre de données composé de rangées de racks identiques dans lesquels le même équipement serveur est installé.

Cet équipement exécute des machines virtuelles/conteneurs/sans serveur qui implémentent des services.

Vocabulaire

En cycle serveur Je nommerai un programme qui implémente le côté serveur de la communication client-serveur.

Les machines physiques dans les racks sont appelées serveurs aucun nous allons.

Machine physique — Ordinateur x86 installé dans un rack. Le terme le plus fréquemment utilisé hôte. C’est comme ça qu’on l’appellera »machine"Ou hôte.

Hyperviseur - une application exécutée sur une machine physique qui émule les ressources physiques sur lesquelles s'exécutent les machines virtuelles. Parfois, dans la littérature et sur Internet, le mot « hyperviseur » est utilisé comme synonyme de « hôte ».

Machine virtuelle - un système d'exploitation fonctionnant sur une machine physique au-dessus d'un hyperviseur. Pour nous, dans ce cycle, peu importe qu'il s'agisse réellement d'une machine virtuelle ou simplement d'un conteneur. Appelons-le "VM«

Locataire est un concept large que je définirai dans cet article comme un service distinct ou un client distinct.

Locations multiples ou multilocation - l'utilisation de la même application par différents clients/services. Dans le même temps, l'isolement des clients les uns des autres est obtenu grâce à l'architecture de l'application, et non via des instances exécutées séparément.

TdR – Commutateur Top of the Rack - un switch installé dans un rack auquel sont connectées toutes les machines physiques.

En plus de la topologie ToR, divers fournisseurs pratiquent End of Row (EoR) ou Middle of Row (bien que ce dernier soit une rareté désobligeante et que je n'aie pas vu l'abréviation MoR).

Réseau de sous-couche ou le réseau sous-jacent ou sous-couche est l'infrastructure physique du réseau : commutateurs, routeurs, câbles.

Réseau superposé ou réseau superposé ou superposition - un réseau virtuel de tunnels fonctionnant au-dessus du réseau physique.

Tissu L3 ou tissu IP - une invention étonnante de l'humanité qui vous permet d'éviter de répéter STP et d'apprendre TRILL pour les entretiens. Un concept dans lequel l'ensemble du réseau jusqu'au niveau d'accès est exclusivement L3, sans VLAN et, par conséquent, sans immenses domaines de diffusion étendus. Nous verrons d’où vient le mot « usine » dans la partie suivante.

SDN - Réseau défini par logiciel. A peine besoin d'une introduction. Une approche de la gestion de réseau dans laquelle les modifications apportées au réseau ne sont pas effectuées par une personne, mais par un programme. Cela signifie généralement déplacer le plan de contrôle au-delà des périphériques réseau finaux vers le contrôleur.

NFV — Virtualisation des fonctions réseau — virtualisation des périphériques réseau, suggérant que certaines fonctions réseau peuvent être exécutées sous la forme de machines virtuelles ou de conteneurs pour accélérer la mise en œuvre de nouveaux services, organiser le chaînage de services et une évolutivité horizontale plus simple.

VNF - Fonction de réseau virtuel. Appareil virtuel spécifique : routeur, switch, pare-feu, NAT, IPS/IDS, etc.

Je simplifie maintenant délibérément la description à une implémentation spécifique, afin de ne pas trop dérouter le lecteur. Pour une lecture plus approfondie, je le renvoie à la section références. De plus, Roma Gorge, qui critique cet article pour ses inexactitudes, promet d'écrire un numéro séparé sur les technologies de virtualisation des serveurs et des réseaux, plus approfondi et attentif aux détails.

Aujourd’hui, la plupart des réseaux peuvent être clairement divisés en deux parties :

Thibaude — un réseau physique avec une configuration stable.
Recouvrir — abstraction sur Underlay pour isoler les locataires.

Cela est vrai aussi bien pour le cas du DC (que nous analyserons dans cet article) que pour celui des FAI (que nous n'analyserons pas, car cela a déjà été SDSM). Bien entendu, avec les réseaux d’entreprise, la situation est quelque peu différente.

Photo mettant l'accent sur le réseau :

Thibaude

Underlay est un réseau physique : commutateurs matériels et câbles. Les appareils souterrains savent comment atteindre les machines physiques.

Il s’appuie sur des protocoles et des technologies standards. Notamment parce que les dispositifs matériels fonctionnent aujourd'hui sur des logiciels propriétaires qui ne permettent ni de programmer la puce ni de mettre en œuvre ses propres protocoles ; par conséquent, une compatibilité avec d'autres fournisseurs et une normalisation sont nécessaires.

Mais quelqu'un comme Google peut se permettre de développer ses propres commutateurs et d'abandonner les protocoles généralement acceptés. Mais LAN_DC n'est pas Google.

La sous-couche change relativement rarement car son travail consiste en une connectivité IP de base entre les machines physiques. Underlay ne sait rien des services, des clients ou des locataires qui s'exécutent dessus : il lui suffit de transmettre le package d'une machine à une autre.
La sous-couche pourrait ressembler à ceci :

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILLE
• L2+STP

Le réseau Underlay est configuré de manière classique : CLI/GUI/NETCONF.

Manuellement, scripts, utilitaires propriétaires.

Le prochain article de la série sera consacré plus en détail à la sous-couche.

Recouvrir

Overlay est un réseau virtuel de tunnels étendus au-dessus d'Underlay, il permet aux machines virtuelles d'un client de communiquer entre elles, tout en assurant une isolation des autres clients.

Les données client sont encapsulées dans certains en-têtes de tunneling pour être transmises sur le réseau public.

Ainsi, les machines virtuelles d'un client (un service) peuvent communiquer entre elles via Overlay, sans même savoir quel chemin emprunte réellement le paquet.

La superposition pourrait être, par exemple, comme je l'ai mentionné ci-dessus :

• Tunnel GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

Un réseau superposé est généralement configuré et maintenu via un contrôleur central. À partir de là, la configuration, le plan de contrôle et le plan de données sont transmis aux appareils qui acheminent et encapsulent le trafic client. Un peu au-dessous Regardons cela avec des exemples.

Oui, il s’agit bien du SDN dans sa forme la plus pure.

Il existe deux approches fondamentalement différentes pour organiser un réseau Overlay :

1. Superposition avec les TdR
2. Superposition de l'hôte

Superposition avec les TdR

La superposition peut commencer au niveau du commutateur d'accès (ToR) situé dans le rack, comme cela se produit, par exemple, dans le cas d'une structure VXLAN.

Il s'agit d'un mécanisme éprouvé sur les réseaux des FAI et tous les fournisseurs d'équipements réseau le prennent en charge.

Cependant, dans ce cas, le commutateur ToR doit être capable de séparer respectivement les différents services et l'administrateur réseau doit, dans une certaine mesure, coopérer avec les administrateurs de machines virtuelles et apporter des modifications (bien que automatiquement) à la configuration des appareils. .

Ici, je renvoie le lecteur à un article sur VxLAN sur Habré notre vieil ami @bormoglotx.
Dans ce présentations avec ENOG les approches de construction d'un réseau DC avec une structure EVPN VXLAN sont décrites en détail.

Et pour une immersion plus complète dans la réalité, vous pouvez lire le livre de Tsiska Une infrastructure moderne, ouverte et évolutive : VXLAN EVPN.

Je note que VXLAN n'est qu'une méthode d'encapsulation et que la terminaison des tunnels peut se produire non pas sur ToR, mais sur l'hôte, comme c'est le cas dans le cas d'OpenStack, par exemple.

Cependant, la structure VXLAN, où la superposition commence au niveau du ToR, est l'une des conceptions de réseau de superposition établies.

Superposition de l'hôte

Une autre approche consiste à démarrer et terminer les tunnels sur les hôtes finaux.
Dans ce cas, le réseau (Underlay) reste le plus simple et statique possible.
Et l’hôte effectue lui-même toute l’encapsulation nécessaire.

Cela nécessitera bien sûr d'exécuter une application spéciale sur les hôtes, mais cela en vaut la peine.

Premièrement, exécuter un client sur une machine Linux est plus facile ou, disons, même possible, tandis que sur un switch, vous devrez probablement vous tourner vers des solutions SDN propriétaires, ce qui tue l'idée du multi-fournisseur.

Deuxièmement, le changement de ToR dans ce cas peut rester aussi simple que possible, à la fois du point de vue du plan de contrôle et du plan de données. En effet, il n'a alors pas besoin de communiquer avec le contrôleur SDN, ni de stocker les réseaux/ARP de tous les clients connectés - il suffit de connaître l'adresse IP de la machine physique, ce qui simplifie grandement la commutation/ tables de routage.

Dans la série ADSM, je choisis l'approche de superposition de l'hôte - alors nous n'en parlons que et nous ne reviendrons pas à l'usine VXLAN.

Il est plus simple de regarder des exemples. Et comme sujet de test, nous prendrons la plateforme OpenSource SDN OpenContrail, désormais connue sous le nom de Tissu de tungstène.

À la fin de l'article, je donnerai quelques réflexions sur l'analogie avec OpenFlow et OpenvSwitch.

Utiliser le tissu en tungstène comme exemple

Chaque machine physique possède vRouteur - un routeur virtuel qui connaît les réseaux qui y sont connectés et à quels clients ils appartiennent - essentiellement un routeur PE. Pour chaque client, il maintient une table de routage isolée (lecture VRF). Et vRouter effectue réellement le tunneling Overlay.

Un peu plus sur vRouter se trouve à la fin de l'article.

Chaque VM située sur l'hyperviseur est connectée au vRouter de cette machine via Interface TAP.

TAP - Terminal Access Point - une interface virtuelle dans le noyau Linux qui permet l'interaction réseau.

S'il existe plusieurs réseaux derrière le vRouter, alors une interface virtuelle est créée pour chacun d'eux, à laquelle une adresse IP est attribuée - ce sera l'adresse de passerelle par défaut.
Tous les réseaux d'un client sont placés en un seul VRF (une table), différentes - en différentes.
Je ferai ici un avertissement sur le fait que tout n'est pas si simple, et j'enverrai le lecteur curieux à la fin de l'article.

Afin que les vRouters puissent communiquer entre eux, et donc avec les VM situées derrière eux, ils échangent des informations de routage via Contrôleur SDN.

Pour sortir vers le monde extérieur, il existe un point de sortie de la matrice - une passerelle de réseau virtuel VNGW - Passerelle de réseau virtuel (mon mandat).

Examinons maintenant des exemples de communications - et ce sera plus clair.

Communication au sein d’une seule machine physique

VM0 veut envoyer un paquet à VM2. Supposons pour l'instant qu'il s'agit d'une VM client unique.

Plan de données

1. VM-0 a une route par défaut vers son interface eth0. Le colis y est envoyé.
   Cette interface eth0 est en fait connectée virtuellement au routeur virtuel vRouter via l'interface TAP tap0.
2. vRouter analyse à quelle interface le paquet est arrivé, c'est-à-dire à quel client (VRF) il appartient, et vérifie l'adresse du destinataire avec la table de routage de ce client.
3. Après avoir détecté que le destinataire sur la même machine se trouve sur un port différent, vRouter lui envoie simplement le paquet sans en-têtes supplémentaires - dans ce cas, vRouter dispose déjà d'un enregistrement ARP.

Dans ce cas, le paquet n’entre pas dans le réseau physique : il est acheminé à l’intérieur du vRouter.

Avion de contrôle

Au démarrage de la machine virtuelle, l'hyperviseur lui indique :

• Sa propre adresse IP.
• L'itinéraire par défaut passe par l'adresse IP du vRouter sur ce réseau.

L'hyperviseur rend compte à vRouter via une API spéciale :

• Ce dont vous avez besoin pour créer une interface virtuelle.
• Quel type de réseau virtuel la VM doit-elle créer ?
• À quel VRF (VN) le lier.
• Une entrée ARP statique pour cette VM - quelle interface se trouve derrière son adresse IP et à quelle adresse MAC elle est associée.

Encore une fois, la procédure d'interaction réelle est simplifiée dans un souci de compréhension du concept.

Ainsi, vRouter considère toutes les machines virtuelles d'un client sur une machine donnée comme des réseaux directement connectés et peut lui-même acheminer entre elles.

Mais VM0 et VM1 appartiennent à des clients différents et, par conséquent, se trouvent dans des tables vRouter différentes.

Leur capacité à communiquer directement entre eux dépend des paramètres du vRouter et de la conception du réseau.
Par exemple, si les machines virtuelles des deux clients utilisent des adresses publiques ou si le NAT se produit sur le vRouter lui-même, un routage direct vers le vRouter peut être effectué.

Dans la situation inverse, il est possible de traverser les espaces d'adressage - vous devez passer par un serveur NAT pour obtenir une adresse publique - c'est similaire à l'accès aux réseaux externes, qui sont abordés ci-dessous.

Communication entre VM situées sur différentes machines physiques

Plan de données

1. Le début est exactement le même : VM-0 envoie un paquet avec la destination VM-7 (172.17.3.2) par défaut.
2. vRouter le reçoit et voit cette fois que la destination se trouve sur une autre machine et est accessible via Tunnel0.
3. Tout d'abord, il accroche une étiquette MPLS identifiant l'interface distante, de sorte qu'au verso, vRouter puisse déterminer où placer ce paquet sans recherches supplémentaires.

   

4. Tunnel0 a la source 10.0.0.2, destination : 10.0.1.2.
   vRouter ajoute des en-têtes GRE (ou UDP) et une nouvelle adresse IP au paquet d'origine.
5. La table de routage vRouter a une route par défaut via l'adresse ToR1 10.0.0.1. C'est là qu'il l'envoie.

   
   

6. ToR1, en tant que membre du réseau Underlay, sait (par exemple, via OSPF) comment accéder à 10.0.1.2 et envoie le paquet le long de la route. Notez qu'ECMP est activé ici. Il y a deux sauts suivants dans l'illustration, et différents threads y seront triés par hachage. Dans le cas d’une véritable usine, il y aura plus probablement 4 prochains sauts.

   Dans le même temps, il n'a pas besoin de savoir ce qu'il y a sous l'en-tête IP externe. Autrement dit, sous IP, il peut y avoir un sandwich IPv6 sur MPLS sur Ethernet sur MPLS sur GRE sur grec.

7. En conséquence, du côté de la réception, vRouter supprime GRE et, à l'aide de la balise MPLS, comprend à quelle interface ce paquet doit être envoyé, le supprime et l'envoie sous sa forme originale au destinataire.

Avion de contrôle

Lorsque vous démarrez la voiture, la même chose se produit comme décrit ci-dessus.

Et plus les éléments suivants :

• Pour chaque client, vRouter alloue une balise MPLS. Il s'agit du label de service L3VPN, par lequel les clients seront séparés au sein de la même machine physique.
  

  En fait, la balise MPLS est toujours attribuée de manière inconditionnelle par le vRouter - après tout, on ne sait pas à l'avance que la machine n'interagira qu'avec d'autres machines derrière le même vRouter et ce n'est probablement même pas vrai.

• vRouter établit une connexion avec le contrôleur SDN en utilisant le protocole BGP (ou similaire - dans le cas de TF, il s'agit de XMPP 0_o).
• Grâce à cette session, vRouter signale les routes vers les réseaux connectés au contrôleur SDN :
  • Adresse réseau
  • Méthode d'encapsulation (MPLSoGRE, MPLSoUDP, VXLAN)
  • Balise client MPLS
  • Votre adresse IP comme nexthop

• Le contrôleur SDN reçoit ces routes de tous les vRouters connectés et les reflète sur les autres. Autrement dit, il agit comme un réflecteur de route.

La même chose se produit dans la direction opposée.

La superposition peut changer au moins toutes les minutes. C’est à peu près ce qui se passe dans les cloud publics, où les clients démarrent et arrêtent régulièrement leurs machines virtuelles.

Le contrôleur central prend en charge toute la complexité de la maintenance de la configuration et de la surveillance des tables de commutation/routage sur le vRouter.

En gros, le contrôleur communique avec tous les vRouters via BGP (ou un protocole similaire) et transmet simplement les informations de routage. BGP, par exemple, dispose déjà d'Address-Family pour transmettre la méthode d'encapsulation MPLS-dans-GRE ou MPLS-dans-UDP.

Dans le même temps, la configuration du réseau Underlay ne change en rien, ce qui est d'ailleurs beaucoup plus difficile à automatiser, et plus facile à rompre avec un mouvement maladroit.

Sortie vers le monde extérieur

Quelque part, la simulation doit se terminer et vous devez quitter le monde virtuel pour entrer dans le monde réel. Et vous avez besoin d’une passerelle téléphonique payante.

Deux approches sont pratiquées :

1. Un routeur matériel est installé.
2. Une appliance est lancée qui implémente les fonctions d'un routeur (oui, suite au SDN, nous avons également rencontré VNF). Appelons cela une passerelle virtuelle.

L'avantage de la deuxième approche est une évolutivité horizontale bon marché - il n'y a pas assez de puissance - nous avons lancé une autre machine virtuelle avec une passerelle. Sur n'importe quelle machine physique, sans avoir à rechercher des racks, des unités, une puissance de sortie gratuits, acheter le matériel lui-même, le transporter, l'installer, le commuter, le configurer, puis également y changer les composants défectueux.

Les inconvénients d'une passerelle virtuelle sont qu'une unité d'un routeur physique est toujours des ordres de grandeur plus puissante qu'une machine virtuelle multicœur, et son logiciel, adapté à sa propre base matérielle, fonctionne beaucoup plus stable (aucun). Il est également difficile de nier le fait que le complexe matériel et logiciel fonctionne simplement, ne nécessitant qu'une configuration, tandis que le lancement et la maintenance d'une passerelle virtuelle sont une tâche réservée à des ingénieurs chevronnés.

D'un seul pied, la passerelle examine le réseau virtuel Overlay, comme une machine virtuelle classique, et peut interagir avec toutes les autres machines virtuelles. En même temps, il peut terminer les réseaux de tous les clients et, par conséquent, effectuer le routage entre eux.

De son autre pied, la passerelle examine le réseau fédérateur et sait comment accéder à Internet.

Plan de données

Autrement dit, le processus ressemble à ceci :

1. VM-0, ayant choisi par défaut le même vRouter, envoie un paquet avec une destination dans le monde extérieur (185.147.83.177) à l'interface eth0.
2. vRouter reçoit ce paquet et recherche l'adresse de destination dans la table de routage - trouve la route par défaut via la passerelle VNGW1 via le tunnel 1.
   Il voit également qu'il s'agit d'un tunnel GRE avec SIP 10.0.0.2 et DIP 10.0.255.2, et il doit également d'abord attacher l'étiquette MPLS de ce client, ce que VNGW1 attend.
3. vRouter emballe le paquet initial avec MPLS, GRE et de nouveaux en-têtes IP et l'envoie à ToR1 10.0.0.1 par défaut.
4. Le réseau sous-jacent délivre le paquet à la passerelle VNGW1.
5. La passerelle VNGW1 supprime les en-têtes de tunnel GRE et MPLS, voit l'adresse de destination, consulte sa table de routage et comprend qu'elle est dirigée vers Internet, c'est-à-dire via Full View ou Default. Si nécessaire, effectue la traduction NAT.
6. Il pourrait y avoir un réseau IP régulier entre VNGW et la frontière, ce qui est peu probable.
   Il peut y avoir un réseau MPLS classique (IGP+LDP/RSVP TE), il peut y avoir une back fabric avec BGP LU ou un tunnel GRE de VNGW à la frontière via un réseau IP.
   Quoi qu'il en soit, VNGW1 effectue les encapsulations nécessaires et envoie le paquet initial vers la frontière.

La circulation en sens inverse passe par les mêmes étapes dans l'ordre inverse.

1. La frontière dépose le paquet vers VNGW1
2. Il le déshabille, regarde l'adresse du destinataire et constate qu'il est accessible via le tunnel Tunnel1 (MPLSoGRE ou MPLSoUDP).
3. En conséquence, il attache une étiquette MPLS, un en-tête GRE/UDP et une nouvelle IP et l'envoie à son ToR3 10.0.255.1.
   L'adresse de destination du tunnel est l'adresse IP du vRouter derrière lequel se trouve la VM cible - 10.0.0.2.
4. Le réseau sous-jacent transmet le paquet au vRouter souhaité.
5. Le vRouter cible lit GRE/UDP, identifie l'interface à l'aide de l'étiquette MPLS et envoie un paquet IP nu à son interface TAP associée à eth0 de la VM.

Avion de contrôle

VNGW1 établit un voisinage BGP avec un contrôleur SDN, à partir duquel il reçoit toutes les informations de routage sur les clients : quelle adresse IP (vRouter) se trouve derrière quel client et par quelle étiquette MPLS il est identifié.

De même, il informe lui-même le contrôleur SDN de la route par défaut avec le label de ce client, en s'indiquant comme nexthop. Et puis cette valeur par défaut arrive aux vRouters.

Sur VNGW, l'agrégation de routes ou la traduction NAT se produit généralement.

Et dans l’autre sens, il envoie exactement cette route agrégée à la session avec des bordures ou des Route Reflectors. Et d'eux, il reçoit l'itinéraire par défaut ou Full-View, ou autre chose.

En termes d'encapsulation et d'échange de trafic, VNGW n'est pas différent de vRouter.
Si vous élargissez un peu la portée, vous pouvez ajouter d'autres périphériques réseau aux VNGW et aux vRouters, tels que des pare-feu, des fermes de nettoyage ou d'enrichissement du trafic, des IPS, etc.

Et avec l'aide de la création séquentielle de VRF et de l'annonce correcte des itinéraires, vous pouvez forcer le trafic à boucler comme vous le souhaitez, ce qu'on appelle le chaînage de services.

Autrement dit, ici aussi, le contrôleur SDN agit comme un réflecteur de route entre les VNGW, les vRouters et d'autres périphériques réseau.

Mais en fait, le contrôleur publie également des informations sur l'ACL et le PBR (Policy Based Routing), ce qui fait que les flux de trafic individuels se déroulent différemment de ce que l'itinéraire leur indique.

QFP

Pourquoi faites-vous toujours la remarque GRE/UDP ?

Eh bien, en général, cela peut être considéré comme spécifique au Tungsten Fabric – vous n’avez pas du tout besoin d’en tenir compte.

Mais si nous le prenons, alors TF lui-même, tout en restant OpenContrail, prenait en charge les deux encapsulations : MPLS en GRE et MPLS en UDP.

UDP est bon car dans le port source, il est très facile d'encoder une fonction de hachage à partir de l'IP+Proto+Port d'origine dans son en-tête, ce qui vous permettra de faire un équilibrage.

Dans le cas de GRE, hélas, il n'y a que des en-têtes IP et GRE externes, qui sont les mêmes pour tout le trafic encapsulé et il n'est pas question d'équilibrage - peu de gens peuvent regarder aussi profondément dans le paquet.

Jusqu'à quelque temps, les routeurs, s'ils savaient utiliser les tunnels dynamiques, ne le faisaient qu'en MPLSoGRE, et ce n'est que très récemment qu'ils ont appris à utiliser MPLSoUDP. Par conséquent, nous devons toujours noter la possibilité de deux encapsulations différentes.

En toute honnêteté, il convient de noter que TF prend entièrement en charge la connectivité L2 utilisant VXLAN.

Vous avez promis de faire des parallèles avec OpenFlow.
Ils le demandent vraiment. vSwitch dans le même OpenStack fait des choses très similaires, en utilisant VXLAN, qui, soit dit en passant, possède également un en-tête UDP.

Dans le plan de données, ils fonctionnent à peu près de la même manière ; le plan de contrôle diffère considérablement. Tungsten Fabric utilise XMPP pour fournir des informations de routage à vRouter, tandis qu'OpenStack exécute Openflow.

Pouvez-vous m'en dire un peu plus sur vRouter ?
Il est divisé en deux parties : vRouter Agent et vRouter Forwarder.

Le premier s'exécute dans l'espace utilisateur du système d'exploitation hôte et communique avec le contrôleur SDN, échangeant des informations sur les routes, les VRF et les ACL.

Le second implémente le plan de données - généralement dans l'espace noyau, mais peut également fonctionner sur des SmartNIC - des cartes réseau avec un processeur et une puce de commutation programmable séparée, ce qui vous permet de supprimer la charge du processeur de la machine hôte et de rendre le réseau plus rapide et plus performant. prévisible.

Un autre scénario possible est que vRouter soit une application DPDK dans l'espace utilisateur.

vRouter Agent envoie les paramètres à vRouter Forwarder.

Qu'est-ce qu'un réseau virtuel ?
J'ai mentionné au début de l'article sur le VRF que chaque locataire est lié à son propre VRF. Et si cela suffisait pour une compréhension superficielle du fonctionnement du réseau overlay, alors à la prochaine itération il faudra apporter des éclaircissements.

Généralement, dans les mécanismes de virtualisation, l'entité Réseau Virtuel (vous pouvez considérer cela comme un nom propre) est introduite séparément des clients/locataires/machines virtuelles - une chose complètement indépendante. Et ce réseau virtuel peut déjà être connecté via des interfaces à un locataire, à un autre, à deux ou n'importe où. Ainsi, par exemple, le chaînage de services est mis en œuvre lorsque le trafic doit passer par certains nœuds dans l'ordre requis, simplement en créant et en connectant des réseaux virtuels dans l'ordre correct.

Il n’y a donc pas de correspondance directe entre le Réseau Virtuel et le locataire.

Conclusion

Il s'agit d'une description très superficielle du fonctionnement d'un réseau virtuel avec une superposition de l'hôte et d'un contrôleur SDN. Mais quelle que soit la plateforme de virtualisation que vous choisissez aujourd'hui, elle fonctionnera de la même manière, qu'il s'agisse de VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ou Juniper Contrail. Ils diffèrent par les types d'encapsulations et d'en-têtes, les protocoles de transmission des informations aux périphériques réseau finaux, mais le principe d'un réseau superposé configurable par logiciel fonctionnant au-dessus d'un réseau sous-jacent relativement simple et statique restera le même.
On peut dire qu'aujourd'hui le SDN basé sur un réseau superposé a gagné le domaine de la création d'un cloud privé. Cependant, cela ne signifie pas qu'Openflow n'a pas sa place dans le monde moderne - il est utilisé dans OpenStacke et dans le même VMWare NSX, pour autant que je sache, Google l'utilise pour mettre en place le réseau souterrain.

Ci-dessous, j'ai fourni des liens vers des documents plus détaillés si vous souhaitez approfondir le problème.

Et qu’en est-il de notre sous-couche ?

Mais en général, rien. Il n'a pas complètement changé. Tout ce qu'il a à faire dans le cas d'une superposition de l'hôte est de mettre à jour les routes et les ARP lorsque vRouter/VNGW apparaît et disparaît et transporte des paquets entre eux.

Formulons une liste d'exigences pour le réseau Underlay.

1. Pouvoir utiliser une sorte de protocole de routage, dans notre situation - BGP.
2. Avoir une large bande passante, de préférence sans surabonnement, afin que les paquets ne soient pas perdus à cause des surcharges.
3. La prise en charge d'ECMP fait partie intégrante du tissu.
4. Être capable de fournir une qualité de service, y compris des éléments délicats comme ECN.
5. Soutenir NETCONF est une base pour l’avenir.

J'ai consacré ici très peu de temps au travail du réseau Underlay lui-même. En effet, plus tard dans la série, je me concentrerai là-dessus, et nous n'aborderons qu'Overlay en passant.

Évidemment, je nous limite tous sévèrement en utilisant comme exemple un réseau DC construit dans une usine Cloz avec un routage IP pur et une superposition de l'hôte.

Cependant, je suis convaincu que tout réseau doté d’une conception peut être décrit en termes formels et automatisé. C'est juste que mon objectif ici est de comprendre les approches de l'automatisation, et de ne pas confondre tout le monde en résolvant le problème sous une forme générale.

Dans le cadre de l'ADSM, Roman Gorge et moi prévoyons de publier un numéro distinct sur la virtualisation de la puissance de calcul et son interaction avec la virtualisation des réseaux. Reste en contact.

Liens utiles

• Architecture du tissu en tungstène.
• à propos de :nuage. 6 heures sur Yandex.Cloud, qui couvre également le réseau virtuel sur TF.
• Qu’est-ce qu’Open vSwitch ?
• Introduction à VxLAN.
• RFC 7348. Réseau local virtuel extensible (VXLAN) : un cadre pour superposer des réseaux virtualisés de couche 2 sur des réseaux de couche 3.
  
• Approche Scaleway de VXLAN EVPN Fabric. Il parle de l'ensemble du réseau DC, y compris Underlay, Overlay, des approches de multi-hébergement et de gestion.

Merci

• Gorga romaine - ancien animateur du podcast linkmeup et désormais expert dans le domaine des plateformes cloud. Pour les commentaires et les modifications. Eh bien, nous attendons son article plus approfondi sur la virtualisation dans un avenir proche.
• Alexandre Chalimov - mon collègue et expert dans le domaine du développement de réseaux virtuels. Pour les commentaires et les modifications.
• Valentin Sinitsyne - mon collègue et expert dans le domaine du Tungsten Fabric. Pour les commentaires et les modifications.
• Artyom Tchernobaï — lien illustrateur. Pour KDPV.
• Alexandre Limonov. Pour le mème "automate".

Source: habr.com