Dans les deux premiers articles, j'ai évoqué la question de l'automatisation et esquissé son cadre, dans le second j'ai fait un repli sur la virtualisation des réseaux, comme première approche de l'automatisation de la configuration des services.
Il est maintenant temps de dessiner un schéma du réseau physique.

Si vous n'êtes pas familier avec la configuration de réseaux de centres de données, je vous recommande fortement de commencer par des articles à leur sujet.

Tous les problèmes :

• 0. ADSM. Partie zéro. Planification
• 1. ADSM. Première partie (qui est après zéro). Virtualisation du réseau
• 2. ADSM. Deuxième partie. Conception de réseau

Les pratiques décrites dans cette série doivent être applicables à tout type de réseau, de toute taille, avec toute variété de fournisseurs (non). Il est cependant impossible de décrire un exemple universel d’application de ces approches. Par conséquent, je me concentrerai sur l’architecture moderne du réseau DC : Usine Kloz.
Nous ferons du DCI sur MPLS L3VPN.

Un réseau Overlay s'exécute au-dessus du réseau physique de l'hôte (il peut s'agir du VXLAN ou du Tungsten Fabric d'OpenStack ou de tout autre élément nécessitant uniquement une connectivité IP de base du réseau).

Dans ce cas, nous obtenons un scénario d’automatisation relativement simple, car nous disposons de nombreux équipements configurés de la même manière.

Nous choisirons une DC sphérique dans le vide :

• Une version design partout.
• Deux fournisseurs formant deux plans réseau.
• Un DC est comme un autre, comme deux petits pois dans une cosse.

Teneur

• Topologie physique
• Routage
• Forfait IP
• Laba
• Conclusion
• Liens utiles

Laissez notre fournisseur de services LAN_DC, par exemple, héberger des vidéos de formation sur la survie dans des ascenseurs bloqués.

Dans les mégalopoles, cela est très populaire, vous avez donc besoin de beaucoup de machines physiques.

Tout d'abord, je vais décrire le réseau approximativement tel que je voudrais qu'il soit. Et puis je vais le simplifier pour le laboratoire.

Topologie physique

Emplacements

LAN_DC aura 6 DC :

• Russie (RU):
  • Moscou (msk)
  • Kazan (kzn)

• Espagne (SP):
  • Barcelone (BCN)
  • Málaga (mlg)

• Chine (CN):
  • Shanghai (sha)
  • Xi'an (que)

À l'intérieur du DC (Intra-DC)

Tous les DC disposent de réseaux de connectivité internes identiques basés sur la topologie Clos.
De quels types de réseaux Clos s'agit-il et pourquoi sont-ils dans un secteur distinct ? article.

Chaque DC dispose de 10 racks avec des machines, ils seront numérotés comme A, B, C Et ainsi de suite.

Chaque rack contient 30 machines. Ils ne nous intéresseront pas.

Dans chaque rack se trouve également un commutateur auquel toutes les machines sont connectées - c'est Commutateur haut du rack - TdR ou autrement, en termes d'usine Clos, nous l'appellerons Feuille des Arbres.

Schéma général de l'usine.

Nous les appellerons XXX-feuilleYOù XXX - l'abréviation de trois lettres DC, et Y - numéro de série. Par exemple, kzn-feuille11.

Dans mes articles, je me permettrai d’utiliser les termes Leaf et ToR de manière plutôt frivole comme synonymes. Cependant, nous devons nous rappeler que ce n’est pas le cas.
ToR est un switch installé dans un rack auquel sont connectées des machines.
Leaf est le rôle d'un appareil dans un réseau physique ou d'un commutateur de premier niveau en termes de topologie Cloes.
Autrement dit, Leaf != ToR.
Ainsi, Leaf peut être un commutateur EndofRaw, par exemple.
Cependant, dans le cadre de cet article, nous les traiterons toujours comme des synonymes.

Chaque commutateur ToR est à son tour connecté à quatre commutateurs d'agrégation de niveau supérieur : Colonne vertébrale. Un rack dans le DC est alloué aux Spines. Nous le nommerons de la même manière : XXX-colonne vertébraleY.

Le même rack contiendra des équipements réseau pour la connectivité entre les routeurs DC-2 avec MPLS intégré. Mais dans l’ensemble, ce sont les mêmes TdR. Autrement dit, du point de vue des commutateurs Spine, les ToR habituels avec des machines connectées ou un routeur pour DCI n'ont aucune importance - juste le transfert.

Ces TdR spéciaux sont appelés Feuille de bord. Nous les appellerons XXX-bordY.

Il ressemblera à ceci.

Dans le diagramme ci-dessus, j'ai en fait placé le bord et la feuille au même niveau. Réseaux classiques à trois couches Ils nous ont appris à considérer les liaisons montantes (d'où le terme) comme des liaisons montantes. Et ici, il s’avère que la « liaison montante » DCI redescend, ce qui pour certains brise légèrement la logique habituelle. Dans le cas de grands réseaux, lorsque les centres de données sont divisés en unités encore plus petites - POD(Point de livraison), mettez en surbrillance l'individu Edge-PODC'est pour DCI et l'accès aux réseaux externes.

Pour faciliter la perception à l'avenir, je dessinerai toujours Edge sur Spine, tout en gardant à l'esprit qu'il n'y a pas d'intelligence sur Spine et qu'il n'y a aucune différence lorsque l'on travaille avec Leaf et Edge-leaf classiques (bien qu'il puisse y avoir des nuances ici , mais en général c'est vrai).

Schéma d'une usine avec Edge-leafs.

La trinité Leaf, Spine et Edge forme un réseau ou une usine Underlay.

La tâche d'une fabrique de réseaux (lire Underlay), telle que nous l'avons déjà définie dans dernier numéro, très, très simple - pour fournir une connectivité IP entre les machines à la fois au sein du même DC et entre elles.
C'est pourquoi le réseau est appelé une usine, tout comme, par exemple, une usine de commutation à l'intérieur de boîtiers réseau modulaires, dont vous pouvez en savoir plus dans SDSM14.

En général, une telle topologie est appelée usine, car tissu en traduction signifie tissu. Et il est difficile d’être en désaccord :

L'usine est entièrement L3. Pas de VLAN, pas de diffusion - nous avons des programmeurs formidables chez LAN_DC, ils savent comment écrire des applications qui vivent dans le paradigme L3, et les machines virtuelles ne nécessitent pas de migration en direct avec préservation de l'adresse IP.

Et encore une fois : la réponse à la question pourquoi l'usine et pourquoi L3 est dans un endroit séparé article.

DCI - Interconnexion du centre de données (Inter-DC)

DCI sera organisé en utilisant Edge-Leaf, c'est-à-dire qu'ils constitueront notre point de sortie vers l'autoroute.
Pour simplifier, nous supposons que les DC sont connectés entre eux par des liens directs.
Excluons la connectivité externe de la considération.

Je suis conscient qu'à chaque fois que je supprime un composant, je simplifie considérablement le réseau. Et quand nous automatiserons notre réseau abstrait, tout ira bien, mais sur le vrai il y aura des béquilles.
C'est vrai. Pourtant, le but de cette série est de réfléchir et de travailler sur des approches, et non de résoudre héroïquement des problèmes imaginaires.

Sur Edge-Leafs, la sous-couche est placée dans le VPN et transmise via le backbone MPLS (le même lien direct).

C'est le diagramme de niveau supérieur que nous obtenons.

Routage

Pour le routage au sein du DC, nous utiliserons BGP.
Sur le tronc MPLS OSPF+LDP.
Pour DCI, c'est-à-dire organiser la connectivité dans le métro - BGP L3VPN sur MPLS.

Schéma de routage général

Il n'y a pas d'OSPF ni d'ISIS (protocole de routage interdit dans la Fédération de Russie) en usine.

Cela signifie qu'il n'y aura pas de découverte automatique ni de calcul des chemins les plus courts - uniquement une configuration manuelle (en fait automatique - nous parlons ici d'automatisation) du protocole, du voisinage et des politiques.

Schéma de routage BGP au sein du DC

Pourquoi BGP ?

Sur ce sujet, il y a RFC entière nommé d'après Facebook et Arista, qui explique comment construire très grand réseaux de centres de données utilisant BGP. Cela se lit presque comme une fiction, je le recommande vivement pour une soirée langoureuse.

Et il y a aussi toute une section dans mon article dédiée à cela. Où est-ce que je t'emmène et j'envoie.

Mais en bref, aucun IGP n'est adapté aux réseaux de grands centres de données, où le nombre de périphériques réseau se compte par milliers.

De plus, utiliser BGP partout vous permettra de ne pas perdre de temps sur la prise en charge de plusieurs protocoles différents et la synchronisation entre eux.

La main sur le cœur, dans notre usine, qui, avec une forte probabilité, ne connaîtra pas une croissance rapide, OSPF suffirait pour les yeux. Ce sont en fait les problèmes des mégascalers et des titans du cloud. Mais imaginons juste pour quelques versions dont nous en avons besoin, et nous utiliserons BGP, comme l'a légué Piotr Lapukhov.

Politiques de routage

Sur les commutateurs Leaf, nous importons les préfixes des interfaces réseau Underlay dans BGP.
Nous aurons une session BGP entre chaque une paire Leaf-Spine, dans laquelle ces préfixes Underlay seront annoncés ici et là sur le réseau.

Au sein d'un centre de données, nous distribuerons les spécifications que nous avons importées dans ToRe. Sur Edge-Leafs, nous les regrouperons, les annoncerons aux DC distants et les enverrons aux TOR. Autrement dit, chaque ToR saura exactement comment accéder à un autre ToR dans le même DC et où se trouve le point d’entrée pour accéder aux ToR dans un autre DC.

En DCI, les routes seront transmises en VPNv4. Pour ce faire, sur Edge-Leaf, l'interface vers l'usine sera placée dans un VRF, appelons-le UNDERLAY, et le quartier avec Spine sur Edge-Leaf s'élèvera au sein du VRF, et entre Edge-Leafs dans le VPNv4- famille.

Nous interdirons également la réannonce des itinéraires reçus des épines vers eux.

Sur Leaf et Spine, nous n'importerons pas de Loopbacks. Nous n’en avons besoin que pour déterminer l’ID du routeur.

Mais sur Edge-Leafs, nous l'importons dans Global BGP. Entre les adresses de bouclage, Edge-Leafs établira entre eux une session BGP dans la famille VPN IPv4.

Nous aurons un backbone OSPF+LDP entre les appareils EDGE. Tout est dans une seule zone. Configuration extrêmement simple.

C'est la photo avec le routage.

ASN BGP

ASN à feuille de bord

Sur Edge-Leafs, il y aura un ASN dans tous les DC. Il est important qu'il y ait iBGP entre Edge-Leafs, et nous ne nous laissons pas entraîner dans les nuances d'eBGP. Soit 65535. En réalité, cela pourrait être le numéro d'un AS public.

ASN de la colonne vertébrale

Sur Spine, nous aurons un ASN par DC. Commençons ici par le tout premier numéro de la gamme des AS privés - 64512, 64513 et ainsi de suite.

Pourquoi ASN sur DC ?

Décomposons cette question en deux :

• Pourquoi les ASN sont-ils les mêmes sur toutes les tranches d’un même DC ?
• Pourquoi sont-ils différents selon les DC ?

Pourquoi y a-t-il les mêmes ASN sur toutes les tranches d’un même DC ?

Voici à quoi ressemblera le chemin AS de la route Underlay sur Edge-Leaf :
[leafX_ASN, spine_ASN, edge_ASN]
Lorsque vous essayez de le renvoyer à Spine, il le supprimera car son AS (Spine_AS) est déjà dans la liste.

Cependant, au sein du DC, nous sommes entièrement convaincus que les routes Underlay qui montent jusqu'au Edge ne pourront pas descendre. Toutes les communications entre les hôtes au sein du DC doivent avoir lieu au niveau de la colonne vertébrale.

Dans ce cas, les routes agrégées des autres DC atteindront de toute façon facilement les ToR - leur AS-Path n'aura que l'ASN 65535 - le nombre d'AS Edge-Leafs, car c'est là qu'ils ont été créés.

Pourquoi sont-ils différents selon les DC ?

Théoriquement, nous devrons peut-être faire glisser Loopback et certaines machines virtuelles de service entre les contrôleurs de domaine.

Par exemple, sur l'hôte, nous exécuterons Route Reflector ou le même VNGW (Virtual Network Gateway), qui se verrouillera avec TopR via BGP et annoncera son bouclage, qui devrait être accessible depuis tous les DC.

Voici donc à quoi ressemblera son AS-Path :
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Et il ne devrait y avoir aucun ASN en double nulle part.

Autrement dit, Spine_DC1 et Spine_DC2 doivent être différents, tout comme leafX_DC1 et leafY_DC2, ce qui est exactement ce à quoi nous approchons.

Comme vous le savez probablement, il existe des hacks qui vous permettent d'accepter des routes avec des ASN en double malgré le mécanisme de prévention des boucles (allowas-in sur Cisco). Et il a même des usages légitimes. Mais il s’agit là d’une faille potentielle dans la stabilité du réseau. Et personnellement, je suis tombé dedans à plusieurs reprises.

Et si nous avons la possibilité de ne pas utiliser de choses dangereuses, nous en profiterons.

Feuille ASN

Nous aurons un ASN individuel sur chaque commutateur Leaf à travers le réseau.
Nous faisons cela pour les raisons évoquées ci-dessus : AS-Path sans boucles, configuration BGP sans signets.

Pour que les itinéraires entre les Leafs se déroulent sans problème, l'AS-Path devrait ressembler à ceci :
[leafX_ASN, spine_ASN, leafY_ASN]
où leafX_ASN et leafY_ASN seraient bien différents.

Ceci est également requis pour la situation d'annonce d'un bouclage VNF entre DC :
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Nous utiliserons un ASN de 4 octets et le générerons en fonction de l'ASN du Spine et du numéro du commutateur Leaf, à savoir, comme ceci : Colonne vertébrale_ASN.0000X.

C'est la photo avec l'ASN.

Forfait IP

Fondamentalement, nous devons attribuer des adresses pour les connexions suivantes :

1. Adresses réseau sous-jacentes entre les ToR et la machine. Ils doivent être uniques sur l’ensemble du réseau afin que n’importe quelle machine puisse communiquer avec une autre. Très bien ajusté 10/8. Pour chaque rack il y en a /26 avec une réserve. Nous allouerons /19 par DC et /17 par région.
2. Adresses de liens entre Leaf/Tor et Spine.

   Je voudrais les attribuer de manière algorithmique, c'est-à-dire les calculer à partir des noms des appareils qui doivent être connectés.

   Qu'il en soit ainsi... 169.254.0.0/16.
   À savoir 169.254.00X.Y/31Où X - Numéro de dos, Y — Réseau P2P /31.
   Cela vous permettra de lancer jusqu'à 128 racks, et jusqu'à 10 Spines dans le DC. Les adresses de liaison peuvent (et seront) répétées de DC à DC.

3. Nous organisons la jonction Spine-Edge-Leaf sur des sous-réseaux 169.254.10X.Y/31où exactement le même X - Numéro de dos, Y — Réseau P2P /31.
4. Reliez les adresses d’Edge-Leaf au backbone MPLS. Ici, la situation est quelque peu différente - l'endroit où tous les éléments sont connectés en un seul gâteau, donc réutiliser les mêmes adresses ne fonctionnera pas - vous devez sélectionner le prochain sous-réseau libre. Prenons donc comme base 192.168.0.0/16 et nous en retirerons les gratuits.
5. Adresses de bouclage. Nous leur donnerons toute la gamme 172.16.0.0/12.
   • Leaf - /25 par DC - les mêmes 128 racks. Nous allouerons /23 par région.
   • Colonne vertébrale – /28 par DC – jusqu'à 16 colonne vertébrale. Allouons /26 par région.
   • Edge-Leaf - /29 par DC - jusqu'à 8 boîtes. Allouons /27 par région.

Si nous n'avons pas suffisamment de plages allouées dans le DC (et il n'y en aura pas - nous prétendons être des hyperscalers), nous sélectionnons simplement le bloc suivant.

C'est l'image avec l'adressage IP.

Bouclages :

Préfixe
Rôle de l'appareil
Région
ДЦ

172.16.0.0/23
bord
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
msk

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
BCN

172.16.0.40/29
mlg

172.16.0.64/27
cn
 

172.16.0.64/29
sha

172.16.0.72/29
que

172.16.2.0/23
colonne vertébrale
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
msk

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
BCN

172.16.2.80/28
mlg

172.16.2.128/26
cn
 

172.16.2.128/28
sha

172.16.2.144/28
que

172.16.8.0/21
feuille
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
msk

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
BCN

172.16.10.128/25
mlg

172.16.12.0/23
cn
 

172.16.12.0/25
sha

172.16.12.128/25
que

Thibaude:

Préfixe
Région
ДЦ

10.0.0.0/17
ru
 

10.0.0.0/19
msk

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
BCN

10.0.160.0/19
mlg

10.1.0.0/17
cn
 

10.1.0.0/19
sha

10.1.32.0/19
que

Laba

Deux vendeurs. Un réseau. ADSM.

Genévrier + Arista. Ubuntu. Bonne vieille Eve.

La quantité de ressources sur notre serveur virtuel à Mirana est encore limitée, nous utiliserons donc pour la pratique un réseau simplifié à l'extrême.

Deux centres de données : Kazan et Barcelone.

• Deux épines chacune : Genévrier et Arista.
• Un tore (Leaf) dans chacun - Juniper et Arista, avec un hôte connecté (prenons pour cela une IOL Cisco légère).
• Un nœud Edge-Leaf chacun (pour l'instant uniquement Juniper).
• Un commutateur Cisco pour les gouverner tous.
• En plus des boîtiers réseau, une machine de contrôle virtuelle fonctionne. Exécuter Ubuntu.
  Il a accès à tous les appareils, il exécutera des systèmes IPAM/DCIM, un tas de scripts Python, Ansible et tout ce dont nous pourrions avoir besoin.

Configuration complète de tous les périphériques réseau, que nous essaierons de reproduire en utilisant l'automatisation.

Conclusion

Est-ce également accepté ? Dois-je écrire une courte conclusion sous chaque article ?

Nous avons donc choisi à trois niveaux Réseau Clos à l'intérieur du DC, car nous nous attendons à beaucoup de trafic Est-Ouest et voulons ECMP.

Le réseau était divisé en physique (sous-couche) et virtuel (superposition). Dans le même temps, la superposition démarre à partir de l'hôte, simplifiant ainsi les exigences relatives à la sous-couche.

Nous avons choisi BGP comme protocole de routage pour les réseaux réseau en raison de son évolutivité et de sa flexibilité politique.

Nous aurons des nœuds séparés pour organiser DCI - Edge-leaf.
Le backbone aura OSPF+LDP.
DCI sera implémenté sur la base de MPLS L3VPN.
Pour les liens P2P, nous calculerons les adresses IP de manière algorithmique en fonction des noms d'appareils.
Nous attribuerons les bouclages en fonction du rôle des appareils et de leur emplacement de manière séquentielle.
Préfixes de sous-couche - uniquement sur les commutateurs Leaf, de manière séquentielle en fonction de leur emplacement.

Supposons qu'à l'heure actuelle, nous n'ayons pas encore installé l'équipement.
Nos prochaines étapes seront donc de les ajouter aux systèmes (IPAM, inventaire), d'organiser les accès, de générer une configuration et de la déployer.

Dans le prochain article, nous traiterons de Netbox - un système d'inventaire et de gestion de l'espace IP dans un DC.

Merci

• Andrey Glazkov alias @glazgoo pour la relecture et les corrections
• Alexander Klimenko alias @v00lk pour la relecture et les modifications
• Artyom Tchernobaï pour KDPV

Source: habr.com